【応用情報技術者試験】システム開発技術を学ぼう！　　　　　　~第5章~テスト技法と評価

システム開発技術とは、企業や組織の「業務課題を解決し、効率化する仕組み（システム）」をIT技術を用いて、企画・設計・プログラミング・テスト・運用するまでの一連の技術とプロセスの総称で、具体的には、要件定義、設計、コーディング、テスト、運用・保守などの工程があり、ウォーターフォールやアジャイルといった様々な開発手法が存在します。 

画像参照：https://www.co-well.jp/blog/system_dev_flow

ブラックボックステスト

ブラックボックステストとは、ソフトウェアの内部構造（コード）を意識せず、外部から入力と出力のみに着目して、仕様通りに動作するかを確認するテスト手法です。ユーザー視点で機能の妥当性や使いやすさを評価でき、同値分割法や境界値分析などの技法を用いて、効率的かつ客観的にテストを行います。主に品質保証(QA)担当者やテスターが実施し、ホワイトボックステスト（内部構造を網羅的に確認するテスト）と組み合わせて品質向上を図ります。 

主な特徴

• ユーザー視点: 実際のユーザーに近い立場で、仕様書通りに機能するかを確認します。
• 内部構造を無視: コードの中身（ロジック）は考慮せず、入力と出力の関係にのみ注目します。
• テストレベル: 単体テストから受け入れテストまで、全てのテストレベルで適用可能です。 

代表的なテスト技法

• 同値分割法: 同じ振る舞いをすると想定される入力値をグループ（同値クラス）に分け、代表値でテストします。
• 境界値分析: 入力値の範囲の境界（最小値、最大値、その前後）でテストを行い、境界付近のバグを発見します。
• 決定表テスト: 複数の条件と結果の組み合わせを図で表現し、網羅的にテストします。
• 状態遷移テスト: システムの状態変化に着目し、遷移が正しいかをテストします。 

役割と重要性

• 仕様の抜け漏れや矛盾、ユーザーインターフェースの不具合などを発見するのに有効です。
• 開発者とは異なる視点でテストすることで、客観的な品質評価が可能になります。
• 仕様自体が間違っていると、ブラックボックステストでは見逃してしまう可能性があるため、ホワイトボックステストとの併用が不可欠です。 

同値分割法

同値分割法とは、ソフトウェアテストで入力データを「同じような振る舞いをする値のグループ（同値クラス/同値パーティション）」に分割し、各グループから代表的な値を選んでテストすることで、テスト工数を削減しつつ効率的にテスト範囲をカバーする技法です。有効な値の範囲（有効同値クラス）と無効な値の範囲（無効同値クラス）に分け、それぞれから代表値を選んでテストし、境界値分析と併用することで、より高い検出率を目指します。 

基本

1. 同値クラスの特定: 入力値や出力結果が同等になると想定される範囲をグループ化します。
   • 有効同値クラス: システムが正しく処理すると期待される値の範囲（例：年齢13〜64歳）。
   • 無効同値クラス: システムがエラーとして処理すべき値の範囲（例：年齢0歳以下、65歳以上、文字など）。
2. 代表値の選択: 各同値クラスから1つ（または複数）の代表的な値を選び、テストケースとします。
3. テストの実施: 選択した代表値でテストを実行し、期待される結果が得られるか確認します。 

具体例（年齢入力）

• 条件: 13歳以上を大人、12歳以下を子供料金とする。
• 有効同値クラス: 13歳〜149歳（一般的な上限として）。
• 無効同値クラス: 0歳以下（-1など）、150歳以上、文字など。
• テストケース:
  • 有効：10歳（子供）、30歳（大人）
  • 無効：-1、150、”abc” 

メリット

• テスト工数の削減: 全ての値をテストする代わりに、代表値で効率的にカバーできる。
• テスト範囲の効率的な網羅: 少ないテストで広い範囲の振る舞いを検証できる。 

境界値分析

境界値分析とは、ソフトウェアテストで仕様の「境界」となる値（最小値、最大値、その前後）に注目し、バグが潜みやすいその周辺を重点的にテストすることで、効率的に不具合（特に「未満」「以上」「以下」などの誤り）を発見する手法です。これは、同値分割法（同値クラスに分ける）と併用され、同じ出力結果になる入力値をグループ分けした後、その境界値（グループの端の値とその隣の値）を選んでテストケースを作成するのが一般的です。 

ポイント

