---
title: "テスト工程の種類まとめ【SG試験】"
description: "単体、結合、システム、受入テストを確認範囲と実施目的で整理し、負荷テストやリグレッションテストのような目的別テストと工程名を混同しない判断軸を示します。不具合発見、性能確認、改修影響確認など、何を確認したいのかを手掛かりに工程とテスト種類を選びます。"
last_modified_at: "2026-06-29"
canonical_url: "https://stemtazoo.github.io/sg/test-process-summary/"
section: "sg"
---

## まず結論

テスト工程は、**システムを作ったあとに、部品・組合せ・全体・利用者視点の順で確認していく流れ**です。

SG試験では、テスト名そのものよりも、**何を確認するテストか**で判断させる問題が出やすいです。

判断のポイントは、次のように見ることです。

- **プログラム単位を確認する** → 単体テスト
- **部品同士のつながりを確認する** → 結合テスト
- **システム全体を確認する** → システムテスト
- **利用者・業務の視点で確認する** → 受入テスト
- **変更後の影響を確認する** → リグレッションテスト
- **高い負荷や限界を確認する** → 負荷テスト／ストレステスト

つまり、テスト工程は「名前を暗記する」よりも、**確認する対象と目的**で切り分けることが大切です。

## 直感的な説明

テスト工程は、家を建てたあとの確認に似ています。

いきなり「家全体が使えるか」だけを見るのではなく、まずは一つひとつの部品や設備を確認します。

たとえば、

- 電気のスイッチが動くか
- 水道が正しくつながっているか
- キッチンや浴室が全体として使えるか
- 実際に住む人が生活しやすいか

という順に確認していくイメージです。

システム開発でも同じで、最初から本番と同じ使い方だけを見るのではなく、**小さい単位から大きい単位へ**確認していきます。

## 定義・仕組み

代表的なテスト工程は、次のように整理できます。

| テスト名 | 確認する対象 | 見るポイント |
|---|---|---|
| 単体テスト | プログラムや機能の部品 | 個々の処理が正しく動くか |
| 結合テスト | 複数の部品のつながり | データの受け渡しや連携が正しいか |
| システムテスト | システム全体 | 要件どおりに動くか |
| 受入テスト | 利用者・業務の視点 | 実際の業務で使えるか |

基本の流れは、次のように考えると整理しやすいです。

1. **単体テスト**で、部品ごとの動きを確認する
2. **結合テスト**で、部品同士のつながりを確認する
3. **システムテスト**で、システム全体が要件どおりか確認する
4. **受入テスト**で、利用者や業務の視点から使えるか確認する

このほかに、目的別のテストとして、負荷テスト、ストレステスト、ラッシュテスト、リグレッションテストなどがあります。

| テスト名 | 目的 | 判断のキーワード |
|---|---|---|
| 負荷テスト | 高い負荷でも正常に動くか確認する | 高負荷、同時利用、応答時間 |
| ストレステスト | 想定を超える負荷で限界を確認する | 限界、通常以上、耐えられるか |
| ラッシュテスト | 短時間のアクセス集中を確認する | 一斉アクセス、集中、販売開始直後 |
| リグレッションテスト | 変更後に既存機能が壊れていないか確認する | 変更後、修正後、退行 |

IPAの情報セキュリティマネジメント試験では、システムの利用や運用に関する基本的な知識も出題範囲に含まれます。出題範囲の全体像は、[IPA 情報セキュリティマネジメント試験の試験内容](https://www.ipa.go.jp/shiken/kubun/sg/outline.html)で確認できます。

## どんな場面で使う？

テスト工程は、システム開発や変更の品質を確認する場面で使います。

たとえば、次のような場面です。

- 新しいシステムを開発したとき
- 既存システムに機能を追加したとき
- 不具合を修正したとき
- セキュリティパッチを適用したとき
- 本番公開前に品質を確認したいとき

SG試験では、問題文に出てくる言葉から、何を確認しているのかを見ます。

たとえば、

- 「個々のプログラム」なら単体テスト
- 「モジュール間の連携」なら結合テスト
- 「システム全体が要件どおり」ならシステムテスト
- 「利用者が業務で使えるか」なら受入テスト
- 「変更による想定外の影響」ならリグレッションテスト

というように切り分けます。

## よくある誤解・混同

### システムテストと受入テストの違い

システムテストは、**開発したシステム全体が要件どおりに動くか**を確認します。

受入テストは、**利用者や発注者の立場で、実際の業務に使えるか**を確認します。

| 用語 | 主な視点 | 判断のキーワード |
|---|---|---|
| システムテスト | 開発側・仕様の視点 | 全体、要件、仕様どおり |
| 受入テスト | 利用者・業務の視点 | 利用者、発注者、業務で使えるか |

選択肢で「利用者に実際に使ってもらう」と書かれていたら、システムテストではなく受入テストを疑います。


### 運用テストと書かれたときの読み方（SG試験）

SG試験では、問題文に「運用テスト」と書かれていても、まず**主語が誰か**で切り分けます。

- **利用部門の利用者が主語**：業務手順どおりに業務を進められるかを優先確認
- **情報システム部門の運用者が主語**：運用手順どおりに監視・ジョブ実行・障害対応できるかを確認

さらに、次のように整理すると誤答を切りやすくなります。

- 「全アプリケーションが仕様書どおりに機能する」→ システムテスト寄り
- 「目標とする性能要件を満たす」→ 性能テスト寄り
- 「決められた業務手順どおりにシステムが稼働する」→ 利用者視点の受入・運用確認寄り

> 迷ったら、
> 1) 主語（利用者か運用者か）
> 2) 確認対象（業務手順か運用手順か）
> 3) 要件種別（機能か性能か）
> の順で切り分けます。

### 結合テストとシステムテストの違い

結合テストは、**部品同士をつなげたときに正しく連携するか**を確認します。

システムテストは、**完成したシステム全体として要件を満たすか**を確認します。

| 用語 | 確認する範囲 | 判断のキーワード |
|---|---|---|
| 結合テスト | 部品同士のつながり | 連携、インターフェース、データ受渡し |
| システムテスト | システム全体 | 全体、要件、完成後 |

「連携」や「データの受け渡し」が中心なら、結合テストです。

### リグレッションテストは工程名というより目的別テスト

リグレッションテストは、単体・結合・システムのような確認範囲ではなく、**変更後の悪影響を確認する目的別テスト**です。

たとえば、プログラムを修正したあとに、既存機能が壊れていないかを確認します。

選択肢で「変更後」「修正後」「以前は正常だった機能」「想定外の影響」と書かれていたら、リグレッションテストです。

### 負荷テストとストレステストの違い

負荷テストは、**想定される高い負荷でも正常に動くか**を確認します。

ストレステストは、**想定を超える負荷で、どこまで耐えられるか**を確認します。

| 用語 | 目的 | 判断のキーワード |
|---|---|---|
| 負荷テスト | 想定内の高負荷で正常動作を確認 | 高負荷、同時利用、応答時間 |
| ストレステスト | 想定超えの負荷で限界を確認 | 限界、通常以上、どこまで耐えるか |

SG試験では、「正常に機能するか」なのか、「限界を確認するか」なのかで切り分けると判断しやすいです。

## まとめ（試験直前用）

- テスト工程は、**小さい単位から大きい単位へ確認する流れ**
- 単体テストは、**プログラムや機能の部品**を確認する
- 結合テストは、**部品同士の連携**を確認する
- システムテストは、**システム全体が要件どおりか**を確認する
- 受入テストは、**利用者・業務の視点で使えるか**を確認する
- SG試験では、**確認する対象と目的**で選択肢を切る