这个问题有点抽象，但是我希望有人可以指出正确的方向。
我的问题是，相对于原始开发时间，一个软件项目的bug可以花多少时间。我意识到有很多决定性因素需要考虑，但我希望进行典型或平均的分类。
例如，如果项目A需要40个小时才能完成，另外还有10个修复错误，则该项目的比例为4：1。
如果另一个项目（B）需要10个小时才能完成，而另外8个bug则需要5：4的比率。
这是有文件记录/研究的概念吗？
感谢您提供的所有信息。我了解，由于涉及所有变量和环境因素，因此不可能对此类指标制定标准。在分配答案之前，我想知道该指标是否具有一致认可的名称，以便我做进一步的研究。我想了解一下自己可以自己生成度量标准并最终为我的项目提出基准标准的度量标准。
Answers:
分配给缺陷修复的总容量的平衡百分比等于缺陷注入率。
当然，有许多因素会影响该比率，其中包括：团队正在开发哪种产品，他们使用什么技术和技术实践，团队的技能水平，公司文化等等。
考虑到B团队，如果他们平均每完成10个工作单元就创建8个返工单元，那么工作这8个单元将创建新的6.4个返工单元。我们可以估计他们最终将要花费的总工作量为几何级数的总和：
10 + 8 + 6.4 + 5.12 + ...
错误的数量将随时间呈指数下降，但是B团队的指数具有如此大的系数，以至于它会非常缓慢地变为零。实际上，上述系列中前三个项的总和仅为24.4；前五个中的33.6；在前10名中，有45名；因此，B小组总结：缺陷注入率0.8；缺陷注入率0.8。功能发展，10/50 = 20％；修复缺陷，占80％。他们的可持续能力分配是20/80。
相比之下，A队的状况要好得多。他们的进度看起来像这样：
40 + 10 + 2.5 + 0.625 + ...
该系列的总和为53 1/3，因此A组的特征开发分配为40 /（53 1/3）= 75％，缺陷修复分配为25％，与缺陷注入率为10/40 = 0.25匹配。
实际上，在前三个之后，A队系列赛中的所有术语都可以忽略不计。实际上，这意味着Team A可以通过几个维护版本来解决所有的错误，而第二个版本的范围很小。这也造成了任何团队都可以做到的幻想。但不是B队。
在阅读戴维·安德森（David Anderson）的新书《看板》（Kanban）时，我就想到了这种等效性。（这本书是在另一个主题上，但是也解决了质量问题。）在讨论软件质量时，Anderson引用了Capers Jones的这本书“软件评估，基准和最佳实践”：
“ ...在2000年...为北美团队测量的软件质量...范围从每个功能点6个缺陷降低到每100个功能点少于3个缺陷，范围是200到1。 中点大约是每个缺陷1个缺陷0.6到1.0个功能点。这意味着团队通常花费90％以上的精力来修复缺陷。 “他引用了一个公司的一位同事提供的示例，该公司花费90％的时间来修复错误。 。
安德森从缺陷注入率到固定虚拟机容量分配的流畅程度（失败需求是术语）表明软件质量研究人员很清楚这两件事的等效性，并且可能已经有一段时间了。
我要在这里提出的推理路线中的关键词是“平衡”和“可持续”。如果我们放弃了可持续性，那么有一种显而易见的方法可以欺骗这些数字：您进行了初始编码，然后继续进行其他地方的编码，然后再由其他人来维护。或者，您将技术债务还清并转嫁给新的所有者。
显然，没有特别的分配适合所有团队。如果我们决定必须在漏洞上花费20％，那么，如果团队的缺陷注入率极低，那么他们将根本没有足够的漏洞来填补时间，而如果团队的漏洞注入率很高，那么他们的漏洞就可以解决。将继续积累。
我在这里使用的数学方法得到了简化。我忽略了诸如交易成本（计划和预算会议，验尸等）之类的东西，这会在一定程度上影响百分比。我也省略了模拟维持一种产品并同时开发另一种产品的方程式。但是结论仍然成立。在技术实践方面，如单元测试，持续集成，代码审查等，请尽您所能来降低缺陷注入率，从而降低故障需求。如果您每10个功能只能创建一个错误，那么您将有大量的空闲时间来开发新功能并满足您的客户的需求。
仅当从修复中获得的收益大于所投资的收益时，才应该花时间在bug上。
使用如下所示的矩阵（水平-修复错误所需的时间，垂直-错误的类型-对用户的影响）
| Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix | Fix
问题示例：
| Few hours | Many hours
--------------+--------------------------------------+---------------------------------
| Window moves 1px every 10 | Windows is painted incorrectly
Minor problem | times when you open the application. | every 100th time the app is open.
| Fix is: handle window resize event | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening | Poor performance when >100 users
| SQL connection. | are connected (unusable app)
| Fix: Fix invalid query + add nice | Fix: change architecture + DB
| message |
不同程度的严重性，工作量，风险等，矩阵可能会更加复杂
您甚至可以为每个错误创建一个等级，并根据等级对其进行修复。就像是：
Bug priority = Risk x Severity x Effort
*对于某些操作数，可能是（1-x），具体取决于您选择的比例：)
因此，回答您的问题：取决于错误的类型，可用时间/预算等。
这是高度可变的，不仅（当然）取决于团队的经验和素质，以及项目的难度（与使用新的OS内核制作另一个标准的Web应用程序不同），还取决于您的管理方法会用。
例如，在瀑布模型上，您可以在第一个测试阶段精确地设置第一个错误，但是在敏捷环境中，由于功能可能会发生变化，因此很难提出这样一条语句：“从现在开始，我们正在修正错误”对我来说，将功能更改视为错误是不公平的）
根据经验，我说这总是被低估的，并且很容易花费与“原始项目”相同的时间。
我认为这个问题是有偏见的：它是从以下前提开始的：修正错误与开发新功能相似。不是这种情况。
优秀的开发人员不会花费大量时间来调试代码，因为他的代码从一开始就没有错误。一个糟糕的开发人员将花费大量时间调试其代码，因为他无法创建合适的抽象来解决实际问题。
请注意，开发人员应自行对自己的代码进行单元测试。交付无错误的代码是他们的职责。因此很难将编码与调试分开。
这也是一个优先事项。在开发时，纠正错误所需的时间与将错误插入代码后的时间成指数关系。因此，与开发新功能相比，更正错误是更重要的。
因此，您应该谈论“花在测试上的时间”（集成测试，用户接受测试...），而不是谈论“花在错误上的时间”。