PictMaster v4.2.2 をリリースしました。
組み合わせテストケース生成ツール PictMaster 4.2.2 をリリースしました。
4.2.1 からの変更点は以下の通りです。
【バグ修正】
・PictMasterのワークシートを含むファイルを開くと、そのファイルに含まれるすべてのワークシートのFE列とFF列の9行目から38行目のセルに空白が書き込まれるバグを修正した。
・PictMasterのワークシートを含むファイルで、PictMaster以外のワークシートが表示されているときにウインドウ分割のショートカットキー（デフォルトはCTL+e）を押下すると、そのワークシートのB列77行目のセル内容に応じて次の結果となるバグを修正した。
セル内容が数値の場合、VBAのエラーとなる。
セル内容が数値以外の場合、そのセルに文字列”結果表”が書き込まれる。
・PictMasterと他のExcelファイルが同時に開かれていて、他のExcelファイルが前面に表示されているときにウインドウ分割のショートカットキーを押下すると、PictMasterのワークシートに表示が切り替わるバグを修正した。
PictMaster 4.2.2 は以下のサイトからダウンロードすることができます。
ファイルオープン時の問題とウインドウ分割ショートカットの問題
PictMasterに次のバグのあることが分かりました。
・PictMasterのワークシートを含むファイルを開くと、そのファイルに含まれるすべてのワークシートのFE列とFF列の9行目から38行目のセルに空白が書き込まれる。
・PictMasterのワークシートを含むファイルで、PictMaster以外のワークシートが表示されているときにウインドウ分割のショートカットキー（デフォルトはCTL+e）を押下すると、そのワークシートのB列77行目のセル内容に応じて次の結果となる。
セル内容が数値の場合、VBAのエラーとなる。
セル内容が数値以外の場合、そのセルに文字列”結果表”が書き込まれる。
・PictMasterと他のExcelファイルが同時に開かれていて、他のExcelファイルが前面に表示されているときにウインドウ分割のショートカットキーを押下すると、PictMasterのワークシートに表示が切り替わる。
以上のバグを修正したバージョン 4.2.2 を近日中にリ リースする予定です。
イベントの発生順序に起因する障害を検出するテストケースを生成する
ソフトウェアの性質のひとつとして、複数のイベントがランダムな順番で発生する、という場合を想定することができます。この場合、イベント発生順序が特定の場合に障害が発生する可能性が考えられます。こうした性質をもつソフトウェアをテストするためにAll-Pair法が役に立ちます。
All-Pair法を用いることで、任意の２つのイベントの発生順序の組合せが原因となる障害を１００％検出することが可能です。
例えば、５種類のイベントがランダムな順番で発生する場合は、次に示すモデルで表すことができます。
このモデルでは、パラメータA～Eがイベントの種類を表し、パラメータの値が、そのイベントの発生順番を表します。生成されるテストケースには１つのテストケース内で同じ発生順番とならないように制約表で無条件制約を指定しています。こうすることで１つのテストケースには同じ値（イベントの発生順番）が含まれないようになります。
生成結果を次に示します。
テストケースは２４件となりました。このテストケースのどの２つのパラメータ（イベント）をとってみても、２つのパラメータで可能な値（発生順序）がすべて網羅されています。このことから、２つのイベントの発生順序の組み合わせに起因する障害をすべて検出することができます。
All-Pair法を用いたことで、任意の２つのイベントの発生順序がすべて網羅されることになります。このことは、たとえばパラメータAの直後にパラメータEのイベントが発生するという順序が、各イベント発生順序の最初、途中、最後のすべての順番で現れることを意味しています。つまり、すべてのイベントのペアが組み合わせ可能なすべての順番で現れるということです。このことは、他のイベントとの関係で特定のイベント発生順番でのみ発生する障害も検出することができることを意味しています。
組み合わせるパラメータ数に３を指定することで３つのイベントの発生順序に起因する障害も検出することができます。この場合のテストケース数は６６前後となります。
なお、パラメータ数は８程度までが実用上の限界のようです。それ以上では計算時間が非常にかかってしまいます。
All-Pair法を用いた方法では、イベントが３種類あるとして、それらの発生順序が次の通りだとした場合
A B C
1, 2, 3
1, 3, 2
2, 1, 3
2, 3, 1
3, 1, 2
3, 2, 1
この６つのテストケースはいずれも固有の意味を持つと見なします。
一方、これとは異なる考え方も存在します。２つのイベントの発生順序にだけ注目し、２つのイベントの間に別のイベントが発生してもそれは無視する考え方です。上の順序では、A, B, Cの個々の発生順序だけに注目すれば、６つのテストケースは次のように３つにまとめることができます。なお最初と最後のイベントだけは、障害が発生しやすいという理由からすべてのイベントが現れるようにします。
A B C
1, 2, 3
2, 3, 1
3, 1, 2
このようにすることでより少ないテストケースとすることができます。こうした考え方で、３つのイベントの順序を網羅することも比較的少ないテストケースで実現することができます（上の例では３つのイベントの順序を網羅しています）。ただし、それと引き替えに異なる個々のイベントのそれぞれの順序に関しては網羅度が低くなります。例えばイベントAのすぐ後にはイベントBしか発生しないことになっています。それでも問題ないと考えるならば、こうした考え方も有効でしょう。
それでは不十分だと考えるなら、ここで説明したAll-Pair法を使用する方法が有効です。
「1因子のバグ発見率がp なら、2因子の組合せではp の2乗に期待される」は本当か？
発生する確率について、1000行あたりのバグ数をあてはめて上記を計算した結果を示します(ここでは、５件/Kstepで計算)。
単機能バグ発生率 = 5/1000 = 0.005
2因子間バグ発生率= (5/1000)^2 = 0.000025
3因子間バグ発生率= (5/1000)^3 = 0.000000125
200万行(=2000Kstep)の製品とすると、
単機能バグ数 = 5/1000×2,000,000 = 10,000件
2因子間バグ数= (5/1000)^2×2,000,000 = 50件
3因子間バグ数= (5/1000)^3×2,000,000 = 0.25件
となります。
私はこのことを知ったとき、強い違和感を覚えました。どういうことかというと、私のこれまでの経験から単機能バグ数に比較して2因子間バグ数があまりにも少なすぎると感じたのです。3因子間バグ数についても同様です。実際のソフトウェアテストにおいては、2因子間バグ数はここで示された数よりはるかに多く検出されるからです。単体テストで検出される単機能バグの件数を考慮にいれても2因子間バグの検出数が少なすぎます。200万行のプログラムで単機能バグ数が10,000件に対して、2因子間バグ数がその5/1000の50件しかないということは実際上ありえないと思います。ソフトウェアテストの現場では、ここで示された件数の十倍から数十倍はあると実感しています。
ではなぜこのような食い違いが起きたのでしょうか。単機能バグ発生率が5/1000なら、2因子間バグ発生率はそのまた5/1000になるということは一見間違いないように思われます。しかし、ここには前提条件が隠されています。2因子間バグ発生率というとき、存在する機能は２つしか想定されていないのです。3因子間バグ発生率については存在する機能は３つしか想定されていません。しかも3因子間バグ発生率では、3つの機能A、B、CがA→B→Cという形でのみ関係していると想定されています。こうした前提条件を認めれば、田口玄一氏の述べたことは正しいことになります。
しかし、現実のソフトウェアでは機能が２つとか３つだけといったものは数少ないでしょう。200万行のプログラムでは、機能の数は数百に達しているとみてもおかしくありません。そして数百の機能の中の１つの機能を取り上げてみれば、その機能が他のいくつもの機能と関係しているはずです。例えば平均してひとつの機能がそれ以外の10の機能と関係しているとすれば、バグの発生する確率は次のとおりとなります。
単機能バグ発生率 = 5/1000 = 0.005
2因子間バグ発生率= (5/1000)^2×10 = 0.00025
3因子間バグ発生率= (5/1000)^3×10×10 = 0.0000125
200万行(=2000Kstep)の製品とすると、
単機能バグ数 = 5/1000×2,000,000 = 10,000件
2因子間バグ数= (5/1000)^2×10×2,000,000 = 500件
3因子間バグ数= (5/1000)^3×10×10×2,000,000 = 25件
となります。つまり、ある機能がそれ以外の10の機能と関係していれば、2因子間バグ数は２つの機能しかない場合と比較して10倍多くなるということです。
これなら実際のソフトウェアテストの結果と大体辻褄があいます。こうしたことから、現実のソフトウェアにおいては、田口玄一氏の述べたことは成立しないという結論になります。なお直交表という言葉が出てきていますが、All-Pair法でも当てはまります。
パラメータと値の並び欄などの編集方法について
ユーザーズマニュアルには記載してありますが、PctMasterのパラメータと値の並び欄の編集方法などについて、意外と知られていないようなのであらためて説明したいと思います。
パラメータと値の並び欄に記入した後で、途中の行のパラメータを削除したり、新しいパラメータを挿入したい場合があります。またパラメータ行の並びを変更したい場合もあるかもしれません。このような場合、Excelのメニューから行の削除や挿入を行なうことは避けなければなりません。なぜならパラメータと値の並び欄に続く制約表や結果表の行位置がずれてしまい、PictMasterが正しく動作できなくなる可能性があるためです。
パラメータと値の並び欄の行を削除したり挿入したい場合はPictMasterの編集機能を使ってください。削除したり挿入したい行の１列目を右クリックすると次のように編集専用のコンテキストメニューが表示されるのでメニューを選択することで行の削除や挿入を行なうことができます。
行の削除や挿入といってもこの場合は実際に行の削除や挿入を行なっているわけではなく、記入されている内容のみを行単位で移動させているだけです。
制約表と結果表の行についてもパラメータと値の並び欄と同様に１列目を右クリックすることで編集専用のコンテキストメニューが表示されます。また制約表のタイトル欄（制約１、制約２～）を右クリックすることでも編集専用のコンテキストメニューが表示され、制約欄の削除と挿入を行なうことができます。
いずれの場合も一度に指定できる行および制約欄は１つのみです。