‍‍‍《目录章节》

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

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。