29

有没有人使用经验法则来估计测试所需的工作量占开发所需工作量的百分比？如果是这样，您使用多少百分比？

4

10 回答 10

15

根据我的经验，25% 的精力花在分析上；50% 用于设计、开发和单元测试；剩下的 25% 用于测试。根据项目的性质、资源知识、输入和输出的质量等，大多数项目将符合这一经验法则的 +/-10% 差异。可以在这些百分比内添加项目管理开销或作为开销在 10-15% 范围内。

于 2013-03-20T23:55:20.067 回答
11

谷歌测试博客最近讨论了这个问题：

所以一个天真的答案是写作考试要交 10% 的税。但是，我们纳税是为了得到回报。

（剪断）

这些好处在今天和明天都会转化为真正的价值。我编写测试，因为我获得的额外收益超过了 10% 的额外成本。即使我不包括长期利益，我今天从测试中获得的价值也很值得。我用测试开发代码的速度更快。多少，这取决于代码的复杂性。您尝试构建的东西越复杂（ifs/loops/dependencies 越多），测试的好处就越大。

于 2009-10-20T15:17:33.663 回答
8

当您估算测试时，您需要确定测试的范围——我们是在谈论单元测试、功能性、UAT、接口、安全性、性能压力和数量吗？

如果你在一个瀑布项目中，你可能有一些相当固定的开销任务。留出时间准备任何规划文件、时间表和报告。

对于功能测试阶段（我是“系统测试员”，所以这是我的主要参考点）不要忘记包括计划！测试用例通常需要至少与执行所需的工作量一样多的工作量来从需求/规范/用户故事中提取。此外，您需要花一些时间进行缺陷提升/重新测试。对于更大的团队，您需要考虑测试管理——日程安排、报告、会议。

一般来说，我的估计是基于所交付功能的复杂性，而不是开发工作的百分比。然而，这确实需要访问至少一组高级指令。多年的测试经验使我能够计算出，一个特定复杂性的测试将需要 x 小时的准备和执行工作。某些测试可能需要额外的数据设置工作。一些测试可能涉及与外部系统的协商，并且持续时间远远超过所需的工作量。

但是，最后，您需要在整个项目的背景下对其进行审查。如果您的估计远高于 BA 或开发的估计，那么您的基本假设可能有问题。

我知道这是一个老话题，但我现在正在重新讨论它，并且是项目经理长期感兴趣的话题。

于 2013-03-14T23:36:06.277 回答
3

Gartner 在 2006 年 10 月指出，测试通常会占用系统集成项目 10% 到 35% 的工作量。我假设它适用于瀑布方法。这是一个相当广泛的范围——但对标准产品的定制数量和要集成的系统数量有很多依赖性。

于 2012-01-30T09:26:48.163 回答
3

几年前，在一个安全关键领域，我听说过有一天要对十行代码进行单元测试。

我还观察到 50% 的开发工作和 50% 的测试工作（不仅仅是单元测试）。

于 2009-10-20T15:18:47.663 回答
3

您是在谈论自动化单元/集成测试还是手动测试？

对于前者，我的经验法则（基于测量）是增加了 40-50% 的开发时间，即如果开发一个用例需要 10 天（在 QA 和严重的错误修复发生之前），编写好的测试需要另外 4 到 5 天- 虽然这最好发生在开发之前和期间，而不是之后。

于 2009-10-20T15:19:00.907 回答
3

测试时间与功能范围的相关性可能比开发时间更密切。我还认为（也许是有争议的）测试时间与您的开发团队的技能相关。

对于 6 到 9 个月的开发工作，我要求绝对最少 2 周的测试时间，由精通他们将要测试的软件的实际测试人员（而不是开发团队）执行（即 2 周不包括加速时间）。这适用于拥有约 5 名开发人员的项目。

于 2009-10-20T15:19:46.660 回答
3

当您谈到测试时，您可能指的是瀑布式或敏捷测试开发。在敏捷环境中，开发人员应将 50% 的时间用于开发和维护测试。

但是，当重构和手动验证时间到来时，这 50% 的额外费用将为您节省时间。

于 2009-10-20T15:28:32.953 回答
1

唯一一次我会考虑额外的测试时间是如果我不熟悉我将使用的测试技术（例如，第一次使用 Selenium 测试）。然后，我可能会考虑 10-20% 的时间来加快工具的速度并建立测试基础设施。

否则测试只是开发的固有部分，不需要额外的估计。事实上，我可能会增加对未经测试完成的代码的估计。

编辑：请注意，我通常先编写代码测试。如果我必须在事后进入并为现有代码编写测试，这会减慢速度。我发现测试优先的开发并没有减慢我的速度，除了非常探索性（阅读：一次性）编码。

于 2009-10-20T15:21:17.523 回答
1

以昨天的天气来判断。上次用了多长时间？你的趋势是更长还是更短？每家店都不一样。

由于 TDD，大多数敏捷商店需要更少的时间、更少的缺陷和更快的时间来解决它们。即便如此，大多数敏捷商店在测试/QC 上花费了一些可衡量的时间。

如果这是此应用程序的第一次测试运行，那么答案是“让我们看看”，然后进行尝试。这取决于你能多快得到问题的回答， - 它的可测试性， - 有多少特性/功能 - 发现了多少缺陷， - 问题解决的速度， - 代码循环测试的次数，以及 - 如何很多时候测试被错误阻止。没有办法说。你可以称它为 50% 或 175% 或更多，这并没有错。为什么不粗略猜测并乘以 Pi？它不会比您可以弥补的任何其他答案更糟糕。

您应该（必须）知道现在需要多长时间，是变快还是变慢，以及覆盖范围是增加还是减少。有了这三点信息，你应该可以猜的很好。

于 2009-10-20T23:08:14.550 回答