从买菜App说起
前两天我妈下载了个买菜App，点完“立即下单”后页面卡住，反复扣了三次款。她气得直拍桌子：这玩意儿怎么不测好再上线？其实，类似的问题本该在开发阶段就被发现，而关键就是——测试用例设计流程。
第一步：搞清楚要测啥
不是一上来就写用例，得先看需求文档。比如这个下单功能，需求里写着‘用户点击下单后，系统应冻结库存、生成订单、跳转支付页’。那测试重点就明确了：库存减没减？订单有没有？能不能重复提交？
第二步：拆场景，像拼图一样
别只盯着正常流程。设想各种可能的情况：网络突然断了怎么办？地址没填全能提交吗？优惠券过期了还用得上吗？把这些当成一个个小场景列出来，每个都对应一个或多个测试点。
第三步：选方法，别瞎猜
常用的方法有几种。等价类划分——比如年龄输入框，允许18-60岁，那就取个中间值35（有效），再取17和61（无效）来试；边界值分析——重点测18和60这两个边；还有因果图，适合多个条件组合的情况，像‘满100减10，且仅限新用户’这种。
第四步：动手写用例，别太啰嗦
一条清晰的用例长这样：
用例编号：TC_ORDER_001
用例标题：验证未登录用户点击下单时是否跳转登录页
前置条件：用户未登录，已选中商品
操作步骤：
1. 进入商品详情页
2. 点击“立即下单”
预期结果：
页面跳转至登录界面第五步：拉人一起过一遍
写完别急着交。找开发、产品经理一块看看，有时候你以为是bug，其实是需求本来就这样设计的。比如我妈遇到的重复扣款，后来发现是前端没做按钮防抖——这个点之前没人提，评审时才暴露出来。
第六步：执行时灵活调整
实际测试时会发现新问题。比如原本没考虑弱网环境，但测试中发现加载超时后数据状态混乱，就得补一条用例专门覆盖这种情况。用例不是写完就锁死的，它得跟着项目走。
日常中的启发
其实这流程不只是程序员用。你装家具看说明书，也会下意识检查零件齐不齐、步骤顺不顺——这本质上也是在做“测试”。只不过测试用例设计，是把这种检查变得更系统、更不容易漏掉关键细节。