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

默默巫

上一期话题我们讨论了"遗留缺陷如何处理？",本周话题我们引申探讨,“在软件发布之前如何预估残留缺陷（未发现的缺陷）？”



如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
二等奖	allenzgw	300论坛积分	8#
三等奖	tails82	100论坛积分	7#

song61310511

软件名称：商超流通管理8.4_连锁版破解
软件语言：简体中文
界面预览：无
软件类型：软件分类：国产软件 / 推广软件/
运行环境：Win9x/2K/XP/2003
软件大小：138305KB
授权方式：共享软件
联系人：908117001@qq.com
开发商：http://www.facepos.com
软件下载地址：http://www.cgpos.com.cn/商超流通管理8.4_连锁版破解.EXE
软件介绍：
1、  强大的报表自定义功能，可以很方便的设置用户自己所需要的报表格式，最适合国内企业对报表格式的要求
2、  全面业态的支持，同时对购销、代销、联营、租赁和专柜的业务处理和财务结算
3、  完善的反审核功能，可以轻松把已审核的单据反审，重新计算库存、成本、最高价、最低价、平均价及历史记录。即使做错资料，也可以轻松还原
4、  近百万条的条码库，可以帮助你在做商品档案时，自动提供该条码的商品信息，更可以提供该商品的市场平均零售价、最高价、最低价及平均进价、最高进价、最低进价，为您的采购和销售定价提供绝无仅有的最有力支持
5、  支持移动加权平均和先进先出批次的算法，还有对企业的利润提升有相当重要的最低进价算法
6、  稳定的前台数据保存和传输设计，可以帮你稳定的保存数据，不会丢失。即使停电或感染病毒，前台销售数据也可以安枕无忧。可以根据网络状态，自动切换到断网收银状态或联网收银状态，自动上传下载资料，后台更改商品价格后，无须做任何操作，前台即可按最新的商品价格进行销售
7、  支持目前主流的POS硬件，提供对更多更全面的硬件的支持
8、  多种多样的促销方式，丰富的会员功能，使您的管理不受限，营销无障碍
9、  提供数据转换功能，切换系统更柔性更平滑，保障营业无间断
10、最强大的代理商工具，提供程序业务源代码和二次开发工具，能够最大的适应客户的需求。让代理商在千变万化的客户需求中，保证最强的竞争力

song61310511

下载地址：
http://www.cgpos.com.cn/商超流通管理8.4_连锁版破解.EXE

carany

不懂，学习中

starseeker

如果是多版本的测试有历史数据可以用“四象限分析法”
可以定义出缺陷数，严重等级，执行时间等3个纬度进行分析。也可以使用SPC方法中的UZ图来做。

zilter

个人觉得首先要分析对客户的影响，再看出现的几率到底有多大！
如果对客户影响大，那一定尽量在发布之前解决掉，测试和研发一起下手，研发审查代码，测试加大测试粒度，可以指定一个测试计划，比如测试20-50遍，重现的几率到底有多大？
实在重现不了就只能挂起了，说明出现的几率并不大！

daogua

恩，我看过，可以的

婧子

想知道11楼的是怎么根据抽屉原理推出的

pycctv

我觉得 在产品发布前预估缺陷的方法还是主要采取对比法。测试技术的发展是一点一滴的积累，要预估产品的缺陷，就要根据以前所发布的产品的缺陷，以及客户所发现的缺陷的数据来对比，从而估算隐藏的缺陷。当然了，在实施以上办法的前提是，严格按照需求分析对产品进行过单元测试，集成测试和系统测试（功能测试，性能测试，压力测试，配置测试，用户文档测试，安全性测试，恢复性测试）。

dqar

假设软件中固有缺陷为N0（估算值）,植入缺陷为Ns,通过测试发现n1个植入缺陷和n2个软件固有缺陷。那么有如下公式：
N0=n2*Ns/n1
则软件中残余缺陷数目大约为：
N0-n2

woza

预估残留缺陷有必要吗？就算你估计的非常正确又有什么帮助。系统里面已经发现的缺陷都未必都去修复，何况是未知的。

不管是做开发还是做测试，都要明白一个基本原则：软件是拿来卖钱的，如果你做的事情不会有客户为你掏钱，那么就是白费功夫。

