第219回： 「ソフトウェアテストしようぜ」33 CEGTest（4. ロジックを網羅する 前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「ペアワイズとの違い」をテーマに「直交表」と「原因結果グラフが生成したデシジョンテーブル」の比較をしました。結論をまとめると以下の通りとなります。
網羅しようとしているものが「組合せ」なのがペアワイズで、「ロジックと制約」なのが原因結果グラフ。
ただし、「ロジックと制約」を網羅する具体的手法については書いていません。今回から数回に分けて書く予定です。
ひょっとしたら以前書いた「デシジョンテーブルの簡単化」を思い出した人がいらっしゃるかもしれません。
はい。結論から言えば、「MC/DCを満たすことがロジックを網羅する鍵」となりますので、同じ話です。前回よりも詳細で丁寧な説明になるように書く予定です。
ということで、今回は、「ロジックと制約を網羅する」の前半にあたる「ロジックを網羅する」のさらに前編です。
ロジック（を実装する論理演算子）の代表的なものには、NOT, AND, ORの3つがあります。
原因結果グラフではこの3つだけを知っていれば大丈夫です。
この3つに加えて、NOR, NAND, XOR, XNORを取り扱える原因結果グラフツールも存在します。しかし、CEGTestで扱える論理演算子はNOT, AND, ORのみです。
また、以下の3つの理由から、NOT, AND, ORのみを使用することをお勧めします。
1. 原因結果グラフの作成ミスを防止する
NOR, NAND, XOR, XNORを使用すると、モデリングするときに間違いが入り込みやすいので、原因結果グラフの作成ミスが増えます。逆に、NOT, AND, ORのみを使用することで、易しくシンプルに表現できます。
2. 原因結果グラフのレビューを楽にする
難しい論理演算子を使うと、原因結果グラフのレビューをするときにレビューアにXNOR等の意味を説明する必要が生じます。また、NOR, NAND, XOR, XNORの論理記号を知っている人は少ないです。
3. NOT, AND, ORの3つで表現できないロジックは存在しない
例えば、NORであれば、ORの結果ノードのNotを取ることで実現できます。このようにNOR, NAND, XOR, XNORの論理演算子は必須ではありません。
また、論理演算子の種類を減らすことだけが目的であれば、NORだけあればよいのですが、それでは図がかえって複雑になってしまいます。
実は、私が使っていた”SoftTest”と”Caliber RBT”というツールは、NOR, NAND, XOR, XNORに対応していました。でも、上記の理由で、NOT, AND, ORのみを使っていました。
さて、先にお断りすると、文字数の関係から今回は、Not関係までとなります。（目安としている4000文字/記事を超えてしまったためです）
ANDとORは次回となります。（ゆっくり・ゆっくり進みます）
「制約を網羅する」のほうは、早くても1か月後になりそうです。
≡ ロジックを網羅するとは
前回の最後のほうに書いたことを図にしてみます。
前回は制約の種類の話はしていないので、図中の制約の右にあるONE, EXC, INC, REQ, MASKについては今は気にしなくて大丈夫です。
原因結果グラフをつくる目的はビジネス・ルールを図化し、そこから（簡単化した）デシジョンテーブルを作成することです。図にすることで、ビジネス・ルールの理解がしやすくなりますし、ビジネス・ルールの変更があったときに、原因結果グラフを直すだけでデシジョンテーブルが自動的に作り直されるメリットがあります。
デシジョンテーブルを作成する目的は、デシジョンテーブルをテストすることで、ビジネス・ルールが正しく実装されたことをテストして明らかにするためです。
ちょっと概念的な話が続き、わかりにくくなっているので、以下では具体例で確認していきます。
≡ ロジックを網羅する具体例
前回は、以下の原因結果グラフを描きました。
以下のように複数の原因ノードが一つの結果ノードにANDやORのロジックで集約される形のほうが馴染みがあって、わかりやすいと思ったからです。
上記は、マイヤーズの三角形のデシジョンテーブルを生成する原因結果グラフです。「第177回： 原因結果グラフのREQ制約」のキャッチイメージにしたのは、多くの方が認識されている“典型的な原因結果グラフのイメージ”だと思ったからです。
しかし、もっとシンプルに、原因と結果を線でつないだだけのものも立派な原因結果グラフです。前回の例題は下記の原因結果グラフでも表現できます。
もっとも、例題にある「組み合わせて使用する仕様」について表現されていないといえば、その通りです。
例題：
文字を修飾する機能に「太字」、「斜体」、「下線」の3つがある。これらは組み合わせて使用することができる。
テストケースを作成しなさい。
一方で、「太字」、「斜体」、「下線」の3つの機能の”単機能テスト”をモデル化したものとしては、つなげるだけで十分です。
「太字」、「斜体」、「下線」とも同じパターンなので、「太字」の原因結果グラフとデシジョンテーブルでロジックの網羅を確認してみます。
このときにCEGTestが自動生成したデシジョンテーブルは以下のとおりです。
デシジョンテーブルの#1, #2など 、列のことをルールと呼びます。
また、デシジョンテーブル内の「T」は「True（真）」、「F」は「False（偽）」を意味します。
True（真）とFalse（偽）ですが、計算機上では”０以外”＝True、”０”＝Falseをあらわします。Trueは0以外ですので、1,2,3…および-1,-2,-3…等々はすべてTrueです。
初めて知ったという方は、混乱するといけないので、この枠内の先の文は読み飛ばすほうが良いです。
余談ですが、「集合」について、私は小学校で習いましたが、最近のカリキュラムでは高校の数Ⅰ（一部は、数A）で習うそうですね。
気になったのでアンケートを取ってみました。
さて、話を戻すと、この「０が偽」と間違いやすいものがあります。
それは関数の戻り値です。
C言語では、「return 0」を関数内で実行すると、その関数の戻り値は0となります。これは、「関数が正常終了したこと」を意味します。また、0以外のときには「関数が異常終了したこと」を意味します。（C言語的には、関数の戻り値が0と0以外というだけで、プログラマーが、その意味を一般的に正常終了と異常終了に解釈するというだけですが）
これは、「正常終了は1通りしかないけれど、異常終了は異常の種類が複数あることが想定されるため、どのタイプの異常が発生したかを戻り値で関数を呼んだもとのルーチンに知らせよう」ということです。
（たまに、文字列の長さを調べるstrlen関数のように、“成功したときに文字列の長さを戻り値にする”ような関数もありますので、必ず関数が異常終了したとは限りませんが）
さて、ここまでは納得したとします。
実は、C言語でmain関数内のreturnはコマンドの戻り値となります。
そして、シェルプログラムでは、「&&」でコマンドを連結することで、前のコマンドが成功した場合、次のコマンドを実行する仕組みがあります。
$ commandA && commandB
と書けば、commandAが正常終了したときに、commandBを実行します。（ここで先頭の$はプロンプトを表しています）
それで、これについて、
「0 && commandB」だよね、
0は偽だから論理式的に変じゃない？
というように、混乱する人がいます。「論理型（boolean type）データの真/偽の値」と「関数の戻り値」の話は分けて考えましょう。
さて、話をデシジョンテーブルに戻します。デシジョンテーブルを再掲します。
ルール1では原因である「太字にチェック」をT（True:真）にしたときに、「太字修飾された文字」という結果がTになるというテストケースを表しています。ルール2は「太字にチェック」をF（False:偽）にしたときに、「太字修飾された文字」という結果がFになるというテストケースです。
上記の原因結果グラフで表しているビジネス・ルール（のロジック部分）は、「原因が真のときの結果は真」、「原因が偽のときの結果は偽」の2つであり、デシジョンテーブルはその2つを網羅しています。
なお、このような1対1の関係にはNotの関係もあります。
例題：
ユーザーの新規登録はログインしていないときに可能。
テストケースを作成しなさい。
ログインしているときに「ユーザーの新規登録」メニューは現れないという仕様のテストです。原因結果グラフはこうなります。
CEGTestツールではNotは線の色と「～」マークで表現します。論理記号のNotは「￢」なのですが、線上に描くと見ずらいためです。
「N」がふにゃっとして「～」になったと思うとわかりやすいと思います。
≡ おわりに
今回は、「ロジックを網羅する」の前編でした。ロジックはシンプルなものです。
ところで、1対1なものにいちいち原因結果グラフを使うのか？というとどうかなとも思うのですが、ユニットテストをつくるときは案外アリです。単純につくっていくことで漏れなくテストケースができていくからです。
次回は、今回の続きとなる「ロジックを網羅する」の後編となります。
残りのANDとORが網羅するものについて確認していきます。原因結果グラフの肝の部分です。
次回の話が腹落ちすると原因結果グラフが使いたくなりますので、分かりやすく書きたいなあと思います。