テスト工程の流れ（単体・結合・システム・運用）

結論：テストは小さい単位から大きい単位へ積み上げる

テストは 単体 → 結合 → システム → 運用 の順に、小さい部品から大きい全体へ積み上げていきます。いきなり全体を動かして不具合が出ても原因の場所が分からないので、まず部品ごとに確かめます。

家づくりでいうと、柱や窓を1本ずつ検品する（単体）→ 組み合わせて継ぎ目を確かめる（結合）→ 完成した家全体の性能を確かめる（システム）→ 施主が実際に住んでみて暮らせるか確かめる（運用）、という流れです。

flowchart LR
  A["単体テスト<br>モジュール内部"] --> B["結合テスト<br>モジュール間のつなぎ目"]
  B --> C["システムテスト<br>全体の機能・性能"]
  C --> D["運用テスト<br>利用者の業務で使えるか"]

4つのテスト工程の比較（ここが一番問われる）

選択肢の文章が「どの工程の説明か」を当てる問題がほとんどです。何を見るかのキーワードで判別します。

システム適格性確認テストは、共通フレーム（開発工程の標準的な呼び名）でのシステムテストの正式名です。要件を満たすかを見るので、テストデータは実際の業務データや例外として扱うデータを用意します。全分岐・全命令を通すデータは単体テスト（前のレッスンのホワイトボックステスト）の話です。

結合テストの進め方：トップダウンとボトムアップ

結合テストには、モジュールの階層（呼ぶ側が上、呼ばれる側が下）のどちらから組むかで2つの方式があります。どちらも「まだ完成していない相手」の代用品が必要になるのがポイントです。

• トップダウンテスト：上位から下位へ結合する。下位が未完成なので、下位の代わりにスタブを使う
• ボトムアップテスト：下位から上位へ結合する。上位が未完成なので、上位の代わりにドライバを使う

参考までに、全モジュールを単体で終えてから一気に全部つなぐ方式は「ビッグバンテスト」と呼ばれ、ボトムアップの説明として出される誤答の定番です。

スタブとドライバ（最頻出・必ず覚える）

スタブ＝呼ばれる側の代役、ドライバ＝呼ぶ側の代役です。API 開発でいうと、スタブは「まだ無いバックエンドの代わりに決まった値を返すモックサーバ」、ドライバは「APIを叩いてくれるテスト用クライアント」に近いイメージです。

覚え方：「トップダウンはスタブ（ト・ス）」、残りがボトムアップとドライバ。上から作ると下が足りない→下の代役＝スタブ、と理屈でも確認できます。

選択肢に出るエミュレータ（別の機械の動作をまねる仕組み）、シミュレータ（現象を模擬する仕組み）、トレーサ（実行の流れを記録する道具）は、結合テストで未完成モジュールの代わりをするものではありません。

回帰テスト（リグレッションテスト）

回帰テストは、プログラムを修正・変更したときに、変更していないはずの部分に悪影響が出ていないかを確かめるテストです。日本語では退行テストとも呼ばれ、試験ではこの3つの名前すべてで出ます。

水道管の1か所を直したら、別の蛇口から水が出なくなっていないか家中を確かめる、というイメージです。開発の工程（単体〜運用）とは別軸で、**保守（リリース後の修正）**のときにも行うのが特徴です。

「新規モジュールの誤りを検出」「毎回テストケースを作り直す」は誤り。むしろ前回と同じテストケースを再実行して結果を比べるのが基本です。

ストレステストと、テスト環境の限界

ストレステストは、要求されている処理能力の限界（高負荷）状態でシステムがどう動くかを確かめるテストで、システムテストの一部です。使いやすさの評価（ユーザビリティ）、他機との性能比較（ベンチマーク）、修正の影響確認（回帰テスト）と取り違えさせる選択肢が並びます。

また、本社内の LAN（建物内のネットワーク）だけでシステムテストをすると、事業所までの通信回線を通した応答時間は確かめられません。応答時間は回線を含む実環境に左右されるからです。一方、プログラムの処理時間・サーバの処理能力・過負荷時の動作は本社内でも検証できます。

運用テストで「利用者」が見るもの

運用テストは利用部門（実際に業務で使う人）と情報システム部門（運用する人）が合同で行うことがあり、誰が何を優先して確認するかが問われます。

「全プログラムが仕様どおりに機能する」「性能要件を満たす」はシステムテストで確認済みのはずの内容なので、運用テストで利用者が優先するものではありません。「業務手順」と「運用手順」の1語の違いでひっかけてきます。