应该分配多少时间用于测试&错误修复

时间:2008-09-07 13:42:09

标签: project-management estimation

每当我必须估计项目的时间(或审查其他人的估计)时,就会在alpha版本和生产版本之间分配测试/错误修复的时间。我非常清楚,对于未知大小的问题集,到目前为止对未来的估计并不是成功估算的好方法。然而,由于各种原因,一定程度的小时数总是在一开始就分配给这部分工作。而这个初始估计距离真实的最终值越远,那些参与调试的人就越需要在他们“超过”估计值时采取这种悲伤。

所以我的问题是:你在制定这样的估算时看到的最佳策略是什么?整体开发估计的百分比是平的吗?设定小时数(期望它会上升)?别的什么?

还需要考虑的其他事项:如果客户负责测试(而不是内部质量保证),您将如何回答这个问题,并且您必须分配一定的时间来回应他们可能找到或未找到的错误(所以你需要弄清楚修复bug的时间估计而不是测试)

5 个答案:

答案 0 :(得分:9)

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

正如Rob Rolnick所说,1:1是一个很好的经验法则 - 但是在规范不好的情况下,客户端可能会推送“错误”,这些错误实际上是指定错误的功能。我最近参与了一个使用了许多版本的项目,但是由于可怕的规范,花在修复bug上的时间比实际开发花费的时间多。

确保良好的规格/设计,并且您的测试/错误修复时间将会减少,因为测试人员可以更轻松地查看测试内容和测试方法,并且任何客户都可以通过更少的方式来推动额外功能。

答案 1 :(得分:6)

也许我只是编写错误的代码,但我喜欢开发人员和测试之间的比例为1:1。我不要等到alpha测试,而是在整个项目中完成。逻辑?根据您的发布计划,开发开始与您的alpha,beta和发货日期之间可能会有很长的时间。此外,越早捕获错误,它们就越容易(也越便宜)修复。

一位优秀的测试员,在每次办理登机手续后很快发现错误,这是非常宝贵的。 (或者,更好的是,在从PR或DPK办理登机手续之前)简单地说,我仍然非常熟悉我的代码,因此大多数错误修复变得非常简单。通过这种方法,我倾向于将大约15%的开发时间留给bug修复。至少在我做估计的时候。因此,在16周的运行中,我会离开大约2-3周。

答案 2 :(得分:5)

来自测试圣经:

Testing Computer Software Testing Computer Software

页。 31:“测试[...]占产品初始开发的45%。”因此,一个好的经验法则是在初始开发过程中将大约一半的精力分配给测试。

答案 3 :(得分:4)

以前项目中只有大量累积的统计数据可以帮助您进行精确估算。如果您有一组明确定义的要求,则可以粗略计算您拥有的用例数。正如我所说,你需要为你的团队提供一些统计数据。您需要知道平均每个位置的错误数以估计总错误数。如果您的团队没有此类号码,则可以使用industry average numbers。在估计了LOC(用例数量* NLOC)和平均每行错误后,您可以对发布项目所需的时间进行或多或少的准确估计。

根据我的实际经验,花在修复bug上的时间等于或多于(99%的情况:)),而不是花在原始实现上的时间。

答案 4 :(得分:2)

使用具有按合同设计或"代码合同的语言" (先决条件,检查断言,后置条件,类不变量等)以获得"测试"尽可能接近您的类和类功能(方法和属性)。然后使用TDD通过合同测试代码。

尽可能多地使用自建代码生成。与所有手动编码的代码相比,生成的代码经过验证,可预测,更易于调试,并且更容易/更快地修复。为什么要写出你能产生的东西?但是,不要使用OPG(其他人发电机)!您生成的代码是您控制和知道的代码。

您可以期望在项目过程中花费一个反转比率 - 也就是说 - 您将在项目的开始(1:1)中编写大量手工代码和合同。当您看到模式时,请教您编写代码生成器以生成代码并重用它。生成的越多,设计,编写,调试和测试的次数就越少。在项目结束时,您会发现您的等式已经颠倒过来:您正在编写较少的核心代码,并且您的重点转移到您的"叶码" (最后一英里)或专业(与广义和生成)代码。

最后 - 获取代码分析器。一个好的,自动化的代码分析规则系统和引擎将为您节省大量的时间查找"愚蠢的错误"因为在人们如何用特定语言编写代码方面存在众所周知的问题。在埃菲尔,我们现在有埃菲尔检查员,我们不仅使用它附带的90多个规则,而且正在学习为我们自己发现的"陷阱"编写我们自己的规则。这样的分析仪不仅可以节省您的错误,还可以增强您的设计 - 即使是绿色程序员也可以获得它#34;相当快速,不再提前做出新手错误,学得更快!

重写现有系统的经验法则是:"如果需要10年的时间来编写,则需要10年才能重写。"在我们的案例中,使用Eiffel,按合同设计,代码分析和代码生成,我们在4年内重新编写了一个14年的系统,并将完全交付4 1/2。新系统比旧系统复杂4倍到5倍,所以这说了很多!