如何准确评估项目测试的工作量？(08-11-03)（获奖名单已公布）

默默巫

很多时候，测试工作量评估不准确，就导致测试延期，系统无法准时上线，给测试部门的头头压力搞得很大。我想知道作为测试Leader, 如何准确评估项目测试的工作量，才能够保证项目测试的顺利进行？

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


因本次答案多为转贴,一等奖空缺.　

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	空缺	当当购物卡50元	空缺
二等奖	ianshine	300论坛积分	11＃
	zhangjm1688		14＃
三等奖	liaoyin1234	100论坛积分	22＃
	zhuzx		24＃
	archonwang		5＃

ketty901

非常同意

hejia0105

学习

enjoy0228

UU1983

菜鸟的求知欲甚高，但是高手的作法不妥，发了博客的连接，我刷了七次才刷出来，我在想既然要把东西公布于众为啥非得给个连接而不直接贴出来呢。。。。。。。在忙就差复制粘贴的时间了，宣传博客可以但是这种作风只在不值得褒奖，以后谁都效仿高手的作风都弄个连接，论坛里面恐怕没人用文字来叙述了，都在里面弄个连接，与人方便与己方便，希望高手下次不要这样，还有就是一件事情，我也给高手投了个鸡蛋。。。。。。。。极度的气愤与沮丧

bingling_11

项目测试的工作量是一个模糊值，在评估时应尽量做到准确，但肯定存在一定的风险，评估时应考虑以下几点：
1. 项目测试分为功能测试和性能测试（包括负载压力测试），例如压力测试的连续测试时间可能必须满足大于等于7个工作日，那这部分时间就应该考虑加入测试的工作量；而功能测试基本上可以根据用户需求以及产品概要设计预估一个工作量。
2、测试工作量=需求分析时间+编写测试用例时间+执行测试用例时间+回归测试时间，再次测试前期准备时间与测试结束后的工作量都不计入。
3. 项目测试存在一定的风险，例如人员、环境、还有项目可能存在预料不到的问题。这些都会影响评估的准确性。
4.  评估测试的工作量应严格按照cmmi的各个步骤进行的话评估的工作量会比较准确，但也存在一定风险。
    总之，按照评估人员的经验以及对用户需求的准确分析仍然能评估出一个比较准确的范围值。

puchonghui

补充一句
24#我也扔了鸡蛋了
不是因为他的内容
而是这种贴链接的做法

宣传自己博客我不反对
但是如果能把内容copy paste过来 再附上个链接不好么
对他来说只是多点两下的事情
可就因为他少点了这两下
使得所有想浏览他的回帖的人都必须多点一次链接
这是iso9000里 以用户为中心的思想么？

puchonghui

没有稳定的团队
估算工作量纯属扯谈

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

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

软件项目的根本因素在于人
其次才是项目本身

dabeixiong

来晚了...献上本人答案~.~!
1. case：case的多少和复杂程度很直接地反映测试的工作量大小，当然如果有的话。甚至有时可以试着跑部分case，选那种最复杂和最简单还有最典型的，然后估算大概时间，非要精确的话可以取平均值上下浮动。
2. 环境：搭建环境的工作，测试工具、系统、平台等等的耗费因素要考虑进去。
3. 团队成员：测试人员对测试工具的熟悉程度，对项目的了解程度，对业务熟练水平，人员本身的工作效率等等加以考虑进行评估，比如这位大哥报个bug通常要多久？是不是能很轻松的跟团队成员交流？甚至考虑团队处于何种阶段，比如组建期，甜蜜期，爆炸期，成熟期，衰老期等等，也就是将个人提升到整个团队效率的高度来评估。
4. 复杂度：对软件本身进行评估是很重要的一点，待测的是个陌生的新软件？还是曾测试过类似的软件？如果是个QFE测试，那相对就轻松得多。如果是新来地...也许就得考虑是不是需要开会介绍一下待测软件，或者培训？总之想办法得让团队一开始就快速了解，这样一是避免日后的盲目性，节约时间加快速度；二让Lead们心里也有谱，就可以更好的控制时间。
5. 参照：过去项目的Schedule拿来借鉴。比如上个Release用了一周测完，现在的Release功能多出5个，还要增加接口测试，兼容性也要提高...从而根据这些要求形成新的Schedule。
6. 标准化：非常重要，以上因素都可以做为评估工作量和时间的因素，但是根据具体的项目，具体的团队，形成标准化的重要性就在于定性：哪些事情我们该做，哪些事情我们不做，哪些功能优先级高，哪些可以推迟...不仅方便量化，也对风险有更好的把握。

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

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

总结：主要思想在于知己知彼，并全面深入的考虑各方面因素。

JerryYe

第一，根据以往的经验，评直觉估算
第二，根据以往成功的测试留下的文档进行估算
第三，工作量分解估算
第四，反复多次估算
第五，随着开发的进展估算
    可参考的方法有：
1.        最短时间+最长时间/2 +异常情况值.
最短时间=无任何其他问题,比如资源不足,需求不明等等问题,正常测试的时间.
最长时间=把所有需要做的工作量都算在内,就是就算没有任何前提的情况下这些时间也足能完成的时间
异常情况值=分析一下当前项目的一些总体情况,客户,或则其他问题,比如会议延迟或者客户沟通的问题.一般是很少出现.
2.        (A+4B+C)/6来计算，A代表乐观时间，B代表最可能时间，C代表悲观时间
个人分析：测试工作量的估算及计划的制定，应在参考开发计划的基础上进行，依据经验及工作量分解的方法进行。充分考虑可能的风险像开发进度的延期、人员的缺失、测试内容的难度等等。分时间段对计划工作量做重新评估调整。可能的话制定阶段性的测试量及计划。

zhangjm1688

看到你的发言，确实受益匪浅。不过，你关于“项目变更带了的风险”这部分如何进行测试估算的观点，貌似比较被动。（呵呵，恕我直言）因为，根据以往的项目经验，特别是欧美项目，需求的变更是很频繁的，那我想我们针对这种情况可否采取以下的措施：
（1）根据新的需求重新做测试工作量评估
（2）考虑尽量周到
（3）流程尽量简化
通过以上措施，积极的应对项目的变更，保证项目后期测试的顺利进行。
另外要补充的，欧美现在使用敏捷开发模式的项目还是蛮多的，针对这种项目的测试工作量评估不知zhuzx有何想法?

zhuzx

朋友们，不要再讨论扔鸡蛋的这个问题，好吗？每个人都有自己的想法，很正常，值得探讨和共同学习，也不是什么坏事情！！就此打住吧，拜托各位了！！

一马平川

原帖由 鬼城 于 2008-11-6 09:32 发表
这样的捣蛋鬼，建议删除用户名！！！

很好的方法！！！

鬼城

这样的捣蛋鬼，建议删除用户名！！！

hrsc

好像现在每期，都有一些不法分子，向高手扔鸡蛋，行为可恶，严重打击答题的积极性。

建议版主们出来管管！！

AwL_1124

变化太大

Fin

小弟不才,总结出来一个道理
规范这些东西是根你的规模,进度时间成正比的,什么样的规模,进度时间的长短决定规范(包括工作量,人员调配等问题.)

奥运宝贝

谢谢各位大侠的回帖，让我学到了不少东西。

再次感谢zhuzx亲自出马！！

rsc66

不愧为版主，写的太好啦！！学习一下！！！

zhuzx

朋友，对这个问题我已经回答，详情见博客：
http://www.51testing.com/?33505/ ... e_itemid_96807.html

[ 本帖最后由 zhuzx 于 2008-11-12 09:31 编辑 ]