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