第一步：信息收集
对于前面几章介绍的阶段所做的事情进行汇总和整合
项目信息
项目周期：项目计划上允许你测试的时间长度
使用流程：产品对外交付流程或者使用流程
历史情况：产品的历史质量情况，包括内部bug发现与外部bug反馈等等
项目的干系人：策划、开发、合作团队
目标用户：哪些用户使用你的产品
使用情景：在什么情况下使用
环境：在什么设备或者硬件环境下使用
最终需要交付的内容：例如产品包以及配套的管理后台
示例（一款考试工具）
项目周期：一个月后需要发布 ==》预估需要或者允许安排多少个轮次往返，是否存在发布进度风险
使用流程：现在用户电脑上搭建软件环境后，再复制资源包进去考试。 ==》尽量贴近用户场景模拟测试
历史情况：内部bug平均每个版本300个以上。已知外部bug达到100个。==》下方测试需求要求能够达到精品标准（BUG少于10个）可以看出来差距比较大，相应周期可能会比较长
项目的干系人：产品研发团队、销售团队==》这里出现了一些不常合作的团队，需要注意一下和这些上游的合作规则
目标用户：（这里是假设）年轻的学生会使用手机进行相关操作==》基于这个群体我们可以通过友盟等平台分析出这个群体主要使用的机型进行适配参考。
使用情景：断网情况下考试 ==》尽量贴近用户场景模拟测试
环境：使用VR相关外部设备==》尽量贴近用户场景模拟测试，进行设备兼容
最终需要交付的内容：产品包、配套后台、帐号等==》需要清楚知道最终交付，并为之努力
功能验证信息：
1、运行环境的兼容：考虑这个功能在各个平台的兼容差异，提醒策划做出需求方面的制定。
2、版本的向下兼容。功能兼容、数据兼容。
3、版本的向后兼容 评估是否兼容未来的版本。
4、功能完整性
5、功能交叉性
6、需求交叉性 新需求与新需求是否交叉，例如多个案子之间有协作依赖关系。新需求与旧规则是否交叉，例如历史规则在这个版本得到变更。
测试需求信息
1、用户体验 交互是否符合用户操作习惯，是否简单好上手
2、测试预期标准 服务端性能标准，安全标准，需要适配的设备，是否国际化，需要达到的发布标准（精品、良品）
3、开发需求 设计方案在开发实现上的局限
4、前期风险评估 前期暴露出来的未来的测试风险、版本进度风险等等。
5、后期测试注意事项 需要把这个时期获得的一些信息与注意事项向后面的环节传递
开发信息：
在开发设计评审阶段发现的开发可能存在的问题。
上面这些在之前的文章已经举过例子，就不再详细说明了。
第二步：确认测试内容
测试的广度与深度：测试的边界在哪里。具体所有的测试项目
可以从几个维度出发：功能维度、性能维度、安全维度、兼容维度、用户体验维度、设计维度、国际化测试维度、安装卸载
功能维度：
存量验证：新增功能对存量的影响
增量验证：新增功能的正向异常验证
性能纬度、稳定性、压力、安全、兼容：
存量验证：指标是否出现偏移
增量验证：新功能指标如何，是否符合相应规范
用户体验：综合测评
测试的重点、难点：
重点一般是基于用户场景、目标需求进行分析
难点一般基于难以模拟或者难以透彻了解的模块进行分析
第三部分：确认测试策略
和测试流程结合。将已有的这些需要测试的项目分散到测试的各个流程与轮数中去。
MSC阶段需要侧重验收哪些场景与功能 ==》验收发现基本质量和目标质量偏差较大，设计纬度验收
一轮测试需要侧重什么 ==》进行测试模块初步全面覆盖，功能、兼容、国际化、安装卸载纬度 覆盖
二轮测试需要侧重什么 ==》功能趋于稳定，加入安全、性能、稳定性、压力测试等
三轮测试==》安排A-B岗测试人员交叉测试
预计几轮需要结束测试 ==》根据BUG收敛情况评估
第四部分：过程风险
测试内容风险：哪些项目是比较模糊的？哪些项目是由于成本无发覆盖的？
测试策略风险：哪些项目是无法确实保证测试质量的？哪些项目是策略无法覆盖的？（例如交叉测试策略可能带来人员不够熟悉模块带来漏测的风险，需要对应的风险控制手段）
第五部分：风险控制
这个模块另起一个单元来讲。
