浅谈软件测试度量（一）

软件测试度量是对软件测试过程的量化分析，对于改进软件测试过程，提高软件测试效率具有重要意义。首先我们必须弄清楚“软件度量”包含度量数据的定义（包括度量项的定义、单位、频率、数据来源、数据提供者等）、收集、分析等一系列的活动。在收集的过程中，暴露问题和解决问题，并根据数据优化软件测试的各个环节。通常我们在分析度量数据的时候，也不能片面孤立的去看某一个数据，数据之间往往具有关联性，一个数据过高或过低都不足以支撑我们得出正确的结论，往往需要几个数据的结合分析才更有参考意义。

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

1、测试用例的需求覆盖度

【指标名称】测试用例的需求覆盖度

【指标定义】测试用例的覆盖程度

【设置目的】检验测试用例覆盖需求和规格的程度

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

【计算公式】测试需求覆盖率=100%*（测试用例覆盖的测试需求数/测试需求总数）

【计量单位】％

【数据提供】POP

【数据审核】产品经理、测试LTM

【统计周期】每次产品版本的测试完成

【考核对象】角色：TE

【分区说明】

A:覆盖率>=95%

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

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

D:覆盖率< 80%

【目前统计方法】

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

【重点难点】

输入方面：只有需求包、没有规格包；需求规格颗粒度较大，测试用例可以覆盖，但是深入度不够；需求规格的频繁变化导致对应文档的维护跟踪工作量大
统计方面：目前只能通过实际阅读来确认覆盖度，无自动化统计方法，依赖于人；目前是在相关评审中顺带着执行。

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

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

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

2、测试用例的评审率

【指标名称】测试用例的评审率

【指标定义】测试用例的评审率

【设置目的】衡量测试用例的评审情况

【计算公式】测试用例评审率=100%*（已评审的测试用例数/测试用例总数）

【计量单位】％

【数据提供】测试LTM

【数据审核】产品经理、测试部经理

【统计周期】每次产品版本的测试完成

【考核对象】角色：TE

【分区说明】

A：>=95%

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

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

D: 评审率< 80%

【目前统计办法】TD上提供标记位，记录测试用例的评审状态。可以直接通过TD工具获取当前测试用例的评审率。

【重点难点】数据的准确性：实际上对测试用例的评审分为组内评审、组外评审两种，分别如下：

组内评审可以要求基于TD并标记好状态，而项目组评审因为时间关系，不太可能按照TD中的实际条目，进行逐条评审。将项目组的评审落实到TD中的每条、每各step的用例，是依赖于TE的手工操作，所以数据会存在一些偏差。

执行方面：此数据是要求在版本测试完成时提供，和测试覆盖率一样，数据的收集会在项目启动时，通过专门的评审会议来操作、标记。这样对在版本开发过程中的需求规格更改（增加、删除、修改）对应的测试用例无专门的评审点，在开发过程中导致的测试用例变更的评审目前各测试组执行力度不一样，可能会存在一定的数据误差。

【理想情况】在版本测试过程中，TE专人实现对测试用例的动态维护：需求的变更和细化；测试用例的补充（根据bug、根据外部应用场景）