メニュー

統合テストとは（統合テストの例を含むチュートリアル）

what is integration testing

問題を排除するために楽器を試してください

統合テストとは：統合テストの例で学ぶ

統合テストは、統合時にモジュール/コンポーネントをテストして、それらが期待どおりに機能することを確認するために行われます。つまり、個別に正常に機能しているモジュールをテストしても、統合時に問題は発生しません。

ブラックボックステスト手法を使用して大規模なアプリケーションをテストするという観点から話す場合、互いに緊密に結合された多くのモジュールの組み合わせが含まれます。これらのタイプのシナリオをテストするために、統合テスト手法の概念を適用できます。

このシリーズでカバーされているチュートリアルのリスト：

チュートリアル＃1： 統合テストとは何ですか？ （このチュートリアル）
チュートリアル＃2： インクリメンタルテストとは
チュートリアル＃3： コンポーネントテストとは
チュートリアル＃4： 継続的インテグレーション
チュートリアル＃5 ユニットテストと統合の違い
チュートリアル＃6： トップ10統合テストツール

統合テストとは

学習内容：

統合テストとは何ですか？

統合テストの意味は非常に単純です- ユニットテストされたモジュールを1つずつ統合/結合し、結合されたユニットとして動作をテストします。

このテストの主な機能または目標は、ユニット/モジュール間のインターフェースをテストすることです。

通常、「ユニットテスト」の後に統合テストを行います。個々のユニットがすべて作成されてテストされたら、それらの「ユニットテスト済み」モジュールの組み合わせを開始し、統合テストの実行を開始します。

このテストの主な機能または目標は、ユニット/モジュール間のインターフェースをテストすることです。

個々のモジュールは、最初に個別にテストされます。モジュールの単体テストが完了すると、すべてのモジュールが統合されるまで1つずつ統合され、組み合わせの動作がチェックされ、要件が正しく実装されているかどうかが検証されます。

ここで、統合テストはサイクルの最後に行われるのではなく、開発と同時に行われることを理解する必要があります。そのため、ほとんどの場合、すべてのモジュールを実際にテストできるわけではありません。存在しないものをテストするための課題は次のとおりです。

なぜ統合テストなのか？

統合テストは複雑であり、ある程度の開発と論理的なスキルが必要であると感じています。それは本当だ！では、このテストをテスト戦略に統合する目的は何ですか？

ここにいくつかの理由があります：

  1. 現実の世界では、アプリケーションが開発されると、それはより小さなモジュールに分割され、個々の開発者には1つのモジュールが割り当てられます。ある開発者が実装するロジックは他の開発者とはかなり異なるため、開発者が実装するロジックが期待どおりであるかどうかを確認し、規定の基準に従って正しい値をレンダリングすることが重要になります。
  2. 多くの場合、データが1つのモジュールから別のモジュールに移動すると、データの面や構造が変化します。一部の値が追加または削除されるため、後のモジュールで問題が発生します。
  3. モジュールは、サードパーティのツールまたはAPIとも相互作用します。これらのツールは、そのAPI /ツールによって受け入れられたデータが正しいこと、および生成された応答も期待どおりであることをテストする必要があります。
  4. テストで非常に一般的な問題–頻繁な要件変更！ :)多くの場合、開発者は単体テストなしで変更をデプロイします。その際、統合テストが重要になります。

利点

このテストにはいくつかの利点があり、そのうちのいくつかを以下に示します。

  • このテストは、統合されたモジュール/コンポーネントが正しく機能することを確認します。
  • テストするモジュールが利用可能になったら、統合テストを開始できます。スタブとドライバーを同じように使用できるため、テストを実行するために他のモジュールを完了する必要はありません。
  • インターフェイスに関連するエラーを検出します。

課題

以下にリストされているのは、統合テストに関係するいくつかの課題です。

＃1） 統合テストとは、システムが正しく機能することを確認するために、2つ以上の統合システムをテストすることを意味します。統合リンクをテストするだけでなく、統合システムが正しく機能することを確認するために、環境を考慮した徹底的なテストを行う必要があります。

