私が見たすべての教科書は、テストと検証が2つの異なる概念であるという事実を大きく作ります。しかし、それらのどれも明確な（または、最後に私にとって十分に明確な）区別を提供しません。
コンテキストを提供するために、ハードウェア設計言語（HDL）を使用したデジタルハードウェア設計の検証に興味があります。
「物理的」または「有形」の違いに頼る説明を見てきました。製造されたデバイスに関するものであれば、それはテストです。これが全体の話ですか？そうだとすれば、なぜ「テスト」という言葉が検証で頻繁に出てくるのか（特に機能検証では、テストケース、テストベンチ、DUT（テスト対象デバイス）、ディレクテッドテスト、ランダムテストなどについて話します）
回答:
QualcommのASIC設計検証エンジニアでした。最も簡単な方法で説明できます。
テスト：製品を作成した後、製品が機能することを確認します（QAを考えてください）。
検証：作成する前に製品が機能することを確認します。
どちらもテストです。製品が存在する前に製品をテストする方法を考え出す必要があり、設計どおりに動作することを確認し、実際に製品がリリースされたときに仕様を確認する必要があるため、検証はより複雑です。
たとえば、Intelは次のプロセッサを設計しており、仕様があり、回路図とシミュレーションがあります。製造と製造を行うために10億ドルを費やします。その後、チップが戻ってきて、彼らはそれをテストし、動作しないことを発見します。彼らは窓からたくさんのお金を投げた。
検証を投入します。検証エンジニアは、チップの動作をシミュレートするモデルを作成し、それらの特定のモデルをテストするテストベンチを作成します。これらのモデルの結果を取得し、RTL（ハードウェア設計言語で記述された回路のモデル）の結果と比較します。それらが一致する場合、物事は（通常）OKです。
検証プロセスにはさまざまな方法論がありますが、一般的なものはUniversal Verification Methodology（UVM）です。
この分野には多くの深みがあり、人々はそこですべてのキャリアを過ごすことができます。
別のランダムな情報：通常、1人の設計エンジニアに対して3人の検証エンジニアが必要です。とにかくそれはフィールドの誰もが言うことです。
編集：多くの人が検証をテストの役割と考えていますが、そうではありません。設計者のようにICのすべての複雑さを理解する必要があるため、それ自体が設計の役割です。そして、ICのすべての機能をカバーするモデル、テストベンチ、およびすべてのテストケースを設計する方法を知る必要があります。 、すべての可能なビットの組み合わせについてRTLコードのすべての単一行をヒットしようとしています。製造プロセスがますます小さくなる（現在14nm）ため、現在のプロセッサには数十億個のトランジスタがあることに注意してください。
また、Intel、AMD、Qualcommなどの大企業では、設計者が実際にチップを設計することはありません。通常、アーキテクトはすべての仕様を定義し、特定の要件（速度、解像度など）を持つ特定の機能を得るために連携する必要があるピースのタイプをレイアウトし、デザイナーはそれをRTLにコーディングします。決して簡単な仕事ではありません。学校を出た多くのエンジニアが考えているほど多くの設計をしているわけではありません。誰もが望んでいるのは建築家ですが、そのためには多くの教育と経験が必要です。多くの建築家は博士号を取得しており、デザイナーとしての分野で15〜20年の経験があります。これらは、自分がやっていることをやっているに値する優秀な人（そして時には狂った人）であり、彼らはそれが得意です。私が取り組んだ最初のチップのアーキテクトは少し厄介で、実際にはいくつかの社会的規範に従っていませんでしたが、彼はあなたがチップに関して固執していることを解決できました、そして時々彼は彼の頭の中でそれを解決して教えてくれました1つの信号を見ると、「一体どうやって彼はそれをしたの？」それからあなたは彼に説明するように頼みます、そして、彼はそうします、そして、それはあなたの頭の上に行きます。すでに卒業していても、実際に教科書を読むようになりました。
私の本では、ベリフィケーションはあなたがデザインしたものが「仕事をする」ことを保証します-すなわち、「デバイス」が実行する必要があるもののセットを持ち、検証はそれらをリストから消します。
ただし、テストでは、「デバイス」が行うことを正しく行うことを確認しています。関数のセットがあり、各関数をテストして、その関数が適切に実行されることを確認します。
簡単に言うと、検証では設計をチェックし、テストでは製品をチェックします。
ASIC（ハードウェア）設計のバックグラウンドから来た3つの重要な用語があります：検証、検証、およびテスト。以前の回答では、一般にこれらの用語の1つまたは2つについて説明していますが、3つすべてを明確に対比してはいけません。私がそれらを理解する方法は次のとおりです。
テストは、仕様が満たされているかどうかを確認するように設計されています。検証は、デバイスが設計入力、つまりすべての仕様を満たしているかどうかを確認することです。もっと多くの解釈があると思いますが、これは私がFIAのガイダンス文書で見たものです。
検証テストと検証テストを区別します。一部の機器を冷却するファンを設計しているとしましょう。検証テストは、ファンがすべての設計要件を満たしていることを確認するために行われます。そのため、エアフロー、熱サイクル、振動などをテストできます。
検証テストは、設計要件が正しいものであることを確認します。ファンについての設計入力は、実際に必要なファンを提供しましたか？たとえば、意図したとおりにファンが実際に機器を冷却していることを確認します。
ISO9000は検証と検証について話します。ISO9000の検証では、プロトタイプ設計をテストして、機能およびパフォーマンスの期待値を満たしていることを証明します。検証とは、最初の実稼働をテストすることも、設計上の期待を満たすことです。最初に検証し、後で検証することが、物事の順序を記憶する私の小さな方法です。
いくつかのソフトウェア標準では、検証と検証の順序が逆になっています。これにより、実際に混乱が生じる可能性があるため、注意してください。
結論は...なぜあなたは何かをテストするのですか-それはプロトタイプ設計ですか-そうである場合、品質基準はこの検証を呼び出す傾向があります。プロダクションランを初めてテストする場合は、ハードウェア担当者がこの検証を呼び出します。
私の個人的な経験だけです。