测试流程优化
适用于创业型及规模不是很大的公司，一般用于敏捷开发
需求分析
- 需求预览
- 关于下一阶段的需求会在群里贴出，需要提前消化，疑惑点先行列出，并且告知测试内部评审时间。
- 评审需求
- 测试内部需求评审，提出疑惑点，领取需求
- 需求文档维护
- 每一阶段都有一位成员补充该阶段需求到需求文档，以便追溯（一般小作坊是没有规范的需求文档的，有时候需要测试自己去维护）
- 测试点提取
- 各人领取对应需求后，分析该需求的测试点
测试用例
- 测试用例
- 不需要写具体的操作步骤，着重写测试点，分基本流和备选流
- 对应需求测试用例由最终负责人编写
- 注意测试用例的格式的统一
- 交叉补充，保证测试点的全面性
范例：
前置条件中加入涉及的需求编号；
用例类型默认为功能测试；
试用阶段默认为系统测试阶段；
用例标题：
【7.9.0】工行支持充值、提现等能力验证
步骤 预期
1、工行充值能力验证 基本流：
1、输入金额等正常信息充值成功，有返回信息
2、*****
备选流：
1、充值过程中，金额不足
2、充值过程中，网络中断
3、控件输入特殊符号容错
4、*****
2、工行提现能力验证 *******
- 冒烟测试用例
- 主要用来给开发自测，将本版本所有用例的基本流列入即可。
- 每一阶段都有一位成员提供冒烟测试用例
- 注意标题格式：【V_7.9.0客户端冒烟用例】
- 完成后链接发给对应客户端负责人
- 封板用例
- 每一阶段都有一位成员补充新增功能到最终封板用例中
冒烟测试
- 提测阶段
- 开发完成开发后，会发送提测邮件，相关需求领取人走下冒烟测试用例，并反馈是否通过
- 如中途有新增需求或更改需求，需开发、测试再次合理估期，可二次追加提测邮件，以保证质量的可控。
- 冒烟测试邮件反馈
- 拿到提测包后，一小时内给出需求冒烟测试结果反馈
- 综合测试结果给与邮件反馈，通过则进入系统测试；不通过则打回。
系统测试
- 测试周期
- 交叉测试
- 第一轮系统测试由领取需求的人执行
- 最后一轮系统测试由需求负责人执行
| 需求编号 | 用例（负责人） | 第一轮（领取人） | 第二轮（测试环境） | 第三轮（正式环境） | 第四轮（负责人） |
|---|---|---|---|---|---|
| 1293-工行充提能力验证 | A | B | C | D | A |
| *** | *** | *** | *** | *** | *** |
- bug规范
范例：
下图中根据禅道已经给出详细说明
- 验收测试
- 即根据封板用例测试一下所有功能的主流程，确保所有模块不出大的问题
- 一般是在新增需求已经完全结束测试的情况下进行
- 性能测试-启动/流量/响应
- 即应用冷启动/热启动的时间（不同版本/竞品的对比）
- 变更大的时候考虑不同版本间耗流量的对比
- 变更大的时候考虑不同版本间响应时间的对比
- Monkey测试-提取crash
- 基本流程走通后进行
- 一般是下班后进行，具体操作可参见https://www.jianjiexuan.com/tools/android-sdk/293.html
- 每一位小伙伴都需要执行，提取crash交由开发修改
备注：
这些只是我结合实际调整的方式，力求在最短的时间内，充分利用人力资源保证质量，每个人可以结合公司实际找出最适合的那种方式，测试本身就要灵活点，不能按部就班、死板。