統合システムをテストするために適用できるさまざまなパスと順列が存在する可能性があります。

＃二） 統合テストの管理は、データベース、プラットフォーム、環境などのいくつかの要因が関係しているため、複雑になります。

＃3） 新しいシステムをレガシーシステムと統合する一方で、多くの変更とテスト作業が必要になります。 2つのレガシーシステムを統合する場合も同様です。

＃4） 2つの異なる会社によって開発された2つの異なるシステムを統合することは、いずれかのシステムに変更が加えられた場合に一方のシステムが他方のシステムにどのように影響するかについては大きな課題です。

システム開発時の影響を最小限に抑えるために、他のシステムとの統合の可能性など、考慮すべき点はほとんどありません。

統合テストの種類

以下に、テスト統合のタイプとその長所と短所を示します。

ビッグバンアプローチ：

ビッグバンアプローチでは、すべてのモジュールを一度に統合します。つまり、モジュールを1つずつ統合することはできません。システムが期待どおりに機能するか、統合されていないかを確認します。完全に統合されたモジュールで問題が検出されると、どのモジュールが問題の原因であるかを特定することが困難になります。

ビッグバンアプローチは、それ自体に欠陥があるモジュールを見つけるのに時間がかかるプロセスであり、欠陥が検出されると、それを修正すると、後の段階で欠陥が検出されるため、コストが高くなります。

ビッグバンアプローチ

ビッグバンアプローチの利点：

  • これは、小規模なシステムに適したアプローチです。

ビッグバンアプローチのデメリット：

  • 問題の原因となっているモジュールを検出することは困難です。
  • ビッグバンのアプローチでは、テストのためにすべてのモジュールをまとめて必要とします。これにより、設計、開発、統合にほとんどの時間がかかるため、テストにかかる時間が短縮されます。
  • テストは一度にのみ行われるため、重要なモジュールテストを単独で行う時間はありません。

統合テストの手順：

  1. 統合の準備 テスト計画。
  2. 統合テストシナリオとテストケースを準備します。
  3. テスト自動化スクリプトを準備します。
  4. テストケースを実行します。
  5. 欠陥を報告します。
  6. 欠陥を追跡して再テストします。
  7. 再テストとテストは、統合テストが完了するまで続きます。

テスト統合アプローチ

テスト統合を行うには、基本的に2つのアプローチがあります。

  1. ボトムアップアプローチ
  2. トップダウンアプローチ。

次の図を検討して、アプローチをテストしてみましょう。

統合1

ボトムアップアプローチ：

ボトムアップテストは、その名前が示すように、アプリケーションの最下位または最内部のユニットから始まり、徐々に上に移動します。統合テストは、最下位のモジュールから始まり、アプリケーションの上位のモジュールに向かって徐々に進行します。この統合は、すべてのモジュールが統合され、アプリケーション全体が単一のユニットとしてテストされるまで続きます。

この場合、モジュールB1C1、B1C2およびB2C1、B2C2は、単体テストされる最も低いモジュールです。モジュールB1とB2はまだ開発されていません。モジュールB1およびB2の機能は、モジュールB1C1、B1C2およびB2C1、B2C2を呼び出すことです。 B1とB2はまだ開発されていないため、B1C1、B1C2＆B2C1、B2C2モジュールを呼び出すプログラムまたは「スティミュレーター」が必要になります。これらの刺激プログラムは呼ばれます 運転手 。

簡単に言えば、 運転手 呼び出し元の関数が存在しない場合に、最下位のモジュールの関数を呼び出すために使用されるダミープログラムです。ボトムアップ手法では、モジュールドライバーがテストケース入力をテスト対象のモジュールのインターフェイスに供給する必要があります。

このアプローチの利点は、プログラムの最下位ユニットに重大な障害が存在する場合、それを検出しやすくなり、修正措置を講じることができることです。

欠点は、最後のモジュールが統合されてテストされるまで、メインプログラムが実際には存在しないことです。その結果、より高いレベルの設計上の欠陥は最後にのみ検出されます。

トップダウンアプローチ

