提取
测试需求是
软件测试活动中的基础
工作，是测试活动展开的前提条件。
在项目实施前在做整个系统的测试方案中工作量评估时，如果是基于系统功能点的方法，则已经对系统中的功能点、性能点等进行分析统计，可以直接在该分析结果的基础上进行细化和完善。
外包项目测试活动中确定用户需求范围是最重要也最困难的工作之一。往往在项目实施前无法准确界定测试范围，原因很多，主要有以下几个方面：
1、系统用户需求不详细，从而无法确定测试范围；
2、用户需求中简单的描述，可能包括很多研发工作，也需要测试，容易别忽略；
3、行业经验不足，对其中的业务不熟悉，造成对业务功能不能确定；
在测试过程中，带来测试范围变化的原因，主要包括：
1、在研发过程中客户较大的改变原来的需求，扩展原来的需求；
2、研发公司改变客户的需求，带来测试范围的变化；
综合以上的原因，主要来自于三个方面：
1、客户的需求前期描述不清，后期的增加、修改变化；
2、研发公司对需求的变更；
3、我们自己团队行业业务、项目经验的不足；
对于第1点，可以约定测试用户需求的基线版本，对于研发过程中需求变更超过一定范围，重新评估增加的工作量。
对于第2点，可以同第1点一样，同客户在前期约定好。
对于第3点，则是需要一个过程，业务和项目经验积累需要一个过程。
要确定测试需求，相当于确定了测试范围，则能比较准确的确定工作量。如何分析测试需求呢？
首先、分析用户提供的所有文档，在业务分析师的帮助下，根据业务分解系统功能，由粗到细，逐渐细化需求，这其中需要客户、研发团队的协助，把不清晰、不明确、不具有可测试性的需求转化明确的、具有可测性的需求。根据测试需求对应的集成测试、系统
功能测试和
性能测试活动不同，其测试需求也不同，例如，对于产品集成测试，则测试需求细化到测试集成的每个模块接口、子系统接口即可。对于功能测试则时一个具体的功能实现，该功能可能时一个典型业务中的一个操作，也可能是整个典型业务。如果是一个典型业务的一个操作功能，则最好把整个典型业务的测试需求串接在一起，形成一个典型业务的测试需求链（具有相关的测试需求形成的一个序列）。
其次、把测试需求尽量使用测试管理工具进行管理，便于测试需求的统计、变更，以及与
测试用例形成关联。
测试需求在客户评审通过后，要形成基线，以后用户需求变更后，要进行测试需求的变更，且保持测试需求与用户需求的版本一致
这篇
文章觉得写的不错，所以转载一下。对于需求最近也深有体会啊。公司刚接收了一个新项目，客户的需求也比较简单，只说要有什么功能，一句话就没了。因为这个功能虽然是A模块的，但它牵涉到调用B模块，在A和B模块的交接处客户未做说明。于是开发想当然的做了，功能是做好了，也满足了需求，但对于用户来说是很不方便的，我们测试人员为此就提了bug.可以说这个测试还是很不错的，能够站在用户的角度考虑。
----------------------------------------------------------------------
需求一般分为显式需求和隐式需求两种
一、显式需求提取参照需求说明书：
1、逐个罗列出功能点，功能描述
2、考虑交叉功能点
3、画出业务流程图
二、对于隐式需求
1、针对行业知识，向客户（提需求的人）和项目组内熟悉产品的人请教。切记，“闻道有先后，术业有专攻”，在这方面很多人需要习惯并且擅长向他人
学习，你就要问的他都烦。
2、针对用户实际需求，要问清楚他想解决的问题和以后的期望值，做到“未雨绸缪”，想客户之所想。期望值虽然暂时达不到，但一定会为你了解产品有非常大的帮助。
3、软件实际需求，在了解用户需求的基础上，向技术人员请教，了解当前产品所能达到的目标。
综上，把所有需求功能点罗列在一张表格里，找对应人员确认，查缺补漏
