我来说几句
我在测试这个行业工作快三年根据工作经验来说下工作量首先请先确定您所在的企业做的项目然后才能符合实际的去评估工作量--------------一定要实际
国外项目如欧美或者对日
这样的项目一般都是有规律的也就是说用户要改什么东西都会按照双方的规定进行办事情
这种是比较好办的
首先测试经理要了解需求和上线的时间
其次要知道测试团队人员的素质
根据测试计划进行在根据测试人员的能力进行分配，每日进度报告要跟上，根据进度报告形成报表的形式，这样直观的可见整个测试团队的进度，以便调节（不会火烧屁股还不知道疼）
即使客户在上线之前提出更改也会给开发和测试的时间
国内项目
一个字乱
需求：首先客户不知道自己要什么样的好，等快要上线的时候需求突然清晰了客户的脑袋终于开窍了，开发人员要加班加点的改辛苦的很
作为测试来说到后期只能不段的加班跟进度
原因：在国内规范制约少导致客户提出的变更多甚至无礼(主要是国内变更不要钱的关系)所以合理的安排在国内很难实现
所以前期可以按照国外的项目进行规范管理但是到后来就起不到作用因为主动权不在你那而是在客户那，客户说改什么你就得改，测试当然也责无旁贷
我也看了好多测试的管理文档也受过专家的培训，不过一句话理论指导实践但不等于实践，我们一定要根据实际情况进行安排，而不是照本宣科，不管什么都套进去这个模式
这个只是我的拙见，说的不对的地方请给于纠正 谢谢 一些常规的估算测试工作量的方法：
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. 大公司还是有教好的需求文档，但是小公司就是有点混乱了。
朋友，对这个问题我已经回答
朋友，对这个问题我已经回答，详情见博客：http://www.51testing.com/?33505/action_viewspace_itemid_96807.html
[ 本帖最后由 zhuzx 于 2008-11-12 09:31 编辑 ] 不愧为版主，写的太好啦！！学习一下！！！
总算见到牛人回帖了，鼓励一下，哈哈
谢谢各位大侠的回帖，让我学到了不少东西。再次感谢zhuzx亲自出马！！ 小弟不才,总结出来一个道理
规范这些东西是根你的规模,进度时间成正比的,什么样的规模,进度时间的长短决定规范(包括工作量,人员调配等问题.)
回复 1# 的帖子
变化太大:(最近的几期每周一问，老是有些人向高手扔鸡蛋，行为可恶！！
好像现在每期，都有一些不法分子，向高手扔鸡蛋，行为可恶，严重打击答题的积极性。建议版主们出来管管！！ 这样的捣蛋鬼，建议删除用户名！！！
我赞成您的观点
原帖由 鬼城 于 2008-11-6 09:32 发表 http://bbs.51testing.com/images/common/back.gif这样的捣蛋鬼，建议删除用户名！！！
很好的方法！！！
对每个人的建议或意见，应该表示理解和宽容
朋友们，不要再讨论扔鸡蛋的这个问题，好吗？每个人都有自己的想法，很正常，值得探讨和共同学习，也不是什么坏事情！！就此打住吧，拜托各位了！！回复 24# 的帖子
看到你的发言，确实受益匪浅。不过，你关于“项目变更带了的风险”这部分如何进行测试估算的观点，貌似比较被动。（呵呵，恕我直言）因为，根据以往的项目经验，特别是欧美项目，需求的变更是很频繁的，那我想我们针对这种情况可否采取以下的措施：（1）根据新的需求重新做测试工作量评估
（2）考虑尽量周到
（3）流程尽量简化
通过以上措施，积极的应对项目的变更，保证项目后期测试的顺利进行。
另外要补充的，欧美现在使用敏捷开发模式的项目还是蛮多的，针对这种项目的测试工作量评估不知zhuzx有何想法? 第一，根据以往的经验，评直觉估算
第二，根据以往成功的测试留下的文档进行估算
第三，工作量分解估算
第四，反复多次估算
第五，随着开发的进展估算
可参考的方法有：
1. 最短时间+最长时间/2 +异常情况值.
最短时间=无任何其他问题,比如资源不足,需求不明等等问题,正常测试的时间.
最长时间=把所有需要做的工作量都算在内,就是就算没有任何前提的情况下这些时间也足能完成的时间
异常情况值=分析一下当前项目的一些总体情况,客户,或则其他问题,比如会议延迟或者客户沟通的问题.一般是很少出现.
2. (A+4B+C)/6来计算，A代表乐观时间，B代表最可能时间，C代表悲观时间
个人分析：测试工作量的估算及计划的制定，应在参考开发计划的基础上进行，依据经验及工作量分解的方法进行。充分考虑可能的风险像开发进度的延期、人员的缺失、测试内容的难度等等。分时间段对计划工作量做重新评估调整。可能的话制定阶段性的测试量及计划。 来晚了...献上本人答案~.~!
1. case：case的多少和复杂程度很直接地反映测试的工作量大小，当然如果有的话。甚至有时可以试着跑部分case，选那种最复杂和最简单还有最典型的，然后估算大概时间，非要精确的话可以取平均值上下浮动。
2. 环境：搭建环境的工作，测试工具、系统、平台等等的耗费因素要考虑进去。
3. 团队成员：测试人员对测试工具的熟悉程度，对项目的了解程度，对业务熟练水平，人员本身的工作效率等等加以考虑进行评估，比如这位大哥报个bug通常要多久？是不是能很轻松的跟团队成员交流？甚至考虑团队处于何种阶段，比如组建期，甜蜜期，爆炸期，成熟期，衰老期等等，也就是将个人提升到整个团队效率的高度来评估。
4. 复杂度：对软件本身进行评估是很重要的一点，待测的是个陌生的新软件？还是曾测试过类似的软件？如果是个QFE测试，那相对就轻松得多。如果是新来地...也许就得考虑是不是需要开会介绍一下待测软件，或者培训？总之想办法得让团队一开始就快速了解，这样一是避免日后的盲目性，节约时间加快速度；二让Lead们心里也有谱，就可以更好的控制时间。
5. 参照：过去项目的Schedule拿来借鉴。比如上个Release用了一周测完，现在的Release功能多出5个，还要增加接口测试，兼容性也要提高...从而根据这些要求形成新的Schedule。
6. 标准化：非常重要，以上因素都可以做为评估工作量和时间的因素，但是根据具体的项目，具体的团队，形成标准化的重要性就在于定性：哪些事情我们该做，哪些事情我们不做，哪些功能优先级高，哪些可以推迟...不仅方便量化，也对风险有更好的把握。
----------------------
具体的评估方法可以使用矩阵法列个矩阵，列是选出各种因素，行是所需时间，得出最后的预计时间。而且一般PM喜欢在此基础上打点富裕，以防不测-.O!
总结：主要思想在于知己知彼，并全面深入的考虑各方面因素。 没有稳定的团队
估算工作量纯属扯谈
同一个模块同一个功能点让不同的人来做
无论是开发还是测试
效率差别可能会在10倍以上
连人员组合都一直在变化还谈什么精确的进度表
如果你们说的这些方法都有用的话为什么还会有那么多schedule delay?
难道是没人在按照这些方法做？
那这些方法又是哪儿来的
谁能给我个理由？？
软件项目的根本因素在于人
其次才是项目本身 补充一句
24#我也扔了鸡蛋了
不是因为他的内容
而是这种贴链接的做法
宣传自己博客我不反对
但是如果能把内容copy paste过来 再附上个链接不好么
对他来说只是多点两下的事情
可就因为他少点了这两下
使得所有想浏览他的回帖的人都必须多点一次链接
这是iso9000里 以用户为中心的思想么？
如何准确评估项目测试的工作量
项目测试的工作量是一个模糊值，在评估时应尽量做到准确，但肯定存在一定的风险，评估时应考虑以下几点：1. 项目测试分为功能测试和性能测试（包括负载压力测试），例如压力测试的连续测试时间可能必须满足大于等于7个工作日，那这部分时间就应该考虑加入测试的工作量；而功能测试基本上可以根据用户需求以及产品概要设计预估一个工作量。
2、测试工作量=需求分析时间+编写测试用例时间+执行测试用例时间+回归测试时间，再次测试前期准备时间与测试结束后的工作量都不计入。
3. 项目测试存在一定的风险，例如人员、环境、还有项目可能存在预料不到的问题。这些都会影响评估的准确性。
4.评估测试的工作量应严格按照cmmi的各个步骤进行的话评估的工作量会比较准确，但也存在一定风险。
总之，按照评估人员的经验以及对用户需求的准确分析仍然能评估出一个比较准确的范围值。
