テストを行なっていくとソフトウェア信頼度成長曲線の傾きが小さくなっていくのはなぜか ？

ソフトウェアの品質を定量的に測定する尺度に「ソフトウェア信頼度成長曲線」があります。これは横軸にテスト時間などを取り、縦軸に障害の累積件数を取ってグラフを作成します。このグラフの傾きが小さくなると、テスト時間をかけた割に新しく検出される障害が少なくなるので、そのソフトウェアの品質が前よりも高くなったと判断することになります。このグラフに近似するゴンペルツ曲線などを当てはめて、残りの障害件数を予測したり、全障害件数の95%を検出するまでにあと何時間テスト時間が必要か、などを予測できるようになります。ソフトウェアの出荷判定の判断基準の一つにソフトウェア信頼度成長曲線のデータを使っている品質保証部門も少なくないと思われます。

このソフトウェア信頼度成長曲線は、テストを行なっていくとその傾きが小さくなっていく傾向があります。今回はその理由を考えてみましょう。

テストは同じテスト項目を繰り返し実施するとしまいには障害が一つも見つからなくなります。これをテストのことわざでは「殺虫剤のパラドックス」といいます。こういうテストのやり方をすると、ソフトウェア信頼度成長曲線は最後には傾きがゼロに限りなく近くなり、残り障害件数は0件に近づくでしょう。この結果は全くあてになりません。別のやり方でテストを行なえば容易に新しい障害が見つかると考えられるからです。

そうではなく、全く異なるテスト項目をそれぞれ１回づつ実施する場合を考えてみましょう。この場合は「殺虫剤のパラドックス」は起こりません。毎回新しいテストを実施することになります。しかし、こうした場合でもなぜかソフトウェア信頼度成長曲線は、テストを行なっていくとその傾きが小さくなっていきます。毎回新しいテストを実施しているのですから、コンスタントに新しい障害が見つかってもよさそうなものです。なぜこうした結果になるのでしょうか。

それを説明する有力な仮説の一つに、「あるテストで発見すべき障害がその前のテストで発見される」という性質があるというものです。例えば機能Aのテストを行なっていた時に、機能Aから呼び出される機能Bの障害が検出されるので、その後に機能Bのテストを行なうと既に障害が修正されているために新しく見つかる障害が少なくなるということです。

この説を裏付けるデータがあります。本ブログの 「障害の半分近くはテスト仕様書以外から見つかっている」  という記事で、テスト仕様書での確認事項で見つかった障害は全体の半数余りしかなく、残りの半数近くは確認事項以外で見つかっている、ということを紹介しています。このことは事後のテストで発見すべき障害が事前のテストで発見されるということを示唆していると言えます。

こうしたことの結果により、毎回新しいテストを実施していってもソフトウェア信頼度成長曲線の傾きは小さくなっていくと考えられます。ここで一つ疑問が湧きます。テストで見つかった障害を修正した場合、そのうちの何パーセントかはデグレード（いわゆるデグレ）を起こし、新しい障害を植え付けてしまっているという事実です。この障害のうちの何割かは後のテストで発見されるでしょう。その分だけ、ソフトウェア信頼度成長曲線の傾きが小さくなる程度が引き伸ばされることになります。

このことは、デグレードを検出するための専用のテストの必要性を示しています。このテストではあまり障害は見つかりませんが、デグレードによる障害を発見するためになくてはならないテスト項目です。このデグレ検出のためのテストは通常テスト工程の最後に行なわれるため、そのことがソフトウェア信頼度成長曲線の傾きを小さなものにすることに拍車をかけることになります。

これは、ソフトウェア信頼度成長曲線の「信頼度」に疑問を投げかけるものとなりえます。本来、単位テスト時間あたりに検出される障害の数はテスト期間中を通じて一定しているという前提条件がソフトウェア信頼度成長曲線の考え方にはあります。それが現実には徐々に少なくなっていくことからテスト時間に応じてソフトウェアの品質が変化し向上しているという根拠となるものです。しかし、テスト工程の最終段階にデグレ検出のためのテストが行われるために、単位テスト時間あたりに検出される障害の数が一定という前提条件が崩れてしまいます。この結果、実際よりもソフトウェアの品質が良いという結果になりがちな傾向をソフトウェア信頼度成長曲線は潜在的に持っているということができます。この問題の解決は難しそうです。

