两年前，针对测试是否要量化考核，写的偏务实的文。我们用的是CQ+TD。

　　-------------------------------------------------------------------------------------------------

　　案例描述

　　软件测试过程的度量对于改进软件测试过程，提高软件测试效率具有重要意义。软件测试度量是对软件测试过程的量化分析。论述了软件测试度量的流程，软件测试度量中的重要指标及对度量指标的分析方法，对于指导和改进软件测试过程具有实际意义。

　　本文对测试领域在业界常用的一些度量数据进行分析，从实现方法、实现意义和实际作用等多个角度，进行分析说明。

　　1、案例分析

　　1.1 测试用例的需求覆盖度

　　【指标名称】测试用例的需求覆盖度
　　【指标定义】测试用例的覆盖程度
　　【设置目的】检验测试用例覆盖需求和规格的程度

　　对测试工作本身、对TR检查，此数据都是一个基础数据。

　　【计算公式】测试需求覆盖率=100%*（测试用例覆盖的测试需求数 /测试需求总数）
　　【计量单位】％
　　【数据提供】POP
　　【数据审核】产品经理、测试LTM
　　【统计周期】每次产品版本的测试完成
　　【考核对象】角色： TE
　　【分区说明】

　　A：覆盖率 >=95%

　　B：95% > 覆盖率 >=90%

　　C：90% > 覆盖率 >=80%

　　D：覆盖率 < 80%

　　【目前统计方法】根据需求跟踪矩阵中列出的测试用例覆盖情况统计。评审测试用例时，对照需求、规格落实到相应的测试用例（实际评审用例时，同时会打开相对应的规格需求，逐条进行落实评审）。

　　【重点难点】输入方面：只有需求包、没有规格包。

　　需求规格颗粒度较大，测试用例可以覆盖，但是深入度不够；

　　需求规格的频繁变化导致对应文档的维护跟踪工作量大。

　　统计方面：目前只能通过实际阅读来确认覆盖度，无自动化统计方法，依赖于人；目前是在相关评审中顺带着执行。

　　执行方面：测试用例覆盖度此项数据是在版本测试完成时统计，而目前数据收集是在开发阶段时，测试进入环节，通过评审测试用例进行的。

　　这样对在版本开发过程中的需求规格更改（增加、删除、修改）对应的测试用例无专门的统计考察点，只能依赖于项目组实际的会议、评审、周报、bug会等来监控，依赖于TR检查时，各领域各角色人员的严格自检。

　　【理想情况】通过统一的工具来管理需求规格和测试用例，可以通过管理软件进行相互的对应、映射，实现关联和自动化统计。

　　1.2 测试用例的评审率

　　【指标名称】测试用例的评审率
　　【指标定义】测试用例的评审率
　　【设置目的】衡量测试用例的评审情况
　　【计算公式】测试用例评审率=100%*（已评审的测试用例数 /测试用例总数）
　　【计量单位】％
　　【数据提供】测试LTM
　　【数据审核】产品经理、测试部经理
　　【统计周期】每次产品版本的测试完成
　　【考核对象】角色：TE
　　【分区说明】

　　A：>=95%

　　B：95% > 评审率 >=90%

　　C：90% > 评审率 >=80%

　　D：评审率 < 80%