如何汇报自动化测试的成果

星球里有同学问了这样一个问题：自动化测试开展了一段时间，现在需要给领导汇报成果，该怎么汇报？表面看起来这是一个技术问题，实际上这是一个向上管理问题。

那么该如何向领导汇报自动化测试创造的成果呢？我们不妨从它的源头出发，思考这几个问题：

• 为什么做自动化测试？

• 预期的目标和结果是什么？

• 过程中解决了哪些问题和痛点？

想清楚做自动化测试的原因，能明确做自动化测试的预期目标和评估标准，解决了团队面临的实际问题，且最终的成果没有偏离预期目标，也拿到了预期甚至超过预期的结果，那就是好的成果。

首先，为什么要做自动化测试？这个问题相信各位技术同学特别是测试同学心里都很清楚：将人力从重复性工作中解放出来，提高单位的人效比。

一般来说一个长期迭代的项目，核心业务流程和关键分支，整体不会有太大的变化，如果每次版本迭代或更新都去手动执行相关的测试用例，从性价比来说肯定是不高的。因此采用自动化执行的方式，将这些测试用例转化为机器执行，既可以提升测试用例的执行效率，也可以释放测试同学的精力在更重要的事情上面，一举两得。

至于是选择 UI 自动化测试还是接口自动化测试抑或单元自动化测试，就是具体问题具体分析的范畴。

其次，自动化测试好歹是一个软件工程实践，在落地之前肯定要明确预期的目标和度量评估标准，以便于在落地执行过程中不偏离目标，可以有效掌握工程整体的进度和实施效果。

预期目标其实很简单，提升效率，怎么算提升效率呢？要选择一个对比对象，比如相比于做自动化测试之前，测试用例执行耗时缩小了多少。以一周一个版本迭代为例，大体的研发测试节奏如下图所示：

其中测试验证(执行用例)大约占整个测试过程的 50%时间，且每个版本除了执行新增的测试用例，原有的主流程和核心分支用测试用占比也不小。以我的经验来说，功能测试一般一天验证 120 条左右的测试用例，强度就已经不低了。如果能将重复性的测试用例用机器执行，在一个版本迭代中，测试就可以节省几个小时的执行用例时间，将精力放在用例设计、风险评估、工具开发和基础设施优化方面。

当然，自动化测试落地实施自然不可能这么简单，要编写和维护脚本，要解决测试数据有效性和测试环境稳定性等方面的问题，这是第三个问题要回答的内容。

第三个问题：自动化测试实施过程中解决了哪些问题和痛点？这个问题不仅是很现实的工程实践要解决的问题，也是高频的面试题。在自动化测试落地实践过程中，一般要重点解决这几个问题：

• 测试数据维护管理：用 Excel、配置文件还是数据库？造测试数据的能力能否为研发联调和自测赋能？

• 测试环境的稳定性：环境的稳定性极大的影响整体的测试效率和测试结果的准确性，但这是长期基础设施建设范畴。

• 测试用例精准匹配：随着业务的不断迭代，测试用例沉淀了一大堆，但也会有失效的，可以通过测试用例集来解决。

解决了这些问题，才算是自动化测试真的落地实践，达到了预期目标并拿到了好的结果。

最后，回到最初的问题，该如何向领导汇报。

首先要明白的一点是，给领导汇报的内容，最终会由领导向更高层汇报，因此抓住重点内容，适度包装很重要。其次自动化测试的内核还是提升效率，需要找到对比对象并且有明确的数据支撑成果。最后，落地过程中解决了哪些影响效率和质量的问题，是否能为团队发展提供赋能也是需要考量的因素。

如果是我来做自动化测试成果的汇报，我会从这几个维度来介绍：

1、相比于实施自动化测试之前，实施后的测试执行效率提升了 X%；

2、测试用例有效覆盖了 P0/P1/P2 场景占 X%，每版本人效提升了 X%；

3、落地过程中识别了 N 个潜在风险，解决了 X 个影响质量和效率的问题；

4、实践过程采用了新技术，提升了环境稳定性，为后续 X 项目积累了经验；

5、预期结果是 X，在 1-2-3 阶段各自达成的效果是 Y，符合或者超过预期 N%；

6、后续打算从 XYN 不同角度去优化，解决 X 问题，扩大覆盖范围，为 D 团队赋能；

其中 1 和 2 代表了提升效率，3 和 4 代表了风险预防和技术视野以及技术体系建设，5 是汇报给领导的成果和结论，6 是未来规划和赋能协作。