因为还有一部分缺陷可以通过ad-hoc 测试(随机、自由的测试)、集体走查(Work-through)和Fire-drill测试(类似消防训练的用户压力/验收测试)等其他手段发现缺陷
4.测试执行的效率和质量
测试执行的质量一般可以用软件发布后所遗留的软件缺陷和总缺陷数的比值来衡量，一般要求低于0.5%，也可以通过种子公式或交叉测试等方法衡量。测试执行的效率可以用下列几种方法来综合度量：
每个人日所执行的测试用例数 每个人日所发现的缺陷数 每修改的KLOC所运行的测试用例数
5.缺陷报告的质量
缺陷报告质量可以评估测试人员工作质量的方法之一，如可测量的指标有：
缺陷报告有效性，所有修正/关闭的(等级高的)缺陷和测试人员所报的所有(等级高的)缺陷的比值，这个值越接近1，有效性就越高，如果考察等级高的缺陷，其正常值大约在0.92 – 0.96 缺陷报告质量，可以用一些中间状态为“需要补充信息”、“不是缺陷”的缺陷数量来衡量，一般占总缺陷数的3%-5%为正常，高于或低于这个值都可能不正常，高于5%，可能说明缺陷报告质量低;低于3%，可能说明测试人员缺少怀疑精神。
6.基于需求的测试覆盖评估
基于需求的测试覆盖评估是依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保100%的测试用例全部成功地执行。一般在测试计划中，就定义了测试的工作量、测试用例数量和测试用例覆盖率(98%-100%)，我们根据事先确定的测试日程安排，可以将测试计划值做成曲线，然后根据实际执行结果，定期(每天或每周)去画实际值曲线，从而可以进行测试全过程监控和预测。
在执行测试活动中，评估测试用例覆盖率又可分为两类测试用例覆盖率估算：
确定已经执行的测试用例覆盖率，即在所有测试用例中有多少测试用例已被执行。假定Tx已执行的测试过程数或测试用例数，Rft是测试需求的总数： 已执行的测试覆盖 = Tx/Rft 确定成功的测试覆盖，即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试，假定Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数。 成功的测试覆盖 = Ts/Rft
7.基于代码的测试覆盖评估
基于代码的测试覆盖评测是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖，则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
评估代码覆盖率，需要断定测试目标期望的、总的测试代码行数，在测试中真正执行的代码行数及其百分比，将此结果记录在测试评估报告中。测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已经定义。
基于代码的测试覆盖通过以下公式计算：
已执行的测试覆盖 = Tc/Tnc
其中Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数，Tnc(Total number of items in the code)是代码中的项目总数。
文章来源于领测软件测试网 https://www.ltesting.net/
