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

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

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

 第3回「ソフトウェアテスト技法ドリル」勉強会に向け、原因結果グラフの勉強をしています。
 ブラウザ上で原因結果グラフを描き、その論理関係からデシジョンテーブルを生成する「CEGTest」というステキツールを、『ソフトウェアテストの勉強室』の加瀬さんが開発されていて、勉強会はこのツールを使っての演習になります。
 さて、こんなに良いツールを与えられても、「グラフ」「ダイアグラム」「マップ」といった、自由に描けるクリエイティブな表現の苦手なわたし。CEGTest様が何をしてくださっているのかを理解するために、デシジョンテーブルの生成を、Excelベースで考えることにしました*1。どんだけExcel好きなんだよ・・・。

命題を分割してみる

 秋山浩一さんの『ソフトウェアテスト技法ドリル』の例題をお借りします。
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

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

 
ロック状態の携帯電話を解除するには、指紋認証を行うか端末暗証番号を入力する
 デシジョンテーブルは論理式に基づくものなのだから、命題が必要です。上の1文から、命題を切り出します。
  • ロック状態の携帯電話をロック解除する
  • 指紋認証を行う
  • 端末暗証番号を入力する
 ここからさらに命題を切り出すべきかは、テストの前提条件次第だと思います。たとえば最初の命題は、「携帯電話がロック状態である」ことが暗黙の前提になっていますが、テストでは条件として切り出すべき命題でしょう。
 一方、「指紋認証を行う」には「指紋認証を行うことのできる機種である」ことが必要ですが、これは前提条件と考えてもよさそう。
 「でしょう」「よさそう」と、適当感が色濃く漂いますが、これは何をテストしたいのかによるものだと、今のところは解釈しています。
 ということで、例題から4つの命題を切り出し、真偽判定できるような表現に修正した以下の4つをExcelに転記してみます。
  • Effect: 携帯電話がロック解除
  • A: 指紋認証パス
  • B: 暗証番号パス
  • C: 携帯電話がロック状態

1-1

論理式を整理する

 Effectをもたらす論理式を、例題の文章から導き、Effectの右に書きます。手抜きのため、ANDは「*」、ORは「+」で表現しています。
1-2
  この論理式を見ると、*と+が混ざってしまっているので、*のみ、+のみの論理式に分割するため、A+BをDで置き換えます。A+Bは「指紋認証パス または 暗証番号パス」なので、Dを「パス」としてしまいます。このDは『ドリル』で「中間ノード」と呼ばれており、適切な中間ノードを見つけることが重要とされています。わたしの理解では、単純に、「Effectを導く論理式に*と+が混じったら中間ノードを作れ」ということでいけるのかな?と考えています。
 Excel表には、Dの行にA+Bと書き、Effectの行はC*Dで置き換えました。
 ここで、置き換えを行ったA+B=Dについて、何らかの制約がないかを考えると、AとBは同時に2つを選択することができない。つまり、EXCL(A, B)という制約があるので、それを追記します。これで、真偽表に展開すべき論理式が出揃いました(青いセル)。

1-3

真偽表に展開する、が・・・!?

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

1-4

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

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

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

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

1-5

 上の表は指紋で、下は暗証番号でそれぞれ認証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)。