浅谈软件测试度量（二）

3、测试用例的执行度

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

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

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

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

【计量单位】%

【数据提供】TLTM

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

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

【考核对象】角色：TE

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

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

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

D:通过率< 70%

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

【重点难点】

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

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

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

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

4、测试持续时间偏差率

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

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

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

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

【计量单位】%

【数据提供】测试LTM

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

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

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

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

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

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

D:通过率< 70%

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

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

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

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

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

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

【计算公式】

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

【数据提供】QA POP

【数据审核】产品经理 

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

【考核对象】产品组

【分区说明】无

【目前统计办法】

目前此项数据由项目管理部负责，各产品线的问题遵循约定的流程进行处理外部问题→客服技术支持→核实确认后录入客服CQ→研发接口人受理→解决问题→客服确认问题解决→在客服CQ关闭问题。按照此约定，所有的外部问题都会登录到客服CQ，由研发管理部专人按季度在客服CQ上提取数据，经过研发内部分析（归类是需求、技术支持、bug）后，完成此数据。

7、提交的有效问题数量 

【指标名称】提交的有效问题数量

【指标定义】每个周期中，CQ中提交的有效问题数量

【设置目的】反映测试人员的一个周期的工作量

【计算公式】

【计量单位】个

【数据提供】POP

【数据审核】测试LTM测试部经理

【统计周期】每个月

【考核对象】TE

【分区说明】

【目前统计办法】目前暂未对此类数据进行考核。对测试人员提交的CQ进行审核，目前有两个难点：一、CQ上需要实现此功能；

二、测试的LTM能够从日常的测试工作中抽离出来，绝大部分精力投入到管理工作时，才有可能投入精力审核提交bug、维护测试用例、把握测试进度和测试方法。

结合下面的一个数据收集，目前进行统计的数据是每个周期中，CQ中每个测试人员提交的问题数量，反馈测试人员的一个周期工作量，反应软件模块的周期稳定性，暂不详细区分测试人员的效率和对业务的理解程度。

8、提交的非有效问题数量

【指标名称】提交的非有效问题数量

【指标定义】每个周期中，CQ中提交的非有效问题数量

【设置目的】度量所有测试人员对系统理解的能力

【计算公式】