Bug剖析

? 所有的Bug報告有以下的基本要求：
? 標(biāo)題。要簡略。
? 指派。誰來處理這個問題。
? 重現(xiàn)步驟。問題再次出現(xiàn)的相關(guān)步驟。
? 優(yōu)先級別。問題的緊迫性與重要性。
? 嚴(yán)重程度。問題所產(chǎn)生的后果。
? 解決方案。怎么解決問題。
其他很多方面對修復(fù)問題及明白其深層次原因也很有幫助，但以上基本準(zhǔn)則簡練得多。下面我們來對每條準(zhǔn)則逐一展開討論，消除這些疑惑。

標(biāo)題及指派

標(biāo)題應(yīng)該簡明扼要，一句話就詳盡說明問題的唯一性，使Bug報告的檢索及標(biāo)識變得簡單。“點擊取消按鈕，屏幕就清空了”是個差勁的標(biāo)題?！瓣P(guān)閉編輯框，清空屏幕”就是個很好的標(biāo)題。后者簡短得多，而且對問題的出處及發(fā)生時間提供了具體的信息。
當(dāng)你要創(chuàng)建一份新的Bug報告時，你必須指定具體人選來解決其中問題。但是，即使你這個團(tuán)隊的每個人都很了解，你也不應(yīng)該將一個Bug指定給其中某一位，除非你是開發(fā)團(tuán)隊的一員。相反，你應(yīng)該將此任務(wù)交給這整個團(tuán)隊。通常的做法是在Bug報告中指定責(zé)任方或團(tuán)隊作為默認(rèn)選擇。默認(rèn)的選擇通常是“主導(dǎo)”或“會診”團(tuán)隊。不會再有更好的了。要相信這些團(tuán)隊，他們會知道問題由誰來解決。
作者注：有些團(tuán)隊希望將所有Bug都指派給團(tuán)隊中的某些個人，這樣可保證沒有Bug被遺漏。但是，他們還是必須確認(rèn)將Bug指派給“主導(dǎo)”或“會診”團(tuán)隊以確保Bug未被遺漏。畢竟，團(tuán)隊外部人員并不知道軟件還有其他什么功能。
作為慣例，所有Bug必須指派給能對其進(jìn)行經(jīng)常性檢查的個人或團(tuán)隊。因為，大多數(shù)優(yōu)先團(tuán)隊會每天開例會，我還是偏好將Bug指定給“主導(dǎo)”或“會診”團(tuán)隊為默認(rèn)選擇。

重現(xiàn)步驟

沒什么比一份Bug報告沒有清晰的重現(xiàn)步驟更讓人郁悶了。就像你的親友對你說：“你知道該怎么辦！”，沒有給你更多解釋。這讓我很茫然，不知道怎么辦。悲催了。
Bug重現(xiàn)步驟應(yīng)是言簡意賅——一言中的。同時要包含軟件創(chuàng)建編號（通常是單獨(dú)列出的），你的工作環(huán)境（操作系統(tǒng)版本、所用瀏覽器及其他相關(guān)的細(xì)節(jié)）以及一些先備條件（像先注冊個Xboxcom金牌賬號等）。
有時你不能確定Bug是怎么發(fā)生的，因為它有時是間歇性的或跟某種特定的狀態(tài)相關(guān)。這種情況下，列出創(chuàng)建編號、運(yùn)行環(huán)境及配置等信息，接著描述下當(dāng)時的情況，以說明具體的Bug重現(xiàn)步驟無法確定。

注：我們有些內(nèi)部工具，如Watson與Autobug，它們可以自動生成Bug報告。誠然，用這些工具生成Bug重現(xiàn)步驟有其局限性，但是它們通常仍可以提供些堆棧跟蹤信息、創(chuàng)建編號、環(huán)境及其他相關(guān)的信息，且它們對隔離問題有幫助。

在簡潔的Bug重現(xiàn)描述后，你必須指出什么是你希望發(fā)生的（“期望”），及事實發(fā)生了什么（“事實”）。所有的重現(xiàn)步驟包括這三方面——配置、期望結(jié)果及實際結(jié)果。這樣當(dāng)別人在看這份Bug報告時就知道到底哪里出錯了及怎么重現(xiàn)它。
通常一張圖、一段視頻頂上千句文字，有很多工具可以對屏幕進(jìn)行圖片及視頻抓取。將這些文件附到Bug報告中，這些文件就是一份能妥善修復(fù)Bug的報告與含糊不清的報告之間的區(qū)別。
作者注：如果一個問題可以用4個步驟講清楚而你在Bug報告里卻用了15個步驟，這是讓人相當(dāng)惱火的。不僅僅是因為4步很簡單，容易理解，而且這樣可以使開發(fā)者及測試者快速找到Bug。重現(xiàn)Bug用的時間越少，在確認(rèn)Bug的原因上所花時間也越少（可能出現(xiàn)Bug的步驟少了），同樣在確認(rèn)Bug已被修復(fù)上所用的時間也越少。

