51Testing软件测试论坛

标题: 如何尽量准确的预估测试工作量？（2011-2-22）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2011-2-22 10:26
标题: 如何尽量准确的预估测试工作量？（2011-2-22）（获奖名单已公布）
测试工作介入的时候，或者写测试计划的时候，需要提前对测试的工作量和时间等内容进行预估，这里希望探讨一下针对测试的工作量大家都是从哪些角度，如何进行计算和预估的？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项获奖名单奖励答案链接
一等奖 zhyb_2008 价值50元礼品 14#
二等奖 willyenillye 300论坛积分 4#
三等奖 hergules 100论坛积分 23#

作者: angle-ying 时间: 2011-2-22 18:36
坐等答案我也挺愁的每次都估计的不是很准确

作者: msnshow 时间: 2011-2-22 20:24
要做到比较准确的预估工作量，我觉得至少需要2点
1、对需求的熟悉
2、有足够的经验

作者: willyenillye 时间: 2011-2-23 10:43
在不同的时期,预估的精度会不一样.在项目组建前,RFP阶段,这个时候会估计出总体工作量,客户往往将交付日期划死,那么项目组的任务就是在规定日期前提交工作产品.有些项目会要求提供人员列表,这个时候可以按照开发:测试以2:1或者3:1的标准配备(我知道可能不够,成本所限,大环境如此).

项目开始后,到需求调研基本结束时,测试计划中需要对测试工作量细分.基本上是根据测试策略中制定的测试种类,结合需求中的用例数或功能点数,进行判断.对于有过程效能数据积累的团队,这根本就不是问题,如果是问题,则说明没有过程效能数据积累,只能凭经验.有经验的测试经理,成熟的团队,测试经理可以根据团队以往经验来判断,如果是陌生的团队,那么经理可以假设,如果自己(或者请教最有经验的测试人员)测这么个模块需要多久,然后乘上一个系数,例如2,然后增加20%风险后,作为工作量的评估标准.

另外,其他测试,例如性能测试,取决于系统或客户对性能测试的要求,进行估算,这方面我一般请教性能测试工程师,完成测试策略中要求的性能测试深度大概需要多久,然后加上风险系数.

对于稳定性测试,一轮至少24小时,加上脚本调试,多轮测试等等,一个星期两个星期都不过分.

最后,我要说,其实测试工作量估计这个事儿达到一个大概的范围就好.标书,项目计划基本上已经将测试计划的弹性压到最小.哈,对了,如果是第三方测试,测试计划就是项目计划的话,上面的很多系数要调整,例如假设需求分析+用例编写时间与执行时间1:1,这些都是靠个人经验了.

作者: ailen1986 时间: 2011-2-23 18:47
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，以防虚报。

作者: ailen1986 时间: 2011-2-23 18:54
以上是参考别人的，希望对大家有帮助哦！

作者: 413307036 时间: 2011-2-24 13:32
参考

作者: 51testing_zhj 时间: 2011-2-25 14:36
根本无法准确估计，当然如果是流程非常正规的公司的话，这个准确率会比较高的。但一般的公司也就这样了，想准确衡量你不累死才怪。

作者: cncnily 时间: 2011-2-25 14:45
没那么多大道理！
1.对项目的需求较为熟悉，且有一定的项目经验
2.了解不同等级员工完成不同等级任务的时间
总之就是经验，做过以后就了解了嘛

作者: zwb131442 时间: 2011-2-25 16:01
个人观点:
1.业务的熟悉度.(制定测试计划、测试方案的人肯定对此类业务很熟悉)
2.工作经验（资深测试）
3.开发人员的投入量-工作量
4.公司的测试规范体系（如项目的等级划分，不同的等级划分，时间节点也不同，集成测试的次数也不同等）
5.公司专家、pm、架构师、开发、测试，进行内审。
6.机器配置的装备(机器配置的好坏，决定工作人员的心情和工作效率)

