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