我们怎么知道形式方法有效？

形式化方法的一个重要目标是通过自动化或人工指导的方法来证明系统的正确性。但是，似乎即使您可以提供正确性证明，也可能无法保证系统不会失败。例如：

• 规范可能无法正确地对系统进行建模，或者生产系统可能过于复杂而无法建模，或者由于相互矛盾的要求，系统可能固有地存在缺陷。已知哪些技术可以测试规范是否完全有意义？
• 证明过程也可能有缺陷！谁知道这些推理规则是正确和合法的？此外，证明可能非常大，我们如何知道它们不包含错误？这是de Millo，Lipton和Perlis的“社会过程以及定理和程序证明”的批评的核心。现代形式方法研究人员如何回应这种批评？
• 在运行时，有许多不确定的事件和因素会严重影响系统。例如，宇宙射线会以不可预测的方式改变RAM，更一般地说，我们无法保证硬件不会遭受拜占庭式的故障，而Lamport证明了这种故障很难克服。因此，静态系统的正确性不能保证系统不会失败！是否有已知的技术可以解释真实硬件的易失性？
• 目前，测试是我们确定软件有效的最重要工具。似乎它应该是形式方法的补充工具。但是，我主要看到的是侧重于形式方法或测试的研究。关于两者结合的已知知识？

关于4：将正式方法和测试结合起来的工作量很大。谷歌搜索“正式方法测试”显示了大量工作。尽管此类工作有许多不同的目标，但主要目标之一是生成更有效的测试套件。该演讲基于模型检查给出了一个很好的介绍。

另外，关于软件安全性的问题也已被排除在外：正式方法需要更加努力地实现这一领域。通常，一个人为一个软件编写一个规范并验证该规范是否得到满足，即，当输入满足先决条件时，输出满足后条件。为了确保软件的安全性，还需要检查该软件对于不满足前提条件的输入是否表现出合理的行为。（这当然等于将所有输入的前提条件设置为true。）所有输入的空间通常比格式正确的输入要大得多，但是通常这是一个甚至可以破坏功能正确的软件的地方，这很容易违反其假设。

关于第3点：已经完成了一些工作，以在明确建模了故障的环境中验证系统，包括“ 故障逻辑：有关容错程序的推理”。Matthew Meola和David Walker。欧洲编程研讨会，2010年。关于概率模型检查和概率验证的工作当然也在一定程度上解决了故障问题。

您的要点：

• 所有规范的正确性最终都是主观的：被认为可以根据其用户正确地解决问题，或者没有解决。这离不开软件开发，也没有方法可以解决这一问题。
• 大量工作证明该过程相对于其假设是正确的。通常，专家可以使用信息来验证这些规则。任何人类活动是容易出错，但使用充分研究的方法非常正式的系统更容易出错比几乎所有其他人的过程。
• 在任何时候，任何系统的故障模式都超出该系统的范围。即使将一些无法预测的错误原因留在了不计其数的地方，您还是最好消除所有可预测的错误源。
• 测试和证明可以轻松共存。测试是一个不太具体，更临时的过程，因此您可能会发现对其进行的正式工作较少。但是您可能对QuickCheck之类的工具感兴趣，该工具可以通过测试补充Haskell类型系统提供的证明。

正式的方法已经被证明可以长时间使用。没有它们，我们将无法应对设计现代数字系统（微处理器）的复杂性。

任何微型船舶都必须对其逻辑进行功能等效性验证；其FPU不受FV约束；但其缓存一致性协议并未受到FV的限制（自1995年以来就是这种情况）。

除非软件和工程物理系统（例如，可以在其中添加安全系数的桥梁）之间存在明显差异，否则它们在CS中起着工程数学的作用。但是，FM的使用始终取决于收益/成本。模糊测试在Microsoft等公司（一张幻灯片中的Google SAGE）上获得了丰厚的回报。

即使在微型计算机中，也存在子系统（例如微处理器管道），其中FV的影响与其他地方（例如FPU）不同，在正式的符号轨迹评估证明没有缺陷的情况下，FV在许多情况下根本没有进行常规测试：Kaivola 等人， CAV'09）。

形式化方法也被用于人工制品的综合（代码，高质量测试，以最佳方式消耗电池组的时间表等）。当然，问题中提出的所有问题都是很有效的，并且像在其他任何技术使用中一样，必须识别并避免虚假广告。

关于2：如果系统在证明助手（例如Twelf或Agda或Coq）中形式化，并且验证了完整性和完整性，并且以这种编码方式完成了证明，则这不是问题。你可能已经正式未被描述的系统是什么，你打算，但你至少不会有不正确的证明或损坏的系统中，你的推理。

但是，似乎即使您可以提供正确性证明，也可能无法保证系统不会失败。

是的，也许没有保证。正式方法旨在发现并消除错误并说服人类。

已知哪些技术可以测试规范是否完全有意义？

您可能对用于形式系统规范的模型检查工具感兴趣。

证明过程也可能有缺陷！谁知道这些推理规则是正确和合法的？

我认为（由于Goedel的不完全性定理）显示推理规则系统是一致的，因此必然会吸引更强大的推理规则集。

此外，证明可能非常大，我们如何知道它们不包含错误？

希望大型证明可以通过小型证明检查器进行检查，人类可以在合理的时间内阅读和理解这些证明。有时称为“ de Bruijn标准”。如果您认为证明检查器不会证明不正确的证明，则只需要检查检查器即可。

是否有已知的技术可以解释真实硬件的易失性？

如何容错汇编类型的语言？

但是，我主要看到的是侧重于形式方法或测试的研究。关于两者结合的已知知识？

“ TAP会议致力于证明和测试的融合”。

只是谷歌搜索“证明和测试”有很多不错的选择。

已知哪些技术可以测试规范是否完全有意义？

这绝对是一个判断电话。在软件工程中，人们设计了非常严格的方法来查找/编写/确认规范。这是由真实的人使用非形式化的方法（在某种意义上说是非数学过程）完成的，因此仍然存在不一致的地方，但是最终，它还是与人们想要验证的内容相对应。

是否有已知的技术可以解释真实硬件的易失性？

当然，这里有一个称为运行时验证的验证领域，您还可以在特定情况下在完全虚拟环境中运行的真实系统上使用基于执行的模型检查（我使用V-DS + APMC为此做出了自己的贡献）。但是，这显然是将系统与环境之间的交互添加到验证过程中的主要问题。

但是，我主要看到的是侧重于形式方法或测试的研究。关于两者结合的已知知识？

哇，今天我将完全无耻，再次引用自己。与我们合作进行模型检查和测试结合的合著者，您可以查看我们小组的一名前博士学位学生的出版物清单，或在任何好的搜索引擎中搜索“近似概率模型检查”或“统计模型检查”（ Younes等，Sen等或我本人等）。

您可能对PVS定理证明者的设计师之一John Rushby的作品很感兴趣，他对您提到的要点普遍感兴趣。您可能会喜欢读给FAA的这本关于形式方法和关键系统认证的经典报告（1993年），以及他的较新著作，其中涉及从提供的各种证据（测试，证明，分析等）。