原文地址： Why bugs don’t get fixed

作者：Alan Page， 微軟卓越測(cè)試工程總監(jiān)，How We Test Software at Microsoft (中文翻譯為《微軟的軟件測(cè)試之道》)一書(shū)的作者之一。

翻譯：盧玥儷、陸夢(mèng)嫣、汪宏

     近來(lái)我遇到越來(lái)越多的人對(duì)我們會(huì)發(fā)布還有bug的產(chǎn)品大為驚訝。而讓我大吃一驚的是，這些人中還有許多是軟件測(cè)試人員，我本以為他們應(yīng)該對(duì)此早已經(jīng)有所了解。建議大家先閱讀Eric Sink較早寫(xiě)的（但是很棒的）文章。不知道我還能對(duì)此話題有多少貢獻(xiàn)，但我想試試。

     許多bug并不值得去修復(fù)。“你這也算是測(cè)試人員嗎？”，你肯定會(huì)沖我大叫，“測(cè)試人員是產(chǎn)品質(zhì)量的捍衛(wèi)者。”我可以再重復(fù)一次（如果需要的話）許多bug并不值得去修復(fù)。“讓我來(lái)告訴你原因。在大多數(shù)情況下，修復(fù)bug就必須要修改代碼。而修改代碼需要投入資源（時(shí)間）并會(huì)引入風(fēng)險(xiǎn)。這真是很糟糕，但這卻是事實(shí)。有時(shí)，如果風(fēng)險(xiǎn)和投入遠(yuǎn)超過(guò)修復(fù)bug的價(jià)值，因此我們就不會(huì)被修復(fù)這些bug。

     我們決定是否修復(fù)一個(gè)bug并不是，也不應(yīng)該是靠“感覺(jué)”。我喜歡用“用戶(hù)痛苦”的概念來(lái)幫助我做決定。我會(huì)用三個(gè)關(guān)鍵因素來(lái)考慮并確定“用戶(hù)痛苦”：

     1、嚴(yán)重性 —— 這個(gè)bug將產(chǎn)生什么影響 —— 它會(huì)讓整個(gè)程序崩潰嗎？它會(huì)導(dǎo)致用戶(hù)的信息丟失嗎？或者并不是那么嚴(yán)重？有更簡(jiǎn)單的解決方法嗎？還是它僅僅是個(gè)無(wú)關(guān)緊要的問(wèn)題？ 

     2、頻繁性 —— 用戶(hù)碰到這個(gè)問(wèn)題的頻率高嗎？它是程序主要工作流程中的一部分？還是隱藏在一個(gè)并不常用的功能中？在最常用的那部分程序中存在的小問(wèn)題很可能是需要修復(fù)的，而一些不常用到的那部分程序中存在的大問(wèn)題，也許我們會(huì)放在一邊。

     3、對(duì)客戶(hù)的影響 ——如果你之前準(zhǔn)備工作做得好，你應(yīng)該已經(jīng)知道你的客戶(hù)是誰(shuí)，你的每個(gè)客戶(hù)群中會(huì)有多少（或者是你希望有多少）用戶(hù)。這樣你就需要判斷，這個(gè)問(wèn)題將會(huì)影響到每位用戶(hù)一，還是僅僅一部分人。如果你能追蹤出客戶(hù)如何使用你的產(chǎn)品，你就能得到更準(zhǔn)確的數(shù)據(jù)。

     以上3點(diǎn)因素就構(gòu)成了一個(gè)公式。給上面的每一個(gè)因素都分配一個(gè)數(shù)值范圍，并且用一些計(jì)算 —— 你可以直接使用加法、乘法或是基于你的應(yīng)用程序以及市場(chǎng)因素加上權(quán)值。打個(gè)比方，我們只需要執(zhí)行加法并且對(duì)每個(gè)bug賦予10分的數(shù)值范圍。

     Bug #1：比如它是一個(gè)會(huì)讓程序崩潰的bug（10分），它存在于程序的主要部分（10分），它影響了80%的客戶(hù)（8分），因此這個(gè)bug的”用戶(hù)痛苦“量值為28分，我們打賭我們肯定會(huì)修復(fù)它。

     Bug #2：它僅僅是一個(gè)關(guān)于排列的bug（2分），它出現(xiàn)在二級(jí)窗口中（2分），這個(gè)bug所在的那部分程序只會(huì)在舊版本中被使用到（2分）。因此這個(gè)bug的“用戶(hù)痛苦” 量值為6分，我們很可能不會(huì)去修復(fù)它了。

     遺憾的是，很多情況并不像上面所說(shuō)的那么簡(jiǎn)單。Bug #3是一個(gè)數(shù)據(jù)丟失問(wèn)題（10分），它存在于一個(gè)應(yīng)用程序的某個(gè)主要部分中，卻只在某些特定的情況下才出錯(cuò)（5分）（順便提一下，數(shù)據(jù)是主觀編造出的）。客戶(hù)研究證明它很少會(huì)被使用（2分）。因此它的 “用戶(hù)痛苦”量值為17分，這是一個(gè)模棱兩可的數(shù)據(jù)，修與不修都可以。一方面，修復(fù)它所需要的投入可能并不值得，只要這個(gè)問(wèn)題能夠被理解，并且它沒(méi)有任何盲點(diǎn)，不再理會(huì)這個(gè)bug很可能是正確的處理方法。

     從另一方面來(lái)看，你必須把它和系統(tǒng)中的其他bug進(jìn)行權(quán)衡。我們?cè)谶@里應(yīng)用“破窗效應(yīng)（Broken Window）”—— 如果應(yīng)用程序中有太多此類(lèi)中等閾值的bug，產(chǎn)品的質(zhì)量（或者最起碼，從質(zhì)量的感覺(jué)上）一定大受影響。你在考慮系統(tǒng)中每一個(gè)bug的時(shí)候，還應(yīng)該結(jié)合考慮系統(tǒng)中其他（已知的）bug，并且以此來(lái)分析、決定哪些bug是需要被修復(fù)的而哪些則不值得被修復(fù)。

     正式發(fā)布的軟件中有bug的確是一件十分糟糕的事 —— 但基于我們現(xiàn)有的開(kāi)發(fā)工具和開(kāi)發(fā)語(yǔ)言，我們還沒(méi)有找到一個(gè)更加合理的解決方法。

補(bǔ)充：

     寫(xiě)出這篇文章的時(shí)候，我想我遺漏了公式中的第四個(gè)因素：發(fā)布日期。臨近發(fā)布日期時(shí)，這個(gè)因素在修復(fù)/不修復(fù)bug的決定中也起了關(guān)鍵作用。然而我并不確定它是否是第四個(gè)因素，也無(wú)法確定在臨近發(fā)布時(shí)期時(shí)，修復(fù)一個(gè)bug所需要的 “用戶(hù)痛苦”量值的閾值是多少。

it知識(shí)庫(kù)：為什么Bugs沒(méi)有被修復(fù)？，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。