典型的测试错误有哪些？(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