第234回： 「ソフトウェアテストしようぜ」46 CEGTest（16.カバレッジ表前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「制約MASK」の例題の説明でした。
ちょっと難しかったけれど、「制約MASKは使わない」という、ある意味、最強の回避策があります。
最強というのは、制約MASKを使わないで済むようにテスト対象物をつくることが良い設計につながるという意味です。
そうするためには、上流工程の要件定義レビューあたりでCEGTestを使用して「この要件をもっと簡単にしよう」という必要があります。
例えば、例に挙げた、[終日]にチェックを入れると[（ユーザー指定）開始時刻]と[（ユーザー指定）終了時刻]の2つがMASKされて消えてしまうGUIが要件定義書に書いてあったとします。
この要件が通ってしまいますと、「制約MASK」を使う必要が生じます。そこで「別の実現方法を考えられませんか？」と質問します。
前回、上記仕様が13年後にどう変わったかを載せました。
［終日］チェックボックスは無くなっていませんので、制約MASKを使うことになりますが、[（ユーザー指定）開始時刻]と[（ユーザー指定）終了時刻]の2つのGUIアイテムが消えずに残っていることで、テスト設計がずっと容易になっています。
容易になっているように見えない人もいるとは思います。でも、仕様が改悪されるケースは少ないので良くなっていることを前提にしてGUIの改変理由を考えてみると良い訓練になると思います。
さて、原因結果グラフの最難関の制約の説明は終わったので、今回から「カバレッジ表」のテーマに移ります。カバレッジ表が終われば、CEGTestの章は終わりです。
≡ カバレッジ表とは
今回は、カバレッジ表の紹介までとなります。
実際のところ、カバレッジ表について知らなくてもCEGTestで原因結果グラフを入力して生成されたデシジョンテーブルの列をすべてテストしたらいい感じに有則の組合せを網羅したテストになります。したがって、初めのうちはカバレッジ表を積極的に使う動機は少ないものです。
しかし、CEGTestツールが何を網羅したテストをしているのか、CEGTestツールが網羅していない重要なテストとはなにか？
それらの情報が書かれているもの、それがカバレッジ表です。
■ カバレッジ表の読み方
実物を見てもらうのが早いと思いますので、ドリル本の例を引用します。
図3.41は、システムへのログインの原因結果グラフを表しています。システムにログインできるユーザには、「一般ユーザ」と「管理者」の2種類しかないとし、「ログイン」することを確認したいとします（今回はログインしないことはテスト対象としていません）。この場合、原因結果グラフに描かれたとおり、「一般ユーザ」と「管理者」は同時にログインすることができませんから、これらのノードに制約ONEがかかっています。
ここで、カバレッジ表には∧∨に対して確認すべき論理式がすべて書かれています。Tは真（True）、Fは偽（False）を表しています。論理式1では、一般ユーザでログインして成功するケース、論理式2では管理者でログインして成功するケース、論理式3はログインしないケースですが、今回は制約ONEがかかっているため確認できない論理式ですのでモニター上ではグレイ（灰色）表示になっています。
原因ノードが2つあるので、両方が真のケースもカバレッジ表に必要そうな気がしますが、∨条件で結ばれているため両方が真（正確には複数の原因ノードが真）のケースは優先順位が落ちてテスト対象から省かれています（∧で結ばれた場合は複数の原因ノードが偽のケースが省かれます）。
カバレッジ表の#1は、デシジョンテーブルの#1つまり一番目のテストに対応しています。つまり、デシジョンテーブルの1番目のテストは論理式1を確認するために作られたテストに当たります。
以上がドリル本でのカバレッジ表の説明です。
■ 丁寧な説明
決して分かりにくく書こうとしたわけではないため、上の説明でもわかるとは思います。
でも、分かりにくそうなところ（太字箇所）もあるので、そちらを説明していきます。
カバレッジ表には∧∨に対して確認すべき論理式がすべて書かれています。
「∧∨に対して」のところが分かりにくいのではと思います。「∧∨に対して」とは、今回の原因結果グラフで言えば、下図の赤矢印が指している個所のことを言っています。
※ 原因ノードに対してのカバレッジを取ろうとしていないことに注意が必要です。たまに「CEGTestツールがつくるデシジョンテーブルに現れない原因ノードがある（CEGTestのバグだ）」という人がいらっしゃいますが、【単体テストを終わらせてから原因結果グラフを使う】ようにしましょう。
赤矢印の個所は、論理式で書けば、
「一般ユーザー ∨ 管理者 ＝ ログイン」
となります。
したがって、「カバレッジ表には∧∨に対して確認すべき論理式がすべて書かれています。」を今回のケースで書きなおせば、
カバレッジ表には「一般ユーザー ∨ 管理者 ＝ ログイン」という論理関係に対して確認すべき論理式がすべて書かれています。
となります。
上記の文中の「確認すべき論理式」と「カバレッジ表」は同じものです。
そこで、「カバレッジ表」に現れる論理式が、原因結果グラフの論理関係「一般ユーザー ∨ 管理者 ＝ ログイン」のなかで確認したいものになっていることを見ていきます。
カバレッジ表を再掲します。
ログインノードに存在する論理式は、
「一般ユーザー ∨ 管理者 ＝ ログイン」
です。
カバレッジ表の中の「論理式1」では、「一般ユーザーがT（True）で、管理者がF（False）だったときに、ログインがT（True）」（一般ユーザーでログインが成功した状態）であることを意味しています。
CEGTestの５回目を思い出してください。思い出してほしいのは以下の個所です。
■ ORのデシジョンテーブル
1. 全ての条件が「F」の列がある
2. 残りの列は条件が1つだけ「T」となり、残りの条件は「F」
※ 1では、各条件がFの時に、結果がFになること、2では、各条件がFだから結果がFになることを確認している。
カバレッジ表の論理式1と論理式2は上の文章の「2. 残りの列は条件が1つだけ「T」となり、残りの条件は「F」」を、論理式3は「1. 全ての条件が「F」の列がある」に対応しています。確認すべき論理式とは、デシジョンテーブルに列として追加するものということです。（カバレッジ表の#1, #2は、デシジョンテーブルの#1, #2列に対応しています）
≡ おわりに
今回は、「カバレッジ表」とはどのようなものかの概要説明でした。
「カバレッジ表がどんなものかは分かったけど、何に使うの……？」と思う人が多いのではないでしょうか。カバレッジ表のフォーマットの説明もまだですし。
そこで、次回は、カバレッジ表の使い方について書こうと思います。
◀前の記事へ 次の記事へ▶
この記事が気に入ったらサポートをしてみませんか？