4、对每个功能点进行整理、罗列，然后在对各功能点进行分析整理，逐步细化为5W格式（明确：什么样的系统用户，在什么时间、什么样的环境下、执行了什么样的操作，产生了什么样的结果）

　　5、跟开发人员、用户或者有经验的测试人员确认，让他们帮你判断本次测试需求你了解的准确性、覆盖率，并且可以提出意见，如有疑问则属于未属于未明确需求需要与用户再次沟通。

　　● 提取测试需求常用方式

　　1、最常见的方式是：通过现有的需求规格说明书得到，但是这个方式的前提是必须有具备需求规格说明书或类似的文本记录。实际上大多数公司或者需求规格说明书不够明确，要么甚至没有。这样的测试需求提炼非常困难。

　　2、第二种方式，则是通过测试组织或人员的经验来形成，比如来自一些通用的行业规范等等。这种提取方法有很大的不确定性，比较容易遗漏重要的测试项，且个人能力不同，导致的结果千差万别。

　　3、第三种方式，通过已实现的系统来获得，这种方式，在工程学角度上是逆反工程——有点亡羊补牢的味道，常用于无需求文档或文档达不到要求的的情况下。由于缺乏正规的工程方法，这种方法往往都是形式而无法在实质上改善软件质量。

　　● 编写测试需求的要点：

　　1、从整体上把握系统，通过阅读相关的说明书来了解系统的主要业务；

　　2、深深了解系统的中涉及到的用户有哪些，不同的用户权限有哪些；主要模块有那些；每个模块的主要实现功能是什么、每个模块的数据从哪里来，最后到哪里去，每个模块可以受什么样的用户什么样的权限控制和操作；系统最后要实现什么样的功能和得到怎样的数据。

　　3、挖掘需求，能挖掘到需求：哪些地方/哪些功能/哪些需求是用户/开发没有想到的，没有想正确的，没有设涉及到的，为用户的使用多想几个为什么一一列出来，在开发之前做到最优化的方案。

　　4、主要模块主要写，次要模块捎带上写；写的测试需求要有整体感，系统化。一目了然！抽象出自己的话语进行写，不要抄袭开发写的书。

　　5、不明确的需求要和开发达成一直，并把相应的内容罗列出来。

　　总之，最主要的是要自己能对系统有整体的把握，系统的理解。知道系统的主要业务和主要数据，对任何人提出的相关问题可以一一详细作答。

　　说的比较浅，自己有很深的体会和了解，并有一定的技巧，欢迎大家一起讨论。