テスト自動化の種類まとめ｜単体・結合・E2E・APIテストの違いと使い分け

🐙 ソースコードはこちら GitHub — automated-testing-portfolio 💼 仕事のご依頼はこちら LinkedIn — Yoshitsugu Baba

テスト自動化には主に「単体テスト」「APIテスト」「結合テスト」「UIテスト（E2E）」など複数の種類があり、目的やテスト対象によって適切な方法を使い分けることが重要です。

📌 この記事はこんな方におすすめ

  • テスト自動化を始めたいが、何から手をつければよいかわからない方
  • 単体・結合・E2E・APIテストの違いをきちんと整理したいエンジニア
  • チームにテスト自動化を導入するにあたって種類を説明する必要がある方
  • テストピラミッドという概念を実務で活かしたいQA担当者

✅ この記事を読むとわかること

  • 単体・結合・E2E・APIテストそれぞれの目的と特徴
  • 4種類のテストをどう組み合わせるか（テストピラミッド）
  • 各テストに向いているツールと使いどころ
  • 実務でどのテストから自動化すべきか

👤

この記事を書いた人：QAエンジニアとしてSelenium・Playwright・pytest・requestsを使ったテスト自動化を実務で担当。単体からE2Eまで複数の種類のテストを組み合わせた自動化設計の経験をもとに解説します。GitHubでコードも公開中。

📌 この記事の結論

テスト自動化の種類は大きく4つ——単体・結合・E2E・APIテスト。それぞれ守備範囲・速度・コストが異なります。「テストピラミッド」の考え方に沿って組み合わせることで、品質を最大化しながらコストを最小化できます。

「テスト自動化を導入したい」と思ったとき、最初に迷うのが「どの種類のテストを自動化すればいいのか」という問題です。

単体テスト・結合テスト・E2Eテスト・APIテスト——これらはすべて「テスト自動化」の一種ですが、目的も使うツールも全く異なります。この記事では、4種類のテストの違いを整理し、実務でどう組み合わせるかを解説します。

4種類のテスト自動化：比較早見表

まずは4種類の違いを一覧で把握しましょう。

種類 テスト対象 実行速度 コスト 代表ツール
🧱 単体テスト 関数・クラス単位 ⚡ 最速 💰 最安 pytest / JUnit
🔗 結合テスト モジュール間の連携 🏃 中程度 💰💰 中程度 pytest / Postman
🌐 APIテスト APIのリクエスト/レスポンス ⚡ 速い 💰💰 中程度 requests / Postman
🖥 E2Eテスト ユーザー操作全体 🐢 低速 💰💰💰 高め Selenium / Playwright

テストピラミッド：4種類の理想的な比率

4種類のテストをどの割合で用意すべきかを示したものが「テストピラミッド」です。下に行くほど数が多く・高速・低コスト、上に行くほど数が少なく・低速・高コストになります。

▼ テストピラミッド

🖥 E2Eテスト
少量・高コスト

🌐 APIテスト
中程度・中コスト

🔗 結合テスト
やや多め・中コスト

🧱 単体テスト
大量・低コスト・高速

💡 ポイント： テストピラミッドの理想比率は 単体テスト70% / 結合・APIテスト20% / E2Eテスト10% 程度と言われています。E2Eを増やしすぎると実行時間が長くなり、CIが重くなる原因になります。

① 単体テスト（ユニットテスト）

どんなテストか

  • 個々の関数やクラスの動作を検証するテスト
  • 開発者が実装直後に実行することが多い
  • 外部依存（DB・APIなど）はモックに置き換えて、ロジックだけを純粋にテストする

関数・メソッド・クラスなど、コードの最小単位が正しく動くかを確認するテストです。外部への依存（DBやAPIなど）をモック（仮のオブジェクト）に置き換えて、対象のロジックだけを純粋にテストします。

✅ 向いているケース

  • 計算ロジック・バリデーション関数
  • 条件分岐が多い処理
  • 境界値・異常系のチェック
  • リファクタリング時の安全網

❌ 向いていないケース

  • UIの見た目の確認
  • 複数モジュールをまたぐ処理
  • 外部APIとの実際の通信確認
代表ツール Python：pytest　/　Java：JUnit　/　JS：Jest
実行速度 ⚡ 最速（ミリ秒〜秒単位）
推奨カバレッジ 全テストの70%程度を単体テストで賄うのが理想
💡 実務Tip： 単体テストは「書くのが早い・実行が速い・問題の原因が特定しやすい」の三拍子が揃っています。まず単体テストを充実させることが、テスト自動化の最初の一歩として最も費用対効果が高いです。

② 結合テスト（インテグレーションテスト）

どんなテストか

  • 複数のモジュールやコンポーネントが連携して正しく動くかを検証するテスト
  • 単体テストではパスしても、モジュールを組み合わせたときに発生するバグを検出する
  • DBへのデータ読み書きや、サービス層とリポジトリ層の連携確認に使われることが多い

複数のモジュール・コンポーネントが連携して正しく動くかを確認するテストです。単体テストでは個々のパーツは動いていても、組み合わせたときに問題が起きることがあります。その「つなぎ目」を検証するのが結合テストです。

✅ 向いているケース

  • DBとのデータ読み書き確認
  • サービス層とリポジトリ層の連携
  • 複数クラスにまたがる処理フロー
  • 外部ライブラリとの統合確認

❌ 向いていないケース

  • 個々の関数の細かいロジック確認
  • ブラウザのUIの動作確認
  • ユーザーの一連の操作フロー