ここでソフトウェア信頼度成長曲線の政治的性格についてひとこと話しておいた方がよいでしょう。予定した出荷時期が迫ってくる中でソフトウェア信頼度成長曲線の傾きがなかなか収束しないという事態となった場合、出荷時期の厳守を優先させるためにソフトウェア信頼度成長曲線が収束した形にしたいという政治的誘惑にかられる場合がないとは言えません。ソフトウェア信頼度成長曲線はそれに与えるデータを工夫することでどのような形にでもすることができます。テスト時間の水増しなどでソフトウェア信頼度成長曲線から予想される残存バグ数を少なく見せかけることもできてしまいます。こうした意図的な歪曲にさらされやすいことがソフトウェア信頼度成長曲線の特徴の一つだともいうことができます。

ソフトウェア信頼度成長曲線は正しく使えばソフトウェアの出荷判定を行なう際の有力なデータとなりますが、それだけではなくそのほかの複数のメトリクスも合わせて総合的に判断して出荷判定を行ないます。

※ 6月11日 内容を追記しました。

線点図を使わないで任意の水準の直交表を作成する

2水準系の直交表を使用するHAYST法では、モデルの水準に合う直交表を得るために線点図を使用して2水準の直交表を多水準の直交表に変形する作業が必要です。ですが、この作業に必要な線点図が公開されているとは限りません。特に多水準の直交表に関する線点図はほとんど公開されていないのが実情です。線点図を作成するには専門的な知識が必要となるため、多くの場合作成は困難です。

しかし、2水準の直交表を使用しなければ線点図は不要です。ネット上からはより多水準の直交表がたくさん手に入れることができます。今回は、以前紹介した希望する水準の直交表が得られる Orthogonal Array Finder を使用して、希望する水準の直交表を作成してみましょう。

ここでは例として6水準が1因子、4水準が2因子、2水準が5因子の直交表を作成してみます。Orthogonal Array Finder に、6^1 4^2 を入力して直交表のリストを表示させます。そうすると次のリストが表示されます。

ここで上から２つ目の、6^3 2^8 を選択し、表示された直交表（6水準が3因子、2水準が8因子）をエディタにコピー＆ペーストします。エディタでファイルをセーブし、そのファイルをExcelで読み込みます。読み込んだら先頭行に因子名の行を挿入し、A、B、C… という具合に因子名を割り当てます。今回は2水準の因子は5個でいいので余る３つの2水準の因子を削除してからExcelファイルとしてセーブします。

今回欲しい直交表は、6水準が1因子、4水準が2因子、2水準が5因子ですから、6水準の因子２つを4水準の因子に変形します。変形前の直交表で6水準の因子２つを4水準の因子に変形するセルをExcelのフィルタ機能を使って絞り込みます。変形前の直交表を表１に示します。この表で緑色に塗りつぶしたセルが4水準に変形する必要のある、水準が4と5のセルです

次にExcelのフィルタ機能を使って、因子Bの水準が4と5のセルを抽出し、その水準を0、1、2、3に順番に書き換えます。同じように今度は因子Cの水準が4と5のセルを抽出し、その水準を0、1、2、3に順番に書き換えます。これで4水準の因子が２つ得られました。書き換えた結果を表２に示します。

2水準の直交表は初めに５つの因子に揃えているのでここでは何もする必要がありません。これで希望する6水準が1因子、4水準が2因子、2水準が5因子の直交表が得られたことになります。

オリジナルの直交表の水準数が希望する水準数より大きい場合は、今回のように余る水準を小さい水準に書き換えることで簡単に変形することができます。この反対に、オリジナルの直交表の水準数が希望する水準数より小さい場合は、話が面倒になります。どうしてもそういう直交表しか得られない場合は、希望する水準をオリジナルの水準に合わせて小さくするしかありません。これは同値分割を行なって、同値とみなせる複数の水準を１つの水準にまとめることです。ただし、そううまくいくとは限りません。同値分割できない水準なのに強引に同値とみなしてしまうと2因子間網羅率100%を保証することができなくなります。こうしたことはできるだけやるべきではありません。

