自动化测试是提升测试效率的有效手段，但是实践过程中，常常听到一些测试同学抱怨说自动化测试并没有发挥应有的价值，有时候甚至沦为绩效考核的工具。比如：

        ● 编写了大量的自动化测试用例，却只有少量的可以正常运行；

        ● 每天都会定时执行自动化测试的回归任务，却很少发现Bug；

        ● 有时候自动化测试的考核指标成为测试人员的负担；

        ● 开发了自动化测试平台，用户使用的频率并不太高；

        之所以会出现以上情况，是因为我们并没有进行有效的自动化测试。那什么是有效的自动化测试呢？我们应该从哪些维度来衡量自动化测试的有效性呢？笔者根据一些实际的经验结合理论的度量指标来和大家一起分析和探讨一下。

常用的自动化测试度量指标

        在实际工作中有些同学常常会用到下面这些指标来对自动化测试进行度量：

自动化测试用例数量

        自动化测试用例数量是不是越多越好呢？并不一定。衡量自动化测试用例的产量有点类似于衡量一个应用的代码数量，并不是数量越多就越好。由于这是一个很简单明了又方便计算的指标，常常被大家广泛使用，但是一味追求数量，可能会造成产生大量无效的自动化测试用例这样的结果。因此建议不要单独使用该指标来度量自动化测试，而是需要结合其他数据来计算自动化测试执行效率和有效自动化测试用例比率等指标，从而来衡量自动化测试系统自身的成熟和完备程度。

自动化测试执行用例次数

        和自动化测试用例数量一样，执行次数也并不是越多越好。该指标适合用来衡量和展示自动化测试系统或平台自身的能力，而并不能很好的体现其产生的实际价值。

自动化测试执行成功率

        自动化测试执行成功率，一般会在单次自动化回归测试的报告中展示，有时候在流水线中设置成功率的阈值，比如低于某个阈值x%的时候，视为自动化回归测试不通过。该指标是个很好的过程指标，但并不适合作为常规度量自动化测试价值的指标。

自动化测试覆盖率

        自动化测试覆盖率的高低，和被测系统的变更结合起来，能够很好反馈系统所存在的质量风险。自动化测试覆盖率，有测试用例覆盖率、功能覆盖率、接口覆盖率和代码覆盖率等等。如果自动化测试能够有很高的覆盖率，也能够帮助团队成员对系统和产品建立信心。只是目前很多团队的覆盖率数据统计维度比较单一，而且也不太准确，比如有些团队是通过人工统计的方式来计算了测试用例覆盖率，但是并未考虑到测试用例本身就未覆盖完全的情况。这种情况下，有可能虽然系统具备了较高的测试覆盖率，但是仍然会有缺陷遗漏的风险。

自动化测试的目的

        既然以上的指标并不能够完全体现自动化测试的价值，那么我们应该如何做呢？我们回归自动化测试的价值本身，首先自动化测试目前阶段并不能完全替代手工测试，而其目的是为了替代一些需要重复执行的手工测试和执行一些手工无法执行的复杂而且容易出错的测试等等。如下图：

        图片 图1-自动化测试vs手工测试

        从上图可以看出，自动化测试在现阶段并不能完全替代手工测试，而能够替代一部分的手工测试，从而实现测试效率的提升；还能够作为手工测试的补充，实现一些手工无法完成的测试任务，来帮助产品提升质量。

        那自动化测试的目的是发现更多的Bug吗？有很多人会使用“发现Bug数量”作为自动化测试是否成功的一个衡量标准。自动化测试目前在回归测试阶段应用比较多，而在回归测试阶段发现的Bug数量一般是比较少的，其根本目的是为了避免手工执行的回归测试不充分而导致缺陷遗漏，才会通过自动化的手段来代替手工的回归测试。在文章的后面会谈到，自动化测试发现的Bug数量可以用来衡量自动化测试用例自身的有效性，从而确保自动化测试用例编写人员能够及时更新用例。

进行合理的自动化测试度量

1.EMTE（Equivalent Manual Test Effort）

        文章前面提到，并不适合通过自动化测试用例数量或者执行次数等指标来衡量其价值。而笔者比较认同由Dorothy Graham提出的EMTE（Equivalent Manual Test Effort）公式，能够一定程度上代表自动化测试起到的作用，其说明如下：

        ● 度量对象为一个自动化测试集合；

        ● 计算这个自动化的测试集合如果完全手工执行需要的工作量（时间）； 

        举例说明，比如“自动化测试集合1”，如果手工执行需要3个小时，而在当前敏捷迭代中该自动化测试集合执行了2次，这时候EMTE=3*2=6(小时)。 

        当然，任何指标的滥用都会产生一定的负面价值，如果为了追求单纯的高EMTE而不断重复执行相同的自动化测试用例，也是不合适的

