为什么需要自动化测试？
- 代替手工重复操作，测试工程师可以花更多时间在设计全面的测试用例和新功能测试上 【代替手工重复】
- 提升回归测试的效率，适合敏捷开发过程 【提升回归效率】
- 更好的利用非工作时间执行测试，工作时间分析失败用例 【利用非工作时间测试】
- 高效实现某些手工测试无法完成或代价巨大的测试类型，比如：关键业务7*24小时持续运行的系统稳定性测试和高并发场景的压力测试 【代替复杂手工测试和长时间测试】
- 还可以保证每次测试执行的步骤以及验证的一致性和可重复性，避免人为的遗漏或疏忽 【保证操作一致性，结果可溯源】
自动化测试的一些劣势
- 不能完全取代手工测试，只能替代手工测试中执行频率高、机械化的重复步骤 【不能替代手工测试】
- 无法应对被测系统的变化，自动化测试用例的维护成本高；因为自动化测试只是执行事先定义好的测试步骤并验证测试结果，对于执行过程中出现的明显错误和意外事件，自动化测试没有任何处理能力 【维护成本高，无法应对系统变化和紧急事件】
- 自动化测试用例的开发工作量远大于单词的手工测试，所以只有当开发完成的测试用例的有效执行次数≥5时，才能收回成本 【用例开发量大，投入产出比难以提高】
- 手工测试发现的缺陷数量更多，自动化测试仅仅能发现回归测试范围的缺陷 【只能发现回归缺陷】
- 自动化测试的效率很大程度依赖自动化测试用例的设计以及实现质量，不稳定的自动化测试用例比没有自动化更糟糕 【自动化测试用例强依赖开发质量】
- 实行自动化测试的初期，用例开发效率都很低，在体系成熟以及测试工程师熟练后一般都要重构初期用例 【后期需要重构不成熟的初期用例】
- 懂业务的人+懂自动化技术的人结合一起才能高效开展自动化测试 【不仅懂技术还得懂业务】
- 自动化测试开发人员必须具备编程能力 【必备编程】
什么样的项目适合自动化测试？
第一：需求稳定，不会频繁变更
过高的需求变更频率会导致自动化测试用例的维护成本直线上升
第二：研发和维护周期长，需要频繁执行回归测试
软件产品比软件项目更适合做自动化测试
- 首先，软件产品的生命周期比较长，会有持续性迭代，每次版本发布都会有回归测试需求
- 其次，自动化测试用例的执行比高于1:5，自动化测试的优势才可以被更好地体现
对软件项目的自动化测试，需要分情况
- 短期项目：不建议实施自动化，就算技术可行性很高，但 投入产出比（ROI） 不高；应该选择 手工探索式测试 ，以发现缺陷为第一要务
- 中长期项目：对比较稳定的功能进行自动化测试，对改动较大or需求不明确的功能进行手工测试，最终目标是用20%的精力去覆盖80%的回归测试
第三：需要在多平台上重复运行相同测试的场景
第四：某些测试项目通过手工测试无法实现，或者手工成本太高
对于所有的性能和压力测试，很难通过手工方式实现，如：
- 一万并发用户的基准性能测试
- 7*24小时的稳定性测试
这个时候必须借助机器来模拟大量用户反复操作被测软件的场景
第五：被测软件的开发较为规范，能够保证系统的可靠性
要实现稳定的自动化测试，被测软件的开发过程必须规范，比如：GUI上的控件命名如果没有任何规则可寻，就会造成GUI自动化的控件识别与定位不稳定，影响效率
另外，某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化会很难开展。
比如，用户登录操作可能需要图片验证码，需要开发提供绕开图片验证码的路径，否则需要自己借助 光学字符识别（OCR）技术 来对图片验证码识别，但它的识别率会很低，直接影响用例的稳定性