什么时候停止测试？

Question

在您的实践中，您使用什么措施来知道何时停止测试应用程序并将其转移到生产环境？

Answer 1

对于我组织中的项目，我通常使用的措施如下：

• 没有 1 级严重性（节目停止）问题
• 没有 2 级严重性（主要功能受损）问题
• 可接受数量的 3 级严重性（次要功能）问题

“可接受的数字”自然是一个非常模糊的数字，具体取决于应用程序的大小等。ETC。

一旦满足这些先决条件，我将召开所有利益相关者（QA 负责人、开发负责人、应用程序支持负责人等）的会议，并仔细检查未决问题列表，并确保就分配给问题的严重性达成一致。显着的问题。一旦我确认不存在未解决的 Sev 1 和 Sev 2 问题，我就会收到每个利益相关者的“通过/不通过”电话。如果每个人都说“开始”，我就很乐意转向生产。如果至少一位利益相关者表示“不进行”，我们会检查“不进行”的原因，并在必要时采取措施解决其背后的问题。

在较小的项目中，流程可能会更加简化，如果这只是一个人的操作，那么您的一组先决条件可能会简单得多，即“该应用程序提供了合理的好处，同时具有（显然）可接受数量的错误 - 让我们把它放在那里！”。只要应用程序提供的好处克服了错误的烦恼，特别是如果您遵循“尽早且经常发布”的准则，那么这可能对您有用。

Answer 2

首先，你永远不会停止测试。什么时候 你 完成测试并发布它，这意味着您的用户正在代替您进行测试。

其次，当您的综合测试脚本以可接受的失败程度通过时，您就可以继续前进了。

最后，这对于您的情况来说是非常具体的。在某些项目中，我们有一个为期 3 周的 beta 测试期，在推出最小的更改之前，很多人都会对系统进行黑客攻击。在其他领域（不太重要），只需另一位开发人员的点头即可将小的更改移出。

Answer 3

我一直想尝试的一种有趣的测试方法是“错误播种”。这个想法是让一个人故意将属于不同类别的错误插入到系统中。

例如：

• 外观、拼写错误等
• 非严重错误
• 严重错误和崩溃
• 数据问题。没有发生错误，但结果存在更深层次的错误。
• ETC。

“播种器”准确记录了插入这些错误的更改内容，以便可以快速恢复它们。当测试团队发现种子错误时，他们也发现了真正的错误，但不知道其中的区别。理论上，如果测试团队发现了 90% 的种子关键错误，那么他们可能就发现了相应数量的真正关键错误。

根据这些统计数据，您可以开始判断何时可以接受发布。当然，由于发现错误（真实的或种子的）的随机性，这甚至不能接近万无一失，但这可能比根本不知道您可能会释放多少错误要好。

Answer 4

在我的工作场所，有时使用的一个指标是，当我们开始发现产品的最后几个版本中存在的旧的和未报告的错误时，我们已经进行了足够的测试。我们的想法是，如果这些是我们在测试过程中发现的错误，并且这些错误已经存在多年而没有客户抱怨它们，那么我们可能可以安全地发货。

当然，您还拥有所有手动测试、自动化测试，让开发人员使用产品、测试版和持续测试内容，但是使用我们现在发现的过去版本中存在但未报告的错误数量当我第一次听到它时，这对我来说是一个新想法。

Answer 5

当所有主要表演者都消失时。

说真的，您应该进行用户验收测试，让您的用户使用您的系统，看看它是否适合他们。如果这不切实际，请与与您的目标受众相似的选定用户进行封闭测试。

不可能真正找到系统中的所有错误，因此有时唯一真正的规则是 只需发货即可.

Answer 6

姆哈伦,

我发现如果你有全面的自动化测试，那么发布软件是完全不负责任的，除非 全部 他们中的一些人通过了。自动化测试意味着这些区域要么是核心功能，要么是您知道的过去发生的错误，并且可以修复以便通过测试。发布未通过 100% 自动化测试的软件是不负责任的行为。

Answer 7

乔恩，

我的意思并不是测试脚本暗示 自动化的 测试。我指的是更传统的方法，即逐步列出要测试的内容以及如何测试。

也就是说，我不同意所有自动化测试都必须通过。这一切都取决于严重性和优先级。在大型项目中，我们可以让开发人员根据用户报告的问题编写失败的测试。由于我们无法修复每个版本的每个错误，因此某些测试根本无法通过。

Answer 8

衡量产品在出现“精彩”或主要功能错误之间所花费的测试时间可以让您知道您已经接近成功了。在产品快速变化并引入新功能的时候，测试团队通常会发现他们报告的大多数错误都是严重的功能错误。在处理这些问题时，通常会出现大量旨在提高交互的流畅性和清晰度的次要、适合和完成类型的问题；总的来说，它们对产品质量有很大影响，但每一项都不是非常重要。随着这些问题得到修复并且测试继续进行，当测试人员陷入错误案例和不寻常的使用模式时，您可能会继续收到错误报告。到那时，这取决于您何时看到发布的商业价值与未被发现的搅局者的风险。