提取测试需求是测试活动中的基础工作，是测试活动展开的前提条件。

        在项目实施前在做整个系统的测试方案中工作量评估时，如果是基于系统功能点的方法，则已经对系统中的功能点、性能点等进行分析统计，可以直接在该分析结果的基础上进行细化和完善。

        外包项目测试活动中确定用户需求范围是最重要也最困难的工作之一。往往在项目实施前无法准确界定测试范围，原因很多，主要有以下几个方面：

1、系统用户需求不详细，从而无法确定测试范围；

2、用户需求中简单的描述，可能包括很多研发工作，也需要测试，容易别忽略；

3、行业经验不足，对其中的业务不熟悉，造成对业务功能不能确定；

        在测试过程中，带来测试范围变化的原因，主要包括：

1、在研发过程中客户较大的改变原来的需求，扩展原来的需求；

2、研发公司改变客户的需求，带来测试范围的变化；

        综合以上的原因，主要来自于三个方面：

1、客户的需求前期描述不清，后期的增加、修改变化；

2、研发公司对需求的变更；

3、我们自己团队行业业务、项目经验的不足；

        对于第1点，可以约定测试用户需求的基线版本，对于研发过程中需求变更超过一定范围，重新评估增加的工作量。

        对于第2点，可以同第1点一样，同客户在前期约定好。

        对于第3点，则是需要一个过程，业务和项目经验积累需要一个过程。

        要确定测试需求，相当于确定了测试范围，则能比较准确的确定工作量。如何分析测试需求呢？

        首先、分析用户提供的所有文档，在业务分析师的帮助下，根据业务分解系统功能，由粗到细，逐渐细化需求，这其中需要客户、研发团队的协助，把不清晰、不明确、不具有可测试性的需求转化明确的、具有可测性的需求。根据测试需求对应的集成测试、系统功能测试和性能测试活动不同，其测试需求也不同，例如，对于产品集成测试，则测试需求细化到测试集成的每个模块接口、子系统接口即可。对于功能测试则时一个具体的功能实现，该功能可能时一个典型业务中的一个操作，也可能是整个典型业务。如果是一个典型业务的一个操作功能，则最好把整个典型业务的测试需求串接在一起，形成一个典型业务的测试需求链（具有相关的测试需求形成的一个序列）。

        其次、把测试需求尽量使用测试管理工具进行管理，便于测试需求的统计、变更，以及与测试用例形成关联。

        测试需求在客户评审通过后，要形成基线，以后用户需求变更后，要进行测试需求的变更，且保持测试需求与用户需求的版本一致。