検証と妥当性確認

• 製品を正しく作っているか、という問いです。
• 主に、インスペクションとレビューで行います。

• 正しい製品を作っているか、という問いです。
• 主にテストで行います。

システムの静的な表現を分析し、問題を見つけるプロセスです。静的な検証に当たります。

システムを実行する必要はありません。

• 実装する前でも確認できます。

• 要求、設計、コード、文書などです。

ソフトウェアを実行して、問題を見つけるプロセスです。動的な検証に当たります。

プログラムが意図したとおりに動くかを確認します。

使われる前に、不具合を見つけます。

• 要求仕様 (Requirement Specification)
• ソフトウェアアーキテクチャ (Software Architecture)
• UML設計モデル (UML Design Model)
• DBスキーマ (DB Schema)
• プログラム

• システムのプロトタイプ (System Prototype)
• プログラム

• 顧客の実際の要求に合っているかどうか。
• 性能や使いやすさなどの、非機能的な特性。

• バグや不具合を見つけるため、開発中にシステムをテストします。
• 開発者が単体テストと統合テストを行います。

• 別のテストチームが、利用者に渡す前の完全なシステムをテストします。
• 全体をテストし、機能が統合されて正しく動くかを確認します。

• 利用者や潜在的な利用者が、自分の環境でシステムをテストします。
• 実際の利用シナリオに基づいて、ソフトウェアを確認します。

• 個々のプログラム単位やオブジェクトのクラスをテストします。
• オブジェクトやメソッドの機能に重点を置きます。

• 複数の単位を組み合わせ、コンポーネントをテストします。
• コンポーネントのインターフェースの確認に重点を置きます。

• システムの一部、またはすべてのコンポーネントを組み合わせてテストします。
• コンポーネント同士の相互作用を重視します。

• 対象を外側から見て、テストケースを導きます。
• 有効な入力と無効な入力を選び、正しい出力を決めます。
• 対象内部の構造については、知識を持ちません。

• プログラムの構造に基づいて、テストケースを導きます。
• プログラムの知識を使い、追加のテストケースを見つけます。

入力の領域を複数の部分集合へ分け、それぞれから代表値を選んでテストする技法です。

テスト範囲を減らしながら、効率よく不具合を見つけられます。

• Partition 1：0、5（無効な値）
• Partition 2：6、10（有効な値）
• Partition 3：11、14（無効な値）

• シーケンスに、少なくとも一つの要素があります。
• T`FIRST ≦ L ≦ T`LAST

• Found = TRUEなら、T(L) = Keyです。
• Found = FALSEなら、TにはKeyが存在しません。