この手法は、最上位のモジュールから始まり、徐々に下位のモジュールに向かって進みます。一番上のモジュールだけが単独でユニットテストされます。この後、下のモジュールが1つずつ統合されます。このプロセスは、すべてのモジュールが統合されてテストされるまで繰り返されます。

makefile c ++の作成

この図のコンテキストでは、テストはモジュールAから始まり、下位モジュールB1とB2が1つずつ統合されます。ここで、下位モジュールB1とB2は実際には統合できません。したがって、最上位のモジュールAをテストするために、「 スタブ 」。

「スタブ」は、最上位モジュールからの入力/要求を受け入れ、結果/応答を返すコードスニペットと呼ぶことができます。このように、下位のモジュールが存在しないにもかかわらず、上位のモジュールをテストすることができます。

実際のシナリオでは、スタブの動作は見た目ほど単純ではありません。モジュールと呼ばれる複雑なモジュールとアーキテクチャのこの時代では、ほとんどの場合、データベースへの接続などの複雑なビジネスロジックが関係しています。その結果、スタブの作成は実際のモジュールと同じくらい複雑で時間がかかります。場合によっては、スタブモジュールが刺激されたモジュールよりも大きいことが判明することがあります。

スタブとドライバーはどちらも、「存在しない」モジュールのテストに使用されるダミーのコードです。それらは関数/メソッドをトリガーし、期待される動作と比較される応答を返します

の違いをまとめましょう スタブとドライバー ：

スタブ運転者
トップダウンアプローチで使用ボトムアップアプローチで使用
最上位のモジュールが最初にテストされます最も低いモジュールが最初にテストされます。
下位レベルのコンポーネントを刺激しますより高いレベルのコンポーネントを刺激します
下位レベルのコンポーネントのダミープログラム高レベルコンポーネントのダミープログラム

唯一の変化はこの世界では一定であるため、「 サンドイッチテスト トップダウンとボトムアップの両方のアプローチの機能を組み合わせた」。オペレーティングシステムのような巨大なプログラムをテストするときは、効率的で自信を高めるいくつかのテクニックが必要です。ここでは、サンドイッチテストが非常に重要な役割を果たし、トップダウンテストとボトムアップテストの両方が同時に開始されます。

統合は中間層から始まり、同時に上下に移動します。この図の場合、テストはB1とB2から開始され、一方のアームが上部モジュールAをテストし、もう一方のアームが下部モジュールB1C1、B1C2＆B2C1、B2C2をテストします。

両方のアプローチが同時に開始されるため、この手法は少し複雑で、特定のスキルセットとともにより多くの人員を必要とし、コストが増加します。

GUIアプリケーション統合テスト

それでは、ブラックボックス手法で統合テストを暗示する方法について説明しましょう。

Webアプリケーションが多層アプリケーションであることは誰もが理解しています。ユーザーに表示されるフロントエンド、ビジネスロジックを持つ中間層、検証を行う中間層、サードパーティのAPIの統合などがあり、その後、バック層があります。データベース。

統合テストの例：

以下の例を確認してみましょう：

私は広告会社のオーナーであり、さまざまなWebサイトに広告を掲載しています。月末に、私の広告を見た人の数と、私の広告をクリックした人の数を確認したいと思います。表示された広告のレポートが必要で、それに応じてクライアントに請求します。

GenNextソフトウェア 私のためにこの製品を開発しました。以下はアーキテクチャです。

統合2

玉ねぎ –エンドユーザーに表示されるユーザーインターフェイスモジュール。すべての入力が提供されます。
BL –は、すべての計算とビジネス固有のメソッドをすべて備えたビジネスロジックモジュールです。
VAL –入力の正しさのすべての検証を含む検証モジュールです。
CNT –ユーザーが入力した入力に固有の、すべての静的コンテンツを含むコンテンツモジュールです。これらの内容はレポートに表示されます。
に –エンジンモジュールです。このモジュールは、BL、VAL、およびCNTモジュールからのすべてのデータを読み取り、SQLクエリを抽出して、データベースにトリガーします。
スケジューラー –は、ユーザーの選択に基づいてすべてのレポートをスケジュールするモジュールです（月次、四半期、半年ごと、および年次）
DB –はデータベースです。

