如何衡量软件产品的质量

Question

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

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

• 重新开放率（重新开放的错误数/已测试的更正错误数）
• 新的错误率（新的数量，包括回归数，测试期间发现的错误数/经过更正的错误检测数）
• 对于每个新增强功能，新增错误率（此增强功能发现的错误数量/任务数量）

以及其他各种数字。

由于我们不会进入的原因，每次测试一切都是不可能的。

所以，我的问题是：

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

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

感谢。

Answer 1

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

如果是非技术人员，请假冒统计数据。通过“假”，我的意思是“提供你所提到的那种不可避免的无意义但真实的数字。”

如果是没有CS背景的技术人员，他们应该被告知停止问题，这是不可判定的，并且比计算和分类剩余的错误更简单。

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

Answer 2

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

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

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

此外，这有点多余且显而易见，但请确保您拥有良好的错误跟踪软件。 ：）

Answer 3

我认为保持简单是最好的方法。按严重程度对您的错误进行分类，并按严重程度降低的顺序对其进行处理。

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

Answer 4

大多数敏捷方法都非常清楚地解决了这个难题。你无法测试一切。在你发布之前，你也不能无限次地测试它。所以程序是依赖于bug的风险和可能性。风险和可能性都是数值。两者的乘积都为您提供了RPN号码。如果数量小于15，则发送测试版。如果您可以将其降至10以下，则可以运送产品并将错误推送到将来的版本中。

如何计算风险？

如果它崩溃那么它是5 如果它崩溃但你可以提供一个工作，那么它的数字小于5。 如果bug减少了功能，那么它就是4

如何计算可能性？

你可以在每次跑步时重新制作它，它是5。 如果提供的工作仍然导致它崩溃然后小于5

好吧，我很想知道是否还有其他人使用这种方案，并渴望了解他们对此的看法。

Answer 5

一根绳子有多长？最终是什么使得优质产品？错误给出了一些指示是，但涉及许多其他因素，单元测试覆盖率是IMO的关键因素。但根据我的经验，影响产品质量与否的主要因素是对正在解决的问题的良好理解。通常情况是，产品要解决的“问题”没有被正确理解，开发人员最终会发现他们头脑中充实的问题的解决方案，而不是真正的问题，因此“错误”被制造出来。我是迭代Agile开发的坚定支持者，这样产品就可以不断地访问“问题”，产品不会偏离目标。

Answer 6

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

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

如何估算软件中的错误？

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

我使用哪些技巧来确保质量良好？

对您的错误进行根本原因分析将指向有缺陷的特定组件，创建错误代码的特定开发人员，缺乏完整要求导致实现与预期不匹配的事实等。

项目审核会议，以快速确定什么是好的，所以这些事情可以重复，什么是坏事，并找到一种方法不再做那些。

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

Answer 7

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

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