It is often difficult to convince programmers to add test support code to the product. (Actual quote: \"I don\'t want to clutter up my code with testing crud.\") Persevere, start modestly, and take advantage of these facts:
说服程序员向产品中添加测试支持代码常常是很困难的（一个真实引语：“我不想让测试代码弄乱我的程序。”）坚持下去，适时开始，并利用以下事实：
1. The test support code is often a simple extension of the debugging support code programmers write anyway.
测试支持代码常常只是程序员随便编写的调试支持程序的简单延伸。
2. A small amount of test support code often goes a long way.
少量的测试支持代码常常就会带来很大帮助。
A common objection to this approach is that the test support code must be compiled out of the final product (to avoid slowing it down). If so, tests that use the testing interface \"aren\'t testing what we ship\". It is true that some of the tests won\'t run on the final version, so you may miss bugs. But, without testability code, you\'ll miss bugs that don\'t reveal themselves through the user interface. It\'s a risk tradeoff, and I believe that adding test support code usually wins. See [Marick95], chapter 13, for more details.
对这种方法的普遍的反对意见是测试支持代码必须编译在最终产品之外（以避免显示）。如果是这样的，测试员使用的测试界面“不是我们交付的产品”。诚然，某些测试不会运行在最终版本中，所以可能会漏掉一些 bug 。但是，没有可测试的代码，你会漏掉一些通过用户界面无法揭示的 bug 。这是一个风险的权衡，我相信添加测试代码通常会占上风。参见[Marick95]的第13章以获取更多详细内容。[Page]
In one case, there\'s an alternative to having the programmer add code to the product: have a tool do it. Commercial tools like Purify, Boundschecker, and Sentinel automatically add code that checks for certain classes of failures (such as memory leaks). They provide a narrow, specialized testing interface. For marketing reasons, these tools are sold as programmer debugging tools, but they\'re equally test support tools, and I\'m amazed that testing groups don\'t use them as a matter of course.
有一种情况是，有一个方案替代程序远向产品添加代码：用工具来完成。一些商用工具如Purify、Boundschecker和Sentinel可以自动添加代码以检查某种类型的错误（比如内存泄露）。它们提供一个狭小的、专用的测试界面。因为市场营销的原因，这些工具是作为程序员调试工具出售的，但它们等同于测试支持工具，测试小组没有把它们当成常规工具来使用，让我觉得很吃惊。
Testability problems are exacerbated in distributed systems like conventional client/server systems, multi-tiered client/server systems, Java applets that provide smart front-ends to web sites, and so forth. Too often, tests of such systems amount to shallow tests of the user interface component because that\'s the only component that the tester can easily control.
测试问题在分布式系统中，比如传统的客户/服务器系统、多层的客户/服务器系统、向站点提供灵巧的前端应用的Java小程序等，可测试性问题更为严重。常常地，测试这类系统等同于用户界面部件的浅显测试，因为它们是测试员能够容易控制的唯一部件。
Finding failures is only the start
发现错误仅仅是开始
It\'s not enough to find a failure; you must also report it. Unfortunately, poor bug reporting is a classic mistake. Tester bug reports suffer from five major problems:
发现错误是不够的，还必须报告它。不幸的是，低劣的 bug 报告是一个典型错误。测试员的错误报告存在五个主要问题：
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. [Page]
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.
文章来源于领测软件测试网 https://www.ltesting.net/
