51Testing软件测试论坛

标题: 如何准确评估项目测试的工作量？(08-11-03)（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2008-11-3 10:21
标题: 如何准确评估项目测试的工作量？(08-11-03)（获奖名单已公布）
很多时候，测试工作量评估不准确，就导致测试延期，系统无法准时上线，给测试部门的头头压力搞得很大。我想知道作为测试Leader, 如何准确评估项目测试的工作量，才能够保证项目测试的顺利进行？

感谢会员奥运宝贝提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！


因本次答案多为转贴,一等奖空缺.　
获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
空缺
当当购物卡50元
空缺
二等奖
ianshine
300论坛积分
11＃
zhangjm1688
14＃
三等奖
liaoyin1234
100论坛积分
22＃
zhuzx
24＃
archonwang
5＃
作者: 吴如领    时间: 2008-11-3 11:14
标题: 先占个位置
先占个位置，内容一会补全！！哈哈
作者: eyec    时间: 2008-11-3 11:17
这个讨论话题很实用，很好！！！
作者: 豆腐佬    时间: 2008-11-3 11:42
标题: 版主，真是好题目一个，表扬一下
版主最近选的话题，都很好，特别表扬一下版主，呵呵！！！
作者: archonwang    时间: 2008-11-3 14:14
疯了，上周问题忘了答。争取本周。

=======================================================================
[2008-11-05]：
回帖一点点写吧。
关于这个问题，困难的不是方法，不是过程，而是前置条件的优劣。

1. 先说说估算的前提条件问题。
之前的项目测试过程中，或多或少都会涉及到工作量估算，这个估算过程有时很简单，简单到一句话，有时很复杂。但是总结起来，工作量估算的核心是什么？个人觉得估算的核心是范围/内容，是所需要进行处理的所有相关事务。从这个意义上说，任何估算都是基于范围/内容的。
说到这里大家可能就会明白，困难的工作实际上就是范围的确定。说起来有点类似于项目的需求范围管理。
一旦第一个条件满足，接下来就是对各项资源的评估。我们常说的资源包括：人力（人数、能力及团队协作）、时间。这些前置条件对评估工作量是不可或缺的系数。个人能力强弱会影响局部进度，团队协作能力会影响全局，人员数量决定绝对进度；时间会影响其他资源的投入，甚至范围也会受其影响放大或缩小。

我们估算的工作量范围受这些因素影响，导致我们会经常性的估算错误——往往都是算少了。



=======================================================================
[2008-11-06]：
接着往下说明。
2. 估算的过程。
估算的一些常见方法我想在此不再赘述，如果有同仁不清楚具体的工作量估算的方法，请直接Google啦。

曾经使用过的估算过程大致如下简述：

这里只说明过往个人的一些估算过程中的经验（比较粗略，见谅）。


=======================================================================
[2008-11-07]：下午再写。

=======================================================================
[2008-11-10]：又忘记了。继续。

接下来说明下方法。很多方法都有人介绍过了，我这里就贴个附件作为结束了（这个文档是在某博客中发现的，很佩服作者的研究和技术涵养）。谢谢~~

[ 本帖最后由 archonwang 于 2008-11-10 11:09 编辑 ]
作者: ywtest    时间: 2008-11-3 21:42
要做到准确评估项目测试的工作量是不可能的，只能尽可能的减少预估与实际的误差。
要预估工作量，首先，需要对整个项目的各个环节都非常了解，列出消耗工作量相对稳定的工作部分；然后，预估那些风险比较大的环节，最好是参照其他项目类似的情况，估计个差不多的时间；最后，资源的多少和到位时间也是需要考虑的。一般来说，联调的风险是最大的，尤其是牵扯到多个系统时更是不好估计。
作者: 厍仕杰    时间: 2008-11-4 00:08
评估工作量说 实话方法也只是个形式.
更多的是经验.
我经常使用的方法是:最短时间+最长时间/2 +异常情况值.
最短时间=无任何其他问题,比如资源不足,需求不明等等问题,正常测试的时间.
最长时间=把所有需要做的工作量都算在内,就是就算没有任何前提的情况下这些时间也足能完成的时间
异常情况值=分析一下当前项目的一些总体情况,客户,或则其他问题,比如会议延迟或者客户沟通的问题.一般是很少出现.
如果上面得出的结果自己用知觉觉得不舒服,还是会灵活调整的.
计划没有变化快!
作者: 奥运宝贝    时间: 2008-11-4 09:44
标题: 高手怎么都不见人影了呢
很期待更多的高手出来回答我的问题，帮帮我！！！
作者: paprisgyl    时间: 2008-11-4 12:20
标题: 占个位置
估算理论就如软件工程中的那些方法，个人认为经验非常重要，先顶起来
作者: 云淡风轻    时间: 2008-11-4 16:02
我觉得可以用(A+4B+C)/6来计算，A代表乐观时间，B代表最可能时间，C代表悲观时间。这是著名的PERT。。。

