初版2004年の少し古い本だが、2022に15刷
されているので安心して読めそうな本

第1章　テストのプロセス

テストには5つの成熟度がある
・テストはソフトウェア開発と同時に進めるライフサイクルプロセス
・・レベル4になるとテストは行動ではなく規律となる。
・組織や人が異なればテストの目的への見え方も変わる

本書てはすぐ現場に適用できるような魔法はかかない
・テスト設計の効率を上げればよりリソースを正しく使える

テストケースは、入力、出力、実行の順番のたった3つで構成されるよう設計される
・テストケースは最小の時間と労力でコスパよくバグを見つける必要がある
・いい加減にでっち上げるものではなく、より複雑で体系化されたものを「デザイン」しなければならない

テストの種別はブラック／ホワイトボックステストに分別される

テストは単体／統合／システム／受け入れテストの4つのレベルで実施される
・システムは多くの場合何週間単位のオーダーで提供され、機能/非機能要件も複雑
・数多のサブシステムが統合され、それらをつなぐ際にもバグは出る
・顧客やユーザーにバグを許容させるのはもちろんngで、最終成果物の期待値を満たす必要がある

全てをテストすることは不可能
・int全範囲ケース書くんか？という話

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

いろいろ手法が説明される

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

ブラックボックステストはソフトウェア内部の知識を必要とせず、要件と仕様書だけをよりどころにしたもの
・要件を分析し、入力、期待する出力を決定
・入力値を使ったテスト作成、実行
・実際の出力と期待する出力を比較し、ソフトウェアが正常に機能するか判断

ソフトウェアの規模が大きいほどブラックボックステストに頼ることになる
・ブラックボックステストは全てのレベル(単体〜受け入れ)に適用可能
・規模が大きいレベルほどホワイトボックステストはしんどい

難点: テスト対象をどれだけテストできたのか測りにくく、不安は残る
・ソフトウェア内部を知る術がない
・入力値はとても小さなサブセットのみを選択し、網羅はしない
・・コンパイラのテスト総当たりでするんか？という話
・・実行順も考慮すると総当たりは無理なことは明白

利点: 有効なサブセットを選択することができれば、より多くのバグを見つけられる

第3章　同値クラステスト

はじめに

同値クラスでテストすればテストケースをかなり絞ることが可能
・同値クラス内では検出された/されなかったバグが全て同様の意味を持つ
・・e.g., 値0-16で何かを出力する分岐があったとして、17個全ての入力ケースを作る必要はない

「契約」によるテストでは無効な入力値をテストする必要はない
・契約による設計アプローチでは、モジュールは事前／事後条件によって定義される
・事前条件が満足された状況のテストケースのみ作成する

防御的テストでは無効な入力もテストする
・防御的設計では、事前条件が満足されない場合、モジュールは例外やエラーを通知する

設計者がどちらかのアプローチを取るか意識できていない場合、統合テストは難航する

技法の解説

同値クラステストを利用する手順
・同値クラスが何かを識別
・それぞれの同値クラスに対しケースを追加

同値クラスが複数ある場合、全て有効な入力で1ケース、それぞれ無効な入力でN(=入力数)作るのが良い
・e.g., 月収,住宅の件数,申請者,住宅のタイプが入力の場合、結果が有効なもので1ケース、無効なもので4ケース作る

適用の対象と制約

同値クラステストはどのフェーズのテストでも利用可能(単体-受け入れ)
・システムの要件に基づいてクラスに分割可能な入力と出力があれば良い
・同値クラステストは入力データの大半がある範囲／集合内の値を取るときに適している
・・同値クラスは結局範囲のことなので特例ケースなどが多いとワークしなそうと理解(p31のおかしなコード)

第４章　境界値テスト

はじめに

境界値テストは文字通り境界に注目する
・「境界」には多くのバグが潜む
・境界を調べれば、その境界が属する同値クラス内の他の値は注目しなくても良い

技法の解説

同値クラスの各境界の値と、すぐ上と下を取れば良い
・1000-83333の場合、999,1000,1001,83332,83333,83334
・・1001,83332は境界の値とほぼ同じ意味を持つので省いても良いかも

適用の対象と制約

・同値クラスと境界値が識別できればどのレベルにも適用可能

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

はじめに

デシジョンテーブルはビジネスルールを記録し、ケースを作成する際の指針にもなる
・エンジニアだけでなく仕様に関わる全ての職種が扱えそう