優(yōu)先級別

對于優(yōu)先級別意義的討論一直沒完沒了，這種級別的范圍值通常為0～3。說實在的，你可以把時間更好地用到其他地方去。這里還是說些簡單的準(zhǔn)則，以此為基礎(chǔ)闡明優(yōu)先級別。
? 優(yōu)先級別一旦設(shè)定則不宜再改，除非Bug本身角色變換了。如果級別1意味著：“在目前的沖刺階段或里程碑期間修復(fù)”，級別2意味著：“到下一個沖刺階段或里程碑期間再修復(fù)，”那么在每個沖刺結(jié)束時，你必須更新Bug的優(yōu)先級別，這樣不僅很浪費(fèi)時間，而且改變了Bug的“最后一次變更時間”，這會喪失很多重要信息。
? 優(yōu)先級別必須容易指定并區(qū)分。你不會想讓你的團(tuán)隊花大量的時間爭論每一個Bug的優(yōu)先級別吧。它必須是顯而易見的，不管是在寫B(tài)ug報告或讀Bug報告的時候。
? 優(yōu)先級別必須易記且易操作。人們不需要問：“下一個Pri 2是什么？”，人們也不需要問哪種級別需要做什么。
基于以上三條準(zhǔn)則，一般普遍接受以下優(yōu)先級別的定義。

Pri 0 一個需引起嚴(yán)重關(guān)注的致命錯誤。不存在變通辦法，是一個不可逾越的Bug 只有解決了這個問題或找到了變通辦法，你才能安心 Pri
1 一個需引起嚴(yán)重關(guān)注的致命錯誤 必須在當(dāng)前的沖刺階段或里程碑期間解決 Pri 2 一個嚴(yán)重的錯誤 必須在產(chǎn)品發(fā)布前解決 Pri
3 一般性錯誤或建議 最好在產(chǎn)品發(fā)布前解決 Pri
0通常有礙測試、部署或其他對時間敏感的工作。你必須給開發(fā)者或團(tuán)隊發(fā)郵件并電話告知他們，或者直接過去跟他們談，直到有人解決這個問題。如果有變通辦法，Pri
0就必須改成Pri 1。

注：確實有開發(fā)團(tuán)隊對優(yōu)先級別有非常多的定義。有的從Pri 1開始，而不是Pri 0；有的不遵從我在本章開始時列出的準(zhǔn)則，或者在一個單獨(dú)的區(qū)域提示Bug信息。
如果你查看另一個團(tuán)隊的工作項目數(shù)據(jù)庫，確定你使用的是他們的定義。這些定義通常顯示在工具提示上或幫助窗口中。

嚴(yán)重程度

嚴(yán)重程度比優(yōu)先級別簡單得多，但是它還是經(jīng)常被搞混。嚴(yán)重程度指的是問題所產(chǎn)生的影響范圍，不關(guān)乎“有多么嚴(yán)重”這樣的問題。其定義是：

? 嚴(yán)重程度1。某問題引起系統(tǒng)崩潰或客戶數(shù)據(jù)丟失。
? 嚴(yán)重程度2。某問題引起的故障阻斷了后續(xù)操作。
? 嚴(yán)重程度3。某問題引起操作不便或界面顯示不完整。
注意，嚴(yán)重程度與優(yōu)先級別是相互獨(dú)立的——換句話說，嚴(yán)重程度與優(yōu)先級別毫無關(guān)系。優(yōu)先級別1的Bug比級別2的Bug更重要，不管其嚴(yán)重程度如何。顯示一些不合適的內(nèi)容就是嚴(yán)重程度3但也可能是優(yōu)先級別1；系統(tǒng)崩潰后用戶強(qiáng)行重啟就是嚴(yán)重程度1同時也可能是優(yōu)先級別3。工程師聲稱一個未致系統(tǒng)崩潰的Bug的嚴(yán)重程度是1，因為嚴(yán)重程度很高。你完全沒必要成為他戲弄的笑料。如果你這樣就白癡了。

解決方案

