(一)典型测试错误

发布: 2009-5-27 09:59 | 作者: 不详 | 来源: 测试时代采编 | 查看: 54次 | 进入软件测试论坛讨论

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.