インテグレーションテストとは？初心者向けガイド：インテグレーションテストの基本と実例共起語・同意語・対義語も併せて解説！

この記事を書いた人

岡田康介

名前：岡田康介（おかだこうすけ）ニックネーム：コウ、または「こうちゃん」年齢：28歳性別：男性職業：ブロガー（SEOやライフスタイル系を中心に活動）居住地：東京都（都心のワンルームマンション）出身地：千葉県船橋市身長：175cm 血液型：O型誕生日：1997年4月3日趣味：カフェ巡り、写真撮影、ランニング、読書（自己啓発やエッセイ）、映画鑑賞、ガジェット収集性格：ポジティブでフランク、人見知りはしないタイプ。好奇心旺盛で新しいものにすぐ飛びつく性格。計画性がある一方で、思いついたらすぐ行動するフットワークの軽さもある。 1日（平日）のタイムスケジュール 7:00 起床：軽くストレッチして朝のニュースをチェック。ブラックコーヒーで目を覚ます。 7:30 朝ラン：近所の公園を30分ほどランニング。頭をリセットして新しいアイデアを考える時間。 8:30 朝食＆SNSチェック：トーストやヨーグルトを食べながら、TwitterやInstagramでトレンドを確認。 9:30 ブログ執筆スタート：カフェに移動してノートPCで記事を書いたり、リサーチを進める。 12:30 昼食：お気に入りのカフェや定食屋でランチ。食事をしながら読書やネタ探し。 14:00 取材・撮影・リサーチ：街歩きをしながら写真を撮ったり、新しいお店を開拓してネタにする。 16:00 執筆＆編集作業：帰宅して集中モードで記事を仕上げ、SEOチェックやアイキャッチ作成も行う。 19:00 夕食：自炊か外食。たまに友人と飲みに行って情報交換。 21:00 ブログのアクセス解析・改善点チェック：Googleアナリティクスやサーチコンソールを見て数字を分析。 22:00 映画鑑賞や趣味の時間：Amazonプライムで映画やドラマを楽しむ。 24:00 就寝：明日のアイデアをメモしてから眠りにつく。

インテグレーションテストとは？

インテグレーションテストとは、ソフトウェアの部品同士がうまく連携して動くかを確かめるテストのことです。ユニットテストで部品を一つずつ動かすのに対して、部品同士のつながりを検証します。例えば、ユーザーが「ログイン」ボタンを押したときに、認証サービスが正しく動作してデータベースと連携できるかを確認します。

ユニットテストとインテグレーションテストの違い

ユニットテストは「小さな部品」を検証します。インテグレーションテストは「複数の部品がつながって動くか」を検証します。システム全体を一度に見る「システムテスト」との違いも覚えておくと良いです。

なぜインテグレーションテストが必要か

部品同士の連携には、データ形式のずれ、タイミングの問題、エラーの伝播などが起きやすいです。個別にテストしても見えにくい、接続部分の不具合を探すのがインテグレーションテストの役割です。

実施の基本的な流れ

ステップ1. 設計：どの部品を組み合わせてテストするか、どのような入力でどういう出力を期待するかを決めます。

ステップ2. 環境の準備：テスト用のデータやモック、スタブ、テスト用の環境を用意します。

ステップ3. テストケースの作成：現実的なシナリオをいくつか作り、入出力を決めます。

ステップ4. 実行と検証：テストケースを実行し、期待通り動くかを確認します。不具合が出れば、原因を部品間の接続に絞って修正します。

実例

例として、ウェブアプリの「認証＋ユーザー情報取得」の流れを見てみましょう。ユーザーがログインすると、認証サービスがパスワードをチェックし、成功すればトークンを返します。そのトークンを使って、別のサービスがデータベースからユーザー情報を取得します。インテグレーションテストでは、これらの連携が正しく行われ、想定どおりのトークンと情報が返るかを確認します。

able> 項目内容対象システム認証サービスとユーザーデータサービスの連携目的部品間のデータ連携とエラー伝播を検証入力データ正しいユーザーIDとパスワード、トークン要求期待される出力有効なトークンとユーザーデータの取得 ble>

自動化とツール

実務では自動化が大切です。継続的インテグレーション（CI）と組み合わせて、コードが変わるたびにテストが走るようにします。テストは言語や環境に合わせたツールで作成します。人力でのテストも重要ですが、時間を節約するために自動テストを活用しましょう。

よくある誤解

よくある誤解として、「インテグレーションテストは全ての組み合わせを試すべき」ではない、という点があります。組み合わせを網羅すると時間がかかるので、リスクの高い接続や頻繁に変わるインターフェースを優先します。

また、モックやスタブを使いすぎると実際の連携が再現できず、現場で役に立たない場合があります。適切なレベルのモックを使うことが大切です。

テスト環境の注意点

実運用と同じデータ形式・プロトコルを使うことが重要です。データの量は少なくても、エッジケース（空データ、長い文字列、特殊文字）を含めると効果が上がります。

まとめ

