敏捷用例平台实现在线高效化用例评审

语言: CN / TW / HK

《目录章节》

一、用例评审流程是怎么样的

1、相对规范用例评审流程

【测试用例准备】

【评审准备流程】

【相对比较正式的用例评审会议纪要】

2、常见的用例评审流程(现状)

【评审通知和会议】

【用例评审会议纪要】

【现状存在的问题】

1、缺少统一化管理

2、隐藏未知的风险

3、影响用例质量和测试质量

二、敏捷用例平台结合用例评审的功能设计

1、框架流程设计**

2、用例评审功能&评审过程

3、功能实现

三、在线化用例评审的总结


图片

一、用例评审流程是怎么样的

1、相对规范用例评审流程

【测试用例准备】

为更好地进行测试用例评审,测试用例可能会做如下梳理

  • 功能测试用例
  • 冒烟测试用例(功能测试用例中的高优先级用例)
  • 单模块内的高优先级用例
  • 涉及上下游系统的核心流程用例,即联调测试用例
  • ……

【评审准备流程】

  • 提前预订会议室,邮件邀请项目关键干系人,包括但不限于产品,研发等
  • 测试用例作为邮件附件,以便参会人员提前熟悉
  • 会议中记录问题,确定跟进人及完成时间
  • 评审结束后输出评审会会议纪要
  • 1个工作日内根据会议纪要修改完善测试用例
  • 测试用例导入测试用例管理工具
  • ……

【相对比较正式的用例评审会议纪要】 群发消息通知(邮件或者即时聊天工具等等)

时间:2022年xx月xx日

人员:xxx,xxx,xxx……

xxxxxx需求的用例评审,会议纪要如下: 

一.用例评审模块:

    1. 邮箱账号登录功能
    2. 登录流程优化
    3. 样式调整

二.已同步问题点如下:

    1. xxxx
    2. xxxxx
    3. xxxx
    4. xxxxx

三.用例相关说明如下:

用例相关说明如下:

用例共150条

功能用例:150,占比100%

冒烟用例:75条,占比50%
    回归用例:30条,占比20%
    ……

四. 附件是整理后的用例,请相关人员查阅,如果有疑问,请及时沟通

以上讨论点,测试侧用例已更新,见附件~

2、常见的用例评审流程(现状)

在敏捷迭代的工作中,为了提高效率,往往比较繁琐的用例评审流程都被简化了

【评审通知和会议】

  • 可能是这样的,直接通知所有人在什么时间段进行评审,缺少提前预览用例和备注问题

图片

  • 也可能是这样的,先评审一部分,等补充完另一部分,后续再重新安排评审

图片

图片

【用例评审会议纪要】

  • 先建立在线文档,跟项目迭代统一在线化文档管理,如果用例评审过程未及时把评审记录保存到在线文档中去,在线文档一直是空白的,等过段时间再来找找之前的用例评审记录时,可能评审记录内容已经遗失了

图片

  • 在线文档中,简单记录过程存在的问题和缺少case

图片

  • 或者在在线文档中,记录评审过程相关需求疑问点和解决思路,以及需要补充哪些case

图片

  • 甚至有可能一些评审会议的待办事项,是记录在本地文本工具、word文档、excel、或者手写本子上……

图片

【现状存在的问题】

1、缺少统一化管理

随着项目的快速迭代,之前用例评审时哪些人参加、提到过什么问题、记录在哪里都有可能被忘记。这些内容缺少统一的在线化管理标准,将评审相关数据进行关联及保存

2、隐藏未知的风险

项目的快速迭代中,编写测试用例可能成为质量保障非必须准入条件,存在不需要编写测试用例,凭借个人经验直接进行测试;已写好的测试用例不需要经过评审,在程序功能刚开发完就直接进测等情况

虽然过程质量没什么问题,但是缺少有力的数据验证保障,可能存在覆盖不全,导致线上bug的情况,在程序维护上增加了未知的风险。

图片

3、影响用例质量和测试质量

