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