第229回： 「ソフトウェアテストしようぜ」42 CEGTest（12.制約INCL）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「制約EXCL」がテーマでした。
制約EXCLは、「制約ONEにすべてがFalseのケースを追加したもの」でした。言い換えると、「制約EXCLで結ばれた原因ノードは排他的であり同時に”存在する”ことができない。ただし、“すべてが存在しない”ことは可能である」というものでした。
文章だと複雑に見えますので、前回提示した、シフォンケーキセットの例を再掲します。制約ONEと制約EXCLの両方がある原因結果グラフですので、両者の違いを理解し、使い分けられるようになりましょう。
上に「使い分けられるようになりましょう」と書きましたが、実際のところは、制約をかけて、デシジョンテーブルの変化を見て、「これなんか違うかも……。」って気が付いて何度も書き直すことで正解にたどりつけばいいのです。
私なんて、いまだにそうですし。
（そりゃ、試行錯誤の回数はだいぶ減ったけど、その分、複雑な原因結果グラフをつくっているので、一回で満足がいくものは、いつまでたってもつくれません。）
また前回は、EXCLとXORとの違いについても説明しました。3つのノードが全てTrueのときに「EXCLではN/A」、「XORではA」になるという違いです。
ところで、EXCLとXORとの違いについての説明はしましたが、EXCLの方を「制約ONEの特殊ケース（全部Falseが存在する）」ということだけを覚えていれば十分です。
制約EXCLは、XORよりも直感的に使うことができますので、EXCLとXORとの違いについてはそれほど気にしなくて大丈夫だからです。
といいますか、XORとの違いは論理演算に慣れている中級者向けの注意点です。正直、『書くと初心者を混乱させないかなあ』『書かないほうがいいかも』と迷いましたが、初心者もすぐに、中級者になるので書きました。
さて、今回は、5つの制約である、「ONE」、「EXCL」、「INCL」、「REQ」、「MASK」のうち「INCL」について書きます。
制約INCLは、「指定したノードを包含する」という制約です。
（といわれても、、、という感じだと思いますが、ぉぃぉぃ分かります。）
まずは、制約INCLについて説明し、続いて、うっかり間違えやすい落とし穴について書きます。
≡ 制約INCLとは
前回と同様に、まずはドリル本に載せたものを示します。
下図はイベントの来場目的のアンケートシートです。複数の来場目的にチェックすることができますが、[その他]の選択肢があることから、一つもチェックしないことは許されないという仕様とします。このような制約を制約INCLでは取り扱います。
原因結果グラフを示します。
こうすることで、1つも選択されることがないことを制約条件とすることができます。
「ベン図」と「ベン図に対して同等な意味を持つ表」を載せておきます。
比較のために、制約ONEのベン図を再掲します。ベン図の黄色い範囲の違いに注目してください。あと、表の「制約結果： A」の違いにも注目してください。
見比べると「全部FのケースがN/A（適用不可）」である点が共通しています。そういう意味で「制約INCLは制約ONEの複数版」と考えるのがよいでしょう。
制約ONEは「必ず1つだけがTの状態（+全部Fのケースは存在しない）」でしたが、制約INCLは「少なくとも1つはTの状態のものがある（+全部Fのケースは存在しない）」の違いです。
制約INCLを制約EXCLと比較した説明を多く目にしますが、上のように、制約INCLは制約ONEの特殊バージョンと考える方がわかりやすいです。
※ わかりやすいとはいえ、何度も図表を見比べないと腹落ちしません。
制約INCLのイメージを持ってもらうために、もう一つ例をあげます。
# そのラーメン屋の店主は、頑固オヤジで有名です。
店主「ラーメンは何にする？」
客「それでは、味噌ラーメンをお願いします」
店主「味噌ね。トッピングは？」
客「えー。味玉とコーンで」
店主「承知」
※ トッピングとして、「味玉」、「メンマ」、「チャーシュー」、「ほうれん草」、「コーン」、「バター」が選べますが、トッピングなしは、「うちは、素ラーメンは売ってないんだ」と親父に叱られてしまうという頑固仕様です。
※ 余談ですが、鳥取の「素ラーメン」はおいしいです。でも、うどんの出汁を使っているだけで、トッピングはあったような気がします。
以下のような原因結果グラフとなります。
今回もONE, EXCLのときと同様にOR関係のノードに対して制約INCLをつけている点にも注意してください。
ここで、制約INCLを制約ONEに変えても（ORで既に一つずつTのものになっているために）、CEGTestツールは全く同じデシジョンテーブルを生成します。ちょっと直感から外れるかもしれませんね。
■ 制約INCLの注意点
制約INCLのINCLは「inclusive」からきています。日本語で言えば、「包含的」です。
定義は上記の通りなのですが、CEGTestで、部分的に制約INCLを書けると、「なんでそうなるの？」と思うかもしれません。
実際にやってみましょう。
これは、まだ説明をしていないカバレッジ表を見ると意味が分かります。
ここでは、「味玉」と「メンマ」と「チャーシュー」に制約INCLをかけました。
OR演算子からつくられたカバレッジ表にある論理式4から7の行についてはどれも、「味玉がF」と「メンマがF」と「チャーシューがF」の組合せなので、それらの行（網羅）が現れなくなったということです。
こちらはCEGTestツールのロジックがそうなっているということです。
論理式4は制約INCLによってテストできません。（下表参照）
ところが、論理式3をコピペして、「ほうれん草」のところを「F」から「T」に変えることで、制約INCLを保ったまま「ほうれん草」がTのテストをすることができます。（下表を参照してください）
制約ONEの場合にはこんな芸当はできませんが、制約INCLは複数のノードが「T」となることが出来るために可能となる回避策です。
私はこの方法を敗者復活と呼んでいるのですが、残念ながらCEGTestには実装されていません。私が会社でつくった原因結果グラフのツールでは実装したのですが、かなり複雑なロジックとなってしまい、それはそれで問題（ツールに実装したロジック自体にバグがある可能性がある）となりますので、CEGTestのシンプルな実装も悪くないと思っています。
こういうことを書くと不安になる人がいらっしゃるとは思うのですが、カバレッジ表でテストされない論理関係が分かりますので、CEGTestを使うときに不安に思う必要はないことは強調しておきます。なお、カバレッジ表については制約の説明の後に書く予定ですのでもう少しお待ちください。
実は上記に変更してテストをしたとしても、チャーシューのTが結果に影響しているのか、ほうれん草のTが結果に影響しているのかはわかりません。
したがって、敗者復活したテストケースは他のテストケースよりも優先度は下がったテストとなります。しかしながら、元のデシジョンテーブルのルール4のように、全部をTとするテストよりは、ほうれん草のTを確認しているように思います。
以上のことから、制約INCLを一部の要素にだけ指定するときには、自分が意図した結果になっているかデシジョンテーブルと、カバレッジ表を慎重に確認するようにします。
慣れるまでは、制約INCLを一部の要素にだけ指定するという使い方はしないほうがよいかもしれません。
■ 制約INCLの使いどころ
ソフトウェアテストの場合には、制約INCLを使うことでテストを削減できることはほとんどありません。
しかしながら、組合せのモデルとして考えた場合、制約INCLを適切に付与した原因結果グラフは、プログラマーに対して実装の参考になる情報を提供することになります。
≡ おわりに
今回は、「制約INCL」の説明でした。
結論としては、「カバレッジ表を読めるようになるまでは、制約INCLは使用しない」ことをお勧めします。注意に書いたリスクがあるからです。
次回は、「REQ」を書く予定です。制約は全部で5種類なので、残りは、「REQ」と「MASK」2つです。
制約REQについては、以前（2022年5月28日ですのでちょうど1年前）に、「第177回： 原因結果グラフのREQ制約」で書きました。
今回はもっと易しく書きたいと思っています。制約REQは、重要な制約なので上記のnoteと重複する部分もあると思いますが、「大事なことなので2度言います」の精神で書きます。
結論を先に書けば、「REQ」は、操作の順序を指定するときに使うものです。制約EXCLの次によく使います。
◀前の記事へ 次の記事へ▶
この記事が気に入ったらサポートをしてみませんか？