5

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

4

6 回答 6

8

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

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

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

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

在较小的项目中,该过程可能会更加精简,如果它只是一个人的操作,那么您的前提条件可能会简单得多,即“应用程序提供了合理的好处,同时具有(显然)可接受数量的错误 -让我们把它放在那里!”。只要应用程序提供的好处克服了错误带来的烦恼,特别是如果您遵循“尽早且经常发布”指南,那可能对您有用。

于 2008-08-28T13:29:17.427 回答
3

首先,你永远不会停止测试。当完成测试并发布它时,这意味着您的用户正在测试而不是您。

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

最后,这非常适合您的情况。在某些项目中,我们有 3 周的 beta 测试期,在此期间,很多人会在最小的更改推出之前入侵系统。在其他领域(不太重要),只需另一个开发人员的点头,就可以将小的更改移出。

于 2008-08-28T13:25:17.327 回答
2

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

例如:

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

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

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

于 2008-08-28T14:23:28.747 回答
1

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

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

于 2008-08-28T13:23:50.763 回答
1

当所有主要的表演停止者都走了。

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

要真正找到系统中的所有错误是不可能的,所以有时唯一真正的规则就是直接发布

于 2008-08-28T13:29:12.310 回答
0

衡量在“令人瞩目”或主要功能错误之间投入产品的测试时间可以让您知道您快到了。在产品中出现新功能的快速变化时,测试团队通常会发现他们报告的大多数错误都是严重的功能错误。在处理这些问题时,通常会出现大量旨在提高交互的流畅性和清晰度的小问题、适合和完成类型的问题;总的来说,它们对产品质量有很大的影响,但每一个都不是非常重要。随着这些问题的修复和测试的继续,您可能会继续收到错误报告,因为测试人员会遇到错误情况和不寻常的使用模式。

于 2008-09-18T20:26:33.473 回答