關鍵字：bug report

你有沒有為了要更多的信息而被返回bug report的經(jīng)歷呢？有沒有碰到過你發(fā)現(xiàn)的一個非常嚴重的錯誤被推遲到下一個版本才去修復的情況呢？

你提交的每一個bug report都是和項目組正在測試中的軟件質(zhì)量問題的一種書面溝通方式。通常，你用于溝通程序錯誤的能力－不是體現(xiàn)在錯誤本身的內(nèi)在嚴重程度－而是體現(xiàn)在確定這個錯誤是否需要修復。

如果這是一個可怕的想法，你可能會想，“等等！我討厭寫作，我并不擅長寫作。怎么樣才能夠通過編寫bug report來決定錯誤的命運呢？”它要吸引大家相信錯誤是為他們說話的－任何一個頭腦正常的人都應該主動地查看一個特定的錯誤是足夠可怕的以致要被修復。不幸的是，事實并不是這樣。

但是好消息是：有效的和軟件開發(fā)人員、項目組溝通的能力不是由你在高校英語課程中的表現(xiàn)所決定的。

這不是關于用有趣的詞語編寫流暢散文，也不是關于語法和拼寫的方法。它是有關僅用能夠表達你觀點的詞語明白地表述錯誤的方法。太多地話將會使你的觀點陷入茫然無措中。太少地話又會使他人用自己的假設去填補隔閡－通常是對軟件有害的部分。如果你不是很確信是什么樣的錯誤，那么不管你的bug report寫得怎么好，也沒有人知道那是什么樣的錯誤。

這篇文章主要討論你現(xiàn)在能夠開始著手提高人們傾聽你發(fā)現(xiàn)的錯誤的機會的4個方法。

了解你的聽眾
毋庸置疑，任何寫作課都會告訴你必須了解你是為誰編寫bug report。

每份bug report至少有兩個聽眾：必須要修復錯誤的人和決定錯誤命運的人或團體。有時一個人會同時負責這兩份工作，但是仍然是兩個不同的聽眾，只是一起發(fā)生在同一個人身上罷了。

你的第一個聽眾－那個必須修復錯誤的人需要清楚，明確的步驟以重現(xiàn)錯誤。信息越多越好。針對這個目的，我們稱這個人為“開發(fā)人員”。開發(fā)人員需要關于我們操作了什么和我們看見了什么的準確信息。

你的第二個聽眾－決定錯誤命運的人或團體需要知道如果不修復此錯誤的后果。這個聽眾需要精練的語句以抓住他們的注意力并且引發(fā)對錯誤的相關連問題的討論。基于這個目的，我們稱他為“錯誤審核委員會”。在使錯誤得以修復的過程中你的角色是幫助錯誤審核委員會了解不修復錯誤的風險遠遠超過修復錯誤可能發(fā)生的風險。

你越了解你的開發(fā)人員和錯誤審核委員會如何工作，你越可以根據(jù)他們的需要裁減你的bug report。盡力在私底下設法了解你的聽眾。如果你能夠出席錯誤審核委員會會議，嘗試這樣做。你將學習到許多關于你的聽眾是如何思考的知識。

選擇一個好的標題
一般把用于描述錯誤的短句稱為錯誤的標題或描述。這是bug report中重要的部分。錯誤審核委員會成員經(jīng)常通過它來決定錯誤是否可以推遲修復。如果標題沒有力度，委員會成員可能認為它是不值得花費太多的時間。（畢竟，在接下來的2個小時里還有145個以上的錯誤要審核。）

以下是一些示例：

好的：超時后在退出時崩潰了

太長的：在數(shù)據(jù)庫不可用后你又保存記錄的更改，然后從文件菜單中選擇退出時程序崩潰了

不足夠的信息：程序崩潰了

太模糊：當數(shù)據(jù)庫離線時出現(xiàn)問題

標題變成了一種給項目組提供檢查和調(diào)查錯誤的方法。和數(shù)據(jù)相比，人們更容易記詞語。人們更愿意記得“在windows2000下不能夠安裝”的錯誤，而不是類似“＃23423”錯誤，而且在以后人們還會利用這些關鍵詞搜索錯誤。

編寫一個好的，簡明的錯誤標題是不容易的。和編寫bug report的其他部分相比，應該多花些時間構(gòu)造理想的錯誤標題。要確信標題是足夠短以便能夠在顯示錯誤的屏幕上和由缺陷跟蹤系統(tǒng)生成的報表中顯示完全（不會折行）。標題不必是完美的語法，而應簡短并一針見血。

書寫清楚，明確的步驟
你提交給開發(fā)人員的步驟應該提供如何產(chǎn)生錯誤的信息，這樣錯誤能夠被發(fā)現(xiàn)并且修復。它也需要給錯誤審核委員會提供錯誤發(fā)生的環(huán)境。

正確：

1．運行客戶端

2．找出一個記錄

3．更改記錄但不存盤

4．使數(shù)據(jù)庫服務器脫機

5．嘗試保存記錄

6．收到一個超時的錯誤

7．退出客戶端