コンポーネントテストとは? テクニック、テストケースの例
コンポーネントテストとは何ですか?
コンポーネントテスト これは、他のコンポーネントと統合せずに、個々のコンポーネントごとに個別にテストを実行するソフトウェアテストの種類です。アーキテクチャの観点から見ると、 モジュールテストまた、一部の文献ではこれをプログラムテストと呼んでいます。
ソフトウェア全体は複数のコンポーネントで構成されており、コンポーネントレベルのテストはそれらのコンポーネントを個別にテストするものです。これは最も頻繁に行われるテストの1つです。 ブラックボックステスト QAチームが実施した各種処理。
命名に関する注意点を最初に述べておく価値がある。ISTQB 用語集では、コンポーネント テストと 単体テスト 同じテストレベルの同義語として使われることがありますが、多くの開発チーム、そしてこの記事でも、実際には両者を区別しています。開発者は自身のコードに対して単体テストを実行し、テスターは納品されたビルドに対してコンポーネントテストを実行します。この記事の末尾にある比較表で、その実際的な区別を示しています。
下の図に示すように、コンポーネントテストには独自のテスト戦略とテスト計画があり、ソフトウェアまたはアプリケーションの各部分が個別に検討されます。各コンポーネントについて、 テストシナリオ が定義され、それが高レベルのテストケースに分解され、最終的に低レベルの詳細なテストケースに分解されます。 テストケース 前提条件あり。
「コンポーネントテスト」という用語の使い方は、分野や組織によって異なります。こうした認識の違いが生じる最も一般的な理由は、以下の3点です。
- 選択された開発ライフサイクルモデルの種類
- テスト対象のソフトウェアまたはアプリケーションの複雑さ
- テストがアプリケーション内の他のコンポーネントから分離して行われるか、分離せずに行われるか
ソフトウェアテストのライフサイクルでは、多くのテスト成果物、つまりテスト活動中に作成および使用されるドキュメントが生成されます。その中でも、テストポリシーとテスト戦略は、特定のプロジェクトにおいてどのような種類のテストが使用され、テストがどの程度の深さまで行われるかを定義します。
コンポーネントのテストを行うのは誰ですか
コンポーネントテストはテスターが実施します。ユニットテストは開発者が実施し、個々の機能や手順をテストします。ユニットテストが完了すると、コンポーネントテストが開始され、テスターがその責任を引き継ぎます。
コンポーネントテストをいつ実行するか
コンポーネントテストは、開発者による単体テストが完了し、ビルドがテストチームにリリースされた直後に実施されます。このビルドはUTビルド、つまり単体テストビルドと呼ばれます。このフェーズでは、各コンポーネントの主要な機能がテストされます。
コンポーネントテストの開始基準
- UTビルドに含めるべき最小限のコンポーネントセットが開発され、単体テストが実施されました。
コンポーネントテストの終了基準
- すべてのコンポーネントの機能は仕様どおりに動作します。
- 重大度、高、中程度の深刻度または優先度の欠陥は残っていません。 不具合ログ.
コンポーネントのテスト手法
テストレベルの深さに基づいて、コンポーネントテストは2つの方法で分類されます。
- CTIS — 小規模なコンポーネントのテスト
- CTIL — 大規模コンポーネントテスト
CTIS — 小規模なコンポーネントのテスト
コンポーネントテストは、テスト対象アプリケーション内の他のコンポーネントから隔離して実施することも、隔離せずに実施することも可能です。他のコンポーネントを隔離して実施する場合、それは小規模コンポーネントテストと呼ばれます。
例1: 5つの異なるウェブページを持つウェブサイトでは、各ウェブページを他のコンポーネントから切り離して個別にテストすることは、小規模なコンポーネントテストです。
例2: 以下に示す guru99.com のホームページには、ホーム、テスト、 SAPウェブ、必修科目!、ビッグデータ、ライブプロジェクト、ブログ。
どのようなソフトウェアも同様に多くのコンポーネントで構成されており、各コンポーネントには独自のサブコンポーネントがあります。例2に挙げた各モジュールを、他のコンポーネントとの統合を考慮せずに個別にテストすることは、コンポーネントテストの簡略化と言えます。
テストのドロップダウンメニューを開くと、テストコンポーネントのサブコンポーネントが表示されます。 手動テストSOAPUI、 QTP, JUnit, Seleniumテスト管理と モバイルテスト下のスナップショットでは、それらのサブコンポーネントが赤色で強調表示されています。
CTIL — 大規模コンポーネントテスト
テスト対象アプリケーション内の他のコンポーネントから分離せずに実施されるコンポーネントテストは、大規模コンポーネントテストと呼ばれます。
例を挙げると、その違いがより明確になります。アプリケーションがコンポーネントA、コンポーネントB、コンポーネントCの3つのコンポーネントで構成されているとします。
開発者はコンポーネントBを作成し、テストを希望しています。コンポーネントBを完全にテストするには、その機能の一部がコンポーネントAに依存し、一部がコンポーネントCに依存している必要があります。下の図を参照してください。
機能の流れは A → B → C であり、これはコンポーネント B が A と C の両方に依存していることを意味します。この流れにおいて、スタブは呼び出される関数であり、ドライバは呼び出し元の関数です。
コンポーネントAとコンポーネントCはまだ開発されていません。コンポーネントBを完全にテストするために、必要に応じてAとCをドライバとスタブに置き換え、実際のコンポーネントが完成するまで、不足している2つのコンポーネントはダミーオブジェクトとして機能します。
- スタブ: スタブは、テスト対象のコンポーネントによって呼び出されます。コンポーネントCが準備できていないため、スタブが代わりに動作し、コンポーネントBが期待する応答を返します。
- ドライバ: ドライバはテスト対象のコンポーネントを呼び出します。コンポーネントAが準備できていないため、ドライバが代わりにコンポーネントBを呼び出し、必要な入力値を渡します。
コンポーネントテストのテストケースの例
以下の2つのウェブページは機能的な観点から相互に関連しており、テスト対象として有用なペアとなっています。
ウェブページ1は、デモ用銀行サイトのログインページです。
ユーザーが有効なユーザーIDとパスワードを入力して送信ボタンをクリックすると、次に示すデモ銀行ウェブサイトのホームページに移動します。
ここでは、ログインページは1つのコンポーネントであり、ホームページは別のコンポーネントです。それぞれのページの機能を個別にテストすることが、コンポーネントテストです。
ウェブページ1に掲載されているコンポーネントテストシナリオ:
- 無効なユーザーIDを入力し、エンドユーザーに分かりやすい警告が表示されることを確認してください。
- 無効なユーザーIDとパスワードを入力し、「リセット」をクリックして、ユーザーIDとパスワードのフィールドがクリアされていることを確認してください。
- 有効なユーザー名とパスワードを入力し、「ログイン」ボタンをクリックしてください。
ウェブページ2に掲載されているコンポーネントテストシナリオ:
- 管理者ページのウェルカムメッセージがホームページに表示されていることを確認してください。
- ウェブページの左側にあるすべてのリンクがクリック可能であることを確認してください。
- ホームページの中央にマネージャーIDが表示されていることを確認してください。
- 図に示すように、ホームページに3種類の画像が表示されていることを確認してください。
単体テストとコンポーネントテスト
以下の表は、2つのレベルが実際の業務においてどのように異なるかをまとめたものです。
| 単体テスト | コンポーネントテスト |
| 個々のプログラムおよびモジュールをテストし、プログラムが仕様どおりに実行されることを実証する。 | ソフトウェアの各オブジェクトまたは部分を、他のオブジェクトから分離する場合と分離しない場合の両方で、個別にテストする。 |
| 設計文書に基づいて検証済み。 | テスト要件およびユースケースに基づいて検証済み。 |
| 開発者によって行われました。 | テスターによって実施されました。 |
| まず最初に完了しました。 | 開発者側での単体テストが完了した後に実施します。 |
| 不具合は通常その場で修正され、正式に記録されることはない。 | 欠陥は記録され、 trac欠陥管理プロセスを通じて処理された。 |






