一、用例评审流程是怎么样的
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。
看到以上现状问题的影响，你还会觉得用例评审不重要吗？
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
