ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

JSTQB-TTAシラバスのお勉強 ─ 第2章「構造ベースドテスト」(2)

 ずいぶん間が空いてしまいましたが、TTAの第2章の残り分、2.5~2.8までです。

www.kzsuzuki.com

2.5 複合条件テスト

 対応するカバレッジは、複合条件網羅。すべてのパラメタのすべての真偽を組み合わせる方法です。
 すぐに組み合わせ爆発が起こることは想像に難くありませんね。

www.kzsuzuki.com

2.6 パステスト

 対応するコードカバレッジは、経路網羅。

www.kzsuzuki.com

 パス数が爆発的に大きくなってしまうので、どう妥協していくかの戦略についてシラバスでは言及しています。コードカバレッジといえばある程度機械的に導出できるイメージがありますが、Beizer本から引用されているパステストの方法は、けっこう職人技を感じるものです。

ソフトウェアテスト技法

ソフトウェアテスト技法

  1. 最も単純で機能を実現する、開始から終了までのパスを選択する。
  2. 前のパスとわずかに違うように1つのパスを追加する。後続の各テストで異なるようにパス中の1つのブランチだけを変えてみる。できる限り、長いパスよりも短いパスを採用する。機能を実現しないパスではなく実現するパスを採用する。
  3. カバレッジに必要な場合のみ、機能を実現しないパスを選択する。
  4. 最も実行される可能性が高いパスを選択する際は、直感を使う

 シンプルかつ「機能を実現する」パスを最初に選んでそこから少しずつ変えていく方法では、当然似たようなパスが多くなり、同じ個所を何度も実行することになります。この方法がなぜよいかについて、Beizer氏は著書の中で以下のように書いています。

 条件を細かく変化させると、テストのドキュメントが簡単で、少なくて済み、条件設定も容易となる。1本のパスですべての条件をまとめてテストしようとすると、他のテスト項目との共通条件がないため、多くの作業量が必要となる。
 テストとは一種の実験である。実験の原則は、一度に1つの条件だけを変えることである。つぎのテストとの差が大きいと、混乱する可能性が高くなる。
 余分なパスを実行しても、数マイクロ秒のCPU時間、テスト実行に要する時間、ドキュメント化に必要な時間が余分にかかるだけである。テスト工程では、パステスト以外にも何種類ものテスト法で、もっと多くのテスト項目を実行しなければならない。したがって、パス数が多少増えてもテスト全体の作業量からみれば微々たるものである。

 シラバスだけ読んでいると、何となくシナリオテストの話をしているように感じてくるのですが、ここではあくまでもコードのカバレッジですね。

2.7 APIテスト

 APIテストは、コードカバレッジとは関係がありません。テスト技法の名前でもなく、単に「APIのテスト」という意味ですね。
 APIテストのポイントは以下の3つです。

  • 正常の範囲から外れた入力を正しく処理できるかを確認する否定テスト
  • APIの組み合わせとパラメタ値の組み合わせテスト
  • 故障・復旧・リトライといった異常ケースのテスト

 JSTQBの用語集によると、「否定テスト」の定義は以下の通りです。

否定テスト(negative testing)
 コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。

 わたし自身はAPIのテストを本格的にやったことがなかったので、この記事を書くにあたって、『WebAPI - The Good Parts』を一通り読んでみました(シラバスではWeb APIに限定しているわけではないのですが)。本書は、Web APIの重要性や考え方から始まって、理想的で美しく、堅牢な設計について丁寧に述べられており、楽しみながら読むことができました。

Web API: The Good Parts

Web API: The Good Parts

 一方、テストについては記述があまりありません。そこで、ソフトウェアテスト・ヒストリアンの辰巳さんのツイートから、『10分で学ぶAPIのテスト!』というWebサイトを覗いてみました。

www.guru99.com

 こちらは、APIの一般的な概要について述べた後、APIのためのテストケースや、アプローチ、APIテストとユニットテストの対比などについて説明しています。  たとえば、「APIテストで摘出されるバグの種類」として、以下を挙げています。

  • エラー状態の不正な扱い
  • 使われていないフラグ
  • 機能の重複・欠損
  • 信頼性についての問題。APIへの接続やレスポンス受領が困難。
  • セキュリティの問題
  • マルチスレッドに関する問題
  • 性能の問題。APIのレスポンスタイムが大きすぎる
  • 呼び出し元に対する不適切なエラー・警告
  • 有効な変数値の不適切な扱い
  • 形式的に正しくないレスポンスデータ

 また、「APIテストの課題」としては、以下を挙げています。

  • パラメタの組み合わせ、選択、コール順序
  • GUIがないので入力値を与えるのが面倒
  • 出力値の検証・妥当性確認が少々難しい
  • パラメタの選択とカテゴライズを知る必要がある
  • 例外処理のテスト
  • コーディングの知識が必要

 本当に10分あれば読める内容なので、Web APIテストビギナーの方は読んでみてはいかがでしょうか。

2.8 構造ベースの技法の選択

 2.6までで説明されたコードカバレッジについて、故障発生時の影響の度合いから選択する例が説明されています。
 たとえばDO-178Bという標準で定められた故障条件が「A. catastrophic」であれば、コードカバレッジはMC/DCでテストする必要がある、といったものです。