追求一些错误的目标,会使自动化测试走向失败。
1)替代手工测试
自动化无法替代手工测试,只能作为辅助手段,在如图的第二象限起作用,

2)高比率的UI测试覆盖率
不是覆盖率越高越好,由测试金字塔来看,底端占比越高,自动化效率越好。

3、发现大多数bug
UI测试的特性决定了它只能用于已有功能的回归/冒烟测试,它根本无法发现大多数Bug。自动化测试更多的作用是让测试工程师从重复的回归测试中解放出来,进行测试方法和测试策略的研究,以便在人工测试中发现更多的Bug。
4.缩短新功能(或一次性交付型项目)的测试时间
自动化测试的收益与有效运行次数成正比,首次实施自动化的成本是比较高的,无法缩短新功能测试时间。
5.让各个项目的自动化测试通过率大于N %
不存在通过率大就通过的情况,只要出现问题,就要去排查原因。
能保证成功的核心目标为验证最重要的已有核心流程的正确性,保证最核心的功能正确。
基于核心目标制定目标,如:
1、在开发人员每次提交代码后,自动触发回归测试,快速地向开发团队提供质量反馈。
将UI自动化测试加入持续集成过程中,在代码提交后自动触发自动化回归测试,快速地给予开发团队质量反馈,如有问题可以及时调整代码。全部UI自动化测试的时间尽量控制在10分钟以内,最长不要超过15分钟。
2、实现监控性的验证,例如将子目标定义为定期监控在线产品的运行状态。
自动化用例也需要测试设计,选取哪些用例,每个用例的步骤,预期结果都要合理。比如,对于登录流程,自动化测试的时候,如何去验证已经登录成功?是首页看到了账户名,还是把cookie写入了浏览器,这些都是需要设计的。
自动化测试的收益 = 有效运行次数×全手动执行成本 −首次实施自动化成本− 长期维护成本
对于必须要执行的手动测试,由自动化来代替执行”的次数,才能真正算是“有效运行次数”
成本不仅要计算首次实施成本,还要考虑长期维护成本。

自动化测试并非一件一劳永逸的事情,而是需要长期去优化改良的事情

已有的自动化测试用例有自己的生命周期,可能因为造成亏损被淘汰。而有些效益不够明显的用例可以进行重构改良,排入下一轮的计划当中。而对于之前尚未实施自动化的测试用例或其他测试执行方面的任务,如果有必要,也可以将其安排到下一轮的自动化测试计划中