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

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

　　组内评审可以要求基于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。

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