在软件发布之前如何预估残留缺陷？（09-6-16）（获奖名单已公布）

allenzgw

在回答这个问题之前，我们首先理清思路，测试的质量首先就体现在缺陷的质量上面。就是发现了多少缺陷，缺陷的严重程度如何，缺陷发现的早晚，缺陷的分布等待，作为测试的结果直接向客户表明了测试的质量。然而测试的质量又有什么所决定呢？是测试用例，测试用例的覆盖率，测试用例的精细度，深度，直接决定了能发现缺陷的多少。所以，要在未发布之前预估缺陷的遗留情况，就要检查测试用例的覆盖情况。

1. 根据测试用例和SRS中功能点的一一对应关系，还有概要设计、详细设计中的对应关系，这个跟着矩阵，检查是否所有的功能点都被覆盖到了。
2. 覆盖到功能点包括起码几个方面，1是正面的用例，2是负面的测试用例，3是所有的分支路径和错误处理是否都做了。
3. 对于有些需求，比如性能需求可能没有在功能测试用例涉及到，而性能需求也没有专门的收集，这就需要专门的收集，并且细化测试。因为很可能所有的功能都满足了，但是性能并不满足。系统并发用户使用并没有测试。这是很容易遗漏的，在项目快收尾阶段仍然需要检查一下是否所有的非功能点都测试过了。
4. 通过以上分析，如果发现有没有覆盖到得，覆盖不足的就是可能有缺陷遗留的地方。

以上总体是为了保证：所有系统该实现的功能都得到实现了，同时系统没有去做任何不该做的事情。
然而，并非通过以上途径就可以确保能够发现所有改发现的缺陷了。我们还可以通过比较分析当前的缺陷数据和历史相关数据来检查：

1. 如果这个被测系统有之前的版本的测试数据，那我们可以比较以前的这个版本所有的缺陷，看看以前一共多少个模块，平均每个模块发现了多少缺陷，然后客户又发现了多少缺陷。而我们现在这些相应的模块发现了多少缺陷。为什么比以前多，为什么比以前少，等等，很多可以比较的地方
2. 类比同类产品的测试，比如都是j2ee，同样类型的系统，平均每kloc代码一共发现多少缺陷？平均每kloc代码一共能写出多少测试用例？平均每个功能点能写出多少测试用例，发现多少bug？而我们目前写了多少测试用例，发现了多少bug？那些模块发现的多或者少？然后检查原因，到底是为什么？因为这些都是可能存在缺陷遗漏的地方。
3. 对于不同的测试人员，做数据的比较，看谁发现的多，谁发现的少，谁发现的某种类型的缺陷多，或者少？因为常常是某些测试人员之容易看到某类型的缺陷，而遗漏另外一些类型的缺陷。
4. 对本被测系统的缺陷库做分析统计，各种类型的缺陷比例各是多少？这个比例是否符合历史数据的比例？分析统计以前产品的遗留缺陷比例，然后对比当前的产品。
5. 分析本公司，或者本测试团队以前的所有的非测试用例找到的缺陷，还有产品发布后被客户提出的缺陷。这些缺陷往往是我们团队自身固有的问题导致的盲区，这些缺陷类型和特点需要在本次测试中专门关注。
6. 分析测试方案、测试用例、开发的详细设计、概要设计的评审文档，以及相应的评审数据，发现的缺陷比例是否合理，以此判断分析是否评审的到位，如果评审不到位，则测试用例可能质量不够高，有遗漏，则测试就可能会少发现缺陷，这些地方需要认真检查。
7.具体的缺陷遗留比例可以根据上面提到的各项数据对比分析来确定，比如同类型，同代码量的软件应该能写1000个测试用例，发现2000个bug，而我们发现了1800个bug，则可以怀疑我们还遗留200个缺陷，但是，这只是怀疑，还需要分析是否由于开发团队的成熟导致的确只有1800个bug。这都是需要进一步分析论证的。


