コンポーネントテストとは? テクニック、テストケースの例

⚡ スマートサマリー

コンポーネントテストでは、アプリケーションの各部分を他の部分と統合することなく個別にチェックし、アセンブリを開始する前に単一モジュール内で欠陥を発見して修正します。

  • 🧩 範囲: 一度に1つのコンポーネントを、周囲のコンポーネントから隔離して処理する。
  • 👥 オーナー: 開発者が単体テストを完了した後、テスターがそれを実行します。
  • 🔬 CTIS: 小規模なコンポーネントテストでは、コンポーネントを完全に分離します。
  • 🔗 CTIL: 大規模コンポーネントテストでは、実際の依存関係またはシミュレーションされた依存関係を維持します。
  • 🧱 Doubles: ドライバがコンポーネントを呼び出し、スタブがドライバによって呼び出される。
  • 終了: ログには、重大度、高、中程度の欠陥は残っていません。

コンポーネントテストの手法とテストケース例

コンポーネントテストとは何ですか?

コンポーネントテスト これは、他のコンポーネントと統合せずに、個々のコンポーネントごとに個別にテストを実行するソフトウェアテストの種類です。アーキテクチャの観点から見ると、 モジュールテストまた、一部の文献ではこれをプログラムテストと呼んでいます。

ソフトウェア全体は複数のコンポーネントで構成されており、コンポーネントレベルのテストはそれらのコンポーネントを個別にテストするものです。これは最も頻繁に行われるテストの1つです。 ブラックボックステスト QAチームが実施した各種処理。

命名に関する注意点を最初に述べておく価値がある。ISTQB 用語集では、コンポーネント テストと 単体テスト 同じテストレベルの同義語として使われることがありますが、多くの開発チーム、そしてこの記事でも、実際には両者を区別しています。開発者は自身のコードに対して単体テストを実行し、テスターは納品されたビルドに対してコンポーネントテストを実行します。この記事の末尾にある比較表で、その実際的な区別を示しています。

下の図に示すように、コンポーネントテストには独自のテスト戦略とテスト計画があり、ソフトウェアまたはアプリケーションの各部分が個別に検討されます。各コンポーネントについて、 テストシナリオ が定義され、それが高レベルのテストケースに分解され、最終的に低レベルの詳細なテストケースに分解されます。 テストケース 前提条件あり。

テスト戦略から低レベルのテストケースまで、コンポーネントのテスト階層構造

「コンポーネントテスト」という用語の使い方は、分野や組織によって異なります。こうした認識の違いが生じる最も一般的な理由は、以下の3点です。

  1. 選択された開発ライフサイクルモデルの種類
  2. テスト対象のソフトウェアまたはアプリケーションの複雑さ
  3. テストがアプリケーション内の他のコンポーネントから分離して行われるか、分離せずに行われるか

ソフトウェアテストのライフサイクルでは、多くのテスト成果物、つまりテスト活動中に作成および使用されるドキュメントが生成されます。その中でも、テストポリシーとテスト戦略は、特定のプロジェクトにおいてどのような種類のテストが使用され、テストがどの程度の深さまで行われるかを定義します。

コンポーネントのテストを行うのは誰ですか

コンポーネントテストはテスターが実施します。ユニットテストは開発者が実施し、個々の機能や手順をテストします。ユニットテストが完了すると、コンポーネントテストが開始され、テスターがその責任を引き継ぎます。

コンポーネントテストをいつ実行するか

コンポーネントテストは、開発者による単体テストが完了し、ビルドがテストチームにリリースされた直後に実施されます。このビルドはUTビルド、つまり単体テストビルドと呼ばれます。このフェーズでは、各コンポーネントの主要な機能がテストされます。

コンポーネントテストの開始基準

  • UTビルドに含めるべき最小限のコンポーネントセットが開発され、単体テストが実施されました。

コンポーネントテストの終了基準

  • すべてのコンポーネントの機能は仕様どおりに動作します。
  • 重大度、高、中程度の深刻度または優先度の欠陥は残っていません。 不具合ログ.

コンポーネントのテスト手法

テストレベルの深さに基づいて、コンポーネントテストは2つの方法で分類されます。

  1. CTIS — 小規模なコンポーネントのテスト
  2. CTIL — 大規模コンポーネントテスト

CTIS — 小規模なコンポーネントのテスト

コンポーネントテストは、テスト対象アプリケーション内の他のコンポーネントから隔離して実施することも、隔離せずに実施することも可能です。他のコンポーネントを隔離して実施する場合、それは小規模コンポーネントテストと呼ばれます。

例1: 5つの異なるウェブページを持つウェブサイトでは、各ウェブページを他のコンポーネントから切り離して個別にテストすることは、小規模なコンポーネントテストです。

例2: 以下に示す guru99.com のホームページには、ホーム、テスト、 SAPウェブ、必修科目!、ビッグデータ、ライブプロジェクト、ブログ。

Guru99 ホームページのナビゲーションメニューは、個別のテスト可能なコンポーネントとして扱われます。

どのようなソフトウェアも同様に多くのコンポーネントで構成されており、各コンポーネントには独自のサブコンポーネントがあります。例2に挙げた各モジュールを、他のコンポーネントとの統合を考慮せずに個別にテストすることは、コンポーネントテストの簡略化と言えます。

テストのドロップダウンメニューを開くと、テストコンポーネントのサブコンポーネントが表示されます。 手動テストSOAPUI、 QTP, JUnit, Seleniumテスト管理と モバイルテスト下のスナップショットでは、それらのサブコンポーネントが赤色で強調表示されています。

