高效测试计划

标签：size   阶段   功能   nbsp   使用场景   部分   研发   比较   快速   

我们先来思考力下：

• 如何一步一步制定测试计划

• 如何进行需求分析

• 如何进行测试策略、工期和资源安排

迭代测试常见的问题

 建立测试计划步骤概述：

• 测试目标：是质量第一 还是快速上线
• 质量目标：是由 测试目标而来 
• 进行需求分析【测试的基石】：

1. 测试的优先级
2. 测试的重点
3. 测试难点
4. 测试关键路径......

• 测试策略（测试的颗粒度、测试的原则 ）

1. 整体的测试策略
2. 阶段的测试策略

• 制定测试计划

1. 资源的安排
2. 风险的识别处理......

迭代测试-高效计划实战

质量目标----------->测试目标

• 产品商业价值 -->质量第一

1. 找到该产品最核心的产品是在做什么
2. 针对的客户来到我们这里最主要是要做什么
3. 给产品带来最大收益的是什么

• 项目铁三角 --> 快速上线

• 线上事故率 --> 线上无P0 和 P1级事故

需求分析：

——从上往下、从左往右，看到的所有按钮全部记录下来

第一步：关联分析 

——从实际操作流程，我们把已经梳理出来的测试点来进行归纳调整下---> 具有操作相关联的放到一起

• 快速熟悉：将所有可以看到的功能点展现到思维导图或是其他文档里面

• 目标分解，由大到小 -->大、小 类的关联性分析（优先级的划分）

• 通过思维导图进行需求分析

• 用连接线把有关联的流程全部串起来 --> 生成Excel

小类分析：

1. 优先级的划分【除了产品给到的优先级，我们也要有自己的优先级】

2. 识别测试重点【关键功能】

3. 识别强关联功能

4. 识别弱关联功能

第二步：测试策略

——整体测试策略

• 业务和技术的深度掌握

1. 业务：深挖用户使用场景，了解每一个细节和逻辑
2. 技术：业务相关的接口、数据表结构等，了解的越深，测试时思路越多，测试方法更有效，测试效果也会更高

• 多样式测试：从业务场景、交互、UI、兼容性、数据逻辑、业务逻辑、性能测试等多个角度去测试，Bug产生效率会更高，质量也会更稳定，而不是仅仅功能测试。

• 组内组外充分沟通

1. 敏捷研发更强调沟通、强调人与人的作用
2. 在快速迭代下，很多信息都处于冰山下面，只有不断的交流和沟通，才能被挖掘出来

——版本测试策略

• 详细设计的脚本验证

• 测试要点的探索式测试

• 交叉抽测和回归测试

• P1功能点 特别重要，应充分的考虑用户的使用场景，覆盖功能的各种细节，以及各种异常

• 在详细测试完了第一轮之后，在对P1进行探索性测试

• P2，进行一次用例的详细设计后，验证即可。不需要采取探索式的测试
• P3，针对测试要点的编写，直接进行 探索式测试 即可
• P4，可以不编写测试要点，直接根据 需求文档 验证即可

Ps: 如果业务的商业价格十分巨大，在小的功能也是重点；如果没有商业价值，在重要的功能也其实没有那么重要（比如是内部的OA系统）。

第三步：制定计划

• 工期的评定：对每一个功能点进行工期的评定
• 开始评定是需考虑到：【关联度】、【重要程度】
• 测试点分配：相关联同一个人来做

评估的工期是不是合理：评定完了后，再次进行评审下：

——发现如果分配的时间来看不合理，想到我们的版本测试策略，比较重要的模块可以使用 交叉测试的思路，可以允许部分任务的交叉，调整为工期分配平均一些

• 进度安排：

测试的顺序，根据测试点的优先级进行排序展开

•  里程碑进度安排

——Excel 看起来的时间安排并不是一目了然，需要进行调整，然后再把【回归测试】加入

 测试开始时间是否如我们所愿-->开发提测的影响-->参考开发计划-->通过开发提测的时间-->确定下测试开始时间

在制定测试计划时，一定要知道开发计划，需要计划也要知道，这样才利于测试整体的工作的安排。

•  风险处理：根据【风险的历史库】 【预先识别的风险】-->制定【风险策略】

•  研发流程 ：根据【开发计划】制定之外，也要根据【研发流程】来制定；如：需要进行冒烟测试

——如对产品要求非常高，对产品要求非常细致，还需要制定【集成测试计划】、【单元测试计划】等等。

高效测试计划

标签：size   阶段   功能   nbsp   使用场景   部分   研发   比较   快速   

原文地址：https://www.cnblogs.com/brf-test/p/14382299.html