编码前的边界情况检查清单

快速结论

至少检查空值、重复请求、数量上限、权限差异、并发冲突、外部依赖失败和回滚成本。把这些项写入规格后，很多线上事故会在评审时就消失。

你应该先看什么

• 空值、缺省值和未知值是否有明确策略。
• 重复操作和重试是否保持幂等。
• 并发写入、限流和权限不足时系统如何表现。

可直接复用的示例

边界清单
- Null / Empty / Unknown
- Duplicate / Retry / Reorder
- Permission / Visibility
- Timeout / Partial Failure / Rollback

高风险领域示例

以下示例涵盖三个边界情况代价最高的领域：支付处理、身份认证和文件摄入。在这些场景中，晚发现边界情况的修复成本极高。

# 支付处理边界情况
- amount = 0.00 → 校验错误拒绝，不调用支付网关
- 购物车与银行卡币种不匹配 → 400，不扣款
- 扣款发起后网关超时 → 记录模糊状态，触发对账任务，返回 503 含 retryable 标记
- 10 秒内重复支付请求 → 返回原始收据，不二次扣款

# 身份认证边界情况
- token 过期后 1ms 使用 → 401，非 403
- 有效 token 但账号已停用 → 403 含 account_suspended 错误码
- 同时从 3 个会话登录 → 最早会话失效，新会话签发，审计日志记录全部三个事件
- 重置密码链接首次点击后再次使用 → 410 Gone

# 文件上传边界情况
- 文件大小恰好达到上限（10MB）→ 接受
- 文件大小超过上限 1 字节 → 413 含明确大小提示
- 文件类型伪造（PDF 扩展名但内容为可执行文件）→ 内容检测拒绝，非扩展名检测
- 上传中途中断 → 丢弃不完整文件，不创建记录

支付边界情况到达生产通常导致双重扣款或未对账交易——两者修复成本均高。认证边界情况未文档化会产生不一致的安全行为，在审计前不可见。文件边界情况是内容检测缺失时最常见的安全漏洞来源。

优先级排序：风险 × 可发现性

并非每个边界情况都需要相同程度的规格细节。实用的优先级排序使用两个维度：出错后的后果（风险），以及 QA 或监控在生产中发现它的难易程度（可发现性）。高风险叠加低可发现性，要求在实现前明确写入规格并映射测试用例。

• 高风险 + 低可发现性——编码前必须文档化并测试：支付冲突、并发写入、权限边界失败、数据损坏路径。
• 高风险 + 高可发现性——文档化并添加监控：性能下降、第三方中断、schema 校验失败。
• 低风险 + 低可发现性——文档化为非目标并说明理由：非默认语言的渲染边界情况。
• 低风险 + 高可发现性——记录但不阻塞：有明确用户提示的次要校验错误。

这个优先级排序的输出不是所有可能边界情况的完整列表——那既不可能也适得其反。而是团队在编码前达成共识的优先列表，每项均标明测试责任人和解决时限。

跨系统层的边界情况

边界情况在不同系统层的分布规律各异。一个用户操作可能同时在 API 层、服务层、数据库层和后台任务层暴露各自的边界情况。规格应标明每个边界情况所在的层次，以确保正确的工程师负责对应的测试。

• API 层：请求体格式错误、缺失必要请求头、超大 payload、意外的 Content-Type。
• 服务层：依赖不可用、熔断器状态、重试风暴行为、缓存失效时机。
• 数据库层：唯一约束冲突、删除时外键失败、事务隔离级别影响、迁移回滚对现有数据的冲击。
• 后台任务层：负载高峰下的任务队列积压、确认失败导致的重复执行、毒消息处理、死信队列行为。

任务层的边界情况是最常见的覆盖盲区。由于任务异步运行，其失败对用户在请求时不可见——这正是它们需要明确规格覆盖的原因。一个静默丢弃记录的未文档化任务失败模式，比用户可以重试的同步错误危害更大。

落地建议

拿最近一个上线后出问题的功能做回溯：这份清单里哪几项当时没覆盖？大多数时候答案是空值处理、重试幂等或并发写冲突。找到了就在下一个功能的规格里提前写进去。

如果团队觉得边界情况太多，可以先只记录“高风险且低可发现性”的项。这样不会让规格膨胀，同时能优先覆盖最可能造成生产损失的路径。

评审时也可以给每个边界情况标记处理方式：立即实现、写成非目标、加监控观察，或放入后续版本。没有分类的边界情况很容易在实现中被遗忘。

分类后的清单更容易进入测试计划和发布检查。

它也能防止团队把所有边界情况都当成同等优先级。

相关文章

• 编写 QA 可测试的边界用例
• 可复用的验收标准示例
• 如何编写可测试软件规格