作者: yxf 时间: 2011-2-25 17:30
5# ailen1986 的帖子受益匪浅，谢了！

作者: leizhihuan 时间: 2011-2-26 00:32
willyenillye 同学说的已经比较全面了，如果是对于整个项目的测试活动进行estimate的话，再加上一些关于项目流程的参数一般就可以了。

作者: yushudd 时间: 2011-2-28 12:42
如果能够有足够的历史数据做支撑，情况会好很多。
如果没有过往数据，建议从现在做起，做好每次项目的预估时间、实际时间开销、项目需求量、开发时间量也算作参考项，其他的参考数据根据项目中能够获取到的数据进行增加。
经过收集、对比、分析你会有所收获。

如果既没有历史数据，现在也不打算收集数据，那测试时间预估说好听点是“经验”，不好听点就是“拍脑门”。在这种情况只能想到一句话“不好说”。

作者: zhyb_2008 时间: 2011-2-28 14:23
测试工作量主要集中在哪些点：
1，对需求的理解和分析
2，测试计划用例的整理
3，测试执行到结束，缺陷的回归
4，测试总结
5，产品例会，产品变更引起的工作量增或减，
6，技术学习和交流等额外时间

基于以上几点，
如何做到尽量准确预估，从以下考虑：
1，预估测试工作量的测试管理基础支撑：
针对产品（项目）需求规格说明书，总体设计的分析，得出基本的测试需求分析点，整理出一份尽可能完善的
测试方案计划，一般需求说明和总体设计里，基本上会映射出测试用例和主要的测试架构和流程。所以，测试方案
主要是针对这些内容，基本确定了比较明确的测试范围，测试方式方法，有了这些东西，应该是把预估整个产品（项目）
的工作量，从产品（项目）这个大的，比较难把握的地方，转移到了测试部门内部，只要看这个测试方案计划真的实
施完成的工作量就行，当然，会有些偏差。那是因为测试方案中，可能对风险的预估可能不足
针对风险的预估，一般会经过多方讨论，结合原有的实施过的项目测试经验，进行一个大致的工作量评价，但不会太过详细
2，具体测试实施工作量的确定：
测试用例整理和测试执行到最后测试总结完成，这部分工作，我想不用太过详细的描述，每个公司，针对不同的测试人员也好，还是针对各种测试规范制度也好，测试相关的软件，程序，硬件资源等，都是不同的，但是，每个测试负责人，都应该能得出一些量化的，经验性的参考指标，去确定工作量的。
这里不细说了，因为大家这块儿应该都有不同的做法，可以简单说下我这儿确定工作量的过程
根据测试方案计划，开发详细进度计划，制订测试工作进度计划时间表，已经有了具体工作量，具体需要几个测试人员去实施，再进行分解，或者只有一个人员来做。这个由产品总体的周期来控制一下。大致这样！不细说。
3，变更工作量
不可能所有的产品或项目都是如期的，尤其是项目负责人做的很差，或者公司有别的因素干扰，不论内部还是外部的，都可能影响到整个产品或项目，这样的话，可能就比较麻烦了，有可能造成了工作量的增，或者减。这部分工作量，我想在一开始时，也可预估，也不用预估，一般一个测试部门，都会有一套针对公司的产品的应急方案在里面。
4，测试过程中，产生的测试开发学习工作量，这个在开发部门会有，在测试部门也会有。这部分应该和测试整体的水平，项目复杂度等有关，这部分的工作量，应该是也不难确定的，毕竟现在的技术还是很开放的。测试部也有技术梯队的建设，另外，还有一些部门间的协作等，这些都综合考虑一下，在整体的测试计划中，也能确定。

以上是日常工作的一些简单回顾，整理的比较乱。大家参考。

作者: 八千里 时间: 2011-2-28 14:33
回复 5# ailen1986

分析的非常到位，值得借鉴

