「はじめて学ぶ ソフトウェアのテスト技法」を読んだ

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

「はじめて学ぶ ソフトウェアのテスト技法」を読んだので、所感と引用を書く。

所感

筆者も認めるとおり、本書で扱うのは「知識」と「理解」について。抽象的な内容が多いので文量に対するエッセンスの比率は高いと感じた。

正直なところ、一読ではすべてを理解できなかった。特に、ペア構成テストで用いる「直交表」などは難解だと感じた。あるいは、「欠陥の分類」は提示される情報の多さに圧倒された。

読了後の感想としては、テスト技法を「物にできた」という実感はない。様々なテスト技法について一通りさらった、という印象。

再読して更に理解を深める必要がありそう。あるいは、実際に開発で意識して適用していくことで、ようやく理解の取っ掛かりを得られるような気がしている。

引用

第1章 テストのプロセス

テストの本質は「実際どうあるか」と「どうあるべきか」を比較するプロセス。

本書のテーマはテストケースの作り方。

テストの成熟度の5つのレベルが面白い。

本書では、テスト設計を有効にし、効率を高めるためのもの。それによって、少ないリソースでより欠陥を検知できる。

テスト設計はソフトウェアの設計と同じくらい難しい。しかし、テストはしばしば付け足しと考えられ、安心するためだけに作成される。

Section1 ブラックボックステスト技法

ブラックボックステストとは、仕様書や要件をよりどころにしたテスト技法。

総当り方式のテストは実現不可能。入力の組み合わせの、小さなサブセットを選択する。

第3章 同値クラステスト

「同値クラス」とは、同じ条件を満たすある範囲のこと。

例えば if (a >= 0 && a <= 10) { ... } というコードにおいて、 0,1,2, ..., 10 は同値クラス。どれか1つの値をテストすれば良い。1つの値でテストが落ちるなら、他の同値クラスの値でも落ちる。その逆もしかり。

この時、-10, STRING, $%!# と言った入力でもテストするべきかどうか。オブジェクト指向の世界で言う契約の設計を理解する必要がある。

例えば、「ファイルを開く」という関数に関して。ファイルが存在していることが前提（事前条件）となる。契約によるテストの場合、事前条件が満たされた状況でのテストしか作成できない。

一方で異常ケースについても考慮するのが防御的設計であり、そのアプローチに従ったのが防御的なテストとなる。

同値クラステストを実施するにはまず、同値クラスが何かを判別する。

また、防御的設計を取って異常値のテストをするなら、異常値は1つずつテストする。「18歳以上の正社員」という判定ロジックならば、「16歳のアルバイト」という入力値は不適格。どちらが原因でエラーとなったのか判別できない。

また、入力ではなく出力に注目するアプローチもある。が、ある出力を確認するのに複数の同値クラスが存在することに留意。

同値クラステストはカバレッジを保ちながら、テストケースの数を管理可能な程度に減らすことができる。

第4章 境界値テスト

同値クラステストは、境界値テストの考え方を導き出してくれる。境界値テストは境界に注目するテストで、境界にはたくさんの欠陥が潜んでいる。

「要件の推測」は許容していい行為ではない。

境界値テストでは、まず同値クラスを選定する。その境界値と「すぐ下」と「すぐ上」の3つの値が境界値テストの入力値となる。年齢なら、17歳、18歳、19歳。米ドルとセントなら、4.99ドル、5.00ドル、5.01ドル。

第5章 デシジョンテーブルテスト

デシジョンテーブルは、条件の集合にもとづいて、複雑なビジネスルールを表現するもの。

条件を網羅し、その結果であるアクションも書き出す。その組み合わせがそのままテストケースとなる。

第6章 ペア構成テスト

あまりにも複雑なパターンが多い場合。すべての変数のすべての値のすべての組み合わせをテストするのではなく、変数値のすべてのペアをテストする。

すべてのペアを見つけ出すためには、「直交表」と「全ペアアルゴリズム」という2つの技法がある。

直交表は数字の入った2次元の配列。任意の2列を選ぶと、すべてのペアが含まれている。直交表を利用してすべてのペアを網羅するテスト用サブセットを選択する手順は、

1. 変数を識別する
2. 各変数がとりうる値の数を求める
3. 列の数が変数の数と同じ以上で、各変数の値をとりうる値の数に対応する値が、列に含まれるような直交表を見つける
4. 直交表にテスト問題を割り付ける
5. テストケースを作成する

具体的な作成手順の記載あり。なんとなく分かるようで、でも分からない。直交表そのものについて理解する必要がある。

全ペアアルゴリズムについて。すべてのペアを網羅するツールが無償で提供されている。直交表によるペア導出とは結果が異なることに留意。

ペアについて。その重要度は均一ではない。Chrome, Firefox, Opera は対応ブラウザとして網羅できるペアだが、その普及率は異なる。また、「緊急停止」のようなクリティカルな、絶対に動作を保障したいものは特にテストする必要がある。もしペアとして漏れていたら手動で追加する必要がある。

しかもペア構成テストの正しさを保障する理論はない。ただ、テストケースの数に対して欠陥の発見率が多いという実績だけがある。

第7章 状態遷移テスト

