测试度量指标的收集和意义 上

 两年前，针对测试是否要量化考核，写的偏务实的文。我们用的是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%

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

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

 

组内评审

项目组（外部）评审

人员

测试组全体成员

测试组长、SE、研发Ltm、各领域接口人

范围

对每条需求形成的测试用例进行逐条评审，对涉及穷举、场景架构、业务流程顺序等组合方式进行深入讨论和评审

评审测试用例的优先级

对某一领域、某一模块的设计测试用例的思路、方法进行评审

对重点功能进行逐条评审

评审测试用例优先级

方法

1、编写者阐述设计思路、讲读测试用例

2、小组成员依次发表意见建议

3、组长汇总，点评测试用例

4、适度组织讨论、对需求进行分析、对需求进行讲解

5、提出测试用例修改计划

1、阐述测试用例设计思路

2、请各模块、各领域人员提出问题

3、根据问题，展示对应详细的测试用例；根据问题，回答测试用例的设计思路、组网应用模型、业务场景构建模型

4、记录测试用例的需改进点

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

执行方面：此数据是要求在版本测试完成时提供，和测试覆盖率一样，数据的收集会在项目启动时，通过专门的评审会议来操作、标记。

                   
这样对在版本开发过程中的需求规格更改（增加、删除、修改）对应的测试用例无专门的评审点，在开发过程中导致的测试用例变更的评审目前各测试组执行力度不一样，可能会存在一定的数据误差。

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

1.3
测试用例的执行度

【指标名称】测试用例的执行度

【指标定义】测试用例的执行程度

【设置目的】检验测试用例的执行情况

【计算公式】测试用例的执行度= 100%* （执行过的测试用例数目 /测试用例总数）

【计量单位】%

【数据提供】TLTM

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

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

【考核对象】角色：TE

【分区说明】A:
通过率 >=95 %

B： 90% > 通过率 >=80%

C:
80% > 通过率 >=70%

D:
通过率 < 70%

【目前统计办法】从TD导出测试用例的执行结果进行统计。

【重点难点】一、在实际测试过程中，如碰到测试任务紧，或即将发布版本，或临时版本测试，或无测试用例的情况，这样不走Testdirect的测试过程将无法被统计。执行起来有一定的难度

            二、测试轮次的问题，这个问题很难细化到那些用例被复用多少次。（实际工作中，有的测试用例被执行多次，如：1。几个不同型号的设备执行的是同一个用例；2。交叉测试时，用例被复用）
建议：遇到用例复用（轮次测试），在建立test set时，请重新以型号或轮次号建立新的test set，以便统计（如果覆盖或者删除都会导致前面的执行结果在最终统计时丢失）需各测试组讨论执行

三、测试颗粒度的问题，为了使最终的统计结果更具有参考价值，测试点的step需要有个规定，否则统计结果可能偏差较大。很多已有的测试用例的颗粒度已不符合要求，怎么办？如有的测试点包括上百个step。

这个要配合测试用例梳理项目逐步进行，测试用例是测试工作的根本，因为工作量很大，需要和产品线的测试任务整体考虑，逐步整理。

1.4
测试持续时间偏差率

【指标名称】测试阶段一次测试通过率

【指标定义】对提交的产品版本第一次测试的测试用例通过百分比。

【设置目的】度量开发质量和测试质量，重点反映开发组的工作质量。

【计算公式】 测试阶段一次测试通过率= 100%* （第一次测试用例通过的数目 / 第一次测试用例执行总数）

【计量单位】%

【数据提供】测试LTM

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

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

【考核对象】角色：SLTM，HLTM

【分区说明】A:
通过率 >=90 %

B： 90% > 通过率 >=80%

C:
80% > 通过率 >=70%

D:
通过率 < 70%

【目前统计办法】 目前暂未执行。

此数据的设立，是从测试的角度来评价产品开发的质量，即软件开发经过开发人员单元测试、集成测试，正式提交后，通过CMO编译出来的正式版本的质量。目前公司现状暂无实现价值。

1.5
产品网上运行问题测试遗漏率

【指标名称】产品网上运行问题测试遗漏率

【指标定义】产品网上运行遗漏Bug数与产品发现Bug总数的比值

【设置目的】度量产品测试的质量

【计算公式】

    产品网上运行问题测试遗漏率=100%*（（实验局发现的BUG＋发布给客户后发现的BUG）/系统测试（包括SDV，SIT，SVT）发现的总BUG）

【数据提供】QA POP

【数据审核】产品经理 

【统计周期】Beta测试结束/发布后周期统计（月，季度）

【考核对象】产品组

【分区说明】无

【目前统计办法】目前此项数据由项目管理部负责，各产品线的问题遵循约定的流程进行处理

外部问题→客服技术支持→核实确认后录入客服CQ→研发接口人受理→解决问题→客服确认问题解决→在客服CQ关闭问题。

           按照此约定，所有的外部问题都会登录到客服CQ，由研发管理部专人按季度在客服CQ上提取数据，经过研发内部分析（归类是需求、技术支持、bug）后，完成此数据。