近來我遇到越來越多的人對我們會發(fā)布還有
bug的產(chǎn)品大為驚訝。而讓我大吃一驚的是，這些人中還有許多是
軟件測試人員，我本以為他們應(yīng)該對此早已經(jīng)有所了解。建議大家先閱讀Eric Sink較早寫的(但是很棒的)
文章。不知道我還能對此話題有多少貢獻(xiàn)，但我想試試。
許多bug并不值得去修復(fù)。“你這也算是測試人員嗎?”，你肯定會沖我大叫，“測試人員是產(chǎn)品質(zhì)量的捍衛(wèi)者。”我可以再重復(fù)一次(如果需要的話)許多bug并不值得去修復(fù)。“讓我來告訴你原因。在大多數(shù)情況下，修復(fù)bug就必須要修改代碼。而修改代碼需要投入資源(時間)并會引入風(fēng)險。這真是很糟糕，但這卻是事實。有時，如果風(fēng)險和投入遠(yuǎn)超過修復(fù)bug的價值，因此我們就不會被修復(fù)這些bug。
我們決定是否修復(fù)一個bug并不是，也不應(yīng)該是靠“感覺”。我喜歡用“用戶痛苦”的概念來幫助我做決定。我會用三個關(guān)鍵因素來考慮并確定“用戶痛苦”：
1、嚴(yán)重性—— 這個bug將產(chǎn)生什么影響 —— 它會讓整個程序崩潰嗎?它會導(dǎo)致用戶的信息丟失嗎?或者并不是那么嚴(yán)重?有更簡單的解決方法嗎?還是它僅僅是個無關(guān)緊要的問題?
2、頻繁性—— 用戶碰到這個問題的頻率高嗎?它是程序主要
工作流程中的一部分?還是隱藏在一個并不常用的功能中?在最常用的那部分程序中存在的小問題很可能是需要修復(fù)的，而一些不常用到的那部分程序中存在的大問題，也許我們會放在一邊。
3、對客戶的影響——如果你之前準(zhǔn)備工作做得好，你應(yīng)該已經(jīng)知道你的客戶是誰，你的每個客戶群中會有多少(或者是你希望有多少)用戶。這樣你就需要判斷，這個問題將會影響到每位用戶一，還是僅僅一部分人。如果你能追蹤出客戶如何使用你的產(chǎn)品，你就能得到更準(zhǔn)確的數(shù)據(jù)。
以上3點因素就構(gòu)成了一個公式。給上面的每一個因素都分配一個數(shù)值范圍，并且用一些計算 —— 你可以直接使用加法、乘法或是基于你的應(yīng)用程序以及市場因素加上權(quán)值。打個比方，我們只需要執(zhí)行加法并且對每個bug賦予10分的數(shù)值范圍。
Bug #1：比如它是一個會讓程序崩潰的bug(10分)，它存在于程序的主要部分(10分)，它影響了80%的客戶(8分)，因此這個bug的”用戶痛苦“量值為28分，我們打賭我們肯定會修復(fù)它。
Bug #2：它僅僅是一個關(guān)于排列的bug(2分)，它出現(xiàn)在二級窗口中(2分)，這個bug所在的那部分程序只會在舊版本中被使用到(2分)。因此這個bug的“用戶痛苦” 量值為6分，我們很可能不會去修復(fù)它了。
遺憾的是，很多情況并不像上面所說的那么簡單。Bug #3是一個數(shù)據(jù)丟失問題(10分)，它存在于一個應(yīng)用程序的某個主要部分中，卻只在某些特定的情況下才出錯(5分)(順便提一下，數(shù)據(jù)是主觀編造出的)。客戶研究證明它很少會被使用(2分)。因此它的 “用戶痛苦”量值為17分，這是一個模棱兩可的數(shù)據(jù)，修與不修都可以。一方面，修復(fù)它所需要的投入可能并不值得，只要這個問題能夠被理解，并且它沒有任何盲點，不再理會這個bug很可能是正確的處理方法。
從另一方面來看，你必須把它和系統(tǒng)中的其他bug進(jìn)行權(quán)衡。我們在這里應(yīng)用“破窗效應(yīng)(Broken Window)”—— 如果應(yīng)用程序中有太多此類中等閾值的bug，產(chǎn)品的質(zhì)量(或者最起碼，從質(zhì)量的感覺上)一定大受影響。你在考慮系統(tǒng)中每一個bug的時候，還應(yīng)該結(jié)合考慮系統(tǒng)中其他(已知的)bug，并且以此來分析、決定哪些bug是需要被修復(fù)的而哪些則不值得被修復(fù)。
正式發(fā)布的軟件中有bug的確是一件十分糟糕的事 —— 但基于我們現(xiàn)有的開發(fā)工具和開發(fā)語言，我們還沒有找到一個更加合理的解決方法。
補充：
寫出這篇文章的時候，我想我遺漏了公式中的第四個因素：發(fā)布日期。臨近發(fā)布日期時，這個因素在修復(fù)/不修復(fù)bug的決定中也起了關(guān)鍵作用。然而我并不確定它是否是第四個因素，也無法確定在臨近發(fā)布時期時，修復(fù)一個bug所需要的 “用戶痛苦”量值的閾值是多少。