(一)典型測試錯誤
發表于:2009-05-27來源:作者:點擊數:
標簽:典型
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. 在 測試 軟件或制訂測試 工作 計劃時很容
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.
原文轉自:http://www.anti-gravitydesign.com