Bug修复与受益递减法则

  如果问100个软件公司的CEO,问他们是否愿意发布含有bug的软件。他们会说什么?50个根本不愿意回答,会说一些软件bug是这个行业中一个需要解决的大问题等不着边的话;40个会说“当然不会!”,并立即给他们的投资者打电话说这是诬陷,会追究法律责任。9位会低着头说“无能为力”。而这最后一位会直盯着你的眼睛说“当然会。”

  我不知道这最后一位是如何领导一个软件公司的,因为他明显学过经济学。

  软件不可能没有bug,如果你希望发布一个完美的软件,你必须解决藏在代码里的所有bug。(想把它们挡在门外?不可能,单元测试敏捷方法,scrum,以及任何当今你能想到的方法论,都不能防止bug进入你的代码库。如果我错了,我相信你会在评论里告诉我。)

  正如你期望的,你在修补bug中投入越多的时间和资金,你就能解决越多的bug。但是,不幸的是,我们的来自经济学的死对头,受益递减法则,同样适用于这个过程。专业的讲,这个法则指在投入生产要素后,每单位生产要素所能提供的产量增加发生递减的现象。用通俗的话讲,这就是说,你能从这个过程中得到的并不等同于你所有投入的。相反,你的产出会随着投入到增加形成一条迅速下降的曲线,曲线的末端、投入到轴线上,最终成为一条长尾。

  举个例子,假如一个程序有100个bug,我们知道这需要投入100分的努力来找到并修复这所有100个bug。受益递减法则告诉我们,头40分努力将会找到70个bug,而接下来的30分努力能找到20个bug,剩下的30分努力能找到最后的10个bug。这就是说,头70个bug(很简单的bug)很便宜,容易找到,算起来每个bug只消耗40/70=0.571分努力。接下来的20个bug(藏的较深的bug)要昂贵的多,每个消耗30/20=1.5分努力,而最后的10个bug(真正难发现的bug)惊人的昂贵,每个消耗30/10=3分努力。消灭这最后的10个bug要比消灭起初的70个bug,每个bug需要投入的时间或资金要多出5倍。从付出的努力看,消灭大多数bug(70%-90%)和消灭所有bug,它们的成本有巨大差别,从数字上看相差两倍之多。

  而在现实中,实际情况比这更糟糕。因为你不知道何时能干掉这最后一个bug---没有一个像上面例子那样的倒计数——你不得不不断的去寻找更多的bug,即使是它们已经全部被干掉了,你也要去证明它们确是全部被干掉了。如果你想消灭所有的bug,你还要计算你的成本。

  所以,消灭一个程序中所有的bug是一件代价很大的事。不妨让我们花一分钟这样思考一下:一个软件公司最终决定要这么做。软件公司并没有设定像“发布没有bug的软件”的目标——他们设定的目标是“11月19号发布”——于是,这个目标改变了公司的测试计划和开发计划(不论有没有计划),这必然意味着的预算的增加。现在,你想象一下,谁会为这多出的预算买单?公司?(嗨!)如果你没有在软件公司工作过,让我来给你一点提示:非也。软件公司会把成本转嫁到客户身上。因此可以得出,你喜欢的软件都是你支付的起的软件。我得到的消息是:你喜欢有bug的软件。(开源软件也是如此。除非你愿意花更多的钱或等更长的时间。很有可能你会接受去忍受次等的软件事实。)

  现在澄清一下,我并不是说软件公司应该发布有大量严重bug的软件。我是说他们的软件里可以有少量的小bug。

  如何知道一个bug是大还是小?你应该思考谁会遇到它,当遇到时会发生什么样的坏情况。如果一个用户,进入第三层菜单,打开一个高级配置窗口,选中三个复选框,在敲击“A”键时得到了一个奇怪的错误信息,这是小bug。它埋的很深,当碰到它时人们会说“靠”,然后改为点击按钮,然后就会愉快的做其它事情去了。如果在使用你的程序中一个常用的操作时崩溃,那这就是个大bug。大部分人遇到这样的bug时都会愤怒不已。

  所以,我要提出一个判断你的软件何时满足发布条件的黄金法则。这个黄金法则内容是,你应该不断的测试并修复软件中的bug,直到发现这些bug是:

  不会让你的公司蒙羞。

  不会激怒你的客户。

  相比起让一些用户遇到这些并不在于的bug的代价,你的要找出程序中所有bug并确保全部纠正的做法代价实在太高。前提条件是,不要让用户做你的测试员——如果你这样做,必定会跟黄金法则冲突——宁愿相信所有的bug并非生来平等,有些能影响一个产品的发布,而另一些则不然。不要害怕发布的产品中有bug。如果你开发的是人们想要的好软件,一些bug的存在并不会打搅他们,尤其是当软件升级操作简便时,比如通过SaaS或Web应用。

  如果你的软件测试符合黄金法则,那么,你的客户最迫切得到的是你的软件,而不是希望你去修改那些小bug。所以,准备发布吧!

  哦,别忘了去问那最后一个CEO关于炒股的技巧。经济学家的公文包里总有最好的数据。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-07-30 12:11:29

