自动化测试的灵魂拷问二：自动化测试真的能提升软件质量吗？

质疑一：据统计即使自动化测试覆盖率比较高的产品，大部分的软件缺陷还是手工发现的，那么软件质量到底是由手工测试来保障的，还是自动化测试来保障的？

自动化测试并不容易，需要有效的指导，并不是所有的测试自动化项目都交付了预期的ROI和成功率，其中一个原因可能是没有使用正确的测试实践。许多测试人员没有意识到降低自动化测试有效性的标准程序。

以阿里某个部门一周的自动化测试数据为例，自动化失败次数不仅没有与发现bug数成正比，还浪费了测试人员41次自动化失败的排查时间，而这些时间对于做自动化查bug的初衷，都是无意义、不必要、也无技术含量之举。

阿里该部门这一周的自动化失败次数不仅没有与发现bug数成正比，还浪费了测试人员41次自动化失败的排查时间，而这些时间对于做自动化查bug的初衷，都是无意义、不必要、也无技术含量之举。


为什么外部环境、业务变更、应用环境问题、执行机问题、数据问题、框架问题这些都能引起这么多失败呢？而单单真正查出bug的概率这么低呢？

结合我们的多年自动化实践与总结，自动化存在如下图这些缺点：


 这还只是阿里某部门单周的一个采样，就已经浪费了41次排查时间，这样的自动化测试，若运行一年，那效果又会如何？能确保后面没有这些干扰的失败吗？失败次数可以和bug数成正比吗？



很多人由此得出结论自动化测试无法保证产品质量。

自动化测试是广义的，是分层的，不只是端对端的系统测试

 

单元测试应该是自动化测试的主力军，其实是接口测试，最后是端对端的UI测试。 

 

 质疑二：即使自动化测试承担了回归测试的任务，很多缺陷也是由手工测试发现的。团队里最好的bug hunter找出来的缺陷大多是依靠Free Test。那么，自动化测试在回归测试方面的有效性也不可信？

这个结论只有两个原因：

• 测试代码的覆盖率不高
• 而是测试脚本设计的不好 

要么是手工发现的bug，脚本没有覆盖，要么是脚本案例设计的逻辑不够好。 

质疑三：在开发前期软件的功能特性还不稳定的情况下，系统端到端的自动化测试开展不起来，以至于自动化测试只能在项目中后期才能运行起来，在提升软件质量方面作用不大？ 

如果等到软件稳定了再进行自动化测试，自然发挥不了太大作用。即使是系统端到端的测试，也是越早进行越好，要实现这一点可以参考我们在“ 彻底实现持续测试（中） ”中所讨论的“服务虚拟化”。另外，尽量采用接口自动化测试，少量采用UI自动化测试。尤其在项目初期，UI界面变更频繁，这时候开发UI自动化测试脚本更加得不偿失。 

质疑四：自动化测试覆盖率不足，除了接口测试自动化，许多基于UI的自动化测试的覆盖率偏低，达不到充分测试的标准。 

工具执行脚本又不会扩展，不会 举一反三、触类旁通，而人在执行测试用例时，会在执行过程中会主动弥补 用例覆盖面不足，多做额外的测试。 

只有做到自动化测试本身的高质量，自动化测试才能真正提升软件质量