前言
测试的流程基本上大同小异，本文将常见的测试流程做一下梳理，通过梳理总结测试流程，期望对之后的测试及测试管理工作有一个清晰的脉络，更好的做好测试工作
需求评审
- 参与人员
- 产品
- 开发
- 测试
- 业务方，也就是提需求的人，一般是与客户接触的前线同事
- 其他相关人员，项目经理
- 主要内容
- 对需求文档进行评审，对于有疑问或者错误的地方，进行讨论沟通，来保证产研测三方对需求理解的准确性和一致性
- 需求文档尽可能详细，一般要求要有业务流程图、需求要实现的原型图初稿，能够较好的帮助相关人员快速的了解业务需求
- 达成目标
- 确定需求范围
- 了解到各个模块对应的开发人员或开发负责人
- 作为确定测试时间的输入
需求分析
- 主要内容
- 需求评审通过后，测试从已定版的需求 和 产品原型图 提取测试项和测试点
- 根据测试点结合不同测试场景，大致确定测试用例的数量，依据测试用例数量和任务排期的长短确定测试方案
- 测试方案
- 达成目标
- 其他
- 测试时间来不及写用例，一定要详细列出测试点并找产品开发评审
- 避免无序测试，测试执行时，思路混乱，漏测主要功能
测试计划
- 主要内容
- 测试计划
- 测试范围
- 测试目标
- 测试出入口
- 通过标准
- 测试人力安排（角色及职责）
- 测试进度安排
- 用例设计开始结束时间
- 用例评审开始结束时间
- 用例执行开始结束时间
- 回归测试开始结束时间
- 测试交付时间
- 测试交付物
- 测试风险
- 达成目标
用例设计
- 主要内容
- 按照需求分析 提取的测试点， 按照测试方案 制定好的测试策略编写测试用例
- 测试用例的编写可以参考：用例设计-颗粒度
- 用例编写完成，组织用例评审，查漏补缺，避免遗漏重要测试场景
- 测试用例
- 用例编号
- 用例名称
- 前置条件
- 测试数据
- 优先级
- 操作步骤
- 预期结果
- 实际结果
- 编写人
- 用例设计思路
一般是按照ISO-9126质量模型来考虑测试类型，在实际的测试工作，考虑如下测试类型即可
- UI测试
- 权限测试
- 功能测试
- 数据测试
- 流程测试（含异常流程）
- 接口测试
- 兼容性测试
- 性能测试
- 安全测试
- 用例设计方法
- 使用最多的等价类和边界值
- 其次就是场景法
- 正交试验法、因果图
- 达成目标
冒烟测试
- 开发提前后，正式测试前，先验证一下主流程或主要实现功能是否存在问题
- 没有阻断性问题后再进行系统的测试，避免测试相关工作已经准备开展，而遇到阻断类型缺陷，无法正常执行下去
测试执行
- 冒烟测试结束后，按照测试计划开展测试
- 可以采取交叉测试的方法，提高测试执行质量
- 执行过程中遇到不可控因素或问题，影响测试计划落地，尽快报风险
测试日报
- 主要内容
- 包含内容
用例总数、执行用例数、未通过数、发现Bug数量、关闭Bug数量、遗留Bug数量、问题等级、影响程度、Bug趋势以及其他建议，发动给相关的产品、开发、测试或需求人员。
- 日报模板
今日状态概要
1、进度是否正常
2、有无阻断性问题
整体 低风险 中风险 高风险
提测时间： xxxx-xx-xx
用例执行情况：
| xx-xx | xx-xx | xx-xx | xx-xx | xx-xx |
|---|
| 总用例数 | | | | | | | 已执行用例数 | | | | | | | 进度（%） | | | | | | | 风险 | | | | | |
Bug情况：
Bug概览：
Bug详情：
| xx-xx | xx-xx | xx-xx | xx-xx | xx-xx |
|---|
| 当日新增 | | | | | | | 待修复 | | | | | | | 修复中 | | | | | | | 测试中 | | | | | | | 已完成 | | | | | |
重要缺陷说明：
测试报告
- 在整个需求或版本测试完成后总结
- 主要反映测试过程中的问题以及对应版本的质量情况，是否满足发布标准、遗留的问题的情况、是否影响相关的使用、特殊的注意事项等。
|