典型的測試錯誤有哪些？(16)

　　1. They do not describe how to reproduce the bug. Either no procedure is given, or the given procedure doesn't work. Either case will likely get the bug report shelved.

　　他們沒有描述如何重現 bug 。要么沒有描述過程，要么描述的過程不正確。這兩種情況都會使錯誤報告被擱置。

　　2. They don't explain what went wrong. At what point in the procedure does the bug occur? What should happen there? What actually happened?

　　他們沒有解釋出了什么問題。在什么地方出現了 bug ?將會發生什么?實際上又發生了什么?

　　3. They are not persuasive about the priority of the bug. Your job is to have the seriousness of the bug accurately assessed. There's a natural tendency for programmers and managers to rate bugs as less serious than they are. If you believe a bug is serious, explain why a customer would view it the way you do. If you found the bug with an odd case, take the time to reproduce it with a more obviously common or compelling case.

　　4. 關于 bug 的級別沒有說服力。你的工作是評估 bug 的嚴重性。對于程序員和經理有一種很自然的傾向：評估的嚴重性比實際的嚴重性低。如果你確信一個 bug 是嚴重的，要解釋一下為什么客戶要以你的方式看待這個問題。如果你發現一個奇怪的錯誤，花一些時間以更普通、更令人信服的方式重現它。

　　5. They do not help the programmer in debugging. This is a simple cost/benefit tradeoff. A small amount of time spent simplifying the procedure for reproducing the bug or exploring the various ways it could occur may save a great deal of programmer time.

　　他們不能幫助程序員排除 bug 。這是一個簡單的成本/收益權衡?；ㄒ稽c時間簡化重現 bug 的過程或探索一下各種發生它的方法可以節約程序員大量的時間。

　　6. They are insulting, so they poison the relationship between developers and testers.

　　它們是侮辱性的，破壞了開發人員和測試人員的關系。

　　[Kaner93] has an excellent chapter (5) on how to write bug reports. Read it.

　　[Kaner93]有一章(第5章)非常好的內容說明了應該如何寫 bug 報告?？梢宰x一下。

　　Not all bug reports come from testers. Some come from customers. When that happens, it's common for a tester to write a regression test that reproduces the bug in the broken version of the product. When the bug is fixed, that test is used to check that it was fixed correctly.

　　不是所有的 bug 報告都是測試員寫的。有一些是來自客戶的。如果出現這樣的情況，常見情況是測試員編寫一個回歸測試，在產品出現問題的版本上重現這個 bug 。如果 bug 得到修復，這個測試可以用于檢查它是否正確修復。

　　However, adding only regression tests is not enough. A customer bug report suggests two things:

　　但是，僅僅添加回歸測試是不夠的?？蛻?bug 報告暗示著兩個東西：

　　1. That area of the product is buggy. It's well known that bugs tend to cluster.

　　產品的那個領域包含了 bug。大家都知道， bug 一般是集中出現的。

　　2. That area of the product was inadequately tested. Otherwise, why did the bug originally escape testing?

　　產品的那個領域沒有進行充分測試。否則的話，為什么開始測試的時候漏掉了那個 bug ?

　　An appropriate response to several customer bug reports in an area is to schedule more thorough testing for that area. Begin by examining the current tests (if they're understandable) to determine their systematic weaknesses.

　　對于某個領域中的幾個客戶 bug 報告的適當響應是對該領域安排一個更全面的測試。首先檢查當前測試(如果它們是可以理解的話)以確定在系統性方面的不足之處。

　　Finally, every bug report is a gift from a customer that tells you how to test better in the future. A common mistake is failing to take notes for the next testing effort. The next product will be somewhat like this one, the bugs will be somewhat like these, and the tests useful in finding those bugs will also be somewhat like the ones you just ran. Mental notes are easy to forget, and they're hard to hand to a new tester. Writing is a wonderful human invention: use it. Both [Kaner93] and [Marick95] describe formats for archiving test information, and both contain general-purpose examples.

　　總之，每個 bug 報告都是客戶的禮物，告訴我們在今后如何更好地測試。一個常見錯誤是不能為下次測試工作做好記錄。下一個產品將在某種程度上類似于這一個， bug 在某種程度上類似于這一個，你剛才所做的測試在某種程度上類似于將來找出那些錯誤的測試。腦海中的記錄容易忘記，也很難傳授給新測試員。書寫是人類一個美妙的發明：使用它。[Kaner93]和[Marick95]都描述了歸檔測試信息的格式，并包含了通用的示例。

原文轉自：http://www.uml.org.cn/Test/200709289.asp