我有一个产品 X，我们每个月都会向客户 C 交付它，包括错误修复、增强功能、新开发等）每个月，我都被要求错误地“保证”产品的质量。
为此，我们使用了从我们所做的测试中获得的一些统计数据，例如：
和其他各种数字。
由于我们不详述的原因，不可能每次都测试所有内容。
所以，我的问题是：
如何估计我的软件中仍然存在的错误的数量和类型？ 我必须遵循哪些测试策略来确保产品是好的？
我知道这是一个悬而未决的问题，但是，嘿，我也知道没有简单的解决方案。
谢谢。
【问题讨论】：
标签： testing
我认为您永远无法真正估计应用程序中的错误数量。除非您使用允许正式证明的语言和流程，否则您永远无法确定。您的时间可能最好花在设置流程以尽量减少错误，而不是尝试估计您有多少错误。
您可以做的最重要的事情之一是拥有一支优秀的 QA 团队和良好的工作项目跟踪。您可能无法每次都进行完整的回归测试，但如果您有自上次发布以来对应用程序所做更改的列表，那么您的 QA 人员（或人员）可以将他们的测试重点放在预计会受到影响的应用。
另一件有用的事情是单元测试。您覆盖的代码库越多，您就越有信心相信一个领域的变化不会无意中影响另一个领域。我发现这非常有用，因为有时我会更改某些内容并忘记它会影响应用程序的另一部分，并且单元测试会立即显示问题。通过单元测试并不能保证您没有破坏任何东西，但它们可以帮助您提高对所做更改有效的信心。
此外，这有点多余且显而易见，但请确保您拥有良好的错误跟踪软件。 :)
【讨论】：
问题是谁要求你提供统计数据。
如果是非技术人员，请伪造统计数据。我所说的“假”是指“提供任何不可避免的无意义但真实的数字”，就像你提到的那种。
如果是没有CS背景的技术人员，应该告诉他们停机问题，这是无法确定的，比剩余的错误计数和分类更简单。
有很多关于软件质量的指标和工具（代码覆盖率、圈复杂度、编码指南和执行它们的工具等）。在实践中，可行的方法是尽可能多地自动化测试，让人类测试人员尽可能多地进行非自动化测试，然后祈祷。
【讨论】：
我认为保持简单是最好的方法。按严重程度对错误进行分类，并按严重程度递减的顺序解决它们。
通过这种方式，您可以交付尽可能高质量的构建（剩余的重大错误数量是我衡量产品质量的方式，而不是一些复杂的统计数据）。
【讨论】：
大多数敏捷方法都非常清楚地解决了这个难题。你不能测试一切。您也不能在发布之前对其进行无限次测试。所以程序是依赖于错误的风险和可能性。风险和可能性都是数值。两者的乘积都会为您提供一个 RPN 编号。如果数量少于 15，您将发送一个测试版。如果您可以将其减少到少于 10 个，您可以发布产品并将错误推送到未来的版本中进行修复。
如何计算风险？
如果是崩溃，则为 5 如果它崩溃但您可以提供解决方法，那么它的数字小于 5。 如果错误减少了功能，那么它是 4
如何计算可能性？
你可以在每次运行时重新生成它，它是 5。 如果提供的解决方法仍然导致它崩溃，那么小于 5
嗯，我很想知道是否有其他人使用这个方案并渴望知道他们在这方面的进展。
【讨论】：
一根绳子有多长？最终是什么造就了优质产品？错误给出了一些迹象是的，但涉及许多其他因素，单元测试覆盖率是 IMO 的关键因素。但根据我的经验，影响产品是否被视为质量的主要因素是对正在解决的问题有很好的理解。经常发生的情况是，产品要解决的“问题”没有被正确理解，开发人员最终发明了解决他们头脑中充实的问题的解决方案，而不是真正的问题，因此产生了“错误” .我是迭代 Agile 开发的坚定支持者，这样产品就可以不断地针对“问题”进行访问，并且产品不会偏离其目标太远。
【讨论】：
我听到的问题是，我如何估计我的软件中的错误？以及我使用什么技术来确保质量好？
这里有几种方法，而不是完整的课程。
如何估计我的软件中的错误？
从历史开始，您知道在测试期间发现了多少（希望如此），并且知道事后发现了多少。您可以使用它来估计查找错误的效率（DDR - 缺陷检测率是其中的一个名称）。如果您可以证明在某个一致的时间段内，您的 DDR 是一致的（或改进的），您可以通过猜测产品发布后发现的发布后缺陷的数量来提供对发布质量的一些洞察。
我使用什么技术来确保质量好？
对错误的根本原因分析将指出存在错误的特定组件、创建错误代码的特定开发人员、缺乏完整需求导致实现不符合预期的事实等。
项目审查会议，以快速确定什么是好的，这样可以重复这些事情，什么是坏的，并找到不再重复这些事情的方法。
希望这些能给你一个好的开始。祝你好运！
【讨论】：
似乎一致认为应该将重点放在单元测试上。错误跟踪是产品质量的一个很好的指标，但只有你的测试团队才能准确。如果您使用单元测试，它会为您提供可衡量的代码覆盖率指标并提供回归测试，因此您可以放心，自上个月以来您没有破坏任何东西。
我的公司依赖于系统/集成级别测试。我看到由于缺乏回归测试而引入了很多缺陷。我认为开发人员对需求的实现偏离用户愿景的“错误”是一个单独的问题，正如 Dan 和 rptony 所说，敏捷方法最好解决这个问题。
【讨论】：