如何准确评估项目测试的工作量？(08-11-03)（获奖名单已公布）
很多时候，测试工作量评估不准确，就导致测试延期，系统无法准时上线，给测试部门的头头压力搞得很大。我想知道作为测试Leader, 如何准确评估项目测试的工作量，才能够保证项目测试的顺利进行？感谢会员奥运宝贝提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖空缺当当购物卡50元空缺二等奖ianshine300论坛积分11＃zhangjm168814＃
三等奖liaoyin1234100论坛积分
22＃
zhuzx24＃
因本次答案多为转贴,一等奖空缺.archonwang5＃
先占个位置
先占个位置，内容一会补全！！哈哈 这个讨论话题很实用，很好！！！版主，真是好题目一个，表扬一下
版主最近选的话题，都很好，特别表扬一下版主，呵呵！！！ 疯了，上周问题忘了答。争取本周。=======================================================================
：
回帖一点点写吧。
关于这个问题，困难的不是方法，不是过程，而是前置条件的优劣。
1. 先说说估算的前提条件问题。
之前的项目测试过程中，或多或少都会涉及到工作量估算，这个估算过程有时很简单，简单到一句话，有时很复杂。但是总结起来，工作量估算的核心是什么？个人觉得估算的核心是范围/内容，是所需要进行处理的所有相关事务。从这个意义上说，任何估算都是基于范围/内容的。
说到这里大家可能就会明白，困难的工作实际上就是范围的确定。说起来有点类似于项目的需求范围管理。
一旦第一个条件满足，接下来就是对各项资源的评估。我们常说的资源包括：人力（人数、能力及团队协作）、时间。这些前置条件对评估工作量是不可或缺的系数。个人能力强弱会影响局部进度，团队协作能力会影响全局，人员数量决定绝对进度；时间会影响其他资源的投入，甚至范围也会受其影响放大或缩小。
我们估算的工作量范围受这些因素影响，导致我们会经常性的估算错误——往往都是算少了。
=======================================================================
：
接着往下说明。
2. 估算的过程。
估算的一些常见方法我想在此不再赘述，如果有同仁不清楚具体的工作量估算的方法，请直接Google啦。
曾经使用过的估算过程大致如下简述：
[*]确定估算对象的范围和内容；[*]就该范围和内容，选择合适的估算方法和相关的经验系数；[*]分解需要进行估算的范围和内容：在范围上划分工作类型，在内容上进行最小化划分，在计划上划分阶段；[*]按一定的系数进行计算，统计估算的最后数值。按阶段划分的化，一般都包含如下几个参数：总工作量、阶段工作量及对应的工时和风险系数[*]执行过程中不断调整估算，为下次估算提供数据。这里要注意的是保留各次估算的结论，在将来进行数据汇总统计时对这些现象进行分析，以提高估算准确度。
这里只说明过往个人的一些估算过程中的经验（比较粗略，见谅）。
[*]个人比较推崇WBS方法、功能点估算及专家估算法。所不同的是，WBS方法任何时候都适用，功能点估算只在需求非常明确的情况下可很容易的估算，而专家估算虽然对任何情况都适用，但是其估算的标准方差往往会很大（不同的专家结论甚至有时候完全不一样，要有心理承受力哦），其次，该方法的费用也最高。所以，个人推荐以WBS/功能点估算为主，专家估算为辅，结合起来进行估算。[*]前面讲过前提，这非常非常重要，若是要把估算做好，最重要的是把估算的前端准备工作做好。我的个人经验表明：反复地组织评审，及时地跟进变更在控制范围方面绝对是个好方法！[*]若组织准备采用专家估算方法时，请务必多找几个专家，以相同的形式、流程步骤和方法对相同类型的测试进行估算，当然，专家估算必须独立于组织之外，在正式结果出现之前，专家不应就该估算对象进行讨论！[*]WBS方法除了上面所说的条件外，还受限于很多因素，比如估算人的能力和项目经验。由于业界对这些内容没有统一的界限和标准，所以得出一个客观的估算，尤其是预算是很困难的，我们一般都把WBS作为功能点估算方法的基础，先进行任务分解，后剥离功能点计算工作量得到的结果一般都比较准确。误差一般都会控制在10~15%以内。[*]WBS估算是很复杂的工作，很多同仁认为只要把测试分解成各个功能、性能等类型测试就算可以了。但是实际上，估算的一个重要的作用在这种分解上没有体现出任何对风险的估计。正确的情况应是把所有要做的各类工作进行最小化分解。比如：对环境进行部署是一个大类，虽然不一定是由QC部门组织实施，但是在整个过程中需要做发起和跟踪确认等工作，所以应计入相应的工作量；当然，也包括各类文档的编写、存档、评审等内容。[*]任何形式的估算应对实施过程中各事项做风险评估，一些较大的公司会在估算中引入风险系数来计入对应的时间。纯粹考虑实施的估算基本上没有任何意义。[*]铁律：不要让新人，尤其是在这一行业没有经验或较少经验的新人担任估算的核心工作。这个限制一般都是指有效工作时间在18个月的测试人员（以每周7天计算）。[*]一般情况下，初始的测试估算要比后续的变更估算容易，但是工作量较大。变更估算的准确率与之前初始估算阶段所做的整理工作完整成正比。[*]所有的估算都应要有随时调整的准备，计划和预算都不是也不可能是一次成功。我这里推荐的周期是每周一次，相对以月为计数的测试阶段。
=======================================================================
：下午再写。
=======================================================================
：又忘记了。继续。
接下来说明下方法。很多方法都有人介绍过了，我这里就贴个附件作为结束了（这个文档是在某博客中发现的，很佩服作者的研究和技术涵养）。谢谢~~
[ 本帖最后由 archonwang 于 2008-11-10 11:09 编辑 ] 要做到准确评估项目测试的工作量是不可能的，只能尽可能的减少预估与实际的误差。
要预估工作量，首先，需要对整个项目的各个环节都非常了解，列出消耗工作量相对稳定的工作部分；然后，预估那些风险比较大的环节，最好是参照其他项目类似的情况，估计个差不多的时间；最后，资源的多少和到位时间也是需要考虑的。一般来说，联调的风险是最大的，尤其是牵扯到多个系统时更是不好估计。 评估工作量说 实话方法也只是个形式.
更多的是经验.
我经常使用的方法是:最短时间+最长时间/2 +异常情况值.
最短时间=无任何其他问题,比如资源不足,需求不明等等问题,正常测试的时间.
最长时间=把所有需要做的工作量都算在内,就是就算没有任何前提的情况下这些时间也足能完成的时间
异常情况值=分析一下当前项目的一些总体情况,客户,或则其他问题,比如会议延迟或者客户沟通的问题.一般是很少出现.
如果上面得出的结果自己用知觉觉得不舒服,还是会灵活调整的.
计划没有变化快!
高手怎么都不见人影了呢
很期待更多的高手出来回答我的问题，帮帮我！！！占个位置
估算理论就如软件工程中的那些方法，个人认为经验非常重要，先顶起来 我觉得可以用(A+4B+C)/6来计算，A代表乐观时间，B代表最可能时间，C代表悲观时间。这是著名的PERT。。。如果对项目精确了解的话，可以自己预估时间；
或者由团队内部的比较了解情况的人估计时间，然后负责人整合时间后反馈回去。如此几回来确定最后的时间。
小弟在网上看的资料！！大家分享一下吧！！
场景一：合同前的工作量估算场景描述：
（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个维度对这些结果进行互相印证，以发现估算过程中的不合理之处，是估计更加合理。 把测试工作尽量细分为多个子任务，层层分解，评估每个子任务的工作量。需求分析这一步很关键。需求尽可能细，最好能由需求得到用例数目。另外，主要靠经验数据，如写测试计划要多长时间，每人天可以设计多少个测试用例，每人天可以执行多少个测试用例等。 1.根据以往的项目测试经验，采用WBS方法估算当前项目的工作量.估算出当前项目需要的总工时。
2.确定项目测试组成员后，将当前项目的工作量分配下去。再让项目成员估算他需要的工时。这样做可以使估算更加客观更加符合实际；更重要的是，相当于测试员对于测试负责人有这样一个时间承诺，会尽可能实现他的承诺。
3.根据1,2点和项目的进度情况确定测试范围，颗粒度。根据可能发生的异常情况的影响程度和发生概率，再多加几天。
这样基本确定测试时间。
准确评估测试工作量比较难，大家可以参考一下国外的经验噢！
Following are some approaches to considerImplicit Risk Context Approach:
A typical approach to test estimation is for a project manager or QA manager to implicitly use risk context, in combination with past personal experiences in the organization, to choose a level of resources to allocate to testing. In many organizations, the 'risk context' is assumed to be similar from one project to the next, so there is no explicit consideration of risk context. (Risk context might include factors such as the organization's typical software quality levels, the software's intended use, the experience level of developers and testers, etc.) This is essentially an intuitive guess based on experience.
Metrics-Based Approach:
A useful approach is to track past experience of an organization's various projects and the associated test effort that worked well for projects. Once there is a set of data covering characteristics for a reasonable number of projects, then this 'past experience' information can be used for future test project planning. (Determining and collecting useful project metrics over time can be an extremely difficult task.) For each particular new project, the 'expected' required test time can be adjusted based on whatever metrics or other information is available, such as function point count, number of external system interfaces, unit testing done by developers, risk levels of the project, etc. In the end, this is essentially 'judgement based on documented experience', and is not easy to do successfully.
Test Work Breakdown Approach:
Another common approach is to decompose the expected testing tasks into a collection of small tasks for which estimates can, at least in theory, be made with reasonable accuracy. This of course assumes that an accurate and predictable breakdown of testing tasks and their estimated effort is feasible. In many large projects, this is not the case. For example, if a large number of bugs are being found in a project, this will add to the time required for testing, retesting, bug analysis and reporting. It will also add to the time required for development, and if development schedules and efforts do not go as planned, this will further impact testing.
Iterative Approach:
In this approach for large test efforts, an initial rough testing estimate is made. Once testing begins, a more refined estimate is made after a small percentage (eg, 1%) of the first estimate's work is done. At this point testers have obtained additional test project knowledge and a better understanding of issues, general software quality, and risk. Test plans and schedules can be refactored if necessary and a new estimate provided. Then a yet-more-refined estimate is made after a somewhat larger percentage (eg, 2%) of the new work estimate is done. Repeat the cycle as necessary/appropriate.
Percentage-of-Development Approach:
Some organizations utilize a quick estimation method for testing based on the estimated programming effort. For example, if a project is estimated to require 1000 hours of programming effort, and the organization normally finds that a 40% ratio for testing is appropriate, then an estimate of 400 hours for testing would be used. This approach may or may not be useful depending on the project-to-project variations in risk, personnel, types of applications, levels of complexity, etc.
Successful test estimation is a challenge for most organizations, since few can accurately estimate software project development efforts, much less the testing effort of a project. It is also difficult to attempt testing estimates without first having detailed information about a project, including detailed requirements, the organization's experience with similar projects in the past, and an understanding of what should be included in a 'testing' estimation for a project (functional testing? unit testing? reviews? inspections? load testing? security testing?)
With agile software development approaches, test effort estimations may be unnecessary if pure test-driven development is utilized. However, it is not uncommon to have a mix of some automated positive-type unit tests, along with some type of separate manual or automated functional testing. In general, agile-based projects by their nature will not be heavily dependent on large testing efforts, since they emphasize the construction of releasable software in very short iteration cycles. These smaller test effort estimates may not be as difficult and the impact of inaccurate estimates will be less severe. zhanwei 14楼的英语是不是很好啊····我看了半天··不懂啊
郁闷ing 14楼的英语是不是很好啊····我看了半天··不懂啊
郁闷ing
zhuzx，你当了版主就不到每周一问来答题啦？？
强烈期待您的高见？？？朋友，这期我一定回答，呵呵！！
原帖由 wtfc 于 2008-11-5 09:35 发表 http://bbs.51testing.com/images/common/back.gif强烈期待您的高见？？？
wtfc朋友，很抱歉，刚看到您的帖子。由于最近公司项目比较多，忙了点，放心吧，这期题目我一定回答的，只是迟早的问题，谢谢您捧场！！
回复 16# 的帖子
英语一般！大体上还能理解，这里主要涉及到五种测试估算的方法：第一，根据以往的经验，评直觉估算
第二，根据以往成功的测试留下的文档进行估算
第三，工作量分解估算
第四，反复多次估算
第五，随着开发的进展估算
然后一段说的是成功的测试工作量估算不容易.....
最后又提了一下关于敏捷开发模式，测试估算的问题。
原文请参见：http://www.softwareqatest.com/qat_lfaq1.html#LFAQ1_11
注：解释的不一定确切阿，你也可以把你具体不清楚地问题描述一下，让同仁们解释解释！
