上周上线一个登录页，前端加了个新校验：手机号末尾不能是连续三个相同数字。测试同学照着文档跑了一遍，说「通过」。结果上线两小时，客服收到17条反馈——用户输13888888888直接卡死在提交按钮上。后来发现，测试用例里压根没覆盖「全重复数字」这种边界值。
测试用例不是填空题，是场景翻译
很多人把写测试用例当成抄需求文档：「输入手机号 → 点击登录 → 检查提示语」。这没错，但漏了最关键的一步：把文字需求，翻译成真实用户可能干的事。比如「支持手机号登录」，真实场景可能是：
- 输11位纯数字（正常）
- 输10位、12位（少一位/多一位）
- 输带空格或短横线的 138-1234-5678（粘贴进来的脏数据）
- 输 13800138000（移动靓号，但后六位全是0）
这些不是“刁难”，是用户每天都在干的事。
网络应用里，三类测试用例最容易漏
1. 网络抖动下的行为
测试环境永远网速满格，但用户可能在地铁里刷网页。一个「提交成功」的用例，得补上：
- 断网状态下点击提交 → 显示「网络不可用，请重试」
- 提交中途断网 → 按钮变灰+倒计时重试，而不是一直转圈
2. 第三方服务异常
登录页调了短信平台接口，测试用例不能只测「发成功」。得模拟：
<!-- 接口返回 503 Service Unavailable -->
<div class="alert error">短信通道繁忙，请稍后再试</div>3. 浏览器兼容性不是截图对比
光在 Chrome 里点一遍「通过」不够。比如 Safari 对 input[type="number"] 的处理会自动过滤掉开头的 0，用户输 00123456789，实际拿到的是 123456789 —— 这个逻辑偏差，必须写成独立用例。
一个小技巧：用「用户动词」代替「系统动作」
别写「验证手机号格式校验」，改成：
- 用户输入「138」后马上点登录 → 应提示「手机号未填完整」
- 用户粘贴「138 1234 5678」→ 自动过滤空格并校验通过
- 用户长按输入框选择「全部替换」为「abcde」→ 提示「请输入11位数字」
动词越具体，用例越防漏。毕竟代码不会骗人，但人写的用例，得先骗过自己。