サブコンポーネントが赤色で強調表示されたテスト用ドロップダウンメニュー

CTIL — 大規模コンポーネントテスト

テスト対象アプリケーション内の他のコンポーネントから分離せずに実施されるコンポーネントテストは、大規模コンポーネントテストと呼ばれます。

例を挙げると、その違いがより明確になります。アプリケーションがコンポーネントA、コンポーネントB、コンポーネントCの3つのコンポーネントで構成されているとします。

開発者はコンポーネントBを作成し、テストを希望しています。コンポーネントBを完全にテストするには、その機能の一部がコンポーネントAに依存し、一部がコンポーネントCに依存している必要があります。下の図を参照してください。

コンポーネントBは、コンポーネントAをドライバに置き換え、コンポーネントCをスタブに置き換えてテストした。

機能の流れは A → B → C であり、これはコンポーネント B が A と C の両方に依存していることを意味します。この流れにおいて、スタブは呼び出される関数であり、ドライバは呼び出し元の関数です。

コンポーネントAとコンポーネントCはまだ開発されていません。コンポーネントBを完全にテストするために、必要に応じてAとCをドライバとスタブに置き換え、実際のコンポーネントが完成するまで、不足している2つのコンポーネントはダミーオブジェクトとして機能します。

  • スタブ: スタブは、テスト対象のコンポーネントによって呼び出されます。コンポーネントCが準備できていないため、スタブが代わりに動作し、コンポーネントBが期待する応答を返します。
  • ドライバ: ドライバはテスト対象のコンポーネントを呼び出します。コンポーネントAが準備できていないため、ドライバが代わりにコンポーネントBを呼び出し、必要な入力値を渡します。

コンポーネントテストのテストケースの例

以下の2つのウェブページは機能的な観点から相互に関連しており、テスト対象として有用なペアとなっています。

ウェブページ1は、デモ用銀行サイトのログインページです。

ユーザーIDとパスワード入力欄を備えたログインページコンポーネント

ユーザーが有効なユーザーIDとパスワードを入力して送信ボタンをクリックすると、次に示すデモ銀行ウェブサイトのホームページに移動します。

ナビゲーションリンクと画像を含むマネージャーホームページコンポーネント

ここでは、ログインページは1つのコンポーネントであり、ホームページは別のコンポーネントです。それぞれのページの機能を個別にテストすることが、コンポーネントテストです。

ウェブページ1に掲載されているコンポーネントテストシナリオ:

  • 無効なユーザーIDを入力し、エンドユーザーに分かりやすい警告が表示されることを確認してください。
  • 無効なユーザーIDとパスワードを入力し、「リセット」をクリックして、ユーザーIDとパスワードのフィールドがクリアされていることを確認してください。
  • 有効なユーザー名とパスワードを入力し、「ログイン」ボタンをクリックしてください。

ウェブページ2に掲載されているコンポーネントテストシナリオ:

  • 管理者ページのウェルカムメッセージがホームページに表示されていることを確認してください。
  • ウェブページの左側にあるすべてのリンクがクリック可能であることを確認してください。
  • ホームページの中央にマネージャーIDが表示されていることを確認してください。
  • 図に示すように、ホームページに3種類の画像が表示されていることを確認してください。

単体テストとコンポーネントテスト

以下の表は、2つのレベルが実際の業務においてどのように異なるかをまとめたものです。

単体テスト コンポーネントテスト
個々のプログラムおよびモジュールをテストし、プログラムが仕様どおりに実行されることを実証する。 ソフトウェアの各オブジェクトまたは部分を、他のオブジェクトから分離する場合と分離しない場合の両方で、個別にテストする。
設計文書に基づいて検証済み。 テスト要件およびユースケースに基づいて検証済み。
開発者によって行われました。 テスターに​​よって実施されました。
まず最初に完了しました。 開発者側での単体テストが完了した後に実施します。
不具合は通常その場で修正され、正式に記録されることはない。 欠陥は記録され、 trac欠陥管理プロセスを通じて処理された。

よくあるご質問

リスクの低減、コンポーネントの機能的および非機能的動作の検証、品質への信頼の構築、欠陥の発見、およびそれらの欠陥の拡大防止ping より高いテストレベルへ。

モデルはコンポーネントを読み取りますtract は、手動によるチェックでは見落としがちな無効な入力、境界値、エラーパスを提案します。テスターは、実行前にすべての期待される結果を確認します。

はい。定型応答を返すスタブと、固定入力を与えるドライバは、アシスタントが素早く作成する定型的なコードです。どの応答が現実的かを判断するのは、依然として人間の判断です。

コンポーネントテストは、1つのコンポーネントを単独で検査します。 統合テスト コンポーネント間のインターフェースと相互作用を検証し、コンポーネントのテスト後に実行されます。

Codeレベルのフレームワークなど JUnit, TestNGNUnitやpytest、さらにUIコンポーネントランナーなど Cypress コンポーネントテスト、Storybook、Jest。これらはすべて、 オートメーション パイプライン。

ダブルの構築と維持。実際のコンポーネントから乖離したスタブは、統合されるまで欠陥を隠蔽するため、実際の依存関係が出荷されたら、すべてのシミュレーション応答を再検討する必要があります。

これは順序を逆にした方法です。コンポーネントが存在する前にテストケースが作成され、自動化され、その後、テストが合格するまでコードが追加されます。コンポーネントは、テストスイートが既に用意された状態で納品されます。

どちらも、誰が実行するかによります。テスターはコンポーネント仕様に対してブラックボックステストを行い、コードにアクセスできる開発者は 白い箱 同一コンポーネント内のカバレッジ。