代表ツール Python：pytest　/　Postman　/　Spring Boot Test
実行速度 🏃 中程度（秒〜数十秒単位）
推奨カバレッジ 全テストの15〜20%程度が目安
💡 実務Tip： 「単体テストは全部PASSするのに本番でバグが出る」という経験がある場合、結合テストが不足している可能性が高いです。特にDB操作や外部サービスとの連携部分は結合テストで重点的にカバーしましょう。

③ APIテスト

どんなテストか

  • APIのレスポンスやステータスコードを検証するテスト
  • UIを通さないため高速に実行できる
  • フロントエンドが未完成でもバックエンドの品質を直接確認できる

HTTPリクエストを送信して、APIのレスポンスが期待通りかを確認するテストです。ステータスコード・レスポンスボディ・レスポンスタイムなどを検証します。ブラウザを使わないためE2Eより高速で、バックエンドの品質を直接確認できます。

✅ 向いているケース

  • REST APIのGET/POST/PUT/DELETEの動作確認
  • ステータスコードの正確性（200/404/500など）
  • レスポンスJSONのスキーマ・値の検証
  • 認証トークン・エラーハンドリングの確認

❌ 向いていないケース

  • ブラウザ上のUIの動作確認
  • 内部ロジックの細かい単体テスト
  • ユーザーの画面操作フロー全体
代表ツール Python：requests + pytest　/　Postman　/　REST Assured
実行速度 ⚡ 速い（秒単位・ブラウザ不要）
推奨カバレッジ 主要なエンドポイントを網羅的にカバー
💡 実務Tip： フロントエンドが未完成の段階でもAPIテストは実行できます。フロントとバックエンドが並行開発しているチームでは、APIテストがバックエンドの品質ゲートとして機能します。JSONPlaceholderなどのモックAPIで練習するのがおすすめです。

④ E2Eテスト（エンドツーエンドテスト）

どんなテストか

  • ユーザーの操作を再現し、実際の動作に近いテストができる
  • ログイン→購入→完了など一連のフローを自動で検証する
  • ブラウザを実際に起動するため、他の種類より実行時間がかかる

実際のブラウザを操作して、ユーザーの一連の操作フロー全体が正しく動くかを確認するテストです。ログイン→商品検索→カート追加→決済完了のような「ユーザーストーリー」単位でテストします。最もリアルな品質確認ができる反面、実行コストが最も高くなります。

✅ 向いているケース

  • ログイン・会員登録・購入などの重要フロー
  • リリース前のリグレッション確認
  • 複数ページにまたがる操作フロー
  • スクリーンショット付きエビデンスが必要な場合

⚠️ 注意が必要なケース

  • 数が多すぎるとCIが重くなる
  • UIが頻繁に変わるとメンテコストが高い
  • 失敗原因の特定が単体テストより難しい
代表ツール Selenium（Python/Java/JS）　/　Playwright（Python/JS/TS）　/　Cypress（JS）
実行速度 🐢 低速（分単位・ブラウザ起動が必要）
推奨カバレッジ 重要なユーザーフローに絞る（全テストの10%以内が理想）
💡 実務Tip： E2Eテストは「やりすぎ」に注意が必要です。重要なフロー（ログイン・決済・会員登録など）に絞り込み、細かいUIの確認は単体テストやAPIテストに任せるのが正解です。Playwrightはスクリーンショット・動画録画機能が充実しており、エビデンス収集にも便利です。

実務でどのテストから自動化すべきか

「全種類を一気に自動化する」のは現実的ではありません。実務では投資対効果の高い順に段階的に導入するのが正解です。

▼ 推奨する導入順序

ステップ テスト種類 理由
1️⃣ 🧱 単体テスト 書きやすく・速く・安い。まず開発者と一緒に整備することで自動化文化を根付かせる
2️⃣ 🌐 APIテスト ブラウザ不要で速い。バックエンドの品質を直接確認できるため費用対効果が高い
3️⃣ 🔗 結合テスト モジュール間の連携バグを早期に検出。単体テストだけでは見つからないバグをカバー
4️⃣ 🖥 E2Eテスト 重要なユーザーフローに絞って導入。最終的な品質確認として機能する

🔑 実務での鉄則

  • 単体テストで「ロジック」を守り、APIテストで「インターフェース」を守り、E2Eで「ユーザー体験」を守る
  • E2Eはあくまで最後の砦——数を絞って重要フローだけをカバーする
  • CI/CDに組み込むことで、コードpushのたびに自動実行される品質ゲートを作る

まとめ

この記事では、テスト自動化の4種類——単体・結合・APIテスト・E2Eテストの違いと使い分けを解説しました。

📋 この記事のまとめ

  • 単体テスト：関数・クラス単位で最速・最安。まず充実させるべき基盤
  • 結合テスト：モジュール間の連携を確認。単体テストでは見つからないバグをカバー
  • APIテスト：ブラウザ不要でバックエンドを直接検証。費用対効果が高い
  • E2Eテスト：ユーザー操作全体を再現。重要フローに絞って導入するのがコツ
  • テストピラミッドの理想比率は 単体70% / 結合・API 20% / E2E 10%
  • 導入順序は 単体テスト → APIテスト → 結合テスト → E2Eテスト が費用対効果が高い

「どの種類から始めればいいかわからない」という方は、まず単体テストから始めてみてください。小さく始めて、少しずつ自動化の範囲を広げていくのが実務での正解です。

次の記事では、実際にSeleniumとPythonを使ってE2Eテストを実装する方法を解説しています。まずは Seleniumでリンク切れを自動検出する方法 から読み進めてみてください👇

タイトルとURLをコピーしました