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