又要聊到自动化了，感觉现在不管是主动或者被动，“自动化”已经是我们测试人员避不开的话题了。
主动，你觉得需要做一些测试提效，于是你去学习了解，并在工作中应用。
被动，或许你想换份工作了。当你打开各公司的招聘JD，又会看到“自动化”，还是得去学习了解。
一、什么是自动化测试
我的理解是：能代替我们手工测试的行为。
比如常见的Web自动化和接口自动化，就是代替我们人工去执行页面操作和接口的操作，并且还要可以验证结果是否符合预期。
二、为什么要做自动化测试
自动化近几年之所以大受追捧（趋之若鹜），肯定还是有它的优势的：
- 可以替代大量重复性工作，测试人员可以有更多时间投入到新功能、或者更全面的用例设计上。
- 可以大幅提高回归测试效率，非常适合敏捷开发过程。
- 可以更好地利用无人值守时间，去更频繁地执行测试，特别适合现在非工作时间执行测试，工作时间分析失败用例的工作模式。
- 可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试等。
- 还可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽。
缺点？那必须存在：
- 自动化测试并不能取代手工测试，它只能替代手工测试中执行频率高、机械化的重复步骤，起到互补。
- 自动化也不智能，只会按照代码里我们既定好的步骤去执行，中间发生任何意外，没有任何处理能力。
- 自动化测试用例的开发工作量远大于单次的手工测试，所以只有当开发完成的测试用例的有效执行次数大于等于 5 次时，才能收回自动化测试的成本。
- 自动化测试发现的bug通常会很少，主要职责就是用来回归。
- 测试的效率很大程度上依赖自动化测试用例的设计以及实现质量，不稳定的自动化测试还不如不要。
- 实行自动化测试的初期，用例开发效率通常都很低。
- 自动化测试开发人员必须具备一定的编程能力，这对传统的手工测试工程师会是一个挑战，需要额外学习成本。
所以，对于自动化测试，不能一概而论，不管三七二十一就上，具体还是看你的项目是否适合。
三、什么项目适合做自动化测试
1. 需求稳定，不会频繁变更
如果需求频繁变，那么对应你的自动化维护成本也会直线上升。你想想，刚调试完的case，结果页面或者接口逻辑变了，又得重调了。
2. 研发和维护周期长，需要频繁执行回归测试
这里说的是软件产品，比如微信app、淘宝web系统。软件产品的生命周期一般都比较长，通常会有多个版本陆续发布，每次版本发布都会有大量的回归测试需求。
而对于项目软件（比如给XX公司开发一套系统，2个月后交付实施），就要视情况而定了。
通常来看，短期的一次性项目并不适合做自动化测试，ROI（投入产出比）不高，以手工探索测试更合适。
对于一些中长期项目，可以这样：
- 对比较稳定的软件功能进行自动化测试，
- 对变动较大或者需求暂时不明确的功能进行手工测试，
最终目标，是用 20% 的精力去覆盖 80% 的回归测试。
3. 需要在多种平台上重复运行相同测试的场景
这种其实就比较常见了，比如web端的多浏览器执行、app端的多系统版本或者多机型测试等等。
这些项目中的单个测试用例都需要被反复执行多次，能够使自动化测试的投资回报率最大化。
4. 某些测试项目通过手工测试无法实现，或者手工成本太高
通常为性能和压力测试。
比如，某一个项目要求进行一万并发用户的基准性能测试，难道你真的要找一万个用户按照你的口令来操作被测软件吗？又比如，对于 7×24 小时的稳定性测试，难道你也要找一批用户没日没夜地操作被测软件吗？
这时候必须借助自动化测试技术了，用机器来模拟。
5. 测试人员已经具备一定的编程能力
如果测试团队的成员没有任何开发编程的基础，推行自动化测试就会比较困难：
- 短期收益：前期的学习成本通常会比较大，很难在短期内对实际项目产生实质性的帮助。此时如果管理层对自动化测试没有正确的预期，很可能会叫停自动化测试。
- 本末倒置：如果测试人员不能正确地看待自动化测试，很可能会花大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这很致命。
所以，要综合实际情况来看待“自动化测试”。它的确可以从一定程度上解放测试人员的劳动力，完成一些人工无法实现的测试，但并不适用于所有的测试场景。
如果，维护自动化测试的代价高过了节省的测试成本，往往会得不偿失。
