a）制定测试计划以前，明确测试范围：
不同的测试范围，对测试量的评估起到至关重要的因素，比如说测试一个模块或测试多个模块或测试整个系统等等，都属于测试范围不一样，明显工作量也不同，差别也挺大的。还有测试范围还包括功能性测试范围或非功能性测试范围等等，在做测试工作量评估的时候，都必须考虑。
b）确定合理、有效的测试方法：
比如说你要考虑测试某个项目，你必须考虑测试方法是否合理。比如说某个模块的功能测试，你可以采用QTP做自动化功能测试，还是手工做功能测试，工作量就不一样，做测试计划以前必须考虑清楚。要不然，估算的工作量肯定不准。
2. 根据测试任务来评估工作量：
a）质量需求和项目背景决定工作量：
不同的项目背景，不同的质量要求，决定不同的测试工作量。如果我们测试的是一个银行系统，涉及到每个人的经济利益，我们测试时必然会对性能测试或安全测试放到第一位，设计较多的异常测试用例，这样一做，必然增加我们的工作量。如果是一般的系统，我们可以只执行一般的功能测试通过就可以了，没有必要去做其它的异常、安全测试。如果系统的质量需求要求高，也许就要进行更深层次的测试，回归测试的力度必然要加大，工作量自然就上去了。
b）尽可能详细的罗列出项目测试内容：
一般来说，测试工作量的评估工作都是交给测试经理或项目组成员协助共同来完成的。准确评估项目测试的工作量，必须要求测试Leader明确详细的测试内容，只有知道测试什么？哪些需要测试？详细分析需求规格说明书，明确测试任务以后，评估才会有依据，所以
尽可能详细的罗列出项目测试内容非常必要。
c）把测试任务细化到每个测试功能点：
我们在估算测试时间的时候，可以把测试任务细化到每个测试的功能点，比如说“新增”、“修改”、“删除”、“暂停”、“恢复”等等都记成一个功能点，在预算的时候，同时把编写测试用例和执行测试用例的时间都要计算进去。例如：编写一个测试用例或执行一个功能测试各需要一个小时，如果我们有100个功能点，我们就知道大约要200个小时。这样估算出来的时间比较精确一点，比较符合实际。
d）预估业务测试或模块交叉测试的复杂容易程度：
很多时候，我们测试初期，对业务了解不是很多，忽视了对业务方面或交叉模块测试的评估，等到了测试后期，大量的业务测试没有测试，测试时间特别紧，所以在测试初期预估测试的复杂容易程度，在评估工作量方面至关重要。
3. 根据开发阶段来评估工作量：
不同的开发阶段，测试时间估算也不太相同。比如说，开发的系统是第一个版本，相对以后的测试工作来说，可能安排的时间要多一点。大多数情况下是这样的，也许后面的版本增加很多新功能，测试工作量还大于第一个版本也是常有的事情。作为测试负责人，对于使用测试阶段来评估工作量，必须根据实际情况来定，不能盲目给出数字，应付了事。
