如何衡量软件产品的质量

Question

我有一个产品 X，我们每个月都会向客户交付 C，包括错误修复、增强功能、新开发等。）每个月，我都会被要求“保证”产品的质量。

为此，我们使用从我们所做的测试中获得的大量统计数据，例如：

• 重新打开率（重新打开的错误数量/测试的已纠正错误数量）
• 新错误率（测试期间发现的新错误数，包括回归、发现的错误数/已测试的已纠正错误数）
• 对于每个新的增强功能，新的错误率（此增强功能发现的错误数量/工作日数）

以及其他各种数字。

每次都测试所有内容是不可能的，原因我们不会详细讨论。

所以，我的问题是：

如何估计软件中残留的错误数量和类型？我必须遵循哪些测试策略才能确保产品良好？

我知道这是一个悬而未决的问题，但是嘿，我也知道没有简单的解决方案。

谢谢。

Answer 1

我认为您永远无法真正估计应用程序中的错误数量。除非您使用允许正式证明的语言和流程，否则您永远无法真正确定。您的时间可能最好花在设置流程以最大限度地减少错误上，而不是尝试估计您有多少错误。

您可以做的最重要的事情之一就是拥有一支优秀的 QA 团队和良好的工作项目跟踪。您可能无法每次都进行完整的回归测试，但如果您有自上次发布以来对应用程序所做的更改的列表，那么您的 QA 人员（或个人）可以将测试集中在以下部分：预计会受到影响的应用程序。

另一件有用的事情是单元测试。您覆盖的代码库越多，您就越有信心一个区域的更改不会无意中影响另一个区域。我发现这非常有用，因为有时我会更改某些内容并忘记它会影响应用程序的另一部分，并且单元测试立即显示了问题。通过单元测试并不能保证您没有破坏任何东西，但它们可以帮助增强您所做的更改正在发挥作用的信心。

另外，这有点多余和明显，但请确保您有良好的错误跟踪软件。:)

Answer 2

问题是谁要求你提供统计数据。

如果是非技术人员，就伪造统计数据。我所说的“假”是指“提供任何不可避免的无意义但真实的数字”，就像你提到的那样。

如果是没有 CS 背景的技术人员，应该告诉他们停机问题，这是不可判定的，并且比对剩余 bug 进行计数和分类更简单。

有很多关于软件质量的指标和工具（代码覆盖率、圈复杂度、编码指南和执行它们的工具等）。在实践中，有效的方法是尽可能多地自动化测试，让人类测试人员尽可能多地进行非自动化的测试，然后祈祷。

Answer 3

我认为保持简单是最好的方法。按严重程度对错误进行分类，并按严重程度递减的顺序解决它们。

通过这种方式，您可以交付尽可能最高质量的构建（剩余的重大错误数量是我衡量产品质量的方式，而不是一些复杂的统计数据）。

Answer 4

大多数敏捷方法论都非常清楚地解决了这个困境。你无法测试一切。在发布之前你也不能无限次地测试它。因此，程序要依赖于错误的风险和可能性。风险和可能性都是数值。两者的乘积给出一个 RPN 数。如果数量少于 15，您将发布测试版。如果您可以将其减少到 10 以下，您就可以发布产品并推动该错误在未来的版本中得到修复。

如何计算风险？

如果是一次崩溃，则它的5件崩溃，但您可以在附近提供工作，那么它的数字小于5。如果 bug 减少了功能，则为 4

如何计算可能性？

你能在每次运行时重新生成它吗，它是 5。如果提供的解决方法仍然导致其崩溃，则少于 5

好吧，我很想知道是否还有其他人使用这个方案，并渴望知道他们在这方面的进展。

Answer 5

一段绳子有多长？最终是什么造就了优质产品？Bug 给出了一些迹象，是的，但还涉及许多其他因素，单元测试覆盖率是 IMO 的关键因素。但根据我的经验，影响产品是否被视为质量的主要因素是对正在解决的问题的充分理解。通常发生的情况是，产品要解决的“问题”没有得到正确理解，开发人员最终发明了解决方案来解决他们头脑中已经充实的问题，而不是真正的问题，因此产生了“错误” 。我是迭代的坚定支持者 敏捷 开发，这样产品就可以不断地解决“问题”，并且产品不会偏离其目标太远。

Answer 6

我听到的问题是，如何估计软件中的错误？我使用什么技术来确保良好的质量？

这里不提供完整的课程，而是提供几种方法。

如何估计软件中的错误？

从历史记录开始，您知道在测试期间发现了多少（希望如此），并且知道事后发现了多少。您可以使用它来估计查找错误的效率（DDR - 缺陷检测率是此名称的一个名称）。如果您可以证明在某个一致的时间段内，您的 DDR 是一致的（或改进的），您可以通过猜测产品发布后发现的发布后缺陷的数量来提供对发布质量的一些见解。

我使用什么技术来确保良好的质量？

对错误的根本原因分析将向您指出有错误的特定组件、创建有错误代码的特定开发人员、缺乏完整需求导致实现不符合预期的事实等。

项目审查会议可以快速确定哪些事情是好的，以便可以重复这些事情，哪些是坏的事情，并找到一种方法不再这样做。

希望这些能给您一个良好的开始。祝你好运！

Answer 7

似乎共识是应该将重点放在单元测试上。错误跟踪是产品质量的一个很好的指标，但只有您的测试团队才是准确的。如果您使用单元测试，它会为您提供可测量的代码覆盖率指标，并提供回归测试，以便您可以放心，自上个月以来您没有破坏任何内容。

我的公司依赖系统/集成级别测试。我看到由于缺乏回归测试而引入了很多缺陷。我认为开发人员对需求的实现偏离用户愿景的“错误”是一个单独的问题，正如 Dan 和 rptony 所说，最好通过敏捷方法来解决。