每次我必须估计一个项目的时间（或查看其他人的估计）时，都会为测试/错误修复分配时间，这些时间将在 alpha 和生产版本之间完成。我非常清楚，就未知大小的问题集估计到目前为止的未来并不是成功估计的好方法。然而，由于各种原因，一开始就为这部分工作分配了一定的小时数。而且这个初始估计值与真实的最终值越远，那些参与调试的人在以后“超过”估计值时将不得不承受更多的痛苦。
所以我的问题是：关于做出这样的估计，你见过的最佳策略是什么？总体开发估算的固定百分比？设置小时数（期望它会增加）？还有什么？
其他需要考虑的事情：如果客户负责测试（而不是内部 QA），您将如何以不同的方式回答这个问题，并且您必须分配一定的时间来响应他们可能会或可能不会发现的错误（所以您需要计算出修复错误但不用于测试的时间估计）
这真的取决于很多因素。仅举几例：您正在使用的开发方法、您拥有的测试资源数量、项目此阶段可用的开发人员数量（许多项目经理最终会将人们转移到新事物上）。
正如 Rob Rolnick 所说，1:1 是一个很好的经验法则——但是在规范不好的情况下，客户端可能会推送实际上是指定不当的特性的“错误”。我最近参与了一个项目，该项目使用了许多版本，但由于糟糕的规范，比实际开发花费更多的时间在错误修复上。
确保良好的规范/设计和您的测试/错误修复时间将减少，因为测试人员将更容易看到测试的内容和方式，并且任何客户将有更少的余地来推动额外的功能。
也许我只是写了错误的代码，但我喜欢开发人员和测试人员之间的比例为 1:1。我不会等到 alpha 进行测试，而是在整个项目中进行。逻辑？根据您的发布计划，从开发开始到您的 alpha、beta 和发布日期之间可能有很长的时间。此外，越早发现错误，修复它们就越容易（也更便宜）。
一个优秀的测试人员在每次签入后很快就会发现错误，这是非常宝贵的。（或者，更好的是，在从 PR 或 DPK 签入之前）简单地说，我仍然非常熟悉我的代码，因此大多数错误修复变得非常简单。使用这种方法，我倾向于将大约 15% 的开发时间留给错误修复。至少在我做估计的时候。所以在 16 周的跑步中，我会离开大约 2-3 周。
只有从以前的项目中积累的大量统计数据才能帮助您给出精确的估计。如果您有一组明确定义的需求，您可以粗略计算您有多少用例。正如我所说，您需要为您的团队提供一些统计数据。您需要知道每个位置的平均错误数来估计错误总数。如果您的团队没有这样的数字，您可以使用行业平均数字。在您估计 LOC（用例数 * NLOC）和平均每行错误数之后，您可以或多或少地准确估计发布项目所需的时间。
根据我的实践经验，花在错误修复上的时间等于或更多（在 99% 的情况下:)）比花在原始实现上的时间。
使用具有按合同设计或“代码合同”（前置条件、检查断言、后置条件、类不变量等）的语言来获得尽可能接近您的类和类特性（方法和属性）的“测试”可能的。然后使用 TDD 用它的合约来测试你的代码。
尽可能多地使用自建代码生成。生成的代码是经过验证的、可预测的、更容易调试的，并且比全手工编码的代码更容易/更快地修复。为什么要写你能生成的东西？但是，不要使用 OPG（other-peoples-generators）！您生成的代码是您控制和了解的代码。
您可以期望在您的项目过程中花费一个反向比率 - 也就是说 - 您将在项目的开始 (1:1) 中编写大量的手动代码和合同。当您看到模式时，请教您编写的代码生成器为您生成代码并重用它。生成的越多，设计、编写、调试和测试的就越少。到项目结束时，您会发现您的方程式已经倒转：您编写的核心代码减少了，您的重点转移到了“叶子代码”（最后一英里）或专业化（与通用和生成） 代码。
最后——得到一个代码分析器。一个好的、自动化的代码分析规则系统和引擎将为您节省大量时间来查找“愚蠢的错误”，因为人们在使用特定语言编写代码时存在众所周知的陷阱。在 Eiffel，我们现在有了 Eiffel Inspector，我们不仅使用它附带的 90 多条规则，而且正在学习为我们自己发现的“陷阱”编写我们自己的规则。这样的分析器不仅可以为您节省错误，还可以增强您的设计——即使是 GREEN 程序员也能很快“理解”并尽早停止犯新手错误并更快地学习！
重写现有系统的经验法则是这样的：“如果用 10 年的时间来编写，那么将需要 10 年的时间来重新编写。” 在我们的案例中，使用 Eiffel、按合同设计、代码分析和代码生成，我们在 4 年内重写了一个 14 年的系统，并将在 4 1/2 内完全交付。新系统比旧系统复杂大约 4 到 5 倍，所以这说明了很多！