作者: 八千里 时间: 2011-2-28 14:35
我们这里的做法，也是采集了一段时间，比如三个月的数据后，一般项目平均研发和测试的时间在2:1左右，个人资深一些的QA会把项目需求拆分成细致的功能点等项来分别评估单独项需要的时间，然后推出总和。

但这个工作的精确评估，是有很大的难度

作者: 真实的追求者 时间: 2011-2-28 15:22
1、经验估算
1）、寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量
2）、参考类似项目的数据，采用经验法估计项目分解中每类活动的工作量
3）、项目分解，将任务分解到一个人或者一个小团队可以执行的颗粒度
4）、采用经验法估计每个活动的工作量
5）、汇总得到：每个阶段的工作量，项目的总工作量
2、能力估算
根据团队或者个人能力（业务熟悉、专业技能等）分配任务

作者: 582357212 时间: 2011-3-1 10:29
楼上的几位兄弟都深入分析了如何预估工作量，很受学习，我也就把我在项目中预估测试工作量的方法说说讨论下：
首先，部门经理会指定一个项目的测试负责人，OK，假定现在有一个项目负责人就是我，项目经理会组织我们和开发对客户需求进行评审，要做哪些东西，做的多复杂等问题，最后会确定这些问题，并确定一个项目的整体时间。然后我们会根据确定后的这份需求文档，提取里面的测试点，写一个Master Testing文档，这是我随便起的一个名字。
然后，我会根据Master Testing里面的详细测试点，预估一个模块整体大小，已经这么大模块对应多大用例工作量，用例执行工作量，因风险产生的工作量等方面。
再然后，就等开发给出他们的详细进度计划，然后根据他们计划中的阶段产出物时间点，作为测试过程中一个活动的开始点，例如，开发给出了几月几号将会给出概要设计说明书，我就以这个日期作为写测试用例的开始时间点，然后加上之前预估的用例写作工作量，就形成了测试用例这方面的进度计划，其他活动与此类似。
最后，再加上评审工作量，测试环境搭建，测试资源申请，文档维护等工作量，形成一个使用Project制作的时间进度计划，该进度计划包括时间和人员。因此整个项目的测试工作量这时候也就很清晰明了了。

作者: zwmango 时间: 2011-3-1 12:05
学习。。。。学习。。。。

作者: zb2535027 时间: 2011-3-1 15:04
回复 19# zwmango

学习。。。借鉴

作者: lzz 时间: 2011-3-1 15:30
本帖最后由 lzz 于 2011-3-1 16:28 编辑

1. Test Estimation Principles

The test estimation is different from other project estimations, because the number of failures is not known in advance—though it can be estimated as well. The number of necessary iterations before the completion criteria are met is usually not known either. As a rule of thumb, at least three iterations  must be reckoned with—one is definitely not enough, unless the completion criterion is a simple execution of all test cases, and independent of the number of outstanding faults and coverage

The estimation must include:
1)Time to produce incident registrations
2)Possible time to wait for fault analysis
3)Possible time to wait for fault correction
4)Time for retest and regression test (minimunm three interations!)

Experience in the testing business shows that 50% of the original number of faults remains after correction. These are distributed like this:
Remaining faults after correction  20%
Unveiled faults after correction 10%
New faults after correction       20%

These are general experience numbers. It's important that you collect your own metrics!

2. The Estimation Process

1). Define the purpose of the estimation—Is this estimation the first approach, for a proposal, or for detailed planning?
2). Plan the estimating task—Estimation is not a two-minute task; set sufficient time aside for it.
3). Write down the basis for the estimation—Here the scope and the size of the work are determined, and all factors that may influence
the estimates are registered. This includes factors related to the nature of the processes we are working by, the nature of the project
we are working in, the people we are working with, and any risks we are facing.
4). Break down the work—This is the work breakdown (i.e., the listing of all the tasks to estimate). Do this as well as possible in relation to
the purpose.
5). Estimate—Use more than one technique as appropriate.
6). Compare with reality and reestimate—This is the ongoing monitoring and control of how the work that we have estimated is actually going.

