第232回：　「ソフトウェアテストしようぜ」45　CEGTest（15.制約MASK後編）

◀前の記事へ　次の記事へ▶

≡ はじめに

前回は、「制約MASK」の概要がテーマで「制約MASK」を使用する例を書きました。

前回のまとめは以下の通りです。

ただし、前回は「制約MASK」を使用した原因結果グラフとそのデシジョンテーブルの提示はしてみたものの、noteが長くなってしまい、それらの図表についてはほとんど説明していません。

そこで、今回は「制約MASK」の前編の続きとして、例題の解説を書こうと思います。

≡ 制約MASKの例題を細かく見ていこう

まずは前回の例題と解答例（ほかの原因結果グラフでも表現できますので“例”です）を再掲します。

《例題》
以下の図は、スケジュール管理アプリにある、【予定】の「タイトル」と「予定時間（開始・終了日時）」を入力する画面です。

この図をよく見ると、日時は、2010年8月3日10時から同日の17時となっています。つまり、その日はハイキングの予定ということです。
であれば、一日中ということで、[終日]のチェックボックスをチェックしてみます。ダイアログは、以下に変わりました。

「上記ダイアログの原因結果グラフとデシジョンテーブルを作成しなさい」というのが、制約MASKの例題です。

ちなみに、13年後の（現在の）OutlookのGUIは以下のように変わっていました。

話を例題に戻します。
前回、解答例として、以下の原因結果グラフとデシジョンテーブルを載せました。

上記の原因結果グラフを「読み解く」ことはそれほど難しいことではありません。でも、ゼロから描いてみると案外描けないものです。もし、自分で描いていない人は今からでも遅くないので、腕試しとして、いったん、上の例題までスクロールして、CEGTestへアクセスして原因結果グラフをつくってみることをおすすめします。

それでは原因結果グラフとデシジョンテーブルを読み解いていきましょう。

■　原因結果グラフの読み解き

まずは、原因結果グラフの読み解きですが、原因結果グラフは描く必要がありますから、描き方について書きます。

原因結果グラフの描き方ですが、まず初めに「1番左に原因ノード」、「1番右に結果ノード」を配置します。

上記原因結果グラフの原因ノードの「開始日」、「ユーザー指定開始時刻」、「終了日」、「ユーザー指定終了時刻」、「終日」の5つすべてが入力である点に注意してください。
ほとんどのケースで、「原因ノード　＝　入力」です。

次に、右端にある結果ノードの「日時」ですが、「スケジュールに登録するイベントは、 いつから、いつまでなのか？」を「日時」と表現しています。「予定日時」でもよいですし、「開始終了日時」でもよいでしょう。

さて、最左端の原因ノードと最右端の結果ノードが決まったところで、次はその間に位置する「中間ノード」を見つけていきます。
以前にチラッと書きましたが、中間ノードは結果ノードから原因ノードに向かって作ると上手くいきます。

結果ノードを起点として、順番に分解しながら中間ノードを見つける方法ですが、具体的には、次のようにします。
まず、結果ノードである「日時」について考えます。すると、「日時」すなわち、「スケジュールに登録するイベントは、 いつから、いつまでなのか？」の指定方法には、「時刻まで指定する方法」（便宜的にここでは「時刻指定」と呼ぶ）と「日付のみで指定する方法」（日付指定）の2種類があることがわかります。
　　日時　＝　時刻指定　∨　日付指定
です。
ここから、「日時」という結果ノードをORで分割できることが分かったので、以下のような中間ノードと、その構造が見つかります。

次に「時刻指定」には何が必要かな？と考えます。
すると、「時刻指定」には「開始日時」と「終了日時」の情報が必要ということに気が付きます。
　　時刻指定　＝　開始日時　∧　終了日時

　　これで、全体として結果ノードをここまで分解することができました。

今回は、これ以上の分解は不要で、すべて原因ノードにつながりました。

あとは、原因ノードの同値分割と、制約をつけるだけです。今回は、原因ノードの粒度は十分に詳細化されています。そこで、同値分割はテストデータを作成するときに考えるとして、制約MASKをつけました。

■　デシジョンテーブルの読み方

原因結果グラフの描き方がわかったところで、次は、CEGTestツールが生成したデシジョンテーブルの読み方（つくるのはCEGTestなので、読めればOK）です。

