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

解决方案

回答

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

当然，我们还拥有所有的手动测试，自动测试，还使开发人员也可以使用产品，测试版和持续测试的内容，但是要使用我们现在发现的错误数量，这些错误在过去的版本中已经存在，但尚未报告。当我第一次听到它时，这是一个新主意。

回答

首先，我们永不停止测试。完成测试并将其发布后，这意味着用户正在测试而不是我们。

其次，当综合测试脚本通过可接受的故障级别时，我们就可以继续进行了。

最后，这是针对情况的。在某些项目中，我们有一个为期3周的Beta测试期，在此期间，很多人都可以在系统上进行细微的改动，然后才能进行最小的更改。在其他区域(不太重要)中，只需其他开发人员的点头就可以移出小的更改。

回答

当所有的主要演出塞子都走了。

认真地，我们应该进行用户接受度测试，并让用户使用系统，并确定系统是否适合他们。如果这不切实际，请对与目标受众相似的部分用户进行封闭式Beta测试。

不可能真正找到系统中的所有错误，因此有时唯一的真正法则就是将其发布。

回答

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

• 没有严重性1(显示停止器)问题
• 没有严重性2(主要功能受到损害)问题
• 严重性3(次要功能)问题的可接受数量

根据应用程序的大小等，"可接受的数字"自然是一个很糊涂的数字。

满足这些准备工作后，我将召开一次所有利益相关者会议(QA负责人，开发负责人，应用程序支持负责人等)，并审查未解决的问题列表，并确保就分配给以下人员的严重性达成共识显着的问题。一旦我确认没有严重的Sev 1和Sev 2问题，我将收到每个利益相关者的"通过/不通过"电话。如果每个人都说"开始"，那么我很乐意转向生产。如果至少一个利益相关者说"不接受"，我们将检查"不接受"的原因，并在必要时采取措施解决其背后的问题。

在较小的项目中，过程可能会更简化，并且如果它只是一个人的操作，则前提条件可能会简单得多，即"应用程序提供了合理的好处，同时有(显然)可接受的错误数量，让我们把它放在那里！"。只要应用程序提供的好处超过了对bug的烦恼，尤其是如果我们遵循"尽早发布且经常发布"的准则，则可能对我们有用。

回答

玛伦，

我发现，如果我们具有全面的自动化测试，则除非所有软件都通过测试，否则完全不负责运送软件。自动化测试意味着这些区域是我们意识到的过去可能发生的核心功能或者错误，并且可以进行修复以通过测试。运送未通过100％自动测试的软件是不负责任的。

回答

乔恩

我并不是说测试脚本暗示了自动化测试。我指的是一种更为传统的方法，它分步列出了要测试什么以及如何对其进行测试。

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

回答

我一直想尝试的一种有趣的测试方法是"错误播种"。这样的想法是，我们需要一个人将故意错误归入不同的类别。

例如：

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

"播种者"准确记录了为插入这些错误所做的更改，以便可以快速还原它们。当测试团队发现种子错误时，他们也在寻找真正的错误，但不知道它们之间的区别。从理论上讲，如果测试团队发现了90％的种子关键错误，那么他们可能已经找到了一定比例的实际关键错误。

从这些统计信息中，我们可以开始判断何时可以发布某个版本。当然，由于发现(实际或者种子)错误的随机性，这甚至还不能做到万无一失，但总比完全不知道要释放多少个bug更好。

回答

测量在" showstopper"或者主要功能错误之间投入产品的测试时间，可以使我们知道自己已经快到了。随着新功能的不断涌入，产品测试团队通常会发现他们报告的大多数错误都是严重的功能错误。随着这些问题的解决，通常会出现大量次要，合适和完成类型的问题，目的是提高交互的流畅性和清晰度。总的来说，它们在产品质量上有很大的不同，但是每个都不是非常重要的。随着这些问题的修复和测试的继续，我们可能会继续获得错误报告，因为测试人员会进入错误情况和异常的使用模式。到那时，这取决于我们何时看到发布的业务价值与未被发现的放映商的风险。