さて、希望した直交表が得られたことで、この直交表の3因子間網羅率を確認してみましょう。その方法は次の通りです。

1. PictMasterのワークシートのすぐ右隣に新しいワークシートを設け原型シートとし、そのワークシートに直交表を貼り付ける。（下図参照。塗りつぶした部分は6水準を4水準に変形した部分）

2. PictMasterのパラメータと値の並びに直交表と同じ因子名と水準名を記入する。

3. PictMasterのもっとも水準数の大きいパラメータの水準に＋１した値を追加する。（下図参照。パラメータAに6を追加している）

4. 環境設定で「原型シートを使用」にチェックを入れ、「統計情報を表示」と「カバレッジを表示」にチェックを入れる。「デフォルトのシードで生成」を指定し、実行ボタンをクリックする。

この操作を行なうと次の40件のテストケースが生成されます。同時に3-wayカバレッジに79.4%と表示されます。

テストケースが36件でないのはPictMasterのもっとも水準数の大きいパラメータの水準に＋１した値(6)を追加したためです。因子Aに6が追加されたため、因子BとCの4水準との組み合わせとして4件のテストケースが追加されています。この新しい値の追加は原型シートの直交表をそのままPictMasterで流用させるために必要なことです。原型シートにない値がモデルの値に含まれていると（今回の場合は因子Aの6）PICTは原型シートの内容をそのまま流用してテストケースを生成します。これをしないと、PICTは直交表をそのまま流用することはしなくなるため、直交表の本来の3-wayカバレッジが算出できません。

テストケースの末尾の塗りつぶされた4行は、もっとも水準数の大きいパラメータの水準に＋１した値を追加したために新たに追加されたテストケースです。そのため表示された3-wayカバレッジの値は元の36件の場合とは厳密には一致しませんがほぼ同じと見なせる程度の値となります。この値は最小テストケース生成で行なっても同じ値となります。

次に比較のためにPairwise法で6水準が1因子、4水準が2因子、2水準が5因子の場合のテストケースを生成してみましょう。もっとも水準数の大きいパラメータの水準に＋１した値を削除し、環境設定で「原型シートを使用」のチェックを外し、「統計情報を表示」と「カバレッジを表示」にチェックを入れ、「最小テストケースを生成」を指定し、実行ボタンをクリックします。

この結果、次の25件のテストケースが生成されます。同時に3-wayカバレッジに66.9%と表示されます。

結果をまとめてみましょう。

直交表

　テストケース数＝36件　3因子間網羅率≒79.4%

Pairwise法

　テストケース数＝25件　3因子間網羅率＝66.9％

この結果はあくまでも今回のケースだけの場合ですが、ある程度は直交表とPairwise法の違いを表していると言えます。直交表はテストケース数は多いが3因子間網羅率が高い。Pairwise法はテストケース数は少ないが3因子間網羅率は低い。しごく当然の結果となりました。後はこの差をどう評価するかの問題でしょう。直交表の場合は番号から実際の水準名に置き換える作業が必要だったりと何かと時間がかかる点も考慮に入れる必要があります。それと、今回は取り上げませんでしたが、制約が関係する場合は話がややこしくなるので別の機会に取り上げたいと思います。

状態遷移のNスイッチテストでイベントの同値分割を行なう

状態遷移のNスイッチテストの問題点の１つに、ある状態遷移に２つ以上のイベントが関係する場合の問題があります。例えば、ウインドウを閉じる操作には、ウインドウの「閉じる」をクリックする、「キャンセル」ボタンをクリックする、キーボード操作でウインドウを閉じる、の３つがあります。これらの操作はいずれも同じ結果となりますが、同じ状態遷移に３つものイベントが関係すると、Nスイッチテストではテストケース数が大幅に増加してしまいます。

