【読書メモ】「はじめて学ぶソフトウェアのテスト技法」(リー・コープランド) 書籍概要・第一章

書籍情報

書籍

はじめて学ぶソフトウェアのテスト技法(日経BP社)(日経BP公式サイトより)

想定される読者

• テスト設計を業務としている技術者
• アジャイル開発にて、たくさんのコードを効率よくテストすることが求められる開発者
• テストの原理原則を把握すべきマネージャー
• 品質責任者
• プロセス改善技術者
• (テスト技法の講義用参考資料が必要な者(大学))

書籍の構成

前書き

• 第1章 テストのプロセス
• 第2章　ケーススタディの説明

セクション1　ブラックボックステスト技法

• ブラックボックステスト概要
• 第3章 同値クラステスト
• 第4章 境界値テスト
• 第5章 デシジョンテーブルテスト
• 第6章 ペア構成テスト
• 第7章 状態遷移テスト
• 第8章 ドメイン分析テスト
• 第9章 ユースケーステスト

セクション2　ホワイトボックステスト技法

• ホワイトボックステスト概要
• 第10章 制御フローテスト
• 第11章 データフローテスト

セクション3 テストのパラダイム

• パラダイムとは
• 第12章 スクリプトテスト
• 第13章 探索的テスト
• 第14章 テストの計画

セクション4 支援技法

• ブックエンドからの発想
• 第15章 欠陥の分類
• 第16章 テストの終了判定

セクション5 最後の考察事項

• 読者自身のテスト用工具箱

第1章　テストのプロセス

テスト = 「本来はどうあるべきか」を比較するプロセス

(公式的な定義はIEEE標準規格610.12-1990に記載されている)

IEEE(The Institute of Electrical and Electronics Engineers, Inc.)
電気・情報工学分野の学術研究団体、技術標準化機関のこと。

テストフェーズの成熟度

• レベル0

  • 「テスト＝デバック」

  • 偶然欠陥が見つかる可能性はあるが、欠陥を見つける目的はない・
• レベル1

  • 「テスト=ソフトウェアが動くことを示す」

  • 現在のソフトウェア実装が正しいことが前提
  • 不合格にならないテストケースを選択するようになる
• レベル2

  • 「テスト=ソフトウェアが動かないことを示す」

  • 欠陥を見つけ出す努力が必要
  • 鬼のように厳しいテストが出来上がる
• レベル3

  • 「テスト=プログラムが動かないことによって発生する危険性をある程度許容範囲まで減らすこと」

  • 欠陥からプログラムの品質を理解し、ソフトウェアの不完全さを開発者に共有する
  • 現在のシステムを顧客に提供した際に、どれだけマイナスなインパクトがあるかを経営陣に共有する
• レベル4

  • 「テスト=品質の高いソフトウェアを作るための精神的規律」

  • テストが容易なソフトウェア開発に視点がおかれる
  • 要件定義・設計・コードレビュー・インスペクションにもテストが容易になる工夫が含まれる
  • 自己診断し、テスト担当者が検出しなくてもエラーをレポートするようなコードを記載する

インスペクション
ソフトウェア開発の各作業工程で、設計仕様書やコーディングしたプログラムのロジックを第三者が検証し、誤りや問題点を検出することである。

テストで直面する課題

• 時間がない
• テスト内容の決定基準がわからない
• 要件がない、変更が多い
• テストプロセスについて学ぶ機会がない
• 支援ツールがない
• 上層部の品質への無関心

テストケース

• 最小の時間と労力でほとんどエラーが検出できる可能性を高めることが重要
• きちんと設計したテストは「入力」「出力」「実行の順番」で構成される

入力

• キーボード入力
• インターフェースシステムからのデータ
• ファイルやDBから呼び出したデータ
• データ到着時のシステム状態
• システム実行環境からのデータ

出力

• 画面に表示されるデータ

• インターフェースシステム・外部機器へ送られるデータ

• ファイル・DBへの書きこみ

  →どんな結果を期待するかを決める役目として「オラクル」がある

オラクル = テストの期待結果とテスト設計者に提供するためのプログラム、プロセス、データなどを意味する

• 子供のオラクル
  • 単にプログラムを実行して結果を眺める
  • 見た感じ正しそうなら、それが正しいものだと信じる
• 回帰テストのテストスイート
  • プロぐアラムを実行して、以前のバージョンのプログラムに適応したテスト結果を、今回の結果と比較する
• 正当性が実証されたデータ
  • 実行結果と大元の出力定義(テーブル、公式など)を比較する
• 市販のテストスイート
  • 既存の検証済み標準テストスイートに対して、プログラムを実行する
  • コンパイラ、Webブラウザ、SQLプロセッサのようなプログラム向け
• 既存のプログラム
  • プログラムを実行し、異なるバージョンのプログラムでの結果と比較する

実行順番

順序通りのテストケース
- レコードを作成
- レコードの読み出し
- レコードの更新
- レコードの読み出し
- レコードの削除
- 削除されたレコードの読み出し

• メリット
  • テストケースが小さく単純になる
• デメリット
  • 1つのテストが失敗するとそれ以降がすべて無効になる

互いに独立なテストケース

• メリット
  • 順番関係なく実行が可能
• デメリット
  • テストケースが大きくて複雑になる

テストの種類

• ブラックボックステスト
  • 要件や仕様にもとづいて行う
  • ソフトウェアの内部パス、構造、実装知識が不要
• ホワイトボックステスト
  • 内部パス、構造、実装にもとづいておこなう
  • プログラミングの詳細なスキルが必要になる
• グレーボックステスト
  • わかる程度まで実装を調べる
  • ブラックボックステストのテストケースをより効果的に選択するために利用

テストレベル

• 単体テスト
  • 関数ごとに作成するテスト
• 結合テスト
  • 関数を組み合わせて行うテスト
  • 個別に問題なく動作する場合でも、組み合わせることで発生する欠陥を検出できる
• システムテスト
  • 最も高いレベルの結合時に怒る欠陥を検出するテスト
  • 機能、ユーザビリティ、国際性、ローカライゼーション、信頼性、可用性、容量、パフォーマンスなど、コード以外の部分のシステムのテストも含まれる
  • 本書では機能テストのみ扱う
• 受入テスト
  • このテストが完了した場合、顧客がソフトウェアを受け入れ、代金を支払う基準となるテスト

上記テストを行うのは、開発期間がある程度長いことが前提

• 短期間での納品の場合、以下のテストレベルを用いる
  • コード品質
  • 機能性
  • ユーザービリティ
  • パフォーマンス
  • セキュリティ

すべてをテストすることができない

• 条件がある場合、すべてのパターンを行うことはできない
• 条件の境界値だけをテストする