如何制定测试团队度量体系

如何制定测试团队度量体系

目录

1、前言

2、指标制定

1、前言

每当月底或一个季度结束，公司或项目都会进行考核指标的统计，来总结每个组员在这个阶段的工作产出与绩效成绩。

那么制定哪些指标最为标准，最为专业，同时针对整个项目组都是公平的，这个就需要每个公司或项目根据实际情况而定。

但大体的都会有BUG数、编写用例数、执行用例数等。

2、指标制定

考核指标公式（仅供参考）：

测试质量（30%）+ 测试效率（20%）+ 测试产出（50%）+ 加分项 - 减分项

1、测试质量，总占比30%

（1）BUG漏测率；占比20%；公式：线上漏测BUG数/缺陷总数；漏测率=0时，得100分；未提交BUG时，得0分

（2）误报率；占比10%；公式：非缺陷类BUG（拒绝的BUG）/缺陷总数；误报率<x%时，得100分，x是数值，根据项目情况而定，如5；未提交BUG时，得0分

2、测试效率，总占比20%

（1）P0/P1BUG验证时效；占比10%；公式：已关闭P0/P1缺陷的平均验证时间（待验证-关闭的时间）；如<1个工作日，得100分；P0P1缺陷数为0时，得0分

（2）P2/P3BUG验证时效；占比5%；公式：已关闭P2/P3缺陷的平均验证时间（待验证-关闭的时间）；如<2个工作日，得100分；P2P3缺陷数为0时，得0分

（3）缺陷验证率；占比5%；公式：已关闭数/（待验证数+已关闭数）；缺陷验证率>=x%时，得100分，x是数值，根据项目情况而定，如95；未提交BUG时，得0分

3、测试产出，总占比50%

（1）测试用例数；占比5%；公式：单日工作量（(功能新增用例数*1+自动化新增用例数*1+功能用例执行数*1)/工作日总天数）

（2）有效BUG数；占比15%；公式：BUG发现数；有效BUG数>=x%时，得100分，x是数值，根据项目情况而定，如30

（3）P0/P1有效BUG数；占比10%；公式：P0P1BUG测出数；P0/P1有效BUG数>=x%时，得100分，x是数值，根据项目情况而定，如6

（4）交付需求数；占比20%；公式：每月个人上线数；交付需求数>=x%时，得100分，x是数值，根据项目情况而定，如5

4、加分项

（1）代码覆盖率；如：每次上线任务的覆盖率高于80%，+1分

（2）技术分享/培训；如：个人当月培训/分享次数，每分享一次，加2分，上限5分

5、减分项

（1）线上事故数；如：每增加一个P0，扣5分，每增加一个P1，扣2分

（2）发布失败数；如：每增加一个，扣5分

（3）质量通报；如：不合规记录，每月累计3次，质量绩效分扣5分，不足3次不扣分，次月重新计数

注：关于缺陷级别

1、致命(P0）

（1）测试执行主要功能直接导致系统死机、蓝屏、挂起、崩溃、程序非法退出

（2）被测系统的主要功能点没有实现

（3）主要模块或功能不满足需求或设计上的要求

（4）软件的安全缺陷导致重要数据丢失或损坏，且无法恢复

2、严重(P1)

（1）测试执行次要功能导致系统死机、蓝屏、挂起、崩溃、程序非法退出

（2）被测系统的次要功能点没有实现

（3）对于主要功能的执行结果与预期结果差别较大

（4）软件的易用性不好，导致用户可能不能正常完成软件的主要功能操作

（5）程序占用过大的系统资源，或是占用资源后不能正常释放

（6）所有合规缺陷问题

3、一般(P2)

（1）软件的实际执行过程与预期结果有差异，但不严重

（2）非正常操作或输入导致系统出错，或执行结果不正确

（3）系统运行过程中偶尔（出现概率＜5%）有出错提示或导致系统运行不正常

（4）软件交互性不好，对于用户可能造成难于操作、学习和理解

（5）在用户经常使用的环境中，界面不美观，影响软件品质

（6）界面、程序或帮助文档中文档或文字描述问题，造成用户难于理解

4、轻微(P3）

（1）软件的实际执行过程与预期结果有较小的差异

（2）软件不能处理用户可能使用的极端条件下的操作

（3）界面、程序或帮助文档中文档或文字描述问题，但影响不大