検証vs検証、テストは検証に属しますか？もしそうなら、どれ？
私は以前に質問し、多くの論争を引き起こしたので、私はいくつかのデータを収集し、同様の質問を再度試みました。例えば。すべてのテストが検証のみであるV＆V： http://www.buzzle.com/editorials/4-5-2005-68117.asp ISO 12207によると、テストは検証で行われます。
- •テスト要件、ケース、および仕様を準備する
- •テストを実施する
検証では言及しています。
このコードは、適切なイベントシーケンス、一貫したインターフェイス、正しいデータと制御フロー、完全性、適切な割り当てタイミングとサイジングバジェット、およびエラーの定義、分離、回復を実装します。各ソフトウェアアイテムのソフトウェアコンポーネントとユニットは、完全かつ適切にソフトウェアアイテムに統合されています。
テストなしで検証する方法はわかりませんが、テクニックとしてはありません。
IEEEから：
検証：特定の開発フェーズの製品がそのフェーズの開始時に課された条件を満たすかどうかを判断するためにソフトウェアを評価するプロセス。 [IEEE-STD-610]。
検証：開発プロセスの最中または最後にソフトウェアを評価して、指定された要件を満たしているかどうかを判断するプロセス。 [IEEE-STD-610]
開発フェーズの終わりに？それはUATを意味します。
だから問題は、どのテスト（ユニット、統合、システム、UAT）が検証または検証と見なされるかということです。動的検証がテストであると言う人もいれば、検証のみであると言う人がいる理由がわかりません。
例：アプリケーションをテストしています。システム要件では、最大で2つのフィールドがあるとしています。 64文字の長さと保存ボタン。使用例：ユーザーは姓名を入力して保存します。フィールドと[保存]ボタンの存在を確認するとき、その確認と言います。ユースケースに従うと、その検証。したがって、その両方は、システム全体で行われます。
ISO 12207には、検証と検証の間で、かなり非標準的な（そして非常にあいまいな！）違いがあります。ほとんどのサークルでは、検証は「私たちはそれを正しく構築しましたか？」という質問に答えます。 （私たちの製品は要件を満たしていますか？）一方、検証は「これは構築するのに適切なものであったか」を意味します（要件のセットは適切ですか？） ISO 12207は要件の検証に言及しています。要件、特に最上位の要件をどのように確認しますか？あなたはしません。あなたはそれらを検証します。
検証と検証を区別するために私の時間の大部分を費やしている製品。この区別に関する問題は、迷惑なほど頻繁に現れました。その区別は私には明らかでしたが、私の解釈は普遍的に合意されていませんでした。これは検証テストですか、検証テストですか？ 誰が気にしますか？なぜ私たちはこの愚かな戦いをしているのですか？他の名前のバラは、甘い香りがします。最終的な目標は、「正しいですか？」という質問に答えることです。
この進行中のインブログリオに対する私たちの決議は、検証と検証の間のその区別を取り除くことでした。検証と検証は、「正しいですか？」という質問に答える1つの単語と考えています。 V＆Vを任意の部分に分割しません。分割するのは、その単一の質問にどのように答えるかです。トップレベルのドキュメントでも、重力のモデル化方法などの詳細なモデルドキュメントでも、第5章のタイトルは「検査、テスト、およびメトリック」です。以前のタイトル「検証と検証」：なくなりました。検証と検証を分割することはありません。代わりに、検査、テスト、およびメトリックに分割します。この章には通常、検査、テスト、トレーサビリティ（通常は自動化）、およびメトリック（通常は自動化）の4つのセクションがあります。補足：トレーサビリティ分析は、特別な（しかし非常に重要な）種類の検査にすぎません。重要であるため、別のセクションとして昇格されています。 「検査、テスト、トレーサビリティ、および測定基準」の章を呼び出すかどうかについて、私は少し口論しました。答えはノーでした。名前を巡る宗教戦争はもうありません。トレーサビリティは一種の検査です。タイトルはまだ合います。
実際に製品を使用せずに「正しい」という質問に答えるものは、「検査」という見出しの下にあります。要件分析、トレーサビリティ分析、モデルによる単純化された仮定がモデルの使用目的に受け入れられることを示す分析：製品を使用しなかったため、これらはすべて検査です。トレーサビリティは検査であるが、独自の家を持っている。製品を使用してその質問に答えるには、「テスト」という規範の下に行きます。単体テストから、既知の分析ソリューションを使用した人工的なセットアップに対するテスト、統合テスト、製品の結果を以前に飛行した車両から収集された実際のデータと比較するものすべて：すべてテストです。多くのメトリックを収集する過程で、それらの多くは自動化されました。さまざまなレベルのドキュメントには、さまざまな種類の退屈ですが重要な数値があります。 SLOC数、複雑さ、コードカバレッジ、付与された権利放棄の数、CMシステムの問題の数。これらの退屈で重要な数値は、「メトリック」という規範の下にあります。
私たちの開発者とテスターは、この変化を気に入っています。なぜなら、今どこに行くのかがはっきりしているからです。プロジェクト管理者はこの変更を気に入っています。これは一貫性があり、命名法についてのばかげた論争をすべて取り除くためです。私たちのCMMIオーバーロードは、私たちが正しい質問（「正しい」）にまだ答えており、そこに到達するための明確に定義されたプロセスを持っているため、それを愛しています。 Beanカウンターは、簡単に見つけて数えることができる多くのBeanを提供しているため、とても気に入っています。
検証は、製品が実際にユーザーのニーズを満たしていること、および仕様がそもそも正しいことを保証しますが、verificationは、製品が要件に従って構築されていることを保証しますおよび設計仕様。
検証または検証と見なされるのはどのテスト（ユニット、統合、システム、UAT）ですか？
ユニット、統合、およびシステムのテストは検証です。 UATは検証です。
だから問題は、どのテスト（ユニット、統合、システム、UAT）が検証または検証と見なされるかということです。
一般的に、ハイレベルで話すと、あなたの例と説明は良いように聞こえます。
あなたの例ではverification is「最大長が64文字の2つのフィールドと保存ボタンがあること」を確認することについて。要件に従って一部の要素が欠落している場合、検証に合格しません。これも最初のステップです。
"validation is"-指定された必須要素の入力と動作の詳細。あなたの場合、それは最大の検証です。そして最小値。入力の長さ、特殊文字の許容量、およびその他の関連するビジネスルール。
関連するビジネスデータフローがある場合は、これをすべて最初に単体テストでして次のステージに伝達します。