結果：崩潰
馬虎的（有很大空間讓人產(chǎn)生誤解的）：
使數(shù)據(jù)庫服務器脫機，保存，然后退出，崩潰了。
太多冗余的信息（不能夠指出什么是引發(fā)錯誤的關鍵原因）
1．運行客戶端
2．為輸入新的條目查詢數(shù)據(jù)庫
3．打開一個瀏覽器
4．在yahoo.com上瀏覽新聞
5．關閉瀏覽器
6．選擇一個條目
7．把種類從“蔬菜” 更改到“水果”
8．使數(shù)據(jù)庫服務器脫機
9．嘗試保存記錄
10．收到一個超時的錯誤
11．退出客戶端
結果：崩潰
在這個例子中，測試人員記錄在發(fā)現(xiàn)錯誤之前他所作的一切，但是他沒有檢查是不是每個步驟都是必要的，例如從yahoo.com閱讀新聞。
如果你只寫下那些產(chǎn)生錯誤必不可少的步驟，開發(fā)人員將很少告訴你他們不能夠重現(xiàn)錯誤，同樣錯誤什么委員會也會很少決定“沒有人將會做到那個程度！”
但是如果每個步驟都是必須的，怎么辦呢？如果錯誤只在你執(zhí)行了一些看上去沒有關系的步驟后出現(xiàn)了，那么在bug report中記錄下這些步驟。你可以在那些看上去沒有邏輯關系的步驟后寫上“必須的步驟”，或者你可以在bug report的開始部分加上注釋：“注意－這里的每一個步驟都是重現(xiàn)錯誤的必要步驟。
編寫清晰的步驟同樣可以在驗證修復過程中提供幫助，特別是在另一個測試人員做驗證的時候。
解釋錯誤的影響，不只是癥狀
一些bug report是令人誤解的。從錯誤的表層看是無傷大雅的，但是如果在你檢查錯誤的牽連時，你發(fā)現(xiàn)它是一個非常嚴重的問題。如果你在錯誤審核委員會，你會擁護先修改哪一個錯誤呢？
1．關于“一個令人討厭的對話框阻止關閉應用程序”的報告
2．關于“在退出時應用程序中止了” 的報告