例えば、次の状態遷移図では同じ状態遷移にe11, e12, e13の３つのイベントが関係しています。

これから単純に2スイッチテストのテストケースを生成すると次の262件のテストケースとなってしまいます。１つのイベントだけの場合が34件ですから8倍近くものテストケースとなってしまいます。

PictMasterを使って状態遷移のNスイッチのテストケースを生成する方法では、エイリアスを使うことができます。エイリアスは同値と見なせる複数の値を１つの値として扱うことでテストケース数を削減することができる機能です。今回の状態遷移図でエイリアスを適用することができます。e11, e12, e13の３つのイベントをエイリアスとして１つのイベントとして扱うようにします。この場合のPictMasterのモデルを次に示します。

この図では制約８まで、1回の状態遷移の部分を示しています。実際には2スイッチテストですから、3回の状態遷移があります。そのやり方については前回の記事を参照してください。

こうしてエイリアス化することで生成されるテストケースは１つのイベントだけの場合と同じ34件となります。そして１つのイベントは本来の３つのイベントに展開されています。

この方法を採用した場合、ソースリストで各状態について３つのイベントが処理されていることを確認しておく必要があります。それさえやっておけば、エイリアスを使用するこの方法でテストケース数の大幅な増加を防ぐことができます。

なお、PictMasterで状態遷移のNスイッチテストのテストケースを生成する方法は、あまり大きな状態遷移図には適用できません。制約指定が複雑になりすぎて、PICTの処理時間が非常に長くなってしまうからです。近い将来、生成エンジンにCIT-BACHを使用したツールを作成する予定です。制約表とCIT-BACHを組み合わせると大きな状態遷移図のNスイッチテストのテストケースを短時間で生成できるようになります。

状態遷移のNスイッチのテストケースを手作業で作成する

Nスイッチテストでは、マトリクス形式の状態遷移表を行列式に見立てて、その積をとるツールを用いることでテストケースを得る方法が知られています。今回は、ツールを用いずに手作業で2スイッチテストのテストケースを作成してみましょう。

状態遷移のNスイッチテストといえば、ツールを使って行列の積をとる方法がほぼ常識となっています。以前の記事でも行列の積をとるツールを用いる方法を紹介したことがあります。ですが、ツールを使わずに手作業で、しかも2スイッチテストのテストケースを作成することはそれほど難しいことではありません。この記事ではその方法を詳しく説明します。

例として次の状態遷移図を用いることにします。

この状態遷移図から2スイッチテストのテストケースを生成してみましょう。最初に「制約表」を備えているPictMasterを使ってテストケースを生成してみます。生成の方法は最初にパラメータとその値として、パラメータに第１状態、第１イベント、第２状態…、という具合に第４状態まで定義し、状態には遷移前の状態名、イベントにはイベント名、遷移後の状態名を記入します。制約表で、ある状態のときにあるイベントである状態に遷移する、という状態遷移を定義します。

このPictMasterのモデルを次に示します。

この図では制約８まで、1回の状態遷移の部分を示しています。実際には2スイッチテストですから、3回の状態遷移があります。それをすべて示すには、制約２４まで示す必要がありますが、制約指定は同じパターンの繰り返しなのでそこまでは示していません。要は制約１～８をコピーして、第２状態の部分と第３状態の部分にペーストするだけです。つまり、同じ制約指定をカスケード状に繰り返しずらしてペーストことになります。この模式図を次に示します。

このようにずらしながら制約指定のペーストを繰り返すだけです。今回は2スイッチテストですから組み合わせるパラメータ数にはN+2=4を指定します。後は実行ボタンをクリックするだけで次の34件のテストケースが得られます。

では次に手作業で2スイッチテストのテストケースを作成する手順を説明します。対象とする状態遷移は同じものです。最初に手作業で作成し終わったテストケースを示し、その次にそれをもとに作成方法を説明することにします。

テストケースの作成手順は次の通りです。

1. テストケースの太枠の部分を作成する
　前状態とイベント、次状態を記入します。確認内容欄はその状態遷移で確認すべき事項を記入します。この欄は後で記入した方がよいでしょう。No.の欄は任意の色で塗りつぶしておきます。これはテストケースを追加していくときに分かりやすくするために必要です。

