bug值与不值修复（转载51testing）

许多bug并不值得去修复。“你这也算是测试人员吗？”，你肯定会冲我大叫，“测试人员是产品质量的捍卫者。”我可以再重复一次（如果需要的话）许多bug并不值得去修复。“让我来告诉你原因。在大多数情况下，修复bug就必须要修改代码。而修改代码需要投入资源（时间）并会引入风险。这真是很糟糕，但这却是事实。有时，如果风险和投入远超过修复bug的价值，因此我们就不会被修复这些bug。

2]I,s4`q8nv1f`0　　我们决定是否修复一个bug并不是，也不应该是靠“感觉”。我喜欢用“用户痛苦”的概念来帮助我做决定。我会用三个关键因素来考虑并确定“用户痛苦”：51Testing软件测试网q8nU?$i2M&UpAgF

51Testing软件测试网Qb#z&w"n,v#r
D

　　1、严重性—— 这个bug将产生什么影响 —— 它会让整个程序崩溃吗？它会导致用户的信息丢失吗？或者并不是那么严重？有更简单的解决方法吗？还是它仅仅是个无关紧要的问题？51Testing软件测试网C1Mc
X0w0Af

3X&e0W?6X0　　2、频繁性—— 用户碰到这个问题的频率高吗？它是程序主要工作流程中的一部分？还是隐藏在一个并不常用的功能中？在最常用的那部分程序中存在的小问题很可能是需要修复的，而一些不常用到的那部分程序中存在的大问题，也许我们会放在一边。

-['y7sO(b BK051Testing软件测试网{S] SYJ'Q
J

　　3、对客户的影响——如果你之前准备工作做得好，你应该已经知道你的客户是谁，你的每个客户群中会有多少（或者是你希望有多少）用户。这样你就需要判断，这个问题将会影响到每位用户一，还是仅仅一部分人。如果你能追踪出客户如何使用你的产品，你就能得到更准确的数据。

jSS\J/S1qyL051Testing软件测试网#?6D3l f\

　　以上3点因素就构成了一个公式。给上面的每一个因素都分配一个数值范围，并且用一些计算 —— 你可以直接使用加法、乘法或是基于你的应用程序以及市场因素加上权值。打个比方，我们只需要执行加法并且对每个bug赋予10分的数值范围。

W;k&~/W6g051Testing软件测试网2C-WR&G4ee:a s

　　Bug #1：比如它是一个会让程序崩溃的bug（10分），它存在于程序的主要部分（10分），它影响了80%的客户（8分），因此这个bug的”用户痛苦“量值为28分，我们打赌我们肯定会修复它。51Testing软件测试网S0BQ:JD;S,H1Cg

51Testing软件测试网1\-xr%Z.y

　　Bug #2：它仅仅是一个关于排列的bug（2分），它出现在二级窗口中（2分），这个bug所在的那部分程序只会在旧版本中被使用到（2分）。因此这个bug的“用户痛苦” 量值为6分，我们很可能不会去修复它了。

Q v'p*_;|wl P!IS0

!_TXV6m5C9a.K0　　遗憾的是，很多情况并不像上面所说的那么简单。Bug #3是一个数据丢失问题（10分），它存在于一个应用程序的某个主要部分中，却只在某些特定的情况下才出错（5分）（顺便提一下，数据是主观编造出的）。客户研究证明它很少会被使用（2分）。因此它的 “用户痛苦”量值为17分，这是一个模棱两可的数据，修与不修都可以。一方面，修复它所需要的投入可能并不值得，只要这个问题能够被理解，并且它没有任何盲点，不再理会这个bug很可能是正确的处理方法。

,wb/Dm
}t"N S"B,lY051Testing软件测试网 Ly~9t"_2D.g?RQ

　　从另一方面来看，你必须把它和系统中的其他bug进行权衡。我们在这里应用“破窗效应（Broken Window）”—— 如果应用程序中有太多此类中等阈值的bug，产品的质量（或者最起码，从质量的感觉上）一定大受影响。你在考虑系统中每一个bug的时候，还应该结合考虑系统中其他（已知的）bug，并且以此来分析、决定哪些bug是需要被修复的而哪些则不值得被修复。

3D)K
Es0{1Rq051Testing软件测试网(q,rQ.cc e*Uo

　　正式发布的软件中有bug的确是一件十分糟糕的事 —— 但基于我们现有的开发工具和开发语言，我们还没有找到一个更加合理的解决方法。51Testing软件测试网yL;Dk^&aX:T

'}T7g{4{^v0　　补充：51Testing软件测试网"b
kcd-^EBS m

r%u#I gWV
T7s0　　写出这篇文章的时候，我想我遗漏了公式中的第四个因素：发布日期。临近发布日期时，这个因素在修复/不修复bug的决定中也起了关键作用。然而我并不确定它是否是第四个因素，也无法确定在临近发布时期时，修复一个bug所需要的 “用户痛苦”量值的阈值是多少。

kgHXI2a0