境界値分析・再考
境界値分析は同値分割と並んで最も基本的なテスト技法です。境界値分析のやり方は知らなくても同じ考え方でテストを行なっている人もいるはずです。それほどまでによく知られているテスト技法です。
そういう境界値分析ですが、今回改めてスポットをあてて見ることにしましょう。
境界値分析の定義をあげてみます。
1. 境界値分析は、同値クラスの境界上のデータで比較判定の誤りが起きやすいという経験的事実に着目したテスト技法である。
2. 境界値には、処理が有効となる有効境界値と、処理が無効となる無効境界値がある。
3. テストでは境界値となる値と、そのとなりの境界を越えた値を使用する。境界値分析を行なう際は、境界値を図で表現するほうが分かりやすくなる。
境界値分析の例をあげてみます。
年齢が成年に達しているかを判定するソフトウェアがあります。この有効な境界値は２０歳、無効な境界値は１９歳となります。
さて、この成年判定ソフトウエアをテストするには、年齢にどのような値を使用すればよいでしょうか。普通に考えると、有効同値クラスの20と無効同値クラスの19があればよいということになるでしょう。
この成年判定ソフトウエアの年齢を判定する比較演算子の書き方には何種類かあります。最初に正しい書き方をあげて見ましょう。
(1) 年齢 >= 20 真なら成年、偽なら未成年
(2) 年齢 <= 19 真なら未成年、偽なら成年
(3) 年齢 > 19 真なら成年、偽なら未成年
(4) 年齢 < 20 真なら未成年、偽なら成年
次に間違った書き方をあげてみます。
(5) 年齢 <= 20 真なら成年、偽なら未成年
(6) 年齢 >= 19 真なら未成年、偽なら成年
(7) 年齢 < 19 真なら成年、偽なら未成年
(8) 年齢 > 20 真なら未成年、偽なら成年
これらは比較演算子の書き方を逆に間違えた例です。
(9) 年齢 >= 20 真なら未成年、偽なら成年
(10) 年齢 <= 19 真なら成年、偽なら未成年
(11) 年齢 > 19 真なら未成年、偽なら成年
(12) 年齢 < 20 真なら成年、偽なら未成年
これらは比較演算子の書き方自体は正しいですが、判定の真偽を逆に間違えた例です。
(13) 年齢 <= 20 真なら未成年、偽なら成年
(14) 年齢 >= 19 真なら成年、偽なら未成年
(15) 年齢 < 19 真なら未成年、偽なら成年
(16) 年齢 > 20 真なら成年、偽なら未成年
これらは比較演算子の書き方と判定の真偽を共に間違えた例です。
(17) 年齢 >= 19 真なら成年、偽なら未成年
(18) 年齢 <= 20 真なら未成年、偽なら成年
(19) 年齢 > 20 真なら成年、偽なら未成年
(20) 年齢 < 19 真なら未成年、偽なら成年
これらは判定に使用する境界値を間違えた例です。
(21) 年齢 >= 19 真なら未成年、偽なら成年
(22) 年齢 <= 20 真なら成年、偽なら未成年
(23) 年齢 > 20 真なら未成年、偽なら成年
(24) 年齢 < 19 真なら成年、偽なら未成年
これらは判定に使用する境界値と判定の真偽を共に間違えた例です。
いずれの間違いも、有効同値クラスの20と無効同値クラスの19があれば見つけることができます。
次の間違った書き方はどうでしょうか。
(25) 年齢 = 20 真なら成年、偽なら未成年
(26) 年齢 = 19 真なら未成年、偽なら成年
この間違いは比較演算子の > や < を書き忘れた例です。コーディングミスの例としては珍しいと思われる間違いです。これらの間違いは有効同値クラスの20と無効同値クラスの19だけでは見つけることができません。正常終了してしまいます。
(25)の間違いを見つけるには境界値ではない有効同値クラスの値が１つ必要です。(26)の間違いを見つけるには境界値ではない無効同値クラスの値が１つ必要です。
こうしたタイプのコーディングミスはかなり珍しいと思いますがないとは言えません。テスト対象がミッションクリティカルだったり、セーフティクリティカルだったりする場合には徹底的なテストが必要とされるため、境界値ではない有効同値クラスの値と境界値ではない無効同値クラスの値を含めたテストが必須になると思われます。
そういう境界値分析ですが、今回改めてスポットをあてて見ることにしましょう。
境界値分析の定義をあげてみます。
1. 境界値分析は、同値クラスの境界上のデータで比較判定の誤りが起きやすいという経験的事実に着目したテスト技法である。
2. 境界値には、処理が有効となる有効境界値と、処理が無効となる無効境界値がある。
3. テストでは境界値となる値と、そのとなりの境界を越えた値を使用する。境界値分析を行なう際は、境界値を図で表現するほうが分かりやすくなる。
境界値分析の例をあげてみます。
年齢が成年に達しているかを判定するソフトウェアがあります。この有効な境界値は２０歳、無効な境界値は１９歳となります。
さて、この成年判定ソフトウエアをテストするには、年齢にどのような値を使用すればよいでしょうか。普通に考えると、有効同値クラスの20と無効同値クラスの19があればよいということになるでしょう。
この成年判定ソフトウエアの年齢を判定する比較演算子の書き方には何種類かあります。最初に正しい書き方をあげて見ましょう。
(1) 年齢 >= 20 真なら成年、偽なら未成年
(2) 年齢 <= 19 真なら未成年、偽なら成年
(3) 年齢 > 19 真なら成年、偽なら未成年
(4) 年齢 < 20 真なら未成年、偽なら成年
次に間違った書き方をあげてみます。
(5) 年齢 <= 20 真なら成年、偽なら未成年
(6) 年齢 >= 19 真なら未成年、偽なら成年
(7) 年齢 < 19 真なら成年、偽なら未成年
(8) 年齢 > 20 真なら未成年、偽なら成年
これらは比較演算子の書き方を逆に間違えた例です。
(9) 年齢 >= 20 真なら未成年、偽なら成年
(10) 年齢 <= 19 真なら成年、偽なら未成年
(11) 年齢 > 19 真なら未成年、偽なら成年
(12) 年齢 < 20 真なら成年、偽なら未成年
これらは比較演算子の書き方自体は正しいですが、判定の真偽を逆に間違えた例です。
(13) 年齢 <= 20 真なら未成年、偽なら成年
(14) 年齢 >= 19 真なら成年、偽なら未成年
(15) 年齢 < 19 真なら未成年、偽なら成年
(16) 年齢 > 20 真なら成年、偽なら未成年
これらは比較演算子の書き方と判定の真偽を共に間違えた例です。
(17) 年齢 >= 19 真なら成年、偽なら未成年
(18) 年齢 <= 20 真なら未成年、偽なら成年
(19) 年齢 > 20 真なら成年、偽なら未成年
(20) 年齢 < 19 真なら未成年、偽なら成年
これらは判定に使用する境界値を間違えた例です。
(21) 年齢 >= 19 真なら未成年、偽なら成年
(22) 年齢 <= 20 真なら成年、偽なら未成年
(23) 年齢 > 20 真なら未成年、偽なら成年
(24) 年齢 < 19 真なら成年、偽なら未成年
これらは判定に使用する境界値と判定の真偽を共に間違えた例です。
いずれの間違いも、有効同値クラスの20と無効同値クラスの19があれば見つけることができます。
次の間違った書き方はどうでしょうか。
(25) 年齢 = 20 真なら成年、偽なら未成年
(26) 年齢 = 19 真なら未成年、偽なら成年
この間違いは比較演算子の > や < を書き忘れた例です。コーディングミスの例としては珍しいと思われる間違いです。これらの間違いは有効同値クラスの20と無効同値クラスの19だけでは見つけることができません。正常終了してしまいます。
(25)の間違いを見つけるには境界値ではない有効同値クラスの値が１つ必要です。(26)の間違いを見つけるには境界値ではない無効同値クラスの値が１つ必要です。
こうしたタイプのコーディングミスはかなり珍しいと思いますがないとは言えません。テスト対象がミッションクリティカルだったり、セーフティクリティカルだったりする場合には徹底的なテストが必要とされるため、境界値ではない有効同値クラスの値と境界値ではない無効同値クラスの値を含めたテストが必須になると思われます。
PictMaster 5.7.7J をリリースしました
PictMaster v5.7.7J をリリースしました。
今回のバージョンでは若干の機能改善を行なっています。
【機能改善】
・拡張サブモデルを指定して生成した場合、モデル(*1)によっては前バージョンより若干テストケース数が少なくなるようにした。
*1: 拡張サブモデルで指定したパラメータのみ指定したパラメータ組み合わせ数で生成し、他のパラメータは組み合わせ数１で生成したテストケースが、拡張サブモデル処理内部で組み合わせ数２として再生成した場合にすべて組み合わせに取り込まれなかった場合(*2)に、前バージョンまでは最も値の数が多いパラメータの値の数だけ最終的なテストケースに追加していたが、本バージョンからは２番目に値の数が多いパラメータの値の数だけ最終的なテストケースに追加するようにした。
このことで前バージョンまでと比べて最も値の数の多いパラメータの値の数から、２番目に値の数の多いパラメータの値の数を引いた数だけテストケース数が少なくなる。
*2: 例えば値の数が 8,5,3,3,2,2,2 のモデルで拡張サブモデルに最初の３つのパラメータを組み合わせ数３に指定して生成を行なうと、前バージョンまでは128件だったが本バージョンでは125件となる。
PictMaster v5.7.7J は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
今回のバージョンでは若干の機能改善を行なっています。
【機能改善】
・拡張サブモデルを指定して生成した場合、モデル(*1)によっては前バージョンより若干テストケース数が少なくなるようにした。
*1: 拡張サブモデルで指定したパラメータのみ指定したパラメータ組み合わせ数で生成し、他のパラメータは組み合わせ数１で生成したテストケースが、拡張サブモデル処理内部で組み合わせ数２として再生成した場合にすべて組み合わせに取り込まれなかった場合(*2)に、前バージョンまでは最も値の数が多いパラメータの値の数だけ最終的なテストケースに追加していたが、本バージョンからは２番目に値の数が多いパラメータの値の数だけ最終的なテストケースに追加するようにした。
このことで前バージョンまでと比べて最も値の数の多いパラメータの値の数から、２番目に値の数の多いパラメータの値の数を引いた数だけテストケース数が少なくなる。
*2: 例えば値の数が 8,5,3,3,2,2,2 のモデルで拡張サブモデルに最初の３つのパラメータを組み合わせ数３に指定して生成を行なうと、前バージョンまでは128件だったが本バージョンでは125件となる。
PictMaster v5.7.7J は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
テスト工数がどうしても足りないときは2Wayカバレッジを100%よりも下げて対応する
開発プロジェクトでは、テスト工数がどうしても足りない場合があります。リリース期限は変えられないし、かといって人は増やせないといったときです。過去のテスト実績から一人が１日で消化できるテスト項目数には限度があることが分かっています。
過去の実績から見てとても工数が足りない場合はテストケース数を減らすしかありません。もしテストケースが組み合わせテストである場合は、テストケース数を削減する方法には３つの方法があります。
1. 組み合わせは行なわず、その中から重要と思われるいくつかを抽出してそれだけテストする。
2. 組み合わせは行なわず、すべての要因が必ず１回は出現する要因を列挙したテストとする。
3. 組み合わせは行なうが、２因子間の組み合わせ網羅率を100%ではなく80%程度とする。
最初の方法ほどテストケース数の削減効果が大きくなりますが、それだけに組み合わせの網羅率は下がることになります。テスト対象が新規機能である場合はできるだけ組み合わせ網羅率は下げたくないものです。こうした場合に有効に使える方法として３つ目の２因子間の組み合わせ網羅率を100%ではなく80%程度とする方法です。
次の表は、いくつかのテスト項目に対して２因子間の組み合わせ網羅率を80%とした場合のテストケース数の削減率を表したものです。
いくらかばらつきがありますが、おおよそ４割程度テストケース数を減らすことができています。テストケース数があまり減らないテスト項目は、各要因の値の数があまりばらついていない場合です。この逆に値の数がばらついているとテストケース数の削減率が大きくなります。
どうしても工数が足りない場合には、２因子間の組み合わせ網羅率を100%ではなく80%程度としてテストケース数を削減する方法が有効です。
あまり重要ではなく、障害が出そうにないと考えられるテスト対象については思い切って組み合わせは行なわず要因列挙型にする方法があります。この方法ではテストケース数は約７割程度減らすことができます。さらに機能に変更がないものについてはテストケース数を大幅に削減し、代表的なものだけを実施する要因限定テストとする方法もあります。
テスト対象のリスクに応じて柔軟な方法でテストケース数を決めるようにしたいものです。
過去の実績から見てとても工数が足りない場合はテストケース数を減らすしかありません。もしテストケースが組み合わせテストである場合は、テストケース数を削減する方法には３つの方法があります。
1. 組み合わせは行なわず、その中から重要と思われるいくつかを抽出してそれだけテストする。
2. 組み合わせは行なわず、すべての要因が必ず１回は出現する要因を列挙したテストとする。
3. 組み合わせは行なうが、２因子間の組み合わせ網羅率を100%ではなく80%程度とする。
最初の方法ほどテストケース数の削減効果が大きくなりますが、それだけに組み合わせの網羅率は下がることになります。テスト対象が新規機能である場合はできるだけ組み合わせ網羅率は下げたくないものです。こうした場合に有効に使える方法として３つ目の２因子間の組み合わせ網羅率を100%ではなく80%程度とする方法です。
次の表は、いくつかのテスト項目に対して２因子間の組み合わせ網羅率を80%とした場合のテストケース数の削減率を表したものです。
いくらかばらつきがありますが、おおよそ４割程度テストケース数を減らすことができています。テストケース数があまり減らないテスト項目は、各要因の値の数があまりばらついていない場合です。この逆に値の数がばらついているとテストケース数の削減率が大きくなります。
どうしても工数が足りない場合には、２因子間の組み合わせ網羅率を100%ではなく80%程度としてテストケース数を削減する方法が有効です。
あまり重要ではなく、障害が出そうにないと考えられるテスト対象については思い切って組み合わせは行なわず要因列挙型にする方法があります。この方法ではテストケース数は約７割程度減らすことができます。さらに機能に変更がないものについてはテストケース数を大幅に削減し、代表的なものだけを実施する要因限定テストとする方法もあります。
テスト対象のリスクに応じて柔軟な方法でテストケース数を決めるようにしたいものです。
「制約表」はデシジョンテーブルと似た構造を持っている
PictMasterを用いてデシジョンテーブルを作成する方法についてはこれまで何度か説明してきましたが、今回は制約表の構造がデシジョンテーブルの構造とほぼ同じであることについて説明します。組み合わせテストツールでデシジョンテーブルを作成することに違和感を持つ人もいるかもしれませんが、制約表がどのような構造を持っているかが分かれば違和感も解消されるのではないかと思います。
デシジョンテーブルは条件の全数組み合わせであり、その組み合わせに論理関係が存在します。この論理関係は、条件と条件間の論理関係と、条件と動作間の論理関係の２つに分類することができます。
条件と条件間の論理関係とは例えば、中学生と中学生都内在住という２つの条件がある場合、中学生＝Yesならば中学生都内在住はYesとNoがあるが、中学生＝Noならば中学生都内在住はNoのみとなるような論理関係のことです。
条件と動作間の論理関係とは例えば、年齢という条件が中学生以上と小学生以下であるとき、料金という動作が中学生以上と小学生で異なるような論理関係のことです。条件と条件間の論理関係は動作とは独立して定義することができますが、このことは条件と動作が無関係であることを意味しません。各条件は動作と何らかの論理関係を持っているからです。
デシジョンテーブルの各動作に対応して、各条件は一意に決定することができます。このことは、各動作を条件との論理関係を表す制約条件とし、その制約条件と組み合わせることが可能な条件の組み合わせを制約対象として定義した制約表を用いることでデシジョンテーブルを表現することが可能であることを意味します。
デシジョンテーブルと制約表の対応を次に示します。
制約表の記入では１つの動作に着目し、それを制約条件とします。異なるルールで同じ動作となる場合は、同じ制約条件（動作）を隣り合う制約として定義することで、１つの動作で２つ以上のルールをOR条件として定義することができます。上の図では制約２と制約３がそれに該当します。
以上のようにPictMasterでデシジョンテーブルの制約表を定義し、組み合わせるパラメータに条件の数を指定することで、デシジョンテーブルのテストケースを自動生成することができます。ちなみに上図では５件のテストケースが生成されます。
制約表の構造がデシジョンテーブルの構造に当てはまることがお分かりいただけたと思います。制約表とデシジョンテーブルの違いは、ルールが明示されているかいないかの違いです。デシジョンテーブルを見ても複雑な論理関係を持つテーブルではそこからルールを読み取ることは至難の業です。それに対して制約表では各ルールが「制約」として表現されています。
デシジョンテーブルを作成するテスト技法に、CFD法と原因結果グラフがあります。どちらもルールが表またはグラフとして表現されています。ただし、これらのテスト技法では複雑な論理関係を持つ圧縮されていないデシジョンテーブルを作成することが難しいという性質があります。
デシジョンテーブルは条件の全数組み合わせであり、その組み合わせに論理関係が存在します。この論理関係は、条件と条件間の論理関係と、条件と動作間の論理関係の２つに分類することができます。
条件と条件間の論理関係とは例えば、中学生と中学生都内在住という２つの条件がある場合、中学生＝Yesならば中学生都内在住はYesとNoがあるが、中学生＝Noならば中学生都内在住はNoのみとなるような論理関係のことです。
条件と動作間の論理関係とは例えば、年齢という条件が中学生以上と小学生以下であるとき、料金という動作が中学生以上と小学生で異なるような論理関係のことです。条件と条件間の論理関係は動作とは独立して定義することができますが、このことは条件と動作が無関係であることを意味しません。各条件は動作と何らかの論理関係を持っているからです。
デシジョンテーブルの各動作に対応して、各条件は一意に決定することができます。このことは、各動作を条件との論理関係を表す制約条件とし、その制約条件と組み合わせることが可能な条件の組み合わせを制約対象として定義した制約表を用いることでデシジョンテーブルを表現することが可能であることを意味します。
デシジョンテーブルと制約表の対応を次に示します。
制約表の記入では１つの動作に着目し、それを制約条件とします。異なるルールで同じ動作となる場合は、同じ制約条件（動作）を隣り合う制約として定義することで、１つの動作で２つ以上のルールをOR条件として定義することができます。上の図では制約２と制約３がそれに該当します。
以上のようにPictMasterでデシジョンテーブルの制約表を定義し、組み合わせるパラメータに条件の数を指定することで、デシジョンテーブルのテストケースを自動生成することができます。ちなみに上図では５件のテストケースが生成されます。
制約表の構造がデシジョンテーブルの構造に当てはまることがお分かりいただけたと思います。制約表とデシジョンテーブルの違いは、ルールが明示されているかいないかの違いです。デシジョンテーブルを見ても複雑な論理関係を持つテーブルではそこからルールを読み取ることは至難の業です。それに対して制約表では各ルールが「制約」として表現されています。
デシジョンテーブルを作成するテスト技法に、CFD法と原因結果グラフがあります。どちらもルールが表またはグラフとして表現されています。ただし、これらのテスト技法では複雑な論理関係を持つ圧縮されていないデシジョンテーブルを作成することが難しいという性質があります。
PictMaster 5.7.6J をリリースしました
PictMaster 5.7.6J をリリースしました。
今回のリリースでは、次の不具合を修正しています。
・値の並び欄の途中に改行を入れた場合、改行の直後の値を制約表で指定するとにエラーとなる問題を修正した。
PictMaster 5.7.6J は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
今回のリリースでは、次の不具合を修正しています。
・値の並び欄の途中に改行を入れた場合、改行の直後の値を制約表で指定するとにエラーとなる問題を修正した。
PictMaster 5.7.6J は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/