Bug報告中最重要且經(jīng)常被混淆的部分是“解決方案”——說明如何解決問題。解決了一個Bug意味著你不再關(guān)心這個問題。當(dāng)Bug的發(fā)現(xiàn)者確認(rèn)這個方案能修復(fù)這個Bug時，你也不打算再作更多的處理。
在你發(fā)布產(chǎn)品前，如果對一個問題需要做更多的處理，即使這不是你的團(tuán)隊的責(zé)任，那這個Bug還是要引起關(guān)注，并指定你團(tuán)隊里的一個人繼續(xù)跟蹤相關(guān)事宜。

以下是解決方案部分可能包含的內(nèi)容：

? 意圖。Bug報告描述了所需處理的細(xì)節(jié)，按預(yù)先意圖進(jìn)行。
? 重復(fù)。這個Bug與報告中先前指出的Bug有相同的起因及非常相似的用戶體驗。不要像分析一個舊Bug一樣分析新Bug——不管這個新的Bug報告看起來會多精美，除非你想與Bug發(fā)現(xiàn)人為敵并喪失“首先發(fā)現(xiàn)Bug”的機(jī)會。
? 外部性。一個Bug是由你控制能力之外的原因引起的，則你可以在Bug未修復(fù)之前發(fā)布產(chǎn)品。如果你團(tuán)隊之外的人沒有修復(fù)這個問題，使你的產(chǎn)品發(fā)布不了，那么保持對這個Bug的關(guān)注并指定你團(tuán)隊里的某人進(jìn)行跟蹤，找到其他團(tuán)隊中存在的問題。
? 已修復(fù)。Bug修復(fù)了。這是我最喜愛的解決方案。
? 不再發(fā)生。你不能讓Bug在之前說過的創(chuàng)建版本及環(huán)境中再次發(fā)生。聲稱“在我的機(jī)子上運(yùn)行沒什么問題”并不代表Bug解除了——隨時與Bug發(fā)現(xiàn)人保持溝通。
? 延期。你不想在這個版本中修復(fù)Bug。延期是偷懶者的借口，他們總說明天我會寫個測試單元。真正的工程師會時刻關(guān)注這個Bug并會在Bug報告里留出一個“等待修復(fù)”專區(qū)來指出下一個改進(jìn)版本，只要他們真的想修復(fù)這個問題。
? 不修復(fù)。你不再修復(fù)Bug。這是我第二種得意的解決方法——這說明你有豐富的經(jīng)驗判知哪些Bug不需要修復(fù)。通常是因為修復(fù)本身會帶來比Bug更多的問題。
當(dāng)你在解決一個Bug時，你必須在解決方案中有段描述。這段描述是很重要的。這樣可使解決方案少些爭論，Bug重現(xiàn)時就更易理解，使你與你的公司免于因為這個問題成了公眾熱議的話題。這在我之前的一個團(tuán)隊中曾發(fā)生過——我們使這個公司免于千夫所指，因為我們的解決方案中對一個出現(xiàn)不合適內(nèi)容的Bug作了描述，以說明我們并非蓄意而為。

當(dāng)一個Bug被解決，它將被自行指派給發(fā)現(xiàn)它的人。如果這個人不是開發(fā)團(tuán)隊的人員，那這個Bug必須指定給另一個團(tuán)隊中的人，這個人可以跟Bug發(fā)現(xiàn)者核實解決方案。但你不能總是指望團(tuán)隊外部的人能及時周到地確認(rèn)解決方案。當(dāng)然，如果這個解決方案不怎么令人滿意，那么這個Bug應(yīng)被重新激活。

過猶不及

Bug報告中還有很多其他區(qū)域。我說過用“創(chuàng)建”及“環(huán)境”兩個區(qū)域記錄Bug相關(guān)信息以及用“等待修復(fù)”區(qū)域來說明什么時候處理Bug。還有一些區(qū)域用來跟蹤記錄底層原因，這個Bug是怎么被發(fā)現(xiàn)的，Bug是在產(chǎn)品或服務(wù)的哪個方面發(fā)生的，潛在的安全威脅以及其他信息。

設(shè)定好Bug報告的必要條件，少則缺，多則無益。要求太多人們會怨聲四起而拒絕完成Bug報告——兩種極端都會對你及你的客戶不利。

Bug報告要易寫且易讀，這樣會促使他們在發(fā)現(xiàn)問題的時候制定清晰的Bug報告。使用一些Bug模板對于一些內(nèi)容的編寫是很有幫助的。對于我們在乎的工程師及客戶來說，規(guī)范的Bug報告使一個問題在用戶發(fā)現(xiàn)前消滅于萌芽狀態(tài)，沒有比這更好的禮物了。