测试流程优化
适用于创业型及规模不是很大的公司,一般用于敏捷开发
需求分析
- 需求预览
- 关于下一阶段的需求会在群里贴出,需要提前消化,疑惑点先行列出,并且告知测试内部评审时间。
- 评审需求
- 测试内部需求评审,提出疑惑点,领取需求
- 需求文档维护
- 每一阶段都有一位成员补充该阶段需求到需求文档,以便追溯(一般小作坊是没有规范的需求文档的,有时候需要测试自己去维护)
- 测试点提取
- 各人领取对应需求后,分析该需求的测试点
测试用例
- 测试用例
- 不需要写具体的操作步骤,着重写测试点,分基本流和备选流
- 对应需求测试用例由最终负责人编写
- 注意测试用例的格式的统一
- 交叉补充,保证测试点的全面性
范例:
前置条件中加入涉及的需求编号;
用例类型默认为功能测试;
试用阶段默认为系统测试阶段;
用例标题:
【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交由开发修改
备注:
这些只是我结合实际调整的方式,力求在最短的时间内,充分利用人力资源保证质量,每个人可以结合公司实际找出最适合的那种方式,测试本身就要灵活点,不能按部就班、死板。