第235回： 「ソフトウェアテストしようぜ」47 CEGTest（17.カバレッジ表後編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「カバレッジ表」の概要説明でした。
CEGTestツールを使っていても、カバレッジ表については、邪魔だなぁと閉じてしまう人が多いのですが、まずは、デシジョンテーブルをみて「なんか変だなぁ？」と思ったときに、カバレッジ表を見るとどうしてこのデシジョンテーブルになっているか、その原因がわかるかもしれません。
さて、前回は、カバレッジ表が何ものかを分かっていただくため、階層がなく最も単純な∨ひとつと制約ONEがひとつの原因結果グラフを使いました。
階層を持つ普通の原因結果グラフもCEGTestでは全く同じロジックを繰り返して作っているだけです。
今回は、カバレッジ表のフォーマットについて確認することで、カバレッジ表の見方をマスターしたいと思います。
上で「CEGTestでは」と書いたのは、「制約INCLの回」で書いた「敗者復活」がCEGTestでは実装されていないからです。
でも、「敗者復活」なんて怪しいロジックは実装せずにカバレッジ表で「この組み合わせは制約XXXのためにデシジョンテーブルには表れていませんよ」と教えてくれるだけで十分ですし、その方が、（その個所について丁寧にテストをすることで）テスト対象のバグに気が付くので良いと思います。
≡ カバレッジ表のフォーマット
前回は、「現物を見て感じろ！」的な説明でしたので、カバレッジ表のフォーマットについて説明します。
今回の例題は、CEGTestのヘルプにあるカバレッジ表です。
上記のテスト対象はこちらです。
2007年のJaSST東京（の色モノセッションミニパネル）で、池田さんと前畑さんがモデレータをされ、同じお題に対して、鈴木三紀夫さんがデシジョンテーブル、私が原因結果グラフ、そして、松尾谷徹さんがCFD法を使用して解くことでデシジョンテーブルと原因結果グラフとCFD法の勘所をお伝えしようというもので、青・赤・黄のマント（ただの布です）をまとって、松尾谷さんなんて、テンガロンハットまで被ってノリノリでプレゼンしたものです。16年前かぁ。
そんな話はどうでもよいのですが、このときの資料に原因結果グラフがのっています。
当時はCEGTestはありませんでしたので、以前ちらっと出てきた、X-CEGツールを使って原因結果グラフを描いています。カバレッジ表は、この問題では省略していますね。（2問目のほうでは載せています）
ということでCEGTestで描きなおします。
さて、本題のカバレッジ表のフォーマットです。カバレッジ表は以下のように、大きく3つのエリアに分かれています。
行の論理式 1から論理式 5は、中間ノードの「ボタン押下」の∨を、論理式 6から論理式 9は、結果ノードの「音が鳴る」の∧で網羅すべき組み合わせです。
■ 赤色のエリア
赤色のエリアは原因結果グラフのノードが列見出しになっています。以下に論理式が1の赤色エリアだけ抜き出してみます。
論理式1では、「正解がT（True）、不正解がF（False）、ファンファーレがF、出題がFのときに、ボタン押下がT」の組合せロジックを確認しています。
これを論理式で書くと、
（正解 ＝ T）∧（不正解 ＝ F）∧（ファンファーレ ＝ F）∧（出題 ＝ F） ＝ （ボタン押下 ＝ T）
となります。
ここで、「正解 ∨ 不正解 ∨ ファンファーレ ∨ 出題 ＝ ボタン押下」という原因結果グラフなのになんで、上の論理式は【∧】なんだよ？と思われた人がいらっしゃるかもしれません。
何を隠そう、私も初めて、この表記を見たときに、「なんでだよー。このドキュメント間違っているんじゃないの？」と思った一人です。
実は、カバレッジ表から論理関係を読み取ったときには、それがなんであろうと【∧】でつないで書くというお約束があったのです。【∧】で書いておけば、各ノードのTとFが一つでも表の中の指示と違っていたら成立しないからです。ツールの内部でも、網羅すべき組み合わせを∧で計算してピックアップしていると思います。（少なくとも、X-CEGはそういう実装です）
■ 青色のエリア
例題の青色のエリアの列見出しは、#1, #2 , #3 , #4で 、「#数字」となっています。この数字は、デシジョンテーブルの列番号と対応しています。
デシジョンテーブルの#1では電源がTとなっていますが、カバレッジ表の#1列をみると、電源の行に「x」が入っています。
ここで、「#」と「x」の違いはCEGTestのヘルプにあるとおりです。
要するにデシジョンテーブルに1回だけ現れる場合は#、複数回現れる場合はxです。
普通は、CEGTestで生成したデシジョンテーブルは全てのルールをテストしますので、「#」と「x」の違いについては気にする必要がありません。
何らかの理由で、全てのルールをテストすることができない場合に、カバレッジ表の青いエリアの列の「#」と「x」の数をカウントして#の数が多い列を優先するという使い方をします。
他には、#の数が多い列から順番にテストすると、早く網羅率を上げることができます。でも、こちらもCEGTest1の網羅率は100%にする人がほとんどですし、そうするほうが良いので、カバレッジ表の表記のお約束と思うくらいとして、質問されたときに答えられれば十分と思います。
■ 黄色のエリア
最後に黄色のエリアですが、ここは備考列です。
ここには、「なぜ、その論理式がデシジョンテーブルに無いか」の理由が書かれます。例えば論理式5について、
とあります。
論理式5は、正解と、不正解と、ファンファーレと、出題の全てのノードがFになるときにボタン押下の中間ノードがFとなる論理式、つまり、
（正解 ＝ F）∧（不正解 ＝ F）∧（ファンファーレ ＝ F）∧（出題 ＝ F） ＝ （ボタン押下 ＝ F）
という論理式について、制約ONEを適用したため、デシジョンテーブルには出現していないということを表しています。（カバレッジ表では灰色で表現されます）
≡ おわりに
今回は、「カバレッジ表」のフォーマットについてでした。
灰色の行があったら、必ず備考列を確認して納得するという習慣づけをすることで、CEGTestが何を網羅して、何を網羅していないのかが分かります。
次回は、最終回として、CEGtestで触れていない「実行不可」と「テスト不可」の違いと、全体のまとめについて書こうと思います。