デシジョンテーブルの2, 5, 6列では、制約MASKの起点ノードの[終日]がTとなっています。冒頭にも書きましたが、制約MASKは以下のノードに影響を与えます。

今回で言えば、上記の「a」が[終日]にあたり、「b」は「ユーザー指定開始時刻」と「ユーザー指定終了時刻」の2つです。だから、デシジョンテーブルの2, 5, 6列の「ユーザー指定開始時刻」と「ユーザー指定終了時刻」は「M」となっています。前回のベン図を再掲します。

AがTのときには、BとCが「M」になっています。「制約MASKのベン図と同等の真理値表」も再掲します。

制約Mの真理値表は組合せを無くするものではありません。上表の「制約結果」を見ると全て「A」なので、組合せは取りえます。制約Mは、制約を受ける先をMに変えてしまうということです。

さて、ここで、デシジョンテーブルの#2列に着目します。
「ユーザー指定開始時刻」と「ユーザー指定終了時刻」が[終日]ノードが「T」となったことを受けて、「M」となっています。また、その結果、「開始日時」と「終了日時」が「I」となっています。

CEGTestのヘルプには、「I」の説明として、「原因側のノードが真偽不明のため真偽が決定できない。」と書いてあります。

この意味ですが、以下の赤く囲った部分に着目してください。

赤く囲った部分を論理式で書くと、
　　開始日時　＝　開始日　∧　ユーザー指定開始時刻
となります。ここで、#2列を見ると「開始日」はTで、「ユーザー指定開始時刻」はMです。この値を上記式に代入します。
　　開始日時　＝　T　∧　M
Mはノード自体がなくなっている（TかFか確認できない）という意味です。「ユーザー開始時刻」はダイアログからも消えていました。（下記参照）

さて、
　　開始日時　＝　T　∧　M
をどう考えるかですが、「Mは無いのですが、∧演算子は残っている」と考えます。

演算の結果は以下のルールで決まります。

今、MはTとFのどちらであるかわからないのですから、開始日時についてTかFかはわからないという状況になります。これが「I」という意味です。CEGTestのヘルプを再掲します。

さて、それではデシジョンテーブルの#5列にはなぜ「I」があらわれないのでしょう。それは、開始日にFが設定されているからです。
開始日時　＝　F　∧　M
ですから、MがTでもFでも開始日時はFになることがわかります。

#5列の終了日時と#6列目の開始日時が「I」になっていないのは、、、おそらく、CEGTestのバグです。でも、表示だけの問題なので、テストとしては大丈夫です。
大丈夫なことは次回以降のカバレッジ表の見方が分かれば納得できます。

▪️ XCEGの結果

昔つくったツール（XCEG）の結果も載せておきますね。

「I」の表示は期待通りでした。
さらに違いが見つかりました。
「I　∧　I」の結果がCEGTestでは「F」XCEGでは「i」（オレンジ色のセル）になっていたのです。（「I」は「真偽が決定できない」意味ですから、演算した結果も真偽が決定できないということで、小文字の「i」にしたのでしょう。「F」よりも妥当とは思いますが、[終日]が「T」の時には、日付指定が「T」で日時指定が「F」でしょうから「F」でもいいのかもしれません。
ちょっと曖昧な書き方をしているのは、制約同士が矛盾した場合どちらを優先すべきかというちょっと難しい問題……この連載ではこれ以上触れない予定です……があるからです。）

≡  おわりに

今回は、「制約MASK」の例題の説明でした。

最後にCEGTestのバグが見つかって、ヒヤッとしました。
制約MASKはあまり使いませんが、CEGTestツールのバグ（#5, #6列の「I」表示）は直してほしいなと思いました。ソースが提供されているのだから「自分で直せ」って話なのですが……。

そして、「制約MASKのトリガーになるノードをTとしたテストを徹底的におこなう」という話も書きました。こちらは原因結果グラフを描かなくても仕様書や要件定義書を読んで、何かの機能を隠すものを見つけたら、そこを注意深くテストすれば良いです。テスト担当者なら無意識でおこなっていることとは思うのですが、「境界」や「空欄」と同じように、意識してテストをつくることをお勧めします。

さて、次回以降ですが、数回にわたって、カバレッジ表について書く予定です。

◀前の記事へ　次の記事へ▶