3. Estimation Techniques
1) FIA(finger in the air) or best guess
2) Experience-based estimation
3) Analogies and experts
4) Delphi technique
5) Three-point estimation (successive calculation)
6) Model-based estimation
7) Function points
8) Test points
9) Percentage distribution
10) Use cases

4.From Estimations to Plan and Back Again

The estimating does not stop with the preparation of the first schedule. Once the actual testing has started—from the first planning activities and onwards,we need to frequently monitor how realities correspond to the estimates.Based on the new information gathered through the monitoring, we must reestimate,when the deviations between estimates and reality get too large to stay in control. Only when all the testing activities are completed can we stop the monitoring and re-estimation.

5.Get Your Own Measurements

In order to get better estimates we need to collect actual data. The more empirical data we have, the better will the estimates be. In general we can say that (almost) any data is better than no data. From an organizational point of view it must be checked that all completed projects collect data, and the usage of these data must, of course, also be enforced.

作者: greenliuqin 时间: 2011-3-1 20:27
发表下自己的意见，还请各位大侠多多指点：
1.软件功能模块多少，每个模块规划好时间。
2.软件测试执行难易度，用例再执行的过程中，会遇到很多其他的问题，比如发现致命bug，需要测试人员隔离分析，或者是测试环境搭建有误等其他异常，都需要考虑在内。

作者: hergules 时间: 2011-3-1 21:18
从实际工作出发说点我的感受：
预估的前提：有一定的测试经验、对类似项目有相关经验。
预估工作量嘛，当然是项目已经立项，还没正式开工，各个部门都开始计划自己的时间。

这个时期有几种情况：
1.需求是否明确（基本上只有客户意向）？
2.需求是否已经形成正式文档（和客户做过初步访谈，细节方面没敲定）？
3.需求是否正式确定已初步进入开发阶段？
不同时期，估算出来的测试时间是不一样的。

举例说明：
公司有一个项目——某企业要做一个企业网站，放一些企业相关资料上去。——大多数业务员接回来的单都是这样说的，然后项目经理问程序员开发这个要多长时间？问测试员测试这个要多长时间？
程序员说：我们有以前的模板，2个礼拜就可以搞定。
测试员：……
你怎么回答这个问题？
答案一：这个模板以前我们已经测试过，如果改动不大，我们三天就可以搞定。
OK，能答成这样，你已经是个合格的测试员了。
答案二：考虑到测试后的修改和回归测试的总体时间，应该在一个礼拜左右。
OK，给出这个答案的应该可以做个测试主管吧。
答案三：客户具体需求不给力、旧模板能适用客户需求的范围和旧模板要修改的程度也不知道，需要进一步的客户需求有比较可靠的判断。
如果你能给出第三种答案，那么你应该已经是测试经理了。

作者: zhangpei2020 时间: 2011-3-1 22:34
1、先看开发的工作量
2、在看项目上线的时间
3、预留修改bug的时间
4、考虑测试人员的技术水平
5、考虑测试人员的分配力度

作者: zhangpei2020 时间: 2011-3-1 22:36
1、先看开发的工作量
2、在看项目上线的时间
3、预留修改bug的时间
4、考虑测试人员的技术水平
5、考虑测试人员的分配力度

作者: 我无语呀 时间: 2011-3-2 09:47
回复 5# ailen1986 详细，客观。支持

作者: 水函 时间: 2011-3-2 14:44
上面说的都灰常有道理啊，咱说点实用的呗，我觉得一般情况下我们接到一个项目，大体上会从以下几个方面考虑：
1.根据项目的规模和复杂程度预估测试工作量A
2.根据以往的项目经验，对上步骤得出的工作量细化成B
3.根据公司的项目过程对B进行修改，结果为C
4.根据开发人员的配置，修改C，得到结果为D（这绝不是对开发人员侮辱，因为现实确实存在这种情况）
5.根据测试组成员，再将D修改为E（如果测试组除了负责人外都是新人，测试工作量无可厚非要增加吧）
当然肯定不是按照这个步骤一步一步来，综合考虑的大概就这几项吧！

