「単体テスト」は正式な方法の1つですか？
調査の結果、次のことがわかりました。
- 形式的な方法は、設計の信頼性と堅牢性に貢献します。 （ref： Wikipedia-Formal method ）
- ユニットテストは、開発者によって導入されたエラーがないことを保証します（ref： Wikipedia-Unit Testing ）
私が見るように here のように、正式な証明は、数式（ブール式）に基づく数学的な計算にすぎません。
単体テストはアサーションからチェックされるため、主に1つまたは一連のブール式で行われます。
さらに、私は（非常に迅速に）正式な証明からユニットテスト生成の 研究論文 を読みました。
- 単体テストは形式的な方法の形式ですか（ここでは、形式的な証明のようなシステムを考えています）。
- まったく別のコンセプトの場合、違いは何ですか？
この質問の目的は、ユニットテストを実行した後でもバグがあるかどうかを知ることではありません。彼の目的は、単体テストと正式な方法の間にリンクがあるかどうかを知ることです。
2つは異なるものであり、実際には、理論上よりも実際にははるかに異なります。
正式な正当性の証明は、アルゴリズムの動作について何かを証明します。たとえば、並べ替えアルゴリズムによってデータが変換されるときにデータに適用される不変条件を調査し、アルゴリズムが終了すると、すべての要素が前の要素より大きいことを証明します。この種の証明は厳密である可能性があります。つまり、正しく実行された場合、アルゴリズムがこの点で間違っていることはありません。
実際には、アルゴリズムはコンピューターコードで具体化する必要があります。通常、コードの特定のビットが目的のアルゴリズムを正確に表していることを証明することは不可能です。 （これには、コンパイラ、標準ライブラリ、仮想マシンなどの動作を正式に証明する必要があります。）プログラミング言語が正式な証明で使用した数学的表記と似ているほど、少し簡単になりますが、たくさん。 （スペースシャトルの中央システムで実行されるコードは、それ自体がほぼ完全な数学的表記であると言われていましたが、プログラムするのはあまり快適ではありませんでした。）
慎重に選択された入力で実際にコードを実行し、期待される出力を生成することを確認する方がはるかにコスト効率が高くなります。これには、エラーがないことを決して確認できないという欠点があります-テストしていない入力/出力ペアに対して動作する可能性があります（通常、テストできるよりも多くのペアがあるか、またはそもそも作業を行うためにコンピュータープログラムが必要な場合）、またはさらに悪いことに、テストが公開しないように、コードが微妙に非決定的またはコンテキスト依存である場合があります。
しかし、実際には、計算に影響を与えるmostエラーは次のように公開されますインテリジェントなチェック、および既知のエラーの記録と、それらが再発しないことを確認するテストケースを保持している場合、通常、コードの品質は十分にビジネス価値のあるものにすることができます。確かに、ユニットテスト、統合テスト、ユーザー受け入れテストを実行して、書かれた仕様と実際の顧客の期待。したがって、現実の世界では、この2つはほぼ完全に異なるアクティビティです。
「正式な方法」の正確で普遍的に受け入れられている定義はありません。ただし、ほとんどの定義は、何らかの形の数学的厳密さ、形式主義、または証明を暗示しており、単体テストでは提供されません。
単体テストは単に「試してみて、この1つの特定のケースで機能するかどうかを確認する」だけですが、正式な方法では、「すべての環境のすべての条件で常にすべてのケースで機能する」ことを証明しようとします。