以上通过各种方式和角度的数据统计和对比，学习以前的经验，借此发现系统可能存在的潜在问题。然而可能还会发现不全，我们有以下手段可以应对：

1. 找经验相对比较丰富的测试人员，或者非本项目的测试人员来对本系统做随机测试。虽说是随机，但是，其实因为都是有经验的人员，而且对相关的系统都很熟悉，测试目的还是非常强的，同时这个测试过程，需要有本系统的测试人员陪同讲解，类似于配对开发而言的配对测试一样。
2. 问开发人员，他们怀疑他们的系统什么地方可能会有缺陷，然后专门去测试这些地方
3. 如果开发有单元测试，这时候我们可以分析单元测试的结果，看看单元测试的覆盖率，是语句覆盖还是判定覆盖，逻辑覆盖，等等，如果某些重要的功能点的覆盖率不够，我们可以专门去从单元测试和集成测试外加系统测试的高度做相应的测试，力图将这几个重点模块的测试覆盖率达到最高。如果之前没有单元测试，这时候也可以分析代码，测试重要的判断点。

总结：基本上我能想到的就是以上这些从测试角度，不涉及开发而谈的方法，判断分析出系统潜在的有问题的地方，以及相应的补救措施。但是需要说明这些方法必须在整个测试过程中实施，而不是快要交付之前才开始检查，这是团队管理人员，在项目计划中必须预留相应的时间和人力贯彻执行的。

tails82

排除按照经验拍脑决策的方式，要进行这种高难度的工作，公司必须有良好的度量体系，能正确收集历史数据为前提。
预估残余缺陷，首先要确定哪些阶段会引入缺陷。
通常认为，传统的瀑布模型中，每个阶段都会引入缺陷。这些阶段为：需求分析->概要设计->详细设计->编码->测试。
而测试又可再进一步细分为：测试需求分析->测试设计->测试实现->测试执行。
如果公司的测试团队已经很成熟，那么应该从需求分析阶段就已经介入了。整个瀑布模型中，具体测试人员会参与哪些，各公司都不同。但如果公司在以往项目的各阶段，都进行了数据收集的工作，那么此时就有用了。根据历史数据计算出，每个阶段应该发现的缺陷的平均值（这个值为该阶段发现的和漏测的缺陷数之和），乘以项目规模系数。用此方法来得出当前项目该阶段应该发现多少缺陷。然后利用蝴蝶效应的理论，前期未发现的缺陷在后期会成倍扩散，在各个阶段检查，是比经验数据多测出了Bug，还是少了。如果少了，那么后续阶段可能会多引入N×（少发现的Bug数）个缺陷。假设前一阶段少发现的缺陷数为X，后续阶段应该发现的缺陷数为Y，那么N×X+Y为后续阶段包含的缺陷数。利用以往该阶段的缺陷探测率，推测出该阶段应该发现的缺陷数。反之，前期发现的多了，后期阶段包含的缺陷就少了。反复运用上述方法，直到最后阶段，就能推测数发布前残留的缺陷数。
当然，要能实施这种高难度工作，并不是每个公司都有能力的。我们公司就没有，只是我的一些想法。如果我是领导，也许会尝试一下。

lee_huo

不能靠猜测的，没有依据，没有说服力。
不过可以通过，缺陷发现阶段、缺陷引入阶段这个2个字段总结和分析出来。
通过历史数据的积累，能够得出缺陷遗留模型，这样分析出来的数据比较可靠和有说服力。

lennie-zhao

测试员根据自身经验可能估计出
还有测试员可以凭‘感觉’估计，也就是对软件的了解，测试程度

alexander_zhu

这个是“猜”不准的。

不管你动用什么方法进行了测试，最后的结果。是根据实际情况不同而不同的。可能你把用户使用率最高的测试100%覆盖，使用率低的20%，那么某天全是那20%的那部分，用户使用的时候缺陷就会被发现很多了。

yetties2005

跟着学习了。。。

hugn_2000

一个较简单的办法是使用TD里的缺陷收敛图，结合正态分布率计算，最后的5％基本就是了