システムテスト・SLCP——開発工程と品質確保の考え方 | 中小企業診断士1次試験経営情報システム

「単体テストと結合テストは何が違うの？」——ソフトウェア開発の品質は、テスト工程の設計で決まります。SLCP（ソフトウェアライフサイクルプロセス）の開発工程とテストの種類・目的・実施者を整理して、経営情報システムの得点源にしましょう。

SLCP（Software Life Cycle Process：ソフトウェアライフサイクルプロセス）とは、ソフトウェアの企画・開発・保守・廃棄までの全工程を体系化した国際規格（JIS X 0160）のことです。中小企業診断士試験の経営情報システムでは、開発工程（Vモデル）の各フェーズと対応するテスト種別、ブラックボックスvsホワイトボックステストの違い、具体的なテスト手法（同値分割・境界値分析等）が繰り返し出題されます。

SLCPの概要——JIS X 0160の主要プロセス

JIS X 0160（SLCP）の3大プロセス区分：①主要プロセス——取得・供給・開発・運用・保守②支援プロセス——文書化・構成管理・品質保証・検証・妥当性確認・レビュー・監査③組織プロセス——管理・インフラストラクチャー・改善・訓練。試験では主要プロセスの「開発プロセス」が中心です。

開発工程	主な作業内容	成果物（ドキュメント）
要件定義（要求分析）	ユーザーのビジネス要求・システム要件を明確化する。何を作るべきかを定義	要件定義書・システム要求仕様書
外部設計（基本設計）	システムの外部仕様を設計。ユーザーインターフェース・画面設計・入出力設計	外部設計書・画面設計書・帳票設計書
内部設計（詳細設計）	プログラムの内部構造・データ構造・モジュール分割を設計	内部設計書・プログラム設計書
製造（コーディング・プログラミング）	設計書に基づいてソースコードを記述する	ソースコード・コードレビュー結果
単体テスト（ユニットテスト）	各モジュール・プログラム単位の動作確認	単体テスト仕様書・テスト結果報告書
結合テスト（統合テスト）	複数のモジュールを組み合わせた連携の確認	結合テスト仕様書・インターフェーステスト結果
システムテスト	システム全体として要件定義・外部設計の内容を満たしているか確認	システムテスト仕様書・性能テスト結果
受入テスト（検収テスト）	ユーザーが発注した要件を満たしているかを確認し、納品の可否を判断	受入テスト仕様書・受入報告書・検収書

Vモデル——開発工程とテストの対応関係

Vモデル（V字モデル）とは：開発工程（左側：上流から下流へ）とテスト工程（右側：下流から上流へ）を対応させた開発モデル。各テスト工程は対応する設計工程の成果物を「正しく実装されているか」検証するという構造です。

Vモデルの開発工程とテストの対応

要件定義

←対応→

受入テスト

外部設計（基本設計）

←対応→

システムテスト

内部設計（詳細設計）

←対応→

結合テスト

製造（コーディング）

←対応→

単体テスト

テストの種類と目的——4段階の全体像

テスト種別	目的	主な実施者	確認対象の設計書	典型的なテスト内容
単体テスト（ユニットテスト）	各モジュール・関数・クラスが設計通りに動作するか確認	開発者（プログラマー）	内部設計書・プログラム設計書	正常系・異常系・境界値・条件分岐のすべてを網羅
結合テスト（統合テスト）	複数のモジュールを組み合わせた時の連携・インターフェースの正確性を確認	開発者・テスト担当者	内部設計書・外部設計書	モジュール間のデータ受け渡し・シーケンス・データ形式の一致
システムテスト	システム全体として外部設計・要件定義を満たしているかを確認。性能・セキュリティ・障害回復も含む	テスト専門チーム（開発チームと別）	外部設計書・要件定義書	機能テスト・性能テスト・負荷テスト・セキュリティテスト・回帰テスト
受入テスト（UAT）	ユーザーが要件定義通りのシステムかを確認し納品の可否を判断	ユーザー・発注者	要件定義書・契約仕様書	業務シナリオに基づく操作確認・データの正確性・使い勝手の確認

ブラックボックステストとホワイトボックステスト

ブラックボックステスト

内部構造（プログラムのコード）を見ずに、入力と出力の関係だけを確認するテスト
「仕様書通りに動くか」を検証する（外部仕様の検証）
主に単体テスト後半〜システムテスト・受入テストで使用
ユーザーや第三者でも実施可能
代表的手法：同値分割・境界値分析・デシジョンテーブル・状態遷移テスト
メリット：実装方法に依存しない客観的なテスト

ホワイトボックステスト

プログラムの内部構造（ソースコード・ロジック）を参照してテストを設計する
「コードが正しく書かれているか」を検証する（内部実装の検証）
主に単体テスト・結合テストで開発者が実施
コードを読める開発者が実施（ユーザーには不向き）
代表的手法：命令網羅（C0）・分岐網羅（C1）・条件網羅（C2）
メリット：論理的に全パスを網羅できる

