「この一冊でよくわかる ソフトウェアテストの教科書」(2)

今日は第3章「ホワイトボックステスト」、第4章「ブラックボックステスト」を読みます。

第3章「ホワイトボックステスト

ホワイトボックステストは、ソフトウェアの内部構造にまで注目したテスト。単体テストのレベルで用いられる。 ホワイトボックステストには制御フローテストデータフローテストがある。

モジュールと論理構造

各モジュールに含まれる複数の処理の流れ、実行順序を論理構造という。ホワイトボックステストを行う際は、この論理構造を検証する。そのためには論理構造をフローチャートなどで視覚化することが有効。

制御フローテスト

制御フローテストでは、「命令文」「分岐経路」「条件」のいずれかに注目し、これらがすべて実行されるかを確認する。

流れとしては

  1. フローチャートを描く
  2. カバレッジ基準を命令文、分岐経路、条件のどれにするか決める
  3. カバレッジ基準を網羅する経路を抽出する(なるべく少ない経路で済むように)
  4. 各経路を通るような入力をモジュールに与え、結果を得る
  5. 結果が想定通りか検証する

命令をカバレッジ基準にした場合はステートメントカバレッジ、分岐経路をカバレッジ基準にした場合はデシジョンカバレッジ、条件をカバレッジ基準にした場合を複合条件カバレッジという。この順に必要なテスト数は増え、下位のカバレッジ基準を包含する。

重要なところは複合条件カバレッジでしっかりテスト、そうでないところはステートメントカバレッジで軽くテスト

データフローテスト

データフローテストは、各変数が定義→使用→消滅の順で処理されているかを検証すること。

感想

いままでやってきた「単体テスト」は基本的に制御フローテストだったんだなぁと。RSpecでテストを書くとき、どれくらいの条件で検証するのか迷いがあったけど、カバレッジ基準に注目すればよかったのかと。 データフローテストはあまり必要性が感じられなかった…(本でも見開き1ページしかさかれてなかったし)

ブラックボックステスト

ブラックボックステストはソフトウェアの内部構造を意識しないテストで、主に機能テスト・システムテストで実施される。

ブラックボックステストを行う際は、どんな観点からテストするのかによってどの機能をテストすべきかが異なる。

テスト観点

機能に注目するのか、非機能に注目するのか(処理速度やストレージ容量など)、ユーザビリティに注目するのか…。それぞれに応じてテストすべき内容が異なる。

テスト設計

テスト観点が決まったら、どの機能をテストするのかなどが決まる。それが決まれば、テストケースが作成できる。

感想

テスト計画のたてかたみたいな話がメインだった。あまりおもしろくなかった。

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践