软件测试的作用

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，以至于支持成本会吃掉利润，或者更糟糕的是将产品召回？[Page]
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.\"

文章来源于领测软件测试网 https://www.ltesting.net/