低代码自动化测试平台的普及，测试同学代码能力的提升使得目前自动化测试已经成了测试工作中非常重要的组成部分，不管是由于kpi压力也好，还是因为需要消除其他方面的质疑声音也罢，我们经常需要在工作中制定一些可以度量的指标来描述某项工作或者改进的实际效果。那么有哪些指标可以去度量自动化测试的最终效果呢，这里给大家一些常见指标作为参考。

可自动化率

这个指标主要是描述所有的测试用例中有多少的用例可以被用自动化的方式进行回归，毕竟有一些用例可能还是要手动去执行的，这个值越高那么进行自动化的边际成本可能就越低。

计算公式：可自动化率 = （可以实现自动化的用例数量 / 用例总数）* 100

自动化脚本bug发现率

这个指标可以直观的描述自动化测试的效果，你可以通过这个指标来评估当前的投入产出比是否可以接受，另外在不同的测试环境中的效果应该是不一样的，举例来说在测试环境中我们可能主要是进行新功能的测试，那么发现的大多数问题可以都是来自手工测试，但是在staging环境或者说是预发布环境，我们应该主要通过自动化脚本来发现bug，所以这个效果值应该相对高一些。

计算公式：（自动化测试发现的bug数 / 有效bug数）* 100

用例通过率

这个指标用来衡量用例的稳定性和自动化测试的实际效率，毕竟如果通过率低的话就意味着我们需要花费大量的时间去定位运行失败的原因。在多次测试中，通过率如果明显下降那么可能意味着：要么是我们的用例不稳定，不值得信赖；要么是本次的发布中包含了太多的bug。

计算公式：（通过的用例数 / 执行的用例数）* 100

用例执行时间

天下武功，唯快不破。如果用例执行的速度太慢那么我们就没有办法在代码部署后迅速的给开发人员以反馈，浪费时间就是浪费生命。

计算公式：用例结束时间 - 用例开始时间

自动化测试用例覆盖率

耳熟能详的概念，也是很多团队都会追求的一个指标，覆盖率越高就证明测试回归的效率越高，这是一个需要长期追踪的指标，kpi里寻常见，okr前几度闻。

计算公式：（自动化用例数 / 用例总数）* 100

自动化用例异常率

顾名思义的指标，值得去长期关注的指标，其实就是通过率的另一种体现，失败率高可能意味着系统或产品的行为发生了更新，用例也需要进行相应的修改了。

计算公式：每次用例执行（失败用例数 / 执行的用例数）* 100

构建异常率

用例追踪cicd中构建质量的指标，异常率越高可能就意味着代码质量相对较差。

计算公式：（构建失败次数 / 构建总数）* 100

迭代中的自动化测试创建率

理论上说我们这个迭代开发的功能就应该在该迭代中被自动化用例所覆盖，迭代完成之后补作业的行为是不推荐的。这个指标可以告诉我们我们离该目标还有多少距离。

计算公式：（本迭代中创建的用例数 / 非本迭代中创建的用例数）* 100

自动化进度

我们的目标是将所有可以自动化的用例都进行自动化，这个指标告诉我们距离这个小目标实现有还有多少路要走。

计算公式：（当前自动化用例总数 / 可以被自动化的用例数）* 100

测试金字塔

这个指标可以告诉我们当前自动化用例的分布情况，理想情况下测试用例的分布应该是金字塔型的，ui用例最少，接口和集成用例较多，单元测试用例最多。

计算公式：（每种自动化测试用例的数量 / 用例总数）* 100

总结

年底了，希望这些指标可以帮助大家进行下一年度的kpi或okr规划。