估计测试工作量占开发时间的百分比
是否有人使用经验法则来估计测试所需的工作量占开发所需工作量的百分比？如果是的话，你使用的百分比是多少？
Does anyone use a rule of thumb basis to estimate the effort required for testing as a percentage of the effort required for development? And if so what percentage do you use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
根据我的经验，25%的精力花在分析上； 50% 用于设计、开发和单元测试；剩余 25% 用于测试。根据项目的性质、资源知识、投入质量和实际情况，大多数项目都会符合此经验法则的 +/-10% 差异。可以在这些百分比内添加项目管理开销，或者作为 10-15% 范围内的顶部开销。
From my experience, 25% effort is spent on Analysis; 50% for Design, Development and Unit Test; remaining 25% for testing. Most projects will fit within a +/-10% variance of this rule of thumb depending on the nature of the project, knowledge of resources, quality of inputs & outputs, etc. One can add a project management overhead within these percentages or as an overhead on top within a 10-15% range.
Google 测试博客最近讨论了此问题：
（剪断）
The Google Testing Blog discussed this problem recently:
(snip)
当您估计测试时，您需要确定测试的范围 - 我们是在谈论单元测试、功能、UAT、接口、安全性、性能压力和体积吗？
如果您正在进行瀑布项目，您可能会遇到一些相当稳定的开销任务。留出时间准备任何规划文件、时间表和报告。
对于功能测试阶段（我是“系统测试人员”，所以这是我的主要参考点），不要忘记包括计划！测试用例通常至少需要与执行所需的工作一样多的工作来从需求/规范/用户故事中提取。此外，您还需要花一些时间来提出缺陷/重新测试。对于较大的团队，您需要考虑测试管理 - 安排、报告、会议。
一般来说，我的估计是基于所交付功能的复杂性而不是开发工作的百分比。然而，这确实需要访问至少一组高级指令。多年的测试经验使我发现，特定复杂性的测试需要 x 小时的准备和执行时间。某些测试可能需要额外的数据设置工作。一些测试可能涉及与外部系统协商，并且持续时间远远超过所需的工作量。
但最终，您需要在整个项目的背景下对其进行审查。如果您的估计远高于 BA 或开发的估计，那么您的基本假设可能有问题。
我知道这是一个老话题，但我现在正在重新审视它，并且项目经理一直对此感兴趣。
When you're estimating testing you need to identify the scope of your testing - are we talking unit test, functional, UAT, interface, security, performance stress and volume?
If you're on a waterfall project you probably have some overhead tasks that are fairly constant. Allow time to prepare any planning documents, schedules and reports.
For a functional test phase (I'm a "system tester" so that's my main point of reference) don't forget to include planning! A test case often needs at least as much effort to extract from requirements / specs / user stories as it will take to execute. In addition you need to include some time for defect raising / retesting. For a larger team you'll need to factor in test management - scheduling, reporting, meetings.
Generally my estimates are based on the complexity of the features being delivered rather than a percentage of dev effort. However this does require access to at least a high-level set of instructions. Years of doing testing enables me to work out that a test of a particular complexity will take x hours of effort for preparation and execution. Some tests may require extra effort for data setup. Some tests may involve negotiating with external systems and have a duration far in excess of the effort required.
In the end, though, you need to review it in the context of the overall project. If your estimate is well above that for BA or Development then there may be something wrong with your underlying assumptions.
I know this is an old topic but it's something I'm revisiting at the moment and is of perennial interest to project managers.
几年前，在安全关键领域，我听说过有一天对十行代码进行单元测试。
我还观察到 50% 的精力用于开发，50% 的精力用于测试（不仅仅是单元测试）。
Some years ago, in a safety critical field, I have heard something like one day for unit testing ten lines of code.
I have also observed 50% of effort for development and 50% for testing (not only unit testing).
您是在谈论自动化单元/集成测试还是手动测试？
对于前者，我的经验法则（基于测量）是开发时间增加 40-50%，即如果开发一个用例需要 10 天（在 QA 和严重的错误修复发生之前），那么编写好的测试还需要 4 到 5 天- 尽管这最好发生在开发之前和开发期间，而不是之后。
Are you talking about automated unit/integration tests or manual tests?
For the former, my rule of thumb (based on measurements) is 40-50% added to development time i.e. if developing a use case takes 10 days (before an QA and serious bugfixing happens), writing good tests takes another 4 to 5 days - though this should best happen before and during development, not afterwards.
当您谈到测试时，您可能指的是瀑布式或敏捷测试开发。在敏捷环境中，开发人员应该花费 50% 的时间来开发和维护测试。
但是，当重构和手动验证时间到来时，这 50% 的额外费用将节省您的时间。
When you speak of tests, you could mean waterfall or agile test development. In an agile environment, developers should spend 50% of their time developing and maintaining tests.
But that 50% extra will save you time when the re-factoring and manual verification time comes.
测试时间可能比开发时间与功能范围更密切相关。我还认为（也许有争议）测试时间与开发团队的技能相关。
对于 6 到 9 个月的开发工作，我要求绝对至少 2 周的测试时间，由精通要测试的软件的实际测试人员（而不是开发团队）执行（即 2 周的时间）不包括加速时间）。这是一个拥有约 5 名开发人员的项目。
Testing time is probably more closely correlated to feature scope than development time. I'd also argue (perhaps controversially) that testing time is correlated to the skill of your development team.
For a 6-to-9 month development effort, I demand a absolute minimum of 2 weeks testing time, performed by actual testers (not the development team) who are well-versed in the software they will be testing (i.e., 2 weeks does not include ramp-up time). This is for a project that has ~5 developers.
Gartner 在 2006 年 10 月指出，测试通常占用系统集成项目工作量的 10% 到 35%。我认为它适用于瀑布方法。这是一个相当广泛的范围 - 但对标准产品的定制量和要集成的系统数量有很多依赖性。
Gartner in Oct 2006 states that testing typically consumes between 10% and 35% of work on a system integration project. I assume that it applies to the waterfall method. This is quite a wide range - but there are many dependencies on the amount of customisations to a standard product and the number of systems to be integrated.
我唯一考虑额外时间进行测试的情况是，如果我不熟悉将要使用的测试技术（例如，第一次使用 Selenium 测试）。然后，我可能会考虑 10-20% 的时间来加快工具的使用速度并让测试基础设施就位。
否则，测试只是开发的固有部分，并不需要额外的估计。事实上，我可能会增加对没有测试的代码的估计。
编辑：请注意，我通常首先编写代码测试。如果我必须事后介入并为现有代码编写测试，那么事情就会变慢。我发现测试优先的开发根本不会减慢我的速度，除了非常探索性的（阅读：扔掉的）编码。
The only time I factor in extra time for testing is if I'm unfamiliar with the testing technology I'll be using (e.g. using Selenium tests for the first time). Then I factor in maybe 10-20% for getting up to speed on the tools and getting the test infrastructure in place.
Otherwise testing is just an innate part of development and doesn't warrant an extra estimate. In fact, I'd probably increase the estimate for code done without tests.
EDIT: Note that I'm usually writing code test-first. If I have to come in after the fact and write tests for existing code that's going to slow things down. I don't find that test-first development slows me down at all except for very exploratory (read: throw-away) coding.
根据昨天的天气来判断。上次花了多长时间？您的趋势是变长还是变短？每家店都不一样。
由于 TDD，大多数敏捷商店需要的时间少得多，缺陷也少得多，并且解决问题的时间也更快。即便如此，大多数敏捷商店都会在测试/质量控制上花费一些可衡量的时间。
如果这是该应用程序的第一次测试运行，那么答案是“让我们看看”，然后进行尝试。这取决于你能多快回答问题，
- 它的可测试性如何，
- 有多少特征/功能
- 发现了多少缺陷，
- 问题解决的速度有多快，
- 代码循环多少次
通过测试，以及
- 测试被阻止了多少次
错误。
没有办法说清楚。你可以称之为 50% 或 175% 或更多，这并没有错。为什么不粗略猜测并乘以 Pi 呢？它不会比你能想到的任何其他答案更糟糕。
您应该（必须）知道现在需要多长时间，是变快还是变慢，以及覆盖范围是增加还是减少。有了这三点信息，你应该能够很好地猜测。
Judge by yesterday's weather. How long did it take last time? Are you trending longer or shorter? Each shop is different.
Most agile shops need a lot less time, have drastically fewer defects, and quicker time to resolve them because of TDD. Even so, most agile shops have some measurable time spent with testing/QC.
If this is the first test run for this application, then the answer is "lets see" followed by an attempt. It depends on how quick you can get questions answered,
- how testable it is,
- how many features/functions
- how many defects are discovered,
- how quickly issues are resolved,
- how many times the code cycles
through testing, and
- how many times testing is blocked by
bugs.
There is no way to tell. You could call it 50% or 175% or more, and not be wrong. Why not make a rough guess and multiply by Pi? It won't be much worse than any other answer you can make up.
You should (must) know how long it takes now and whether it's getting faster or slower, and whether the coverage is increasing or decreasing. With those three bits of information, you should be able to guess quite well.