关于自动化测试的思考-起源于百人计划分享

为了简化测试工作，写的小demo，只要能够帮助自己提高测试效率，那它就是自动化。

---

什么是自动化测试？###

【摘取自虫师的博文】首先理清自动化测试的概念，广义上来讲，自动化包括一切通过工具（程序）的方式来代替或辅助手工测试的行为都可以看做自动化，包括性能测试工具（loadrunner、jmeter）,或自己所写的一段程序，用于生成1到100个测试数据。狭义上来讲，通工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。

自动化测试的分类###

自动化测试分类.jpg

单元测试：自动化投入产出比最大，单元测试主要是由开发人员进行自测，现阶段国内做真正将单元测试自动化做起来的公司比较小。
集成/接口测试：介于单元测试和UI测试之间，投入产出比相对于单元测试要小，接口测试主要由测试人员进行，接口测试的变动相对于ui层来说就小的多了，也就减小了代码维护的难度，在自动化测试的工作中，测试人员的自动化重心应该放在接口测试层。
UI测试：投入产出比最小的层，UI的自动化测试在前段时间非常火，如果想要实现全面的UI自动化基本不可能，维护成本太大，版本迭代如此迅速的今天，界面元素说变就变，更是加大了ui自动化的难度，在实际工作中，ui自动化所覆盖的用例基本都是项目的核心业务，用于每次提测之后的冒烟测试。

哪些项目适合做自动化测试？###

1. 需求变动小
2. 项目时间长
3. 自动化测试脚本可以重复使用

自动化测试的学习方向？###

首先，我们说说UI自动化测试是否有必要的问题，文章的前面也简述了UI自动化的弊端（维护成本太高，产出比小），既然UI自动化的维护成本如此之高，那么我们就不用做UI自动化测试了？错，所有前辈们流程的东西肯定是有其原因的，我们可以去其糟粕，只实现项目中重要功能的UI自动化，用于在每次提测之后的第一项测试，如果新加或者是新修改的功能都影响了项目的核心功能，那么直接将提测的项目打回到开发手里，这样可以节约时间，提高效率。

在实际的工作中，我们在UI自动化的项目上尽量合理的投入，不但可以提高效率，而且有利于质量保证。

移动互联网盛行的时代，我们需要的是产品快速迭代上线，在这样的大环境下，更需要有接口测试的保障，而相对于UI自动化，接口测试相对于难度不是那么大，维护成本也低，毕竟，哪个公司一天没事就在捣腾自己的接口，除非想死。

之前看过老徐的一篇文章《预测2017软件测试职业整体发展趋势》，原文是这样的

1. 接口自动化测试，会明显的爆发（想要快速迭代上线，必须有接口自动化作为保障）

2. UI自动化测试，比重会逐渐降低（会有更多的专项自动化，或者云平台来支撑，以及第三方测试服务支撑）

更多有料的文章，大家可以关注“简尚”公众号，总会有惊喜在你身边。

有了前辈（老徐）的指导，你有方向了么？

后记：
感谢老徐提供的百人计划的平台，给我方向，同时感谢黄河的无私分享。

如果大家喜欢我的文章，请点赞，如果大家还想听下回分解，请关注我。