一、什么是自动化测试？
自动化测试，顾名思义，自动完成测试工作。通过一些自动化测试工具或自己造轮子，实现模拟之前人工写的工作并验证其结果完成整个测试过程，这样的测试过程，便是自动化测试。把人对软件的测试行为转化为由机器执行测试行为的一种实践，对于最常见的自动化测试来讲，就是由自动化测试工具模拟之前需要人工在软件界面上的各种操作，并且自动验证其结果是否符合预期。自动化测试听上去很美好，感觉好像是第一次工业革命，它开创了以机器代替手工劳动的时代，其实它也有其自身的局限性。
自动化测试的本质是先写一段代码然后去测试另一段代码。所以每一个自动化测试的项目都是从手工测试做起的，如果没有手工测试的基础，是没法进行自动化测试。
二、为什么需要自动化测试？
2.1 自动化测试的优势
为了让你更好地理解自动化测试的价值，即为什么需要自动化测试，我先来跟你聊聊自动化测试通常有哪些优势：
- 自动化测试可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上；
- 自动化测试可以大幅提升回归测试的效率，非常适合敏捷开发过程；
- 自动化测试可以更好地利用无人值守时间，去更频繁地执行测试，特别适合现在非工作时间执行测试，工作时间分析失败用例的工作模式；
- 自动化测试可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试等；
- 自动化测试还可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽。
2.2 自动化测试的“坑”
而为了避免对自动化测试的过度依赖，你还需要了解自动化测试有哪些劣势，这将帮你绕过实际工作中的“坑”。
- 自动化测试并不能取代手工测试，它只能替代手工测试中执行频率高、机械化的重复步骤。你千万不要奢望所有的测试都自动化，否则一定会得不偿失。
- 自动测试远比手动测试脆弱，无法应对被测系统的变化，业界一直有句玩笑话“开发手一抖，自动化测试忙一宿”，这也从侧面反映了自动化测试用例的维护成本一直居高不下的事实。其根本原因在于自动化测试本身不具有任何“智能”，只是按部就班地执行事先定义好的测试步骤并验证测试结果。对于执行过程中出现的明显错误和意外事件，自动化测试没有任何处理能力。
- 自动化测试用例的开发工作量远大于单次的手工测试，所以只有当开发完成的测试用例的有效执行次数大于等于 5 次时，才能收回自动化测试的成本。
- 手工测试发现的缺陷数量通常比自动化测试要更多，并且自动化测试仅仅能发现回归测试范围的缺陷。
- 测试的效率很大程度上依赖自动化测试用例的设计以及实现质量，不稳定的自动化测试用例实现比没有自动化更糟糕。
- 实行自动化测试的初期，用例开发效率通常都很低，大量初期开发的用例通常会在整个自动化测试体系成熟，和测试工程师全面掌握测试工具后，需要重构。
- 业务测试专家和自动化测试专家通常是两批人，前者懂业务不懂自动化技术，后者懂自动化技术但不懂业务，只有二者紧密合作，才能高效开展自动化测试。
- 自动化测试开发人员必须具备一定的编程能力，这对传统的手工测试工程师会是一个挑战。
三、什么样的项目适合自动化测试？
第一：需求稳定，不会频繁变更
过高的需求变更频率会导致自动化测试用例的维护成本直线上升
第二：研发和维护周期长，需要频繁执行回归测试
软件产品比软件项目更适合做自动化测试：
-
- 首先，软件产品的生命周期比较长，会有持续性迭代，每次版本发布都会有回归测试需求
- 其次，自动化测试用例的执行比高于1:5，自动化测试的优势才可以被更好地体现
对软件项目的自动化测试，需要分情况：
-
- 短期项目：不建议实施自动化，就算技术可行性很高，但 投入产出比（ROI） 不高；应该选择 手工探索式测试 ，以发现缺陷为第一要务
- 中长期项目：对比较稳定的功能进行自动化测试，对改动较大or需求不明确的功能进行手工测试，最终目标是用20%的精力去覆盖80%的回归测试
第三：需要在多平台上重复运行相同测试的场景
这样的场景其实有很多，比如：
- 对于 GUI 测试，同样的测试用例需要在多种不同的浏览器上执行；
- 对于移动端应用测试，同样的测试用例需要在多个不同的 Android 或者 iOS 版本上执行，或者是同样的测试需要在大量不同的移动终端上执行；
- 对于一些企业级软件，如果对于不同的客户有不同的定制版本，各个定制版本的主体功能绝大多数是一致的，可能只有个别功能有轻微差别，测试也是需要覆盖每个定制版本的所有测试；
- ……
这些都是自动化测试的最佳应用场景，因为单个测试用例都需要被反复执行多次，能够使自动化测试的投资回报率最大化。
第四：某些测试项目通过手工测试无法实现，或者手工成本太高
对于所有的性能和压力测试，很难通过手工方式实现，如：
-
- 一万并发用户的基准性能测试
- 7*24小时的稳定性测试
这个时候必须借助机器来模拟大量用户反复操作被测软件的场景
第五：被测软件的开发较为规范，能够保证系统的可靠性
要实现稳定的自动化测试，被测软件的开发过程必须规范，比如：GUI上的控件命名如果没有任何规则可寻，就会造成GUI自动化的控件识别与定位不稳定，影响效率
另外，某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化会很难开展。
比如，用户登录操作可能需要图片验证码，需要开发提供绕开图片验证码的路径，否则需要自己借助 光学字符识别（OCR）技术 来对图片验证码识别，但它的识别率会很低，直接影响用例的稳定性
第六，测试人员已经具备一定的编程能力
如果测试团队的成员没有任何开发编程的基础，那你想要推行自动化测试就会有比较大的阻力。这个阻力会来自于两个方面：
-
- 前期的学习成本通常会比较大，很难在短期内对实际项目产生实质性的帮助，此时如果管理层对自动化测试没有正确的预期，很可能会叫停自动化测试；
- 测试工程师通常会非常热衷于学习使用自动化测试技术，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这将直接降低软件整体的质量。
