如何制定测试团队度量体系
目录
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）界面、程序或帮助文档中文档或文字描述问题，但影响不大
