検証に実際のテストが含まれないのはなぜですか？
このトピックについてたくさん読んだこと---など 検証と妥当性確認に関するこのソフトウェアテストの基礎サイト および ソフトウェアテストと品質保証：NaikとTripathyによる理論と実践 ---まだわかりません。検証は、製品を正しく構築していることを証明する必要がありますが、検証は、適切な製品を構築したことを証明します。ただし、検証手法として言及されているのは静的手法（コードレビュー、要件チェックなど）だけです。テストしないと、正しく実装されているかどうかをどのように判断できますか？検証により、製品が指定された要件を満たしていることが保証されると言われています。繰り返しになりますが、関数が何らかの方法で機能するように指定されている場合、テストすることによってのみ機能すると言えます。
誰かが私にこれを説明してもらえますか？
この質問がいくつかの論争を引き起こしたので、私の経歴からこの答えを始めましょう。毎日のプロジェクト作業でV＆Vに触れることは別として、私は母校のソフトウェアエンジニアリング部門で数年間働き、ソフトウェアエンジニアリングの講師をしています。これは私が言うことが正しいことを保証するものではありませんが、少なくともこの答えに何らかの真実があるかもしれないという疑いの利益を私に与えることを願っています。
あなたが信じているほど混乱していないことを保証しておきましょう。あなたがあなたの質問で述べたことは、それが誤解を招くのと同じくらい真実です。最初に指摘させていただきますが、あなたが正しく述べたことは次のとおりです。
- 検証=製品を正しく構築するvs検証=適切な製品を構築する
- 静的手法は検証の一部です。主に、プログラムと要件から導出された正式な入力を受け取り、それらを相互に評価するためです。
- 検証により、要件が正しく実装されていることが保証されます（つまり、正しい方法で構築されていること）
testingに関する混乱を片付けましょう。最初に、多くのコメントが以前に述べたように、自動テスト（ユニット、統合など）によるコードの動的テストは確かに検証の一部です。ただし、ほとんどの混乱の原因は、検証中の人々がテストについても話すことですが、それでも別の意味があります。検証では、テストには通常、意図した目的でアプリケーションを使用する人が関与します。最適な場合、これは顧客自身です。
ただし、検証と検証のテストで見つかった「エラー」[1]は、根本的に異なります。
- 検証テストエラー：これらは、何らかの形で要件に違反するエラーです。
- 検証テストエラー：これらは、機能ではなく、構築した製品そのもののエラーであるため、要件内のエラーが明らかになります。
ほとんどの人にとって、さまざまなV＆Vケースの具体例を見ると役立ちます。以下は、エラーの極端な例です。
「f（x）はx + 1を返す必要がある」という低レベルの要件があり、「f」の実装は常に定数2を返します。このエラーはいくつかの異なる検証アプローチで見つかるかもしれませんが、顧客はおそらくそうしません。あなたはe-ショッピングサイトを構築していて、彼は「f」を知らず、気にもしないので、検証中にそれを見つけます。
「システムは最大80％のCPU負荷で毎秒1000のリクエストを処理できる必要がある」という要件があります。繰り返しますが、検証は、ほとんどの静的な手法と同じように、困難を伴います。実際、これを確認する最も簡単な方法は、アプリケーションをリクエストでハンマーで叩き、その間のCPU負荷を監視することで、アプリケーションを動的にテストすることです。
上記の「f」の要件をもう一度検討します。今回は「正しい」実装を使用します。すべてのレビュー、静的分析、動的テストは成功を報告しますが、顧客testsがソフトウェアであり、Webページのショッピングカートアイコンを見逃していることを伝えます。要件フェーズで行ったため、このエラーを見つけることができる検証の量はありません。
ご覧のとおり、「テスト」は、より正確に定義されていない場合、検証と妥当性確認の両方の一部であり、実際、「テスト」は両方に対して実行する必要があります。
[1]ここでは、「エラー」を口語的に使用して、エラー、失敗、間違い、障害などの区別を避けています。
確かに：検証はあなたが正しい製品を構築していることを証明し、検証はあなたが正しい製品を構築していることを証明します。
したがって
- 検証とは、プロセスを証明することです...必要な標準と手順に従っており、通常は静的分析とコードレビューによってチェックされます。
- 検証は、結果の製品を証明しています...コードが必要なことを実行し、通常は動的分析とテストによってチェックされ、指定された入力が指定された出力になることを示します
私は通常はしません ウィキペディアを引用 、しかしこの場合、それは役に立ちます...
2つのプロセスの詳細な説明は、ISO 12207ソフトウェアライフサイクルプロセスにあります（他の回答の1つは、制御されていないコピーへのリンクを投稿します）。
7.2.4.3.2検証タスク
- 要件の検証
- 設計検証
- コード検証
- 統合検証
- ドキュメントの検証
7.2.5.3.2検証タスク
- テスト要件、ケース、仕様を準備する
- テストを実施する
さて、冒頭の質問は、検証にテストが含まれない理由を尋ねました。そして、他のいくつかの回答にもかかわらず、評判の高いP.SEメンバーによると、それは検証アクティビティのポイントではなく、validationアクティビティ。
いくつかの回答は、コードまたは統合を検証するためにテストする必要があることを示唆しています。いいえ-そのアクティビティは、実行ではなく、モジュール性やインターフェイスなどを証明することです。
最終的に、この議論が示しているのは、検証とは何か検証とは何かについて多くの混乱があるということです。境界が灰色の領域であることに助けられず、異なる標準でわずかに異なって定義されています。
重要なのは、V＆Vの両方の部分をカバーする必要があるということです。その場合、意味的には、VであるかVであるかは問題ではなく、VとVだけです。