検証に実際のテストが含まれていないのはなぜですか？

このトピックについて多くを読んだ後--- 検証と検証、ソフトウェアテストと品質保証に関するこのSoftware Testing Fundamentalsサイトなど --- NaikとTripathyによる理論と実践 ---まだわかりません。検証では、製品を適切に構築していることを証明し、検証では、適切な製品を構築していることを証明します。しかし、検証手法として言及されているのは静的手法（コードレビュー、要件チェックなど）だけです。あなたがそれをテストしない場合、それが正しく実装されているかどうかはどのように言えますか？検証は、製品が指定された要件を満たしていることを保証すると言われています。繰り返しになりますが、機能が何らかの形で機能するように指定されている場合、テストすることによってのみ機能すると言えます。

誰か私にこれを説明してもらえますか？

この質問はいくつかの論争を引き起こしたので、私の答えを私の背景から始めましょう：毎日のプロジェクト作業でV＆Vにさらされることは別として、私は母校のソフトウェアエンジニアリング部門で数年間働いており、ソフトウェアエンジニアリングの講師をしています。これは、私が言ったことが正しいことを保証するものではありませんが、少なくとも、この回答に何らかの真実があるのではないかという疑いの利益が得られることを願っています。

あなたが信じているほど混乱していないことを確認させてください。あなたの質問であなたが述べたことは、それが誤解を招くのと同じくらい真実です。まず、あなたが正しく述べたことを指摘しておきます。

• 検証=製品を正しく構築するvs検証=適切な製品を構築する
• 静的手法は検証の一部です。主に、プログラムと要件から導出された正式な入力を受け取り、それらを相互に評価するためです。
• 検証により、要件の正しい実装が保証されます（つまり、正しい方法で構築されていること）

次に、テストに関する混乱を片付けます。まず、多くのコメントが以前に述べたように、自動テスト（ユニット、統合など）によるコードの動的テストは、実際に検証の一部です。ただし、混乱のほとんどを引き起こすのは、検証中の人々がテストについても話し、それでも別の意味を持っているということです。検証では、通常、テストは意図された目的でアプリケーションを使用する人を含みます。最適なケースでは、これはお客様自身です。

ただし、検証と検証のテストで見つかった「エラー」[1]は根本的に異なります。

• 検証テストエラー：これらは、何らかの形で要件に違反するエラーです。
• 検証テストエラー：これらは、機能ではなく、作成した製品そのもののエラーであるため、要件内のエラーを明らかにします。

ほとんどの場合、さまざまなV＆Vケースの具体的な例を見ると役立ちます。以下は、エラーの極端な例です。

• 「f（x）はx + 1を返す必要がある」という低レベルの要件があり、「f」の実装は常に定数2を返す検証中にそれを見つけます。これは、eショッピングサイトを構築していて、彼が "f"を知らないか気にしていないためです。

• 「システムは、最大80％のCPU負荷で1秒あたり1000リクエストを処理できる必要がある」という要件があります。繰り返しになりますが、検証はほとんどの静的手法と同じように困難を伴います。実際、これを確認する最も簡単な方法は、アプリケーションをリクエストでハンマー処理して動的にテストし、その間CPU負荷を監視することです。

• 上記の「f」の要件をもう一度考えます。今回は「正しい」実装です。すべてのレビュー、静的分析、動的テストは成功を報告しますが、その後、顧客はソフトウェアをテストし、Webページのショッピングカートアイコンを見逃していることを伝えます。要件フェーズで行ったため、このエラーを見つけることができる検証の量はありません。

ご覧のとおり、「テスト」は、より正確に定義されていない場合でも、検証と検証の両方の一部であり、実際、「テスト」は両方に対して実行する必要があります。

[1]ここでは、「エラー」を口語的に使用して、エラー、失敗、間違い、障害などの区別を避けています。

実際、検証は製品を正しく構築していることを証明し、検証は正しい製品を構築していることを証明します。

したがって

• 検証はプロセスの証明です...必要な標準と手順に従っていること、通常は静的分析とコードレビューによってチェックされます。
• 検証は結果として得られる製品の証明です...コードは必要なことを行い、通常は動的分析とテストによってチェックされ、指定された入力が指定された出力になることを示します

私は通常ウィキペディアを引用しませんが、この場合は役に立ちます...

2つのプロセスの詳細な説明は、ISO 12207ソフトウェアライフサイクルプロセスにあります（他の回答の1つは、制御されていないコピーへのリンクを投稿します）。

7.2.4.3.2検証タスク

• 要件の確認
• 設計検証
• コード検証
• 統合検証
• 文書検証

7.2.5.3.2検証タスク

• テスト要件、ケース、仕様を準備する
• テストを実施する

さて、最初の質問では、検証にテストが含まれていない理由を尋ねました。そして、他の回答の一部にもかかわらず、高い評判のP.SEメンバーで、私はそれがポイントではないことをあなたにそれを置く検証活動が、の検証活動。

一部の回答は、コードまたは統合を検証するためにテストする必要があることを示唆しています。いいえ-その活動はモジュール化とインターフェースなどを証明することであり、実行ではありません。

Utimatelyは、どのようなこの議論が示すことは多くの混乱が何であるかにようがあるということです検証、何で検証が、これは、灰色の領域である境界によって助け、そして異なる規格に多少異なって定義されていません。

重要なのは、V＆Vの両方の部分をカバーする必要があるということです。意味的にそうである限り、VであるかVであるかは問題ではありません。VとVだけです。