从一个登录功能说起
前几天帮朋友公司看一个登录页面的问题，他们总说“测试都做了，怎么上线还有bug”？点进去一看，测试用例清一色都是“输入正确账号密码，点击登录，检查是否跳转”。这确实是一种情况，但现实中的用户可不会这么配合。
比如有人会忘记密码、连续输错5次、账号格式写错、密码包含特殊字符、甚至直接点浏览器后退。这些情况有没有覆盖到？测试用例不是写给开发看的流程图，而是用来发现潜在问题的探测器。
明确测试目标，别一上来就列步骤
很多人拿到需求就开始写“第一步、第二步”，其实该先问一句：我们要测什么？是功能逻辑、数据处理、还是异常容错？比如注册功能，核心目标可能是“确保手机号唯一性”，那测试用例就应该围绕这个展开，而不是只盯着界面按钮。
可以先把关键路径列出来：正常注册成功、重复手机号、空手机号、格式错误等。每个路径对应一组输入和预期结果。
用等价类划分减少冗余
比如年龄输入框要求18-60岁，你不可能把18到60每一个数都试一遍。这时候可以把输入分成三类：小于18、18-60之间、大于60。每类选一个代表值就够了。这样既节省时间，又能保证覆盖。
边界值不能漏
接着上面的例子，除了取中间值，还得看看边界上有没有问题。比如输入17、18、60、61这几个数字，系统提示是不是合理？很多bug就藏在这些交界处。就像水杯装水，快满的时候最容易洒出来。
别忘了异常和操作失误
用户网络突然断了怎么办？点了两次提交会不会重复创建？页面刷新后数据还在不在？这些非正常流程往往比主流程更容易出事。建议专门建一个“异常场景”分类，把可能出岔子的地方列出来逐个击破。
加点真实感，模拟用户习惯
有些人喜欢用粘贴复制填表单，有的习惯按回车提交，有的会在中途切换账号。可以在测试用例里加入这类细节。比如“复制带空格的邮箱地址，粘贴到输入框，检查是否自动去除前后空格”。
举个简单的例子
假设要测试一个计算器的加法功能：
测试用例1：正常整数相加
输入：a=5, b=3
预期结果：显示8
测试用例2：负数参与运算
输入：a=-2, b=4
预期结果：显示2
测试用例3：边界情况（最大值）
输入：a=999999, b=1
预期结果：正确显示1000000 或 提示溢出
测试用例4：非法输入
输入：a=abc, b=123
预期结果：提示“请输入有效数字”这样的用例既有常规操作，也有意外情况，比单纯写“点击加号看结果”有用得多。
定期回头看看老用例
项目做久了，有些老功能没人动，但测试用例可能已经跟不上变化了。比如原来只能上传jpg，现在支持png了，但用例还写着“上传非jpg文件应失败”，这就成了误导。隔段时间翻一遍，删掉过时的，补上新的。
设计测试用例不是一次性任务，更像是种菜——得经常浇水、除草、看长势。写得好，能提前揪出问题；写得敷衍，那就只是应付检查的纸面功夫。