2.ROI（投入产出比）

        进一步来看，EMTE只是计算了收益，并没有计算自动化测试的投入，那么通过计算ROI（投入产出比）来衡量收益更加合适些。从下图，我们可以看到自动化测试的时间投入，也会包含脚本编写、测试准备、测试执行、失败原因分析和环境恢复/数据清理等事项。

        计算自动化测试的ROI，需要首先计算出节省的时间：（自动化测试节省时间=EMTE—手工测试需要的时间）。然后再进一步汇总计算自动化测试投入的总时间，也就是各个阶段需要的时间总和，最终计算出

        ROI：ROI=（自动化测试节省的时间——自动化测试投入总时间）/自动化测试投入总时间。

3.自动化测试用例发现Bug效率

        前面文章也提到，单纯使用自动化测试发现的Bug数量来衡量其价值是不合适的。但是可以作为对自动化测试用例自身的有效性约束还是有些作用的。其公式为：自动化测试用例发现Bug效率= （自动化测试发现的Bug数量/自动化测试用例执行数量）*100%。 该指标的数据不会很高，可以通过趋势跟踪的方式来确保自动化测试用例能够及时更新，并且一定程度上约束无效的执行。

4.自动化测试覆盖比率

        自动化测试覆盖率结合手工测试的覆盖率，综合计算才能够反馈出基于需求变更的测试覆盖率程度。而单纯衡量自动化测试的覆盖率，更多的是代表自动化测试系统自身的成熟度。建议采用多维度的覆盖率计算，包含自动化测试功能覆盖率、自动化测试接口覆盖率和自动化测试代码覆盖率。通过计算自动化测试覆盖率比例的方式来衡量自动化测试的贡献情况：

        自动化测试覆盖比率 = 自动化测试覆盖率/ (自动化测试覆盖率+手工测试覆盖率)*100%

5.与研发效能的结果指标建立关联

        相信大家都认可，过分注重过程指标的度量，是不合时宜的。自动化测试的价值评估和度量需要尽量与研发效能的结果指标建立关联。例如自动化测试的EMTE和ROI两个指标，可以和衡量研发效能交付能力的“发布前置时间”相关联，观察经过一段时间的自动化测试能力提升，是否可以不断减少“发布前置时间”，从而实现交付能力的提升。而自动化测试用例发现Bug效率和自动化测试覆盖比率的提升，一定程度上应该可以影响到交付质量中的线上缺陷密度指标，通过更高的自动化测试覆盖率和更全面的自动化回归测试，减少遗留到线上的缺陷。从度量的角度，如果发现自动化测试的指标无法对结果指标产生影响，那很可能是数据统计出了问题，或者指标需要调整。

6.总结

        该选择三四个适合自己系统的度量指标，对自动化测试产生的价值和自动化测试系统本身进行持续的评估。而我们常常会为了容易实现，而选择单个维度的简单指标来进行度量的方式，是不可取的。过分追求单个指标的数据，会造成一定程度的偏差，而选择多个互相制约的指标进行度量，才能够更加全面评估自动化测试的价值和有效性。而选择度量指标仅仅是个开始，如何科学有效的获取准确的指标数据，才是真正挑战的开始，单纯依靠手工统计的方式肯定是不行的。需要在开始构建自动化测试系统时，就着手开始考虑了。

引用:

        1.https://www.slideshare.net/TechWellPresentations/tc-graham

        2.https://blog.testproject.io/2019/12/04/how-to-measure-the-value-of-your-test-automation/

作者介绍

熊志男 京东科技数字化效能部 

        目前在行云DevOps平台的产品团队， 2014年加入京东，在研发效能工具开发和工程实践的落地方面都有丰富的经验。参与并主要推动的持续集成和代码扫描实践 从20人左右的小团队做起，逐步扩展到百人团队，主要参与建设的代码质量平台也从团队内部的工具，逐步发展成为公司级的 上千人使用的工具平台。掌握持续集成流程中的单元测试、代码审查、自动部署和自动化测试各个阶段的工具方案和实现原 理，并了解研发团队的实际痛点，有丰富的实际落地经验。是《京东系统质量保障技术实战》作者之一，翻译《Selenium自动化 测试—基于Python语言》一书。