如果对项目精确了解的话，可以自己预估时间；

或者由团队内部的比较了解情况的人估计时间，然后负责人整合时间后反馈回去。如此几回来确定最后的时间。
作者: ianshine    时间: 2008-11-4 16:05
标题: 小弟在网上看的资料！！大家分享一下吧！！
场景一：合同前的工作量估算
场景描述：
（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个维度对这些结果进行互相印证，以发现估算过程中的不合理之处，是估计更加合理。
作者: maclehappy13    时间: 2008-11-4 16:21
把测试工作尽量细分为多个子任务，层层分解，评估每个子任务的工作量。需求分析这一步很关键。需求尽可能细，最好能由需求得到用例数目。另外，主要靠经验数据，如写测试计划要多长时间，每人天可以设计多少个测试用例，每人天可以执行多少个测试用例等。
作者: 魔法小兔    时间: 2008-11-4 16:22
1.根据以往的项目测试经验，采用WBS方法估算当前项目的工作量.估算出当前项目需要的总工时。
2.确定项目测试组成员后，将当前项目的工作量分配下去。再让项目成员估算他需要的工时。这样做可以使估算更加客观更加符合实际；更重要的是，相当于测试员对于测试负责人有这样一个时间承诺，会尽可能实现他的承诺。
3.根据1,2点和项目的进度情况确定测试范围，颗粒度。根据可能发生的异常情况的影响程度和发生概率，再多加几天。

这样基本确定测试时间。
作者: zhangjm1688    时间: 2008-11-4 16:37
标题: 准确评估测试工作量比较难，大家可以参考一下国外的经验噢！
Following are some approaches to consider

Implicit 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.
作者: 阿七    时间: 2008-11-4 21:26
zhanwei
作者: yongzhao    时间: 2008-11-4 21:58
14楼的英语是不是很好啊····我看了半天··不懂啊
郁闷ing
作者: yongzhao    时间: 2008-11-4 21:59
14楼的英语是不是很好啊····我看了半天··不懂啊
郁闷ing
作者: wtfc    时间: 2008-11-5 09:35
标题: zhuzx，你当了版主就不到每周一问来答题啦？？
强烈期待您的高见？？？
作者: zhuzx    时间: 2008-11-5 09:52
标题: 朋友，这期我一定回答，呵呵！！
原帖由 wtfc 于 2008-11-5 09:35 发表
强烈期待您的高见？？？


