技术摘要：异常行为：它们的测试频率如何？

问题陈述

异常（Exceptions）是编程中一种基础的构建块，用于处理预期会发生但不频繁发生的错误情况，从而允许开发者避免使用过多的 if/else 检查来使代码变得臃肿。虽然现有的研究和最佳实践表明，高质量的测试套件应该同时覆盖正常行为和异常行为，以防止回归并捕捉 Bug，但经验证据表明，开发者主要测试的是正常（“快乐路径”）行为。

当前文献中存在一个关键空白：先前的研究几乎完全集中在异常测试上——即那些显式断言异常会传播到测试层级的测试（例如使用 assertRaises）。这些研究并未考虑到那些在运行时被抛出但在到达测试程序之前就被代码内部（通过 try/except 块）捕获并处理的异常。因此，目前尚不清楚在现实世界的系统中，异常行为实际上被测试套件执行的频率如何，包括那些不会传播到测试框架中的异常。此外，从测试的角度来看，异常在运行时抛出的频率——是从罕见发生到异常成为常态的行为——尚未得到深入探讨。

研究方法

作者通过分析 25 个真实世界 Python 系统的测试套件进行了实证研究。该数据集包括了一系列流行的第三方库（如 Flask、Requests、Pylint）和标准库模块（如 email、pathlib、argparse），涵盖了 5,372 个已执行的方法、1,790 万次方法调用以及 140 万次抛出的异常。

该研究采用了以下方法论：

1. 插桩（Instrumentation）： 作者利用基于 Python sys.settrace 函数的动态分析工具 SpotFlow 对测试套件进行插桩，以在方法层面监控执行情况。
2. 数据收集： 在测试执行期间，插桩后的系统记录了：
   • 哪些方法被执行了。
   • 特定方法是否在运行时抛出了异常。
   • 每个方法的总调用次数。
   • 导致异常的调用次数（异常抛出调用）。
3. 分析： 收集到的数据被用于回答三个针对不同粒度的研究问题（RQ）：
   • RQ1（方法级）： 有多少方法在运行时抛出异常？
   • RQ2（调用级）： 在抛出异常的方法中，实际导致异常的调用频率是多少？
   • RQ3（系统级）： 异常抛出的方法和调用在不同系统之间是如何变化的？

关键结果

RQ1：异常抛出方法的普遍性

• 21.4% 的已执行方法（5,372 个中的 1,150 个）在测试执行期间至少抛出了一个异常。
• 剩余的 78.6% 是无异常的。
• 异常抛出方法被发现比无异常方法更复杂且被更频繁地执行。在中位数上，异常抛出方法接收到的调用次数是无异常方法的 4 倍，执行的路径是无异常方法的 3 倍。
• 研究识别出了 200 种不同的异常类型。大多数是通用的（如 ValueError、TypeError），而特定异常通常由单个方法抛出。

RQ2：异常抛出的频率

• 在会抛出异常的方法中，异常抛出调用的中位频率为 10%（10 次调用中发生 1 次）。
• 异常抛出频率的分布呈现高度偏态：
  • 罕见（≤10%）： 50% 的异常抛出方法属于此类。
  • 偶尔（>10% 至 ≤50%）： 28.4% 的方法。
  • 常见（>50% 至 <90%）： 9.6% 的方法。
  • 几乎总是（≥90%）： 11.8% 的方法。
• 观察结论： 接近 80% 的抛出异常的方法其发生频率较低。然而，有相当一部分少数派（约 20%）频繁地抛出异常，并且在某些情况下（例如特定的 Pylint 方法），抛出异常是其“预期”或“正常”的行为（在 100% 的调用中发生）。

RQ3：系统间的差异

• 25 个系统中的 22 个包含比异常抛出方法更多的无异常方法。
• 25 个系统中的 19 个每个方法的异常抛出调用中位数比例低于 30%。
• 系统之间存在显著差异；例如，csv 库有 53.3% 的异常抛出方法，而 Error Corrector 仅有 5.6%。

意义与启示

本文认为，由于忽略了在本地处理的异常，当前对异常行为测试的理解是不完整的。研究结果挑战了“异常抛出总是‘异常’或罕见事件”的假设。

作者针对研究人员和从业者提出了三个主要启示：

1. 开发新型测试工具：
   由于大多数异常抛出方法执行频率较低（通常 <10% 的调用），现有的测试套件可能会留下大量的错误处理代码未被测试。作者建议开发能够识别覆盖异常情况测试的工具，包括那些异常在本地被捕获且不会传播到测试层级的场景。此类工具可以提醒开发者错误处理逻辑中缺失的覆盖率。

2. 重新评估“异常”行为：
   本研究强调，异常抛出并不一定意味着“异常”。对于某些方法（例如属于“几乎总是”类别的方法），抛出异常是标准控制流的一部分。从事异常行为测试的研究人员必须区分哪些方法中的异常代表 Bug/边缘情况，以及哪些方法中的异常是预期的结果。未能做出这种区分可能会导致对测试质量或 Bug 检测能力的错误评估。

3. 重构高开销的 try/except 块：
   作者指出，在 Python 中，EAFP（“请求宽恕比请求许可更容易”）的编码风格经常导致 try/except 块的使用。虽然在异常罕见时效率很高，但捕获异常的计算开销很大。研究识别出的那些频繁抛出异常的方法（例如在 90% 以上的调用中出现 KeyError 或 AttributeError）是进行重构的强力候选对象。将这些替换为显式检查（例如 if key in dict）可以显著提高性能。

结论

这项实证研究提供了对现实世界 Python 系统中异常行为被测试频率的首次全面观察，同时兼顾了传播型异常和本地处理型异常。结果表明，虽然大多数异常抛出方法执行频率较低，但代码库中有相当一部分依赖于异常作为一种频繁的控制机制。作者得出结论，需要更好的工具来支持这些行为的测试，并且可以通过重构那些异常抛出过于频繁的代码模式来实现性能优化。