最終更新日：2026年9月3日

fe fe-technology programming

まず結論

ソフトウェアテストは、「どの段階で行うか」と「何を確認するか」を分けて考えると判断しやすくなります。

基本情報技術者試験では、次の流れをまず押さえます。

モジュール単体
→ 単体テスト

モジュール同士の接続
→ 結合テスト

システム全体
→ システムテスト

利用者・発注者が受入可否を確認
→ 受入テスト

さらに、負荷テスト・退行テスト・例外テストなどは「何を確認するか」という目的で分類します。

特にFEでは、次の判断が重要です。

システム全体に想定負荷をかけて性能や安定性を確認する → 負荷テスト（システムテスト工程で行う代表例）

修正・変更後に、以前正常だった箇所が壊れていないか確認する → 退行テスト（レグレッションテスト）

直感的な説明

ソフトウェアテストは、完成品になるまで確認範囲を少しずつ広げていくイメージです。

部品1個を見る
↓
単体テスト

部品同士をつないで見る
↓
結合テスト

完成したシステム全体を見る
↓
システムテスト

実際に使う側が確認する
↓
受入テスト

一方、負荷テストや退行テストは「テストする範囲」ではなく、何を確かめたいかを表す名前です。

例えば負荷テストなら、システムへ多数のアクセスや大量処理を発生させ、想定した負荷でも正常に動作できるかを確認します。

このため、問題文に

システムテスト工程
＋
高い負荷
＋
性能・安定性を確認

とあれば、負荷テストを選びます。

退行テストは、修正した部分だけを見るテストではありません。

プログラムを修正・変更した
↓
修正した部分は動く
↓
でも、ほかの正常箇所まで壊れていないか？
↓
退行テスト

「変更後」「修正後」「以前正常だった機能への影響」という表現が出たら、退行テストを疑います。

定義・仕組み

テスト工程による分類

テスト 主な確認対象 判断キーワード
単体テスト 個々のモジュール モジュール単体、仕様書、部品ごと
結合テスト モジュール間の連携 インタフェース、接続、モジュール間
システムテスト システム全体 全体、機能、性能、負荷、耐久性
受入テスト 利用者・発注者から見た要件 利用者、発注者、業務要件、受入

目的による分類

テスト 確認すること 判断キーワード
機能テスト 要求された機能が動くか 機能、仕様どおり
負荷テスト 高い負荷でも正常に動作するか 多数アクセス、高負荷、性能、安定性
退行テスト 修正が既存機能へ悪影響を与えていないか 修正後、変更後、正常箇所への影響、regression
例外テスト 異常値や例外に適切に対応できるか 異常入力、例外、エラー処理

ここで大切なのは、「システムテスト」と「負荷テスト」は同じ分類軸ではないことです。

システムテスト
→ どの段階・範囲で行うか

負荷テスト
→ 何を確認するか

したがって、システムテスト工程の中で負荷テストを実施するという関係が成り立ちます。

科目Aでどう出る？

科目Aでは、問題文のキーワードから「工程」と「目的」を切り分けます。

問題文・選択肢の表現 判断
モジュール仕様書に基づいて動作確認 単体テスト
モジュール間のインタフェースを確認 結合テスト
システム全体に想定負荷をかける システムテスト工程で行う負荷テスト
修正後に以前の機能が壊れていないか確認 退行テスト
利用者が業務要件を満たすか確認 受入テスト

試験中は、まず次の順で見ます。

1. 何を対象にしている？
   部品 / 接続 / 全体 / 利用者

2. 何を確かめている？
   機能 / 負荷 / 修正影響 / 異常系

負荷テストを選ぶ判断

次のような表現があれば負荷テストを疑います。

  • 多数の利用者が同時にアクセスする
  • 大量データを処理する
  • 想定される負荷、またはそれ以上の負荷を与える
  • 応答性能や安定性を確認する
  • 高負荷時だけ発生する不具合を確認する

退行テストを選ぶ判断

次のような表現があれば、退行テスト（レグレッションテスト）を疑います。

  • 不具合を修正した後に確認する
  • プログラムを変更した後に確認する
  • 以前は正常だった機能が今も正常か確認する
  • 修正した箇所以外の正常箇所への影響を確認する
  • 変更によって別の不具合が発生していないか確認する

