U過去問を解いていて「SLCP」という言葉で手が止まりました。ソフトウェアライフサイクルプロセス——開発の始まりから廃棄まで、どの工程でどんな作業をするかを標準化したものです。テストの種類と工程の対応関係が試験では特によく問われるので、まとめてみました。
この記事でわかること
- SLCP（ソフトウェアライフサイクルプロセス）の全体像
- V字モデル——開発工程とテスト工程の対応関係
- テストの種類（単体・結合・システム・受入テスト）
- ブラックボックステストとホワイトボックステスト
- テスト技法（同値分割・境界値分析・デシジョンテーブル）
目次
SLCP——システム開発の全工程を標準化する
SLCP（Software Life Cycle Process）
SLCPとは、ソフトウェアの企画・開発・運用・廃棄までの全工程を標準的に定義したもの。国際規格はISO/IEC 12207、日本版はJIS X 0160。主要プロセス：
① 企画プロセス：システム化の目的・要件の大枠を決定
② 要件定義プロセス：利害関係者の要件を明確化（何を作るか）
③ 開発プロセス：設計→実装→テスト（どう作るか・作る・確認する）
④ 運用プロセス：本番環境での運用・監視・障害対応
⑤ 保守プロセス：バグ修正・機能追加・性能改善
⑥ 廃棄プロセス：システム終了・データ移行・破棄
V字モデル——開発とテストの対応関係
| 開発工程（左下り） | 対応するテスト工程（右上り） | 確認対象 |
|---|---|---|
| 要件定義 | 受入テスト（UAT） | ユーザーの要件を満たしているか |
| 外部設計（基本設計） | システムテスト（総合テスト） | システム全体の機能・性能・セキュリティ |
| 内部設計（詳細設計） | 結合テスト（統合テスト） | モジュール間のインターフェース・連携 |
| プログラム設計・実装 | 単体テスト（ユニットテスト） | 個々のモジュール・関数の動作 |
V字モデルのポイント
- 左側の各工程で作成した「設計書・仕様書」が、右側の対応するテストのテスト基準になる
- 上流工程での要件定義の品質がシステムテスト・受入テストの合否を左右する
- バグを上流工程で発見するほど修正コストが低い（工程が進むと修正コストは指数的に増大）
テスト技法——ブラックボックスとホワイトボックス
| テスト技法 | 視点 | 代表的な手法 |
|---|---|---|
| ブラックボックステスト | 内部構造を意識せず、入力と出力だけを確認。仕様通りに動くかを検証 | 同値分割・境界値分析・デシジョンテーブルテスト・状態遷移テスト |
| ホワイトボックステスト | プログラムの内部ロジックを確認。すべての命令・分岐を通過させる | 命令網羅（C0）・分岐網羅（C1）・条件網羅（C2） |
主要なテスト技法の詳細
| 技法 | 内容 | 例 |
|---|---|---|
| 同値分割 | 入力値を「同じ結果になるグループ」に分け、各グループから代表値を選んでテスト | 年齢入力（0〜17歳・18〜64歳・65歳以上）→各グループ1件ずつテスト |
| 境界値分析 | 境界（最小値・最大値・境界の±1）の値でテスト。バグが多い箇所 | 18歳以上が対象→17・18・19歳でテスト |
| デシジョンテーブル | 条件の組み合わせと期待する動作を表にまとめてテスト。複雑な条件分岐に有効 | 会員種別×購入金額→割引率の組み合わせを網羅 |
Uのメモ
学習メモ
- SLCP：企画→要件定義→開発（設計・実装・テスト）→運用→保守→廃棄の標準化フレーム
- V字モデル：実装↔単体テスト、詳細設計↔結合テスト、基本設計↔システムテスト、要件定義↔受入テスト
- ブラックボックス：入出力で確認（同値分割・境界値分析） / ホワイトボックス：内部ロジックで確認
- 境界値分析：バグが出やすい境界付近（最小・最大・±1）を重点的にテスト
- バグは上流で発見するほど修正コストが低い→要件定義の品質が最重要
