《目录章节》
一、用例评审流程是怎么样的
1、相对规范用例评审流程
【测试用例准备】
【评审准备流程】
【相对比较正式的用例评审会议纪要】
2、常见的用例评审流程（现状）
【评审通知和会议】
【用例评审会议纪要】
【现状存在的问题】
*1、缺少统一化管理
*
*2、隐藏未知的风险
*
*3、影响用例质量和测试质量
*
二、敏捷用例平台结合用例评审的功能设计
1、框架流程设计
2、用例评审功能&评审过程
3、功能实现
三、在线化用例评审的总结
一、用例评审流程是怎么样的
1、相对规范用例评审流程
【测试用例准备】
为更好地进行测试用例评审，测试用例可能会做如下梳理
- 功能测试用例
- 冒烟测试用例（功能测试用例中的高优先级用例）
- 单模块内的高优先级用例
- 涉及上下游系统的核心流程用例，即联调测试用例
- ……
【评审准备流程】
- 提前预订会议室，邮件邀请项目关键干系人，包括但不限于产品，研发等
- 测试用例作为邮件附件，以便参会人员提前熟悉
- 会议中记录问题，确定跟进人及完成时间
- 评审结束后输出评审会会议纪要
- 1个工作日内根据会议纪要修改完善测试用例
- 测试用例导入测试用例管理工具
- ……
【相对比较正式的用例评审会议纪要】 群发消息通知（邮件或者即时聊天工具等等）
时间：2022年xx月xx日
人员：xxx，xxx，xxx……
xxxxxx需求的用例评审，会议纪要如下：
一.用例评审模块：
- 邮箱账号登录功能
- 登录流程优化
- 样式调整
二.已同步问题点如下：
- xxxx
- xxxxx
- xxxx
- xxxxx
三.用例相关说明如下：
用例相关说明如下：
用例共150条
功能用例：150，占比100%
冒烟用例：75条，占比50%
回归用例：30条，占比20%
……四. 附件是整理后的用例，请相关人员查阅，如果有疑问，请及时沟通
以上讨论点，测试侧用例已更新，见附件~
2、常见的用例评审流程（现状）
在敏捷迭代的工作中，为了提高效率，往往比较繁琐的用例评审流程都被简化了
【评审通知和会议】
- 可能是这样的，直接通知所有人在什么时间段进行评审，缺少提前预览用例和备注问题
- 也可能是这样的，先评审一部分，等补充完另一部分，后续再重新安排评审
【用例评审会议纪要】
- 先建立在线文档，跟项目迭代统一在线化文档管理，如果用例评审过程未及时把评审记录保存到在线文档中去，在线文档一直是空白的，等过段时间再来找找之前的用例评审记录时，可能评审记录内容已经遗失了
- 在线文档中，简单记录过程存在的问题和缺少case
- 或者在在线文档中，记录评审过程相关需求疑问点和解决思路，以及需要补充哪些case
- 甚至有可能一些评审会议的待办事项，是记录在本地文本工具、word文档、excel、或者手写本子上……
【现状存在的问题】
1、缺少统一化管理
随着项目的快速迭代，之前用例评审时哪些人参加、提到过什么问题、记录在哪里都有可能被忘记。这些内容缺少统一的在线化管理标准，将评审相关数据进行关联及保存
2、隐藏未知的风险
项目的快速迭代中，编写测试用例可能成为质量保障非必须准入条件，存在不需要编写测试用例，凭借个人经验直接进行测试；已写好的测试用例不需要经过评审，在程序功能刚开发完就直接进测等情况
虽然过程质量没什么问题，但是缺少有力的数据验证保障，可能存在覆盖不全，导致线上bug的情况，在程序维护上增加了未知的风险。
3、影响用例质量和测试质量
用例评审在整个研发流程的生命周期中，它不是非必须的交付产物，但是却可能是测试人员写好测试用例关键的检查过程：需求功能点的用例是否覆盖全面、异常场景用例是否完善、接口用例是否补充、核心场景是否有冒烟用例……；放大影响面来评估，会直接影响整个软件过程的测试质量，存在业务场景的测试覆盖不全、缺少异常场景验证测试、核心场景验证测试不全……出现漏测少测等情况，导致出现线下、线上bug。
看到以上现状问题的影响，你还会觉得用例评审不重要吗？
二、敏捷用例平台结合用例评审的功能设计
1、框架流程设计
2、用例评审功能&评审过程
-
用例评审入口：
-
用例页面，点击用例评审按钮，展开用例评审页面和相关操作
-
根据用例是否关联计划和评审状态展示对应按钮
-
a. 用例页面，增加评审模式开关，默认关闭，
-
-
开启则打开用例评审页面，
-
-
b. 如果创建评审计划时开启签到，进入评审模式时，会自动弹窗提示扫码签到，默认是关闭状态
-
c. 未评审，高亮显示 【开始评审】
-
d. 评审中，高亮显示【结束评审】
-
e. 评审中，编辑评审结论（保存/取消）
-
f. 评审完成，弹窗确认“通过/不通过”，支持编辑评审时长和评审结论；在评审页面上方提示：评审任务已完成，可以 创建 第 X 次评审（支持创建多次评审记录）
-
g. 用例已评审，重新打开评审模式开关，可以查看相关评审记录信息
3、功能实现
1. 创建评审计划
当用例未有评审计划，开启评审模式时，第一次会弹窗填写预计评审时间和填写推送相关参与评审人员，支持开启和关闭参会人员签到
评审计划创建成功，自动推送企业微信通知到相关人员
2. 开始评审
进入评审页面，第一次未开始评审，右上角会高亮显示“开始评审”，点击签到支持弹窗让参会人员用手机扫码签到
3. 评审中和结束评审
点击“开始评审”，可以在评审结论位置填写评审相关备注信息，支持多次修改，自动生成实际开始时间；点击“开始评审”之后，右上角会切换为“结束评审”按钮
填写完评审结论并“保存”生效，点击“结束评审”时，会弹窗提醒本次评审“通过/不通过”，默认生成评审时长，支持修改具体评审时长；自动带入评审结论，支持修改评审结论备注
4. 重新进行用例评审
当次评审结束，需要再次进行评审，点击“创建”，弹窗输入预计评审时间和是否开启签到，功能类似第一次创建评审计划，创建成功即可重新进行用例评审
5. 查看评审记录
当进行已有多次评审记录时，在用例页面打开“评审”，进入评审模式，可以查看多轮次的评审记录，显示多次评审时长和总时长等等
用例评审支持的场景：
- 当用例存在多人编写不同业务模块时，可以拆分用例模块分开进行评审，生成指定轮次的评审计划
- 当用例评审不通过而结束评审后，再次发起评审，重新生成下一轮次的评审计划
- 当用例评审之后，有新增需求补充的测试用例，支持再次发起下一轮次的评审计划
6. 评审结束推送通知
评审结束，自动推送评审结论，以及实际评审时间和时长
三、在线化用例评审的总结
1、增加写用例过程快速进行评审，并记录每次评审存在的问题和补充
2、支持边评审，边修改用例，让会议纪要不再成为“纪要”，而是“即该就要”
3、用例平台化管理，查看历史用例，也能快速查到评审记录
4、让每次评审的价值最大化，让每次投入的时间都能被重视
作者简介
庄锦弟 一个喜欢撸码的后端测开
汪彬 一个喜欢研究的前端测开
转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~
