如何估计测试的工作量呢？
我们采用的一般方法是根据以往的经验，和客户那边过来的需求说明来做工作量的估计。基本上没有什么正规的流程和方法。想知道业界有没有比较成熟的、通用的方法来做这个呢？谢谢！ 我也有这方面的 困扰，就是每次都觉得自己能够完成工作，但又每次都赶÷要么就是加班完成，总是很郁闷。我知道问题并不是在我，而是与开发的配合，我提出的问题没能及时修改，时间就浪费在这等待中。所以每次都很郁闷。。。 Kali，我觉得我的问题和你碰到的问题可能还不完全一样。
我现在最大的困扰是估算跑完一遍测试用例的工作量。简单说，也就是完成一个产品或者某个功能的测试，需要多少测试用例。然后按照某些经验值，就可以算出完成第一遍测试，需要的时间。我知道某些大公司有比较完善的流程或者算法，例如根据code的数量计算测试用例的数量（？？？），我们公司则完全没有，大家全凭经验。：（
至于你说的问题，我们也经常遇到，说一些我的经验：
1、遇到某些问题需要开发组做修改的时候，如果不是非常严重的问题，我们采用的方法是绕开这个问题，继续其他的测试。否则整个测试组都停下来等着，根本等不起。
2、如果遇到严重的问题，系统根本没办法继续工作了，那么无论如何也一定要开发组最先修改；
3、但是如何避免严重的问题的出现呢？我们采用的方法是，监控开发组做Integration test的质量。提出我们的要求，“如果他们做Integration test之后，产品质量不能达到某一标准，我们拒绝开始测试！”当然这种做法，需要得到大老板的支持，和开发组老板的支持。
希望有所帮助。
你确实问了个很难回答的问题
有些人喜欢用文档来计算工作量，比如查看需求文档的页数，再算一定的比率，个人觉得这是没有意义的。另外一些人，喜欢用功能点来计算，主要还是凭个人经验吧。
而在实际工作中，我们喜欢用开发的周期来计算测试的周期。考虑到一个队伍的成熟和默契度。将开发周期乘一定的指数。
比如，开发一个系统，从开发到首次编码全部完成，开发部大概心里有个数。然后，我们的时候就是它的一定的系数了。我们一般是1.5倍这样算。 很困难，一般我是按需求细化再进行估算的。简单的估算是一个功能，两种Case（一正一反）；如果碰到复杂点的情况，还需要使用到概率统计和覆盖率估算的方法进行验证。 我觉得暂时还没有什么系统的、科学的方法来估计
按功能点及其复杂度来估计可能会比较好
但是这里面完全也是个经验值的…… 我觉得用公式加经验，公式毕竟是个死的东西，不通用。 大多还是以经验来判断 我觉得测试工作量估算应结合系统业务复杂度、业务功能点多少、测试人员水平、测试类型等多方面考虑。当然，如果之前有做过类似项目，可以根据以往测试类似项目的经验来估算
页:
[1]
