测试驱动开发与自动定理证明

Question

我对数字逻辑/架构设计感兴趣的一件事是Automated Theorem Proving来验证，例如，浮点乘法模块。

单元测试很方便，但尝试测试（暴力）每个可能的浮点模块输入几乎是难以处理的。相反，您可以找到（1）它将始终生成正确结果的证据，或者（2）证明它将生成至少一个不正确结果的证据。

我现在正在尝试将类似的逻辑集成到我的软件中，我想知道我是否可以将它与测试驱动开发结合使用或代替测试驱动开发？

Answer 1

过去我在形式验证方面有很多经验，尽管它适用于硬件组件（VHDL / Verilog）。相同的原则可以应用于软件，但如果您有任何类型的I / O或事件，输入空间将变得难以管理。当状态空间变得太大时，在大型“模型”上证明任何类型的陈述也是不切实际的。

理想情况下，您可以使用“计算”​​函数的定理证明器来证明其正确性。但是，仍应使用测试有几个原因：

• 你的定理中可能存在“错误”。如果编写定理的人是编写正在测试的实际代码的人，那么这尤其“危险”。
• 正在测试的定理通常不完整。
• 您必须在您的测试环境中放置断言，以确保您用于代码输入（“环境”）的假设有效。

Answer 2

听起来你正在尝试构建“经过数学验证的软件”，这是一件非常难以实现的事情。

请参阅其他问题：why cant programs be proven
（注意：链接的问题标题具有误导性 - 某些程序可以被证明，但很难）

Answer 3

你是说你会在数学上证明你的算法在纸上是正确的，或者编写代码会做同样的事情吗？ （我对你如何做后者很感兴趣 - 如果可能的话，请链接到博客文章或如何在评论中做一些解释）

在前一种情况下，如果没有测试，您无法证明您的实施反映了您的意图并按预期工作 在后一种情况下，如果定理证明代码不执行实现 - 前一个论点成立。

就我个人而言，我只是使用TDD - 因为简单让我和其他人阅读一堆写得很好的测试并找出代码的作用。更不用说更快了。 您不必测试每个可能的输出 - 而是确定一组有代表性的输入。每个输入都应该通过代码执行不同的结果/路径。

Answer 4

始终与测试结合使用。否则，你无法证明你的实现实际上与你证明的是正确的一致。