如何尽量准确的预估测试工作量？（2011-2-22）（获奖名单已公布）
测试工作介入的时候，或者写测试计划的时候，需要提前对测试的工作量和时间等内容进行预估，这里希望探讨一下针对测试的工作量大家都是从哪些角度，如何进行计算和预估的？如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单
奖项获奖名单奖励答案链接
一等奖zhyb_2008价值50元礼品14#
二等奖willyenillye300论坛积分4#
三等奖hergules100论坛积分23#
坐等答案 我也挺愁的 每次都估计的不是很准确 要做到比较准确的预估工作量，我觉得至少需要2点
1、对需求的熟悉
2、有足够的经验 在不同的时期,预估的精度会不一样.在项目组建前,RFP阶段,这个时候会估计出总体工作量,客户往往将交付日期划死,那么项目组的任务就是在规定日期前提交工作产品.有些项目会要求提供人员列表,这个时候可以按照开发:测试以2:1或者3:1的标准配备(我知道可能不够,成本所限,大环境如此).
项目开始后,到需求调研基本结束时,测试计划中需要对测试工作量细分.基本上是根据测试策略中制定的测试种类,结合需求中的用例数或功能点数,进行判断.对于有过程效能数据积累的团队,这根本就不是问题,如果是问题,则说明没有过程效能数据积累,只能凭经验.有经验的测试经理,成熟的团队,测试经理可以根据团队以往经验来判断,如果是陌生的团队,那么经理可以假设,如果自己(或者请教最有经验的测试人员)测这么个模块需要多久,然后乘上一个系数,例如2,然后增加20%风险后,作为工作量的评估标准.
另外,其他测试,例如性能测试,取决于系统或客户对性能测试的要求,进行估算,这方面我一般请教性能测试工程师,完成测试策略中要求的性能测试深度大概需要多久,然后加上风险系数.
对于稳定性测试,一轮至少24小时,加上脚本调试,多轮测试等等,一个星期两个星期都不过分.
最后,我要说,其实测试工作量估计这个事儿达到一个大概的范围就好.标书,项目计划基本上已经将测试计划的弹性压到最小.哈,对了,如果是第三方测试,测试计划就是项目计划的话,上面的很多系数要调整,例如假设需求分析+用例编写时间与执行时间1:1,这些都是靠个人经验了. 1. 根据测试范围和测试方法来估计工作量：
a）制定测试计划以前，明确测试范围：
不同的测试范围，对测试量的评估起到至关重要的因素，比如说测试一个模块或测试多个模块或测试整个系统等等，都属于测试范围不一样，明显工作量也不同，差别也挺大的。还有测试范围还包括功能性测试范围或非功能性测试范围等等，在做测试工作量评估的时候，都必须考虑。
b）确定合理、有效的测试方法：
比如说你要考虑测试某个项目，你必须考虑测试方法是否合理。比如说某个模块的功能测试，你可以采用QTP做自动化功能测试，还是手工做功能测试，工作量就不一样，做测试计划以前必须考虑清楚。要不然，估算的工作量肯定不准。
2. 根据测试任务来评估工作量：
a）质量需求和项目背景决定工作量：
不同的项目背景，不同的质量要求，决定不同的测试工作量。如果我们测试的是一个银行系统，涉及到每个人的经济利益，我们测试时必然会对性能测试或安全测试放到第一位，设计较多的异常测试用例，这样一做，必然增加我们的工作量。如果是一般的系统，我们可以只执行一般的功能测试通过就可以了，没有必要去做其它的异常、安全测试。如果系统的质量需求要求高，也许就要进行更深层次的测试，回归测试的力度必然要加大，工作量自然就上去了。
b）尽可能详细的罗列出项目测试内容：
一般来说，测试工作量的评估工作都是交给测试经理或项目组成员协助共同来完成的。准确评估项目测试的工作量，必须要求测试Leader明确详细的测试内容，只有知道测试什么？哪些需要测试？详细分析需求规格说明书，明确测试任务以后，评估才会有依据，所以
尽可能详细的罗列出项目测试内容非常必要。
c）把测试任务细化到每个测试功能点：
我们在估算测试时间的时候，可以把测试任务细化到每个测试的功能点，比如说“新增”、“修改”、“删除”、“暂停”、“恢复”等等都记成一个功能点，在预算的时候，同时把编写测试用例和执行测试用例的时间都要计算进去。例如：编写一个测试用例或执行一个功能测试各需要一个小时，如果我们有100个功能点，我们就知道大约要200个小时。这样估算出来的时间比较精确一点，比较符合实际。
d）预估业务测试或模块交叉测试的复杂容易程度：
很多时候，我们测试初期，对业务了解不是很多，忽视了对业务方面或交叉模块测试的评估，等到了测试后期，大量的业务测试没有测试，测试时间特别紧，所以在测试初期预估测试的复杂容易程度，在评估工作量方面至关重要。
3. 根据开发阶段来评估工作量：
不同的开发阶段，测试时间估算也不太相同。比如说，开发的系统是第一个版本，相对以后的测试工作来说，可能安排的时间要多一点。大多数情况下是这样的，也许后面的版本增加很多新功能，测试工作量还大于第一个版本也是常有的事情。作为测试负责人，对于使用测试阶段来评估工作量，必须根据实际情况来定，不能盲目给出数字，应付了事。
4. 根据测试经验的积累来评估工作量：
我们可以借鉴类似项目的测试经验，比如说被测试的系统，我们做过类似的产品，就可以把相关的测试文档，修改一下，复用以前的测试用例，这时候测试工作量就减少了很多。如果没有，我们只能重来。还有就是借鉴以前项目编写测试用例或执行测试的时间，对测试工作量的准确评估，也具有一定的参考价值。
5. 根据测试风险来评估工作量：
a）测试人员变动带来的风险：
在一般的软件公司，测试人员的流动是常有的事情，所以估计测试工作量的时候，我们一定要把它计算在里面，留有一定的余地，以防不测。比如说：以前安排了一个做过类似项目，对类似项目熟悉的测试人员，也许给他安排了一天的工作量。如果他不在了，其它的人去做这个测试也许就2天，甚至3、5天都不一定能够搞定。测试人员带了的风险还是特别高的。
b）系统测试环境的风险：
系统测试环境带来的风险，一般来说比较小，发生的可能性很小，如果一旦发生了，也相当可怕。最可怕的就是硬件故障，在经济实力允许的情况下，我们一般的方法是准备两套测试环境，一套测试环境出现问题，我们立马切换到另外一个测试环境中去继续测试，避免影响正常的测试进度。但是大部分的公司都不愿意花血本，来购买昂贵的硬件，而是以牺牲时间来付出代价。
c）、开发人员版本发布延迟风险：
不做好版本配置管理或没有正规的测试规范的公司，大部分情况下很难估计工作量，他们基本上都是边改边开发边测试，如果一旦开发出现异常，整个测试就立马终止，这对测试的相互制约作用也会更大，这样对我们估算的工作量也不准确。
d）、项目变更带了的风险：
一个项目做到中途，由于客户对技术不断深入的了解，很多时候不是“需求变更”，就是“设计变更”，弄得我们测试人员特别郁闷，不断修改测试文档。如果相关部门没有正规的变更管理，变更引起的工作量更没办法估算。很多测试后期出现工作量加大，测试延期的问题，都是对项目风险估算不足造成的。
6. 发挥项目团队的力量来评估工作量：
a）积极调动下属，发挥集体的智慧：
我带领的测试团队，对工作量的估计大致是这样的：
测试主管对自己带的项目做一个整体时间预估，给出一个大致估计时间。我再把每个模块分配给准备安排测试这个项目的每个测试工程师做一个测试工作量评估，得到结果后和测试主管的工作量对比。这个时候我要考虑他们每个人的实际能力做适当的调整，最后把调整相对准确的时间，递交项目组评审，如果通过，就OK，如果他们有建议，视建议的程度好坏，再决定是否做修改。有空的时候，我会定时检查每个人的工作内容是否准时完成，督促一下工作。一般来说，时间偏差相差不会超过一周，呵呵！！！
b）建立一个测试工作量的预算表格：
测试计划书写结束，我一般是把测试工作量的每一项，写成一个Checklist，每项大致多少时间，写出来。邮件的形式发给部门的全体成员，提高工作量的透明度。每天下班结束以前，每个人都要对测试的工作做汇报，包括已经完成的工作或未完成的工作都进行汇报，时间不是很长，就几分钟的时间，测试Leader也要做Review，以防虚报。 以上是参考别人的，希望对大家有帮助哦！ 参考 根本无法准确估计，当然如果是流程非常正规的公司的话，这个准确率会比较高的。但一般的公司也就这样了，想准确衡量你不累死才怪。 没那么多大道理！
1.对项目的需求较为熟悉，且有一定的项目经验
2.了解不同等级员工完成不同等级任务的时间
总之就是经验，做过以后就了解了嘛 个人观点:
1.业务的熟悉度.(制定测试计划、测试方案的人肯定对此类业务很熟悉)
2.工作经验（资深测试）
3.开发人员的投入量-工作量
4.公司的测试规范体系（如项目的等级划分，不同的等级划分，时间节点也不同，集成测试的次数也不同等）
5.公司专家、pm、架构师、开发、测试，进行内审。
6.机器配置的装备(机器配置的好坏，决定工作人员的心情和工作效率) 5# ailen1986的帖子受益匪浅，谢了！ willyenillye 同学说的已经比较全面了，如果是对于整个项目的测试活动进行estimate的话，再加上一些关于项目流程的参数一般就可以了。 如果能够有足够的历史数据做支撑，情况会好很多。
如果没有过往数据，建议从现在做起，做好每次项目的预估时间、实际时间开销、项目需求量、开发时间量也算作参考项，其他的参考数据根据项目中能够获取到的数据进行增加。
经过收集、对比、分析你会有所收获。
如果既没有历史数据，现在也不打算收集数据，那测试时间预估说好听点是“经验”，不好听点就是“拍脑门”。在这种情况只能想到一句话“不好说”。 测试工作量主要集中在哪些点：
1，对需求的理解和分析
2，测试计划用例的整理
3，测试执行到结束，缺陷的回归
4，测试总结
5，产品例会，产品变更引起的工作量增或减，
6，技术学习和交流等额外时间
基于以上几点，
如何做到尽量准确预估，从以下考虑：
1，预估测试工作量的测试管理基础支撑：
针对产品（项目）需求规格说明书，总体设计的分析，得出基本的测试需求分析点，整理出一份尽可能完善的
测试方案计划，一般需求说明和总体设计里，基本上会映射出测试用例和主要的测试架构和流程。所以，测试方案
主要是针对这些内容，基本确定了比较明确的测试范围，测试方式方法，有了这些东西，应该是把预估整个产品（项目）
的工作量，从产品（项目）这个大的，比较难把握的地方，转移到了测试部门内部，只要看这个测试方案计划真的实
施完成的工作量就行，当然，会有些偏差。那是因为测试方案中，可能对风险的预估可能不足
针对风险的预估，一般会经过多方讨论，结合原有的实施过的项目测试经验，进行一个大致的工作量评价，但不会太过详细
2，具体测试实施工作量的确定：
测试用例整理和测试执行到最后测试总结完成，这部分工作，我想不用太过详细的描述，每个公司，针对不同的测试人员也好，还是针对各种测试规范制度也好，测试相关的软件，程序，硬件资源等，都是不同的，但是，每个测试负责人，都应该能得出一些量化的，经验性的参考指标，去确定工作量的。
这里不细说了，因为大家这块儿应该都有不同的做法，可以简单说下我这儿确定工作量的过程
根据测试方案计划，开发详细进度计划，制订测试工作进度计划时间表，已经有了具体工作量，具体需要几个测试人员去实施，再进行分解，或者只有一个人员来做。这个由产品总体的周期来控制一下。大致这样！不细说。
3，变更工作量
不可能所有的产品或项目都是如期的，尤其是项目负责人做的很差，或者公司有别的因素干扰，不论内部还是外部的，都可能影响到整个产品或项目，这样的话，可能就比较麻烦了，有可能造成了工作量的增，或者减。这部分工作量，我想在一开始时，也可预估，也不用预估，一般一个测试部门，都会有一套针对公司的产品的应急方案在里面。
4，测试过程中，产生的测试开发学习工作量，这个在开发部门会有，在测试部门也会有。这部分应该和测试整体的水平，项目复杂度等有关，这部分的工作量，应该是也不难确定的，毕竟现在的技术还是很开放的。测试部也有技术梯队的建设，另外，还有一些部门间的协作等，这些都综合考虑一下，在整体的测试计划中，也能确定。
以上是日常工作的一些简单回顾，整理的比较乱。大家参考。 回复 5# ailen1986
分析的非常到位，值得借鉴 我们这里的做法，也是采集了一段时间，比如三个月的数据后，一般项目平均研发和测试的时间在2:1左右，个人资深一些的QA会把项目需求拆分成细致的功能点等项来分别评估单独项需要的时间，然后推出总和。
但这个工作的精确评估，是有很大的难度 1、经验估算
1）、寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量
2）、参考类似项目的数据，采用经验法估计项目分解中每类活动的工作量
3）、项目分解，将任务分解到一个人或者一个小团队可以执行的颗粒度
4）、采用经验法估计每个活动的工作量
5）、汇总得到：每个阶段的工作量，项目的总工作量
2、能力估算
根据团队或者个人能力（业务熟悉、专业技能等）分配任务 楼上的几位兄弟都深入分析了如何预估工作量，很受学习，我也就把我在项目中预估测试工作量的方法说说讨论下：
首先，部门经理会指定一个项目的测试负责人，OK，假定现在有一个项目负责人就是我，项目经理会组织我们和开发对客户需求进行评审，要做哪些东西，做的多复杂等问题，最后会确定这些问题，并确定一个项目的整体时间。然后我们会根据确定后的这份需求文档，提取里面的测试点，写一个Master Testing文档，这是我随便起的一个名字。
然后，我会根据Master Testing里面的详细测试点，预估一个模块整体大小，已经这么大模块对应多大用例工作量，用例执行工作量，因风险产生的工作量等方面。
再然后，就等开发给出他们的详细进度计划，然后根据他们计划中的阶段产出物时间点，作为测试过程中一个活动的开始点，例如，开发给出了几月几号将会给出概要设计说明书，我就以这个日期作为写测试用例的开始时间点，然后加上之前预估的用例写作工作量，就形成了测试用例这方面的进度计划，其他活动与此类似。
最后，再加上评审工作量，测试环境搭建，测试资源申请，文档维护等工作量，形成一个使用Project制作的时间进度计划，该进度计划包括时间和人员。因此整个项目的测试工作量这时候也就很清晰明了了。 学习。。。。学习。。。。 回复 19# zwmango
学习。。。借鉴