インテグレーションテストは「部品同士のつながり」を確かめる重要な工程です。小さな部品の品質だけでなく、連携部分の動作を検証することで、製品全体の品質を高められます。

インテグレーションテストの同意語

インテグレーションテスト: 複数の部品（モジュール・コンポーネント）が正しく連携して動作するかを検証するテスト。ユニットテストの後に行い、部品間のインターフェースやデータの流れ、境界条件、エラーハンドリングなどを確認します。
統合テスト: 複数の部品を組み合わせた状態で、システム全体として正しく機能するかを検証するテストです。部品間の接続・データのやり取り・異常系の挙動などを重点的に確認します。
結合テスト: 部品同士の接続・連携部分を中心に、モジュール間のインターフェースが正しく機能するかを検証するテストです。ユニットテストの次の段階として、相互作用の正しさを重視します。
統合検証: 統合された構成が仕様要件を満たしているかを検証する表現です。動作の正確性・要件適合性を確認する目的で実施します。
結合検証: 結合テストと同様に、部品の組み合わせが要件どおり機能するかを確認する検証作業です。仕様通りの動作を満たすかを評価します。

インテグレーションテストの対義語・反対語

ユニットテスト: インテグレーションテストが複数部品の連携を検証するのに対し、ユニットテストは個々の部品（関数・クラスなど）を分離して機能を検証するテストです。部品単位の正しさを早期に保証します。
単体テスト: ユニットテストとほぼ同義の呼称。小さな単位の機能を独立して検証する目的は同じです。
モジュールテスト: モジュール（機能のまとまり）単位で検証します。複数モジュールの連携は対象外に近く、境界の不具合を見つけることが主眼です。
コンポーネントテスト: ソフトウェアを構成する部品（コンポーネント）ごとに動作を検証します。統合テストより粒度が細いケースが多く、UI部品の検証にも使われます。
ホワイトボックステスト: 内部実装（コードの構造・分岐）を前提に検証するテスト。設計や実装の瑕疵を早期に発見しやすい点が特徴です。
ブラックボックステスト: 内部実装を意識せず、仕様どおりの振る舞いを検証するテスト。外部からの入力と出力だけで判断します。
エンドツーエンドテスト: ユーザー視点でシステム全体の動作を検証するテスト。全体の振る舞いを包括的に確認する目的で用いられます。
システムテスト: システム全体を対象に要件通りに動作するかを検証するテスト。実運用環境に近い条件での検証が中心です。
受け入れテスト: 顧客要件やビジネス要件を満たしているかを確認するテスト。最終的な受け入れ判断の根拠として用いられます。

インテグレーションテストの共起語

統合テスト: 複数のモジュールやサービスが正しく連携して動作するかを検証する基本的なテスト。
API統合テスト: API間の連携が仕様通り動くかを検証するテスト。
契約テスト: サービス間の契約（API仕様やデータ形式）に沿って連携が正しく機能するかを検証。
エンドツーエンドテスト: システム全体を通してビジネス機能が最終的に正しく動作するかを検証。
モック: 実際の外部依存を模倣するためのテストダブル。
スタブ: 呼び出し元の返答を固定して返す簡易な置き換え。
テストダブル: 実際の依存を代替する総称。
ダミー: 実在の機能の代替として使う簡易オブジェクト。
データベース統合テスト: アプリとデータベースの連携でデータの読み書きや整合性、トランザクションが正しく動くかを検証。
メッセージング統合テスト: メッセージキューやイベントの送受信・処理の連携を検証。
サービス間連携: 複数のサービスが連携して処理を進められるかを検証。
依存関係: 外部サービスやモジュールへの依存が正しく構成・管理されているかを評価。
インターフェース検証: API仕様やインターフェース契約に沿って機能が連携するかを確認。
テスト環境: テスト専用の環境を用意して実行すること。
CI/CD: 継続的インテグレーション/デリバリーのワークフローで自動的にテストを実行。
テスト自動化: 人手を介さず自動でテストを実行すること。
テストケース: 検証の手順と期待結果を具体化したもの。
テストスイート: 複数のテストケースをまとめた集合。
回帰テスト: 修正後に既存機能が壊れていないかを確認するためのテスト。
ログと監視: テスト実行時のログを収集・監視して原因を特定しやすくする。
テストデータ: テストに使う入力データのこと。
テストデータ管理: テストデータの作成・管理・保守を行うこと。
環境パリティ: 開発・検証・本番環境の差を最小化することで再現性を高める考え方。
テスト計画: テストの目的・範囲・スケジュールなどを整理する計画。
デプロイ前統合テスト: デプロイ前に実施する統合テストで結合の問題を早期発見。
テストフレームワーク: テスト作成・実行を支えるツールと枠組み（例：JUnit、pytest）
テストハーネス: テストを実行する際の土台となるコード/設定。
カバレッジ: 統合テストがどの程度のコードや機能を検証しているかの指標。
データ整合性: 連携後のデータが整合性を保っているかを検証。
セキュリティ統合テスト: 認証・認可、データ保護などセキュリティ要件が連携で満たされるかを検証。
パフォーマンステスト: 統合後の処理性能やスループットが要件を満たすかを検証。
異常系検証: エラーハンドリングや障害時の挙動を検証。
テストデータクレンジング: 使い終わったテストデータを削除・匿名化する作業。

