典型的测试错误有哪些？(5)

　　尽早测试的作用不仅仅是防止编码错误。像我们将在下一个主题中所讨论的那样，许多测试代表的是用户任务。设计它们的过程可以在昂贵的重新工作之前发现用户界面和可用性问题。我发现过的问题包括：错误消息不能显示在用户可以看到的地方，插件不能放到一起，两个必须同时使用的屏幕不能同时显示，一个“很明显” 的功能不能执行。测试设计作为一个发现规格说明书 bug 的方法，很好地与可用性工程工作相适应([Nielsen93])。

　　I should note that involving testing early feels unnatural to many programmers and development managers. There may be feelings that you are intruding on their turf or not giving them the chance to make the mistakes that are an essential part of design. Take care, especially at first, not to increase their workload or slow them down. It may take one or two entire projects to establish your credibility and usefulness.

　　我应当说明早期介入测试对于许多程序员和开发经理来说不自然。可能有一种感觉是你干扰了他们，没有给他们在设计的基础部分犯错误的机会。小心些，尤其是在开始的时候，不要增加他们的工作量或减慢了他们的速度。可能需要一至两个完整的项目才能建立你们的可信度并显示出作用。

　　主题二：计划测试工作

　　I'll first discuss specific planning mistakes, then relate test planning to the role of testing.

　　我将首先讨论特定的计划错误，然后将测试计划与测试作用关联起来。

　　It's not unusual to see test plans biased toward functional testing. In functional testing, particular features are tested in isolation. In a word processor, all the options for printing would be applied, one after the other. Editing options would later get their own set of tests.

　　将测试计划偏重于功能测试的情况的并不少见。在功能测试中，某个功能部件是孤立测试的。在字处理软件中，所有打印选项都将一个接一个地应用。编辑选项在后面将得到它们自己的测试集。

　　But there are often interactions between features, and functional testing tends to miss them. For example, you might never notice that the sequence of operations open a document, edit the document, print the whole document, edit one page, print that page doesn't work. But customers surely will, because they don't use products functionally. They have a task orientation. To find the bugs that customers see - that are important to customers - you need to write tests that cross functional areas by mimicking typical user tasks. This type of testing is called scenario testing, task-based testing, or use-case testing.

　　但是，在各个功能部件中常常有交互作用，功能测试很容易遗漏它们。例如，你可能从未注意到一系列的操作：打开文档、编辑文档、打印整个文档、编辑一页、打印该页不能工作。但是客户一定会注意到，因为他们不会按功能使用产品。他们是面向任务的。如果要找到客户看到的 bug——这些 bug 对于客户来说是很重要的——你需要编写模仿典型用户任务的跨功能区的测试用例。这类测试称为场景测试、基于任务的测试，或使用用例测试。

　　A bias toward functional testing also underemphasizes configuration testing. Configuration testing checks how the product works on different hardware and when combined with different third party software. There are typically many combinations that need to be tried, requiring expensive labs stocked with hardware and much time spent setting up tests, so configuration testing isn't cheap. But, it's worth it when you discover that your standard in-house platform which "entirely conforms to industry standards" actually behaves differently from most of the machines on the market.

　　偏重于功能测试也会低估配置测试的重要性。配置测试检查产品在不同硬件上、以及在与不同的第三方软件组合使用时如何工作。通常有不同的典型组合需要尝试，需要有装备了硬件的昂贵实验室，并花费很多时间设置测试，所以配置测试成本不低。但是，当你发现你的“完全符合业界标准”的标准机构内部平台实际上在市场上不同的机器上表现不同的时候，这样做就值了。

　　Both configuration testing and scenario testing test global, cross-functional aspects of the product. Another type of testing that spans the product checks how it behaves under stress (a large number of transactions, very large transactions, a large number of simultaneous transactions). Putting stress and load testing off to the last minute is common, but it leaves you little time to do anything substantive when you discover your product doesn't scale up to more than 12 users.

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