Here is a short article from Alan Page, Test Architect on Microsoft's Engineering Excellence team :
Some examples of things to consider in test estimation are:
Historical data - At the very least, you can estimate test design based on previous projects
Complexity - Complexity relates directly to testability. Simple applications can be tested more quickly than complex programs
Business goals - Is the application a prototype or demonstration application? Or, is it flight control software for a spaceship? The business goals influence the breadth and depth of the testing effort
Conformance / Compliance - If the application must conform to a standard, these requirements must be considered when estimating the testing task.
Is there any ratio or relationship between development time and testing time?
No, there's really not. You have to look at the functional requirements of your application to determine what needs tested and how long it's going to take.
I hope that you, as a project manager, plan to use an iterative development process like Scrum or some other agile method. I wouldn't think of the testing as a phase in the development that should be done after the development phase is finished, but as an essential part of the development process.
Unit tests are great and should be obligatory everywhere, but don't make the mistake of starting too late with the functional testing. If the project is as short as 6 months it's essential to have something up and running in half that time, even if it lacks most of the functionality, and start with that part of the testing while the rest of the features are being added.
A general rule of thumb is that testing will take 1/3 as long as development to do properly, but it can vary greatly depending on what you're doing and how extensive testing you expect.
I don't believe that is a question we can answer for you. To give you a reasonable estimate, we'd need to know several things:
What are your testing goals? (Code coverage, defects found/fixed, requirements tested, etc.) How much time have you spent testing on similar projects? What quality issues did you encounter on those projects? (Too many defects discovered, severity of defects acceptable/unacceptable) Have you done any test planning yet? How many defects did the unit testing uncover? Were there areas of greater/lesser concern? How did you address those? What kind of test analysis will you be doing?
There are metrics that you could use to help give you a rough estimate for this kind of work, but the problem is that they really need to be tuned to your environment to give meaningful estimates. One measure might suggest 2 months for testing, but you might not realize that your environment requires twice that time until you commit to 2 months and find out that you really needed 4.
I agree with the accepted answer from Pascal Paradis.
In addition, make sure you include test planning in your schedule. Planning can take just as long as actual testing, if not longer. This can be difficult because it requires finalized documentation from development team.
It's hard to answer such question. It most probably depends on your experience in similar projects. I just can provide you with some statistics for some projects I have worked in. You can see that it's hard to get a formula for the testing time in terms of the development time:
Project | Complexity | Development Time | Test Time | # Developers | # Testers
发布评论
评论（7）
这是来自 短文 href="http://blogs.msdn.com/alanpa/pages/about-me.aspx" rel="nofollow noreferrer">Alan Page，Microsoft 工程卓越团队的测试架构师：
Here is a short article from Alan Page, Test Architect on Microsoft's Engineering Excellence team :
不，确实没有。 您必须查看应用程序的功能需求，以确定需要测试哪些内容以及需要多长时间。
No, there's really not. You have to look at the functional requirements of your application to determine what needs tested and how long it's going to take.
我希望作为项目经理的您计划使用迭代开发流程，例如 Scrum 或其他一些敏捷方法。 我不认为测试是开发中的一个阶段，应该在开发阶段完成后完成，而是作为开发过程的重要组成部分。
单元测试很棒，并且在任何地方都应该是强制性的，但不要犯功能测试开始得太晚的错误。 如果项目只有 6 个月，那么即使缺少大部分功能，也必须在一半时间内启动并运行某些功能，并在添加其余功能的同时从该部分测试开始。
I hope that you, as a project manager, plan to use an iterative development process like Scrum or some other agile method. I wouldn't think of the testing as a phase in the development that should be done after the development phase is finished, but as an essential part of the development process.
Unit tests are great and should be obligatory everywhere, but don't make the mistake of starting too late with the functional testing. If the project is as short as 6 months it's essential to have something up and running in half that time, even if it lacks most of the functionality, and start with that part of the testing while the rest of the features are being added.
一般的经验法则是，测试需要的时间是开发的 1/3 才能正常完成，但它可能会根据您正在做什么以及您期望的测试范围而有很大差异。
A general rule of thumb is that testing will take 1/3 as long as development to do properly, but it can vary greatly depending on what you're doing and how extensive testing you expect.
我认为我们无法为您回答这个问题。 为了给您一个合理的估计，我们需要了解几件事：
您的测试目标是什么？ （代码覆盖率、发现/修复的缺陷、测试的需求等）
您在类似项目上测试花费了多少时间？
您在这些项目中遇到了哪些质量问题？ （发现的缺陷太多，缺陷的严重程度可接受/不可接受）
您已经制定了测试计划吗？
单元测试发现了多少缺陷？ 是否存在更值得关注/不太关注的领域？ 您是如何解决这些问题的？
您将进行什么样的测试分析？
您可以使用一些指标来帮助您对此类工作进行粗略估计，但问题是它们确实需要根据您的环境进行调整才能提供有意义的估计。 一项措施可能建议 2 个月进行测试，但您可能没有意识到您的环境需要两倍的时间，直到您承诺 2 个月并发现您确实需要 4 个月。
I don't believe that is a question we can answer for you. To give you a reasonable estimate, we'd need to know several things:
What are your testing goals? (Code coverage, defects found/fixed, requirements tested, etc.)
How much time have you spent testing on similar projects?
What quality issues did you encounter on those projects? (Too many defects discovered, severity of defects acceptable/unacceptable)
Have you done any test planning yet?
How many defects did the unit testing uncover? Were there areas of greater/lesser concern? How did you address those?
What kind of test analysis will you be doing?
There are metrics that you could use to help give you a rough estimate for this kind of work, but the problem is that they really need to be tuned to your environment to give meaningful estimates. One measure might suggest 2 months for testing, but you might not realize that your environment requires twice that time until you commit to 2 months and find out that you really needed 4.
我同意帕斯卡·帕拉迪斯接受的答案。
此外，请确保将测试计划纳入您的日程安排中。 规划的时间可能与实际测试的时间一样长，甚至更长。 这可能很困难，因为它需要开发团队的最终文档。
I agree with the accepted answer from Pascal Paradis.
In addition, make sure you include test planning in your schedule. Planning can take just as long as actual testing, if not longer. This can be difficult because it requires finalized documentation from development team.
这样的问题很难回答。 这很可能取决于您在类似项目中的经验。 我只能给你提供一些我参与过的项目的统计数据。你可以看到，从开发时间的角度来看，很难得到测试时间的公式：
项目| 测试时间。 复杂性 | 开发时间| 测试时间| # 开发者 | # 测试人员
A | 4 | 90 天 | 60 天 | 4 | 1
乙 | 1 | 60 天 | 30 天 | 2 | 1
C | 5 | 90 天 | 120 天 | 4 | 1D
| 2 | 15 天 | 7 天 | 2 | 2E
| 3 | 120 天| 90 天 | 2 | 2
It's hard to answer such question. It most probably depends on your experience in similar projects. I just can provide you with some statistics for some projects I have worked in. You can see that it's hard to get a formula for the testing time in terms of the development time:
Project | Complexity | Development Time | Test Time | # Developers | # Testers
A | 4 | 90 Days | 60 Days | 4 | 1
B | 1 | 60 Days | 30 Days | 2 | 1
C | 5 | 90 Days | 120 Days | 4 | 1
D | 2 | 15 Days | 7 Days | 2 | 2
E | 3 | 120 Days| 90 Days | 2 | 2