はじめて学ぶソフトウェアのテスト技法 : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ）

キーワード：
　リー・コープランド、テスト、テスト設計、入門書、引用

テスト設計のためのさまざま事例と手順が示されている本。以下のような目次となっている。

第1章　テストのプロセス

第2章　ケーススタディの説明

Section Ⅰ　ブラックボックステスト技法

Section Ⅱ　ホワイトボックステスト技法

Section Ⅲ　テストのパラダイム

Section Ⅳ　支援技法

Section Ⅴ　最後の考察事項
(目次から抜粋)

この本の目次の構成があまりいけてないが、そのまま抜粋した。

この本は、さまざまなテスト設計の技法がまとめられたもので、ソフトウェアテストの設計だけに焦点を絞っているようだ。そして、この本の目的は以下のように示されている。

　システムの規模がどのようなものであっても、すべての異なる論理パスの組み合わせと、すべての異なる入力データの組み合わせに対してテストを行うことは不可能です。リソースの制約があるので、それぞれテストするなんらかの意味を持つ無限の選択肢の中から、テスト担当者がほんの小さな部分（サブセット）を選んでテストする以外に、方法はありません。この書籍の目的は、このようなサブセットを分析、設計、選択して、欠陥をより多く検出できるテストケースを作成できるように読者を支援することです。
(pp.1)

このように、テストケースを自分で作れるようになるのが最終目標のようだ。

では、どのようなテスト手法があるかというと、大きく分けると、ブラックボックステストとホワイトボックステストに分類できる。これはテストを良くやっている人、もしくは情報処理試験を受けた人ならすぐに定義が思い浮かぶだろうが、一応自分の復習のために、以下に定義を示しておく。まずはブラックボックステスト。

　ブラックボックステストは、要件と仕様書だけをよりどころにしたテスト戦略です。ホワイトボックステストとの違いは、ブラックボックステストではテスト対象ソフトウェアの内部パス、構造や実装に関する知識を必要としないことです。
(pp.26)

次は、ホワイトボックステストの定義。

　ホワイトボックステストは、テスト対象ソフトウェアの内部パス、構造、実装に関する知識をよりどころにしたテスト戦略です。ブラックボックステストとの違いは、ホワイトボックステストを実施するには通常、詳細なプログラミングのスキルが必要になることです。
(pp.126)

これだけではなんのことかいまいち分からない人は、以下を参照。

そして、ブラックボックステストの対象は、単体テスト、統合テスト、システムテスト、受け入れテストといシステム開発のすべてのレベルで適用できるとあるのに対し、ホワイトボックステストの適用対象は、単体テスト、統合テスト、システムテストまで適用できるとある。ホワイトボックステスト=単体テストとして分岐、ループチェック、SQL文の抽出、結合条件チェックをするだけだと思っていたが、それはホワイトボックステストの1つの側面に過ぎないとあった。曰く、ホワイトボックステストは、単なるコードのテストというよりもパスのテストであり、同じ技法をサブシステム内のモジュール間のパス、システム内のサブシステム間のパス、さらにはシステム同士のパスにまで適用できるとあった。これは自分の知らないことだと思った。実際の現場では、ホワイトボックステストはそこまで広範囲には適用していないような気もする。テスト工数を削減するために・・・。

ブラックボックステスト技法として、以下のようなテスト方法が示されている。

同値クラステスト
境界値テスト
デシジョンテーブルテスト
ペア構成テスト
状態遷移テスト
ドメイン分析テスト
ユースケーステスト

絶対抑えておかなければならないのは、同値クラステストと境界値テストだろう。これだけは、いつでもすぐにテストケースを作れるようになっておかなければならない。逆に、ペア構成テストとかは初めて知った。これは、変数の取りうる組み合わせのうち、すべてのペアをテストするというものらしい。

ホワイトボックステスト技法としては、以下が示されている。

制御フローテスト
データフローテスト
スクリプトテスト
探索的テスト
テストの計画

耳慣れないのは、スクリプトテストと探索的テストだろう。スクリプトテストは、『仕事を計画し、計画に従って仕事をする』というようにウォーターフォールモデル的にテストを実施していき、テスト計画書、テスト設計仕様書、テストケース仕様書などを作成していくアプローチらしい。対して、探索的テストは、計画的ではなく、テスト担当者がテストケースを実行しながらテストケースの設計をコントロールするようなアジャイル的なアプローチらしい。これは知らなかった。規模の大きなエンタープライズシステムではどう考えても、スクリプトテストしか適用できないと思った。探索的テストを実行すると、テスト工数が見積もれないし、納品成果物もおかしなものになりそうだ。しかし、XPのようなアジャイル的でドキュメントレスで、小規模な開発では有効かもしれない。

この本の面白い部分は、各章の引用にある。このようなアメリカ人の書くコンピュータ技術書は、気の利いた、各章の言い当て妙な引用が載っていることが多い。著者はこのような引用はもう出尽くした感があると思ったらしい。そこで、各章の引用に世界最悪な小説の冒頭部の文書を作るというコンテストで入賞したものを載せているようだ。著者が示しているように単なる面白さ狙いで、全く各章の内容を反映していないらしい（笑）　1つだけ、これは最悪だ!!と思ったものを示しておく。

戦いでボロボロに傷つき死に瀕したミュータント蜂の軍団は、羽根をあたり一面に共鳴させながら脚を宙に上げて必死にもがいており、虫番将軍は自分の巨大な飛行アブラムシにまたがってこの腐臭ただよう凄惨な戦場を一瞥すると、上官にむかってこう言った。「閣下、社会の窓があいております」
(pp.117)

これは最悪だwww逆にこの続きが読みたくなってくるから不思議（笑）　どの章の引用も、一文がくどいほど長く説明的で、文の最後には文頭から想像できないところに終着する。どれも最悪で、あまり買って読みたい小説にはならないだろうね。

まぁ、引用はさておき、各テスト技法がそれなりに分かりやすく示されている。特に例題などが参考になる。演習問題もあるが、その答えがどこにも載ってない。自分で応用できるようになれということだろう。

テスト技法の基本を網羅的に理解したい場合にはいいが、各テスト技法の詳細について知りたい場合には、この本だけでは足りないと思われる。これを出発点に、さまざまなテスト本を読んでいけばいいと思う。

入門書としては、以下もお薦め。