ここで、Webアプリケーション全体のアーキテクチャを単一のユニットとして見てきたので、この場合の統合テストでは、モジュール間のデータの流れに焦点を当てます。

ここでの質問は次のとおりです。

  1. BL、VAL、およびCNTモジュールは、UIモジュールに入力されたデータをどのように読み取って解釈しますか？
  2. BL、VAL、およびCNTモジュールはUIから正しいデータを受信して​​いますか？
  3. BL、VAL、CNTのデータはどのフォーマットでEQモジュールに転送されますか？
  4. EQはどのようにデータを読み取り、クエリを抽出しますか？
  5. クエリは正しく抽出されていますか？
  6. スケジューラはレポートの正しいデータを取得していますか？
  7. ENがデータベースから受け取った結果セットは正しく、期待どおりですか？
  8. ENは応答をBL、VAL、およびCNTモジュールに送り返すことができますか？
  9. UIモジュールはデータを読み取ってインターフェースに適切に表示できますか？

現実の世界では、データの通信はXML形式で行われます。したがって、ユーザーがUIに入力するデータはすべて、XML形式に変換されます。

このシナリオでは、UIモジュールに入力されたデータは、3つのモジュールBL、VAL、およびCNTによって解釈されるXMLファイルに変換されます。 ENモジュールは、3つのモジュールによって生成された結果のXMLファイルを読み取り、そこからSQLを抽出して、データベースに照会します。 ENモジュールは、結果セットも受信してXMLファイルに変換し、UIモジュールに返します。UIモジュールは、結果をユーザーが読み取り可能な形式に変換して表示します。

真ん中には、ENモジュールから結果セットを受け取り、レポートを作成してスケジュールするスケジューラモジュールがあります。

では、統合テストはどこにあるのでしょうか。

さて、情報/データが正しく流れているかどうかをテストすることは、統合テストになります。この場合、XMLファイルを検証します。 XMLファイルは正しく生成されていますか？彼らは正しいデータを持っていますか？データはあるモジュールから別のモジュールに正しく転送されていますか？これらはすべて、統合テストの一部としてテストされます。

XMLファイルを生成または取得し、タグを更新して、動作を確認してください。これは、テスターが通常行う通常のテストとは非常に異なるものですが、これにより、テスターの知識とアプリケーションの理解に価値が加わります。

他のいくつかのサンプルテスト条件は次のとおりです。

  • メニューオプションは正しいウィンドウを生成していますか？
  • ウィンドウはテスト中のウィンドウを呼び出すことができますか？
  • すべてのウィンドウについて、アプリケーションが許可する必要があるウィンドウの関数呼び出しを特定します。
  • ウィンドウからアプリケーションが許可する必要がある他の機能へのすべての呼び出しを識別します
  • リバーシブルコールを識別します。呼び出されたウィンドウを閉じると、呼び出しウィンドウに戻るはずです。
  • 不可逆的な呼び出しを特定する：呼び出されたウィンドウが表示される前に、呼び出しウィンドウが閉じます。
  • 別のウィンドウへの呼び出しを実行するさまざまな方法をテストします。 –メニュー、ボタン、キーワード。

統合テストを開始する手順

  1. アプリケーションのアーキテクチャを理解します。
  2. モジュールを特定する
  3. 各モジュールの機能を理解する
  4. あるモジュールから別のモジュールにデータがどのように転送されるかを理解します。
  5. データがシステムにどのように入力および受信されるかを理解します（アプリケーションのエントリポイントとエグジットポイント）
  6. テストのニーズに合わせてアプリケーションを分離します。
  7. テスト条件を特定して作成します
  8. 一度に1つの条件を取り、テストケースを書き留めます。

統合テストの開始/終了基準

エントリー基準：

  • 統合テスト計画文書は承認され、承認されます。
  • 統合テストケースが用意されています。
  • テストデータが作成されました。
  • ユニットテスト 開発されたモジュール/コンポーネントの完了です。
  • 重大で優先度の高い欠陥はすべてクローズされます。
  • テスト環境は統合用にセットアップされています。

