強い制約とサブモデルを用いてデシジョンテーブルを自動生成する
これまでこのカテゴリ（PictMasterでデシジョンテーブル）では、組み合わせテストツールであるPictMasterを使ってデシジョンテーブルを生成する方法を説明してきましたが、今回はこれまでの説明とは異なる全く新しい生成の方法を紹介します。この方法はこれまでの方法と比較して非常に簡単で間違いが起きにくい方法です。
説明の例としてある水族館の入場券の発券システムを取り上げることにします。この水族館の入場料は次の表で決められます。
(1) 小学生以下、都内在住・在学の中学生は無料です。中学生は生徒手帳を持参してください。
(2) 障害者手帳・愛の手帳をお持ちの方と、その付添者原則１名は無料です。
(3) ６５歳以上の方は、年令の証明となるものをお持ちください。
生徒手帳の提示のない中学生および年齢の証明となるものの提示のない６５歳以上は一般の扱いとなります。生徒手帳、年令の証明となるものの確認と付添者１名の制限は切符売場窓口の係員が行ないます。
係員は発券システムの画面を操作して入園券を発券します。発券システムの画面を以下に示します。
・ラジオボタンは各区分ごとにかならずどれか１つだけが選択状態となる。
・都内在住と都内在学のチェックボックスは中学生のラジオボタンを選択した場合に選択可能となる。
この動作制限のテストはこの発券システムのデシジョンテーブルテストとは別に行なうことになります。
デシジョンテーブルを自動生成する手順は次の通りです。
１．仕様をもとに条件（パラメータ）とその値およびアクション（入園料）を洗い出す。
２．制約表で各入園料を制約条件とし、その入園料となる必要最小限のパラメータの値の組み合わせを指定する。
３．同じ入園料となる必要最小限のパラメータの値の組み合わせが複数ある場合は、OR条件となるように右隣りの制約に同じ制約条件の色でそれを記入する。
４．サブモデルでアクションを除くすべてのパラメータを指定し、サブモデルの組み合わせるパラメータ数に指定したパラメータの数を記入する。
５．環境設定の組み合わせるパラメータ数に１を指定し、生成を行なう。
以上をもとにこの発券システムのデシジョンテーブルを生成するPictMasterのモデルを次に示します。
制約１では、生徒手帳提示の中学生の場合のみ都内在住と都内在学が選択可能であることを指定しています。この制約指定があることによって、制約２以降での制約指定が簡単になります。
このモデルの生成結果を次に示します。
圧縮したデシジョンテーブルを用いる危険性についてはこれまで述べてきた通りです。どうしても用いたいのであればテスト対象の制御フローを把握し、それに合った圧縮を行なったデシジョンテーブルを用いる必要があります。
今回説明した方法は、アクションを制約条件とし、そのアクションとなる必要最低限の条件の値を制約対象として組み合わせテストツールで組み合わせ可能な組み合わせだけを生成する方法であり、従来の全組み合わせを作成してから個々の組み合わせごとにアクションを記入するという教科書的なデシジョンテーブル作成方法に比べて格段に簡単で間違いの起きにくい方法です。さらに制約表がそのまま圧縮したデシジョンテーブルとなる点でも全く新しい方法です。
また制約指定に「強い制約」を用いることによってテストケース数の爆発を防いでいます。同様に年齢や性別などのようにどれか１つだけが必ず真となる条件は、Yes／Noの２値で表すのではなく、それぞれの値をそのまま用いる多値で表すことによってもテストケース数の爆発を防いでいます。
説明の例としてある水族館の入場券の発券システムを取り上げることにします。この水族館の入場料は次の表で決められます。
(1) 小学生以下、都内在住・在学の中学生は無料です。中学生は生徒手帳を持参してください。
(2) 障害者手帳・愛の手帳をお持ちの方と、その付添者原則１名は無料です。
(3) ６５歳以上の方は、年令の証明となるものをお持ちください。
生徒手帳の提示のない中学生および年齢の証明となるものの提示のない６５歳以上は一般の扱いとなります。生徒手帳、年令の証明となるものの確認と付添者１名の制限は切符売場窓口の係員が行ないます。
係員は発券システムの画面を操作して入園券を発券します。発券システムの画面を以下に示します。
・ラジオボタンは各区分ごとにかならずどれか１つだけが選択状態となる。
・都内在住と都内在学のチェックボックスは中学生のラジオボタンを選択した場合に選択可能となる。
この動作制限のテストはこの発券システムのデシジョンテーブルテストとは別に行なうことになります。
デシジョンテーブルを自動生成する手順は次の通りです。
１．仕様をもとに条件（パラメータ）とその値およびアクション（入園料）を洗い出す。
２．制約表で各入園料を制約条件とし、その入園料となる必要最小限のパラメータの値の組み合わせを指定する。
３．同じ入園料となる必要最小限のパラメータの値の組み合わせが複数ある場合は、OR条件となるように右隣りの制約に同じ制約条件の色でそれを記入する。
４．サブモデルでアクションを除くすべてのパラメータを指定し、サブモデルの組み合わせるパラメータ数に指定したパラメータの数を記入する。
５．環境設定の組み合わせるパラメータ数に１を指定し、生成を行なう。
以上をもとにこの発券システムのデシジョンテーブルを生成するPictMasterのモデルを次に示します。
制約１では、生徒手帳提示の中学生の場合のみ都内在住と都内在学が選択可能であることを指定しています。この制約指定があることによって、制約２以降での制約指定が簡単になります。
このモデルの生成結果を次に示します。
圧縮したデシジョンテーブルを用いる危険性についてはこれまで述べてきた通りです。どうしても用いたいのであればテスト対象の制御フローを把握し、それに合った圧縮を行なったデシジョンテーブルを用いる必要があります。
今回説明した方法は、アクションを制約条件とし、そのアクションとなる必要最低限の条件の値を制約対象として組み合わせテストツールで組み合わせ可能な組み合わせだけを生成する方法であり、従来の全組み合わせを作成してから個々の組み合わせごとにアクションを記入するという教科書的なデシジョンテーブル作成方法に比べて格段に簡単で間違いの起きにくい方法です。さらに制約表がそのまま圧縮したデシジョンテーブルとなる点でも全く新しい方法です。
また制約指定に「強い制約」を用いることによってテストケース数の爆発を防いでいます。同様に年齢や性別などのようにどれか１つだけが必ず真となる条件は、Yes／Noの２値で表すのではなく、それぞれの値をそのまま用いる多値で表すことによってもテストケース数の爆発を防いでいます。
デシジョンテーブルの圧縮でテスト漏れが起きるもっとも単純な例
これまでの記事で、圧縮したデシジョンテーブルでテストを行なうとテスト漏れが起きることを説明しました。今回はテスト漏れが起きるもっとも単純な例を取り上げてみます。
取り上げる例題は電話番号の発信者番号通知処理です。
電話をかけると通常は自分の電話番号が相手に通知されます。これを電話会社との契約によって通知しないようにすることができます。また相手の電話番号の前に特別なダイヤルを付加して電話をかけることによって、相手に自分の電話番号を通知するかしないかを指定することもできます。
この発信者番号通知処理の仕様は次の通りです。
１．電話会社との契約で「通知する」を選択していると自分の電話番号が相手に通知される。
２．電話会社との契約で「通知しない」を選択していると自分の電話番号が相手に通知されない。
３．電話をかける際に相手の電話番号の前に１８６を付加すると電話会社との契約にかかわらず自分の電話番号が相手に通知される。
４．電話をかける際に相手の電話番号の前に１８４を付加すると電話会社との契約にかかわらず自分の電話番号が相手に通知されない。
この仕様から発信者番号通知処理について次のルールが得られます。
１．通知する
(1) 電話会社との契約が「通知する」でかつ付加ダイヤルなしで電話をかける。
(2) １８６を付加して電話をかける。
２．通知しない
(1) 電話会社との契約が「通知しない」でかつ付加ダイヤルなしで電話をかける。
(2) １８４を付加して電話をかける。
このルールをもとに表１の圧縮したデシジョンテーブルが作成できます。実際には付加ダイヤルの種類には別のサービスの関係でこれ以外にもあるのですがここでは問題を単純にするためにこの２種類だけとします。
デシジョンテーブルをテストで使用する場合は必ず圧縮していないデシジョンテーブルを使用する必要があります。ただし、プログラム構造が分っていて、どのような制御フローで処理するかが明確に把握できていて、その制御フローに合った圧縮を行なっているデシジョンテーブルを使用するならその限りではありません。
取り上げる例題は電話番号の発信者番号通知処理です。
電話をかけると通常は自分の電話番号が相手に通知されます。これを電話会社との契約によって通知しないようにすることができます。また相手の電話番号の前に特別なダイヤルを付加して電話をかけることによって、相手に自分の電話番号を通知するかしないかを指定することもできます。
この発信者番号通知処理の仕様は次の通りです。
１．電話会社との契約で「通知する」を選択していると自分の電話番号が相手に通知される。
２．電話会社との契約で「通知しない」を選択していると自分の電話番号が相手に通知されない。
３．電話をかける際に相手の電話番号の前に１８６を付加すると電話会社との契約にかかわらず自分の電話番号が相手に通知される。
４．電話をかける際に相手の電話番号の前に１８４を付加すると電話会社との契約にかかわらず自分の電話番号が相手に通知されない。
この仕様から発信者番号通知処理について次のルールが得られます。
１．通知する
(1) 電話会社との契約が「通知する」でかつ付加ダイヤルなしで電話をかける。
(2) １８６を付加して電話をかける。
２．通知しない
(1) 電話会社との契約が「通知しない」でかつ付加ダイヤルなしで電話をかける。
(2) １８４を付加して電話をかける。
このルールをもとに表１の圧縮したデシジョンテーブルが作成できます。実際には付加ダイヤルの種類には別のサービスの関係でこれ以外にもあるのですがここでは問題を単純にするためにこの２種類だけとします。
デシジョンテーブルをテストで使用する場合は必ず圧縮していないデシジョンテーブルを使用する必要があります。ただし、プログラム構造が分っていて、どのような制御フローで処理するかが明確に把握できていて、その制御フローに合った圧縮を行なっているデシジョンテーブルを使用するならその限りではありません。
複雑な論理構造を持つソフトウェアのプログラミングに 圧縮したデシジョンテーブルは強力な味方
プログラミングする人の多くは自分がデシジョンテーブルを使ってプログラミングしていることを知らないのではないかと思います。機能仕様書に書かれている仕様を表現している表の多くは形式こそ少し違いますがその本質はデシジョンテーブルそのものです。もともとデシジョンテーブルはソフトウェアの仕様を分かりやすく表現する手段として用いられました。かつてはデシジョンテーブルからプログラムを自動生成する試みもあったようです。今では開発分野よりもテスト分野の方でテスト技法としてデシジョンテーブルがよく知られています。
複雑な論理構造を持つプログラミングを行なう場合は、圧縮したデシジョンテーブルがあるとプログラミングが格段にやりやすくなるうえにプログラミングミスも減らすことができます。機能仕様書に書かれている仕様を表現している表のデシジョンテーブルは圧縮したデシジョンテーブルです。もしこれが圧縮されていないデシジョンテーブルでプログラミングしようとするととても大変なことになります。プログラミングミスも頻発するでしょう。
デシジョンテーブルを使ってプログラミングする場合、デシジョンテーブルの条件の並び順が重要になります。前回の記事と同じ例を用いて説明しましょう。この仕様を以下に再掲します。
ある博覧会の入場料を決定する仕様は次のように定められています。
１．平日以外は２０００円
２．平日は１６００円
３．１８歳未満は１４００円
４．優待券を持参している人は１８００円
５．優待券を持参している１８歳未満は１２００円
６．複数の条件に一致する場合は安い料金を適用する
圧縮していないデシジョンテーブルを表１に示します。この表の条件の順番には特に意味はありません。
複雑な論理を扱うプログラミングではこのように必ず圧縮したデシジョンテーブルを使うことで格段に正確にプログラミングすることができるようになります。その一方で、テストにおいて圧縮したデシジョンテーブルを使うことはテスト漏れの危険が常に付きまとうということになります。
ではどうしてもテストケースを減らしたいので圧縮したデシジョンテーブルを使いたい場合はどうしたらよいでしょうか。その場合は、テスト対象のソースコードを解析し、各条件ごとにいくつの結果ルートを持ったプログラムであるかを把握し、それに合った圧縮を行なったデシジョンテーブルを用いればよいということになります。こうなると制御パステストと同等な完全にホワイトボックスのテスト技法となります。
複雑な論理構造を持つプログラミングを行なう場合は、圧縮したデシジョンテーブルがあるとプログラミングが格段にやりやすくなるうえにプログラミングミスも減らすことができます。機能仕様書に書かれている仕様を表現している表のデシジョンテーブルは圧縮したデシジョンテーブルです。もしこれが圧縮されていないデシジョンテーブルでプログラミングしようとするととても大変なことになります。プログラミングミスも頻発するでしょう。
デシジョンテーブルを使ってプログラミングする場合、デシジョンテーブルの条件の並び順が重要になります。前回の記事と同じ例を用いて説明しましょう。この仕様を以下に再掲します。
ある博覧会の入場料を決定する仕様は次のように定められています。
１．平日以外は２０００円
２．平日は１６００円
３．１８歳未満は１４００円
４．優待券を持参している人は１８００円
５．優待券を持参している１８歳未満は１２００円
６．複数の条件に一致する場合は安い料金を適用する
圧縮していないデシジョンテーブルを表１に示します。この表の条件の順番には特に意味はありません。
複雑な論理を扱うプログラミングではこのように必ず圧縮したデシジョンテーブルを使うことで格段に正確にプログラミングすることができるようになります。その一方で、テストにおいて圧縮したデシジョンテーブルを使うことはテスト漏れの危険が常に付きまとうということになります。
ではどうしてもテストケースを減らしたいので圧縮したデシジョンテーブルを使いたい場合はどうしたらよいでしょうか。その場合は、テスト対象のソースコードを解析し、各条件ごとにいくつの結果ルートを持ったプログラムであるかを把握し、それに合った圧縮を行なったデシジョンテーブルを用いればよいということになります。こうなると制御パステストと同等な完全にホワイトボックスのテスト技法となります。
デシジョンテーブルの圧縮でバグの見逃しが発生するとはどういうことか？
圧縮したデシジョンテーブルを使ってテストを行なうことの危険性については以前に説明しました。その時あげた例はあまり一般的ではなかったので、今回はより一般的に起きやすい例をあげてみることにします。今回取り上げる例はある博覧会の入場料を決定する仕様です。
ある博覧会の入場料を決定する仕様は次のように定められています。
１．平日以外は２０００円
２．平日は１６００円
３．１８歳未満は１４００円
４．優待券を持参している人は１８００円
５．優待券を持参している１８歳未満は１２００円
６．複数の条件に一致する場合は安い料金を適用する
この博覧会の入場料を決定するデシジョンテーブルを作成することにします。
仕様から料金ごとのルールは次の通りとなります。
(1) ２０００円
平日でなくかつ１８歳以上でかつ優待券を持参していない。
(2) １８００円
平日でなくかつ１８歳以上でかつ優待券を持参している。
(3) １６００円
平日でかつ１８歳以上。
(4) １４００円
１８歳未満でかつ優待券を持参していない。
(5) １２００円
１８歳未満でかつ優待券を持参している。
このルールをもとにして直接次のデシジョンテーブルが作成できます。
これで圧縮したデシジョンテーブルと圧縮していないデシジョンテーブルの２つが得られました。
ここでこの仕様をソフトウェアとして実装する場合を考えてみましょう。この仕様の実装方法は１つとは限りません。少なくとも４種類はあります。ここではこの仕様の実装例として次の３つのフローチャートを示します。
これらのソフトウェアを表１の圧縮したデシジョンテーブルでテストすると、最初のソフトウェアではテスト漏れは起こりません。５つのルールでソフトウェアのすべてのルートを網羅しているからです。しかし、真ん中と最後のソフトウェアではテスト漏れが起きます。圧縮したデシジョンテーブルではルールが５つしかないのに、真ん中のソフトウェアでは６つ、最後のソフトウェアでは７つのルートがあり、網羅されないルートが出てくるからです。一方、圧縮していないデシジョンテーブルではどのソフトウェアでもテスト漏れは起きず、すべてのルートが網羅されます。
デシジョンテーブルを使ってテストを行なう場合、ブラックボックステストにおけるテスト対象のソフトウェアがどのように実装されているかを事前に把握することはできません。したがってデシジョンテーブルを圧縮してテストを行なうということは、常にテスト漏れの危険がつきまとうということを肝に銘じておく必要があります。
テスト技法を解説した書籍やネット上の解説では、そのほとんどがデシジョンテーブルを圧縮することが当然のように書かれています。デシジョンテーブルを圧縮することがいかに危険なことであるか。このことは強調してもしすぎるということはありません。
ごく一部の書籍やネット上の解説ですが、デシジョンテーブルの圧縮では「処理順が重要なので開発側との協力が必要」などと書かれているものがあります。おそらく言いたいのは「デシジョンテーブルを圧縮する場合は、テスト対象のソフトウェアのプログラム構造に合わせてテスト漏れが起きないような形で圧縮しなければならない」ということだろうと思われます。そもそもデシジョンテーブルテストはブラックボックスのテスト技法だったはずです。それなのにこれでは圧縮したデシジョンテーブルでのテストは制御パステストと同様なホワイトボックスのテスト技法ということになります。
ある博覧会の入場料を決定する仕様は次のように定められています。
１．平日以外は２０００円
２．平日は１６００円
３．１８歳未満は１４００円
４．優待券を持参している人は１８００円
５．優待券を持参している１８歳未満は１２００円
６．複数の条件に一致する場合は安い料金を適用する
この博覧会の入場料を決定するデシジョンテーブルを作成することにします。
仕様から料金ごとのルールは次の通りとなります。
(1) ２０００円
平日でなくかつ１８歳以上でかつ優待券を持参していない。
(2) １８００円
平日でなくかつ１８歳以上でかつ優待券を持参している。
(3) １６００円
平日でかつ１８歳以上。
(4) １４００円
１８歳未満でかつ優待券を持参していない。
(5) １２００円
１８歳未満でかつ優待券を持参している。
このルールをもとにして直接次のデシジョンテーブルが作成できます。
これで圧縮したデシジョンテーブルと圧縮していないデシジョンテーブルの２つが得られました。
ここでこの仕様をソフトウェアとして実装する場合を考えてみましょう。この仕様の実装方法は１つとは限りません。少なくとも４種類はあります。ここではこの仕様の実装例として次の３つのフローチャートを示します。
これらのソフトウェアを表１の圧縮したデシジョンテーブルでテストすると、最初のソフトウェアではテスト漏れは起こりません。５つのルールでソフトウェアのすべてのルートを網羅しているからです。しかし、真ん中と最後のソフトウェアではテスト漏れが起きます。圧縮したデシジョンテーブルではルールが５つしかないのに、真ん中のソフトウェアでは６つ、最後のソフトウェアでは７つのルートがあり、網羅されないルートが出てくるからです。一方、圧縮していないデシジョンテーブルではどのソフトウェアでもテスト漏れは起きず、すべてのルートが網羅されます。
デシジョンテーブルを使ってテストを行なう場合、ブラックボックステストにおけるテスト対象のソフトウェアがどのように実装されているかを事前に把握することはできません。したがってデシジョンテーブルを圧縮してテストを行なうということは、常にテスト漏れの危険がつきまとうということを肝に銘じておく必要があります。
テスト技法を解説した書籍やネット上の解説では、そのほとんどがデシジョンテーブルを圧縮することが当然のように書かれています。デシジョンテーブルを圧縮することがいかに危険なことであるか。このことは強調してもしすぎるということはありません。
ごく一部の書籍やネット上の解説ですが、デシジョンテーブルの圧縮では「処理順が重要なので開発側との協力が必要」などと書かれているものがあります。おそらく言いたいのは「デシジョンテーブルを圧縮する場合は、テスト対象のソフトウェアのプログラム構造に合わせてテスト漏れが起きないような形で圧縮しなければならない」ということだろうと思われます。そもそもデシジョンテーブルテストはブラックボックスのテスト技法だったはずです。それなのにこれでは圧縮したデシジョンテーブルでのテストは制御パステストと同様なホワイトボックスのテスト技法ということになります。
徹底したテストが行なえる複雑な論理関係を持ったデシジョンテーブルをPictMasterで生成する
先日、「原因結果グラフとCFD技法を比較する」という記事で複雑な仕様を持つ例題を取り上げて原因結果グラフとCFD技法を用いてデシジョンテーブルを作成しました。今回は同じ例題についてPictMasterを使用してデシジョンテーブルを生成する方法を紹介します。
原因結果グラフとCFD技法を用いて作成したデシジョンテーブルは、結果に影響を与えないと考えられる原因についてはその組み合わせを一部省略したものでした。このデシジョンテーブルでは徹底したテストを行なうことはできません。徹底したテストを行なうには組み合わせを省略しないデシジョンテーブルが必要ですが、手作業では煩雑な作業となります。そこで今回はPictMasterを用いて省略しないデシジョンテーブルを作成してみます。
例題をもう一度以下に示します。
例題の仕様
例題は、就業可能な最低就業年齢を判定する問題です。最低就業年齢は次の仕様で決定されます。
1. 使用者が、労働者として就業させることが可能な最低年齢は、満15歳に達した日以後の最初の3月31日が経過した者（義務教育終了者）である（労働基準法56条）。
2. 最低年齢に達しない者は労働基準法上「児童」と称され、原則として就業させることはできないが、例外として次の事業については行政官庁の許可を受けて使用することができる。
3. 行政官庁の許可を受けるには、児童の年齢証明書、児童の就学に差し支えがないことを証明する学校長の証明書、および親権者または後見人の同意書を様式第1号の使用許可申請書に添えて労働基準監督署に提出しなければならない（年少則1条）。
4. 使用者は、使用する満18歳未満の者について、その年齢を証明する戸籍証明書を事業所に備え付けなくてはならない。また、満15歳に達した以後の3月31が経過しない者を使用する場合、児童の就学に差し支えがないことを証する学校長の証明書および親権者または後見人の同意書を事業場に備え付けなくてはならない（労働基準法57条）。
これはかなり複雑な論理関係を持つ例題です。
パラメータと値の決定
最初にモデルのパラメータと値を決定します。必要となるパラメータと値には次のものがあります。
年齢
満18歳以上, 満16歳以上～18歳未満, 満15歳, 満15歳未満
今日が3月30日以前
T, F
児童の年齢証明書を提出
T, F
学校長の証明書を労基署に提出
T, F
学校長の証明書を事業所に提出
T, F
使用許可申請書を提出
T, F
戸籍証明書を提出
T, F
親権者がいる
T, F
後見人がいる
T, F
同意書を労基署に提出
T, F
同意書を事業所に提出
T, F
就業可能
T, F
「年齢」はどれか一つだけが真となるので、パラメータ年齢の値として定義します。原因結果グラフでのONE制約はこれで表現することができます。パラメータの就業可能は期待する結果なので組み合わせ対象からは除外します。詳しくはサブモデルで説明します。
その他のパラメータの値はすべてTとFです。原因結果グラフを作成した時は親権者と後見人のそれぞれについて労基署に提出と事業所に提出を原因ノードとしましたが、親権者と後見人のどちらか真となった方が書類を提出することになるので、今回は「親権者がいる」と「後見人がいる」とは独立に「同意書を労基署に提出」と「同意書を事業所に提出」をパラメータとすることで、組み合わせるパラメータの総数を前回の16個から11個に削減しています。
サブモデルの指定
パラメータの「就業可能」はデシジョンテーブルでのアクションに相当するので組み合わせ対象から除外します。これはサブモデルを使用することで可能となります。サブモデル欄にパラメータの「年齢」から「同意書を事業所に提出」までの11個を記入し、サブモデル欄の組み合わせるパラメータ数に11を指定します。そして環境設定の組み合わせるパラメータ数に1を指定します。こうすることで「就業可能」を除いたパラメータの全数組み合わせとなります。
制約の指定
例題の複雑な論理関係は制約表で表現することができます。例題のパラメータ数は11個あります。単純な全数組み合わせでは４×２×２×２×２×２×２×２×２×２×２＝４０９６通りにもなります。このままでは扱うことができません。そこで組み合わせできない組み合わせを制約表で除外することにします。ただし、除外すると言っても普通のやり方では歯が立ちません。ここではいわゆる「強い制約」を用いることによって、全数組み合わせの件数を劇的に削減させるようにします。「強い制約」の意味については「強い制約、弱い制約」を参照してください。
PictMasterのモデル
以下にこの例題を解くPictMasterのモデルを示します。
制約１～２
年齢が満18歳未満では親権者か後見人のどちらか一方が真となる。
制約３
満18歳以上ではいかなる書類の提出も不要で無条件に就業可能である。
制約４
満16歳以上～満18歳未満では「戸籍証明書を提出」が真であれば就業可能である。
制約５
満16歳以上～満18歳未満では「戸籍証明書を提出」が偽であれば就業不可である。
制約６
満15歳で「今日が3月30日以前」が偽で「戸籍証明書を提出」が真であれば就業可能である。
制約７
満15歳で「今日が3月30日以前」が偽で「戸籍証明書を提出」が偽であれば就業不可である。
制約８
満15歳で「今日が3月30日以前」が真で各書類の提出がすべて真であれば就業可能である。
制約９～１５
満15歳で「今日が3月30日以前」が真で各書類のどれか一つの提出が偽であれば就業不可である。
制約１６
満15歳未満で各書類の提出がすべて真であれば就業可能である。
制約１７～２３
満15歳未満で各書類のどれか一つの提出が偽であれば就業不可である。
パラメータの「親権者がいる」と「後見人がいる」の行は空白にしておきます。ここの組み合わせは制約１～２の指定に従って生成されます。
生成されたデシジョンテーブル
以上のモデルで生成を行なった結果を次に示します。
制約指定に「強い制約」を用いたために、生成されたデシジョンテーブルは制約指定とよく似ています。異なるのは「親権者がいる」と「後見人がいる」の組み合わせが追加されてテストケース数が２倍に増えている点だけです。制約１～２を削除し制約指定で空白行となっている「親権者がいる」と「後見人がいる」にどちらか一方だけが真の値を指定することで21件のテストケースとすることもできます。こうした場合はデシジョンテーブルを生成する必要はなく、制約指定がそのままデシジョンテーブルになります。このように制約指定によって複雑な論理関係を持つデシジョンテーブルを簡単に生成できることがお分かりいただけたと思います。
このデシジョンテーブルを用いることで徹底したテストを行なうことができます。
これまで何回かPictMasterでデシジョンテーブルを生成する方法を紹介してきましたが、それらはアクションを結果表を用いて指定する方法でした。今回の方法はそれとは異なり、サブモデルを用いてパラメータとしてのアクションを組み合わせから除外し、制約指定でアクションの値を指定しています。この新しい方法もPictMasterでデシジョンテーブルを生成する上で有効な方法であることが今回分かりました。
ほとんどの組み合わせテストツールでは、非常に複雑な制約を指定することが煩雑な作業となるという難点があります。また各制約間の論理関係を把握することが難しいという欠点もあります。従ってこれまで組み合わせテストツールでデシジョンテーブルを作成するということを行なった例はないのではないかと思います。しかしPictMasterでは制約表という独特の制約指定方式のおかげで複雑な論理関係を持つデシジョンテーブルを手軽に生成することができます。
原因結果グラフとCFD技法を用いて作成したデシジョンテーブルは、結果に影響を与えないと考えられる原因についてはその組み合わせを一部省略したものでした。このデシジョンテーブルでは徹底したテストを行なうことはできません。徹底したテストを行なうには組み合わせを省略しないデシジョンテーブルが必要ですが、手作業では煩雑な作業となります。そこで今回はPictMasterを用いて省略しないデシジョンテーブルを作成してみます。
例題をもう一度以下に示します。
例題の仕様
例題は、就業可能な最低就業年齢を判定する問題です。最低就業年齢は次の仕様で決定されます。
1. 使用者が、労働者として就業させることが可能な最低年齢は、満15歳に達した日以後の最初の3月31日が経過した者（義務教育終了者）である（労働基準法56条）。
2. 最低年齢に達しない者は労働基準法上「児童」と称され、原則として就業させることはできないが、例外として次の事業については行政官庁の許可を受けて使用することができる。
3. 行政官庁の許可を受けるには、児童の年齢証明書、児童の就学に差し支えがないことを証明する学校長の証明書、および親権者または後見人の同意書を様式第1号の使用許可申請書に添えて労働基準監督署に提出しなければならない（年少則1条）。
4. 使用者は、使用する満18歳未満の者について、その年齢を証明する戸籍証明書を事業所に備え付けなくてはならない。また、満15歳に達した以後の3月31が経過しない者を使用する場合、児童の就学に差し支えがないことを証する学校長の証明書および親権者または後見人の同意書を事業場に備え付けなくてはならない（労働基準法57条）。
これはかなり複雑な論理関係を持つ例題です。
パラメータと値の決定
最初にモデルのパラメータと値を決定します。必要となるパラメータと値には次のものがあります。
年齢
満18歳以上, 満16歳以上～18歳未満, 満15歳, 満15歳未満
今日が3月30日以前
T, F
児童の年齢証明書を提出
T, F
学校長の証明書を労基署に提出
T, F
学校長の証明書を事業所に提出
T, F
使用許可申請書を提出
T, F
戸籍証明書を提出
T, F
親権者がいる
T, F
後見人がいる
T, F
同意書を労基署に提出
T, F
同意書を事業所に提出
T, F
就業可能
T, F
「年齢」はどれか一つだけが真となるので、パラメータ年齢の値として定義します。原因結果グラフでのONE制約はこれで表現することができます。パラメータの就業可能は期待する結果なので組み合わせ対象からは除外します。詳しくはサブモデルで説明します。
その他のパラメータの値はすべてTとFです。原因結果グラフを作成した時は親権者と後見人のそれぞれについて労基署に提出と事業所に提出を原因ノードとしましたが、親権者と後見人のどちらか真となった方が書類を提出することになるので、今回は「親権者がいる」と「後見人がいる」とは独立に「同意書を労基署に提出」と「同意書を事業所に提出」をパラメータとすることで、組み合わせるパラメータの総数を前回の16個から11個に削減しています。
サブモデルの指定
パラメータの「就業可能」はデシジョンテーブルでのアクションに相当するので組み合わせ対象から除外します。これはサブモデルを使用することで可能となります。サブモデル欄にパラメータの「年齢」から「同意書を事業所に提出」までの11個を記入し、サブモデル欄の組み合わせるパラメータ数に11を指定します。そして環境設定の組み合わせるパラメータ数に1を指定します。こうすることで「就業可能」を除いたパラメータの全数組み合わせとなります。
制約の指定
例題の複雑な論理関係は制約表で表現することができます。例題のパラメータ数は11個あります。単純な全数組み合わせでは４×２×２×２×２×２×２×２×２×２×２＝４０９６通りにもなります。このままでは扱うことができません。そこで組み合わせできない組み合わせを制約表で除外することにします。ただし、除外すると言っても普通のやり方では歯が立ちません。ここではいわゆる「強い制約」を用いることによって、全数組み合わせの件数を劇的に削減させるようにします。「強い制約」の意味については「強い制約、弱い制約」を参照してください。
PictMasterのモデル
以下にこの例題を解くPictMasterのモデルを示します。
制約１～２
年齢が満18歳未満では親権者か後見人のどちらか一方が真となる。
制約３
満18歳以上ではいかなる書類の提出も不要で無条件に就業可能である。
制約４
満16歳以上～満18歳未満では「戸籍証明書を提出」が真であれば就業可能である。
制約５
満16歳以上～満18歳未満では「戸籍証明書を提出」が偽であれば就業不可である。
制約６
満15歳で「今日が3月30日以前」が偽で「戸籍証明書を提出」が真であれば就業可能である。
制約７
満15歳で「今日が3月30日以前」が偽で「戸籍証明書を提出」が偽であれば就業不可である。
制約８
満15歳で「今日が3月30日以前」が真で各書類の提出がすべて真であれば就業可能である。
制約９～１５
満15歳で「今日が3月30日以前」が真で各書類のどれか一つの提出が偽であれば就業不可である。
制約１６
満15歳未満で各書類の提出がすべて真であれば就業可能である。
制約１７～２３
満15歳未満で各書類のどれか一つの提出が偽であれば就業不可である。
パラメータの「親権者がいる」と「後見人がいる」の行は空白にしておきます。ここの組み合わせは制約１～２の指定に従って生成されます。
生成されたデシジョンテーブル
以上のモデルで生成を行なった結果を次に示します。
制約指定に「強い制約」を用いたために、生成されたデシジョンテーブルは制約指定とよく似ています。異なるのは「親権者がいる」と「後見人がいる」の組み合わせが追加されてテストケース数が２倍に増えている点だけです。制約１～２を削除し制約指定で空白行となっている「親権者がいる」と「後見人がいる」にどちらか一方だけが真の値を指定することで21件のテストケースとすることもできます。こうした場合はデシジョンテーブルを生成する必要はなく、制約指定がそのままデシジョンテーブルになります。このように制約指定によって複雑な論理関係を持つデシジョンテーブルを簡単に生成できることがお分かりいただけたと思います。
このデシジョンテーブルを用いることで徹底したテストを行なうことができます。
これまで何回かPictMasterでデシジョンテーブルを生成する方法を紹介してきましたが、それらはアクションを結果表を用いて指定する方法でした。今回の方法はそれとは異なり、サブモデルを用いてパラメータとしてのアクションを組み合わせから除外し、制約指定でアクションの値を指定しています。この新しい方法もPictMasterでデシジョンテーブルを生成する上で有効な方法であることが今回分かりました。
ほとんどの組み合わせテストツールでは、非常に複雑な制約を指定することが煩雑な作業となるという難点があります。また各制約間の論理関係を把握することが難しいという欠点もあります。従ってこれまで組み合わせテストツールでデシジョンテーブルを作成するということを行なった例はないのではないかと思います。しかしPictMasterでは制約表という独特の制約指定方式のおかげで複雑な論理関係を持つデシジョンテーブルを手軽に生成することができます。