關鍵字：Bug追蹤
很多朋友都問我，為什么那么喜歡研究bug報告，其實個人一直覺得bug報告高于一切，它是測試人員價值的體現(xiàn)。也許是工作的性質，我經(jīng)常將香港的同事和深圳同事做比較，發(fā)現(xiàn)他們一個優(yōu)點特別值得我們學習：做什么事一般不會去衡量事情的終利益，更多的是決定后考慮如何更好地把事情做好。
    腳踏實地，希望我自己也能夠這樣努力下去。 

·盡量減少重現(xiàn)的步驟以達到用少的步驟來重現(xiàn)問題；這對編程人員來說是很有幫助發(fā)現(xiàn)問題根源的。

·好由報bug的人驗證bug是否可以關閉。任何人都可以修復bug，但只有那個發(fā)現(xiàn)bug的人才能夠確信bug是否真正的已被修復。

·在將bug解決時要分清楚解決的方式。一般的bug系統(tǒng)允許你通過例如“fixed(已修復)”， “won’t fix (不打算修復)”， “postponed(以后修復)”， “not repro(不可重現(xiàn))”， “duplicate（重復）”或“by design(設計如此)”方式來解決bug。同時好寫上解決的方式或非正常解決問題（如以上幾種類型）的原因。

·當你的bug報告以“not repro(不可重現(xiàn))”打回給你時，先檢查一個步驟是否有遺漏或清晰，再去找編程人員。編程人員通常是在無法用bug報告中的步驟重現(xiàn)bug時才選擇這個選項。

·仔細地追蹤版本信息。你給測試人員的每一個build都應該有一個build ID編號，這樣剛入門的測試人員不會重新測試壓根沒有修復的那個版本。

·如果你是個編程人員，并且正陷入讓測試人員使用bug管理庫的苦惱中，你只要不用其他方法接受bug報告。如果你的測試人員習慣將bug報告用郵件的形式發(fā)給你，你只需用一個簡短的消息回復他們：“請將它們輸入到bug庫中，因為我無法追蹤郵件。”

·如果你是一個測試人員，并且正陷入讓測試人員使用bug管理庫的苦惱中，你只要不和他們說任何有關bug的事――將bug輸入到數(shù)據(jù)庫中，數(shù)據(jù)庫會自動發(fā)送email給他們。

·不要添加太多的新字段。有些人喜歡添加一些新的字段來追蹤他所需的信息。試想一下，測試人員要花多長的時間去填寫一個幾十個字段的表單，而且又有多少人還愿意填寫下一個bug呢。

·如果知道bug出現(xiàn)模塊的負責人員或將解決bug的開發(fā)人員，請在標題中明確的指出，例如你發(fā)現(xiàn)的bug是有關增加人員的，那么在標題中可以指出“增加人員時出現(xiàn)xx錯誤”。

·如果用英文報bug，好使用現(xiàn)在時或過去時，例如用"appears"而不是"will appear"。

·不要使用完全的大寫形式，那樣會讓人感覺象控訴。不要使用感嘆號或其他表現(xiàn)個人感情色彩的詞語或符號。

·不要使用含糊的詞語（例如，好像，似乎）來描述發(fā)現(xiàn)的現(xiàn)象。

·請考慮如下問題：
1.同一軟件中的相似功能是否有相同的問題？
2.其他的瀏覽器是否有相同的問題？
3.其他的軟硬件配置是否有相同的問題？
4.其他的區(qū)域（locales）是否有相同的問題？
5.不同的安排設置是否有相同的問題？
6.以前的版本否有相同的問題？

·編寫bug report沒有什么定式，沒有的范本，基本的是能夠讓客戶或目標修改，瀏覽bug report人員看懂，而且在短時間內，而不需反復思考的。其他有時要考慮目標讀者的一些喜歡。例如有些類似的bug到底是合并還是單獨提交，bug的步驟劃分（到底是每一步都為一點，還是有些點可以合并）。在這一點上我覺得“靈活和適應”是很關鍵的。

·在發(fā)現(xiàn)一個Bug并填寫完bug report之后，在review的時候，需要特別注意的一點是：這個bug report會不會讓其他人還有聯(lián)想或發(fā)揮的空間。一個好的bug report是不可以細分的，  換句話說是這個bug是不會讓他人覺得你還有些地方需要在測試一下，或許還有其他的問題。例如，有個測試人員發(fā)現(xiàn)在輸入16這個數(shù)字（允許范圍內）且提交時系統(tǒng)會返回一個錯誤：不能輸入48以下的數(shù)字。這確實是一個錯誤，但是如果只按現(xiàn)在的步驟提交，另一個可能會有這樣的想法：是不是輸入48以下的數(shù)字都會有這樣的問題呢？這樣他有可能要求你在測試其他的數(shù)據(jù)。這樣延長了這個bug的生命期，而且浪費了大家的時間。