作者: 没翅膀的飞鱼 时间: 2011-3-2 22:15
回复 18# 582357212

我们公司的大致流程和你讲的差不多

作者: 愚人 时间: 2011-3-4 13:48

1. 根据测试范围和测试方法来估计工作量：
　　a）制定测试计划以前，明确测试范围：

　　不同的测 ...
ailen1986 发表于 2011-2-23 18:47

这个给力……

作者: happy_wendi 时间: 2011-3-4 22:37
我个人认为测试的工作量是没有办法做到100%精确的，因为测试理论上是不可能发现软件中的所有bug的。那么如何尽量精确地预估呢？可以考虑从以下几方面考虑：1、参考以往的基线数据：比如日设计用来多少？日测试执行用例多少？基本上正规的测试部门应该有做类似数据的度量的；2、根据所测试软件的复杂度和历史发现bug做参考：基本上复杂度高的软件，测试的工作量是成指数倍增长的。一般情况下，发现的bug越多，遗留的未知bug也会越多，测试工作量也会增大；

作者: shanglijuan1209 时间: 2011-3-7 10:17
大家伙的都值得借鉴啊

作者: bicknuer 时间: 2011-3-8 14:14
以上看到的都是对于以往经验的定性估算，我想借助于统计学，对历史数据进行定量计算
一。选取关系变量
1。项目大小：项目代码数，功能点数（系数1- 10）排除离群点项目
2。技术复杂度：项目实现的技术难度（系数1- 10）
3。自动化测试水平：自动化测试在测试过程中的应用程度（系数1- 10）
4。项目管理水平：公司项目管理水平成熟度（系数1 - 10）
5。测试人员水平：测试人员的技术能力，业务能力总体水平（系数1- 10）
6。项目总体质量指标：各项目所达到的质量水平（系数1- 10）
7。项目测试类型：各项目测试策略，方法的复杂度（系数1-10）

二。从以往项目数据中采集以上数据，并乘以相关系数

三。对以上数据和测试工作量建立一个多元线形回归方程（数学没那么高水平，用统计工具）
对数据进行方差分析，多元线形回归分析，判断回归方程的有效性，研究相关变量的显著性

四。将新的项目的相关参数代入回归方程，计算测试工作量。

以上都还停留在纸面上，最近听了几堂统计学的课，有感而发
不知道哪位大虾有过统计学在这方面的应用，指点一下

作者: Jackc 时间: 2011-3-8 16:06
本帖最后由 Jackc 于 2011-3-8 16:08 编辑

回复 33# bicknuer

呃，多元线性回归方程.....这个....有点夸张了吧...

我觉得你提到的第1部分挺好的，提取影响项目进行的各个因素，并根据实际项目的的情况设置系数。

通常我们可以再次将项目因子分类，并规定不同类别间的运算关系和系数（为了与1中的系数区分，通常会再次引入一个新的系数，且这个系数往往是定值。当然，有些公司也把这个系数直接放到1中去了，但我认为这种做法风险稍大），最后估算出期望得到结果。
如，
将项目影响因子分为2大类：项目数据 / 团队数据
每类再分为利/弊

这样分类后，就可以用简单的运算规则设计工作量统计的计算公式。也不需涉及到所谓的多元线性方程，四则运算就能构造公式的基本框架
——————————————

说实话，在实际操作中，1张项目因子表，1个有经验的管理者，再拍拍脑壳，工作量就估算出来了。（何来这么复杂的理论...）

作者: zhong3269 时间: 2011-3-8 20:10
先收藏一下，回头仔细看看，看一遍不够，在看一变。

