腳踏實地，希望我自己也能夠這樣努力下去。
·盡量減少重現的步驟以達到用最少的步驟來重現問題；這對編程人員來說是很有幫助發現問題根源的。
·最好由報bug的人驗證bug是否可以關閉。任何人都可以修復bug，但只有那個發現bug的人才能夠確信bug是否真正的已被修復。
·在將bug解決時要分清楚解決的方式。一般的bug系統允許你通過例如“fixed(已修復)”, “won't fix (不打算修復)”, “postponed(以后修復)”, “not repro(不可重現)”, “duplicate（重復）”或“by design(設計如此)”方式來解決bug。同時最好寫上解決的方式或非正常解決問題（如以上幾種類型）的原因。
·當你的bug報告以“not repro(不可重現)”打回給你時，先檢查一個步驟是否有遺漏或清晰，再去找編程人員。編程人員通常是在無法用bug報告中的步驟重現bug時才選擇這個選項。
·仔細地追蹤版本信息。你給測試人員的每一個build都應該有一個build ID編號，這樣剛入門的測試人員就不會重新測試壓根就沒有修復的那個版本。
·如果你是個編程人員，并且正陷入讓測試人員使用bug管理庫的苦惱中，你只要不用其他方法接受bug報告。如果你的測試人員習慣將bug報告用郵件的形式發給你，你只需用一個簡短的消息回復他們：“請將它們輸入到bug庫中，因為我無法追蹤郵件�！�
·如果你是一個測試人員，并且正陷入讓測試人員使用bug管理庫的苦惱中，你只要不和他們說任何有關bug的事――將bug輸入到數據庫中，數據庫會自動發送email給他們。
·不要添加太多的新字段。有些人喜歡添加一些新的字段來追蹤他所需的信息。試想一下，測試人員要花多長的時間去填寫一個幾十個字段的表單，而且又有多少人還愿意填寫下一個bug呢。
·如果知道bug出現模塊的負責人員或將解決bug的開發人員，請在標題中明確的指出，例如你發現的bug是有關增加人員的，那么在標題中可以指出“增加人員時出現xx錯誤”。
·如果用英文報bug，最好使用現在時或過去時，例如用"appears"而不是"will appear"。
·不要使用完全的大寫形式，那樣會讓人感覺象控訴。不要使用感嘆號或其他表現個人感情色彩的詞語或符號。
·不要使用含糊的詞語（例如，好像，似乎）來描述發現的現象。
·請考慮如下問題：
1.同一軟件中的相似功能是否有相同的問題？
2.其他的瀏覽器是否有相同的問題？
3.其他的軟硬件配置是否有相同的問題？
4.其他的區域（locales）是否有相同的問題？
5.不同的安排設置是否有相同的問題？
6.以前的版本否有相同的問題？
·編寫bug report沒有什么定式，沒有絕對的范本，最基本的是能夠讓客戶或目標修改，瀏覽bug report人員看懂，而且在短時間內，而不需反復思考的。其他有時要考慮目標讀者的一些喜歡。例如有些類似的bug到底是合并還是單獨提交，bug的步驟劃分（到底是每一步都為一點，還是有些點可以合并）。在這一點上我覺得“靈活和適應”是很關鍵的。
·在發現一個Bug并填寫完bug report之后，在review的時候，需要特別注意的一點是：這個bug report會不會讓其他人還有聯想或發揮的空間。一個好的bug report是不可以細分的, 換句話說就是這個bug是不會讓他人覺得你還有些地方需要在測試一下，或許還有其他的問題。例如，有個測試人員發現在輸入16這個數字（允許范圍內）且提交時系統會返回一個錯誤：不能輸入48以下的數字。這確實是一個錯誤，但是如果就只按現在的步驟提交，另一個可能會有這樣的想法：是不是輸入48以下的數字都會有這樣的問題呢？這樣他有可能要求你在測試其他的數據。這樣就延長了這個bug的生命期，而且浪費了大家的時間。
文章來源于領測軟件測試網 http://www.kjueaiud.com/