好的测试用例有哪些特点：能直接定位缺陷根因

上周迭代商户退款模块，连着两天被开发吐槽用例没用，蹲在工位翻完三天写的二十七条用例，才彻底捋明白好的测试用例有哪些特点，不是套模板凑字段，是贴合代码实际运行链路。

之前写用例全照着公司模板填，前置条件、输入、预期结果、优先级挨个补齐，字段填满就默认合格。那次退款需求，模板里写了“输入负数退款金额，校验拦截”，看起来完全合规。线上灰度当天直接爆出问题：用户输入-0.00，系统没有拦截，直接发起了空退款流水。翻回用例才看见，只写了负整数、负两位小数，压根漏掉了负零这个边界值。开发事后直白说，这种全覆盖模板化用例，看着规整，实际跑起来百分百漏测。

很多人都忽略隐性前置条件。

这是最容易翻车的细节。

同批次退款用例里，还有一条跨门店退款的用例。当时只标注前置条件：商户开启跨门店权限。跑功能测试时全部通过，等到联调第三方支付，全部失败。折腾两个小时才搞明白，支付侧还有隐性限制：跨门店退款必须要求订单支付时长不超过90天，产品原型里一句话带过，没写进需求文档。之前所有用例都默认只要开权限就能退款，完全没绑定时间前置条件。事后复盘统计，本次迭代80%的用例失效，都是隐性前置条件缺失导致，不是参数覆盖不全。

组里新来的测试习惯写模糊预期结果，这点对比下来差距特别明显。他写的用例预期永远是“系统提示错误，拒绝操作”，每次回归都要来回找产品确认文案。我同期修改的同场景用例，直接粘贴前端弹窗原文：“退款金额不能小于0.01元，请重新输入”，同时标注弹窗展示位置为页面顶部红色浮窗。两轮回归下来，他平均每条用例耗时多出40秒，反复沟通还容易出现主观判定偏差。其实清晰可核验，意思就是不需要测试者主观判断，机器或者任意同事接手，都能一秒判定通过还是失败。

还有个极易混淆的点：用例必须独立解耦，不能依赖执行顺序。

早期为了节省编写时间，习惯性复用前置操作。比如先执行订单全额退款，再执行订单部分退款，把全额退款完成作为部分退款的前置。单独跑部分退款用例永远失败，每次回归都要固定顺序执行。上周版本紧急灰度，测试机器重置了缓存，所有用例打乱自动执行，批量报错。排查后发现二十多条用例存在顺序依赖。后续整改的时候，直接给每条用例补齐独立前置：部分退款前置条件固定为【订单状态已支付、未发起任意退款、订单剩余余额充足】，剥离所有外部执行依赖。

午休的时候随手删掉了三条冗余用例。三条用例分别测试网络超时、页面卡顿、接口重试，最终预期都是退款失败、资金原路退回。底层调用的是同一个熔断接口，触发逻辑完全一致。之前为了凑覆盖率重复编写，白白占用回归工时。合格的用例不会做无效同质化覆盖，只区分底层逻辑，不区分表层操作场景。

下班关灯的时候，盯着屏幕里精简后的退款用例列表发呆。之前一直追求用例数量、模板完整度，浪费了大半工时。

桌上水杯反光晃了眼，抬手关掉了显示器。