状態遷移図を作成すると、複雑なシステムのルールや相互作用を、非常に簡潔に表現できる。状態、遷移、イベント、アクションから構成される。

状態遷移表を作成すると、状態遷移図で発生する抜け漏れを防げる。状態、イベント、アクション、次の状態から構成される、

テストケースの作成について。状態遷移図のすべての状態、すべてのイベントをテストすると、カバレッジが低くなる。すべての遷移を少なくとも1回はテストするようなテストケースを作成するのが推奨される。

状態遷移テストは、外部との接点を持たない単純繰り返しなシステムには向かない。

第8章 ドメイン分析テスト

ドメイン分析は、複数の変数を一緒にテスト可能な（またはテストすべき）場合に、有効でしかも効率の高いテストケースを特定できる技法。同地テスト、境界値テストを拡張したもの。

• on ポイント: 境界上の値
• off ポイント: 境界上ではなく境界に隣接する値
• in ポイント: 境界条件を満たすが、境界上にはない値
• out ポイント: 境界条件を満たさない値

難しくてよくわからなかった…。

第9章 ユースケーステスト

システムのトランザクションについて、最初から最後まで通しでテストするには、ユースケースが有用。

• 技術的な視点ではなく、ユーザーの視点でシステムを機能要件を把握できる。

Boris Beizer は、トランザクションテストではテストリソースの30％から140％が、テストデータのせいせい、収集、抽出に使われると言っている。そのバジェットを確保しておくこと。

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

ホワイトボックステストとは、パスへのテストのこと。ソフトウエア内部の仕組みを知っている必要がある。 難点としては、すべての実行パスをテストを実行することが非現実だということ。（ブラックボックステストですべての入力値をテストするのが難しいのと同様。

第10章 制御フローテスト

条件文を網羅するテストを書くこと。もちろん、条件文自体の不備や、その内部の式の誤りは検知できない。 制御フローグラフによってパスを分析し、その結果に基づいてテストケースを作成する。 サイクロマチック数は基礎パスの最小数。（基礎パスとは、直列で通過するすべての可能なパスを生成できる、独立でループを含まないパス

第11章 データフローテスト

データフローテストとは、コーディングエラーによる変数の値の不正な使用を見つけるツール。変数の定義、使用、破棄という観点からテストを行う。（「定義→使用」は正常パターンだが、「破棄→使用」はエラーパターン、など）

Section 3 テストのパラダイム

第12章 スクリプトテスト

スクリプトテストはウォーターフォール開発の文脈で誕生したもの。テスト計画書、テスト設計書などを要件定義フェーズで作成しておく。

ドキュメントが公式であること、カバレッジ、トレーサビリティといった利点がある。一方で、要件が明確であること、柔軟性に欠くこと、テストスキルが低下すること、と言った難点もある。

第13章 探索的テスト

探索的テストは、製品を探索しながらテストの設計と実行を行う。

あるテスト結果が次のテストの設計と実行の道標になる。

要件が曖昧でも機能する一方で、欠陥を予防する力は持たない。

第14章 テストの計画

適応型計画では、（利用可能な時間とリソースにもとづいて）計画できるときに、（利用可能な知識にもとづいて）計画できるところまで計画しますが、計画が可能になる前にはそれを行わない。

計画が現在進行系のプロセスである以上、計画書は現時点でわかっている情報と知識に基づいた暫定的な産物であり、新しい情報や理解が得られた際は常に見直しの対象になる

スクリプトテストと探索的テストは状況に応じて使い分ける

Section4 支援技法

第15章 欠陥の分類

欠陥について、様々な分類がある。一番役に立つのは、社内で、チーム内で独自の分類を作成すること。

第16章 テストの終了判定

テストをいつ終了すればいいか

カバレッジが目標値に達した時 →ただし本質的ではなくなる可能性あり。もっと詳細で具体的な基準のほうが優れている。

欠陥検出率がしきい値以下になった時 →ただし、検出しにくい欠陥、テストが有効でない場合、などがある

限界コストが高くなりすぎた時 →製造業では、製品1つの製造コストはその製造数が増えるほど安くなる。一方で、ソフトウェアのバグ検出コストは、バグ検出の数に比例して高くなる。どこかのタイミングで、バグによって被る損害を上回ってしまう。

テストは一種の情報収集のプロセス。十分な情報を集めたら打ち切っても良い。 すべてのバグを検知する、という判断基準は終了条件にはならない。

テストが十分できたと判断するための条件は以下の通り。

• 既存バグがあるにしても、どんな問題を見つけるべきがわかっている
• まだテストしていない部分のどこに重要な問題が出てきそうかわかっている
• リスクに見合った量と方法で製品を検査した
• テストに使える資源はできる限りすべて使用した
• 顧客が要求するテストプロセス標準をすべて満たしている
• テスト方針、テスト結果および品質基準評価をできるだけ明確に示してある

Section5 最後の考察事項

大切なことはより多くの（テスト）ツールを持つこと、状況によって最適なツールを使い分けられるようになること。 本書が扱ったのは「知識」と「理解」について。能力の次の段階である「応用」については、我々の手に委ねられている。

以上。

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

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

はじめて学ぶソフトウェアのテスト技法【電子書籍】[ リー・コープランド ]