总结、探寻我所理解的测试策略，输出可执行的文案，只为回首往事时不因虚度年华而悔恨，不因碌碌无为而羞耻。
参考：软件需求分析方法
软件需求分析是一个项目的开端，也是项目实施最重要的关键点，一个项目的成功软件需求分析是关键的一步。
我所理解的需求分析流程可以如下：
一、识别测试需求
理想的测试需求获取路径当然是需求文档(需求规格说明书)，但是实际很多时候需求文档并不一定是最完整且时时的(理论上应该是最完整且时时的)，所以作为测试人员一方面要求完整且时时的需求文档，另一方面要多渠道获取需求的相关信息，丰富自己对需求的了解，如下图所示：
二、分析测试需求：
1 依据识别的测试需求，通读需求文档和设计，重点关注以下问题：
（1）.需求文档和设计是否是用户真实意图的体现？
（2）.需求文档和设计中是否有模棱两可和有歧义的地方？
（3）.及时反馈问题，在测试用例设计前理清需求事实和可能的问题，并得到明确的结果。
2 依据需求文档和设计图画业务流程图。目标是通过流程图的绘制，对整个业务的处理逻辑及其细节有非常清楚的认知，为后续编写测试用例设计做准备。
（1）.流程图要画，在这个过程中一方面是对需求逻辑的理解，另一方面也督促自己与开发确认逻辑(或者用例评审时辅助使用)；
（2）.流程图尽可能细化，每个业务判断逻辑都要应该有各种情况的处理逻辑；
（3）.各种输入条件之间的关联关系、输出数据之间的关联关系标注清楚；
（4）.梳理逻辑的过程也是在测试需求在逻辑上有无漏洞和考虑欠佳的地方，为后续测试打基础。
3 需求对于其他类型有无要求，如果有，需要明确并在需求测试总结中标注，在用例设计阶段需要设计对应的用例，举例如下：
（1）.是否对性能提出了明确的要求？
（2）.是否对运行环境、操作习惯提出了明确要求？
（3）.是否对安全性方面提出了明确的要求？
三、提取测试对象
提取的前提是对需求本质明确，需求文档和设计已无阶段性问题，在次基础上可以制作需求测试结果表。
总结：输出了需求测试结果表，预示着对需求已无阶段性的疑问，对需要要测试的方向已经明确；对具体的方向要测试的种类已经清晰，后续就是依据该表和业务逻辑设计对应的类别测试用例。
备注：该表格不是一成不变的，随便测试用例设计的推荐和需求的变更，需要持续更新该表，当一段时间过后再去回归该需求，此表可以提供明确的需求说明(较之需求文档和设计更清晰)
