每次我需要估计一个项目的时间(或者查看其他人的估计)时，都会分配时间进行测试/错误修复，这将在alpha版本和生产版本之间进行。我非常了解，就未知大小的问题集进行到目前为止的估计并不是成功估计的好方法。但是，由于种种原因，一开始总是将确定的小时数分配给该工作部分。而且，此初始估算值与实际的最终值相差越远，与调试相关的人员在"超出"估算值时将不得不承受的痛苦越多。

所以我的问题是：就这样进行估算，我们看到的最佳策略是什么？占开发人员总预算的固定比例？设置小时数(期望会增加)？还有别的吗

还有其他需要考虑的问题：如果客户负责测试(而不是内部质量检查)，而我们必须分配一定的时间来响应可能会或者可能不会发现的错误(我们需要这样做)，我们将如何以不同的方式回答这个问题找出修复错误但不用于测试的时间估算值)

解决方案

回答

也许我只是编写错误的代码，但是我喜欢在开发人员和测试之间保持1：1的比例。我不等到alpha进行测试，而是在整个项目中进行测试。逻辑吗？根据发布时间表，从开发开始到alpha，beta和发布日期之间可能会有很多时间。此外，我们发现错误的时间越早，则越容易(且更便宜)修复它们。

一个好的测试人员在每次入住后都会很快发现错误，这是非常宝贵的。 (或者，更好的是，在从PR或者DPK进行检入之前)，我仍然非常熟悉我的代码，因此大多数错误修复都变得非常简单。通过这种方法，我倾向于将大约15％的开发时间留给错误修复。至少在我估算时。因此，在16周的跑步中，我会离开2-3周左右。

回答

只有以前项目中大量的累积统计信息才能提供准确的估算值。如果我们有一组明确定义的需求，则可以对我们拥有多少个用例进行粗略的计算。正如我所说，我们需要为团队提供一些统计数据。我们需要知道每个位置的平均错误数，才能估算错误总数。如果团队没有这样的数字，则可以使用行业平均数字。在估计了LOC(用例数* NLOC)和每行平均错误之后，我们可以对发布项目所需的时间进行或者多或者少的准确估计。

根据我的实际经验，用于错误修复的时间等于或者大于原始实现的时间(在99％的情况下:))。

回答

这实际上取决于很多因素。仅举几例：我们正在使用的开发方法，我们拥有的测试资源的数量，项目在此阶段可用的开发人员数量(许多项目经理最终会将人们转移到新的事物上)。

正如罗布·罗尼克(Rob Rolnick)所说，在规范不好的情况下，1：1是一个很好的经验法则，客户端可能会推送"错误"，而这些错误实际上是错误指定的功能。我最近参与了一个使用多个版本的项目，但是由于糟糕的规范，比实际开发花费了更多的时间来解决错误。

确保良好的规范/设计，并减少测试/错误修复时间，因为这将使测试人员更容易看到要测试的内容和方式，并且任何客户都不会有更多的余地来推动额外的功能。

回答

根据测试圣经：

测试计算机软件

p。 31："测试占产品初始开发的45％。"因此，一个良好的经验法则是在最初的开发过程中将大约一半的精力分配给测试。