「はじめて学ぶソフトウェアのテスト技法」 リー・コープランド 著

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法

ソフトウェアのテストに関する本は、きちんと本を読んだのは初めてだけど、いろいろなところでちょっとずつ目にはしていた。そういう意味で、書いてある内容はどこかで見たような事が多いのだけど、頭の中を整理する意味で役に立ちそうだ。一つ、直交表というものだけ今まで知らなかった。この本だけだと直交表の使い方は分かるけど、直交表そのものは何なのかは分からない。調べてみたけど、なんかよく分からない。「この表を作成する一貫した理論はない」とか書いてあるし。


以下、俺の理解による、目次に毛が生えた程度のまとめ。


 第1章 テストのプロセス
 すべてをテストする事は出来ないので、テストはよく考えて設計しなくてはいけない。テストにはブラックボックステストホワイトボックステストがある。また、テストのレベルには、単体テスト、統合テスト、システムテスト、受け入れテストがある。

  
 第2章 ケーススタディの説明
 この本で例題として使用している2つのオンラインシステムについての説明


Section I ブラックボックステスト技法
ブラックボックステストは、ソフトウェアの内部パスや構造を考慮せず、用件と仕様書からテストを設計する。従って、全てのパスはテストできないが、効率はよい。


 第3章 同値クラステスト
 同値クラスとは、同等に処理されるデータや同じ結果を返すデータの集合を表す。同値クラスの1つのデータのみテストすることで、テストケースを削減する事ができる。
 
 第4章 境界値テスト
 境界には欠陥が多いため、同値クラスの境界値をテストする。


 第5章 デシジョンテーブルテスト
 複数の入力の組み合わせに対応するアクションを記述した物がデシジョンテーブル。これはそのままテストケースとして使用できる。


 第6章 ペア構成テスト
 テストの条件の組み合わせの数が非常に多い場合、全ての組み合わせではなく、全てのペアの組み合わせを採用すると、テストケースを削減できる。全てのペアを見つけ出す方法には「直交表」を利用する方法と「全ペアアルゴリズム」を利用する方法がある。


 第7章 状態遷移テスト
 状態遷移図は、イベントとシステムの状態との相互作用を明確に表す事ができる。全ての状態遷移をテストする場合に利用できる。より正確なテストをする場合は、状態遷移表を用いる。


 第8章 ドメイン分析テスト
 複数の変数を同時にテストする場合はドメイン分析テストを利用する。同値テストや境界値テストは変数が1つだが、それを多次元に拡張した物がドメイン分析テスト。境界値テストと同様に、境界となる組み合わせを見つけテストする。


 第9章 ユースケーステスト
 ユーザから見たシステムの機能をどう使うのかを定義したシナリオがユースケース。各シナリオごとにテストを行う。


Section II ホワイトボックステスト技法
ホワイトボックステストは、システム内部のパスや構造からテストケースを作成する。ソフトウェア内部が理解できる程度のプログラミング能力がテスト担当者に要求される。ホワイトボックステストには大きく分けて制御フローテストとデータフローテストがある。

 
 第10章 制御フローテスト
 制御フローグラフから、全ての実行パスを網羅するようにテストケースを作成する。このテストで検出できない欠陥はあるが、ステートメントカバレッジとブランチカバレッジは保証される。


 第11章 データフローテスト
 処理の流れに、全ての変数の、定義、使用、消滅を追加した物がデータフローダイヤグラムである。各変数について、全ての定義−使用のペアを網羅するテストケースを作成する。


Section III テストのパラダイム
ソフトウェアテストにはスクリプトテストと探索的テストのパラダイムが存在する。しかし、両者は補完し合う。


 第12章 スクリプトテスト
 スクリプトテストでは、テストをいくつかのフェーズに分割し、テスト計画に沿ってテストを行う。再現性、客観性、監査性に優れるが、柔軟性に欠ける。IEEE829で8つのドキュメントが定義されている。


 第13章 探索的テスト
 探索的テストでは、テストの計画と実施を同時に行う。テスト結果をテストケースにフィードバックする。テスト担当者のスキルに依存する。


 第14章 テストの計画
 計画は現在進行形のプロセスである。現時点での知識に基づいた計画は、新しい情報が得られたら、見直しが必要である。


Section IV 支援技法
テストをどこから開始するか、いつ終了するかは重要な問題である。


 第15章 欠陥の分類
 いくつかの分類の紹介
 ・SEIによるリスク識別のための分類
 ・ISO9126による品質属性の分類
 ・Boris Beizerによるソフトウェア欠陥の分類
 ・Kaner,Falk,Nguyenによるソフトウェア欠陥の分類
 ・Binderによるオブジェクト指向用の分類
 ・Whittakerによる"How to Break Software"の分類
 ・VijayaraghavanによるEコマース用の分類


 第16章 テストの終了判定
 どんなにテストしても、全てのバグを見つけたかどうかを知る事は出来ない。そのため、カバレッジの目標値、欠陥検出率、限界コスト等が終了を判定する基準となる。


Section V 最後の考察事項
すべての道具を使う必要はなく、特定の状況で必要な道具が何かを判断できる事が重要だ。