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

　　Using coverage as a test design technique works only when the testers are both designing poor tests and testing redundantly. They'd be better off at least targeting their poor tests at new areas of code. In more normal situations, coverage as a guide to design only decreases the value of the tests or puts testers under unproductive pressure to meet unhelpful goals.

　　僅當測試員設計了的測試質量不高并且冗余地進行測試時，將測試度作為測試設計技巧才能起作用。至少可以讓他們將這些把這些質量不高的測試轉移到新的領域中。在正式的場合，覆蓋率作為一個設計的指導只會減少測試的價值，或將測試員置于低效率的壓力下，以達到沒有用處的目標。

　　Coverage does play a role in testing, not as a guide to test design, but as a rough evaluation of it. After you've run your tests, ask what their coverage is. If certain areas of the code have no or low coverage, you're sure to have tested them shallowly. If that wasn't intentional, you should improve the tests by rethinking their design. Coverage has told you where your tests are weak, but it's up to you to understand how.

　　覆蓋率在測試中確實能起作用，但不是作為測試設計的指導，而是作為一個大致的評估。在運行完測試后，看一下它們的覆蓋率是多少。如果某個領域的代碼沒有覆蓋到或覆蓋率很低，可以確定你對它們的測試很膚淺。如果不是故意那樣做的，你應該考慮重新設計它們以改進測試。覆蓋率告訴你測試的哪個部分是薄弱的，但如何理解則取決于你。

　　You might not entirely ignore coverage. You might glance at the uncovered lines of code (possibly assisted by the programmer) to discover the kinds of tests you omitted. For example, you might scan the code to determine that you undertested a dialog box's error handling. Having done that, you step back and think of all the user errors the dialog box should handle, not how to provoke the error checks on line 343, 354, and 399. By rethinking design, you'll not only execute those lines, you might also discover that several other error checks are entirely missing. (Coverage can't tell you how well you would have exercised needed code that was left out of the program.)

　　你也不能完全忽略覆蓋率。你可以瀏覽未覆蓋的代碼行(可能是在程序員的輔助下)以發現你忽略的某種測試。例如，你可能瀏覽代碼以確定你是否對某個對話框的錯誤處理測試不足。在完成這些之后，你翻回頭應該考慮對話框應該處理的所有用戶錯誤，而不是檢查第343、354和399行的錯誤。通過重新思考設計，你不僅能執行那些行，而且可能會發現幾個其他完全被忽略了錯誤。(覆蓋率不能告訴你程序之外的、所需要代碼的執行情況)。

　　There are types of coverage that point more directly to design mistakes than statement coverage does (branch coverage, for example). However, none - and not all of them put together - are so accurate that they can be used as test design techniques.

　　還有幾類覆蓋率，比語句覆蓋率更直接地指向設計錯誤(例如分支覆蓋率)。但是，其他種類——即使把他們都放在一起——也不能夠精確到用于測試用例設計技巧。

　　One final note: Romances with coverage don't seem to end with the former devotee wanting to be "just good friends". When, at the end of a year's use of coverage, it has not solved the testing problem, I find testing groups abandoning coverage entirely. That's a shame. When I test, I spend somewhat less than 5% of my time looking at coverage results, rethinking my test design, and writing some new tests to correct my mistakes. It's time well spent.

　　最后再說明一下：對覆蓋率的興趣似乎不能以從前的愛好者希望成為“好朋友”而結束。在使用了一年的覆蓋率之后，它沒有解決測試問題，我發現測試小組完全放棄了覆蓋率。這是一件丟人的事情。當我測試的時候，我花大約5%的時間查看覆蓋率結果，重新考慮我的測試用例設計，并編寫一些新的測試用例校正我的錯誤。這個時間是值得花的。

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