制約の指定方法で変わるPICTの生成時間
PICTで複雑な制約を指定すると生成時間がかなり長くなる場合があります。前から感じていたことですが、同じ結果となる等価な異なる制約指定を行なうと、生成時間に違いが出てきます。そこでどのような制約の指定方法が最も生成時間が短くなるか実験してみました。
この実験ではマシンにPentium 4 2.4GHz 1GB RAM を使用し、他に実行中のアプリケーションがない状態で測定を行ないました。実験に使用したモデルを示します。
表１．モデル
このモデルで以下の３つの等価な制約指定でそれぞれ最少テストケース生成に100回を指定して生成を行なってみました。
表２．制約指定その１
表３．制約指定その２
表４．制約指定その３
それぞれの制約指定での生成時間は以下のとおりでした。
制約指定その１ ８秒
制約指定その２ ４５秒
制約指定その３ ９秒
この結果から言えることは、
特性１．制約対象をAND指定（#）で行なうと生成時間が短くなる。
特性２．制約対象をOR指定（指定なし）で行なうと生成時間が長くなる。
特性３．制約条件の制約指定方法は生成時間に影響を与えない。
ということです。ただし、この例では制約対象で記述する値の数に大きな違いがあります。
そこでAND指定でもOR指定でも同じ値の数となる例についても実験してみました。制約指定は以下の２つです。この例ではどちらの指定を行なっても記述する値の数に違いがありません。
表５．制約指定その４
表６．制約指定その５
それぞれの制約指定での生成時間は以下のとおりでした。
制約指定その４ １５秒
制約指定その５ ８秒
この結果から、やはり先にあげた特性１と特性２は成立することが分かります。
さらに同様なパラメータDを追加し、表５と表６の制約指定を２組指定した結果、以下のとおりとなりました。
制約指定その４×２ ２２秒
制約指定その５×２ ８秒
この結果から、制約が複雑になればなるほど制約指定の違いが生成時間に及ぼす影響が大きくなることが分かります。さらに注目すべきことに制約対象をAND指定で行なった場合は生成時間の増加が見られないことです。
テスト設計者が記入した制約表をPictMasterが調べて、生成時間が短くなるように制約指定を最適化する、という機能も考えられます。この機能があればテスト設計者が制約表に記入する指定方法を気にせずに生成時間を最短にすることができます。次のバージョンで盛込むかもしれません。
それでは、また。
この実験ではマシンにPentium 4 2.4GHz 1GB RAM を使用し、他に実行中のアプリケーションがない状態で測定を行ないました。実験に使用したモデルを示します。
それぞれの制約指定での生成時間は以下のとおりでした。
制約指定その１ ８秒
制約指定その２ ４５秒
制約指定その３ ９秒
この結果から言えることは、
特性１．制約対象をAND指定（#）で行なうと生成時間が短くなる。
特性２．制約対象をOR指定（指定なし）で行なうと生成時間が長くなる。
特性３．制約条件の制約指定方法は生成時間に影響を与えない。
ということです。ただし、この例では制約対象で記述する値の数に大きな違いがあります。
そこでAND指定でもOR指定でも同じ値の数となる例についても実験してみました。制約指定は以下の２つです。この例ではどちらの指定を行なっても記述する値の数に違いがありません。
それぞれの制約指定での生成時間は以下のとおりでした。
制約指定その４ １５秒
制約指定その５ ８秒
この結果から、やはり先にあげた特性１と特性２は成立することが分かります。
さらに同様なパラメータDを追加し、表５と表６の制約指定を２組指定した結果、以下のとおりとなりました。
制約指定その４×２ ２２秒
制約指定その５×２ ８秒
この結果から、制約が複雑になればなるほど制約指定の違いが生成時間に及ぼす影響が大きくなることが分かります。さらに注目すべきことに制約対象をAND指定で行なった場合は生成時間の増加が見られないことです。
テスト設計者が記入した制約表をPictMasterが調べて、生成時間が短くなるように制約指定を最適化する、という機能も考えられます。この機能があればテスト設計者が制約表に記入する指定方法を気にせずに生成時間を最短にすることができます。次のバージョンで盛込むかもしれません。
それでは、また。
PICTのコア生成アルゴリズム「グリーディヒューリスティック手法」とは？
PICTは組み合わせ生成プロセスを、「準備」と「生成」の２段階に分けています。準備段階では生成段階で必要となるすべての情報を計算します。その中には網羅するすべてのパラメータの組み合わせが含まれています（スロットとしての組み合わせ）。
その次にPICTは生成段階に移行し、「グリーディヒューリスティック手法」を用いて最も最適な解に近い組み合わせを生成します。
「ヒューリスティクス」とは、「必ず正しい答えが導けるわけではないが、ある程度のレベルで正解に近い解を得ることが出来る方法」をいいます。答えの精度は保障されませんが、解答に至るまでの時間が少なくてすむという特徴があります。ヒューリスティクスの直訳は「発見学」で、ヒューリスティクスを「発見的手法」とか「発見的解法」と呼ぶこともあります。
ヒューリステック手法により最適に近い解を求めることは「NP完全」問題を解くことでもあります。「NP完全」のNPとは、計算複雑性理論における問題の複雑性クラスで、Non-deterministic Polynomial time（非決定性多項式時間）の略です。「NP完全」とは、クラスNPに属する問題でかつ、クラスNPのすべての問題から多項式時間帰着可能な問題です。従ってヒューリステック手法により、有限時間内に最適とは限らないが少なくとも最適に近い解を得ることができることになります。
PICTが採用している「グリーディヒューリスティック手法」の「グリーディ」とは、貪欲法（greedy algorithm）といい、アルゴリズムの一種です。貪欲法とは局所探索法と並んで近似アルゴリズムの最も基本的な考え方の一つです。このアルゴリズムは問題の要素を複数に分割し、分割した要素をそれぞれ独立に評価を行い、評価値の高い順に問題に取り込んでいくことで解を得るという方法です。問題を複数に分割する方法は特に組合せ最適化問題と相性が良く、問題によっては最適解を得られたり、最低限の精度保証（近似度）が算出可能なものもあります。
PICTが組み合わせを生成する際に、最も多くの未対象組み合わせを網羅するスロットを取得する、という部分がこの「グリーディ」に相当する部分だと考えられます。さらに付け加えるとすれば、最も多くの未対象組み合わせを網羅するスロットが複数存在した場合、どのスロットを採用するのかを決めるのが、PICTに与える初期条件値だと思われます。その選択の結果により、生成される組み合わせの数に違いが生じるのでしょう。
以上、PICTの「グリーディヒューリスティック手法」について説明しました。難しい数学的用語についてはWikipediaから引用しました。一応PICTの心臓部のアルゴリズムについて概略を説明したつもりです。
本人が数学を苦手としているので数式を一切用いていません。;^_^
この記事の参考になる記事が「PICTの組み合わせ生成アルゴリズム 」にありますので参照してみてください。
それでは、また。
その次にPICTは生成段階に移行し、「グリーディヒューリスティック手法」を用いて最も最適な解に近い組み合わせを生成します。
「ヒューリスティクス」とは、「必ず正しい答えが導けるわけではないが、ある程度のレベルで正解に近い解を得ることが出来る方法」をいいます。答えの精度は保障されませんが、解答に至るまでの時間が少なくてすむという特徴があります。ヒューリスティクスの直訳は「発見学」で、ヒューリスティクスを「発見的手法」とか「発見的解法」と呼ぶこともあります。
ヒューリステック手法により最適に近い解を求めることは「NP完全」問題を解くことでもあります。「NP完全」のNPとは、計算複雑性理論における問題の複雑性クラスで、Non-deterministic Polynomial time（非決定性多項式時間）の略です。「NP完全」とは、クラスNPに属する問題でかつ、クラスNPのすべての問題から多項式時間帰着可能な問題です。従ってヒューリステック手法により、有限時間内に最適とは限らないが少なくとも最適に近い解を得ることができることになります。
PICTが採用している「グリーディヒューリスティック手法」の「グリーディ」とは、貪欲法（greedy algorithm）といい、アルゴリズムの一種です。貪欲法とは局所探索法と並んで近似アルゴリズムの最も基本的な考え方の一つです。このアルゴリズムは問題の要素を複数に分割し、分割した要素をそれぞれ独立に評価を行い、評価値の高い順に問題に取り込んでいくことで解を得るという方法です。問題を複数に分割する方法は特に組合せ最適化問題と相性が良く、問題によっては最適解を得られたり、最低限の精度保証（近似度）が算出可能なものもあります。
PICTが組み合わせを生成する際に、最も多くの未対象組み合わせを網羅するスロットを取得する、という部分がこの「グリーディ」に相当する部分だと考えられます。さらに付け加えるとすれば、最も多くの未対象組み合わせを網羅するスロットが複数存在した場合、どのスロットを採用するのかを決めるのが、PICTに与える初期条件値だと思われます。その選択の結果により、生成される組み合わせの数に違いが生じるのでしょう。
以上、PICTの「グリーディヒューリスティック手法」について説明しました。難しい数学的用語についてはWikipediaから引用しました。一応PICTの心臓部のアルゴリズムについて概略を説明したつもりです。
本人が数学を苦手としているので数式を一切用いていません。;^_^
この記事の参考になる記事が「PICTの組み合わせ生成アルゴリズム 」にありますので参照してみてください。
それでは、また。
制御パステストへのAll-Pair法の適用
ホワイトボックステスト技法の１つである「制御パステスト」は単体テストでの有効なテスト技法の１つです。今回はこの制御パステストのテストケースをAllPairIIのJennyで生成しようというものです。
制御パステストには大きく分けて以下の３つの種類があります。
（1）すべての命令を1回は実行する「命令網羅」
（2）すべての条件分岐を1回は実行する「条件網羅」
（3）すべての制御パスを実行する「経路網羅」
命令網羅は条件網羅に含まれ、命令網羅と条件網羅は経路網羅に含まれます。経路網羅は、プログラムの取りうるルートをすべて網羅するカバレッジ率が最も大きいものです。それだけにテストケース数が多くなり、実際のテストではめったに実施されないと思われます。
All-Pair法で経路網羅を実現するには「組み合わせるパラメータ数」を分岐文の数だけ指定することで可能です。ただし組み合わせ数が多くなると組み合わせ生成に非常に時間がかかります）。
制御パステストにAll-Pair法を適用する場合、All-Pair法の2パラメータ間のすべてのペアを網羅するという性質から、それは(2)の条件網羅のテストケースを生成することになります。
制御パステストにAll-Pair法を適用する例として、道路網のある地点から別のある地点までの最短経路を求めることにします。
道路網には多くの交差点やＴ字路があり、各交差点間の距離は１から３までの間でランダムに与えられています。１つだけ制限事項を設けます。道路の迂回はできないものとします。つまりスタート地点に戻る方向へは進めないものとします。
この事例には「PICT と PictMaster のための活用情報集 」というサイトに以前掲載したものを引用しますが、当時はPictMasterで組み合わせを生成するのにCPUにIntel Xeon E5462 2.8GHz のマシンを使用して1回の生成に2時間40分かかりました。現在はAllPairIIで生成エンジンにJennyを使用することができるため、1秒未満という極めて短い時間で組み合わせを生成することができるようになりました。Jennyを用いることによってAll-Pair法で制御パステストのテストケースを実用的な時間で生成することができるようになったのです（現在、「PICT と PictMaster のための活用情報集」というサイトに掲載されている制約表は２ヶ所誤りがあります）。
道路網を表１に示します。
表１ 最短経路を求める道路網
道路網の交差点とＴ字路にはＡからEと数字をあわせた記号をつけて識別します。道路の脇にある１桁の数字は距離を表しています。道路の迂回ができないということは、例えばB2の地点で進める方向はB3またはC2に限定されるということです。
最短経路のルートを求めるには通れるすべてのルートを探し出す必要があります。その結果見つかったルートの集まりは、すべての交差点、Ｔ字路をもれなく通ることになります。通れるすべてのルートを探し出す手段としてAll-Pair法を用いると、最も少ないルート数ですべての交差点、Ｔ字路をもれなく通るルートを探し出すことができます。ただし、厳密に言うとすべてのルートを探し出すには経路網羅である必要があります。しかし実用上の観点から条件網羅とします。この場合、必ずしも最短経路が見つかるとは限りませんが、最も最短経路に近い経路を見つけることができます。
この道路網は、ソフトウェアプログラムに置き換えることができます。十字路と一部のＴ字路は分岐文に相当します。次にソフトウェアの分岐文に当たる箇所を赤字で示しました。
表２ フローチャートとしてみたときの分岐点
以上の分岐点をもとにフローチャートで表すと以下のとおりとなります。
図１ 道路網をフローチャートで表す
道路網の交差点やＴ字路で通行可能な方向を表現したパラメータと値の並びを次に示します。この表でパラメータは交差点、Ｔ字路を意味します。値の並びはその交差点、Ｔ字路で通れる次の交差点、Ｔ字路を意味します。記号に続く数字は、その交差点、Ｔ字路までの距離です。「-」はほかの交差点、Ｔ字路からはこの交差点、Ｔ字路は通れないことを指定するときに使用します。
表３ パラメータと値の並び欄
この制約表の一部を表４に示します。表のクリックでより広い範囲を見ることができます。
表４ 制約表の一部
表４の制約表には特徴があり、ある交差点、Ｔ字路で進むことのできる方向を制約欄に制約条件として記述し、そこで示された次の交差点、Ｔ字路で次に進むことのできる交差点、Ｔ字路を同じ制約の列で制約対象として記述します。制約対象までの間にほかのパラメータの行がある場合は、そこの交差点、Ｔ字路を通ることのないようにすべて「-」を記入します。
制約対象として指定された交差点、Ｔ字路は、同じパラメータの異なる制約欄に制約条件として１つずつ記入します。後は同じ手順の繰り返しです。この制約表の記入はとても簡単な機械的作業で済みます。
AllPairIIが生成した結果の１つを次に示します。この結果ではルート数が34、最短経路は黄色で網掛けしたNo.18の9でした。この結果は、最少テストケース生成に300を指定して得られたものです。この結果は必ずこうなるというわけではありません。念のため。
表５ 生成結果の例 
この生成結果がすべての分岐点についてすべての分岐方向を網羅していることを確認するには、34ルートを表の上でなぞる必要があります。単純にボールペンなどで34ルートもなぞろうとすると経路の線がこんがらがって何が何だかわからなくなります。知りたいのは分岐点の各方向を通っているかどうかですから、線で単純になぞるのではなく、分岐点の部分についてのみ、どちらから来てどちらに分岐したかを短い直線または90度の角度の短い線を描くだけにします。2回以上同じ線分に来た時は何も描く必要はありません。こうすることですべての分岐点ですべての分岐先に分岐していることが確認できます。
今回のモデルは、16個の分岐文がひし形に配置されたケースでしたが、分岐文が縦方向に連なる配置のケースでも適用することができます。
以上、制御パステストの条件網羅のテストケースをAll-Pair法で生成する方法を紹介しました。実際のプログラムは、ループがあったり、参照している変数の値によって通れないルートがあったりしますが、原理的にはAll-Pair法が適用可能なことは示せたのではないかと思います。
それでは、また。
制御パステストには大きく分けて以下の３つの種類があります。
（1）すべての命令を1回は実行する「命令網羅」
（2）すべての条件分岐を1回は実行する「条件網羅」
（3）すべての制御パスを実行する「経路網羅」
命令網羅は条件網羅に含まれ、命令網羅と条件網羅は経路網羅に含まれます。経路網羅は、プログラムの取りうるルートをすべて網羅するカバレッジ率が最も大きいものです。それだけにテストケース数が多くなり、実際のテストではめったに実施されないと思われます。
All-Pair法で経路網羅を実現するには「組み合わせるパラメータ数」を分岐文の数だけ指定することで可能です。ただし組み合わせ数が多くなると組み合わせ生成に非常に時間がかかります）。
制御パステストにAll-Pair法を適用する場合、All-Pair法の2パラメータ間のすべてのペアを網羅するという性質から、それは(2)の条件網羅のテストケースを生成することになります。
制御パステストにAll-Pair法を適用する例として、道路網のある地点から別のある地点までの最短経路を求めることにします。
道路網には多くの交差点やＴ字路があり、各交差点間の距離は１から３までの間でランダムに与えられています。１つだけ制限事項を設けます。道路の迂回はできないものとします。つまりスタート地点に戻る方向へは進めないものとします。
この事例には「PICT と PictMaster のための活用情報集 」というサイトに以前掲載したものを引用しますが、当時はPictMasterで組み合わせを生成するのにCPUにIntel Xeon E5462 2.8GHz のマシンを使用して1回の生成に2時間40分かかりました。現在はAllPairIIで生成エンジンにJennyを使用することができるため、1秒未満という極めて短い時間で組み合わせを生成することができるようになりました。Jennyを用いることによってAll-Pair法で制御パステストのテストケースを実用的な時間で生成することができるようになったのです（現在、「PICT と PictMaster のための活用情報集」というサイトに掲載されている制約表は２ヶ所誤りがあります）。
道路網を表１に示します。
道路網の交差点とＴ字路にはＡからEと数字をあわせた記号をつけて識別します。道路の脇にある１桁の数字は距離を表しています。道路の迂回ができないということは、例えばB2の地点で進める方向はB3またはC2に限定されるということです。
最短経路のルートを求めるには通れるすべてのルートを探し出す必要があります。その結果見つかったルートの集まりは、すべての交差点、Ｔ字路をもれなく通ることになります。通れるすべてのルートを探し出す手段としてAll-Pair法を用いると、最も少ないルート数ですべての交差点、Ｔ字路をもれなく通るルートを探し出すことができます。ただし、厳密に言うとすべてのルートを探し出すには経路網羅である必要があります。しかし実用上の観点から条件網羅とします。この場合、必ずしも最短経路が見つかるとは限りませんが、最も最短経路に近い経路を見つけることができます。
この道路網は、ソフトウェアプログラムに置き換えることができます。十字路と一部のＴ字路は分岐文に相当します。次にソフトウェアの分岐文に当たる箇所を赤字で示しました。
以上の分岐点をもとにフローチャートで表すと以下のとおりとなります。
道路網の交差点やＴ字路で通行可能な方向を表現したパラメータと値の並びを次に示します。この表でパラメータは交差点、Ｔ字路を意味します。値の並びはその交差点、Ｔ字路で通れる次の交差点、Ｔ字路を意味します。記号に続く数字は、その交差点、Ｔ字路までの距離です。「-」はほかの交差点、Ｔ字路からはこの交差点、Ｔ字路は通れないことを指定するときに使用します。
この制約表の一部を表４に示します。表のクリックでより広い範囲を見ることができます。
表４の制約表には特徴があり、ある交差点、Ｔ字路で進むことのできる方向を制約欄に制約条件として記述し、そこで示された次の交差点、Ｔ字路で次に進むことのできる交差点、Ｔ字路を同じ制約の列で制約対象として記述します。制約対象までの間にほかのパラメータの行がある場合は、そこの交差点、Ｔ字路を通ることのないようにすべて「-」を記入します。
制約対象として指定された交差点、Ｔ字路は、同じパラメータの異なる制約欄に制約条件として１つずつ記入します。後は同じ手順の繰り返しです。この制約表の記入はとても簡単な機械的作業で済みます。
AllPairIIが生成した結果の１つを次に示します。この結果ではルート数が34、最短経路は黄色で網掛けしたNo.18の9でした。この結果は、最少テストケース生成に300を指定して得られたものです。この結果は必ずこうなるというわけではありません。念のため。
この生成結果がすべての分岐点についてすべての分岐方向を網羅していることを確認するには、34ルートを表の上でなぞる必要があります。単純にボールペンなどで34ルートもなぞろうとすると経路の線がこんがらがって何が何だかわからなくなります。知りたいのは分岐点の各方向を通っているかどうかですから、線で単純になぞるのではなく、分岐点の部分についてのみ、どちらから来てどちらに分岐したかを短い直線または90度の角度の短い線を描くだけにします。2回以上同じ線分に来た時は何も描く必要はありません。こうすることですべての分岐点ですべての分岐先に分岐していることが確認できます。
今回のモデルは、16個の分岐文がひし形に配置されたケースでしたが、分岐文が縦方向に連なる配置のケースでも適用することができます。
以上、制御パステストの条件網羅のテストケースをAll-Pair法で生成する方法を紹介しました。実際のプログラムは、ループがあったり、参照している変数の値によって通れないルートがあったりしますが、原理的にはAll-Pair法が適用可能なことは示せたのではないかと思います。
それでは、また。
PICTのバグを回避する方法 または PICTの最高の能力を引き出す方法
PictMasterで以下のようなモデルと制約指定を行なうと、約1分30秒後にPICTが空きの生成結果を出力するバグのあることが分かりました。これはWindows XPの場合であり、Windows Vistaでは別の結果になるかもしれません。
図１．PICTのバグが起きるモデルと制約表の例
この制約表では制約条件に「#」を用いる逆制約を指定しており、制約対象には順制約を指定しています。つまり制約の指定方法が異なっています。これを以下のように制約指定として制約条件と制約対象で同じ制約の指定方法（順制約か逆制約）に変更することでPICTのバグを回避することができます。
図２－１．正常に動作する、図１と等価な制約表（その１）
図２－２．正常に動作する、図１と等価な制約表（その２）
図２－１、図２－２の制約指定では1秒以内に正しい結果が得られます。
これらの制約指定では、PICTの制約式の AND と OR が、制約条件と制約対象で一致しています。そのことでPICTが必要とするメモリ量が大幅に少なくなったと考えられます。
PICTが大量のメモリを必要とするとき、OS側が仮想メモリを用いてそのメモリ要求を正しく処理することができればPICTのバグも起きないと思いますが、要求するメモリ量がOSの処理能力を超えてしまったため、PICTの異常出力につながったと考えられます。
生成エンジンがPICTの場合、多くの数の値をもつパラメータに対して多くの値の制約指定を行う場合は、制約条件と制約対象で同じ制約の指定方法（順制約か逆制約）で行なうようにすることでPICTのバグを回避できるとともに大幅に短時間で正しい生成結果を得ることができます。
PICTそのものは、ANDとORが入れ子になった複雑な制約指定が可能ですが、そのことが今回の大量メモリ要求に関係しているように思われますが詳しいことは不明です。
それでは、また。
この制約表では制約条件に「#」を用いる逆制約を指定しており、制約対象には順制約を指定しています。つまり制約の指定方法が異なっています。これを以下のように制約指定として制約条件と制約対象で同じ制約の指定方法（順制約か逆制約）に変更することでPICTのバグを回避することができます。
図２－１、図２－２の制約指定では1秒以内に正しい結果が得られます。
これらの制約指定では、PICTの制約式の AND と OR が、制約条件と制約対象で一致しています。そのことでPICTが必要とするメモリ量が大幅に少なくなったと考えられます。
PICTが大量のメモリを必要とするとき、OS側が仮想メモリを用いてそのメモリ要求を正しく処理することができればPICTのバグも起きないと思いますが、要求するメモリ量がOSの処理能力を超えてしまったため、PICTの異常出力につながったと考えられます。
生成エンジンがPICTの場合、多くの数の値をもつパラメータに対して多くの値の制約指定を行う場合は、制約条件と制約対象で同じ制約の指定方法（順制約か逆制約）で行なうようにすることでPICTのバグを回避できるとともに大幅に短時間で正しい生成結果を得ることができます。
PICTそのものは、ANDとORが入れ子になった複雑な制約指定が可能ですが、そのことが今回の大量メモリ要求に関係しているように思われますが詳しいことは不明です。
それでは、また。
PictMasterをPictMasterでテストする（単体テストへの適用）
組み合わせテスト技法はブラックボックステストだけでなく、ホワイトボックステストにも適用できます。ホワイトボックステストでは単体テストへの適用が可能です。
単体テストでは、例えば１つの関数の入力パラメータと関数内で参照しているグローバル変数などを組み合わせテストの要因（パラメータと値）とします。
そこでPictMasterのプロシージャ（VBAのサブルーチン）をPictMasterを使ってテストしてみました。ここで取り上げたテスト対象のプロシージャは、最も複雑なプロシージャの１つである「関係式生成」という230行ほどのプロシージャです。「関係式生成」は制約表の１つのセルの行番号、列番号、およびセル内のカンマで区切られたいくつ目の値かを入力パラメータとして受け取り、制約式の前後関係を参照しながら制約式の関係式を生成します。
この組み合わせテスト（単体テスト）のモデルと制約表の例を以下に示します。
図１．単体テストのモデルと制約表
ここで、行番号、列番号および位置番号はプロシージャの入力パラメータです。位置番号とは、処理対象の値がセル内で何番目に位置しているかを示します。対象長さとは、セル内に含まれる値の数を示します。その他のパラメータと値はプログラムリストを見て決めます。
比較対象の「パラメータと値」に重み付け(5)を行なっています。これは、重み付けを行わないと、演算子との関係で「パラメータどうし」が多く現れ、「パラメータと値」が少なくなります。しかし、実情は「パラメータどうし」がめったに使われることはなく、ほとんどが「パラメータと値」であるため、組み合わせテストにおいて、「パラメータと値」がより多く現れるように重み付けで５倍多く現れるようにしています。この場合の組み合わせ数は２９で、重み付けを行わない場合は２０でした。
組み合わせのテストケースを以下に示します。
表１．単体テストのテストケース
このテストを実施していくと、No.6でPICTのバグを見つけました。１回だけのテストケース生成で、２分ほどかかったのち、中身がない空きの出力を行なって終了してしまいます。時間はかかっても出力するときは正確な組み合わせの出力を行なうのがPICTのメリットの一つと考えていたのですが、ちょっと認識を改めないといけないようです。
より、少ない規模でもこの現象は起こります。そういった１つのモデルと制約表、および制約式の例を以下に示します。
図２．PICTのバグが発生するモデルと制約表
リスト１．PICTのバグが発生するモデルと制約式のリスト
バグのないソフトウェアはない、ということは事実のようです（苦笑）。
こうなると、複雑な制約の場合にまれにいくつかのペアの欠落が生じるJennyの使用も考慮したほうがよさそうです。図２のモデルをAllPairIIのJennyで実行すると、１秒以内に正しい組み合わせを生成します。PICTの場合は約１分後に空きの出力が生成されます。
PICTで対応できない部分はAllPairIIのJennyで対応すべきでしょう。今後はAllPairIIもサポート対象としていきたいと思います。
それでは、また。
単体テストでは、例えば１つの関数の入力パラメータと関数内で参照しているグローバル変数などを組み合わせテストの要因（パラメータと値）とします。
そこでPictMasterのプロシージャ（VBAのサブルーチン）をPictMasterを使ってテストしてみました。ここで取り上げたテスト対象のプロシージャは、最も複雑なプロシージャの１つである「関係式生成」という230行ほどのプロシージャです。「関係式生成」は制約表の１つのセルの行番号、列番号、およびセル内のカンマで区切られたいくつ目の値かを入力パラメータとして受け取り、制約式の前後関係を参照しながら制約式の関係式を生成します。
この組み合わせテスト（単体テスト）のモデルと制約表の例を以下に示します。
ここで、行番号、列番号および位置番号はプロシージャの入力パラメータです。位置番号とは、処理対象の値がセル内で何番目に位置しているかを示します。対象長さとは、セル内に含まれる値の数を示します。その他のパラメータと値はプログラムリストを見て決めます。
比較対象の「パラメータと値」に重み付け(5)を行なっています。これは、重み付けを行わないと、演算子との関係で「パラメータどうし」が多く現れ、「パラメータと値」が少なくなります。しかし、実情は「パラメータどうし」がめったに使われることはなく、ほとんどが「パラメータと値」であるため、組み合わせテストにおいて、「パラメータと値」がより多く現れるように重み付けで５倍多く現れるようにしています。この場合の組み合わせ数は２９で、重み付けを行わない場合は２０でした。
組み合わせのテストケースを以下に示します。
このテストを実施していくと、No.6でPICTのバグを見つけました。１回だけのテストケース生成で、２分ほどかかったのち、中身がない空きの出力を行なって終了してしまいます。時間はかかっても出力するときは正確な組み合わせの出力を行なうのがPICTのメリットの一つと考えていたのですが、ちょっと認識を改めないといけないようです。
より、少ない規模でもこの現象は起こります。そういった１つのモデルと制約表、および制約式の例を以下に示します。
リスト１．PICTのバグが発生するモデルと制約式のリスト
バグのないソフトウェアはない、ということは事実のようです（苦笑）。
こうなると、複雑な制約の場合にまれにいくつかのペアの欠落が生じるJennyの使用も考慮したほうがよさそうです。図２のモデルをAllPairIIのJennyで実行すると、１秒以内に正しい組み合わせを生成します。PICTの場合は約１分後に空きの出力が生成されます。
PICTで対応できない部分はAllPairIIのJennyで対応すべきでしょう。今後はAllPairIIもサポート対象としていきたいと思います。
それでは、また。