用例评审在整个研发流程的生命周期中,它不是非必须的交付产物,但是却可能是测试人员写好测试用例关键的检查过程:需求功能点的用例是否覆盖全面、异常场景用例是否完善、接口用例是否补充、核心场景是否有冒烟用例……;放大影响面来评估,会直接影响整个软件过程的测试质量,存在业务场景的测试覆盖不全、缺少异常场景验证测试、核心场景验证测试不全……出现漏测少测等情况,导致出现线下、线上bug。

图片

看到以上现状问题的影响,你还会觉得用例评审不重要吗?

图片

二、敏捷用例平台结合用例评审的功能设计

1、框架流程设计

图片

2、用例评审功能&评审过程

  1. 用例评审入口:
  2. 用例页面,点击用例评审按钮,展开用例评审页面和相关操作

  3. 根据用例是否关联计划和评审状态展示对应按钮

  4. a. 用例页面,增加评审模式开关,默认关闭,
  5. 图片

  6. 开启则打开用例评审页面,

  7. 图片
  8. b. 如果创建评审计划时开启签到,进入评审模式时,会自动弹窗提示扫码签到,默认是关闭状态
  9. c. 未评审,高亮显示 【开始评审】
  10. d. 评审中,高亮显示【结束评审】
  11. e. 评审中,编辑评审结论(保存/取消)

  12. f. 评审完成,弹窗确认“通过/不通过”,支持编辑评审时长和评审结论;在评审页面上方提示:评审任务已完成,可以 创建 第 X 次评审(支持创建多次评审记录)

  13. g. 用例已评审,重新打开评审模式开关,可以查看相关评审记录信息

3、功能实现

图片

1. 创建评审计划

当用例未有评审计划,开启评审模式时,第一次会弹窗填写预计评审时间和填写推送相关参与评审人员,支持开启和关闭参会人员签到

图片

评审计划创建成功,自动推送企业微信通知到相关人员

图片

2. 开始评审

进入评审页面,第一次未开始评审,右上角会高亮显示“开始评审”,点击签到支持弹窗让参会人员用手机扫码签到

图片

图片

图片

3. 评审中和结束评审

点击“开始评审”,可以在评审结论位置填写评审相关备注信息,支持多次修改,自动生成实际开始时间;点击“开始评审”之后,右上角会切换为“结束评审”按钮

图片

填写完评审结论并“保存”生效,点击“结束评审”时,会弹窗提醒本次评审“通过/不通过”,默认生成评审时长,支持修改具体评审时长;自动带入评审结论,支持修改评审结论备注

图片

图片

4. 重新进行用例评审

当次评审结束,需要再次进行评审,点击“创建”,弹窗输入预计评审时间和是否开启签到,功能类似第一次创建评审计划,创建成功即可重新进行用例评审

图片

5. 查看评审记录

当进行已有多次评审记录时,在用例页面打开“评审”,进入评审模式,可以查看多轮次的评审记录,显示多次评审时长和总时长等等

用例评审支持的场景:

  • 当用例存在多人编写不同业务模块时,可以拆分用例模块分开进行评审,生成指定轮次的评审计划
  • 当用例评审不通过而结束评审后,再次发起评审,重新生成下一轮次的评审计划
  • 当用例评审之后,有新增需求补充的测试用例,支持再次发起下一轮次的评审计划

图片

6. 评审结束推送通知

评审结束,自动推送评审结论,以及实际评审时间和时长

图片

三、在线化用例评审的总结

1、增加写用例过程快速进行评审,并记录每次评审存在的问题和补充

2、支持边评审,边修改用例,让会议纪要不再成为“纪要”,而是“即该就要”

3、用例平台化管理,查看历史用例,也能快速查到评审记录

4、让每次评审的价值最大化,让每次投入的时间都能被重视

图片


作者简介

庄锦弟  一个喜欢撸码的后端测开

汪彬      一个喜欢研究的前端测开

转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。

关注公众号「转转技术」(综合性)、「大转转FE」(专注于FE)、「转转QA」(专注于QA),更多干货实践,欢迎交流分享~