2. 次状態と同じ前状態のテストケースをコピー＆ペーストし右端の遷移先の欄にペースト先のNo.を記入する
　次に、次状態と同じ前状態で始まるイベント、次状態の組み合わせをコピーし、テストケースの末尾にペーストします。このとき、ペーストした行の番号を遷移先の欄に記入します。
　最初の例で説明すると、No.1の次状態はs1なので、前状態がs1であるNo.2,3,4のテストケースをコピーし、No.9以降にペーストします。そしてペーストしたNo.をNo.1の遷移先の欄に9,10,11と記入します。この操作をNo.8までの状態に関して繰り返します。ここまでが「第１状態」に関する手順です。

3. 続いて第２状態に関する部分について同じ操作を繰り返す
　ここまでで第２状態の部分までのテストケースが作成できました。これは1スイッチテストのテストケースになります。続いて 1. で行なったのと同じ操作を第２状態のテストケースについて繰り返します。

ここまでで２スイッチテストのテストケースが作成できたことになります。手順は単純な繰り返し作業ですので難しいところはないでしょう。遷移先のNo.を記入する際に間違わないように気をつける必要があります。コピー元は必ず第１状態の部分からコピーした方が間違いが少ないでしょう。

このテストケースでは、ツールで生成したテストケースとは違って、上から下に遷移先をたどっていく形になります。ツールで生成したテストケースは34件でしたが、手作業で作成したテストケースは59件となりました。この違いはツールで生成したテストケースは横方向に４つの状態を網羅しているのに対して、手作業で作成したテストケースは横方向に２つの状態だけを網羅していることによります。
　では手作業で作成したテストケースはツールで生成したテストケースと等価であると言えるでしょうか。それを確認するには、次の検算を行なうことで確認することができます。
　まず、ツールで生成したテストケースが２状態間の遷移をいくつ有しているかを計算します。このテストケースは１行に３つの状態遷移が含まれていますから、34×3=102件の２状態間の遷移があることになります。
　次に手作業で作成したテストケースが２状態間の遷移をいくつ有しているかを計算します。このテストケースは単純に59件という訳ではありません。遷移先の欄に2つ以上の遷移先が記入されていることから分かるように、本当の２状態間の遷移はもっと多くあります。この計算は次の方法で行ないます。
　第１状態の遷移先の欄について、左側の7件は元々のテストケースなので除外し、残りの真ん中と右側のNo.の個数を加算します。これは9件です。続いて、第２状態の遷移先の欄のNo.の個数をさらに加算します。+34件で=43件です。この43件は手作業で作成したテストケースに新たに追加すべき状態遷移先の数を意味しています。手作業で作成したテストケース59件に43件を加算すると102件となります。これはツールで生成したテストケースにおける２状態間の遷移の件数と一致しています。
　これで手作業で作成したテストケースとツールで生成したテストケースとが等価であることが分かりました。

今回紹介した方法は、実際のテスト作業で実用的に使用できるかというと少し改良の余地があります。特に複数の遷移先がある場合に、今どの遷移先のテストを行なっているのかが、このままでは分かりずらいという問題があります。

とはいえ、少々時間はかかりますが、手作業でも比較的単純作業で2スイッチテストのテストケースが作成できることだけはお分かりいただけたと思います。この操作を繰り返すことで3スイッチ以上のテストケースも作成することができます。しかし手作業なので煩雑な作業であることは確かです。


※ 6月7日 状態遷移図を差し替え　Mac/Windows用のドローソフトである ConceptDraw PRO  を用いて描画しています。使い方に慣れが必要ですが、慣れるととても便利です。

制約表が持つ可能性について

PictMasterの一番の特徴を上げるとすれば「制約表」になります。制約をサポートした組み合わせテストツールでの制約の指定方法はツールごとに異なりますが、いくつかに大きく分けることができます。

マトリクス表方式

