我们先来思考力下：
-
如何一步一步制定测试计划
-
如何进行需求分析
-
如何进行测试策略、工期和资源安排
迭代测试常见的问题
建立测试计划步骤概述：
- 测试目标：是质量第一 还是快速上线
- 质量目标：是由 测试目标而来
- 进行需求分析【测试的基石】：
- 测试的优先级
- 测试的重点
- 测试难点
- 测试关键路径......
- 测试策略（测试的颗粒度、测试的原则 ）
- 整体的测试策略
- 阶段的测试策略
- 制定测试计划
- 资源的安排
- 风险的识别处理......
迭代测试-高效计划实战
质量目标----------->测试目标
- 产品商业价值 -->质量第一
- 找到该产品最核心的产品是在做什么
- 针对的客户来到我们这里最主要是要做什么
- 给产品带来最大收益的是什么
- 项目铁三角 --> 快速上线
- 线上事故率 --> 线上无P0 和 P1级事故
需求分析：
——从上往下、从左往右，看到的所有按钮全部记录下来
第一步：关联分析
——从实际操作流程，我们把已经梳理出来的测试点来进行归纳调整下---> 具有操作相关联的放到一起
-
快速熟悉：将所有可以看到的功能点展现到思维导图或是其他文档里面
-
目标分解，由大到小 -->大、小 类的关联性分析（优先级的划分）
-
通过思维导图进行需求分析
-
用连接线把有关联的流程全部串起来 --> 生成Excel
小类分析：
-
优先级的划分【除了产品给到的优先级，我们也要有自己的优先级】
-
识别测试重点【关键功能】
-
识别强关联功能
-
识别弱关联功能
第二步：测试策略
——整体测试策略
- 业务和技术的深度掌握
- 业务：深挖用户使用场景，了解每一个细节和逻辑
- 技术：业务相关的接口、数据表结构等，了解的越深，测试时思路越多，测试方法更有效，测试效果也会更高
- 多样式测试：从业务场景、交互、UI、兼容性、数据逻辑、业务逻辑、性能测试等多个角度去测试，Bug产生效率会更高，质量也会更稳定，而不是仅仅功能测试。
- 组内组外充分沟通
- 敏捷研发更强调沟通、强调人与人的作用
- 在快速迭代下，很多信息都处于冰山下面，只有不断的交流和沟通，才能被挖掘出来
——版本测试策略
-
详细设计的脚本验证
-
测试要点的探索式测试
-
交叉抽测和回归测试
-
P1功能点 特别重要，应充分的考虑用户的使用场景，覆盖功能的各种细节，以及各种异常
- 在详细测试完了第一轮之后，在对P1进行探索性测试
- P2，进行一次用例的详细设计后，验证即可。不需要采取探索式的测试
- P3，针对测试要点的编写，直接进行 探索式测试 即可
- P4，可以不编写测试要点，直接根据 需求文档 验证即可
Ps: 如果业务的商业价格十分巨大，在小的功能也是重点；如果没有商业价值，在重要的功能也其实没有那么重要（比如是内部的OA系统）。
第三步：制定计划
- 工期的评定：对每一个功能点进行工期的评定
- 开始评定是需考虑到：【关联度】、【重要程度】
- 测试点分配：相关联同一个人来做
评估的工期是不是合理：评定完了后，再次进行评审下：
——发现如果分配的时间来看不合理，想到我们的版本测试策略，比较重要的模块可以使用 交叉测试的思路，可以允许部分任务的交叉，调整为工期分配平均一些
-
进度安排：
测试的顺序，根据测试点的优先级进行排序展开
-
里程碑进度安排
——Excel 看起来的时间安排并不是一目了然，需要进行调整，然后再把【回归测试】加入
测试开始时间是否如我们所愿-->开发提测的影响-->参考开发计划-->通过开发提测的时间-->确定下测试开始时间
在制定测试计划时，一定要知道开发计划，需要计划也要知道，这样才利于测试整体的工作的安排。
-
风险处理：根据【风险的历史库】 【预先识别的风险】-->制定【风险策略】
-
研发流程 ：根据【开发计划】制定之外，也要根据【研发流程】来制定；如：需要进行冒烟测试
——如对产品要求非常高，对产品要求非常细致，还需要制定【集成测试计划】、【单元测试计划】等等。