技法の解説

横軸にルール、縦軸に条件とアクションを積む。各ルール(縦の列)がテストケースとなり、条件が入力、アクションが期待値となる。

デシジョンテーブルを作っておけばそのままテストケースが作成できる
・条件が範囲の場合、境界値を考えれば良い

デシジョンテーブルは縮小できるが、できるだけ縮小しない方が良い
・ある条件によって他の条件の値が意味をなさない場合、DCと記載し、1ルールで良い
・誤って縮小されると、ケース漏れとなる

適用の対象と制約

ビジネスルールが条件の組み合わせとアクションで表せるなら、どのレベルにも適用可能

第６章　ペアワイズテスト

はじめに

変数値の全ての組み合わせをテストするのではなく、全てのペアをテストする
・組み合わせが多いとしんどいが、テストしないわけにもいかない
・多くの欠陥はたかだか2機能の組み合わせで検出されるので、ペアワイズでみつけられる(?)
・・かなり複雑な条件のときに起こってしまうレアなバグみたいなことは往々にしてあると思っていて、それが必ず少しの影響や毀損で済むとも限らないと思う派。ただペアワイズテストの目的からはずれるのか

技法の解説

直交表の列がそのままテストケースになる(以下はchatgptより)
・直交表の最大のポイントは、どの2列を取り出しても「値の組み合わせ」が均等に、かつ漏れなく現れるところにある
・任意の2列に注目すると、その2列だけを切り取った部分表で「全組み合わせが1回以上ずつ出現」
・つまり「Chrome–Windows」「Chrome–Mac」「Firefox–Windows」…といったペアが、必ずどこかの行にひとつは収まる
・これをすべての2列ペアで保証しているため、2要素のすべての組み合わせを網羅できる

アルゴリズムで全ペア網羅するのもあり

ある特定の重要な組み合わせが漏れていたら必ずテストケースに追加する
・頻度やドメインによって柔軟に対応すべき。はじめに、で疑問に思った部分のモヤを晴らしてくれた

適用の対象と制約

必要となる条件は、入力の組み合わせの数が大きいこと

第７章　状態遷移テスト

はじめに

状態遷移図は、以前に何が起きたか、処理の有効／無効がいつどこで存在したかなどを記録する

技法の解説

状態遷移図は、状態、遷移、イベント、アクションで描ける

よくある誤りは、１つの状態遷移図に複数の異なるエンティティを混在させること
・e.g., 予約と搭乗手続き
・状態遷移図は、１つの特定のエンティティで完結する

状態遷移図を表にするのも良い
・抜け漏れをなくしたい時に有効
・しかし、巨大になりがち

テストケースは全ての遷移を少なくとも1回通るようにすると良い
・状態A→Bの全てのパスとしてしまうと、ケースがかなり多くなる

適用の対象と制約

システムが状態を持たないときや、外部からのリアルタイムのイベントに応答する必要がない時には適用できない

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

はじめに

ドメイン分析は同値クラステストや境界値テストをn次元に拡張
・変数はしばしば相互作用を持ち、独立してテストしても無意味

相互作用を持つ2つのパラメータは2次元平面特有の欠陥を持つ
・境界の移動、傾き違い、境界抜け、余分な境界
・2次元平面なのでもちろん傾きがあったり、折れ曲がったりする

技法の解説

用語
・onポイント:境界の値
・offポイント:境界に隣接する値
・inポイント:境界条件を満たすが境界上にはない値
・outポイント:いずれの境界条件も満たさない

マトリクスを組むのが良さそう
・それぞれの変数を列に取り、その制約条件ごとにon/offポイント、代表値を決める
・1列がテストケースになる
・例題見るとわかりやすい

適用範囲と制約

複数の変数が相互作用する時に使える

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

はじめに

ユースケースはユーザーの視点から定義されるのであり、システムの視点からではない
・ユースケース:アクターがある特定の目的を達成するためにシステムをどう使うか示すシナリオ

ユースケースは、使われている開発パラダイムには特に関わりなく有用
・どんなシステムでも、個別のトランザクションを一つ一つテストして機能を通しで実行するようなテスト設計は有効

技法の解説

テンプレを使うと良い
・ユースケースの詳細度がブレるため

それぞれのトランザクションの大きさに目を向けるのが良い
・リスクが高いものを重点的にテストすべき

適用の対象と制約

システムのトランザクションは定義しろ、文書にまとめておけ