持续测试破解自动化测试的行业谜题

谁说自动化测试发现不了 BUG？

每一个质量保障团队对自动化的投入都会面领着管理者价值拷问，例如自动化测试发现了多少 BUG，自动化测试能不能发现 BUG 等一系列的问题。虽然任何一个内行人都知道自动化测试是必不可少的环节，但是却又很难回答如上的一些问题。

自动化测试的行业谜题

自动化测试主要是将一些手动测试任务通过测试脚本的形式留存下来，然后通过测试脚本回放的方式来完成回归测试部分的工作，那么在很多团队中的自动化测试如下图所示方式运行的。

在每次项目提测后，手工测试工程师先按照提交测试的系统以及需求撰写测试用例，下一步就是完成测试，当测试通过后测试开发工程师再按照业务测试用例编写测试脚本。这个过程中，自动化测试最重要的就是在回归测试的时候能够快速回放，节省回归测试成本。

换个角度来考虑这个问题，IEEE 610 对测试用例的定义指出，测试用例的三部分分别是测试数据、测试执行过程以及预期结果。再回到图中自动化测试的执行流程，我们不难看出，手工测试用例和自动化测试用例的除去技术实现不同以外，测试数据、测试执行过程以及预期结果都是一致的。因此手从测试用例已经完成了对应的业务逻辑验证，如果有 BUG 就已经发现了并修复了。这个时候无论是在此进行手工测试还是运行自动化测试，都不应该在发现 BUG 才是正确的，否则就只能证明之前的某个环节没有达到本应达到的效果。

如果仅仅用发现缺陷来衡量自动化测试的收益，那么回归测试中的自动化测试就很难实现可见收益，也就很难回答管理者的问题。

持续测试让自动化测试证明价值

持续测试其实就是一种新的测试实践，是在软件交付生命周期过程中，以防控业务风险为目的，将每一个业务交付阶段都辅以测试活动进行质量保障，并尽最大可能自动化，通过测试结果不断的反馈给制品过程的测试实践活动。持续测试是伴随持续集成、持续交付和持续部署而产生的。测试工程师在流水线交付的过程中，可以通过建立质量门禁来保障所交付系统的质量，并通过自动化来提升质量效能，从而实现研发效能的提升。

通过建立 DevOps 流水线上的质量门禁，从而实现质量卡点。在流水线上常用的质量门禁指标包含代码分析的技术债务、单元测试通过率和代码覆盖率、接口测试通过了和接口覆盖率，UI 自动化验收测试的主流程的覆盖率，E2E 测试的通过率。

这样，将自动化测试活动放到了手工测试之前，那么如果手工测试在测试自动化测试用例已经验证过的流程，手工测试也不会发现 BUG（不知道这个时候会不会有人来质疑手工测试阶段是否有必要存在？）。所以在持续测试中，并在 E2E 测试中还进行对应流程的验证，手工测试和自动化测试要实现相互弥补。E2E 测试更加提倡使用探索测试完成，这样在不同的阶段通过不同的质量保障活动保障最后的交付质量。