老张在家给小区物业写了个报修小工具，自己测了两遍觉得没问题，结果邻居王姐一用，点‘提交’就卡死——原来漏测了没填手机号的场景。后来他翻出以前公司用的测试用例评审标准，一条条对，补了5个边界情况，再上线，稳了。
什么叫测试用例评审标准？
不是高大上的流程文档，就是一份‘ checklist ’：你写的每条测试步骤，有没有人能看懂？能不能真跑通？会不会漏掉用户实际会干的事？比如：输入11位手机号、输入10位、输入字母、直接空着不填……这些都得列清楚。
居家开发常用的4条硬标准
1. 可执行性：
每条用例必须有明确操作+预期结果。别写‘检查功能正常’，要写‘在‘报修类型’选‘漏水’，点击提交，页面弹出‘已受理，30分钟内响应’提示’。
2. 覆盖真实场景：
想想你家人的操作习惯。我妈总爱连点3次‘确认’，我爸喜欢把验证码粘贴到用户名框里——这些‘手滑型’用例比‘完美流程’还重要。
3. 独立不依赖：
第7条用例不能要求先跑完第1–6条。每条都该像单机游戏存档，随时打开就能试。不然换台电脑或隔两天再测，光搭环境就得半小时。
4. 有据可查：
每条后面最好备注依据。比如‘验证密码长度≥8位（依据：登录页下方小字说明）’。以后自己回看，或者发给朋友帮忙测，一眼知道为啥这么写。
一个真实的小例子
这是老张改后的‘提交报修’用例片段：
用例ID：BR-03
标题：未填写联系电话时提交报修
前置条件：已登录，进入报修表单页
操作步骤：1. 不填‘联系电话’；2. 填写其他必填项；3. 点击‘提交’
预期结果：页面停留在当前页，联系电话输入框下方显示红色提示‘请输入11位手机号’
依据：物业通知中明确要求‘所有报修需留有效联系方式’比起最初那句‘测试提交功能’，现在谁都能照着跑，连上初中的儿子试了两次就找出JS校验没生效的问题。
在家写工具、搭NAS、做自动化脚本，别跳过这一步。测试用例不是给领导看的纸面功夫，是你给自己留的退路——哪天半夜被业主群@说‘又崩了’，翻出评审过的用例，3分钟定位，比重装系统快多了。