典型的测试错误有哪些？

　　It's easy to make mistakes when testing software or planning a testing effort. Some mistakes are made so often, so repeatedly, by so many different people, that they deserve the label Classic Mistake.

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

　　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.

　　本文主要是测试过程的一系列错误报告。你可能认为它们中的部分属于特性问题而不是 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 (accused 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]).

原文转自：http://www.uml.org.cn/Test/200709289.asp