　これは直交表系のツールにみられる方式ですが、縦軸と横軸に組み合わせるパラメータと値を割り当て、そのマトリクス表で「組み合わせできない組み合わせを指定する」方式です。この方式の良い点は、誰が見てもほとんど説明を受けなくてもすぐに意味が分かることにあります。

　一方、欠点は特定の組み合わせがOR条件となる制約を表現することできない点です。例えば、A=a1 のとき、B=b1、C=c1となる場合と、C=c1、D=d1となる場合の両方がOR条件である制約をマトリクス表で表現できないということです。これはマトリクス表だけのものではなく、組み合わせできない組み合わせを指定する方式すべてが共通して持つ欠点です。

　扱うパラメータと水準の数が少ない場合は問題になりませんが、この数が多くなるとマトリクス表が巨大になり、制約を表現することが難しくなります。

　またこの方式では「制約条件」と「制約対象」の区別が表現できません。どの組み合わせの時、どの組み合わせとなるかということを表現できないのです。できるのは「組み合わせできない組み合わせ」だけです。

　複数の制約が存在する場合、制約間の関係の把握が難しいという問題もあります。

関係式方式

　これはPairwise方式のツールに広くみられる方式ですが、制約に関係するパラメータと値を指定し、それらを関係式で表現する方式です。GUIを備えたツールではパラメータと値、演算子などはプルダウンメニューから選択することになります。この方式の良い点は、多くの制約をコンパクトに記述できる点にあります。またある程度複雑な制約も表現することができます。

　この方式の欠点はマトリクス表方式ほどではありませんが、複数の制約が存在する場合、制約間の関係の把握が難しいという問題があります。これは数多くの制約を指定した結果、各制約間の相互作用により「矛盾した制約」となってしまった場合に、その矛盾した制約を突き止めるのに苦労することにつながります。

　多くの制約を指定する場合に時間がかかることも問題です。どのパラメータのどの値か、どの演算子かをプルダウンメニューから指定しますが、指定すべき制約が多くなるとこれが意外に時間がかかります。

制約表方式

　これは制約を表形式で表現するという点ではマトリクス表方式と同じですが、その表現の仕方は全く異なっています。この方式では「制約条件」と「制約対象」の区別が表現できます。制約条件は色の塗りつぶしで表現します。

　複数の制約が存在する場合、制約間の関係が表形式で見やすく表示されるため各制約間の関係の把握が容易です。
　極めて複雑な制約でもカラフルな制約表を見ることで直感的に理解できるようになります。

　制約の指定にかかる時間は３つの方式の中で一番短くて済みます。

　もちろん制約表方式にも欠点はあります。表方式であるため、マトリクス表ほどではありませんが大きな表となる場合があります。また、セルの中に値を記入する方式なので、記入する値が多いとスペースが足りなくなります。

　こうした問題に対処するため、PictMasterではウインドウ分割（CTL-e押下）で表を部分的にスクロールできたり、スペースが足りなくなる問題についてはExcelベースであることから、行の高さを調節することで解決できるようにしています。

制約表方式の一番のメリットは、非常に複雑な制約を簡単に分かりやすく表現できる点にあります。このことがPictMasterの適用対象を拡張するうえで大きな原動力となっています。

普通の組み合わせツールでデシジョンテーブルの複雑な制約を表現しようと考える人はいないでしょう。制約表では簡単にそれができてしまいます。もともと制約表の構造がデシジョンテーブルの構造と酷似しているという理由もありますが…。

同様に制約表を用いることで状態遷移テストの技法であるN-スイッチテストのテストケースを自動生成することも可能です。この方法のメリットは、同値クラスとみなせる複数のイベントをエイリアスで１つのイベントとして扱うことができること、特に重要と考えられる特定の状態とイベントの組み合わせを値の重みづけの機能を用いることで重点的にテストするテストケースが生成できること、ツールからテストにそのまま使えるテストケースが生成できること、などがあります。

今後はこれらのテスト技法に制約表と組み合わせツールを適用することで、テストケース自動生成の実用化を目指す予定です。

※ 6月8日 重みづけの記述を削除　重みづけの機能について有効ではないことが判りましたので削除しました。