ソフトウェアテストの種類 — 単体・結合・システムテスト

導入

アプリをリリースした直後に「動かない」というクレームが殺到したら、開発者にとって最悪の事態です。そうならないために、ソフトウェア開発では段階的なテストを繰り返してから本番に臨みます。

なぜ重要か

テスト工程はシステム開発コストの3〜4割を占めるとも言われており、品質保証の中核を担います。テストを省略したり不十分なままリリースしたりすると、本番環境での障害対応コストは修正前の何十倍にも膨れ上がることがあります。

試験対策としても、ソフトウェアテストはマネジメント系の中で頻繁に問われるテーマです。「各テスト工程の目的」「実施者は誰か」「ブラックボックスとホワイトボックスの違い」は毎回のように出題されており、確実に押さえておきたい分野です。また、近年のアジャイル開発の普及により、継続的インテグレーション（CI）と組み合わせた自動テストの概念も注目されており、テストへの理解はITエンジニアとして働く上でも欠かせない知識になっています。

くわしく知ろう

ソフトウェアテストは、開発工程の順に単体テスト・結合テスト・システムテスト・受入テストの4段階で実施するのが一般的です。

単体テスト（ユニットテスト）は、プログラムを構成する個々のモジュール（部品）が単体で正しく動作するかを確認する工程を指します。開発者自身が実施することが多く、最も細かい粒度のテストです。

結合テスト（統合テスト）は、複数のモジュールを組み合わせて連携が正しく機能するかを確認します。モジュール間のインタフェース（接続部分）で問題が起きやすいため、重要な工程になっています。

システムテストは、システム全体として要件を満たしているかを確認する工程で、開発側が実施します。性能や負荷への耐性も検証の対象になります。

受入テスト（ユーザー受入テスト：UAT）は、発注者や利用者が実際に使ってみて、要件どおりに動作するかを最終確認する工程です。

また、テスト設計の手法として「ブラックボックステスト」と「ホワイトボックステスト」があります。前者はプログラムの内部構造を意識せず入力と出力だけを確認する方式で、後者はプログラムの内部ロジックを見ながら全ての経路が通るように設計する方式です。

具体例で理解する

たとえばECサイトを開発する場合、「カート機能のモジュール単体の動作確認」が単体テスト、「カートと決済機能を連携させた確認」が結合テスト、「サイト全体としての動作・負荷確認」がシステムテスト、そして「実際の発注者や担当者が操作してOKを出す」のが受入テストにあたります。

試験での出題パターン

【パターン1：テスト工程の目的や実施者を問う問題】

「発注者が実際にシステムを操作して動作を確認する工程はどれか」「開発者自身が個々のモジュールを検証する工程はどれか」という形式で出題されます。4つの工程それぞれの「誰が（実施者）」「何を（対象）」「なぜ（目的）」を整理しておくと確実に正解できます。特に単体テストの実施者が開発者であること、受入テストの実施者が発注者・利用者であることは混乱しやすい点です。

【パターン2：ブラックボックスとホワイトボックスの区別】

「内部ロジックを確認する手法はどれか」「仕様書に基づいて入出力のみを検証する手法はどれか」という問い方がされます。「内部を見るか見ないか」という1点で判断できるよう、ブラックボックス（内部を見ない）とホワイトボックス（内部を見る）の対比を言葉で説明できるレベルまで理解を深めておくとよいでしょう。

よくある間違い・紛らわしいポイント

【システムテストと受入テストの混同】

どちらもシステム全体を対象とするテストですが、実施者が異なります。システムテストは開発側（ベンダー）が実施し、発注者に納品する前の内部検証として位置づけられます。受入テストは発注者や利用者が実施し、「これで受け入れられる品質か」を判断します。「最終確認」「ユーザーが実施」というキーワードが出てきたら受入テストを選びましょう。

【単体テストと結合テストの粒度の違い】

単体テストはひとつのモジュールだけを対象とします。結合テストは複数のモジュールをつなげて連携を検証します。よく混同されますが、「単体＝1つのモジュール単独」「結合＝複数のモジュールを接続した状態」と粒度の違いで覚えると整理しやすくなります。

【回帰テスト（リグレッションテスト）の位置づけ】

修正や機能追加を行った後に、既存の機能が壊れていないかを確認するテストを回帰テスト（リグレッションテスト）と呼びます。これは工程名ではなく目的・用途による呼び方で、単体・結合・システムテストのいずれの段階でも実施されうる点に注意してください。

まとめ・試験ポイント

• テストの順序＝単体→結合→システム→受入（開発の順序と逆に検証が積み上がる）
• 単体テスト＝モジュール単体で動作確認、実施者は開発者
• 結合テスト＝モジュール間の連携を確認、インタフェースの問題を検出
• システムテスト＝システム全体の要件確認、開発側が実施
• 受入テスト＝発注者・利用者が最終確認（UAT）
• ブラックボックス＝内部を見ずに入出力で検証、ホワイトボックス＝内部ロジックを検証
• 試験では「各テスト工程の目的と実施者の組み合わせ」を問う出題が多い