第177回：　原因結果グラフのREQ制約

≡ はじめに

Twitterで書籍の内容についてご質問をいただきました。

何回かやり取りをしたのですが、140文字で伝えることが困難なのでnoteを書くことにしました。

≡ 原因結果グラフのREQ制約

原因結果グラフが何かは、加瀬さんの以下のページがわかりやすいと思います。

上のサイトにもREQ制約の説明があります。

分かりやすい説明ですが、今回の話の都合上、さらにかみ砕いて書いてみます。

まずは、以下の仕様についてCEGTestツールで原因結果グラフを描いて、デシジョンテーブルを求めます。

ジュースの自販機を思い浮かべていただければと思います。

例えば、デシジョンテーブルのルール#1のテストなら

といったようなテストをします。2番目なら「100円入れて150円の商品は買えません」といったテストですし、3番目なら「200円入れても商品ボタンを押さなければ商品は出てこない」というテストです。

ここで、「お金を先に入れないと商品購入ボタンは光らない」という購入手順があることを思い出したとします。

順序と言えばREQ制約です。同じ原因結果グラフに追記してみます。

デシジョンテーブル内の論理関係に変化はほとんどありませんが、原因結果グラフ（モデル）としては、商品ボタンを押すには先に「入金≧商品代金」にしてねという情報を表しています。CEGTestツールの場合は原因ノードの縦位置に沿ってデシジョンテーブルの行が配置されるので、うっかり、下図のような原因結果グラフを描いて、その後、デシジョンテーブルだけを見てテストをすると失敗するかもしれません。

自動販売機は入金してからボタンを押すのが当たり前と思っている人がいるかもしれません。
ところが、Suicaなどのカードで買うときには、商品を選択してからカードをかざします。つまり、こんな原因結果グラフになります。

≡  疑問点と回答

上記のデシジョンテーブル で、一番納得がいかないことは、「デシジョンテーブルにSuicaのテストが現れない（Suicaは全部F）」ということだと思います。

結論から書きますと、「原因結果グラフは組合せテスト技法」なのでこのようなことが起こります。該当箇所を抜き出してみます。

支払方法が決まった後では、Suicaであろうと現金であろうと論理関係には影響を与えません。言い換えれば、どちらでも良いのでSuicaのテストはなくてよいのです。（組合せテストの前にSuicaの単機能テストは必要です）

次に、支払方法にFがないことが気になる人がいるかもしれません。こちらは制約ONEの影響です。制約ONEは1つだけTになる（全部がFはあり得ないという制約です）ので、支払方法がFになることはないということになります。下図のように、制約ONEを制約EXCLに変更すれば、支払方法がFとなるテストケースがあらわれます（#2）。たとえば、PayPayでは購入できないことのテストなどをしたければ、こうします。

原因結果グラフが網羅するのは論理部分のMC/DCカバレッジです。ですから基本的に中間ノードの行にはTとFが現れます。（基本的にと書いたのは制約ONEのケースがあるからです）

≡  おわりに

原因結果グラフが作成するデシジョンテーブルには不可解な組み合わせが出ることがありますが、

• 原因ノードについては単機能テスト済みであること

• したいテストがあるならデシジョンテーブル以外のテストも実施すること

で乗り切れるのではないかと思います。

原因結果グラフのテストは「これをしたらバグがすべて見つかるテスト技法」といったものではなく「仕様に記載のある最低限の組合せの規則を網羅するテスト技法」です。

ただし、この「仕様に記載のある最低限の組合せ」のテストができていない組織が多いので、原因結果グラフのテストを行うと一安心という側面も多いものです。