在测试软件或制订测试工作计划时很容易犯一些错误。有些错误经常被许多不同的人一而再、再而三地犯，应该被列为典型错误。
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.
- 过度使用技术：艰难问题的快速技术修复。
本文有两个目标。第一，应当识别错误，将它们放到具体环境中，描述它们为什么是错误，并给出替代方法的建议。因为一个错误的具体环境通常是先决错误，所以本文将以叙事的方式而不是以可以按任意顺序阅读的列表方式来描述。第二，本文应该是一个便于查看的错误列表。因为这个原因，文章中出现的典型错误都以大号粗体字印刷，并在文章的结尾处汇总。
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]).
人们犯的第一个主要错误是认为测试小组应当负责质量保证。这个角色常常分配给组织中的第一测试小组，将它作为最后的防御，成为开发小组（被指责为产生低劣质量）和客户（必须受到保护以远离低劣质量）的一个屏障。它的特征是测试小组（常称为“质量保证组”）表面上具有阻止产品发货的权力。 这本身是一个令人沮丧的任务：测试小组不能提高质量，只能强制一个最低水平。更糟糕的是，这种权力常常是看上去比实际的重要。如果发现这一点，再加上有违常理地暗示开发人员质量是别人的事情，导致测试小组和测试员感到失望、愤事嫉俗、感觉自己是受害者。我们从Deming 和其他人的工作可以得知：如果每个人都在开发的各个阶段对他们的工作质量负责，则产品会又好又便宜（[Deming86]，[Ishikawa85]）。
In practice, whatever the formal role, most organizations believe that the purpose of testing is to find bugs. This is a less pernicious definition than the previous one, but it's missing a key word. When I talk to programmers and development managers about testers, one key sentence keeps coming up: "Testers aren't finding the important bugs." Sometimes that's just griping, sometimes it's because the programmers have a skewed sense of what's important, but I regret to say that all too often it's valid criticism. Too many bug reports from testers are minor or irrelevant, and too many important bugs are missed.
实际上，不管表面上的作用是什么，大多数组织都相信测试的目的是发现 bug。这个定义的危害比前一个定义的危害要小，但是忽略了一个关键词。当我同程序员和开发经理谈到测试员的时候，不时听到一个关键的句子：测试员找不到重要的 bug。有时候这种说法只是一种抱怨，有时候是因为程序员对于什么是正确的感觉不对，但我很遗憾地说，它们经常是有效的批评。测试员的太多的bug 报告是微小的、不相关的，而有太多重要的错误都被遗漏了。
What's an important bug? Important to whom? To a first approximation, the answer must be "to customers". Almost everyone will nod their head upon hearing this definition, but do they mean it? Here's a test of your organization's maturity. Suppose your product is a system that accepts email requests for service. As soon as a request is received, it sends a reply that says "your request of 5/12/97 was accepted and its reference ID is NIC-051297-3". A tester who sends in many requests per day finds she has difficulty keeping track of which request goes with which ID. She wishes that the original request were appended to the acknowledgement. Furthermore, she realizes that some customers will also generate many requests per day, so would also appreciate this feature. Would she:
什么是重要的 bug？对谁而言是重要的？直观的估计，答案肯定是“对于客户”。听到这个定义，几乎每个人都会点头称是，但他们确实这样认为吗？这里要测试一下你们组织的成熟度。假设你们的产品是一个接受电子邮件请求服务的系统。当收到请求时，它马上发送一个“您在97年5月12日发送的请求已经受理，参考ID是NIC-051297-3”的答复。一个每天发送很多请求的测试员发现要分清楚哪个请求与哪个ID对应是非常困难的。她希望最初的请求能够附加在确认邮件的后面。并且，她意识到某些可户可能每天也会产生很多请求，所以会高度评价这个功能的。那么她将：
1. file a bug report documenting a usability problem, with the expectation that it will be assigned a reasonably high priority (because the fix is clearly useful to everyone, important to some users, and easy to do)?
写一个 bug 报告，记录一个可用性问题，希望能够分配一个合理的高优先级（因为这个修复很明显对每个人都很用，对有部分用户来说还非常重要，并且也容易修改）？
2. file a bug report with the expectation that it will be assigned "enhancement request" priority and disappear forever into the bug database?
写一个 bug 报告，希望它被分配为“功能提升请求”优先级并永远从 bug 数据库中消失？
3. file a bug report that yields a "works as designed" resolution code, perhaps with an email "nastygram" from a programmer or the development manager?
写一个 bug 报告，产生一个“按设计工作”解决码，可能还加上一个来自程序员或开发经理的“不同意”电子邮件?
4. not bother with a bug report because it would end up in cases (2) or (3)?
不打算费事去写 bug 报告，因为它将以情况(2)或(3)结束？
If usability problems are not considered valid bugs, your project defines the testing task too narrowly. Testers are restricted to checking whether the product does what was intended, not whether what was intended is useful. Customers do not care about the distinction, and testers shouldn't either.
如果可用性问题不认为是有效的 bug，那么你们的项目将测试任务定义得太狭窄了。测试员严格限制为检查产品是否按预期工作，而不管这种预期是否有效。客户不关心这个区别，测试员也不应该关心。
Testers are often the only people in the organization who use the system as heavily as an expert. They notice usability problems that experts will see. (Formal usability testing almost invariably concentrates on novice users.) Expert customers often don't report usability problems, because they've been trained to know it's not worth their time. Instead, they wait (in vain, perhaps) for a more usable product and switch to it. Testers can prevent that lost revenue.
测试员经常是组织中唯一像专家一样大量使用系统的人。他们会注意到专家会看到的可用性问题。（形式上的可用性测试几乎不可避免地集中于没有经验的用户。）专家客户常常不会报告可用性问题，因为他们已经被训练的知道不值得花时间去这样做。相反，他们（也许是徒劳地）等待下一个可用的产品然后切换过去。测试员可以避免这个损失。
While defining the purpose of testing as "finding bugs important to customers" is a step forward, it's more restrictive than I like. It means that there is no focus on an estimate of quality (and on the quality of that estimate). Consider these two situations for a product with five subsystems.
将测试的目的定义为“找到对用户重要的 bug ”是向前进了一步，但与我所喜欢定义相比仍有限制。这意味着没有集中于质量评估（以及这种评估的质量）。考虑一下测试含有五个子系统的产品的两种情况。
1. 100 bugs are found in subsystem 1 before release. (For simplicity, assume that all bugs are of the highest priority.) No bugs are found in the other subsystems. After release, no bugs are reported in subsystem 1, but 12 bugs are found in each of the other subsystems.
在发布前，在子系统1中找到了100个bug 。（为了简单起见，假设所有的 bug 都是最高级别的。）在其他子系统中没有发现 bug 。在发布后，在子系统1中没有报告 bug ，但在其他每个子系统中都报告了12个 bug 。
2. Before release, 50 bugs are found in subsystem 1. 6 bugs are found in each of the other subsystems. After release, 50 bugs are found in subsystem 1 and 6 bugs in each of the other subsystems.
在发布前，在子系统1中找到了50个 bug 。在其他每个子系统中都找到了6个 bug 。在发布后，在子系统1中报告了50个 bug ，在其他每个子系统中都报告了6个 bug。
From the "find important bugs" standpoint, the first testing effort was superior. It found 100 bugs before release, whereas the second found only 74. But I think you can make a strong case that the second effort is more useful in practical terms. Let me restate the two situations in terms of what a test manager might say before release:
从“找到重要 bug”的观点看，第1种测试情况较为理想。在发布前找到了100个 bug ，但是第2种情况中只找到74个。但我想你们可能会提出一个有力的理由认为第2中测试在实际中更有用。让我以产品发版前测试经理可能说些什么来重新描述一下两种测试情况：
1. "We have tested subsystem 1 very thoroughly, and we believe we've found almost all of the priority 1 bugs. Unfortunately, we don't know anything about the bugginess of the remaining five subsystems."
“我们全面测试了子系统1，我们相信已经找出了几乎所有优先级为1的 bug。不幸的是，我们对其他五个子系统的bug一无所知。”
2. "We've tested all subsystems moderately thoroughly. Subsystem 1 is still very buggy. The other subsystems are about 1/10th as buggy, though we're sure bugs remain."
“我们比较全面地测试了所有的子系统。子系统1仍旧有不少 bug。其他子系统虽然还有 bug，但只有子系统1的 bug 的十分之一。”
This is, admittedly, an extreme example, but it demonstrates an important point. The project manager has a tough decision: would it be better to hold on to the product for more work, or should it be shipped now? Many factors - all rough estimates of possible futures - have to be weighed: Will a competitor beat us to release and tie up the market? Will dropping an unfinished feature to make it into a particular magazine's special "Java Development Environments" issue cause us to suffer in the review? Will critical customer X be more annoyed by a schedule slip or by a shaky product? Will the product be buggy enough that profits will be eaten up by support costs or, worse, a recall?
必须承认，这是一个极端的例子，但是证明了一个重要的观点。项目经理有一个艰难的决定：是延迟产品交付，再工作一段时间，还是现在就交付使用？许多因素——都是一些大致的评估——都必须予以权衡：竞争对手会抢先发布产品并占领市场吗？如果丢掉一个未完工的功能部件会使得某一个杂志的 “Java 开发环境” 特别期刊的评论中对我们造成损害吗？关键客户X对产品延期和劣质产品哪一个更感到烦恼？产品是否有很多bug，以至于支持成本会吃掉利润，或者更糟糕的是将产品召回？
The testing team will serve the project manager better if it concentrates first on providing estimates of product bugginess (reducing uncertainty), then on finding more of the bugs that are estimated to be there. That affects test planning, the topic of the next theme.
如果测试小组首先集中于产品错误的估计（减少不确定性），然后再找到更多的错误，他们会更好地服务于项目经理。这会影响测试计划。测试计划将在下个主题中论述。
It also affects status reporting. Test managers often err by reporting bug data without putting it into context. Without context, project management tends to focus on one graph:
这也会影响状态报告。测试经理常常会被没有放到具体环境中的报告bug数据误导。没有具体环境，项目管理倾向于集中于一幅图：
The flattening in the curve of bugs found will be interpreted in the most optimistic possible way unless you as test manager explain the limitations of the data:
平滑的错误曲线很容易以一种乐观的方式解释，除非你作为测试经理解释了数据的局限：
- "Only half the planned testing tasks have been finished, so little is known about half the areas in the project. There could soon be a big spike in the number of bugs found."
- 只有一半的计划测试做完了，对于项目的一半所知甚少。很快就有很多错误要被发现了。
- "That's especially likely because the last two weekly builds have been lightly tested. I told the testers to take their vacations now, before the project hits crunch mode."
- 很有可能这样，因为在过去的两个周构建只是略微测试了一下。我告诉测试员在项目进入艰难状态之前，现在开始休假。
- "Furthermore, based on previous projects with similar amounts and kinds of testing effort, it's reasonable to expect at least 45 priority-1 bugs remain undiscovered. Historically, that's pretty high for a successful product."
- 并且，根据以前的经验，可以预料到至少还有45个级别为1的 bug还没有发现。从历史看，这对于一个成功产品来说是很高的。
For discussions of using bug data, see [Cusumano95], [Rothman96], and [Marick97].
关于使用bug数据的讨论，请参阅[Cusumano95]、[Rothman96]和[Marick97]。
Earlier I asserted that testers can't directly improve quality; they can only measure it. That's true only if you find yourself starting testing too late. Tests designed before coding begins can improve quality. They inform the developer of the kinds of tests that will be run, including the special cases that will be checked. The developer can use that information while thinking about the design, during design inspections, and in his own developer testing.
我在前面说过，测试员不能直接提高质量，他们只能评估它。只有在你发现测试开始得太晚的时候，这种说法才是正确的。在编码开始前设计测试将会提高质量。他们让开发人员知道将进行什么样的测试，将检查哪些特殊用例。开发人员在思考设计、审查设计和自己做测试的时候可以使用这些信息。
Early test design can do more than prevent coding bugs. As will be discussed in the next theme, many tests will represent user tasks. The process of designing them can find user interface and usability problems before expensive rework is required. I've found problems like no user-visible place for error messages to go, pluggable modules that didn't fit together, two screens that had to be used together but could not be displayed simultaneously, and "obvious" functions that couldn't be performed. Test design fits nicely into any usability engineering effort ([Nielsen93]) as a way of finding specification bugs.
尽早测试的作用不仅仅是防止编码错误。像我们将在下一个主题中所讨论的那样，许多测试代表的是用户任务。设计它们的过程可以在昂贵的重新工作之前发现用户界面和可用性问题。我发现过的问题包括：错误消息不能显示在用户可以看到的地方，插件不能放到一起，两个必须同时使用的屏幕不能同时显示，一个“很明显”的功能不能执行。测试设计作为一个发现规格说明书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 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.
一个相关错误是不测试文档，也不测试安装过程。测试文档意味着检查文档中所有过程和示例都能工作。测试安装过程是避免给别人留下糟糕的第一印象的好方法。
How about avoiding testing altogether?
不做测试会怎么样？
At a conference last year, I met (separately) two depressed testers who told me their management was of the opinion that the World Wide Web could reduce testing costs. "Look at [wildly successful internet company]. They distribute betas over the network and get their customers to do the testing for free!" The Windows 95 beta program is also cited in similar ways.
在去年的一个会议上，我（分别）遇到两个沮丧的测试员，他们告诉我他们的管理是基于这样一种意见：万维网（World Wide Web）可以减少测试成本。“看看非常成功的网络公司”。他们在网络上分发β版，让客户免费给他们做测试！”。Windows 95的β程序也是这样的。
Beware of an overreliance on beta testing. Beta testing seems to give you test cases representative of customer use - because the test cases are customer use. Also, bugs reported by customers are by definition those important to customers. However, there are several problems:
要当心对β测试的过分依赖。因为测试用例是客户使用的，所以β测试似乎是给了你客户使用的代表用例。另外，客户报告的错误也是对客户重要的。但是，有几个问题：
1. The customers probably aren't that representative. In the common high-tech marketing model, beta users, especially those of the "put it on your web site and they will download" sort, are the early adopters, those who like to tinker with new technologies. They are not the pragmatists, those who want to wait until the technology is proven and safe to adopt. The usage patterns of these two groups are different, as are the kinds of bugs they consider important. In particular, early adopters have a high tolerance for bugs with workarounds and for bugs that "just go away" when they reload the program. Pragmatists, who are much less tolerant, make up the large majority of the market.
客户可能不是代表。在一个普通的高科技市场营销模型中，β用户，特别是那种“将产品放到网站上让他们下载”的情况，是早期的采用者。他们喜欢摆弄新技术。他们不是实用主义者，不是那种愿意等到新技术被证明是安全可靠后才采用的人。这两种类别的使用方式是不同的，就像他们认为bug的重要程度是不同的一样。特别地，早期的采用者对于能够用变通方法解决的bug和重新加载程序就能消失的bug有较强的容忍性。但容忍性较差的实用主义者占据了市场的大部分。
2. Even of those beta users who actually use the product, most will not use it seriously. They will give it the equivalent of a quick test drive, rather than taking the whole family for a two week vacation. As any car buyer knows, the test drive often leaves unpleasant features undiscovered.
即使是那些实际使用产品的β用户，大多数也不会认真地使用。他们会给一个类似于试驾车的快速测试，而不是带着整个家庭休假两周。很多购买汽车的人都知道，试驾车经常会遗漏一些令人不愉快的特性。
3. Beta users - just like customers in general - don't report usability problems unless prompted. They simply silently decide they won't buy the final version.
β用户象客户一样，除非特别要求，一般不会报告可用性错误。他们只是暗自决定不去购买最终产品。
4. Beta users - just like customers in general - often won't report a bug, especially if they're not sure what they did to cause it, or if they think it is obvious enough that someone else must have already reported it.
β用户象客户一样，常常不会报告 bug ，尤其是当他们不能确定是什么操作导致了错误，或者是他们认为这个错误很明显，其他人肯定已经报告了。
5. When beta users report a bug, the bug report is often unusable. It costs much more time and effort to handle a user bug report than one generated internally.
当β用户报告错误时，错误报告常常无法使用。处理一个用户的错误报告比一个内部产生的错误报告要花费多得多的时间和精力。
Beta programs can be useful, but they require careful planning and monitoring if they are to do more than give a warm fuzzy feeling that at least some customers have used the product before it's inflicted on all of them. See [Kaner93] for a brief description.
β程序可能是有用的，但是需要仔细的计划和监督，否则它们在激怒所有β客户之前，除了带来一种模糊的、兴奋的感觉，认为至少有一些客户在使用产品之外，不会有其他收获。参见[kaner93]以获取一个简要描述。
The one situation in which beta programs are unequivocally useful is in configuration testing. For any possible screwy configuration, you can find a beta user who has it. You can do much more configuration testing than would be possible in an in-house lab (or even perhaps an outsourced testing agency). Beta users won't do as thorough a job as a trained tester, but they'll catch gross errors of the "BackupBuster doesn't work on this brand of 'compatible' floppy tape drive" sort.
β测试有用的一种情况是配置测试。对于任何古怪的配置，你都可以找到一个使用此配置的β用户。你可以做比机构内部实验室（或者甚至是外包给测试机构）多的配置测试。β用户不会象一个训练有素的测试员一样做完整的测试，但他们可以捕捉到大致错误，像“BackupBuster在这个品牌的兼容磁带驱动器上不能工作”。
Beta programs are also useful for building word of mouth advertising, getting "first glance" reviews in magazines, supporting third-party vendors who will build their product on top of yours, and so on. Those are properly marketing activities, not testing.
β程序也有助于建立口头的广告，获得杂志的“第一印象”评论，支持第三方供应商在你的产品上构建他们的产品等等。这些都是正常的市场营销活动，不是测试。
Planning and replanning in support of the role of testing
计划和重新计划测试的支持作用
Each of the types of testing described above, including functional testing, reduces uncertainty about a particular aspect of the product. When done, you have confidence that some functional areas are less buggy, others more. The product either usually works on new configurations, or it doesn't.
上面所描述的包括功能测试在内的各种类型的测试，减少了产品某一方面的不确定性。在执行完毕后，你可以确信某些功能领域的错误较少了，其他的还比较多。产品通常将在新配置中起作用，或者是不起作用。
There's a natural tendency toward finishing one testing task before moving on to the next, but that may lead you to discover bad news too late. It's better to know something about all areas than everything about a few. When you've discovered where the problem areas lie, you can test them to greater depth as a way of helping the developers raise the quality by finding the important bugs.
有一种很自然的倾向，就是在进行到下一个测试任务之前先完成一个任务，但这可能导致你过晚地发现坏消息。对所有领域都了解一些比深入了解几个领域更重要。如果你发现了问题在哪个地方，你可以更深入地测试它们，通过发现重要bug来帮助开发人员提高质量。
Strictly, I've been over-simplistic in describing testing's role as reducing uncertainty. It would be better to say "risk-weighted uncertainty". Some areas in the product are riskier than others, perhaps because they're used by more customers or because failures in that area would be particularly severe. Riskier areas require more certainty. Failing to correctly identify risky areas is a common mistake, and it leads to misallocated testing effort. There are two sound approaches for identifying risky areas:
严格地说，我对将测试的作用描述为减少不确定性是太简单了。更恰当的说法是“风险加权”的不确定性。产品中某些领域比其他领域更有风险，也许是因为它们由更多客户使用或是因为那个领域的故障更严重。危险性高的区域需要更好的稳定性。不能正确地识别危险区域是一个常犯的错误，它导致测试工作的不恰当分配。
1. Ask everyone you can for their opinion. Gather data from developers, marketers, technical writers, customer support people, and whatever customer representatives you can find. See [Kaner96a] for a good description of this kind of collaborative test planning.
向每一个能够找到的人征询意见。从开发人员、市场人员、技术写作人员、客户支持人员和你能找到的每一个客户代表那里收集意见。查看[Kaner96a]以获得关于这种协同测试计划的描述。
2. Use historical data. Analyzing bug reports from past products (especially those from customers, but also internal bug reports) helps tell you what areas to explore in this project.
使用历史数据。分析以前产品的 bug 报告（特别是来自客户的，但也要包含内部 bug 报告）可以帮助你辨别在这个项目中还需要探索哪些领域。
"So, winter's early this year. We're still going to invade Russia."
“今年冬天来得很早。但我们还是要入侵俄国。”
Good testers are systematic and organized, yet they are exposed to all the chaos and twists and turns and changes of plan typical of a software development project. In fact, the chaos is magnified by the time it gets to testers, because of their position at the end of the food chain and typically low status. One unfortunate reaction is sticking stubbornly to the test plan. Emotionally, this can be very satisfying: "They can flail around however they like, but I'm going to hunker down and do my job." The problem is that your job is not to write tests. It's to find the bugs that matter in the areas of greatest uncertainty and risk, and ignoring changes in the reality of the product and project can mean that your testing becomes irrelevant.
好的测试员是有计划、有组织的，但他们受到计划，特别是软件开发项目计划的各种混乱、各种意外转折的影响，因为他们处于食物链的最后一环，而且通常地位比较低。一个不幸的反应是固执地坚持测试计划。从感情上讲，这会令人很满意：“他们可以随意胡乱摆弄，但我要坐下来做我的工作。”但问题是你的工作不是编写测试。而是在最不确定和危险的领域发现bug 。忽略产品和项目的实际变化可能意味着你的测试变得无关紧要。
That's not to say that testers should jump to readjust all their plans whenever there's a shift in the wind, but my experience is that more testers let their plans fossilize than overreact to project change.
这不是说测试员在有任何变化时都应该匆忙地重新调节他们的计划，但我的经验是很多的测试员都让计划僵化而不是对项目变化起过度的反应。
-----------------------------------------------------------------------------------------
转自：http://www.uml.org.cn/Test/200709289.asp
