典型的測試錯誤有哪些？

　　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