主要なテスト手法の詳細

同値分割（ブラックボックス）

入力データを「同じ動作をするグループ」に分割し、各グループから代表値を選んでテスト
有効同値クラス（正常な入力）と無効同値クラス（異常な入力）に分ける
例：年齢入力（1〜120）に対して有効クラス代表値50、無効クラス代表値0や150
全データを試さずに効率的に網羅できる

境界値分析（ブラックボックス）

データの境界値（上限・下限・境界±1）でテスト。バグは境界付近に集中しやすい
例：年齢入力（1〜120）に対して0・1・2・119・120・121をテスト
同値分割と組み合わせて使うことが多い
「オフバイワンエラー」の発見に特に有効

デシジョンテーブル（ブラックボックス）

複数の条件と結果の組み合わせを表で整理するテスト設計手法
条件の組み合わせを網羅的に列挙し、各組み合わせに対する期待動作を定義
例：ディスカウント条件（会員か×購入額10万以上か）に対して4通りの組み合わせ
業務ルールが複雑な場合に効果的

命令網羅・分岐網羅（ホワイトボックス）

命令網羅（C0）：すべての命令文を少なくとも1回実行するテストケースを作成（最低限の網羅）
分岐網羅（C1）：すべての条件分岐（真・偽）を少なくとも1回通過する（C0より厳格）
条件網羅（C2）：複合条件の各部分条件の真・偽を全組み合わせカバー（最も厳格）
C0⊂C1⊂C2の包含関係

試験対策——テスト工程の整理表

テスト	テスト技法	対象の設計書	主な実施者	目的
単体テスト	主にホワイトボックス（C0/C1/C2）+ ブラックボックス（同値・境界値）	内部設計書（プログラム設計書）	開発者（プログラマー）	モジュール単体の正確性確認
結合テスト	主にブラックボックス（インターフェース確認）	内部設計書・外部設計書	開発者・テスト担当	モジュール間連携・インターフェースの正確性
システムテスト	ブラックボックス（機能・性能・負荷・セキュリティ）	外部設計書・要件定義書	テスト専門チーム	システム全体の要件充足確認。性能・信頼性も検証
受入テスト	ブラックボックス（業務シナリオ）	要件定義書・契約仕様書	ユーザー・発注者	ユーザー要件の充足確認・納品可否の判断

システムテストの種類（試験頻出）：機能テスト・性能テスト・負荷テスト・ストレステスト・セキュリティテスト・回帰テスト（リグレッションテスト）・操作性テストなど複数の種類があります。特に「回帰テスト（リグレッションテスト）」は修正した部分が他の機能に悪影響を与えていないかを確認するテストで、保守・改修時の品質保証に欠かせません。

「ブラックボックステストはコードを見ない」とはどういうことですか？

ブラックボックステストは、プログラムの内部ロジック（ソースコード）を一切参照せず、入力に対して期待通りの出力が得られるかだけを確認するテスト手法です。「箱の中身を見ずに動作だけを確認する」イメージです。仕様書や要件定義書に基づいてテストを設計するため、コードを書いた人以外（テスト専門者・ユーザー）でも実施できます。

単体テストと結合テストの違いは何ですか？

単体テスト（ユニットテスト）は個々のモジュール・プログラム・クラス単独の動作を確認します。一方、結合テスト（統合テスト）は複数のモジュールを組み合わせた時の連携・インターフェースが正しく機能するかを確認します。例えば「ログイン機能モジュール単体が正しく動くか」が単体テスト、「ログイン後に正しい画面に遷移するか（ログイン機能+画面遷移機能の連携）」が結合テストです。

同値分割と境界値分析はどう違いますか？なぜ両方使うのですか？

同値分割は同じ動作をする入力のグループを代表値で確認する手法で、境界値分析はグループの境界（上限・下限）付近を重点的に確認する手法です。バグは「100以上と99以下の境界」「正常範囲の上限・下限」などの境界付近に集中しやすいため、同値分割でグループを特定し、境界値分析でその境界を重点的に検証することで、効率よく高いバグ検出率を実現できます。

命令網羅（C0）・分岐網羅（C1）・条件網羅（C2）の関係は？

C0（命令網羅）⊂C1（分岐網羅）⊂C2（条件網羅）の包含関係があり、右に行くほど厳格になります。C0はすべての命令文を1回実行すれば合格。C1はすべての条件分岐の真・偽両方を実行（C0を含む）。C2は複合条件（A かつ B）の各部分条件の全組み合わせを実行（C1を含む）。テストコストと品質のバランスからC1（分岐網羅）が実務では最もよく使われます。

受入テストは誰が実施しますか？開発者でも可能ですか？

受入テスト（UAT：User Acceptance Testing）は原則として発注者・ユーザー側が実施します。「注文した通りのシステムが納品されたか」を確認する検収行為であるため、開発者側（受注者）が実施することは利益相反になりかねません。ただし実際には発注者の担当者が技術的に不慣れな場合もあるため、開発者がサポートしながらユーザーが確認する形態もあります。