wtfc朋友，很抱歉，刚看到您的帖子。由于最近公司项目比较多，忙了点，放心吧，这期题目我一定回答的，只是迟早的问题，谢谢您捧场！！
作者: zhangjm1688    时间: 2008-11-5 14:03
标题: 回复 16# 的帖子
英语一般！大体上还能理解，这里主要涉及到五种测试估算的方法：
第一，根据以往的经验，评直觉估算
第二，根据以往成功的测试留下的文档进行估算
第三，工作量分解估算
第四，反复多次估算
第五，随着开发的进展估算
然后一段说的是成功的测试工作量估算不容易.....
最后又提了一下关于敏捷开发模式，测试估算的问题。
原文请参见：http://www.softwareqatest.com/qat_lfaq1.html#LFAQ1_11
注：解释的不一定确切阿，你也可以把你具体不清楚地问题描述一下，让同仁们解释解释！
作者: UU1983    时间: 2008-11-5 14:49
标题: 我来说几句
我在测试这个行业工作快三年根据工作经验来说下
工作量首先请先确定您所在的企业做的项目然后才能符合实际的去评估工作量--------------一定要实际
国外项目如欧美或者对日
这样的项目一般都是有规律的也就是说用户要改什么东西都会按照双方的规定进行办事情
这种是比较好办的
首先测试经理要了解需求和上线的时间
其次要知道测试团队人员的素质
根据测试计划进行在根据测试人员的能力进行分配，每日进度报告要跟上，根据进度报告形成报表的形式，这样直观的可见整个测试团队的进度，以便调节（不会火烧屁股还不知道疼）
即使客户在上线之前提出更改也会给开发和测试的时间
国内项目
一个字乱
需求：首先客户不知道自己要什么样的好，等快要上线的时候需求突然清晰了客户的脑袋终于开窍了，开发人员要加班加点的改辛苦的很
作为测试来说到后期只能不段的加班跟进度
原因：在国内规范制约少导致客户提出的变更多甚至无礼(主要是国内变更不要钱的关系)所以合理的安排在国内很难实现
所以前期可以按照国外的项目进行规范管理但是到后来就起不到作用因为主动权不在你那而是在客户那，客户说改什么你就得改，测试当然也责无旁贷
我也看了好多测试的管理文档也受过专家的培训，不过一句话理论指导实践但不等于实践，我们一定要根据实际情况进行安排，而不是照本宣科，不管什么都套进去这个模式
这个只是我的拙见，说的不对的地方请给于纠正 谢谢
作者: liaoyin1234    时间: 2008-11-5 14:58
一些常规的估算测试工作量的方法：

       1. Ad-hoc方法
      这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。
      这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。

　   2.开发时间的百分比法Percentage of development time。
      这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。　　
      这种方法变化比较大而且通常基于以前的经验。
      通常预留项目的总花费时间的35%给测试。? 5-7%给组件和集成测试? 18-20%给系统测试? 10%给接收测试(或回归测试等)