終了基準：

  • すべての統合テストケースが実行されました。
  • 重大で優先度の高いP1およびP2の欠陥は開かれていません。
  • テストレポートを作成しました。

統合テストケース

統合テストケースは主に モジュール間のインターフェース、統合リンク、データ転送 すでにユニットテストされているモジュール/コンポーネントとしてのモジュール間、つまり機能と他のテストの側面はすでにカバーされています。

したがって、主なアイデアは、2つの作業モジュールの統合が統合時に期待どおりに機能するかどうかをテストすることです。

Linkedinアプリケーションの統合テストケースの例には、次のものが含まれます。

  • ログインページとホームページの間のインターフェイスリンクを確認します。つまり、ユーザーが資格情報を入力してログに記録するときに、ホームページに移動する必要があります。
  • ホームページとプロファイルページ、つまりプロファイルページ間のインターフェイスリンクを確認すると、開くはずです。
  • ネットワークページと接続ページの間のインターフェイスリンクを確認します。つまり、(ネットワークページの招待)の(承認)ボタンをクリックすると、クリックすると接続ページに承認済みの招待が表示されます。
  • 通知ページと「おめでとう」ボタンの間のインターフェースリンクを確認します。つまり、「おめでとう」ボタンをクリックすると、新しいメッセージウィンドウが表示されます。

この特定のサイト用に、多くの統合テストケースを作成できます。上記の4つのポイントは、テストに含まれる統合テストケースを理解するための単なる例です。

統合はホワイトボックスまたはブラックボックスの手法ですか？

統合テスト手法は、ブラックボックスとブラックボックスの両方でカウントできます。 ホワイトボックステクニック 。 ブラックボックステクニック テスターがシステムの内部知識を持っている必要がない場合、つまりコーディングの知識は必要ありませんが、ホワイトボックス技術はアプリケーションの内部知識を必要とします。

統合テストの実行中に、データベースからデータをフェッチし、必要に応じてデータを提供する2つの統合Webサービスのテストを含めることができます。つまり、ホワイトボックステスト手法を使用してテストできますが、Webサイトに新しい機能を統合してテストできます。ブラックボックス技術を使用します。

したがって、統合テストがブラックボックスまたはホワイトボックスの手法であるかどうかは特定されていません。

統合テストツール

このテストに使用できるツールはいくつかあります。

以下にツールのリストを示します。

  • Rational Integration Tester
  • 分度器
  • 蒸気
  • テッシー

上記のツールの詳細については、このチュートリアルを確認してください。

統合テストを作成するための統合テストツールトップ10

システム統合テスト

システム統合テストは、 完全な統合システム 。

モジュールまたはコンポーネントは、コンポーネントを統合する前に、単体テストで個別にテストされます。

すべてのモジュールがテストされると、すべてのモジュールを統合することによってシステム統合テストが実行され、システム全体がテストされます。

統合テストとシステムテストの違い

統合テストは、単体テストされた1つまたは2つのモジュールを統合してテストし、統合されたモジュールが期待どおりに機能するかどうかを検証するための検証を行うテストです。

システムテストは、 システム全体 テストされます。つまり、すべてのモジュール/コンポーネントが統合されて、システムが期待どおりに機能し、統合されたモジュールが原因で問題が発生しないかどうかを確認します。

結論

これはすべて、統合テストと、ホワイトボックスとブラックボックスの両方の手法での実装に関するものです。関連する例で明確に説明したことを願っています。

テスト統合は、最初のステップ自体ですべてのモジュールを統合するために2つ以上のモジュールが統合されている場合に欠陥を見つけやすくするため、テストサイクルの重要な部分です。

欠陥を早期に発見するのに役立ち、その結果、労力とコストも節約できます。これにより、統合モジュールが期待どおりに正しく機能することが保証されます。

統合テストに関するこの有益なチュートリアルが、概念の知識を深めることを願っています。

推奨読書

^