eagleking

发布之前肯定是要进行测试的，测试之后测试部将给出测试报告。
要预估残留缺陷，应该根据测试报告。
查看严重问题主要出现在哪些模块，哪个模块发现的问题最多，
一共出现多少问题。
由此预估残留缺陷。。。

tails82

我觉得抽屉原来不太适用。因为前提是要测试同一段程序。但是一般公司都是把系统分成几个子系统，交给不同的人去测试的。
还有就是，我还不太明白这个公式是怎么推导出来的。你那个总BUG数指预计残留的Bug数吗？A是100个，B是50个，相同的是30个。那不同的Bug数应该是100+50-30=120？ 120相当于120抽屉吗？把150个Bug放到120个抽屉里，结果有30个抽屉有多余一个的Bug，如何再继续得出预估的Bug数？谢谢！

puchonghui

如果有比较充足并且准确的数据积累，那么作出一定的预判是可能的。

不过我不太明白：预估残留缺陷数的目的到底是什么？

chengxq

这个在CMMI5的时候，最好作相关数据的收集，做好一定的基线，预测残留缺陷
主要是过程稳定的，而且在每个过程都在控制目标值的标准下
当然可能还没有建立过程性能模型，那可以通过bug回归测试的收敛率来进行判断

b45993e

软件发布前缺陷分析所用缺陷根本原因的关键字，可以有下几种实例：
        * 编程：原始编程出错，没有客观原因。
        * 修改：由于修改缺陷而引发的新变更，并且引发的变更与原变更的错误是相关的。
        * 培训：项目组新成员培训不充分，或使用新工具不熟练引起的变更。
        * 需求文档：需求分析文档不明确、不详尽等原因所引起的变更。
        * 信息交流：信息交流不畅，开发成员间沟通不及时引起的变更。
        * 外部问题：所涉及软件模块外部问题引起的变更。
        * 其他：指以上各种原因之外所产生的变更。
        软件发布后缺陷分析所用缺陷根本原因的的关键字，可以有下几种实例：
        * 需求分析：需求分析不足等原因所引起的变更。
        * 系统设计：软件系统设计种种原因所引起的变更。
        * 程序编码：软件开发阶段中编程错误所引起的变更。
        * 维护：软件发布后程序维护时引起的变更。
        * 实施：实施人员做软件初始化设置或系统参数设置不当等，实施时所引发的变更。
        * 用户：泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。
        * 数据异常：运行中不明原因引起的用户数据混乱和异常。
        * 升级：软件版本升级过程发生的问题，包括用户在升级时未按规程操作产生的问题。

kukumaru

附:抽屉原理
抽屉原理又称鸽笼原理或狄利克雷原理，它是数学中证明存在性的一种特殊方法。举个最简单的例子，把3个苹果按任意的方式放入两个抽屉中，那么一定有一个抽屉里放有两个或两个以上的苹果。这是因为如果每一个抽屉里最多放有一个苹果，那么两个抽屉里最多只放有两个苹果。运用同样的推理可以得到：
　 原理1 把多于n个的物体放到n个抽屉里，则至少有一个抽屉里有2个或2个以上的物体。
　 原理2 把多于mn个的物体放到n个抽屉里，则至少有一个抽屉里有m+1个或多于m+l个的物体。

kukumaru

抽屉原理：
测试员A发现100个BUG
测试员B发现50个BUG
其中共同的BUG数30个

那么总BUG数：(100*50)/30=167个

lychee1016

使用TD里的缺陷收敛图,然后再凭经验直觉了

name135791

我所了解的两种

1。根据公司开发的类似产品可以对新开发产品有个比较合理的残留缺陷估计值，方法是统计以前的类似产品由客户发现的而在测试中未发现缺陷数量，然后拿它除以测试中发现的

缺陷数，得出一个比率（样本多的话，还可以求平均比率，这样会更加准确）；然后拿新产品测试中的缺陷数乘以这个比率就可以得出残留缺陷估计值。

2。错误播种法，在软件中故意种下缺陷，然后计算这种故意种下的缺陷被发现的比率，就可以推断得到残留缺陷估计值。

个人觉得第一种方法更好