测试需求按照功能性、可靠性、易用性、性能、可维护性、可移植性来分类。同时也要按照优先级来分类，有的是必须测试通过的，有的可以协商。

　　除了说明我们需要测试的内容以外，测试需求还有一个重要的作用：辅助说明测试接受标准。比如某个版本的功能测试需求有100个功能点，其中30个必须实现，其他70个实现60个即可，假如每个功能点1分，那么，功能测试接受标准就是：总分90分以上并且30个重要功能点必须测试通过。假如没有达到这个接受标准（只有85分），我们就可以负责的说：测试不通过，不能发布。如果要发布，可以，变更项目计划和测试计划。

　　测试需求最好能细致到功能点的粒度，这样对项目量化管理非常有好处，而且，我认为这是应该在项目版本计划中进行说明的，如果项目计划中没有说的很详细，那我们的测试计划就要写的详细一些。

　　我们来看一个例子，这是武汉公安项目的测试报告的一部分，其中列出了功能测试需求的执行情况。

添加专项工作	操作角色仅为系统管理员，正确新建专项工作	通过
编辑专项工作	操作角色仅为系统管理员，正确保存编辑后的专项工作	通过
删除专项工作	操作角色仅为系统管理员，正确删除所选的专项工作	通过
导出专项工作的警情列表	按照同样的数据字典格式导出保存为.xls文件	通过

　　可以看出这里的测试需求列的比较细，而且是以用户的角度来进行说明。至于在实际项目中，我们需要写的多细，可以根据项目情况来决定，只是不要忘记我们编制测试计划的主要目的。建议尝试把测试需求写细一些，体会一下量化管理的感觉。以后我们的测试例会可以把测试需求拿出来评审，比较一下不同项目的不同策略。