第137回：　CFD法　その8（CFDからデシジョンテーブル　後編）

≡ はじめに

前回は、「CFD法　その7（CFDからデシジョンテーブル　前編）」と題し、「作成したCFDからデシジョンテーブルを作る基本的な方法」について説明しました。

“基本的”と書いた通り、前回の方法でテスト設計を進めても構いません。それで組合せ爆発が起こるなら設計が悪いのですから。そのときには、開発者と一緒にCFDを描きながら（テスト対象物の）設計を見直せば良いという考え方です。

と、このように正論を並べてみても、現実問題として「そんなことはできない」場面はいくらでもあります。
例えば、「設計までは（立場が強い発注元の）別会社が行う」などのケースでは設計の改善が難しいことでしょう。
仮に、設計の悪さを元請が認めたとしても「次回から改善しますので、今回はよろしくお願いします」と言われるのが御の字です。他にも第三者検証会社もお客様の設計の悪さに言及しにくいかもしれません。（第三者検証会社であっても、悪いものは悪いと指摘する方が良いのですが、コトはそう単純ではありません）

そのようなときには、コストを追加投入して人海戦術で乗り切るか、納期を延ばしてテストの自動化で乗り切るかのどちらかを選びがちですが、そのどちらもできないときがあります。
そんなときは以下の手順でテストの網羅基準を調整することでテストケースを減らします。

今回は、同値図の中の同値クラスがたくさんあった場合に、「同値クラスの関係（ANDとOR）」に着目して「有効系のフローを減らす方法」について説明します。（無効系のフローを減らす方法は前回の通りです）

// デシジョンテーブル の簡単化とはちょっと違います。 //

≡ CFD法の課題

CFD法には、「ORによる組合せ爆発」という課題がありました（今もすべてが解決しているわけではありません）。まずは、CFDの同値クラスのANDとORについて説明します。

■　CFDの同値クラスのAND

CFDに慣れてきたと思いますので、抽象的なCFDで説明します。

「まだ慣れていないよー」というかたは、CFD法の連載だけ抜き出してマガジンにまとめましたので、復習してください。本当は、Twitterや質問箱で質問してくださるとよいのですが。

今回の結果表記は、前回の最後の方に軽く説明した同値分割図の形式にしています。結果ノードでも結果の同値分割図でも、自分が描きやすい方で構いません。

※ 松尾谷氏の手順にしたがって先に結果の同値分割を行えればベストなのですが、それは難易度が高いです。
多くの場合は、処理フローの出口に結果ノードを置く方が簡単です。

ただし、テスト対象に、入力条件が少ない（あるいは無い）、自由度の高いソフトウェアの場合は、難しいと言っていられません。
そのようなときには、要求やユーザーストーリーのゴールを参考にして結果の同値分割を先に行ってください。（そのどちらも無いときには、「こんなんじゃ、まともなテストなんてできない」って暴れる、、、あるいは呆れてみせる、、、ことも大切と思います。）
他にも市場条件が多すぎるときには、結果の同値分割が有効です。
入力の自由度が高い例としてはGoogleの検索機能、市場条件が多すぎる例としてはカーナビのテストを想像していただければと思います。
※ カーナビの走行テストでは、「河津七滝ループ橋」や「高層ビルに挟まれた道路のXX時XX分（GPS衛星が1つしか受信できなくなる場所とタイミング）」といった、“特別（過酷？）な条件下でゴールを設定したシナリオテスト”が欠かせません。

CFD法以前の話として、そもそも、そのようなソフトウェアのテストは難しいです。

各同値図のなかの同値クラス「a1, b1, c1, d1, e1」は、有効系の青い流れ線でつながり、最終的に結果の同値図内の「機能が働いた」を実現しています。

ここで、a1, b1, c1, d1, e1は、結果の原因であり、「結果を導く条件の組合せ」とも言えます。

つまり、
a1 AND b1 AND c1 AND d1 AND e1
のときに、「機能が働いた」という結果になります。

これが、「CFDの同値クラスのAND」です。デシジョンテーブルは、次のようになります。

有効系が1つと無効系が5つです。

よく見ると、原因結果グラフの∧（AND）のデシジョンテーブルに似ています。CEGTestツールで確認してみます。

偶然？　んなことはないです。
必然です。

有効系の同値クラスがANDでつながっても、テストケースは爆発しないことが確認できました。次はORのケースです。

■　CFDの同値クラスのOR