作者: yzylion 时间: 2011-3-8 21:39
看了前面各位同伴的回答都非常精彩，这里谈谈我个人的一些理解，欢迎沟通，讨论：
1、分析
首先，当我们接到测试的任务的时候，我们需要对这个任务做一定的分析。弄清楚我们的任务需要做什么事情？也就是范围？我们手头上有哪些资源？包括人力资源和非人力资源以及我们会得到什么样的支撑。另外，我们需要在多久的时间做完这个任务？这个任务的出口准则也就是常说的验收标准是什么？在这些都弄清楚之后，就进入我们的第二步。

2、初步估算
   在弄清楚了以上的问题之后，我们也就知道了我们到底要做什么？进度是什么？有哪些资源等了，这个时候如果我们公司平常有比较好的数据的积累，即组织级的数据积累，我们可以参考这样的数据得出一个初步的工作量估算报告。多少人工？多少人月等？如果公司没有这样的组织级数据的积累，那么就可以grouptime的成员，大家坐在一起，用delphi的方法来进行预估，然后取出平均值。对了，在这之前，还需要在分析阶段属于一个WBS的工作分解结构，作为我们这里的delphi分析输入。在这一步完成之后，得到一个初步的工作预估表。类似于我们常说的详细的项目进度计划，只是在我们这里是测试进度计划。

3、监控、调优和积累
   最后，就秉承先固化后优化的观点，在计划的执行过程中做到有效的监控，及时的发现问题进行调优和纠偏。项目完成之后，做相关的总结，将数据积累下来，便于后期的估算的参考等

一蹴而就的没有偏差的预算，我个人认为不是说没有，只是这个需要很长的一个过程的数据的积累，同时还有数据的一个维护和有效性的风险跟踪和管理，调整，因为，本身这也就是预算嘛，呵呵

个人之见，欢迎沟通，拍砖讨论。谢谢

作者: 真实的追求者 时间: 2011-3-9 17:42
转）
场景一：合同前的工作量估算

　　场景描述：

　　(1)没有实施过CMMI2级

　　(2)合同未签，需要给客户报价

　　(3)有客户的概要需求，有类似的项目数据可供参考

　　(4)需要估计整个项目的总工作量，以便于估算总成本，给客户报价

　　估算步骤：

　　(1)寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量;

　　(2)进行WBS分解，力所能及地将整个项目的任务进行分解;

　　(3)参考类似项目的数据，采用经验法估计WBS中每类活动的工作量;

　　(4)汇总得到项目的总工作量;

　　(5)与第(1)步的结果进行印证分析，根据分析结果，确定估计结果。

　　场景二：基于详细需求的经验估计

　　场景描述：

　　(1)只有详细需求，没有历史数据

　　估算步骤：

　　(1)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。

　　(2)采用经验法估计每个活动的工作量;

　　(3)汇总得到：每个阶段的工作量、项目的总工作量。

　　其他说明：

　　在该场景下，只使用了经验法，无法对结果进行印证，难以判断结果的合理性。

　　场景三：由编码估算整体

　　场景描述：

　　(1)有类似项目的历史数据

　　(2)有编码活动的生产率数据

　　(3)有详细需求

　　(4)实施了CMMI2级，但是没有积累历史项目的工作量分布数据

　　估算步骤：

　　(1)产品分解，将系统分为子系统，子系统分解为模块;

　　(2)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。

　　(3)建立WBS分解中的活动与产品元素的映射关系，识别出WBS中哪些活动可以采用模型法估算;

　　(4)估计产品元素的规模，可以采用代码行法或功能点法，并估计每个产品元素的复杂度、复用率等;

　　(5)根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量;

　　(6)根据历史的类似项目的数据及估算人的经验估计其他活动的工作量，可以采用经验法。

　　(7)汇总得到：每个阶段的工作量、项目的总工作量。

　　其他说明：

　　在该场景下，混合使用了经验法与模型法，这2种方法互相补充，而不是互相印证。

　　场景四：由总体印证基于WBS的估计

　　场景描述：

　　(1)有类似项目的历史数据

　　(2) 有类似项目的全生命周期的生产率数据(含管理工作量)

