2. 测试用例设计方法如何结合真实业务？
很多人学测试用例设计，只记住了等价类、边界值、判定表、因果图、场景法。
但面试官真正关心的不是你能不能背出这些名字，而是你能不能把方法用到真实业务里。
一、先理解业务，再选择方法
测试用例设计不是先套方法，而是先看业务特点。
不同业务适合不同方法：
- 输入框、金额、数量适合等价类和边界值；
- 多条件组合适合判定表；
- 复杂业务流适合场景法；
- 状态变化适合状态迁移法；
- 历史问题集中区域适合错误推测法。
如果不理解业务，上来就套模板，用例很容易变成形式主义。
二、等价类要结合有效和无效业务数据
等价类不是随便分“正确”和“错误”。
以手机号注册为例，可以分为：
- 有效手机号；
- 少于 11 位；
- 多于 11 位；
- 非数字字符；
- 未注册手机号；
- 已注册手机号；
- 被禁用手机号；
- 境外手机号是否支持。
这里已经不是单纯校验格式，而是结合了账号状态和业务规则。
三、边界值要关注业务边界
边界值不只是最小值、最大值。
比如优惠券满减规则是“满 100 减 20”，测试点应该包括：
- 订单金额 99.99；
- 订单金额 100；
- 订单金额 100.01；
- 多件商品合计满 100；
- 使用积分后是否仍满 100；
- 运费是否计入满减门槛。
真正容易出问题的边界，往往是业务计算边界。
四、判定表适合多条件组合
比如审批功能是否允许提交，可能受多个条件影响：
- 用户角色；
- 单据状态；
- 审批金额；
- 是否超过预算；
- 是否已被别人处理。
如果只凭感觉写用例，很容易漏掉组合。
可以先列条件，再列动作：
- 普通员工 + 草稿状态 + 金额正常：允许提交；
- 普通员工 + 已提交状态：不允许重复提交；
- 审批人 + 待审批状态：允许审批；
- 非审批人 + 待审批状态：不允许审批；
- 审批人 + 已撤回状态：不允许审批。
这样用例更系统。
五、场景法适合主流程和异常流程
业务系统最重要的是流程。
以下单流程为例，主流程是：
- 选择商品；
- 加入购物车；
- 提交订单；
- 使用优惠券；
- 支付成功；
- 生成订单；
- 扣减库存。
异常流程包括：
- 商品下架；
- 库存不足；
- 地址为空；
- 优惠券过期；
- 支付失败；
- 重复提交；
- 支付成功但订单状态未更新。
面试时把主流程和异常流程一起讲，才像真实测试。
六、状态迁移法适合订单、审批、工单类业务
有些业务的核心不是输入，而是状态变化。
比如订单状态可能包括：
- 待支付；
- 已支付；
- 已取消；
- 已发货；
- 已完成；
- 退款中；
- 已退款。
测试时要关注：
- 哪些状态可以流转；
- 哪些状态不能逆向流转；
- 重复操作是否被拦截；
- 状态变更后相关数据是否同步；
- 前端展示、接口返回、数据库状态是否一致。
七、错误推测法来自经验积累
错误推测法不是乱猜，而是根据历史问题判断风险。
常见高风险点包括：
- 重复点击导致重复提交；
- 网络超时导致状态不一致；
- 权限校验只做前端不做后端；
- 金额精度计算错误；
- 缓存未刷新导致数据旧；
- 多人同时操作导致并发问题。
这些点在真实项目里非常常见。
八、面试回答模板
可以这样回答：
我设计测试用例时不会只套方法，而是先分析业务流程和风险点。对于输入类字段，我会用等价类和边界值；对于多条件判断，比如权限和审批规则，我会用判定表；对于下单、支付、审批这类流程，会用场景法覆盖主流程和异常流程；对于订单状态、工单状态，会用状态迁移法；最后结合历史 Bug 做错误推测，补充重复提交、权限绕过、数据一致性等高风险场景。
这个回答能体现你会把理论落到业务里。
九、下一步建议
测试方法不用背得很花，关键是每种方法都能举出真实业务例子。
建议你准备三个场景：
- 登录怎么设计用例；
- 下单怎么设计用例；
- 审批流怎么设计用例。
配套刷题：