本文是自动化测试系列的第四篇文章，这篇文章我想聊聊对自动化测试度量的一些想法。
上周末在知识星球社群的内部分享中，也有同学问了这个问题：自动化测试度量指标有哪些？各有什么价值？
脱离数据支撑谈价值多少有点底气不足，但脱离自动化的初衷和背景谈度量指标，就有些南辕北辙了。
做自动化测试的目的
在聊自动化测试度量指标前，有必要回到做自动化的初衷上，就是为什么要做自动化测试，要解决什么问题。
在不同公司，对不同的团队和技术同学来讲，做自动化的目的各有不同。常见的目的有下面几点：
- 测试数据准备耗时长，为了提升造数据的效率而做自动化测试；
- 项目上线之前的核心业务链路回归，为了提升回归测试效率，这也是一种上线前的check手段；
- 提测前为了快速验证提测质量，作为一种冒烟测试手段提升效率，同时这也是一种测试左移的实践；
- 团队大业务线多，通过统一框架和协作规范来提升测试团队协作效率，减少造轮子，避免资源内耗浪费；
当然还有其他目的，总结一下，做自动化测试的目的主要是降本增效。即通过技术手段，提升测试过程效率和团队协作效率，新增测试回归验证手段，降低重复性工作投入成本。
基于目的制定度量指标
如上文所述，关于自动化测试的度量指标，我个人的观点是基于实际的目的出发来制定度量指标。举例：
|
自动化测试目的 |
细分类型 |
度量指标 |
如何度量 |
|
效率 |
造数据效率 |
|
和手动造数耗时对比 |
|
冒烟测试效率 |
冒烟执行耗时 |
和手动冒烟测试耗时对比 |
|
|
线上回归效率 |
回归执行耗时 |
和手动回归测试耗时对比 |
|
|
覆盖率 |
接口覆盖率 |
|
梳理核心接口，投入最多资源精力 |
|
用例覆盖率 |
|
梳理核心case，投入最多资源精力 |
|
|
业务场景覆盖率 |
|
根据业务场景，case by case度量 |
|
|
过程质量 |
构建执行成功率 |
自动化任务执行成功率 |
低于某个阈值判定脚本质量不通过 |
|
用例执行通过率 |
自动化case执行成功率 |
低于某个阈值判定提测质量不通过 |
制定度量指标要注意的
制定度量指标时，建议遵循和考量如下几点：
- 切忌面向指标/面向KPI做度量；
- 考虑到冗余成本，指标不宜过多；
- 制定指标是为了提升质量，而非做数据；
- 根据做自动化测试的目的来制定度量指标；
- 度量指标对比应该以是否解决了痛点为依据；
- 度量指标是辅助评估依据，并不是唯一正确的结果；
- 制定指标应考虑到哪些指标更实际有效，从解决问题角度出发；
- 度量指标不要单一的评估，应结合多个维度来综合评估开展质量度量；