　　3.类比法(经验值法或历史数据法)
      根据以前或相似项目(主要在项目性质，领域，规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：? 在设计和实现阶段花费的时间? 测试工作的规模，例如用户需求的数量，页面数，功能点? 数据样式，例如实体，字段的数量? 屏幕或字段数量? 测试对象的规模，例如KLOC

       4.WBS(work breakdown structure)估算法
      将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。

　　5.Delphi 法
     Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方……
      Delphi法的步骤是：
      a、协调人向各专家提供项目规格和估计表格;
      b、协调人召集小组会各专家讨论与规模相关的因素;
      c、各专家匿名填写迭代表格;
      d、协调人整理出一个估计总结，以迭代表的形式返回专家;
      e、协调人召集小组会，讨论较大的估计差异;6、专家复查估计总结并在迭代表上提交另一个匿名估计;
      f、重复4-6， 直到达到一个最低和最高估计的一致。

　　6.PERT估计法
     PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。
     用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E， 和标准偏差SD.
作者: 24489024    时间: 2008-11-5 15:09
大公司还是有教好的需求文档，但是小公司就是有点混乱了。
作者: zhuzx    时间: 2008-11-5 17:43
标题: 朋友，对这个问题我已经回答
朋友，对这个问题我已经回答，详情见博客：
http://www.51testing.com/?33505/ ... e_itemid_96807.html

[ 本帖最后由 zhuzx 于 2008-11-12 09:31 编辑 ]
作者: rsc66    时间: 2008-11-5 18:05
不愧为版主，写的太好啦！！学习一下！！！
作者: 奥运宝贝    时间: 2008-11-5 18:12
标题: 总算见到牛人回帖了，鼓励一下，哈哈
谢谢各位大侠的回帖，让我学到了不少东西。

再次感谢zhuzx亲自出马！！
作者: Fin    时间: 2008-11-5 23:30
小弟不才,总结出来一个道理
规范这些东西是根你的规模,进度时间成正比的,什么样的规模,进度时间的长短决定规范(包括工作量,人员调配等问题.)
作者: AwL_1124    时间: 2008-11-6 00:13
标题: 回复 1# 的帖子
变化太大
作者: hrsc    时间: 2008-11-6 09:27
标题: 最近的几期每周一问，老是有些人向高手扔鸡蛋，行为可恶！！
好像现在每期，都有一些不法分子，向高手扔鸡蛋，行为可恶，严重打击答题的积极性。

建议版主们出来管管！！
作者: 鬼城    时间: 2008-11-6 09:32
这样的捣蛋鬼，建议删除用户名！！！
作者: 一马平川    时间: 2008-11-6 09:45
标题: 我赞成您的观点
原帖由 鬼城 于 2008-11-6 09:32 发表
这样的捣蛋鬼，建议删除用户名！！！


很好的方法！！！
作者: zhuzx    时间: 2008-11-6 09:55
标题: 对每个人的建议或意见，应该表示理解和宽容
朋友们，不要再讨论扔鸡蛋的这个问题，好吗？每个人都有自己的想法，很正常，值得探讨和共同学习，也不是什么坏事情！！就此打住吧，拜托各位了！！
作者: zhangjm1688    时间: 2008-11-6 11:02
标题: 回复 24# 的帖子
看到你的发言，确实受益匪浅。不过，你关于“项目变更带了的风险”这部分如何进行测试估算的观点，貌似比较被动。（呵呵，恕我直言）因为，根据以往的项目经验，特别是欧美项目，需求的变更是很频繁的，那我想我们针对这种情况可否采取以下的措施：
（1）根据新的需求重新做测试工作量评估
（2）考虑尽量周到
（3）流程尽量简化
通过以上措施，积极的应对项目的变更，保证项目后期测试的顺利进行。
另外要补充的，欧美现在使用敏捷开发模式的项目还是蛮多的，针对这种项目的测试工作量评估不知zhuzx有何想法?
作者: JerryYe    时间: 2008-11-6 14:24
第一，根据以往的经验，评直觉估算
第二，根据以往成功的测试留下的文档进行估算
第三，工作量分解估算
第四，反复多次估算
第五，随着开发的进展估算
    可参考的方法有：
1.        最短时间+最长时间/2 +异常情况值.
最短时间=无任何其他问题,比如资源不足,需求不明等等问题,正常测试的时间.
最长时间=把所有需要做的工作量都算在内,就是就算没有任何前提的情况下这些时间也足能完成的时间
异常情况值=分析一下当前项目的一些总体情况,客户,或则其他问题,比如会议延迟或者客户沟通的问题.一般是很少出现.
2.        (A+4B+C)/6来计算，A代表乐观时间，B代表最可能时间，C代表悲观时间
个人分析：测试工作量的估算及计划的制定，应在参考开发计划的基础上进行，依据经验及工作量分解的方法进行。充分考虑可能的风险像开发进度的延期、人员的缺失、测试内容的难度等等。分时间段对计划工作量做重新评估调整。可能的话制定阶段性的测试量及计划。
作者: dabeixiong    时间: 2008-11-9 18:55
来晚了...献上本人答案~.~!
1. case：case的多少和复杂程度很直接地反映测试的工作量大小，当然如果有的话。甚至有时可以试着跑部分case，选那种最复杂和最简单还有最典型的，然后估算大概时间，非要精确的话可以取平均值上下浮动。
2. 环境：搭建环境的工作，测试工具、系统、平台等等的耗费因素要考虑进去。
3. 团队成员：测试人员对测试工具的熟悉程度，对项目的了解程度，对业务熟练水平，人员本身的工作效率等等加以考虑进行评估，比如这位大哥报个bug通常要多久？是不是能很轻松的跟团队成员交流？甚至考虑团队处于何种阶段，比如组建期，甜蜜期，爆炸期，成熟期，衰老期等等，也就是将个人提升到整个团队效率的高度来评估。
4. 复杂度：对软件本身进行评估是很重要的一点，待测的是个陌生的新软件？还是曾测试过类似的软件？如果是个QFE测试，那相对就轻松得多。如果是新来地...也许就得考虑是不是需要开会介绍一下待测软件，或者培训？总之想办法得让团队一开始就快速了解，这样一是避免日后的盲目性，节约时间加快速度；二让Lead们心里也有谱，就可以更好的控制时间。
5. 参照：过去项目的Schedule拿来借鉴。比如上个Release用了一周测完，现在的Release功能多出5个，还要增加接口测试，兼容性也要提高...从而根据这些要求形成新的Schedule。
6. 标准化：非常重要，以上因素都可以做为评估工作量和时间的因素，但是根据具体的项目，具体的团队，形成标准化的重要性就在于定性：哪些事情我们该做，哪些事情我们不做，哪些功能优先级高，哪些可以推迟...不仅方便量化，也对风险有更好的把握。

----------------------

具体的评估方法可以使用矩阵法列个矩阵，列是选出各种因素，行是所需时间，得出最后的预计时间。而且一般PM喜欢在此基础上打点富裕，以防不测-.O!

总结：主要思想在于知己知彼，并全面深入的考虑各方面因素。
作者: puchonghui    时间: 2008-11-9 21:42
没有稳定的团队
估算工作量纯属扯谈

同一个模块同一个功能点让不同的人来做
无论是开发还是测试
效率差别可能会在10倍以上
连人员组合都一直在变化还谈什么精确的进度表

如果你们说的这些方法都有用的话为什么还会有那么多schedule delay?
难道是没人在按照这些方法做？
那这些方法又是哪儿来的
谁能给我个理由？？

软件项目的根本因素在于人
其次才是项目本身
作者: puchonghui    时间: 2008-11-9 21:47
补充一句
24#我也扔了鸡蛋了
不是因为他的内容
而是这种贴链接的做法

宣传自己博客我不反对
但是如果能把内容copy paste过来 再附上个链接不好么
对他来说只是多点两下的事情
可就因为他少点了这两下
使得所有想浏览他的回帖的人都必须多点一次链接
这是iso9000里 以用户为中心的思想么？
作者: bingling_11    时间: 2008-11-10 17:21
标题: 如何准确评估项目测试的工作量
项目测试的工作量是一个模糊值，在评估时应尽量做到准确，但肯定存在一定的风险，评估时应考虑以下几点：
1. 项目测试分为功能测试和性能测试（包括负载压力测试），例如压力测试的连续测试时间可能必须满足大于等于7个工作日，那这部分时间就应该考虑加入测试的工作量；而功能测试基本上可以根据用户需求以及产品概要设计预估一个工作量。
2、测试工作量=需求分析时间+编写测试用例时间+执行测试用例时间+回归测试时间，再次测试前期准备时间与测试结束后的工作量都不计入。
3. 项目测试存在一定的风险，例如人员、环境、还有项目可能存在预料不到的问题。这些都会影响评估的准确性。
4.  评估测试的工作量应严格按照cmmi的各个步骤进行的话评估的工作量会比较准确，但也存在一定风险。
    总之，按照评估人员的经验以及对用户需求的准确分析仍然能评估出一个比较准确的范围值。
作者: UU1983    时间: 2008-11-10 17:55
标题: 建议高手规范自己的行为
菜鸟的求知欲甚高，但是高手的作法不妥，发了博客的连接，我刷了七次才刷出来，我在想既然要把东西公布于众为啥非得给个连接而不直接贴出来呢。。。。。。。在忙就差复制粘贴的时间了，宣传博客可以但是这种作风只在不值得褒奖，以后谁都效仿高手的作风都弄个连接，论坛里面恐怕没人用文字来叙述了，都在里面弄个连接，与人方便与己方便，希望高手下次不要这样，还有就是一件事情，我也给高手投了个鸡蛋。。。。。。。。极度的气愤与沮丧
作者: enjoy0228    时间: 2008-11-13 18:11
标题: good
作者: hejia0105    时间: 2008-11-18 11:26
学习
作者: ketty901    时间: 2008-11-21 13:02
标题: 回复 36# 的帖子
非常同意



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2