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

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

• 重新打开率(重新打开的错误数量/已测试的已纠正错误的数量)
• 新的错误率(新的错误数量，包括回归，测试期间发现的错误/已测试的已纠正错误的数量)
• 对于每个新的增强功能，新的错误率(为此增强功能找到的错误数量/工时)

和其他各种数字。

由于我们不愿讨论的原因，不可能每次都对所有内容进行测试。

所以，我的问题是：

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

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

谢谢。

解决方案

回答

我认为保持简单是最好的方法。按严重性对错误进行分类，并按照严重性从高到低的顺序进行处理。

这样一来，我们就可以交付最高质量的产品(与一些复杂的统计数据相比，剩下的大量重大错误是我如何评估产品质量的)。

回答

问题是谁需要我们提供统计信息。

如果是非技术人员，请伪造统计数据。所谓"虚假"，是指"提供我们所提到的那种不可避免的毫无意义的但实数"。

如果是没有CS技术背景的技术人员，则应该向他们告知停止问题，这是无法确定的，而且比对剩余的bug进行计数和分类更为简单。

关于软件质量，有很多度量标准和工具(代码覆盖率，圈复杂度，编码准则和实施这些准则的工具等)。在实践中，有效的方法是使尽可能多的测试自动化，让人类测试人员进行尽可能多的非自动化测试，然后祈祷。

回答

一段绳子有多长？最终，什么才是优质的产品？错误表明是可以的，但涉及许多其他因素，单元测试的覆盖范围是IMO中的关键因素。但是以我的经验，影响产品是否可以视为质量的主要因素是对要解决的问题的充分理解。通常会发生的事情是，该产品要解决的"问题"没有得到正确的理解，开发人员最终发明了解决方案，以解决他们脑子里充血的问题，而不是真正的问题，因此产生了"错误" 。我强烈支持迭代式敏捷开发，因为这种方式可以使产品不断地针对"问题"进行访问，并且产品不会偏离其目标。

回答

我认为我们无法真正估算出应用程序中的错误数量。除非我们使用允许形式证明的语言和过程，否则我们将永远无法真正确定。我们可能需要花费更多的时间来设置流程以最大程度地减少错误，而不是尝试估计有多少错误。

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

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

另外，这有点多余而且很明显，但是请确保我们具有良好的错误跟踪软件。 :)

回答

大多数敏捷方法都非常清楚地解决了这一难题。我们无法测试所有内容。在发布之前，我们也无法对其进行无数次测试。因此，程序要依靠错误的风险和可能性。风险和可能性都是数值。两者的乘积为我们提供一个RPN号。如果数量少于15，则我们将发布测试版。如果我们可以将其降低到少于10个，则可以发货，并在以后的发行版中修复该错误。

如何计算风险？

如果它崩溃了，那么它是5
如果它崩溃了，但是我们可以提供解决方法，那么它的数量应小于5.
如果错误降低了功能，则其值为4

如何计算可能性？

我们可以在每次运行时重制它吗，它是5.
如果提供的解决方法仍然导致崩溃，则小于5

好吧，我很想知道是否还有其他人正在使用此方案，并渴望知道他们在此方面的里程。

回答

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

这里有几种方法，而不是全部学习。

如何估算软件中的错误？

从历史开始，我们知道(希望)在测试过程中发现了多少，并且知道事实之后发现了多少。我们可以使用它来估计发现错误的效率(DDR缺陷检测率就是其中一个名称)。如果我们可以证明某个持续时间段内的DDR是一致的(或者不断提高的)，则可以通过猜测产品发布后将发现的发布后缺陷的数量来对发布质量有所了解。

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

对错误的根本原因分析将为我们指出存在错误的特定组件，创建错误代码的特定开发人员，缺乏完整需求的事实导致实现与期望不符等。

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

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

回答

似乎已经达成共识，即应该将重点放在单元测试上。错误跟踪可以很好地指示产品质量，但是对于测试团队而言，它是准确的。如果我们使用单元测试，它将为我们提供可衡量的代码覆盖率指标，并提供回归测试，因此我们可以放心，自从上个月以来，我们还没有遇到任何问题。

我的公司依靠系统/集成级别的测试。我看到由于缺乏回归测试而引入了许多缺陷。我认为，开发人员对需求的实现偏离用户视野的"错误"是一个单独的问题，如Dan和rptony所述，可以通过敏捷方法论来解决。