出力の組合せ

昨日の夜、twitter で @kyon_mm さんとやり取りをしていたことをもう少し考えてみようと思う。

もともとは数学的なテクニックを使って、自動的にテストパターンを作成する（したいけど、数学勉強しなきゃなあ）という話が発端だったかと思います。Inputは「入力条件」「出力結果」「論理関係を含むDSL」、Outputは「入力条件・出力結果を含んだ組合せテストケース（テスト条件）」というようなツールを目指しているのだと理解しました。

※DSLはドメイン特化言語で、仕様記述言語を意味するらしい。

ここで「出力結果の組合せ」というのは、何らかのシステムの端末で出力されるエラー通知方法

｛ディスプレイ：”エラーA”を表示、”エラーB”を表示、”エラーA・B”を表示｝、｛エラー音：音１、音２｝

といった要素と値の組合せを指している。

直感的には、出力結果の組合せを考慮するということは、それらになんらかの論理関係（主従関係）がある、ということになり、出力結果の要素のいずれかが他の要素の入力（原因）になっているんじゃないかなと思いました。

ひとつだけディスプレイに表示される場合は音１が鳴り、”エラーA・B”が表示される場合は音２が鳴る

みたいな。こういう仕様がわかっているならば、デシジョンテーブルなどで表現する方法もある。この場合、ディスプレイ表示（または、ディスプレイ表示を引き起こすイベント）が入力条件に位置する。

でも、「出力の組合せ」を考えたいというのは、おそらくはこういった関係性が仕様上ない場合を指しているのではないかと考えました。あるサイトに広告が3種類あって、

｛広告A：a1、a2｝、｛広告B：b1、b2、b3｝、｛広告C：c1、c2｝

といった広告がランダムに表示される、といったシチュエーション。

実際、JavaScriptを含むタグであったりすると、仕様上は存在しない影響を生み出す場合があり、組合せテストはしたいところ。でも、これも単純に広告A～Cの組合せを考えて、影響がないことをまずは確認することで、その後のさらなる結合テストでの検証範囲を狭めればよいのではないかと思いました。