• 対象: 「〇〇以上」「〇〇未満」のように数値の範囲が定義されている条件。
• 境界値: 最小値、最大値、その最小値-1、最大値+1、特殊な値（0など）。
• 目的: 境界値付近での実装ミス（例: 「未満」を「以下」と誤って実装）による不具合の検出。
• 手順:
  1. 同値分割法で入力値をグループ分け（同値クラス）する。
  2. 各同値クラスの「境界値」と、その隣接する値（最小値-1、最大値+1）を選びテストケースとする。 

具体例（年齢が18歳以上で選挙権がある場合）

• 仕様: 18歳以上で選挙権あり、17歳以下で選挙権なし。
• 同値クラス:
  • 選挙権なし（有効外）: 17歳以下
  • 選挙権あり（有効）: 18歳以上
• 境界値:
  • 17歳（境界-1）
  • 18歳（境界値）
  • 19歳（境界+1）
• テストケース: 17, 18, 19歳を入力してテストする。 

なぜ有効か

• 効率的: 全ての値をテストできないため、不具合が起きやすい「境界」に絞ることで効率的なテストが可能。
• 効果的: 仕様の解釈ミスやコーディングミスが最も発生しやすい箇所を狙い撃ちできる。 

境界値分析は、テスト設計の基本であり、特に数値や範囲を扱う機能の品質向上に不可欠な手法です。

決定表テスト

決定表テストとは、複数の条件（入力）とそれに対応する動作（出力）の組み合わせを「決定表（デシジョンテーブル）」という表形式で整理し、網羅的かつ効率的なテストケースを作成するブラックボックステスト技法です。複雑なビジネスルールやシステム仕様において、条件の組み合わせによる結果の変化を明確にし、テストの抜け漏れを防ぎ、品質向上とテスト効率化を図るのに非常に有効です。 

主な特徴とメリット

• 網羅性の向上: すべての条件の組み合わせ（ルール）を一覧で視覚化できるため、テストケースの漏れを防ぎ、網羅的なテスト設計が容易になります。
• 複雑なロジックの明確化: 「もし〇〇ならば、△△する」といった複雑な条件分岐を整理し、チーム内での共通認識を作りやすくします。
• 不要なケースの削減: あり得ない条件の組み合わせを特定し、不要なテストケースを排除することで、テスト工数を削減できます。
• テスト効率化: 整理された表からテストケースを導出するため、テスト設計がスムーズになり、開発・テストのスピードアップにも貢献します。 

決定表の構成要素

• 条件記述部: 考慮すべき入力条件（例：年齢、クーポン有無）を記述します。
• 動作記述部: 考慮すべき出力結果（例：割引率、エラー表示）を記述します。
• 条件指定部: 各条件が「真 (Y)」「偽 (N)」などの値をとる組み合わせを列挙します。
• 動作指定部: 条件指定の組み合わせ（ルール）に対して、どの動作が実行されるかを指定します。 

どんな時に使う？

• 複数の入力条件が絡み合い、その組み合わせによって出力が変わるシステム。
• オンラインショップの割引計算、ローン審査、ユーザー権限に応じた機能表示など。 

決定表テストは、条件と結果の関係が複雑な場合に、その全体像を把握し、漏れなくテストするための強力なツールとして活用されます。 

状態遷移テスト

状態遷移テストとは、ソフトウェアやシステムがある「状態」から別の「状態」へ、「イベント（入力や操作）」によって正しく変化するかを検証するテスト手法です。状態遷移図や状態遷移表を使ってすべての状態とイベントの組み合わせを洗い出し、仕様通りの動作（遷移）や、不正な遷移が起きないかを確認することで、システムの品質を向上させます。Webアプリの画面遷移、家電のモード切り替え、自動販売機の動作確認などに有効です。 

ポイント

• 状態 : システムが取りうる状況（例: 「未ログイン」「ログイン中」「エラー状態」）。
• イベント : 状態を変化させるきっかけ（例: 「ログインボタン押下」「パスワード入力ミス」）。
• 遷移 : イベントによって状態が変化すること（例: 「未ログイン」から「ログイン中」へ）。
• モデル化: 状態とイベントの関係を「状態遷移図」や「状態遷移表」にまとめ、テストケースを作成します。
• 網羅性: 全ての状態、有効な遷移、無効な遷移（遷移できないはずのケース）などを網羅的にテストし、抜け漏れを防ぎます。 

例：ログイン機能のテスト

• 状態: 未ログイン、ログイン中、ロック状態。
• イベント: 正しいID/パスワード入力、誤ったID/パスワード入力、ログアウト。
• テスト内容:
  • 未ログイン状態で正しいID/PWを入力したら「ログイン中」になるか。
  • ログイン中に誤ったPWを入力したら「ロック状態」になるか（またはエラー表示）。
  • ロック状態ではID/PW入力を受け付けないか。 

