対象試験と出題頻度
システムテスト（総合テスト）は、基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェア開発工程のテスト段階を区別する問題として定番化しており、「単体テスト」「結合テスト」「運用テスト」との違いを正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「単体テスト・結合テスト・システムテスト・運用テスト…どれが何をするの？」と混乱しがちです。ここだけは確実に押さえてください。
システムテスト（総合テスト／System Test）とは、一言で言うと
「結合テスト後に、開発者側がシステム全体を本番想定で検証する最終工程」
のことです。
イメージとしては、「新車を出荷する前のメーカー総合検査」です。
部品単体の検査（単体テスト）や、エンジンとミッションを組み合わせた検査（結合テスト）が終わったあと、完成した1台の車を実際の道路と同じ条件で走らせ、最高速度・燃費・衝突安全性・エアコンの効き具合まで丸ごとチェックします。これがシステムテストの位置づけです。
📊 システムテストの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | System Test（総合テスト） |
| 実施主体 | 開発者側（ベンダー） |
| テスト対象 | 統合済みシステム全体 |
| 実施タイミング | 結合テスト後／運用テスト前 |
| 主な検証観点 | 機能要件・非機能要件（性能・負荷・セキュリティ等） |
解説
ソフトウェア開発では、「作りながら検証」「組み立てながら検証」「全部組み終わって検証」という段階的なテストが行われます。
それぞれの段階で見つけられる不具合の種類が違うため、上流から下流へ順番に積み上げていく必要があります。
システムテストは、その積み上げの最後の壁です。ここを通過したものだけが、ユーザー側で行う運用テストへと引き渡されます。
テスト工程におけるV字モデル上の位置
システム開発のV字モデルでは、各設計工程に対応するテスト工程が決まっています。システムテストは「システム要件定義」と対になります。
つまり「最初にユーザーと約束した要件をすべて満たしているか」を確認する工程です。
V字モデルにおけるテスト工程の対応
詳細設計
点線「┄┄┄┄」：同じ高さの設計工程とテスト工程が対応する
▲ 左の設計を降りて谷で実装＋単体テストを行い、右を昇って結合テスト・システムテストへ進む
システムテストの主な検証観点
システムテストでは、機能要件だけでなく非機能要件も含めて多面的に検証します。代表的な観点は次のとおりです。
| 観点 | 確認する内容 |
|---|---|
| 機能テスト | 要件定義書に記載された機能がすべて動作するか |
| 性能テスト | 応答時間・スループットが目標値を満たすか |
| 負荷テスト | 想定ピーク時の同時アクセスに耐えられるか |
| 耐久性テスト | 長時間連続稼働でメモリリーク等が出ないか |
| セキュリティテスト | 不正アクセスや脆弱性に対する防御が機能するか |
| 例外処理テスト | 異常入力・障害発生時に適切に対処できるか |
| 回帰テスト | 修正によって既存機能にデグレが発生していないか |
他のテスト工程との比較
類似工程との違いを「対象範囲」「実施主体」「目的」の3軸で整理すると、混同を防げます。
| 工程 | 対象範囲 | 実施主体 | 主目的 |
|---|---|---|---|
| 単体テスト | モジュール単位 | 開発者 | 詳細設計どおりに動くか |
| 結合テスト | 複数モジュールの組合せ | 開発者 | インタフェースの整合性 |
| システムテスト | システム全体 | 開発者 | 要件・非機能を満たすか |
| 運用テスト （受入テスト） |
本番運用環境 | 利用者（発注側） | 業務で使えるかの最終承認 |
ポイントは、システムテストまでは開発者が主導し、運用テストから発注側へバトンが渡るという主体の違いです。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 システムテストの核心を3行で
・結合テストの後、開発者がシステム全体を本番想定で検証する工程
・機能要件に加え、性能・負荷・セキュリティなど非機能要件も検証する
・V字モデル上では「システム要件定義」と対をなす最上位のテスト
試験ではこう出る！
システムテストは、FE・APの午前問題で「テスト工程の役割」「実施主体」「観点の分類」として頻繁に出題されています。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H30秋 午前 問48 |
システムテストの説明として正しいものを選ぶ問題。 | ・「要求仕様を満たしているかを開発者側で検証」が正解 ・運用テスト・結合テスト・単体テストがひっかけ |
| AP H29春 午前 問49 |
負荷テストで確認すべき内容を問う問題。 | ・性能要件の到達可否 ・機能の正常動作（機能テスト）と区別 |
| FE R元秋 午前 問46 |
テスト工程の順序を問う問題。 | ・単体→結合→システム→運用の順序 ・実施主体の切替えタイミング |
| AP R3秋 午前 問48 |
非機能要件をシステムテストで検証する場面の選択問題。 | ・性能・可用性・セキュリティが非機能要件 ・機能テストとの境界 |
📝 IPA試験での出題パターン
パターン1：「テスト工程の説明を選べ」
4つのテスト工程の説明が並び、システムテストに該当するものを選ぶ形式。ひっかけは「業務の流れに沿って利用者が確認」（運用テスト）、「モジュール内部のロジック」（単体テスト）、「モジュール間の連携」（結合テスト）。キーワードは「システム全体」「開発者が実施」「要求仕様の充足」。
パターン2：「非機能要件のテスト観点を選べ」
負荷・性能・セキュリティ・耐久性などの観点と、その確認内容の対応を問う形式。「負荷テスト＝想定ピーク時の挙動」「性能テスト＝応答時間・スループット」を区別する。
パターン3：「実施主体を選べ」
システムテストは開発者側、運用テストは発注者側という主体の違いを問う形式。R元秋FE 問46はこの典型。
深追いせず、「全体・開発者・要件充足・非機能含む」の4キーワードで覚えればOKです。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発におけるシステムテスト（総合テスト）の説明として、最も適切なものはどれでしょうか？
- A. 利用部門の担当者が本番環境で業務シナリオを実行し、システムが業務に使えるかを最終承認する工程である。
- B. 結合済みのシステム全体を対象に、開発者側が機能要件と性能・負荷・セキュリティなどの非機能要件を検証する工程である。
- C. 個々のモジュールが詳細設計どおりに動作するかを、ドライバやスタブを用いて単独で検証する工程である。
正解と解説を見る
正解：B
解説：
システムテストは、結合テスト後に開発者側がシステム全体を本番想定で検証する工程であり、機能要件と非機能要件の両方を網羅的に確認する点が最大の特徴です。
選択肢Aは運用テスト（受入テスト）の説明です。実施主体が利用部門である点と、業務での適合性を最終承認する目的が決定的に異なります。選択肢Cは単体テストの説明です。テスト対象がモジュール単位であり、ドライバやスタブを用いる点はシステム全体を扱うシステムテストとは別工程です。
よくある質問（FAQ）
Q. システムテストはテスト環境と本番環境のどちらで行いますか？
原則として本番環境にできるだけ近い「ステージング環境」で実施します。本番データのコピーや本番相当のサーバ構成を用意し、性能・負荷の数値が本番で再現できるようにします。本番環境そのものを使うのは原則として運用テスト以降であり、システムテストの段階で本番DBに書き込みを行うことはほぼありません。
Q. 「総合テスト」と「システム結合テスト」は同じものですか？
違います。総合テストはシステムテストの別名で、システム全体を対象にする最終段階のテストです。一方「システム結合テスト」は結合テスト（インテグレーションテスト）の一種で、サブシステム間の連携を確認する段階を指します。会社や書籍によって呼称が揺れる用語ですが、IPA試験では「システムテスト＝総合テスト」と覚えておけば問題ありません。
Q. アジャイル開発でもシステムテストは行いますか？
行います。ただしウォーターフォール型のように工程として独立させず、各スプリントの最後やリリース前にCI/CDパイプラインで自動実行されるケースが一般的です。E2Eテスト（エンドツーエンドテスト）と呼ばれる自動テストが、実質的にシステムテストの役割を担っています。SeleniumやPlaywright、Cypressなどのツールでブラウザ操作を自動化し、ユーザー視点のシナリオを毎日回す運用が増えています。
Q. 性能テストで使う代表的なツールは何ですか？
オープンソースではApache JMeterやGatling、k6が定番です。仮想ユーザーを大量に発生させ、想定アクセス数のトラフィックをサーバへ送り込み、応答時間・スループット・エラー率を計測します。商用ではLoadRunnerが古くから使われています。試験では具体的なツール名までは問われませんが、「負荷をかけて性能要件を満たすか測る道具がある」という事実は知っておくと文章問題で混乱しません。
Q. システムテストで不具合が見つかった場合、どこまで戻りますか？
不具合の原因によります。コードの単純なバグなら修正後に該当機能の再テストと回帰テストで済みますが、要件定義の漏れや設計の構造的欠陥が原因なら、設計工程まで戻って手戻りが発生します。手戻りコストが大きいため、上流工程でレビューを徹底することが重要視されます。これがシフトレフト（テストや品質確保を開発の早い段階に寄せる考え方）が推奨される理由です。
