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

　　必须承认，这是一个极端的例子，但是证明了一个重要的观点。项目经理有一个艰难的决定：是延迟产品交付，再工作一段时间，还是现在就交付使用?许多因素 ——都是一些大致的评估——都必须予以权衡：竞争对手会抢先发布产品并占领市场吗?如果丢掉一个未完工的功能部件会使得某一个杂志的 “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.

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