测试需求分析
主要目的
获取测试点，根据测试点来编写测试用例
把不直观的需求转变为直观的需求（流程图）
（1）使得测试范围可以度量（有多少功能点，有多少功能项）
（2）使得独立的功能点其对应的所有处理分支可以度量
（3）使得系统需要测试的业务场景可以度量
需求分析和测试需求分析的区别
需求分析：初步设想----原始需求----需求分析----需求规格：输入、处理和输出
测试需求分析：单功能点输入处理输出----业务流程分析----全局----隐式需求挖掘需求分析和测试需求分析
注意：二者的过程不同
测试需求分析：
1、通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容（功能测试）
2、通过分析各个功能模块之间的业务顺序，和接口之间信息和数据的传递，对存在功能交互的功能项，给出对应的验证内容（功能交互测试）
3、考虑到需求的完整性，要充分考虑隐式需求的验证，比如界面的验证，注册账号的唯一性验证（界面、易用性、兼容性、安全性、性能）
4、根据场景法和错误分析法补充测试用例
其中1和2来自需求文档。
对于功能交互测试（接口测试/集成测试）举个例子：
登录和注册：系统内的接口测试
OA系统和CRM系统集成：系统外的接口测试
此外还有前端和后台管理之间的接口测试
对于3来说，一定要充分挖掘隐含需求
产品经理：客户和业务提出来的初步设想，得到原始需求，需求分析（输出需求规格说明书）
测试需求分析：单个功能点和流程进行分析，全局（上路测试）-挖掘隐含需求 进行分析
测试点分析步骤
1、正常功能验证
2、功能验证：按顺序从上至下，对每个输入项进行验证（数据长度、数据类型，必填项）
3、功能交互验证：模块之间传递的信息和数据，存在功能交互的功能项
4、隐性需求：充分熟悉产品业务，挖掘隐性需求
对于一个存在生命周期的软件来说，开发和测试往往不是一次性的，因为随着新需求和版本的改进，新版本会不断地发布。问题：如何在最终发布之前确定需求？
考虑软件需求的版本化控制，当要进行新版本的迭代时，在工作开始前就确定好本次需求的范围如果需求出现变更，应当根据市场策略，已公布的发布时间，客户需求，实现代价，难易程度以及对现有工作的影响，对需求进行适度划分，严格定义当前版本需要实现的功能，其他部分作为未来版本的需求。
遵循一个原则：对于一个版本的需求变更，必须要早发现、早讨论、早决定、早调整。
