2、文档

　　从已有项目文档中提取有价值的内容。结合《测试申请单》的内容，在用户原始需求资料、需求文档、设计文档中寻找有价值资料。记住用户原始资料的重要性，当发现疑问时，有可能需求文档或设计文档出现了歧义，可以在用户提供资料中提取信息。

　　3、自身业务知识

　　第三点是凭借自己对软件的了解，对业务知识的了解，甄别需求完整性，正确性，加以补充。

　　4、确定测试需求范围

　　n多项需求，在经过前三步后，确定本次测试点需求范围。以及各个需求点具体内容。

　　5、画个流程图

　　可以根据需求要点，画业务流程图，方便梳理自己的思绪。

　　6、用户确认，或者跟开发人员或者有经验的同事确认

　　辛苦的整理完这些东西，好跟用户或者开发人员有个沟通，让他们帮你判断本次测试需求你了解的准确性，并且可以提出意见。及时将反馈意见补充到你的测试需求文档中。

　　需求确认完毕，开始测试。

　　如何提取测试需求

　　一、与需求相关的

　　1、直接来自需求

　　测试需求的绝大部分直接来自需求。工作中其实容易混淆什么是真正的需求，什么是需求的解决方案，什么是设计和实现带来的约束。什么是需求呢？如果不这样不行的，才是需求。例如，作为一个银行系统，客户需要能够查询余额。不能查询余额的系统银行不会为这个系统而买单。所以，这是需求。那么，需要密码才能查询余额是不是需求呢？这不是需求。因为我可以通过指纹识别来查询余额吧，为什么一定要用密码呢？那么要设定一个6位数字当作密码是不是需求呢？当然也不是。这只是为了达到保密目的而做的一个设计上的限制。6位密码其实完全可以是8位或者别的身份标志。所以，先弄清什么是真正的需求，然后提取出来作为测试需求。

　　2、补充需求

　　需求并不完美，所以你还可以补充一些需求。具体包括：遗漏（如：分支流程、对特殊数据的支持和处理。。。）；隐性的需求（如：对某些人或特定领域来说的常识；行业规范；UI标准；停留在需求分析人员脑中的隐含需求）；竞争对手的类似系统的功能等。

　　3、挖掘需求

　　通过提问的方式可以挖掘一些需求。例如，通常比较难以得到高质量的非功能需求。因为用户只是需要越快越好，他也无法告诉你多快才是他能接受你又可行的。这时，通常相应的性能测试需求可以通过Q&A的形式以具体的问题去启发或者得到。还有一些需求，虽然一直存在，但用户长期以来已经习惯了忍受。你不从某个角度去问，他也不会当作需求提给你。

　　二、不会出现在需求中的

　　某些测试需求不会出现在需求中，因此需要测试人员补充。

　　1、反向测试用例

　　你常需要补充的测试需求中很重要的一块是反向测试用例，即需求要求这样做了。那么需求上没有要求做的是否系统没有做。

　　2、设计和实现约束

　　前面“直接来自需求”中提到的需求的解决方案或者设计/实现的约束，在其进一步确认后需要逐步补充到测试需求中来。

　　3、可测试性的需求

　　后一点常容易被人忽视：测试人员还需要补充为了提高系统可测试性而提的测试需求。例如，某个系统依赖于多个其他系统的接口。为了在对方没有提供可测试的环境或者版本的时候可以先测试我方对接口的正常处理，需要系统提供一个功能，模拟生成对方的数据，也可以查看我方发给对方数据包的具体内容。

　　需求一般分为显式需求和隐式需求两种

　　一、显式需求提取参照需求说明书：

　　1、逐个罗列出功能点，功能描述

　　2、考虑交叉功能点

　　3、画出业务流程图

　　二、对于隐式需求

　　1、针对行业知识，向客户（提需求的人）和项目组内熟悉产品的人请教。切记，“闻道有先后，术业有专攻”，在这方面很多人需要习惯并且擅长向他人学习，你要问的他都烦。

　　2、针对用户实际需求，要问清楚他想解决的问题和以后的期望值，做到“未雨绸缪”，想客户之所想。期望值虽然暂时达不到，但一定会为你了解产品有非常大的帮助。

　　3、软件实际需求，在了解用户需求的基础上，向技术人员请教，了解当前产品所能达到的目标。

　　综上，把所有需求功能点罗列在一张表格里，找对应人员确认，查缺补漏