典型的测试错误有哪些？(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 。这是一个简单的成本/收益权衡。花一点时间简化重现 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 报告。可以读一下。

　　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