(二)典型测试错误

发表于:2007-9-17 14:58

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:翻译:米全喜    来源:网络转载

分享:

          

          

         to one like this:
 
            转化为:

          

          

        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章以获取更多详细内容。

        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.

        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]都描述了归档测试信息的格式,并包含了通用的示例。

31/3123>
100家互联网大公司java笔试题汇总,填问卷领取~

精彩评论

  • miracle602
    2007-9-23 22:47:38

    太专业了

  • 51testing
    2007-9-20 17:23:03

    是会员推荐的一篇经典的国外文章

  • fmsbai5
    2007-9-20 14:20:39

    如果这是一篇近期国外的文章的话,那么国外的测试看起来没有超出我们多少。

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号