ソフトウェアテストにおけるシステムとは
ソフトウェアテストがそのテスト対象とするシステムの最も簡潔な表現の１つは次のとおりになるでしょう。
「システムとは、入力と条件をもとに計算を行ない、その結果を出力するコンピュータである。」
出力 ＝ 入力×条件×計算
ｚ ＝ ｆ（ｘ，ｙ） 二変数関数
言い換えると、
「システムとは、入力 ｘ と、条件 ｙ による二変数関数の計算を行ない、その結果 ｚ を出力するコンピュータである。」
入力 ｘ は、ユーザによる操作、タイムアウトによるイベント発生など。
条件 ｙ は、機能の動作を指定するシステムデータ、システムが置かれた環境がもたらす影響など。
出力 ｚ は、入力と条件の組み合わせにもとづくシステムの振る舞いを意味します。出力の中にはシステムの条件を変化させるもの（オートマトン：状態遷移）もあります。
機能Aとは、ｚa ＝ ｆ（xa，ya） 機能Bとは、ｚｂ ＝ ｆ（ｘｂ，ｙｂ）
機能の違いは、変数 ｘ と ｙ の組み合わせに依存します。
テストにおいては、変数 ｘ（入力）と、ｙ（条件）の組み合わせを可能な限り網羅する必要があります。この際、可能であれば同値分割・境界値分析を適用します。テスト対象の性質に合わせて適切なテスト技法を決定することになります。
デシジョンテーブルは難しい！？ CFD技法を使ってみる 【5月20日更新】
デシジョンテーブルはテスト対象が複雑なビジネスルールを持つ場合に有効なテスト技法です。
デシジョンテーブルは、直接テスト対象から作成することができますが、「ＣＥＧ（原因結果グラフ）」や「CFD技法」を使用して作成することもできます。今回はCFDを使ってデシジョンテーブルを作成してみました。
デシジョンテーブルの問題として以前に引用したことのあるJaSST'07 Tokyo での「三賢者、テストを語る （DTvsCEGvsCFD）」 のDTの「入場料問題」（28ページ目）を使うことにします。この問題を以下に示します。
この問題をテストするデシジョンテーブルを作成するには、アクションに影響を与える条件をすべて洗い出す必要があります。
この問題の仕様には、６歳で小学生ではない人はどう扱うのかといったように不明確な点があるのですが、問題をいたずらに複雑化しないためにそれは無視することにします。
アクションに影響を与える条件には以下のものがあります。
・個人
・団体
・一般
・小学生
・県内在住
・６歳未満
・６５歳以上
この問題の仕様には注意すべき点があります。県内在住の小学生は、個人・団体と一般・小学生からなるマトリクスからは独立しているということです。これを考慮しないで県内在住の小学生もマトリクスに含めてCFDを作成してしまうと、県内在住の小学生をどう扱ったらよいか収拾がつかなくなってしまいます。仕様では、県内在住の小学生は、個人・団体の如何を問わず、無料となる仕様です。
出来上がったCFDを示します。県内在住の小学生は、個人、団体、一般、県外在住の小学生からなる入場料のマトリクスからは独立した条件としています。マトリクスに含める小学生は県外在住の小学生に限定しています。
このCFDから作成したデシジョンテーブルです。
ルールは７つとなりました。CFDでデシジョンテーブルを書くと、団体と個人の上位の条件がまずあって、その中に入れ子として下位条件の形で一般と県外の小学生という分け方になります。
直接デシジョンテーブルを作成する場合は、各条件の組み合わせをすべて網羅したうえで、通常は結果に影響を与えない組み合わせを削除し、さらに結果に影響を与えない原因について「－」を記入する必要があります。これらの作業で間違いの入り込む余地があるため、細心の注意が必要とされます。
それに対して、CFD技法では、条件の組み合わせが流れ線の結合で表現されるため、余計な組み合わせが発生することはありません。必要最小限の組み合わせが原因間を結ぶ流れ線によっておのずと決まるため、間違いの入り込む余地がなく、最初から少ないテストケースのデシジョンテーブルを作成することができます。
CFD技法は原因の洗い出しさえ間違わなければ、正しいデシジョンテーブルを比較的容易に作成できる優れたテスト技法だと感じました。
PictMaster v4.3.1 をリリースしました。
4.3.1での変更点は以下の通りです。
【機能改善】
・多くの制約があるときに、コンテキストメニューから「列の挿入」を選択した場合の処理時間を短縮しました。
PictMaster v4.3.1 は以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
多重割込みの組み合わせを網羅する
PictMasterを用いていくつかの割込み優先度を持つシステムでの多重割込みの可能な組み合わせを網羅するテストケースを作成することができます。ここでは例として３つの割込み優先度（レベル）を持つシステムを考えてみます。
割込み優先度が３つの場合、発生する割込み事象（イベント）には３つの割込み発生と３つの割込み処理終了の合計６つがあることになります。モデルでは６つの割込み事象が発生する順番をパラメータとし、個々の割込みで発生する割込み優先度ごとの割込み発生と割込み処理終了を値とします。
割込みの優先度は、割込みA ＜ 割込みB ＜ 割込みC とし、割込みCが最も高いものとします。多重割込み処理がどのように行なわれるのかを次の例をもとに説明します。
②．割込みレベルAの割込み要因がONになるが、優先度の高いレベルBの割込み処理が実行中なので待ち合わせとなる。
③．割込みレベルCの割込みが発生し割込み処理が開始される。このとき優先度の低い割込みレベルBの割込み処理は中断する。
④．割込みレベルCの割込み処理が終了する。割込みレベルBの割込み処理の中断点から処理が再開される。
⑤．割込みレベルBの割込み処理が終了する。待ち合わせとなっていたレベルAの割込みが発生し、レベルAの割込み処理が開始される。
⑥．割込みレベルAの割込み処理が終了する。
以上は多重割込み処理の一例ですが、多重割込み処理には次のルールがあります。
【多重割込み処理のルール】
(1) 割込み要因がONとなった場合、より優先度の高い割込み処理が実行中でなければその割込みが発生し、割込み処理が実行される。
(2) 割込み要因がONとなった場合、より優先度の高い割込み処理が実行中であればその割込みは待ち合わせとなる。
(3) 割込み処理実行中により優先度の高い割込みが発生すると、実行中の割込み処理は中断され、優先度の高い割込み処理が実行される。
(4) 割込み処理が終了した場合、中断されている割込み処理があればそのうちの最も優先度の高い割込み処理が再開される。ただし、その処理よりも優先度の高い割込みが待ち合わせ状態である場合は、待ち合わせ状態だった割込みが発生し、割込み処理が実行される。
(5) 割込み処理が終了した場合、中断されている割込み処理がなく、待ち合わせ状態の割込み要因があればそのうちの最も優先度の高い割込みが発生し、割込み処理が開始される。
このルールを満足する多重割込みの組み合わせを網羅することにします。このテストケースを生成するモデルと制約指定を次に示します。
パラメータの事象１～６は、３種類の割込みの発生と対応する割込み処理の終了が発生する順番を意味しています。パラメータの値は、その順番で可能な割込み発生または割込み処理終了を意味しています。
このモデルでは多重割込みの組み合わせを生成することを目的としています。例えば事象１から事象２までは、３種類の割込みのいずれかが発生可能であり、割込み処理の終了は実行されません。事象３になると優先度の高い割込みCと割込みBの割込み処理の終了が可能となります。事象４では割込みBの割込み処理の終了はありません。なぜなら、仮に事象４で割込みBの割込み処理が終了したとすると、残された割込み処理は割込みAのみとなります。そうすると事象５は割込みAの発生で事象６は割込みAの割込み処理の終了となります。しかし、このモデルでは多重割込みの組み合わせを網羅することを目的としているのでこの場合の事象５～６は多重割込みではないため、この組み合わせは除外する必要があるのです。したがって事象４には割込みBの割込み処理の終了は含まれないことになります。
制約１は無条件制約を使用して１つのテストケースで同じ値が出現しないようにしています。制約２～４で割込み処理Bおよび割込み処理Cの処理終了となった場合に次に発生可能な事象を指定しています。
このモデルと制約指定で生成された多重割込みのテストケースを次に示します。ここで割込みの「発生」となっていてもより優先度の高い割込み処理が実行中の場合、その割込みは待ち合わせ状態となることに留意してください。
テストケースは１２件となりました。組み合わせるパラメータ数を６に設定し、全数組み合わせとした場合も同じ１２件となります。これはこの制約指定による可能な組み合わせが１種類しか存在しないためです。
割込みレベルが３つの場合は、手作業でもデシジョンテーブルを用いて組み合わせを作れそうですが、４つの場合はどうなるでしょうか。１つ割込みレベルが増えただけですが、可能な事象の組み合わせは飛躍的に増加します。割込みレベルが４つの場合のモデルを次に示します。
事象４には割込みBの処理終了がありません。仮に事象４に割込みBの処理終了があるとした場合、事象１～３のいずれかで割込みBが発生している必要があることになります。かつ割込みBより優先度の高い割込みCまたは割込みDの少なくともどちらかが事象１～２のいずれかで発生しており、かつ事象３でその割込み処理終了となる必要があります。この条件を満たす組み合わせは、事象４の割込みBの処理終了の時点で次に処理すべき割込み処理がない状態になってしまいます。多重割込みのテストケースを生成することが目的なのですが、この時点で多重割込みではなくなってしまいます。したがって事象４に割込みBの処理終了は含めないようにする必要があるのです。事象４が割込みCの処理終了である場合、同じ理由で事象１と事象２に割込みDと割込みCの発生を含む組み合わせは制約指定で除外する必要があります。
以上で述べた事象４の時点でいったん割込み処理がなくなる組み合わせを次に示します。
事象６にも割込みBの処理終了がありません。仮に事象６に割込みBの処理終了があるとした場合、事象７と８には割込みAの発生とその処理終了だけが組み合わせ可能です。これは事象６で割込みBの処理が終了した時点で多重割込み状態ではなくなってしまうため、事象６には割込みBの処理終了を含めないようにする必要があります。
次に４つの割込みレベルをもつモデルの制約指定を示します。制約の数は３６ありますが難しいところはなく機械的に記入することができます。
制約１は無条件制約を使用して１つのテストケースで同じ値が出現しないようにしています。制約２～３４で割込み処理B、割込み処理Cおよび割込み処理Dの処理終了となった場合に次に発生可能な事象を指定しています。制約３５と制約３６で前に述べたように途中で多重割込みでなくなる組み合わせを除外しています。制約３６は制約３５との関係をAND条件とするために制約条件に異なる色を使っています。
割込みレベルが４つある場合の多重割込みの組み合わせは、２つの要因の組み合わせを網羅した場合、５６件となりました。８つの要因を網羅した全数組み合わせの場合は１１２件となります。
実際の割込みでは、同じ割込みレベルにいくつもの割込み要因が存在してい場合がほとんどですが、そこまで考慮した組み合わせでは制約の数が５０個までという制限を超えてしまうため扱うことができません。仮に可能だとした場合、生成される組み合わせは膨大な件数になりそうです。
「オープンソースのソフトウェアだから３因子以上の障害が多い」は本当か ？
障害がいくつの要因の組み合わせで発生しているかを示す例として、2004年に IEEEで発表された論文（Software Fault Interactions and Implications for Software Testing）の表がよく引用されます。（表１）
（注）この論文は次のURLから読むことができます。
http://csrc.nist.gov/groups/SNS/acts/documents/TSE-0172-1003-1.pdf
この表にはオープンソースのソフトであるブラウザ（Mozilla）とサーバ（Apache）が含まれています。
表の中でデータがそろっている組込み機器、ブラウザ、サーバおよびデータベースについて、いくつの要因の組み合わせで発生する障害が多いかに注目すると、ブラウザとサーバが他のソフトとは異なり、２つ以上の要因の組み合わせで発生する障害が特に多いことがわかります。この理由としてしばしば持ち出されるのが、
「オープンソースのブラウザやサーバのように、世界中の多くの人が関わっているものについては4因子以上の組み合わせ問題も発生していますが、そちらは設計の改善で対応すべき問題でありソフトウェアテストの課題ではないと考えます。」
といった主張です。つまり、オープンソースのソフトだから世界中の人々が独自に手を加えているため、インターフェースの整合性が取りずらくなり、多くの因子の組み合わせで発生する障害が起きやすいのだ、という考え方です。そうだからインターフェースの齟齬が起きないように「設計の改善で対応すべき問題であり」、テストとは無関係なので「ソフトウェアテストの課題ではない」という結論に落ち着いてしまっています。
一見するともっともらしい主張ですが本当にそうでしょうか？
IEEEで発表された論文には、各ソフトウェアがテスト工程のどの段階であるのかが示されています。それによると、組込み機器は市場への出荷後であり、ブラウザとサーバはベータテストの段階であり、データベースは統合テストの段階となっています。市場出荷後であるにもかかわらず、１つの要因で発生する障害が最も多い組込み機器は論外ですので検討対象から外すとして、ブラウザとサーバはデータベースソフトより３因子以上の要因の組み合わせで発生する障害がかなり多くなっています。この違いはやはりオープンソースのソフトとそうでないソフトの違いによるものなのでしょうか。
当ブログでは、以前からテストの最終段階になると２つ以上の要因の組み合わせによる障害が多くを占めるようになる、ということを指摘してきました。たとえば次の記事です。
「出荷後の障害で最も多いのは２要因間の組み合わせに起因している 」 2008年6月23日
「有名な IEEE の FTFI の表は信頼できるか？ 」 2008年9月10日
「ソフトウェアの品質を示す新しい指標の提案 」 2008年9月29日
「市場障害はいくつの要因の組み合わせで発生しているか 」 2010年7月12日
「テストが進むにつれて２つの要因の組合せで発生する障害が多くを占める 」 2011年3月9日
ある製品の総合テストの「最終段階」で発見された障害がいくつの要因の組み合わせで占められているかを示す表があります。
このデータはオープンソースのブラウザのデータとよく似ています。もちろんこの製品はオープンソースなどではありません。ブラウザとサーバのデータはいずれもテストの最終段階であるベータテストでの結果であることに注意すべきです。それに対してデータベースは統合テスト全体でのデータです。
オープンソースのブラウザとサーバで４因子以上の組み合わせ問題が発生しているのは「オープンソースソフトウェアの設計の改善」で対応できる問題ではなく、テスト工程の終盤で見られるごく一般的な傾向であり、それゆえ、テスト工程の終盤では２要因の組み合わせのみならず、３要因の組み合わせについても考慮したテストが必要かもしれないのです。
しかしながら３要因の組み合わせテストはコストが非常にかかります。どうテストを行なうべきかは慎重に検討することが必要だと思います。