软件测试的作用

 在测试软件或制订测试工作计划时很容易犯一些错误。有些错误经常被许多不同的人一而再、再而三地犯，应该被列为典型错误。

  Classic mistakes cluster usefully into five groups, which I\'ve called \"themes\":

  典型错误可以有效地分为五组，我把这些组称为“主题”。

  · The Role of Testing: who does the testing team serve, and how does it do that?

  · 测试的作用：谁承担测试小组的责任，如何做？

  · Planning the Testing Effort: how should the whole team\'s work be organized?

  · 制订测试工作计划：应该如何组织整个小组的工作？

  · Personnel Issues: who should test?

  · 人员问题：谁应该做测试？

  · The Tester at Work: designing, writing, and maintaining individual tests.

  · 工作中的测试员：设计、编写和维护各测试。

  · Technology Rampant: quick technological fixes for hard problems.

  · 过度使用技术：艰难问题的快速技术修复

  I have two goals for this paper. First, it should identify the mistakes, put them in context, describe why they\'re mistakes, and suggest alternatives. Because the context of one mistake is usually prior mistakes, the paper is written in a narrative style rather than as a list that can be read in any order. Second, the paper should be a handy checklist of mistakes. For that reason, the classic mistakes are printed in a larger bold font when they appear in the text, and they\'re also summarized at the end.

  本文有两个目标。第一，应当识别错误，将它们放到具体环境中，描述它们为什么是错误，并给出替代方法的建议。因为一个错误的具体环境通常是先决错误，所以本文将以叙事的方式而不是以可以按任意顺序阅读的列表方式来描述。第二，本文应该是一个便于查看的错误列表。因为这个原因，文章中出现的典型错误都以大号粗体字印刷，并在文章的结尾处汇总。

  Although many of these mistakes apply to all types of software projects, my specific focus is the testing of commercial software products, not custom software or software that is safety critical or mission critical.

  虽然这些错误很多都适用于所有类型的软件项目，但我的重点将放在商用软件产品的测试上，而不是定制软件或者是高度安全或关键任务的软件测试上。

  This paper is essentially a series of bug reports for the testing process. You may think some of them are features, not bugs. You may disagree with the severities I assign. You may want more information to help in debugging, or want to volunteer information of your own. Any decent bug reporting system will treat the original bug report as the first part of a conversation. So should it be with this paper. Therefore, follow this link for an ongoing discussion of this topic.[Page]

  本文主要是测试过程的一系列错误报告。你可能认为它们中的部分属于特性问题而不是 bug。你可能不赞成我设定的严重性级别。你可能需要更多的信息以用于帮助排除错误，或者希望提供你自己的信息。任何设计良好的错误报告系统都将原始的错误报告当作是对话的起始部分。本文也是这样，所以，可以按照链接参加这个主题的讨论。

  Theme One: The Role of Testing

  主题一：测试的作用

  A first major mistake people make is thinking that the testing team is responsible for assuring quality. This role, often assigned to the first testing team in an organization, makes it the last defense, the barrier between the development team (aclearcase/" target="_blank" >ccused of producing bad quality) and the customer (who must be protected from them). It\'s characterized by a testing team (often called the \"Quality Assurance Group\") that has formal authority to prevent shipment of the product. That in itself is a disheartening task: the testing team can\'t improve quality, only enforce a minimal level. Worse, that authority is usually more apparent than real. Discovering that, together with the perverse incentives of telling developers that quality is someone else\'s job, leads to testing teams and testers who are disillusioned, cynical, and view themselves as victims. We\'ve learned from Deming and others that products are better and cheaper to produce when everyone, at every stage in development, is responsible for the quality of their work ([Deming86], [Ishikawa85]).

  人们犯的第一个主要错误是认为测试小组应当负责质量保证。这个角色常常分配给组织中的第一测试小组，将它作为最后的防御，成为开发小组（被指责为产生低劣质量）和客户（必须受到保护以远离低劣质量）的一个屏障。它的特征是测试小组（常称为“质量保证组”）表面上具有阻止产品发货的权力。 这本身是一个令人沮丧的任务：测试小组不能提高质量，只能强制一个最低水平。更糟糕的是，这种权力常常是看上去比实际的重要。如果发现这一点，再加上有违常理地暗示开发人员质量是别人的事情，导致测试小组和测试员感到失望、愤事嫉俗、感觉自己是受害者。我们从Deming 和其他人的工作可以得知：如果每个人都在开发的各个阶段对他们的工作质量负责，则产品会又好又便宜（[Deming86]，[Ishikawa85]）。

  In practice, whatever the formal role, most organizations believe that the purpose of testing is to find bugs. This is a less pernicious definition than the previous one, but it\'s missing a key word. When I talk to programmers and development managers about testers, one key sentence keeps coming up: \"Testers aren\'t finding the important bugs.\" Sometimes that\'s just griping, sometimes it\'s because the programmers have a skewed sense of what\'s important, but I regret to say that all too often it\'s valid criticism. Too many bug reports from testers are minor or irrelevant, and too many important bugs are missed.[Page]

原文转自：http://www.ltesting.net