聊聊自动化测试的度量指标

本文是自动化测试系列的第四篇文章，这篇文章我想聊聊对自动化测试度量的一些想法。

上周末在知识星球社群的内部分享中，也有同学问了这个问题：自动化测试度量指标有哪些？各有什么价值？

脱离数据支撑谈价值多少有点底气不足，但脱离自动化的初衷和背景谈度量指标，就有些南辕北辙了。

 

做自动化测试的目的

在聊自动化测试度量指标前，有必要回到做自动化的初衷上，就是为什么要做自动化测试，要解决什么问题。

在不同公司，对不同的团队和技术同学来讲，做自动化的目的各有不同。常见的目的有下面几点：

1. 测试数据准备耗时长，为了提升造数据的效率而做自动化测试；
2. 项目上线之前的核心业务链路回归，为了提升回归测试效率，这也是一种上线前的check手段；
3. 提测前为了快速验证提测质量，作为一种冒烟测试手段提升效率，同时这也是一种测试左移的实践；
4. 团队大业务线多，通过统一框架和协作规范来提升测试团队协作效率，减少造轮子，避免资源内耗浪费；

当然还有其他目的，总结一下，做自动化测试的目的主要是降本增效。即通过技术手段，提升测试过程效率和团队协作效率，新增测试回归验证手段，降低重复性工作投入成本。

 

基于目的制定度量指标

如上文所述，关于自动化测试的度量指标，我个人的观点是基于实际的目的出发来制定度量指标。举例：

自动化测试目的	细分类型	度量指标	如何度量
效率	造数据效率	每周造数条数 平均造数耗时 造数任务调用量	和手动造数耗时对比
	冒烟测试效率	冒烟执行耗时	和手动冒烟测试耗时对比
	线上回归效率	回归执行耗时	和手动回归测试耗时对比
覆盖率	接口覆盖率	P0/P1接口覆盖率 总体接口覆盖率	梳理核心接口，投入最多资源精力
	用例覆盖率	P0case覆盖率 P1case覆盖率	梳理核心case，投入最多资源精力
	业务场景覆盖率	正向场景覆盖率 逆向场景覆盖率 核心场景覆盖率	根据业务场景，case by case度量
过程质量	构建执行成功率	自动化任务执行成功率	低于某个阈值判定脚本质量不通过
	用例执行通过率	自动化case执行成功率	低于某个阈值判定提测质量不通过

 

制定度量指标要注意的

制定度量指标时，建议遵循和考量如下几点：

1. 切忌面向指标/面向KPI做度量；
2. 考虑到冗余成本，指标不宜过多；
3. 制定指标是为了提升质量，而非做数据；
4. 根据做自动化测试的目的来制定度量指标；
5. 度量指标对比应该以是否解决了痛点为依据；
6. 度量指标是辅助评估依据，并不是唯一正确的结果；
7. 制定指标应考虑到哪些指标更实际有效，从解决问题角度出发；
8. 度量指标不要单一的评估，应结合多个维度来综合评估开展质量度量；