软件测试流程

前言

测试的流程基本上大同小异，本文将常见的测试流程做一下梳理，通过梳理总结测试流程，期望对之后的测试及测试管理工作有一个清晰的脉络，更好的做好测试工作

需求评审

- 参与人员

• 产品
• 开发
• 测试
• 业务方，也就是提需求的人，一般是与客户接触的前线同事
• 其他相关人员，项目经理

- 主要内容

• 对需求文档进行评审，对于有疑问或者错误的地方，进行讨论沟通，来保证产研测三方对需求理解的准确性和一致性
• 需求文档尽可能详细，一般要求要有业务流程图、需求要实现的原型图初稿，能够较好的帮助相关人员快速的了解业务需求

- 达成目标

• 确定需求范围
• 了解到各个模块对应的开发人员或开发负责人
• 作为确定测试时间的输入

需求分析

- 主要内容

• 需求评审通过后，测试从已定版的需求 和 产品原型图 提取测试项和测试点
• 根据测试点结合不同测试场景，大致确定测试用例的数量，依据测试用例数量和任务排期的长短确定测试方案

- 测试方案

• 测试环境
• 测试数据
• 测试模块
• 测试点
• 测试方法
• 测试风险

- 达成目标

• 输出测试点
• 输出测试方案

- 其他

• 测试时间来不及写用例，一定要详细列出测试点并找产品开发评审
• 避免无序测试，测试执行时，思路混乱，漏测主要功能

测试计划

- 主要内容

• 依据开发计划 制定 测试计划

- 测试计划

• 测试范围
• 测试目标
• 测试出入口
• 通过标准
• 测试人力安排（角色及职责）
• 测试进度安排
  • 用例设计开始结束时间
  • 用例评审开始结束时间
  • 用例执行开始结束时间
  • 回归测试开始结束时间
  • 测试交付时间
• 测试交付物
• 测试风险

- 达成目标

• 输出测试计划

用例设计

- 主要内容

• 按照需求分析 提取的测试点， 按照测试方案 制定好的测试策略编写测试用例
• 测试用例的编写可以参考：用例设计-颗粒度
• 用例编写完成，组织用例评审，查漏补缺，避免遗漏重要测试场景

- 测试用例

• 用例编号
• 用例名称
• 前置条件
• 测试数据
• 优先级
• 操作步骤
• 预期结果
• 实际结果
• 编写人

- 用例设计思路

一般是按照ISO-9126质量模型来考虑测试类型，在实际的测试工作，考虑如下测试类型即可

• UI测试
• 权限测试
• 功能测试
• 数据测试
• 流程测试（含异常流程）
• 接口测试
• 兼容性测试
• 性能测试
• 安全测试

- 用例设计方法

• 使用最多的等价类和边界值
• 其次就是场景法
• 正交试验法、因果图

- 达成目标

• 用例设计完成
• 通过用例评审
• 输出较为完备的测试用例

冒烟测试

• 开发提前后，正式测试前，先验证一下主流程或主要实现功能是否存在问题
• 没有阻断性问题后再进行系统的测试，避免测试相关工作已经准备开展，而遇到阻断类型缺陷，无法正常执行下去

测试执行

• 冒烟测试结束后，按照测试计划开展测试
• 可以采取交叉测试的方法，提高测试执行质量
• 执行过程中遇到不可控因素或问题，影响测试计划落地，尽快报风险

测试日报

- 主要内容

• 根据测试需求的执行情况，发布测试日报

- 包含内容

用例总数、执行用例数、未通过数、发现Bug数量、关闭Bug数量、遗留Bug数量、问题等级、影响程度、Bug趋势以及其他建议，发动给相关的产品、开发、测试或需求人员。

- 日报模板

今日状态概要
1、进度是否正常
2、有无阻断性问题
整体 低风险 中风险 高风险

提测时间： xxxx-xx-xx

用例执行情况：

	xx-xx	xx-xx	xx-xx	xx-xx	xx-xx
总用例数
已执行用例数
进度（%）
风险

Bug情况：
Bug概览：

总数	P0	P1	P2	P3
XX	XX	XX	XX	XX

Bug详情：

	xx-xx	xx-xx	xx-xx	xx-xx	xx-xx
当日新增
待修复
修复中
测试中
已完成

重要缺陷说明：

测试报告

• 在整个需求或版本测试完成后总结
• 主要反映测试过程中的问题以及对应版本的质量情况，是否满足发布标准、遗留的问题的情况、是否影响相关的使用、特殊的注意事项等。