• テストサイクル
  • 計画、設計、実施を管理で回していく
• テスト計画
  • 品質保証のタイプ
    • 検出型
    • 網羅型
    • 最善型

SWEBOKのソフトウェアテスティング

• 静的テストと動的テスト
• ブラックテストとホワイトテスト、グレーボックステスト
• レベルで分けるテスト
• コンテキストで分けるテスト

静的テストと動的テスト

• 静的テスト
  • 人による静的テスト
    • レビュー
    • ウォークスルー
  • 機械的な静的テスト
    • 複雑度分析
    • データフロー分析
    • アルゴリズム分析
    • 形式手法 : ソフトウェア要求と設計を数学的に検証

ブラックテストとホワイトテスト、グレーボックステスト

• ブラックテストとホワイトテスト、グレーボックステスト
• ブラックボックスとホワイトボックスによる分類
  • ブラックボックス
    • 同値分割
    • 境界値分析
    • デシジョンテーブル
    • 有限状態機械に基づくテスティング
    • 形式仕様によるテスティング
    • エラー推測
    • 運用プロファイル
  • ホワイトボックス
    • コードに基づくテスティングのための参照モデル
    • 変異テスティング

レベルで分けるテスト

• レベルで分けるテスト

  • 開発レベル
    • 単体テスト
    • 結合テスト
    • システムテスト
  • 目標レベル
    • ユーザー指向
      • 受け入れ/認定テスト
      • 導入テスト
      • アルファおよびベータテスティング
      • ユーザビリティテスティング
    • 不具合指向
      • テスティングによる信頼性の実現および評価
      • 回復テスティング
    • 要件指向
      • 適格性テスティング/機能テスティング/正当性テスティング
      • バックツー/バックテスティング
      • 構成テスティング
    • 設計指向
      • パフォーマンステスティング
      • ストレステスティング
    • その他
      • 回復テスティング

• 結合テスト

  • トップダウン手法で下位ユニットがあに場合はスタブという下位モジュールの入出力を模擬するモジュールを作成
  • ボトムアップ手法で上位ユニットがない場合は、上位ユニットの入出力を模擬するドライバを作成

コンテキストで分けるテスト

• テスト担当者の直感と経験に基づく分類
  • 探索的テスト : ベテランによるアドホックなテスト
• 仕様に基づく分類
  • 同値分割
  • 境界値分析
  • デシジョンテーブル
  • 有限状態機械に基づくテスティング
  • 形式仕様によるテスティング
• コードに基づく分類
  • フローグラフ、コールグラフ
• フォールトに基づく分類
  • エラー推測
  • 変異テスティング
• 利用に基づく分類
  • 運用プロファイル
• アプリケーションの性質に基づく分類
  • オブジェクト指向テスティング
  • 部品に基づくテスティング
  • コンポーネントベーステスティング
  • GUIテスト
  • 並行プログラムのテスティング
  • プロトコル適格性テスティング
  • 分散システムのテスティング
  • リアルタイムシステムのテスティング
  • 科学計算ソフトウェアのテスティング

分析

• テスト項目の抽出

  • テスト観点
    1. 正常系パターン : 同値分割 – 仕様通りかを確認
    2. 異常系パターン : 同値分割 – 仕様通りかを確認
    3. 例外発生パターン : 同値分割 – 仕様通りかを確認
    4. 境界値パターン : 境界値分析 – バグっぽいところを叩く
    5. ゼロ・NULLなどのパターン : エラー推測 – バグっぽいところを叩く
  • 1~3は仕様確認のためのものなので、必ず仕様書代わりのテストコードとして記述
  • 4~5はバグが埋め込まれやすいポイントを叩くための観点で仕様を表現するものとは少し意味外が異なる
  • TDDでテストファーストなテストで4,5のテストコードをもれなく書くことは通常無い。従来手法と同等レベルの単体テストを実施する場合、4,5の観点のテストをするための単体テストの工程を別途切る必要がある

• ホワイトボックステスト

  • 制御パステストによる
  • カバレッジ基準 : テストする処理経路の網羅度合いを測る
    • ステートメントカバレッジ
      • 命令網羅、C0カバレッジ
    • ブランチカバレッジ
      • 分岐網羅、C1カバレッジ
  • ブランチカバレッジが100%であればステートメントカバレッジも必ず100%になる

• ホワイトボックステストとブラックボックステストの使い分け

  • 理想論としての品質確保のためにはホワイトボックステストを実施してブラックボックステストをすることだが、テストは仕様どおりに動くことを確認するもののため、ブラックボックステストをメインにするべき

• カバレッジ率

  • 直交表を用いて2機能間の問題をがっちり抑え、3機能以上の問題については、3機能の組み合わせ結果が仕様書に明記されている箇所と、開発者へのヒアリングや過去のバグリストから検出した怪しいところ、テスト中に見つけた3機能以上の組み合わせバグ原因に焦点を絞り、局所的にテストするほうが効率が良い
  • カバレッジ率を100%にできない場合
    • 単体テスト環境ではテストできない
    • 仕様にないロジックのコーディング

• どこでテストをやめるか

  • 十分性チェック
    • カバレッジ
    • レビュー : メモレベルでも抽出の観点が書いてあるとレビューしやすくなる
    • メトリクス
      • 試験密度 : 試験密度=テスト項目数÷ソースコード行数
      • バグ密度 : バグ密度=検出バグ数÷ソースコード行数

• 直交表

  • ソフトウェア設計の流れ
    1. 因子/水準の決定
    2. 直交表の決定
    3. 線点図の組み換え
    4. 因子/水準の割り付け
    5. 禁則の回避
    6. 完成したマトリクスのチェック

• All-pair法

  • 2機能間組み合わせカバレッジ率が100%になるような最小のテストマトリクスを目指して生成
  • 2機能間の組み合わせを出すことに集中しているため、組み合わせが偏ってしまう欠点
  • 直交表もAll-pair法の一種とみなす場合もある

• マインドマップ

  • マインドマップで発散する方向に発想を広げ、テストケース表では収束させて落とし込むといった形で活用することもできる

• IEEE829-1998 テストプランのアウトライン

  1. テスト計画書番号
  2. 概要
  3. テスト項目
  4. テスト対象
  5. 非テスト対象
  6. アプローチ
  7. テスト項目の合否基準
  8. 一時中断基準と再開要件
  9. テスト提供物
  10. テストタスク
  11. 環境要件
  12. 責任
  13. 要因計画とトレーニング
  14. スケジュール
  15. リスク対策
  16. 承認

ドキュメンテーション

• テスト仕様書のレビュー観点
  1. テスト仕様書があるか
  2. テスト仕様書が何を元に作成されたか
  3. 全体計画と詳細テスト仕様に分かれているか
  4. テスト計画より前にテストケースが設計されていないか
  5. メトリクスに関する記述に着目
     • テストが簡単んい終わるように完了基準が設定していないか
     • テストが永遠に終わらないような完了基準を設定していないか
     • メトリクスデータのみを利用してテストを終わらせようとしていないか
  6. 書いていないことに対するテストケース設計
  7. テスト内容に十分性を証明できるか
  8. その他

参考

ソフトウェアテスト入門　押さえておきたい<<要点・重点>>