测试需求分析

测试需求是用来识别什么内容是需要进行测试的，通常需要覆盖一些业务规则，功能以及非功能的内容，不需要有实际的测试数据出现。如作为验证插入DB的操作，测试需求为：“验证你能插入一条记录”；“如果记录已经存在，插入将失败”；“如果表已经满了，插入将失败l”；“初始状态时能插入一条记录到一个空的表中”

为什么要识别测试需求？
是确定测试完整性的一个基础；用以确定测试的范围；用来识别可做自动化测试的策略；作为一个测试的方向标；
测试需求从哪里来?
业务需求，功能内部逻辑；MRD,技术设计方案，UC等
业务需求与测试需求的关系

业务需求通常是指系统需要做什么，如ATM能进行取款；取款在20-300之间；取款的金额是20的倍数，而测试需求除了需要覆盖系统应该做什么外，还要覆盖系统不应该做什么，是用来发现需求中存在的问题，如取款按钮是可选的；在20-300之间的20的倍数是可取的；小于20元是不允许的；大于300是不允许的；20的倍数但是大于300是不允许的；在20-300之间但不是20的倍数是不允许的；收到的金额与请求的金额相当；取款的总额必须是小于账户余额等等

建议的测试需求分析层级图如下：

业务功能级别：关注相互之间的联系，完整性以及系统功能之间的交互性(可选)
功能任务级别：把每个功能分解成任务，对于复杂的任务，可以分解成子任务，注意：一些业务功能不能被分解成更细的任务

 事务级别/事务数据类型级别：执行这项任务DB要执行的事务，关注系统内部发生的任务，鉴别与DB关联的逻辑事务或者其他与执行任务相关的事务，识别数据处理，计算，数据的格式化处理; 识别将做哪种操作：增加，删除，修改，查询；一个事务完全可能做多种操作

字段校验级别：对各种数据类型的校验，覆盖对所有字段数据的编辑以及交叉编辑，使用校验对象的某某属性，请参考什么附表即可，不要把每个属性都作为一个独立的测试需求

事例说明如下：
1. 验证出租车任务成功（业务功能级别）
1.1 检查客户投保情况（任务级别）
1.2 查询车是否可取（任务级别）
1.3查询车辆费用（任务级别）
1.4 开出租票（任务级别）
1.4.1 验证顾客记录能输入（事务级别）
1.4.2验证信用卡信息查询结果有效（事务级别）
1.4.2.1 验证在有效日期范围内
1.4.2.2 验证字段的有效位数
1.4.2.3 验证信用卡余额足够
1.4.3验证车的状态从“等待”变为“已出租” （事务级别）

2. 账务结算功能（业务功能级别）
3. 出租车预定功能（业务功能级别）

在进行测试需求编写时，建议尽量按功能组或相关功能的方式来进行划分：如出租车租金费计算，出租车预定功能等，确保覆盖系统的各个方面。

注：本文转自http://qa.taobao.com/?p=10186