有一份桑迪亚技术报告讨论了制造解决方案的方法（PDE 精确解决方案的概念的概括），其中详细讨论了数字代码验证测试的验收标准的概念。他们提出了 4 类：

1. 专家的判断，
2. 百分比误差，
3. 一致性，
4. 准确顺序，

在这里，您目前正在使用与输出数据的回归测试相关的专家判断版本。Bill Greene 的评论包含了百分比误差的概念，在数值计算值和分析值之间的绝对差值方面具有可接受的容差。这种容差值的“好”选择在某种程度上仍然是一个判断调用，并且是离散化、实现和正在使用的计算机体系结构的函数。

仅测试给定系统的单个离散化的值仍然不如收敛测试严格，收敛测试在多个分辨率下运行，并且证实了系统误差的减少与网格长度成比例的方式理论表明它应该（当然，这种实数比较也需要容差）。在 CI 下使用这种方法的最大烦恼是，它可能需要适度的高分辨率才能位于由前序误差项（而不是上面的高阶项和下面的机器精度）支配的区域。这使得在发生多个提交时运行时间比舒适时间长。

我曾经负责在另一个环境中解决这个问题。这是我所做的：

• 我发现了守恒定律。正如物理学家所熟知的那样，它们是纯金。能量守恒存在于许多 FE 设置中，但几乎所有物理模型中都存在大量守恒定律。如果您可以找到守恒定律并在（例如）每个时间步计算相关的守恒量，那么您对相关解决方案的信心就会大大提高。

• 如另一个答案中所述，我制造了解决方案，并将数值结果与$L_{1}$,$L_2$和$L_{\infty}$规范（为此我喜欢 googletest，但有很多很好的框架可以完成这项任务）。当然，这些永远不会为零，但是您可以设置一些合理的界限，并且当测试中断（并且它们会中断）时，您将有三个很好的衡量标准来衡量这种破坏是否是不可容忍的。

• 对于线性模型，您具有叠加和尺度不变性。因此，您甚至不需要分析解决方案，您只需重新调整您的 rhs 并测试新解决方案是否与您的缩放解决方案匹配。你会认为这不是一个强大的测试，但你猜怎么着。. . （有些人会争辩说这与我的第一点相同。）

• 我努力确保在 clang 上编译的代码，而不仅仅是 MSVC。这允许我使用 AddressSanitizer、UndefinedBehaviorSanitizer 和 ThreadSanitizer。这些捕获了许多内存泄漏和竞争条件，并提供了让我无需过度努力即可解决相关问题的输出。

• 我提出要比较的输出文件迫使科学家编写解析器，我们知道这非常困难。一旦管理层意识到大多数单元测试失败是解析器错误而不是代码错误，我的任务和范围就扩大了，我有更多的权力来检查代码。