🇺🇸

Original

English

🇨🇳

Translation

Chinese

Edge Cases

边缘情况文档

An edge cases document systematically catalogs the unusual, boundary, and error scenarios for a feature. While happy-path flows are typically well-specified, edge cases often get discovered in production . causing bugs, poor user experience, and support burden. Documenting edge cases upfront ensures engineering handles them intentionally and QA knows what to test.

边缘情况文档会系统地记录某个功能的异常场景、边界场景和错误场景。通常，常规流程（happy-path flows）的规格说明都很完善，但边缘情况往往在生产环境中才被发现，进而导致漏洞、糟糕的用户体验和支持负担。提前记录边缘情况可以确保开发团队有针对性地处理这些问题，同时让QA团队明确测试重点。

When to Use

适用场景

During feature specification before engineering begins
When preparing QA test plans
After discovering production bugs to prevent similar issues
When reviewing PRDs or user stories for completeness
Before launch to ensure error states have been designed

开发开始前的功能规格制定阶段
准备QA测试计划时
发现生产环境漏洞后，用于预防类似问题
审查PRD或用户故事（user stories）的完整性时
上线前，确保错误状态已完成设计

Instructions

操作步骤

When asked to document edge cases, follow these steps:

Define the Feature Scope Clearly describe what feature or flow you're analyzing. Edge cases are specific to context . the same input might be valid in one feature and invalid in another.
Walk Through Input Validation Consider every user input: What if it's empty? Too long? Wrong format? Contains special characters? What are the minimum and maximum valid values?
Explore Boundary Conditions Find the edges of acceptable ranges. If a field accepts 1-100, test 0, 1, 100, and 101. Consider pagination boundaries, timeout thresholds, and rate limits.
Map Error States Identify what can go wrong: network failures, permission denied, resource not found, concurrent modifications, expired sessions. Document both the scenario and expected behavior.
Consider Concurrency Issues What if two users act simultaneously? What if the user double-clicks? What if data changes between load and save? Race conditions often cause subtle bugs.
Define Recovery Paths For each error, specify how users recover. What message do they see? Can they retry? Is data preserved? Good error handling turns frustration into confidence.
Prioritize by Likelihood and Impact Not all edge cases need the same attention. High-likelihood + high-impact cases need robust handling; rare + low-impact cases might just need graceful failure.

当需要记录边缘情况时，请遵循以下步骤：

定义功能范围 清晰描述你正在分析的功能或流程。边缘情况具有特定的上下文——同一输入在某个功能中可能有效，在另一个功能中则可能无效。
梳理输入验证逻辑 考虑所有用户输入：如果输入为空怎么办？过长怎么办？格式错误怎么办？包含特殊字符怎么办？有效值的最小和最大值是多少？
探索边界条件 找出可接受范围的边界值。如果某个字段接受1-100的数值，那么要测试0、1、100和101。还要考虑分页边界、超时阈值和速率限制。
梳理错误状态 识别可能出现的问题：网络故障、权限不足、资源未找到、并发修改、会话过期。同时记录场景和预期行为。
考虑并发问题 如果两个用户同时操作会发生什么？如果用户双击会怎样？如果在加载和保存之间数据发生变化会如何？竞争条件（race conditions）往往会导致难以察觉的漏洞。
定义恢复路径 针对每个错误，明确用户如何恢复。他们会看到什么提示信息？能否重试？数据是否会被保留？良好的错误处理可以将用户的挫败感转化为信任感。
按可能性和影响程度排序 并非所有边缘情况都需要同等关注。高可能性+高影响的情况需要可靠的处理方案；低可能性+低影响的情况只需确保能优雅地失败即可。

Output Format

输出格式

Use the template in

references/TEMPLATE.md

to structure the output.

使用

references/TEMPLATE.md

中的模板来组织输出内容。

Quality Checklist

质量检查清单

Before finalizing, verify:

All user inputs have validation edge cases documented
Boundary conditions are explicitly listed
Network/system failure scenarios are covered
Each error state has a defined user-facing message
Recovery paths are specified (not just error detection)
Edge cases are prioritized by likelihood and impact

最终定稿前，请验证以下内容：

所有用户输入的验证边缘情况均已记录
边界条件已明确列出
网络/系统故障场景已覆盖
每个错误状态都定义了面向用户的提示信息
已指定恢复路径（而非仅检测错误）
边缘情况已按可能性和影响程度排序

See

references/EXAMPLE.md

for a completed example.

请查看

references/EXAMPLE.md

获取完整示例。

deliver-edge-cases