在软件发布之前如何预估残留缺陷？（09-6-16）（获奖名单已公布）
上一期话题我们讨论了"遗留缺陷如何处理？",本周话题我们引申探讨,“在软件发布之前如何预估残留缺陷（未发现的缺陷）？”如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单奖项获奖名单奖励答案链接二等奖allenzgw300论坛积分8#三等奖tails82100论坛积分7# 一个较简单的办法是使用TD里的缺陷收敛图，结合正态分布率计算，最后的5％基本就是了 跟着学习了。。。:) 这个是“猜”不准的。
不管你动用什么方法进行了测试，最后的结果。是根据实际情况不同而不同的。可能你把用户使用率最高的测试100%覆盖，使用率低的20%，那么某天全是那20%的那部分，用户使用的时候缺陷就会被发现很多了。
不好估计
测试员根据自身经验可能估计出还有测试员可以凭‘感觉’估计，也就是对软件的了解，测试程度 不能靠猜测的，没有依据，没有说服力。
不过可以通过，缺陷发现阶段、缺陷引入阶段这个2个字段总结和分析出来。
通过历史数据的积累，能够得出缺陷遗留模型，这样分析出来的数据比较可靠和有说服力。 排除按照经验拍脑决策的方式，要进行这种高难度的工作，公司必须有良好的度量体系，能正确收集历史数据为前提。
预估残余缺陷，首先要确定哪些阶段会引入缺陷。
通常认为，传统的瀑布模型中，每个阶段都会引入缺陷。这些阶段为：需求分析->概要设计->详细设计->编码->测试。
而测试又可再进一步细分为：测试需求分析->测试设计->测试实现->测试执行。
如果公司的测试团队已经很成熟，那么应该从需求分析阶段就已经介入了。整个瀑布模型中，具体测试人员会参与哪些，各公司都不同。但如果公司在以往项目的各阶段，都进行了数据收集的工作，那么此时就有用了。根据历史数据计算出，每个阶段应该发现的缺陷的平均值（这个值为该阶段发现的和漏测的缺陷数之和），乘以项目规模系数。用此方法来得出当前项目该阶段应该发现多少缺陷。然后利用蝴蝶效应的理论，前期未发现的缺陷在后期会成倍扩散，在各个阶段检查，是比经验数据多测出了Bug，还是少了。如果少了，那么后续阶段可能会多引入N×（少发现的Bug数）个缺陷。假设前一阶段少发现的缺陷数为X，后续阶段应该发现的缺陷数为Y，那么N×X+Y为后续阶段包含的缺陷数。利用以往该阶段的缺陷探测率，推测出该阶段应该发现的缺陷数。反之，前期发现的多了，后期阶段包含的缺陷就少了。反复运用上述方法，直到最后阶段，就能推测数发布前残留的缺陷数。
当然，要能实施这种高难度工作，并不是每个公司都有能力的。我们公司就没有，只是我的一些想法。如果我是领导，也许会尝试一下。
有办法发现残留缺陷
在回答这个问题之前，我们首先理清思路，测试的质量首先就体现在缺陷的质量上面。就是发现了多少缺陷，缺陷的严重程度如何，缺陷发现的早晚，缺陷的分布等待，作为测试的结果直接向客户表明了测试的质量。然而测试的质量又有什么所决定呢？是测试用例，测试用例的覆盖率，测试用例的精细度，深度，直接决定了能发现缺陷的多少。所以，要在未发布之前预估缺陷的遗留情况，就要检查测试用例的覆盖情况。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. 如果开发有单元测试，这时候我们可以分析单元测试的结果，看看单元测试的覆盖率，是语句覆盖还是判定覆盖，逻辑覆盖，等等，如果某些重要的功能点的覆盖率不够，我们可以专门去从单元测试和集成测试外加系统测试的高度做相应的测试，力图将这几个重点模块的测试覆盖率达到最高。如果之前没有单元测试，这时候也可以分析代码，测试重要的判断点。
总结：基本上我能想到的就是以上这些从测试角度，不涉及开发而谈的方法，判断分析出系统潜在的有问题的地方，以及相应的补救措施。但是需要说明这些方法必须在整个测试过程中实施，而不是快要交付之前才开始检查，这是团队管理人员，在项目计划中必须预留相应的时间和人力贯彻执行的。 我所了解的两种
1。根据公司开发的类似产品可以对新开发产品有个比较合理的残留缺陷估计值，方法是统计以前的类似产品由客户发现的而在测试中未发现缺陷数量，然后拿它除以测试中发现的
缺陷数，得出一个比率（样本多的话，还可以求平均比率，这样会更加准确）；然后拿新产品测试中的缺陷数乘以这个比率就可以得出残留缺陷估计值。
2。错误播种法，在软件中故意种下缺陷，然后计算这种故意种下的缺陷被发现的比率，就可以推断得到残留缺陷估计值。
个人觉得第一种方法更好 使用TD里的缺陷收敛图,然后再凭经验直觉了 抽屉原理：
测试员A发现100个BUG
测试员B发现50个BUG
其中共同的BUG数30个
那么总BUG数：(100*50)/30=167个 附:抽屉原理
抽屉原理又称鸽笼原理或狄利克雷原理，它是数学中证明存在性的一种特殊方法。举个最简单的例子，把3个苹果按任意的方式放入两个抽屉中，那么一定有一个抽屉里放有两个或两个以上的苹果。这是因为如果每一个抽屉里最多放有一个苹果，那么两个抽屉里最多只放有两个苹果。运用同样的推理可以得到：
原理1 把多于n个的物体放到n个抽屉里，则至少有一个抽屉里有2个或2个以上的物体。
原理2 把多于mn个的物体放到n个抽屉里，则至少有一个抽屉里有m+1个或多于m+l个的物体。 软件发布前缺陷分析所用缺陷根本原因的关键字，可以有下几种实例：
* 编程：原始编程出错，没有客观原因。
* 修改：由于修改缺陷而引发的新变更，并且引发的变更与原变更的错误是相关的。
* 培训：项目组新成员培训不充分，或使用新工具不熟练引起的变更。
* 需求文档：需求分析文档不明确、不详尽等原因所引起的变更。
* 信息交流：信息交流不畅，开发成员间沟通不及时引起的变更。
* 外部问题：所涉及软件模块外部问题引起的变更。
* 其他：指以上各种原因之外所产生的变更。
软件发布后缺陷分析所用缺陷根本原因的的关键字，可以有下几种实例：
* 需求分析：需求分析不足等原因所引起的变更。
* 系统设计：软件系统设计种种原因所引起的变更。
* 程序编码：软件开发阶段中编程错误所引起的变更。
* 维护：软件发布后程序维护时引起的变更。
* 实施：实施人员做软件初始化设置或系统参数设置不当等，实施时所引发的变更。
* 用户：泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。
* 数据异常：运行中不明原因引起的用户数据混乱和异常。
* 升级：软件版本升级过程发生的问题，包括用户在升级时未按规程操作产生的问题。 这个在CMMI5的时候，最好作相关数据的收集，做好一定的基线，预测残留缺陷
主要是过程稳定的，而且在每个过程都在控制目标值的标准下
当然可能还没有建立过程性能模型，那可以通过bug回归测试的收敛率来进行判断 如果有比较充足并且准确的数据积累，那么作出一定的预判是可能的。
不过我不太明白：预估残留缺陷数的目的到底是什么？
回复 12# 的帖子
我觉得抽屉原来不太适用。因为前提是要测试同一段程序。但是一般公司都是把系统分成几个子系统，交给不同的人去测试的。还有就是，我还不太明白这个公式是怎么推导出来的。你那个总BUG数指预计残留的Bug数吗？A是100个，B是50个，相同的是30个。那不同的Bug数应该是100+50-30=120？ 120相当于120抽屉吗？把150个Bug放到120个抽屉里，结果有30个抽屉有多余一个的Bug，如何再继续得出预估的Bug数？谢谢！
根据测试数据
发布之前肯定是要进行测试的，测试之后测试部将给出测试报告。要预估残留缺陷，应该根据测试报告。
查看严重问题主要出现在哪些模块，哪个模块发现的问题最多，
一共出现多少问题。
由此预估残留缺陷。。。
为什么要在软件发布之前预估残留缺陷？
预估残留缺陷有必要吗？就算你估计的非常正确又有什么帮助。系统里面已经发现的缺陷都未必都去修复，何况是未知的。不管是做开发还是做测试，都要明白一个基本原则：软件是拿来卖钱的，如果你做的事情不会有客户为你掏钱，那么就是白费功夫。
推荐使用缺陷植入法估算遗留缺陷
假设软件中固有缺陷为N0（估算值）,植入缺陷为Ns,通过测试发现n1个植入缺陷和n2个软件固有缺陷。那么有如下公式：N0=n2*Ns/n1
则软件中残余缺陷数目大约为：
N0-n2 我觉得 在产品发布前预估缺陷的方法还是主要采取对比法。测试技术的发展是一点一滴的积累，要预估产品的缺陷，就要根据以前所发布的产品的缺陷，以及客户所发现的缺陷的数据来对比，从而估算隐藏的缺陷。当然了，在实施以上办法的前提是，严格按照需求分析对产品进行过单元测试，集成测试和系统测试（功能测试，性能测试，压力测试，配置测试，用户文档测试，安全性测试，恢复性测试）。
页:
[1]
2