Bug修复与受益递减法则的相关文章

win10最新版Build 10041发布!包括大量新功能和Bug修复

  微软官方宣布,Windows 10最新测试编译版本Build 10041已经向Fast Ring快速内测用户发放了,包括大量新功能和Bug修复. 该版本仅面向那些已经安装了上一个内测版本的用户,而且只能通过Windows Update在线更新. Slow Ring慢速内测用户需要等待独立的ISO镜像,具体时间待定. 如何获取?首先加入Windows Insider内测项目,然后进入系统设置- 更新与恢复- 高级设置,将预览版安装方式改为"快速"即可. Build 10041属于技术

duilib CDateTimeUI 在Xp下的bug修复

转自:http://my.oschina.net/u/343244/blog/370131 CDateTimeUI 的bug修复.修改CDateTimeWnd的HandleMessage方法 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 if(WM_NOTIFY==uMsg) {  

Swoole 1.8.12 发布,Bug修复版本

PHP的异步.并行.高性能网络通信引擎Swoole 已发布 1.8.12 版本.此版本是一个BUG修复版本,修复了多个细节问题.建议所有用户升级至此版本. 主要更新: 修复Swoole\Table在遍历数据时删除元素导致迭代器错误的问题 增加Swoole\Http\Client新选项websocket_mask控制WebSocket客户端启用mask 修复Swoole\Server在BASE模式下无法使用task_ipc_mode=3配置 优化Swoole\Http\Server响应体gzip压

KDE Frameworks 5.35.0 发布,核心组件 bug 修复

KDE Frameworks 5.35.0 发布了,本次更新为开发人员带来了一系列在 KDE Plasma 5 桌面环境中使用的许多核心组件中的 bug 修复和新功能实现.例如,改进了 Attica 的错误通知,并在 Plasma Framework 中添加了 VLC Media Player 托盘图标支持.KDE Frameworks 5.35.0 中其它值得关注的组件包括:BluezQt,KActivitiesStats,KPeople,KDE Doxygen Tools,KNotifica

Win10 Mobile Build 10586.107正式推送 BUG修复

继欧洲.印尼等地之后,微软今天正式为Lumia 550/950/950 XL推送了Windows 10 Mobile更新,国行用户也已陆续收到. 升级后的系统版本显示为10.0.10586.107,但没有了技术预览版的字样,从这个角度讲应该就是正式版,只是微软并未公开这样的说法. 虽然贵为正式版,但Build 10586.107未带来任何新特性,主要为bug修复,其改进如下: 修复了开始屏幕磁贴丢失问题. 改善旁白功能的多语言支持. 改善企业政策或者用户启用BitLocker/设备加密时的设备重

仿酷狗音乐播放器开发日志十九——CTreeNodeUI的bug修复二(附源码)

转载请说明原出处,谢谢        今天本来打算把仿酷狗播放列表的子控件拖动插入功能做一下,但是仔细使用播放列表控件时发现了几个逻辑错误,由于我的播放 列表控件是基于CTreeViewUI和CTreeNodeUI做得,所以产生这几个bug的原因还在于他们两个,在<仿酷狗音乐播放器开发日志十一 --CTreeNodeUI的bug修复>中已经修复过一个动态添加控件的相关bug,这属于第二次修复了.关于第一次bug的修复,后来 Duilib扩展群的 joe 又进行过比我更全面的修复,我现在使用的C

《大冲锋》隐身BUG修复公告

尊敬的<大冲锋>http://www.aliyun.com/zixun/aggregation/3290.html">玩家: 由于有部分玩家在情人节版本更新过程中出现文件丢失情况,导致这部分玩家的角色装备出现问题,发生角色隐身现象.目前已将此类BUG修复,并对出现隐身BUG的角色进行装备恢复.为此给您带来的不便,我们深表歉意.感谢您对<大冲锋>的鼓励与支持! <大冲锋>运营团队 2012年2月15日 <大冲锋>(FinalCombat,简称F

开发测试工作考核数据之---生产环境bug修复及时率

编写背景: 前段时间有不少猎头来电询问是否考虑换工作,我一一回绝:因为在目前公司要完成的目标目前完成了1个,正在进行中1个,剩余1个还没有开始:其中一个猎头问我为什么来这家公司,主要是因为我的老板懂测试这个工种和工作,非常实实在在的支持和重视测试部门. 非常感谢今年的绩效考核工作,增加了一项考核指标:生产环境bug修复及时率,让我有机会学习和学会如何用这项指标来驱动开发的工作和检查测试工作成果,感谢我的老板给我的工作指导和好的想法,感谢在工作中时常提醒我做重要事情并给我很多工作建议的mac. 今

LOL设计师 德莱文BUG修复中 大圣杯太OP

&http://www.aliyun.com/zixun/aggregation/37954.html">nbsp;       [科技讯]6月20日信息,昨日红帖汇总,包括新版召唤师峡谷改动建议,德莱文bug修复.卢锡安削弱讨论,大圣杯削弱讨论等等. 关于新版召唤师峡谷 设计师Nome在论坛上与大家讨论了召唤峡谷升级的问题......[查看详情]