メリット

• 仕様の抜け漏れや曖昧さを開発初期に発見できる。
• 複雑なシステムでも、状態ごとの挙動を体系的に把握できる。
• 網羅的なテストケース作成により、品質の高いシステム構築に貢献する。 

ホワイトボックステスト

ホワイトボックステストとは、ソフトウェアの内部構造（ソースコード、ロジック、設計）を理解し、プログラムが仕様通りに正しく動作するかを検証するテスト手法です。開発者が担当し、単体テストで主に実施され、コードの網羅性を高めることで、見落としがちな潜在的なバグやエラーを早期に発見し、システムの信頼性を向上させます。 

特徴と目的

• 内部構造の可視性: ソースコードや設計書を見ながら、命令文、分岐条件、データの流れなどを中心にテストします。
• 開発者による実施: プログラミング知識が不可欠なため、開発者が自ら行うのが一般的です。
• 網羅性の重視: すべてのコードパスや条件分岐を網羅的にテストし、見落としを防ぎます（例: 100%カバレッジ）。
• 早期のバグ発見: 単体テスト段階でコードレベルのミスを検出でき、手戻りを減らせます。 

ブラックボックステストとの違い

• ホワイトボックス: 内部構造を理解して「作り手」視点でテスト（例: 単体テスト）。
• ブラックボックス: 内部構造を無視し、外部仕様（入力と出力）のみで「ユーザー」視点でテスト（例: 受け入れテスト、システムテスト）。 

実施される主な工程

• 単体テスト: モジュール単位のテストで、最も頻繁に実施されます。
• 結合テスト、システムテスト: 連携部分やシステム全体でも、内部構造を意識して適用されることがあります。 

手法例

• 命令網羅 : プログラム内のすべての命令を、少なくとも一度は実行する。
• 判定条件網羅（分岐網羅） : プログラム内のすべての条件分岐（if文やswitch文など）において、「真」になる経路と「偽」になる経路の両方を少なくとも1回実行する。
• 条件網羅 : プログラム内のすべての条件式（例：A や B）が、「真」と「偽」の両方の結果で少なくとも1回実行する。
• 判定条件/条件網羅：「分岐するすべてのルート（判定条件網羅）」と「分岐条件それぞれの真偽の両方（条件網羅）」を満たすテストケースを実施する。
• 複合条件網羅：条件分岐に複数の条件の組み合わせがある場合に、そのすべての組み合わせをする。

条件式と条件分岐の違い
条件式は「真か偽」を判定する式（例: x > 10）です。
条件分岐は、その条件式の判定結果（真偽）に基づいて「どの処理を実行するか」を決定するプログラムの仕組み（例: if文やswitch文）です。
つまり、条件式が「質問」で、条件分岐がその質問への「回答（処理の選択）」にあたります。 

メリットとデメリット

• メリット: 潜在的なバグの発見、コード品質向上、信頼性向上。
• デメリット: 専門知識が必要、テスト工数が増大しやすい、仕様自体の誤りは検出できない。 

ホワイトボックステストは、ブラックボックステストと併用することで、ソフトウェアの品質を総合的に高めるために非常に重要なテスト手法です。 

信頼度成長曲線

信頼度成長曲線とは、ソフトウェア開発のテスト工程で縦軸に累積バグ発見数、横軸にテスト時間やテストケース数を取り、S字型の曲線で品質の向上度合い（信頼性の成長）を可視化するグラフです。テスト序盤はバグが多いため急増し、終盤には収束（水平に近づく）することで、残りのバグ予測やテスト終了の目安として利用され、PB曲線（バグ曲線）とも呼ばれます。

 画像参照：https://itmanabi.com/reliability-growth-curve/

主な特徴と用途

• S字カーブ: 開発初期はバグが急増、中期以降は発見が鈍化し、最終的に収束する（グラフが水平に近づく）のが一般的です。
• 可視化: 開発の進捗状況や品質の傾向（「成長」しているか）を一目で把握できます。
• 予測: 曲線から将来の推移を予測し、テストの完了時期や品質目標の達成度を評価します。
• モデル: ゴンペルツ曲線やロジスティック曲線などの数式で近似し、残バグ数などを統計的に推定します。 

活用例

• 品質管理: グラフの傾きが緩やかになることで、品質が向上したと判断し、テスト終了の判断材料にします。
• 進捗管理: プロジェクト管理者がテストの遅延や品質の課題を早期に発見し、対策を講じるのに役立ちます。