インテグレーションテストの関連用語

インテグレーションテスト: 複数のモジュールやサービスが正しく連携して動作するかを検証するテスト。モジュール間のインターフェースやデータの受け渡し、エラーハンドリングが適切かを確認します。
結合テスト: モジュール同士が結合された状態で、相互の連携とデータの流れが正しく機能するかを検証するテスト。ユニットテストの後段として位置づけられることが多いです。
エンドツーエンドテスト: システム全体のワークフローを、最初の入力から最終出力まで一連の動作として検証するテスト。ユーザー視点の機能が正しく動くかを確認します。
APIテスト: 公開APIの機能、仕様に沿った入出力、認証・認可、エラーハンドリングを検証するテスト。RESTやGraphQLなどのインターフェースを対象にします。
コンポーネントテスト: 個々のコンポーネントが単体としてだけでなく、周囲と連携する中で正しく動くかを検証するテスト。
契約テスト: サービス間の契約（インターフェース・データ形式・メッセージの仕様）に基づき、相互作用が期待どおりに動くかを検証するテスト。Pactなどの手法を用いることがあります。
ステージングテスト: 本番環境に近いステージング環境で、実運用を想定した動作を検証するテスト。
ユニットテスト: 個々の関数・クラスなど最小単位の機能が正しく動作するかを検証するテスト。
テストダブル: 実際の依存を置き換えるための道具の総称。モック・スタブ・ダミー・フェイクなどを含みます。
モック: 呼び出しの有無・回数・引数を検証できるように、依存を完全に模倣する代替物。
スタブ: 返答を固定して返す、依存の振る舞いを簡略化する代替物。
ダミー: テストで使われるが機能はなく、データ構造としてクラス/オブジェクトを満たすだけ。
フェイク: 簡易実装の代替物。実装は簡素だが実用的な挙動を提供します。
テストドライバー: 呼び出し元を生成・制御するテスト用のコード。テスト対象の準備を補助します。
テストデータ: テストで使用する入力データ。現実的なケースを再現するために作成します。
テスト環境: テストを実施するための専用サーバ・データベース・設定などの環境。
テストケース: 特定の入力・条件・期待結果を記述した、個々のテスト手順。
テスト計画: テストの目的・範囲・方針・スケジュールを定義する文書。
テスト自動化: 繰り返し実行可能なテストを自動で実行・結果を報告する仕組み。
継続的インテグレーション: 開発者の変更を頻繁に統合して、自動ビルドと自動テストを行う開発手法。
CI/CD: 継続的インテグレーションと継続的デリバリー/デプロイを組み合わせた運用。テスト自動化とデプロイを連携します。
テストカバレッジ: テストが対象コードのどの程度を網羅しているかを示す指標。
ログ収集: テスト実行中のログを集め、挙動の追跡・原因特定を容易にする取り組み。
モニタリング: テスト導入後の実行状況を監視し、異常を検知する活動。
トレーサビリティ: 要件とテストケースの対応付けを追跡できる状態。要件追跡性とも呼ばれます。
依存関係: テスト対象のモジュールが依存する他のモジュール・サービスの関係を把握すること。
インターフェース契約: 互いのインターフェース仕様（データ形式・タイミング・エラーコード）を取り決めた契約。
APIゲートウェイ: 複数のAPIを統合して外部に公開するエントリポイント。統合テストにも影響します。
ミドルウェア: アプリケーションとデータベース・サービス間の連携を担うソフトウェア。連携点を検証対象とします。
データ整合性: 複数のモジュール間でデータが矛盾なく一貫している状態を検証。
データベース連携: アプリとデータベースの間の操作・整合性・パフォーマンスを検証。
メッセージング: キューやトピックを介した非同期連携の動作を検証。
イベント駆動: イベント発生と処理の流れが適切に連携するかを検証。
トップダウン統合テスト: 上位レベルの設計から段階的に統合して検証する手法。
ボトムアップ統合テスト: 下位レベルの部品から組み上げて上位へと統合して検証する手法。
サンドイッチ統合テスト: 上位・下位を組み合わせた中間的アプローチで検証する手法。
失敗シナリオ: 障害を想定したケースを設計・検証する。
回帰テスト: 変更後に既存機能が壊れていないかを確認する再実行テスト。
境界値分析: 境界条件の値で挙動が崩れないかを検証。
境界条件: 境界近辺のデータや状態での動作を検証。
回復とリトライ: 障害時の回復・再試行の振る舞いを検証。
デプロイメント: テスト環境から本番環境へ移行する際の手順と挙動を検証。
テスト実行報告: テストの実行結果をまとめた報告書・ログ。