Nスイッチテスト技法はほとんど使われていない? | 組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題

Nスイッチテスト技法はほとんど使われていない?

状態遷移テストの1テスト技法であるNスイッチテストは、巷間言われているほど使われていないようです。「"状態遷移"」、「"Nスイッチ"」、「テスト」の3つのキーワードでGoogle検索してみたところ、約50件しかヒットしませんでした。「”デシジョンテーブル”」、「テスト」で検索した場合が約6,000件、「"組み合わせテスト"」、「ソフト」で検索した場合が約5,090件ですからその差は歴然です。

どうしてこのような差が出るのでしょうか。考えられる理由として以下が挙げられるようです。

(1) 1スイッチテスト以上になるとテストケース数が大幅に増加するためコスト面から実施しづらい。
(2) Nスイッチテストのテストケース作成に使える実用的なツールがない。
(3) そもそも通常の状態遷移テスト(0スイッチテストと同じ)で十分と考えている。

これらのうち(1)については、本当にそう言えるのか疑わしいと思います。状態遷移テストはテストケースあたりのテスト実施時間がかなり短時間であるという特徴 があります。テスト対象が何かにもよりますが、状態遷移テストなら1日当たり100~200件のテストケースを消化することも不可能ではありません。仮に Nスイッチテストによってテストケースが3倍4倍に増えたとしても思ったほどコストは増えないものです。

理由の(2)については、あまり 説得力があるとは思えません。前にも述べましたが1スイッチテストであればツールを使わずに、行列式の積を取るという方法ではなく、各状態ごとに遷移ルー トを追う方法で手作業でテストケースを作成することが可能です。それほど難しいことではありません。やる気さえあればあまり時間をかけずに作成できてしま います。

理由の(3)については裏返せば、Nスイッチテストを行なってもより多く障害が検出できると期待することができない、と考えられているのかもしれません。Nスイッチテストでは、N+1回の状態遷移の経路をすべて網羅するテストを行ないますが、1スイッチテストでは高々2回の状態遷移の経路を網羅するだけであり、そのようなテストで何らかの障害を検出することができると期待することはできないということです。

一般的な状態遷移テストでは、現状態→イベント→次状態のテストケースを使用しますが、結合テストがまがりなりにも行なわれていれば、この方法による総合テストで障害が見つかることはほとんど期待できないでしょう。

障害を見つけ出すには、怪しそうな部分に的を絞って即興でテストを行なうエラー推測などの手法によるテストが必要となります。これには内部データの条件も勘案して境界値分析の手法を適用したり、状態遷移とならないループするイベントを使って何度もループさせるなど、様々な例外的な条件でのテストが有効です。こうしたテストで発見される障害は、単に3つや4つの状態間の遷移を網羅するNスイッチテストのテストケースをそのまま実行しただけでは決して発見することができない性質のものです。

以上から現時点でNスイッチテストがあまり使われていないのは、やはり使ってもより多く障害を発見することができるという見込みが得られないと考えられているためだと思われます。

Nスイッチテスト技法を有益なテスト技法とするためには、何かもう一工夫が必要となるようです。