边缘案例

边缘案例（edge case）是指其中一个运作参数是在极值（最大值或最小值）下的状态，系统可能会有些特殊的情形。例如，喇叭运作在最大音量下，就算其他设定没有变化，也可能会有明显的音质扭曲。

有些边缘案例可能会被忽略。在工程学中，若要针对边缘案例进行规划，并且作优雅的处理，这类工作的工作量很大，常常会被忽略或是低估。

以下是一些常见边缘案例的原因^[1]：

• 未预期的使用者行为
• 使用者行为随时间而出现了变化
• 测试覆盖率不足
• 产品本身的复杂度（例如分散式系统或微服务架构）
• 资源不足（例如处理器能力不足、主存储器不足或是电脑记忆体不足）
• 其他极端情形

以下是一些简单边缘案例的例子：

• 应用程序中的过长用户名造成应用程序缓冲区溢位，显示异常
• 订位系统在闰年的2月29日时无法正常运作。

一些不明显的边缘案例可能会造成其系统的失效。可能是在设计阶段没有预先考量到，也没有想到在正常使用时可能会有此情形。因此，若要建立好的工程标准，需要包括相关的边缘案例。

软件工程

程式设计里的边缘案例会和算法中需特别处理的输入值有关。若要确认程式在这些情形下的行为，需要建立单元测试：一般会测试算法、子程序、和方法在这些邉界条件下的行为。会针对这些边界建立许多的边缘案例，以达成足够的代码覆盖率，其中的假设是程式若在这些极端情形下可以正常运作，在其他条件下应该也可以正常运作^[2]。

例如，有一个将二个数字相除的函式，在测试时需包括这二个数字为很大数字和很小数字的案例，若程式在这些极端条件下可以运作，在中间条件下也可以运作^[3]。

程式设计者也会建立集成测试，处理一些单元测试没有考虑到的边缘案例^[4]。这些测试包括一些整体系统才会出现的案例。单元测试要确保函式可以有正确的输出，而整合测试要确保系统和数据库或外部应用程序接口整合时可以有正常输出。系统使用分布式计算、微服务或物联网都会增加其复杂度，这些系统下的整合测试也就格外重要。特别是微服务，整合测试可能无法覆盖所有微服务的端口，因此会有没有覆盖到的边缘案例，这也带来测试上的挑战^[5]。

其他和边缘案例有关的测试有负载测试（英语：load testing）和负面测试（英语：Negative testing），这些测试的目的在扩展系统的覆盖率，减少没有考虑到边缘案例的比率。

在测试驱动开发的模式中，边缘案例可以用由系统需求来确认，并且可以对应测试，这些都是在撰写程式之前就可以进行的。团队在和持份者和其成员讨论后，即可产出这些文件，放在产品需求文档中。

相关条目

• 边角案例，多个测试条件都在极值（最大或最小值）的测试案例。
• 验识工程（英语：Forensic engineering）
• 模糊测试
• 随机测试（英语：Random testing）
• 快乐路径（英语：Happy path）