こちらも、まずは」CFDを見てみます。

似ていますが、同値図A, B, Cに有効系の同値クラスがひとつずつ増えています。この場合のデシジョンテーブルは、次のようになります。

無効系のテストケースのそれぞれについてどの同値クラスのフローを確認したいのかについて明示にしたいのでオレンジ色をつけてみました。テストスクリプトを作らずに、デシジョンテーブル を見ながらテストを実行するケースでは、このような色付けが案外役に立ちます。

前回の復習となりますが、オレンジ色の列の他の同値クラスの選択はどれを選択してもOKです。例えば、12列目は、
　｛a1, b2, c1, それ以外｝
という条件になっていますが、｛a2, b1, c2, それ以外｝でも、｛a1, b1, c1, それ以外｝でも構いません。それがCFD法の無効系のテストケースの作り方です。

デシジョンテーブル ですが、今度は、有効系が8つと無効系が5つとなりました。
先のANDのほうでは、有効系が1つと無効系が5つでした。無効系の数は同じなのに、有効系の数は1個から8個へと激増しています。

もし、同値図Dの同値クラスも｛d1, d2｝と2つに増えれば、有効系が16と無効系が5つとなります。つまり、有効系はORがあると、どんどん増えていくということです。

このように、ORが増えると「組合せ爆発」が起こります。

ご参考までに、こちらもCEGTestの結果を張っておきます。

こちらは、同じには見えません。
CEGTestではORの場合もMC/DCカバレッジ基準で、組合せを減らしているからです。

≡ 有効系の減らし方

上に、「ORが増えると組合せ爆発が起こります」と書きました。有効系について、全組合せを作ろうとすればそうなります。

そこで、“全組合せでなくても良い部分”を見極めて減らそうというアイデアが生まれました。

こちらは、辰巳さんのスライドの11ページの引用です。
※　スライドにある通り、『Introduction to Software Testing』に記載のある「組み合わせテストの網羅基準（やカバレッジアイテム）」を辰巳さんが分かりやすく整理されたものです。

全組合せは、上の表の４行目の基準列にある“AC”です。“AC”以外にも、“EC”と“PW”が良く使われます。シナリオテストでは“BC”も定番です。

ということで、ORのある同値図については、デシジョンテーブルを作る前に同値図間の組合せ網羅基準を決めることで適切な大きさのデシジョンテーブル を作ることができます。

先程の例なら、同値図の関係性を示すために、例えばこんな総当たり表を作って同値図間の組合せ網羅基準を整理します。（同値図よりも細かく、同値クラス間の関係性を整理することもあります）

この図では、「同値図AとBの間の組合せ網羅基準をPW（Pair-Wise）」、「AとCの間の組合せ網羅基準をAC（All Combinations）」、「BとCの間の組合せ網羅基準をAC（Each Choice）」と決めたことを表しています。（同じ同値図は組み合わせられないので“-”で埋めて、左下は右上と同じ組み合わせなので黒く塗りつぶしています）

“同じ同値図は組み合わせられない”について補足説明します。
そもそも、同値図は着目している対象を「（完全）同値分割」して同値クラスに分割したものです。したがって、逆に言うと、ひとつの同値図内に存在する同値クラスは排他の関係ですので一つしか選択できません。
１つなので、組み合わせられないという意味です。
詳しくは、「第133回：　CFD法　その5（同値図 演習解説）」を参照してください。

この情報を使って、先ほどのデシジョンテーブルを見直してみると、

となりました。灰色にした2, 3, 6, 7列がなくても、AとBの間のPW、AとＣの間のＡＣ、ＢとＣの間のＥＣが満たされていることがわかります。（無効系の「それ以外」はそもそも組合せません）

こちらですが、手作業で行うと間違えやすいのでツール化が望まれます。

≡ おわりに

今回は、同値クラスがたくさんあった場合の「有効系の減らし方」について説明しました。次回は、フローパスが長いときの対処方法について説明します。

なお、CFD法を作成した松尾谷さんやデバッグ工学研究所でCFD法の指導をされている堀田さんのようなエキスパートはCFDからデシジョンテーブルを作るときに、慎重に1列（1ルール）ずつソフトウェアの内部構造を想像しながらよりバグが出やすい組合せを狙って作っていきます。匠の技ですね！
エキスパートでしたらそのような作り方もありですが、私のような普通の人は網羅基準を設けて作る方が“なぜそのテストを行うのか”について説明ができますので良いと考えています。