試験中は、次の1本で切り分けられます。

変更した → 変更していない場所まで壊れていないか確認 → 退行テスト

性能テストや耐久テストは「どれくらい処理できるか」「高負荷や長時間運転に耐えられるか」を見るテストです。

一方、退行テストの中心は性能ではなく、変更による既存機能への悪影響です。

結合テストとの切り分け

「モジュール間」「インタフェース」「上位・下位モジュール」が中心なら結合テストです。

結合の進め方まで問われる場合は、次の記事も確認できます。

どんな場面で使う？

開発の流れとしては、次のように整理できます。

モジュールを作る
↓
単体テスト
↓
モジュールを組み合わせる
↓
結合テスト
↓
システム全体を確認する
↓
システムテスト
  ├ 機能テスト
  ├ 性能テスト
  ├ 負荷テスト
  └ 耐久性などの確認
↓
利用者・発注者が確認する
↓
受入テスト

また、修正が入った場合には退行テストが重要になります。

不具合を修正
↓
修正した機能を確認
↓
以前正常だった機能への影響も確認
↓
退行テスト

このように、テスト工程とテスト目的を重ねて考えると、選択肢を切りやすくなります。

よくある誤解・混同

負荷テストは結合テストで行う

基本的な切り分けとしては誤りです。

結合テストは、モジュール同士の接続やインタフェースを確認します。

負荷テストは、システム全体に負荷を与えて性能や安定性を確認するため、システムテスト工程の代表的なテストとして扱います。

システムテストと負荷テストは同じ意味

同じではありません。

  • システムテスト：テストする段階・範囲
  • 負荷テスト：テストする目的

という違いがあります。

モジュール仕様書に基づく確認はシステムテスト

誤りです。

個々のモジュールの仕様に基づく動作確認は、基本的に単体テストです。

モジュール間のインタフェース確認はシステムテスト

誤りです。

モジュール間の接続確認は結合テストです。

退行テストは修正した箇所だけを確認する

誤りです。

修正した箇所そのものの確認に加えて、その変更によって、以前まで正常だった別の機能に悪影響が出ていないかを確認することが重要です。

問題文に「ほかの正常箇所への影響」「既存機能への影響」とあれば、退行テストを強く疑います。

レグレッションテストは新システムなら必ずシステムテストで行う

レグレッションテスト（退行テスト）の判断軸は、修正・変更による既存機能への影響を確認することです。

単に「新システムのシステムテスト工程だから」という理由で選ぶものではありません。

ホワイトボックス・ブラックボックスはテスト工程の名前

誤りです。

これらは、主にテストケースをどの視点で設計するかの分類です。

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

確認問題（基本情報技術者試験対策）

新しく構築したオンラインシステムのシステムテストで、多数の利用者が同時にアクセスした場合にも応答性能を維持できるか確認したい。最も適切なテストはどれか。

  • ア. 負荷テスト
  • イ. モジュール間インタフェーステスト
  • ウ. モジュール単体の仕様確認テスト
  • エ. 修正後の退行テスト
▶ クリックして答えと解説を見る（ここを開く）

正解：ア

多数の利用者が同時アクセスするなど、高い負荷を与えて性能や安定性を確認するのは負荷テストです。

  • イは結合テストの論点
  • ウは単体テストの論点
  • エは修正・変更後の影響確認の論点

👉 判断ポイント
「システム全体」＋「高負荷」なら、システムテスト工程で行う負荷テストと考えます。

まとめ（試験直前用）

  • 単体テスト：モジュール単体を見る
  • 結合テスト：モジュール間の接続を見る
  • システムテスト：システム全体を見る
  • 受入テスト：利用者・発注者が確認する
  • 負荷テスト：高負荷時の性能・安定性を見る
  • 退行テスト：変更後に、以前正常だった機能への悪影響を見る
  • 「工程」と「目的」は別の分類軸として考える

部品 → 単体、接続 → 結合、全体 → システム、高負荷 → 負荷、変更後の既存機能への影響 → 退行。

© 2024-2026 stemtazoo. All rights reserved.