原因結果グラフとCEGTestに関する考察 - その1

　第3回「ソフトウェアテスト技法ドリル」勉強会に向け、原因結果グラフの勉強をしています。
　ブラウザ上で原因結果グラフを描き、その論理関係からデシジョンテーブルを生成する「CEGTest」というステキツールを、『ソフトウェアテストの勉強室』の加瀬さんが開発されていて、勉強会はこのツールを使っての演習になります。

　さて、こんなに良いツールを与えられても、「グラフ」「ダイアグラム」「マップ」といった、自由に描けるクリエイティブな表現の苦手なわたし。CEGTest様が何をしてくださっているのかを理解するために、デシジョンテーブルの生成を、Excelベースで考えることにしました*1。どんだけExcel好きなんだよ・・・。

命題を分割してみる

　秋山浩一さんの『ソフトウェアテスト技法ドリル』の例題をお借りします。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ロック状態の携帯電話を解除するには、指紋認証を行うか端末暗証番号を入力する

　デシジョンテーブルは論理式に基づくものなのだから、命題が必要です。上の1文から、命題を切り出します。

• ロック状態の携帯電話をロック解除する
• 指紋認証を行う
• 端末暗証番号を入力する

　ここからさらに命題を切り出すべきかは、テストの前提条件次第だと思います。たとえば最初の命題は、「携帯電話がロック状態である」ことが暗黙の前提になっていますが、テストでは条件として切り出すべき命題でしょう。
　一方、「指紋認証を行う」には「指紋認証を行うことのできる機種である」ことが必要ですが、これは前提条件と考えてもよさそう。
　「でしょう」「よさそう」と、適当感が色濃く漂いますが、これは何をテストしたいのかによるものだと、今のところは解釈しています。

　ということで、例題から4つの命題を切り出し、真偽判定できるような表現に修正した以下の4つをExcelに転記してみます。

• Effect: 携帯電話がロック解除
• A: 指紋認証パス
• B: 暗証番号パス
• C: 携帯電話がロック状態

論理式を整理する

　Effectをもたらす論理式を、例題の文章から導き、Effectの右に書きます。手抜きのため、ANDは「*」、ORは「+」で表現しています。

 　この論理式を見ると、*と+が混ざってしまっているので、*のみ、+のみの論理式に分割するため、A+BをDで置き換えます。A+Bは「指紋認証パス または 暗証番号パス」なので、Dを「パス」としてしまいます。このDは『ドリル』で「中間ノード」と呼ばれており、適切な中間ノードを見つけることが重要とされています。わたしの理解では、単純に、「Effectを導く論理式に*と+が混じったら中間ノードを作れ」ということでいけるのかな？と考えています。
　Excel表には、Dの行にA+Bと書き、Effectの行はC*Dで置き換えました。

　ここで、置き換えを行ったA+B=Dについて、何らかの制約がないかを考えると、AとBは同時に2つを選択することができない。つまり、EXCL(A, B)という制約があるので、それを追記します。これで、真偽表に展開すべき論理式が出揃いました（青いセル）。

真偽表に展開する、が・・・！？

　上の表の#a・#bともに2つの論理式の組み合わせですので、真偽表は4行ずつ。ただしEXCL制約により、AとBがともに真になるケースは相殺しており（灰色のセル）、真偽表には7行が残ります。

　これは、CEGTestで導くカバレッジ表と一致するものと思っていましたが、一致しません。カバレッジ表には、黄色にした行が存在しないのです。

　CEGTestでC=A*Bのグラフを書くと、カバレッジ表には「AもBも偽」というケースがそもそも現れません。AND条件の場合、「どちらかが偽なら偽判定なんだから、両方偽はいらんだろう」という意味の省略なのでしょうか。同様に、C=A+Bとすると、「AもBも真」というケースが現れません。これが、原因結果グラフの性質なのか、CEGTestの仕様なのか、わたしにはわかりません*2
　真偽表ではEXCL制約により、BとCがともに真となるケースを消しこんでいましたが、CEGTestで実際にグラフを書いてみると、このEXCL制約があってもなくてもカバレッジ表・デシジョンテーブルの内容は変わりません。

デシジョンテーブルに詰め込む

　さて、この真偽表には、検証すべき単純な論理式が出揃っています。これをデシジョンテーブルに詰め込むアルゴリズムをわたしは知りませんが、この7行なら詰め込みパターンは2つしかありません。

　上の表は指紋で、下は暗証番号でそれぞれ認証OKとなるパターンですね。

　最後の詰め込みの段階で、恣意性が現れるようです。
　(C, D, Effect) = (T, T, T)と、(A, B, D) = (F, T, T)はそれぞれ必ず(？)デシジョンテーブルに現れて検証されるが、その2つを組み合わせた(A, B, C, D, Effect) = (F, T, T, T, T)が現れるかはわからない、ということですね。

　Pairwise法が、2項目間の値の組み合わせを網羅するのに対し、原因結果グラフに基づくデシジョンテーブルは、すべての原子的な（？）論理式を網羅する、・・・ということになるのかなあ*3

　と、原因結果グラフからカバレッジ表、そしてデシジョンテーブルに変換するCEGTestが何をしているのか、少しはわかりかけてきた気がしますが、やはりわからぬ点もたくさんあります。まずは宿題を終わらせて、当日張り切って臨みます。

 

　その2はコチラ。

www.kzsuzuki.com

*1:本エントリは、原因結果グラフの解説でも何でもありません。ほとんど、備忘録といってもいいものございます。

*2:『ドリル』の著者・秋山さん（@akiyama924）に、Twitterでコメントいただきました。「AもBも偽」が現れないのはCEGTest固有の仕様ではなく、原因結果グラフの一番のポイント、とのことです。
また、CEGTestの加瀬さん（@softest）にも補足いただきました。原因については、真と偽がそれぞれ最低1回ずつは出現する実装になっているとのことです。
どうもありがとうございました！(2011/2/4)。

*3:これは間違いですね。AND条件においては2つ以上が偽となる真偽パターンは割愛。OR条件においては2つ以上が真となる真偽パターンを割愛しているので、「一定の優先度以上の真偽パターンを網羅する」というのが正しそうです。この割愛によって、N個の真偽の組み合わせ2^Nパターンのうち、N+1個が、最低限網羅されることになります。(2011/2/4)。