---
title: "ソフトウェアテストの種類とは？機能・結合・退行・例外を切り分ける【基本情報技術者試験】"
description: "ソフトウェアテストの種類を「何を確認するテストか」で整理し、機能テスト、結合テスト、退行テスト、例外テスト、単体テスト、システムテスト、受入テストの切り分けをFE試験向けに解説します。"
last_modified_at: "2026-07-25"
canonical_url: "https://stemtazoo.github.io/fe/software-testing-types/"
section: "fe"
---

## まず結論

ソフトウェアテストは、**何を確認するテストか** で切り分けると分かりやすいです。

基本情報技術者試験では、テスト名を丸暗記するよりも、選択肢の中にある **確認対象** を見ます。

特に、次の4つは混同しやすいです。

| テスト | ひとことでいうと |
|---|---|
| 機能テスト | 要求された機能を満たすか確認する |
| 結合テスト | モジュール間のつながりを確認する |
| 退行テスト | 修正後に、既存機能へ悪影響がないか確認する |
| 例外テスト | 異常値や例外ケースへの対応を確認する |

試験では、**修正の悪影響** と出てきたら、まず退行テストを疑います。

## 直感的な説明

ソフトウェアテストは、車の点検に近いです。

同じ「点検」でも、見る場所が違います。

| 車の点検にたとえると | ソフトウェアテスト |
|---|---|
| ライトが点くか確認する | 機能テスト |
| エンジンとタイヤが連動して動くか確認する | 結合テスト |
| 修理後に、別の場所が壊れていないか確認する | 退行テスト |
| 急ブレーキや異常操作でも安全か確認する | 例外テスト |

このように、テスト名は「何を見るか」を表しています。

そのため、選択肢を読むときは、最初に **対象が機能なのか、接続なのか、修正影響なのか、異常系なのか** を見ます。

英語では、退行テストは `regression test` と呼ばれます。  
`regression` は「後戻り」という意味で、修正によって以前できていたことができなくなるイメージです。

## 定義・仕組み

ソフトウェアテストには、目的や実施タイミングによっていろいろな種類があります。

FE試験では、まず次の表で整理すると選択肢を切りやすくなります。

| テスト名 | 確認すること | 判断キーワード |
|---|---|---|
| 単体テスト | 個々のモジュールや部品が正しく動くか | モジュール単体、部品ごと |
| 結合テスト | 複数のモジュールを組み合わせたとき正しく動くか | モジュール間、インタフェース、接点 |
| システムテスト | システム全体が要求を満たすか | システム全体、総合的 |
| 受入テスト | 利用者や発注者が受け入れ可能か | 利用者、発注者、業務要件 |
| 機能テスト | 要求された機能を満たすか | 要求機能、仕様どおり |
| 退行テスト | 修正後に既存機能へ悪影響がないか | 修正後、変更後、以前正常だった部分 |
| 例外テスト | 異常値や例外ケースに適切に対応できるか | 異常入力、例外ケース、エラーメッセージ |

大きく分けると、テストには **段階で見る分類** と **目的で見る分類** があります。

| 分類の見方 | 例 |
|---|---|
| 開発の段階で見る | 単体テスト、結合テスト、システムテスト、受入テスト |
| 確認目的で見る | 機能テスト、退行テスト、例外テスト、性能テスト、負荷テスト |

このテーマは、基本情報技術者試験の「ソフトウェア開発」や「テスト」と関係する内容です。公式の出題範囲やシラバスは、[IPA：基本情報技術者試験](https://www.ipa.go.jp/shiken/kubun/fe.html) から確認できます。

## 科目Aでどう出る？

科目Aでは、テスト名の説明として正しいものを選ぶ問題が出題されやすいです。

判断するときは、次のように **キーワードから切る** と楽です。

| 問題文・選択肢の表現 | 選ぶテスト |
|---|---|
| 要求されたすべての機能を満たしているか | 機能テスト |
| モジュール同士を組み合わせる | 結合テスト |
| モジュール間のインタフェースを確認する | 結合テスト |
| 修正後に、以前正常だった部分に影響がないか | 退行テスト |
| リグレッションテスト、回帰テスト | 退行テスト |
| 異常値や例外ケースを入力する | 例外テスト |
| 個々のモジュールを確認する | 単体テスト |
| システム全体で確認する | システムテスト |
| 利用者が業務で使えるか確認する | 受入テスト |

代表的な選択肢は、次のように切り分けます。

| 選択肢の方向性 | 判断 |
|---|---|
| システムが要求された機能を満たすか | 機能テスト |
| モジュール同士を組み合わせる | 結合テスト |
| 修正がほかに悪影響を与えていないか | 退行テスト |
| 異常ケースへの耐性を確認する | 例外テスト |

「システムの一部を修正したときに、修正部分がほかに悪影響を及ぼさないか」とあれば、**退行テスト** です。

## どんな場面で使う？

問題文では、テスト名そのものよりも、問題文の中で **どの段階の確認をしているか** を読む力が大切です。

例えば、開発の流れを次のように整理します。

```text
モジュールを作る
↓
単体テスト
↓
モジュールを組み合わせる
↓
結合テスト
↓
システム全体を確認する
↓
システムテスト
↓
利用者が確認する
↓
受入テスト
```

さらに、修正が入った場合は、次の観点が追加されます。

```text
不具合を修正する
↓
修正部分を確認する
↓
以前正常だった機能に影響がないか確認する
↓
退行テスト
```

問題文では、テスト工程の説明文や表を読んで、**今見ているのが部品なのか、接続なのか、全体なのか、修正影響なのか** を追うと判断しやすくなります。

## よくある誤解・混同

ソフトウェアテストでよくある誤解は、**テスト名が似ているので、すべて「動くか確認する」で同じに見えてしまう** ことです。

| 誤解 | 正しい理解 |
|---|---|
| 機能テストと結合テストは同じ | 機能テストは要求機能、結合テストは接続を見る |
| 修正した部分だけ確認すれば退行テスト | 退行テストは修正が既存部分へ悪影響を与えていないかを見る |
| 例外テストは例外処理を作ること | 異常入力や例外ケースで正しく処理できるか確認するテスト |
| 単体テストと結合テストは同じ | 単体は部品ごと、結合は部品同士のつながり |
| システムテストと受入テストは同じ | システムテストは開発側の全体確認、受入テストは利用者側の受入確認 |

試験では、次の判断軸を持つと迷いにくいです。

```text
機能を見る → 機能テスト
つながりを見る → 結合テスト
修正の悪影響を見る → 退行テスト
異常時の動きを見る → 例外テスト
部品を見る → 単体テスト
全体を見る → システムテスト
利用者が確認する → 受入テスト
```

また、ホワイトボックステストとブラックボックステストは、テストの段階ではなく **テストケースを何に基づいて作るか** の分類です。

| テスト | 見るもの |
|---|---|
| ホワイトボックステスト | 内部構造、処理経路、条件分岐 |
| ブラックボックステスト | 仕様、入力、出力 |

段階の話と、テスト設計方法の話を混ぜないことも大切です。

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

- テストは「何を確認するか」で切り分ける
- 機能テストは、要求された機能を満たすかを見る
- 結合テストは、モジュール間の接続やインタフェースを見る
- 退行テストは、修正後に既存機能へ悪影響がないかを見る
- 例外テストは、異常値や例外ケースへの対応を見る
- 単体、結合、システム、受入は、開発工程の段階で整理する