做功能测试时，最常被问到的问题不是‘怎么点按钮’，而是‘这功能到底该写几个用例？怎么写才不算漏？’——比如一个简单的用户登录框，输入框、密码框、登录按钮、记住我复选框、忘记密码链接，看着就几样东西，但真动手写用例，有人列了5条，有人写了23条。差别在哪？就在‘设计思路’四个字上。
别一上来就写用例，先问三个问题
拿到一个页面或接口，先别急着打开 Excel。停下来问问自己：
- 用户会怎么用它？（正常路径）
- 用户可能怎么‘搞砸’它？（异常操作）
- 开发可能哪里没防住？（边界和逻辑漏洞）
拿登录页举例：用户正常输对账号密码 → 成功跳转；输错密码 → 提示‘密码错误’；空着两个框点登录 → 提示‘请输入账号’；只输账号不输密码 → 提示‘请输入密码’；账号输100个a → 看前端是否截断、后端是否校验长度；密码框里粘贴含换行符的字符串 → 后端会不会崩？这些都不是拍脑袋想的，是顺着上面三个问题自然推出来的。
常用思路不是套路，是观察角度
等价类划分、边界值分析、场景法……这些名词听起来像教科书，其实只是把日常思考方式写成了方法论：
比如‘手机号登录’，你自然会想：11位纯数字算一类（有效等价类），10位、12位、带字母的、空着、全是0 —— 这些就是无效等价类；再深一层，第1位是1、第2位是3～9（国内号段规则），这就是边界细节。
又比如‘上传头像’，不能只测‘点开选一张jpg图’，还要试：
– 选一个5MB的png（超大小）
– 选一个名字含中文+特殊符号的文件（如“我的头像@2024!.jpg”）
– 连续快速点两次‘上传’按钮（前端有没有防重复提交）
– 上传中途关掉网络（提示是否友好）
代码里藏着最实在的设计线索
翻一翻开发提交的代码片段，比看需求文档还管用。比如登录接口的校验逻辑里有这么一行：
if (password.length < 8 || password.length > 20) { throw new IllegalArgumentException("密码长度必须在8-20位"); }那你的测试用例就明确多了：输7位密码、21位密码、8位、20位、15位——至少这5条得覆盖。再看前端 JS 里有：
username = username.trim().replace(/<script>/g, "");说明它做了基础 XSS 过滤，那你就可以试：
– 输入 <script>alert(1)</script> 看是否被干掉
– 输入 <img src=x onerror=alert(1)> 看是否绕过
– 输入前后带空格的账号，看 trim 是否生效
用例不在多，在‘戳得准’
见过一份电商结算页的测试用例表，光‘优惠券使用’就列了67条。但其中42条都是不同金额组合的穷举，而真正卡住过的bug，是用户领了满300减50券，结算时刚好凑单到299.99元，页面没提示‘未达门槛’，提交订单却失败回滚——这个场景根本没进表。后来加了一条：金额卡在门槛临界点±0.01元时的行为，上线后再没出过同类问题。
所以与其堆数量，不如每次写完几条，反问一句：‘这条要是挂了，用户会骂什么？’如果答案是‘根本发现不了’或者‘早该被开发自测拦住’，那这条大概率可以删掉。