深入理解软件测试中自动化测试

什么是自动化测试

编写代码（脚本），也就是把手工测试用例的操作步骤和校验转化成脚本实现，然后批量执行代码（脚本）实现测试的目的， 就是自动化测试

从自动化测试的概念推导出，自动化测试用例编写的根据是我们的手工测试用例

自动化测试的分类

接口自动化测试， web UI自动化测试， app 自动化测试， 性能自动化测试等

为什么要做自动化测试

优点：

1、把人从重复的测试活动中解放出来（比如在迭代1版本实现了测试点A的自动化脚本， 在迭代2 ，迭代3 迭代N的版本中都可以使用自动化脚本覆盖这个测试点，把人解放出来），让人多手工测试哪些自动化不能覆盖的点，提升测试质量

2、主要用于回归测试(回归之前迭代做的功能)，缩短回归时间，提升测试效率

怎么理解自动化测试主要用于回归测试：

1、比如在A迭代实现了设备管理员模块， A迭代的测试完成后间歇期写设备管理员模块的自动化脚本

2、B迭代测试的时候， 可能还需要测试设备管理员模块，这个时候可以用自动化脚本去覆盖， 可以缩短测试周期，提升测试覆盖度， 保证质量

3、对于web系统，平均的话每个人每天大概可以执行70个左右的测试用例， 那1000个测试用例需要， 14人天左右才能执行完， 但是如果把这1000个测试用例转化成自动化脚本，那么可能就仅仅需要10-20个小时就测试完成，然后加上半天左右的结果分析， 就把1000个测试点给测试完成了

缺点：

1、自动化测试的脚本需要达到一定的数量才能见到测试效果，但是前期需要搭建自动化框架，所以自动化测试有前期投入大，后期收益高的特点， 这个特点也说明自动化测试适合长期迭代的软件，不适合项目型的软件。

2、UI自动化测试发现问题的效率没有人手工执行发现问题的效率高，毕竟ui自动化测试用例的测试点有限， 所以在做测试的时候，测试点第一次测试的时候最好是手工去覆盖， 后面回归的时候可以用自动化脚本覆盖

3、ui自动化脚本执行比较慢， 不是特别稳定，需要比较多的等待时间， 一般情况下一个UI自动化脚本执行时间是20秒-45秒， 1000个自动化测试用例， 如果一个机器执行，时间需要5-10个小时， 这个时候可能就需要分布到多个机器跑，比如说分布到3个机器， 那么只需要2-3个小时就可以出结果。

自动化测试的误区

1.自动化测试会完全取代手工测试

2.自动化测试一定比手工测试牛X，更加高达上

3.自动化可以发掘更多BUG（ui自动化测试发现bug占总bug 的比例可能在5% ）， 自动化更多的时候是保障系统功能没有问题

4.所有用例都适合自动化， 和硬件相关的，和第三方系统相关的功能， 很多时候这些功能我们要通过手工测试去覆盖

5.并非所有的项目都适合自动化测试

什么项目适合自动化测试

①需求稳定，不会频繁变更

自动化测试最大的挑战就是需求的变化，而自动化脚本本身就需要修改、扩展、debug，去适应新的功能，如果投入产出比太低，那么自动化测试也失去了其价值和意义；

折中的做法是选择相对稳定的模块和功能进行自动化测试，变动较大、需求变更较频繁的部分用手工测试；

②多平台运行，组合遍历型、大量的重复任务

测试数据、测试用例、自动化脚本的重用性和移植性较强，降低成本，提高效率和价值；

③软件维护周期长，有生命力

自动化测试的需求稳定性要求、自动化框架的设计、脚本开发与调试均需要时间，这其实也是一个软件开发过程，如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试也就不需要了；

自动化测试的工具

Web自动化测试工具：selenium(web强烈推荐）

接口自动化测试工具：SoapUI、postman，jmeter，也可以通过python/java等语言。

手机自动化测试工具：appium、robotium。

编写自动化脚本的人和时间

一个项目中的自动化框架一般有专人（这个人可能就不做手工测试啦）维护，编写自动化脚本可能是全员

全员编写自动化脚本的时间是迭代的间歇期， 专人是维护完框架一直写

执行自动化的时间、人、流程

时间：迭代的每个轮次转测试后

人：专人负责，一般和项目自动化框架专人是同一人

流程：批量执行自动化脚本，分析自动化结果， 发自动化测试报告（相关产品，研发，测试）

挑选哪些测试用例编写自动化脚本

从自动化测试的概念推导出，自动化测试用例编写的根据是我们的手工测试用例

从这几个维度来挑选，1、功能重要性 2、实现难度

功能重要的， 实现容易的肯定优先实现， 如果功能重要的都不好实现，那么先从功能次重要的，容易实现的开始