ソフトウェアテストの分類
テスト段階別
- 単体テスト: 単体テストは、ソフトウェア設計の最小単位、つまり正確性をチェックするためのプログラム モジュールまたはコード セグメントのテスト作業であり、通常は開発者によって実行されます。
- 統合テスト: 統合テストは、テストの設計要件に従ってモジュールを組み立てることであり、主な目的はインターフェイスに関連する問題を見つけることです。
- システム テスト: システム テストは、統合テストに合格した後に実行されます。目的は、システムを完全に実行し、各サブシステムが正常に動作し、設計要件を満たしているかどうかを確認することです。
- 受け入れテスト: 受け入れテストは、要求フェーズの「要求仕様書」を受け入れ基準とし、実際のユーザーの動作環境をシミュレートする必要があります。実際のプロジェクトの場合は顧客と一緒に実施できますし、製品の場合は最後のシステムテストになります。テスト内容は機能モジュールの総合テスト、特にドキュメントテストです。
執行機関によると
- アルファ テストとは、ソフトウェア開発会社の内部担当者がさまざまなユーザーをシミュレートして、今後のソフトウェア製品 (アルファ バージョンと呼ばれる) をテストして、エラーを見つけて修正することを指します。α テストのポイントは、実際の動作環境とソフトウェア製品のユーザーの操作を可能な限り現実的にシミュレートし、考えられるすべてのユーザーの動作モードを可能な限りカバーするように努めることです。アルファテストを通じて調整されたソフトウェア製品をベータ版と呼びます。
- ベータテストは、ソフトウェアの複数のユーザーが実際の使用環境でテストを実施し、これらのユーザーが関連するエラー情報を開発者に返します。ベータテストでは、ユーザーが実際の問題や主観的な問題も含めて発生したすべての問題を記録し、開発者に定期的に報告し、アルファテストで一定の信頼性が得られた場合にのみベータテストを開始できます。テストの最終段階に入っています。同時に、製品のすべてのマニュアルテキストもこの段階で完全に完成する必要があります。
- サードパーティによるテストは、開発者やユーザーによるテストとは異なり、テスト作業の客観性を確保することが目的です。
実行状況に応じて
- 静的手法とは、テスト対象のプログラムそのものを実行するのではなく、ソースプログラムの構文、構造、処理、インターフェースなどを解析またはチェックすることでプログラムの正しさを確認するだけの手法を指します。要求仕様、ソフトウェア設計仕様、ソースプログラムに対して構造解析、フローチャート解析、シンボリック実行を行い、エラーを発見します。
- 動的テスト手法とは、テスト対象のプログラムを実行して、実行結果と期待される結果との差異を確認し、実行効率、正確性、堅牢性などの性能を分析することを指します。
静的テストと動的テストの違いは次のとおりです。
テスト技術によると
| 試験方法 | 導入 |
|---|---|
| ホワイトボックステスト | ホワイトボックス テストは構造テストとも呼ばれ、主にソフトウェア コーディング プロセスのエラーを検出するために使用されます。プログラマーのプログラミング経験、プログラミング ソフトウェアの習熟度、作業状況、その他の要因がプログラミングの品質に影響を与え、コード エラーにつながります。 |
| ブラックボックステスト | ブラックボックステストは機能テストとも呼ばれ、主にソフトウェアの各機能が正常に使用できるかどうかを検出します。テストプロセスでは、プログラムを開くことのできないブラックボックスとみなし、プログラムの内部構造や特性を考慮せずにプログラムインターフェイスをテストし、プログラムの機能が設計どおりに開いて正常に使用できるかどうかを確認します。要件とマニュアルの仕様。 |
| グレーボックスのテスト | グレー ボックス テストは、ホワイト ボックス テストとブラック ボックス テストの間のテストであり、出力と入力の正確性だけでなく、プログラムの内部状況にも注意を払う、統合テストのフェーズで主に使用されます。グレー ボックス テストは、ホワイト ボックス テストほど詳細かつ完全ではありませんが、ブラック ボックス テストよりもプログラムの内部ロジックに注目し、いくつかの代表的な現象、イベント、兆候を通じて内部の動作状態を判断することがよくあります。 |
ソフトウェアテストモデル
ソフトウェア テスト モデルはソフトウェア テスト作業のフレームワークであり、ソフトウェア テスト プロセスに含まれる主なアクティビティとアクティビティ間の相互関係を記述します。ソフトウェアテストモデルには、V モデル、W モデル、H モデル、X モデル、プレモデルなどが含まれます。
Vモデル
V モデルには一定の制限があり、テスト プロセスを要件分析、一般設計、詳細設計、コーディング後の段階としてのみ考慮します。テストはソフトウェア開発の最終段階であり、主にプログラムのエラーを見つけるためのテストであり、要件分析段階で隠れた問題はその後の受け入れテストまで発見されないことを人々に理解してもらうのは簡単です。
Wモデル
V モデルと比較して、W モデルでは、ソフトウェア開発の各段階で同時に実行する必要がある検証と検証 (V&V) アクティビティが増加します。
W モデルは、テストと開発のプロセスをそれぞれ表す 2 つの V 字型モデルで構成されており、テストにはソフトウェア開発サイクル全体が伴います。テストの対象は、プログラムだけでなく、要件や設計も含まれます。たとえば、テストと開発は同期されます。
W モデルは、「ソフトウェアのテストをできるだけ早く、継続的に行う」という原則を体現しています。W モデルにも制限があります。Wモデルでは、要件、設計、コーディングなどの活動を連続的に捉え、テストや開発の活動が直線的な前後関係を保ち、前の段階の終了後に次の段階の作業が開始されるため、 、W モデルは反復をサポートできません。開発モデル
Hモデル
V モデルと W モデルはどちらも、ソフトウェア開発は要件、設計、コーディングなどの一連の一連のアクティビティであると考えています。実際、これらのアクティビティはほとんどの場合重複する可能性があるため、対応するテスト間に厳密な順序関係はありません。 . 単体テスト、統合テスト、システム テストの間で繰り返しが行われます。V モデルと W モデルの問題点から、H モデルではテスト活動が完全に分離され、テスト準備活動とテスト実行活動が明確に反映されます。
H モデルは、ソフトウェア テストが独立したプロセスとしてソフトウェア ライフ サイクル全体を通じて実行され、他のプロセスと同時に実行されることを明らかにし、ソフトウェア テストはできるだけ早く準備して実行する必要があると指摘しています。さまざまなテスト アクティビティを特定の順序で実行したり、繰り返したりすることができ、特定のテストが準備完了点に達する限り、テスト実行アクティビティを実行できます。
Hモデルの特徴:
- テストの準備とテストの実行を分離することは、リソースの割り当て、コストの削減、効率の向上に役立ちます。
- (テクノロジーではなく) テストプロセスの複雑さを完全に反映します。
Xモデル
X モデルの左側は、個々のプログラム断片のコーディングとテストを記述します。
X モデルの右上では、統合テストに合格した完成品が封印されてユーザーに提出され、より大きな規模および範囲の統合の一部として使用することもできます。
探索的テストは、X モデルの右下にあります。これは、事前に計画されていない特殊なタイプのテストであり、多くの場合、テスト計画外のソフトウェアのバグが見つかります。
フロントモデル
フロントモデルの特徴：
- 開発とテストを組み合わせる
- 各成果物をテストする
- 設計段階で設計を計画およびテストする
- 受け入れテストと技術テストを分離する
- 代替開発とテスト
フロントモデルの長所と短所:
アドバンテージ：
- テストの品質を向上させるための厳格な QA と QC
- テストは開発中に常に実行されるため、テストが効果的に改善されます。
- 受け入れテストに重点が置かれ、システムが正常に受け入れられることを確認するためにデュアルモード テストが使用されます。
欠点:
- 複雑なプロセス管理
- 要件が変わると対応が難しい
- 文書化、品質管理、構成管理、プロジェクト管理に対する高い要件
テストケース
テスト ケース (Test Case) は、ソフトウェア テストの動作を管理可能なモデルに変換することを目的とした、ソフトウェア テストの動作を科学的に組織化し、誘導するものであると同時に、テストを定量化する手法の 1 つでもあります。 . ソフトウェアのクラス、テストケースが異なります。テストケースの設計方法には主にブラックボックステスト法とホワイトボックステスト法があります。
テストケースの役割
- ガイド付きテストの実装
- テストデータの準備の計画
- テスト結果を評価するための指標
- ソフトウェアの保守性と再利用性を確保する
- 欠陥の分析基準
テストケースの設計要件
- 効果
- 経済
- 多重度
- 完全
- 決定可能性
- 再現性