4. 根据测试经验的积累来评估工作量：
我们可以借鉴类似项目的测试经验，比如说被测试的系统，我们做过类似的产品，就可以把相关的测试文档，修改一下，复用以前的测试用例，这时候测试工作量就减少了很多。如果没有，我们只能重来。还有就是借鉴以前项目编写测试用例或执行测试的时间，对测试工作量的准确评估，也具有一定的参考价值。
5. 根据测试风险来评估工作量：
a）、测试人员变动带来的风险：
在一般的软件公司，测试人员的流动是常有的事情，所以估计测试工作量的时候，我们一定要把它计算在里面，留有一定的余地，以防不测。比如说：以前安排了一个做过类似项目，对类似项目熟悉的测试人员，也许给他安排了一天的工作量。如果他不在了，其它的人去做这个测试也许就2天，甚至3、5天都不一定能够搞定。测试人员带了的风险还是特别高的。
b）、系统测试环境的风险：
系统测试环境带来的风险，一般来说比较小，发生的可能性很小，如果一旦发生了，也相当可怕。最可怕的就是硬件故障，在经济实力允许的情况下，我们一般的方法是准备两套测试环境，一套测试环境出现问题，我们立马切换到另外一个测试环境中去继续测试，避免影响正常的测试进度。但是大部分的公司都不愿意花血本，来购买昂贵的硬件，而是以牺牲时间来付出代价。
c）、开发人员版本发布延迟风险：
不做好版本配置管理或没有正规的测试规范的公司，大部分情况下很难估计工作量，他们基本上都是边改边开发边测试，如果一旦开发出现异常，整个测试就立马终止，这对测试的相互制约作用也会更大，这样对我们估算的工作量也不准确。
d）、项目变更带了的风险：
一个项目做到中途，由于客户对技术不断深入的了解，很多时候不是“需求变更”，就是“设计变更”，弄得我们测试人员特别郁闷，不断修改测试文档。如果相关部门没有正规的变更管理，变更引起的工作量更没办法估算。很多测试后期出现工作量加大，测试延期的问题，都是对项目风险估算不足造成的。
6. 发挥项目团队的力量来评估工作量：
a)、积极调动下属，发挥集体的智慧：
我带领的测试团队，对工作量的估计大致是这样的：
测试主管对自己带的项目做一个整体时间预估，给出一个大致估计时间。我再把每个模块分配给准备安排测试这个项目的每个测试工程师做一个测试工作量评估，得到结果后和测试主管的工作量对比。这个时候我要考虑他们每个人的实际能力做适当的调整，最后把调整相对准确的时间，递交项目组评审，如果通过，就OK，如果他们有建议，视建议的程度好坏，再决定是否做修改。有空的时候，我会定时检查每个人的工作内容是否准时完成，督促一下工作。一般来说，时间偏差相差不会超过一周，呵呵！！！
b)、建立一个测试工作量的预算表格：
测试计划书写结束，我一般是把测试工作量的每一项，写成一个Checklist，每项大致多少时间，写出来。邮件的形式发给部门的全体成员，提高工作量的透明度。每天下班结束以前，每个人都要对测试的工作做汇报，包括已经完成的工作或未完成的工作都进行汇报，时间不是很长，就几分钟的时间，测试Leader也要做Review，以防虚报
文章来源于领测软件测试网 https://www.ltesting.net/
