测试用例这东西，测试写起来像做菜。用例菜谱上写“盐少许”，测试新手永远不知道是用例多少克。测试用例写“输入正确的测试用户名密码，登录成功”，用例执行的测试人照样一头雾水——什么叫正确？密码长度有没有限制？要不要大小写？

我见过最糟糕的测试用例，是用例一条Excel记录：“验证登录功能”。就七个字。测试执行人打开系统，用例试了三次，测试没报错，用例就勾了“通过”。测试结果上线当天，用例用户用了个带特殊字符的测试密码，系统直接白屏。那个测试用例写了跟没写一样。

真正能用的测试用例，得具体到能吵架。比如：“在用户名输入框输入‘admin’，密码输入框输入‘Admin@123’，点击登录按钮，预期结果：跳转到首页，右上角显示‘欢迎，admin’。” 每一步都像操作手册，连鼠标点哪儿都写清楚。别嫌啰嗦，执行的人可能是个刚入职的实习生，也可能是个熬夜加班的开发——他们没空猜你的心思。

写用例的顺序也有讲究。别从“正常流程”开始写，先写异常。为什么？因为正常流程谁都会跑，异常路径才是系统翻车的高发区。我通常先列一页纸的“坏人清单”：密码错了怎么办？用户名为空呢？连续提交两次？网络断一下？把这些场景先写出来，用例的基本盘就稳了。

还有个细节容易被忽略——前置条件。比如测“修改密码”，得先确保用户已登录，且旧密码正确。这些前置不写清楚，执行的人跑到一半发现“咦，我没登录啊”，然后自己补一步，测试结果就变味了。前置条件写具体点，能省掉一半的沟通成本。

另外，别把预期结果写成“系统正常”。什么叫正常？是弹出提示框，还是页面刷新？提示框的文字是什么？颜色是红是绿？我见过一个用例，预期结果写“系统给出友好提示”，执行人看到弹窗里写着“Error 500”，愣是勾了通过——他觉得服务器返回了错误信息，也算“提示”。你看，不写清楚就是这种后果。

优先级也得标。P0是核心功能，挂了就不能上线；P1是重要功能，出问题要紧急修；P2是边缘功能，可以慢慢商量。别把“登录”和“记住密码”的优先级混在一起，不然版本发布前，团队会因为“要不要为记住密码延期一天”吵翻。

最后说句实在话，测试用例是写给执行的人看的，不是写给评审专家看的。所以别用那种“验证系统在输入超长字符串时表现符合预期”的鬼话——直接写“输入500个字符，点击提交，预期结果：页面提示‘最多输入200个字符’，且输入框不允许继续输入”。简单，直接，能执行。

写完了自己先跑一遍。你写的时候觉得没问题，真跑起来，可能第一步就卡住了——比如你根本找不到那个登录按钮在哪。这种尴尬，写的人自己发现，比执行的人发现要好受得多。