3. 功能测试用例怎么设计才完整

很多同学写测试用例只会抄需求，或者照着页面元素一个个写。

这种用例设计方式既浪费时间，又容易漏测。真正好的用例设计要有思路、有方法、有覆盖。

一、先梳理测试范围

写用例前要先确认：

• 需求是否完整；
• 业务流程是否清晰；
• 业务规则是否明确；
• 权限和角色是否定义；
• 异常场景是否补充；
• 测试环境是否具备。

如果需求不清楚，不要直接写用例，先和产品确认。

二、用例设计要有层次

好的用例设计通常分三层：

• 主流程用例：覆盖核心业务链路；
• 分支流程用例：覆盖次要功能和分支场景；
• 异常流程用例：覆盖错误、边界、异常情况。

比如订单功能，主流程用例包括：

• 正常下单支付；
• 正常发货收货；
• 正常完成订单。

分支流程用例包括：

• 取消订单；
• 申请退款；
• 订单超时关闭。

异常流程用例包括：

• 库存不足下单；
• 优惠券失效；
• 支付失败；
• 重复提交；
• 网络中断。

层次清晰，用例才不乱。

三、每个功能点要覆盖完整场景

对一个功能点，通常要覆盖：

• 正常场景；
• 边界场景；
• 异常场景；
• 权限场景；
• 数据验证。

比如新增用户功能：

• 正常：填写完整信息保存成功；
• 边界：必填项为空、超长输入、格式错误；
• 异常：重复手机号、网络超时、接口失败；
• 权限：无权限用户不能新增；
• 数据：用户表新增记录、角色关联正确、密码加密存储。

每个功能点按这个思路展开，用例才完整。

四、边界值不能只测 0 和最大值

边界值测试要结合业务规则。

比如商品库存字段：

• 是否允许负数；
• 是否允许小数；
• 库存为 0 时是否可上架；
• 库存为 0 时是否可下单；
• 最大库存限制；
• 库存扣减是否正确；
• 库存恢复是否正确。

边界不是简单的数值边界，而是业务边界。

五、异常场景要主动补充

需求文档通常写正常流程多，异常流程少。

测试要主动补充异常场景：

• 数据为空；
• 数据超长；
• 特殊字符；
• 格式错误；
• 重复数据；
• 并发操作；
• 网络异常；
• 接口失败；
• 权限不足；
• 状态不允许；
• 第三方服务异常。

比如提交订单时要补充：

• 库存不足；
• 商品下架；
• 优惠券失效；
• 用户被禁用；
• 地址不完整；
• 网络中断；
• 重复点击提交。

异常场景往往比正常场景更容易出 Bug。

六、权限和角色要单独设计用例

权限测试不要只看菜单是否隐藏。

要覆盖：

• 菜单权限；
• 按钮权限；
• 数据权限；
• 接口权限。

比如普通用户：

• 不能看到管理员菜单；
• 不能点击管理员按钮；
• 不能查看其他用户数据；
• 不能调用管理员接口。

权限只做前端隐藏是不安全的，必须后端也校验。

七、数据验证要结合接口和数据库

功能测试如果只看页面，很容易漏掉数据问题。

要补充：

• 接口请求参数是否正确；
• 接口响应结果是否正确；
• 数据库字段是否正确更新；
• 关联表数据是否同步；
• 状态字段是否正确变化；
• 金额、数量是否一致。

比如支付成功后要验证：

• 订单表状态；
• 支付流水表；
• 库存表数量；
• 优惠券状态；
• 用户积分。

八、用例要可执行可追溯

好的用例要包含：

• 用例标题；
• 前置条件；
• 测试步骤；
• 测试数据；
• 预期结果；
• 实际结果；
• Bug 关联。

用例标题要简洁明确，比如：

• 订单支付成功后订单状态变为已支付；
• 库存不足时下单失败提示库存不足；
• 无权限用户点击删除按钮提示无权限。

不要写模糊的标题，比如"测试订单功能"。

九、面试回答模板

可以这样回答：

设计用例时我会先梳理测试范围，确认需求、流程、规则、权限和异常场景是否清晰。用例设计上按主流程、分支流程、异常流程三层展开；每个功能点覆盖正常、边界、异常、权限和数据验证；边界值结合业务规则，比如库存字段不只测数值边界，还测库存为 0 时能否下单、上架。异常场景主动补充，包括数据为空、超长、格式错误、并发、网络异常、接口失败等。权限用例验证菜单、按钮、数据和接口四层；数据验证结合接口和数据库确认状态、金额、流水是否一致。

这个回答能体现你有系统化的用例设计思路。

十、下一步建议

建议你挑选一个熟悉的功能，按上面思路重新设计一遍用例：

• 列出主流程、分支流程、异常流程；
• 对每个功能点展开正常、边界、异常、权限、数据；
• 补充接口和数据库验证点。