Theme Two: Planning the Testing Effort 典型测试错误（二）——计划测试工作

pele · 发表于 2006-8-14 22:53:38

主题二：计划测试工作

  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.

  配置测试和场景测试都测试产品的全面的、跨功能的方面。另一类测试是跨越产品以检查在压力（大量事务、很大的事务、大量并发事务）下的表现。将压力测试和负载测试推迟到最后一刻才进行是一种常见的情况，但是这样做的结果是，当你发现你的产品不能支持12个以上的用户时，你已经没有多少时间来采用实际的措施。

  Two related mistakes are not testing the documentation and not testing installation procedures. Testing the documentation means checking that all the procedures and examples in the documentation work. Testing installation procedures is a good way to avoid making a bad first impression.

  一个相关错误是不测试文档，也不测试安装过程。测试文档意味着检查文档中所有过程和示例都能工作。测试安装过程是避免给别人留下糟糕的第一印象的好方法。