前ページまでで、既存のソフトウエアテストのアプローチを見てきました。現在、ソフトウエアテストには多様なツールや手法がありますが、それらはホワイトボックステスト、ブラックボックステストのいずれかに大別できます。前ページで言及したように、テストでは適切なトレードオフと効率化をどのように判断するかが重要です。その際には、論理的に検討する道具や知識が必要になります。
ここからは、開発現場で使われているテスト手法やテストツールをいくつか取り上げて、より詳細に見ていきます。
ホワイトボックステストを実施または支援する有用なツールはいくつかあります。パスカバレッジのテストツールでは、Jtestなどの単体テスト自動生成ツールや JUnitなどの単体テストのフレームワーク、JCoverageなどのカバレッジ計測ツールがあります。ここで紹介したツールはJava言語に対応したものですが、他の言語のツールも同様にいろいろとあります。
単体テストの生成を自動化させるか、それともテスト生成は手動で行い、それを管理するフレームワークやカバレッジ計測をするためにツールを使うかなどは、開発現場に応じて選択することになります。
網羅基準については、テストで全ての命令を網羅したことを保証する命令網羅(C0)や、全ての分岐が実行されたかを保証する分岐網羅(C1)などを選択します。このとき無効値(例外処理)まで実施するテストは実行コストが掛かる場合が多いので、無効値をどのように扱うかが問題になります。
一方、ブラックボックステストでは、例えばデシジョンテーブルや原因結果グラフを生成するCEGTestなどがありますが、ホワイトボックステストと比べて自動生成のツールはあまりありません。一方、要求からテストまでの一連の流れを管理するテスト管理システムはいくつかあります。
実際の開発現場では多くの場合、Excelを使って、手動でデシジョンテーブルなどを作成します。また、そのテストケースの管理にもExcelを使っていることでしょう。
ここで「アミューズメントパーク施設の入場料」のテストケースを作成するために、デシジョンテーブルを Excelで記述した例を紹介します。このパークでは子供と高齢者の年齢割引があり、女性に限っての曜日割引、高齢者に限っての県内在住者割引があります。このときのデシジョンテーブルの一部は以下の図1のようになります。
テーブル内の1は「その条件が成立」、0が「不成立」、-が「その条件に依存しない」ことを示しています。このデシジョンテーブルを作成することによって、テストケース(今回の表では1〜7までテストケースの一部)に抜け漏れがないことや、逆に重なりや矛盾がないことを目視で確認できます。
デシジョンテーブルを作成するときに、原因や結果にどのような因子を選び、どのような水準で分割するかを決定するのかは、与えられた問題と要求される品質レベルから発見するしかありません。そして開発現場ではテストケースの数が膨大になるとテストコストも膨大になるので、因子や水準の数を制限する必要も出てくるかもしれません。このようにブラックボックステストは各種の発見的手法が必要になり、ツールでは対応し難いものになっています。
また問題点として、テストに抜け漏れや重なりがないかという網羅性を確認する場合は多くの場合、人間が目視で行う必要がある、という点が挙げられます。さらに、無効系のデータ(上記のテーブルでは「その他」となっている条件)をテストでどのように扱うかも問題になります。
最初に紹介したコストと品質の問題や完了基準などのさまざまな問題点をこのデシジョンテーブルでも解決していく必要があります。
テストツールはテスト作業の一部を支援するものであり、全部ではありません。効率化のために使うもので、ツールは全能ではありません。手法やツールからは銀の弾丸は見つかりません。しかし手法やツールは便利なもので、これらは効率を上げるためには使うべきです。
デシジョンテーブルでは条件の値の組み合わせを手動で行っていましたが、それを機械的に実施する手法として、オールペア法と直交表があります。
そこで次回はデシジョンテーブルなどによる組み合わせテストを取り上げ、その中で、オールペア法と直交表の手法とツールを紹介します。
コストと品質のバランスをどのように調整するか、バランスをとるためにどのような基準でテストを実施するのかなどを示し、開発現場のためのオールペア法と直交表との付き合い方を体験しながら覚えていきましょう。
Copyright © ITmedia, Inc. All Rights Reserved.