小作坊也可出高质量——测试流程优化

Posted on Posted in TestDoc

测试流程优化

适用于创业型及规模不是很大的公司,一般用于敏捷开发

需求分析

  • 需求预览
    • 关于下一阶段的需求会在群里贴出,需要提前消化,疑惑点先行列出,并且告知测试内部评审时间。
  • 评审需求
    • 测试内部需求评审,提出疑惑点,领取需求
  • 需求文档维护
    • 每一阶段都有一位成员补充该阶段需求到需求文档,以便追溯(一般小作坊是没有规范的需求文档的,有时候需要测试自己去维护)
  • 测试点提取
    • 各人领取对应需求后,分析该需求的测试点

测试用例

  • 测试用例
    • 不需要写具体的操作步骤,着重写测试点,分基本流和备选流
    • 对应需求测试用例由最终负责人编写
    • 注意测试用例的格式的统一
    • 交叉补充,保证测试点的全面性
范例:
前置条件中加入涉及的需求编号;
用例类型默认为功能测试;
试用阶段默认为系统测试阶段;
用例标题:
7.9.0】工行支持充值、提现等能力验证
步骤                                      预期
1、工行充值能力验证                        基本流:
                                          1、输入金额等正常信息充值成功,有返回信息
                                          2*****
                                          备选流:
                                          1、充值过程中,金额不足
                                          2、充值过程中,网络中断
                                          3、控件输入特殊符号容错
                                          4*****
2、工行提现能力验证                        *******

  • 冒烟测试用例
    • 主要用来给开发自测,将本版本所有用例的基本流列入即可。
    • 每一阶段都有一位成员提供冒烟测试用例
    • 注意标题格式:【V_7.9.0客户端冒烟用例】
    • 完成后链接发给对应客户端负责人
  • 封板用例
    • 每一阶段都有一位成员补充新增功能到最终封板用例中

冒烟测试

  • 提测阶段
    • 开发完成开发后,会发送提测邮件,相关需求领取人走下冒烟测试用例,并反馈是否通过
    • 如中途有新增需求或更改需求,需开发、测试再次合理估期,可二次追加提测邮件,以保证质量的可控。
  • 冒烟测试邮件反馈
    • 拿到提测包后,一小时内给出需求冒烟测试结果反馈
    • 综合测试结果给与邮件反馈,通过则进入系统测试;不通过则打回。

系统测试

  • 测试周期

 

  • 交叉测试
    • 第一轮系统测试由领取需求的人执行
    • 最后一轮系统测试由需求负责人执行
需求编号 用例(负责人) 第一轮(领取人) 第二轮(测试环境) 第三轮(正式环境) 第四轮(负责人)
1293-工行充提能力验证 A B C D A
*** *** *** *** *** ***
  • bug规范
范例:
下图中根据禅道已经给出详细说明


  •  验收测试
    • 即根据封板用例测试一下所有功能的主流程,确保所有模块不出大的问题
    • 一般是在新增需求已经完全结束测试的情况下进行
  • 性能测试-启动/流量/响应
    • 即应用冷启动/热启动的时间(不同版本/竞品的对比)
    • 变更大的时候考虑不同版本间耗流量的对比
    • 变更大的时候考虑不同版本间响应时间的对比
  • Monkey测试-提取crash
备注:

这些只是我结合实际调整的方式,力求在最短的时间内,充分利用人力资源保证质量,每个人可以结合公司实际找出最适合的那种方式,测试本身就要灵活点,不能按部就班、死板。

发表评论

电子邮件地址不会被公开。 必填项已用*标注