什么是自动化测试?

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

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

　　自动化测试的分类

　　接口自动化测试，webUI自动化测试，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、实现难度

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