你什么时候停止测试？

Question

在您的实践中，您使用什么衡量标准来了解何时停止测试应用程序并将其转移到生产中？

Answer 1

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

• 没有严重性1（显示停止）问题
• 没有严重性2（主要功能瘫痪）问题
• 可接受的严重级别3（次要功能）问题

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

一旦满足这些先决条件，我将召开所有利益相关方的会议（QA主管，开发主管，应用支持负责人等），并查看未解决的问题列表，并确保达成一致意见。分配给未决问题的严重性。一旦我确认没有未完成的Sev 1和Sev 2问题，我将从每个利益相关者处获得“Go / No Go”电话。如果每个人都说“Go”，我很乐意转到Production。如果至少有一个利益相关者说“不行”，我们会检查“不行”的原因，并在必要时采取措施解决背后的问题。

在较小的项目中，流程可能会更加简化，如果只是单人操作，那么您的前提条件可能会更加简单，即“应用程序提供合理的好处，同时具有（显然）可接受的数量虫子 - 我们把它放在那里！“只要应用程序提供的好处超过了bug的烦恼，特别是如果您遵循“早期和经常发布”指南，那可能对您有用。

Answer 2

首先，你永远不会停止测试。当你完成测试并释放它时，所有这些都意味着你的用户正在测试而不是你。

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

最后，这非常适合您的情况。在某些项目中，我们有一个为期3周的beta测试期，在最短的更改可以推出之前，很多人都会破解系统。在其他领域（不太重要），只需另一个开发人员的点头就可以移出小的变化。

Answer 3

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

例如：

• 化妆品，拼写错误等
• 非关键错误
• 严重错误和崩溃
• 数据问题。没有错误发生，但更深层次的结果是错误的。
• 等

“播种者”准确记录了为了插入这些错误而更改的内容，以便快速恢复。当测试团队发现种子错误时，他们也发现了真正的错误，但不知道其中的差异。从理论上讲，如果测试团队发现了90％的种子关键错误，那么他们可能会找到相应数量的真实关键错误。

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

Answer 4

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

当然，您还拥有所有手动测试，自动化测试，使开发人员也可以使用产品，测试版和不断测试的东西，但是使用了我们现在发现的有多少错误，但是没有报告，在我第一次听到它时，在过去的版本中给我一个新的想法。

Answer 5

当所有主要的节目塞子都消失了。

说真的，你应该进行一次用户验收测试，让你的用户使用你的系统，看看它们是否全部切断了。如果这不切实际，请针对与目标受众类似的精选用户进行封闭测试。

无法真正找到系统中的所有错误，因此有时唯一真正的规则是只发送。

Answer 6

mharen，

我发现如果你有全面的自动化测试，除非所有通过，否则运送软件是完全不负责任的。自动化测试意味着这些区域既可以是核心功能，也可以是过去发生的错误，并且可以修复以便通过测试。运送没有通过100％自动化测试的软件是不负责任的。

Answer 7

乔，

我并不是说测试脚本暗示自动测试。我指的是更传统的方法，逐步列出测试内容以及测试方法。

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

Answer 8

测量“showstopper”或主要功能错误之间产品的测试时间量可以让你知道你几乎就在那里。在有新功能的产品快速流动的时候，测试团队常常发现他们报告的大多数错误都是严重的功能错误。在处理这些问题时，往往会出现大量的轻微，适合和完成类型的问题，旨在提高交互的平滑性和清晰度;总的来说，它们在产品质量上有很大的不同，但每一个都不是非常重要。随着这些问题得到修复并且测试仍在继续，您可能会继续获取错误报告，因为测试人员会将错误情况和不寻常的使在这一点上，它取决于您何时看到发布的业务价值与未检测到的showstoppers的风险。