　　(3)有详细需求

　　(4)实施了CMMI2级，但是没有积累历史项目的工作量分布数据

　　估算步骤：

　　(1)产品分解，将系统分为子系统，子系统分解为模块;

　　(2)估计产品元素的规模，可以采用代码行法或功能点法;

　　(3)累计出整个产品的总规模，并估计产品总体的复杂度、复用率等;

　　(4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量;

　　(5)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。

　　(6)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。

　　(7)汇总得到：每个阶段的工作量、项目的总工作量。

　　(8)与第(4)步得出的工作量进行比较印证，如果偏差不大，则以第(7)步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：

　　类似项目的生产率数据不适合本项目;

　　WBS分解的颗粒度不够详细;

　　估算专家的经验不适合本项目;

　　具体任务的估计不合理;

　　针对原因，对估算的结果进行调整，使其趋向合理。

　　其他说明：

　　在该场景下，对于项目的总工作量有2个结果或者多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，是估计更加合理。

　　场景五：三维印证基于WBS的估计

　　场景描述：

　　(1)有类似项目的历史数据

　　(2) 有类似项目的全生命周期的生产率数据(含管理工作量)

　　(3)有详细需求

　　(4)实施了CMMI3级，有历史项目的工作量分布数据(阶段分布、工种分布)

　　估算步骤：

　　(1)产品分解，将系统分为子系统，子系统分解为模块;

　　(2)估计产品元素的规模，可以采用代码行法或功能点法;

　　(3)累计出整个产品的总规模，并估计产品总体的复杂度、复用率等;

　　(4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量;

　　(5)根据历史项目的工作量分布数据及第(4)步估算的项目总工作量，计算：每个阶段的工作量、每个工种的工作量

　　(6)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。

　　(7)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。

　　(8)汇总得到：每个阶段的工作量、每个工种的工作量、项目的总工作量。

　　(9)与第(4)、(5)步得出的工作量进行比较印证，如果偏差不大，则以第(7)步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：

　　类似项目的生产率数据不适合本项目;

　　WBS分解的颗粒度不够详细;

　　估算专家的经验不适合本项目;

　　具体任务的估计不合理;

　　针对原因，对估算的结果进行调整，使其趋向合理。

　　其他说明：

　　在该场景下，对于项目的总工作量有2个结果或者多个结果，并且采用2种方法都得到了每个阶段、每个工种的工作量、项目的总工作量，可以从上述的3个维度对这些结果进行互相印证，以发现估算过程中的不合理之处，是估计更加合理。

作者: bicknuer 时间: 2011-3-9 18:11
回复 34# Jackc

引入多元线性回归方程是为了充分利用以往项目采集的数据，而且随着项目的积累，不断递归，方程会越接近真实值。统计还可以分析条件因子对项目的影响指标。
只是设定系数的话这个系数设置的合理不合理也无从知道，只能在项目后期才能判断所有系数的总体是否合理，差距多大。
回归方程现在也不是太大问题，手工不太可能，但现在很多统计软件只要输入数据就能导出了
最大的问题是历史数据可能采集不全。

作者: 真实的追求者 时间: 2011-3-11 17:17
这每周一问都快一个月了  不换点新的问题！~！！！
这每周一问都快一个月了  不换点新的问题！~！！！
这每周一问都快一个月了  不换点新的问题！~！！！
这每周一问都快一个月了  不换点新的问题！~！！！
这每周一问都快一个月了  不换点新的问题！~！！！
这每周一问都快一个月了  不换点新的问题！~！！！

作者: mlj_12 时间: 2011-3-12 10:22
我觉得就算你预估好了工作量，但在实际工作中会增加额外的工作量，所以要尽量放宽时间

作者: 碧水小龙 时间: 2011-4-28 15:59
学习，思考中

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	zhyb_2008	价值50元礼品	14#
二等奖	willyenillye	300论坛积分	4#
三等奖	hergules	100论坛积分	23#