ソフトウェアテスト

概要

用語の定義
- ソフトウェア故障（Software failure）
  ソフトウェアが期待どおりに正しく動作しないこと．
- ソフトウェアフォールト（Software fault）／ソフトウェアバグ（Software bug）
  ソフトウェア故障を引き起こすプログラム内の欠陥．
  ソフトウェアフォールト(ソフトウェアバグ)があれば故障が必ず起こるとは限らない．ソフトウェアの場合，その使用期間中にソフトウェアフォールトが表面化せず，最後までソフトウェア故障が発生しないこともある．
- ソフトウェアエラー（Software error）
  ソフトウェアフォールト(ソフトウェアバグ)を含む原因となった開発過程中(要求・設計・実装)の誤り．
  ソフトウェアエラーによってソフトウェアプロダクトにソフトウェアフォールトが埋め込まれ，ソフトウェア故障を引き起す原因となる．すなわち，エラー（原因）がフォールト（結果）を生み，フォールト（原因）が故障（結果）を引き起こす．
  なお，プログラミングやソフトウェアテストの世界では，しばしば“バグ”の同義語とみなされる．
テストとは
- テストの目的
  プログラムの品質，信頼性を向上させることである．プログラム中の欠陥（バグ）をできる限り多く発見することを目標として行われる．
  ソフトウェアテストでは，欠陥が存在することを示すことはできるが，欠陥が存在しないことは証明できない．したがって，テストはプログラムが正しいことを証明することではない．テストを行った範囲内においては，正しく動作すると言えるだけである．
- テストの定義
  テストとは，エラーを発見する目的でプログラムを実行する過程である．また，良いテストとは，まだ発見されていないエラーを検出する確率の高いものである．

テストの原則

テストの計画，実効を行う際の原則には以下のような項目がある．
（John Wiley & Sons, Inc., 1979. (長尾　真，松尾正信訳: ソフトウェア・テストの技法, 近代科学社，1980) より抜粋，要約）

テスト・ケースの必須条件は，期待される出力または結果を予想しておくことである．
プログラマは自分のプログラムをテストしてはならない．また，プログラム開発グループは，自分たちのプログラムをテストしてはいけない．
単体テストや結合テストなどプログラマが試験すべき範囲はあるが，最終的なテストはプログラマ以外が行うべきである．
それぞれのテスト結果を完全に検査すること．
テストでは，意図されていない動作も調べなければならない．
プログラムが使い捨てのものでない限り，テストケースもプログラムと同様に保守すべきである．
テスト計画は，エラーの発見を想定して立てること．
プログラムのある部分でまだエラーが存在している確率は，すでにその部分で見つかったエラーの数に比例する．

エラー発見手法

コード検査
グループによるコード読み合わせのための一連の手続きとエラー発見手法
ウォークスルー
グループによる簡単なテストケースを用いたプログラム動作のシミュレートによるエラー発見手法
机上チェック
個人によるコード検査あるいはウォークスルー

エラーを効率的に発見するために，エラー・チェックリストを用意することが重要である．エラーの観点としては，次のようなものがある．

データ参照エラー
データ定義エラー
計算エラー
比較エラー
制御エラー
インタフェースエラー
入出力エラー

テストケースの設計

プログラムのテストケースの設計方針には，次の2つの考え方がある．

ホワイトボックステスト（構造テスト）
機能とは独立にプログラムの構造から，実行されるプログラムのパスを中心に網羅性を検証する．
ブラックボックステスト（機能テスト）
プログラムの構造（実現アルゴリズム）には関知せず，プログラムの外部的に定義された機能のみに注目して試験する．

一般的な手法としては，ブラックボックス法を使ってテストケースを作成し，ホワイトボックス法でテストケースを補足していく方法である．

ホワイトボックステスト
次のような観点からテストケースを作成する．
- 命令網羅
  すべての命令が少なくとも１回実行される．
- 判定条件（分岐）網羅
  各判定条件が真と偽の両方の結果を実行する．
- 条件網羅
  判定条件の各条件において，すべての可能な結果を少なくとも１回実行する．
- 判定条件／条件網羅
  判定条件網羅と条件網羅の両方の条件を満たす．
- 複数条件網羅
  各判定条件において、すべての条件の組合わせを実行する．
ブラックボックステスト
機能に着目してテストケースを生成する際に，次のような観点からテスト入力を選択する．
- 同値分析
  入力可能領域を同じ処理論理のものに分割し，それぞれの代表値をテストケースとして選択する．
- 限界値分析
  入力可能領域の両端およびその外側(無効入力)をテストケースとして選択する．
- 原因ー結果グラフ
  原因と結果の関係を表すグラフを作成し，これをもとに網羅的なテストケースを選択する．
- エラー推測
  起こりやすいエラーを推測して，そのエラーを発生するテストケースを作成する．

テスト基準 (Test Adequency Criteria)

テスト手法に基づく，テストの網羅性を判断する基準である．

制御構造モデル
ホワイトボックステストにおける網羅性(Coverage)の基準である．それぞれの網羅性が 100%になることを目標にテストケースを生成し，実行する．
- C0 Coverage：命令文の実行網羅性
- C1 Coverage：分岐の実行網羅性
- M0 Coverage：モジュールの実行網羅性
- M1 Coverage：モジュールのコール関係の実行網羅性
データ構造モデル
データ構造に着目した網羅性(Coverage)の基準である．
- D0 Coverage：データ要素の設定，参照の網羅性
- D1 Coverage：データ階層の親子関係の組合せにおけるデータ要素の設定，参照の網羅性
外部仕様
- 原因・結果グラフ
  原因・結果グラフをもとに網羅的を判断する．
- 状態遷移図
  状態遷移図をもとに網羅的を判断する．

品質評価指標

ソフトウェアプロダクトの種類や内容により異なるが，品質評価指標の代表的な例を示す． (→ 品質評価指標)

設計書・マニュアル
- エラー検出密度
  
  摘出エラー数／開発規模（ks）［件／ks］
  固有の分野あるいは過去の類似事例がある場合は，開発規模よりもドキュメント枚数の方が望ましい．
- 目標値の設定
  次の標準エラー密度をべースとし，内容的な難易度および作業上の難易度を考慮して，範囲で設定する．
  機能設計書：5～10件／ks　，　詳細設計書：6～12件／ks
  すべての観点のチェックが終了した段階で，エラー摘出密度が目標値の範囲内にない場合は，チェック観点の不足または品質に問題がある（品質不良）とする．
テスト密度
テストの各段階におけるテスト件数とフォルトの検出密度の目安である．
- 単体テスト
  テスト件数：50～100 件/Ks
  フォールト検出密度：8～13 件/Ks
- 統合テスト
  テスト件数：20～50 件/Ks
  フォールト検出密度：3～8 件/Ks
残存バグ数
テストの各段階における残存バグ数の目標値である．
- M1完了 (コンパイル正常終了）
  20 件/Ks
- M2完了 (単体試験完了）
  4 件/Ks
- DB完了 (結合試験完了）
  0.1～0.2 件/Ks