4、测试用例评审：评审流程、评审标准、如何有效参与评审

测试用例写完了，是不是直接扔给开发去跑？

千万别。我见过太多团队，用例写了一大堆，结果评审会上被开发一句话怼回来：「这场景根本不存在啊。」——白忙活一场。

测试用例评审，说白了就是让各方帮你「找茬」。你一个人想破头也想不到的边界情况，别人一眼就能看出来。今天我就聊聊评审这件事，怎么走流程、用什么标准、以及——怎么让自己在评审会上不尴尬。

4.1 评审流程：别跳过，也别走形式

我习惯把评审分成三步走。少了哪一步，效果都会打折扣。

4.1.1 预审阶段（自己先过一遍）

别急着拉群开会。先自己把用例跑一遍逻辑。我自己的做法是：

• 检查每个用例的「前置条件」是否写清楚
• 确认「预期结果」是可验证的，不是模糊描述
• 把重复的、冗余的用例删掉

嗯，这一步其实最容易被忽略。但你想，如果自己都没理清楚，开会时被问住，那多尴尬。

4.1.2 正式评审（控制在1小时内）

拉上产品经理、开发、测试同事。我建议用「走查」的方式，而不是逐条念用例。怎么走查？

• 按业务场景分组，一次讲一个场景
• 讲「我要测什么、为什么这么测」
• 让大家提问题，而不是单纯确认

我曾经遇到过一个项目，评审会开了3小时，最后大家全在刷手机。后来我改成「每人提前看用例，会上只讨论争议点」，效率高了很多。

4.1.3 评审后跟进（最容易烂尾的一步）

评审会上提出的修改意见，一定要落实到人。我习惯用表格跟踪：

问题描述	提出人	责任人	状态
登录用例缺少「密码错误5次锁定」场景	张三（开发）	李四（测试）	已修改
支付用例的「超时」时间与实际业务不符	王五（产品）	李四（测试）	待确认

说白了，评审不是开完会就结束了。没人跟进，等于白评。

4.2 评审标准：拿什么来衡量用例好坏

我见过不少新人写的用例，看着挺多，但一评审就发现全是「无效用例」。那什么样的用例才算好？我总结了四个标准：

4.2.1 完整性

功能路径是否覆盖全了？异常场景有没有漏掉？

举个例子：测「用户注册」，你写了「手机号正确注册成功」，但「手机号已注册」「手机号格式错误」「验证码过期」这些场景呢？缺一个，上线就可能出问题。

4.2.2 可执行性

别人拿着你的用例，能不能直接跑？

我见过最离谱的用例，预期结果写的是「系统应该正常处理」。什么叫正常处理？是弹窗提示？还是跳转页面？——这种用例，评审时直接打回重写。

4.2.3 独立性

用例之间不要有依赖。A用例失败了，B用例还能不能跑？

我踩过这个坑。有一次用例A是「创建订单」，用例B是「取消订单」。结果A失败了，B也跟着全红。后来我把它们拆成独立的，每个用例自己造数据、自己清理数据。

4.2.4 可维护性

业务变了，你的用例改起来方便吗？

我建议用例里不要写死具体的ID、时间戳。用变量代替。比如：

# 不好的写法
点击按钮("id_12345")

# 好的写法
点击按钮(订单提交按钮的ID)

4.3 如何有效参与评审：别当「听众」

很多人参加评审会，就是坐在那里听别人讲。其实这样收获很小。我分享几个实用技巧：

4.3.1 提前看用例，带着问题来

我习惯在评审会前一天，把用例发到群里。让大家先看，有问题提前标注。会上直接讨论争议点，而不是从头到尾读一遍。

你想想看，如果大家都没提前看，会上才开始读，那效率得多低？

4.3.2 从「用户视角」提问

开发关注技术实现，产品关注业务逻辑。但测试要关注「用户会怎么用」。

我曾经在评审一个「退款」功能时，开发说「退款金额不能超过订单金额」。我反问了一句：「如果用户用了优惠券呢？实际支付金额小于订单金额，按哪个退？」——这个问题，就是用户视角。

4.3.3 学会说「不」

评审时，可能会有人提出「这个场景不用测，概率太低了」。我的经验是：

• 如果概率低但影响大（比如支付失败导致资金损失），必须测
• 如果概率低且影响小（比如某个按钮颜色显示异常），可以暂缓

说白了，测试资源有限，要学会取舍。但取舍的标准要讲清楚，不能一句「不用测」就带过。

4.4 知识体系：一张图看懂评审

下面这张图，是我自己总结的评审知识体系。你可以把它贴在工位上，每次评审前扫一眼：

好了，关于评审就聊这么多。记住一句话：评审不是走过场，而是帮你发现盲区。下次评审时，试着用我上面说的技巧，你会发现——原来别人眼中的「理所当然」，可能正是你漏掉的关键点。