« 2010年4月 | トップページ | 2010年6月 »

原因結果グラフの「制約のテスト」 ONE制約

  • 原因結果グラフの「制約のテスト」

  • 原因結果グラフの「制約のテスト」 その2

  • の続きです。

    ==

    「制約のテスト」を考える上で、どんなバグを検出できるか。まずはONE制約。4つのノード「A」「B」「C」「D」にONE制約がかかっている状態を例にしてみます。

    One_ceg

    4つのノードの必ず一つが真になるので、入力条件空間を平面で表現すると、以下のように4つの領域が隙間なく、境界線によって分割された状態が考えられます。

    One_ok

    任意の入力条件は、4つの領域「A」「B」「C」「D」のいずれかに属することがわかる。これが ONE=(A B C D) が成立する状態です。では、成立しない状態とはどういう状態でしょう?

    1. 領域「A」が領域「B」と一部分重なる場合
    2. One_a_over_b

      領域「A」と領域「B」を分割する境界がバグによって領域「B」側にシフトした場合、ONE=(A B C D)は成立しない。同様に領域「C」側にシフトした場合、領域「D」側にシフトした場合、を考えると以下の3通りの条件の組合せが考えられる。シフトする場合と同様、飛び地で領域が重なりあう場合も同じでしょう。

      One_a_over_b_dt

      例えば、不等号「≦」「<」の誤り、条件となる定数誤りなどがこのバグに該当する。また、何かのイベントがただ一つだけ生じるはずが、同時に2つのイベントが生じてしまうケースも。

      そして、これは他の領域「B」「C」「D」についてもいえるので、同様に3つの条件の組合せが作れて、合計12通りが全部。

      One_over_dt

      同じ条件の組合せが2つずつあるので、半分の6通りにまとまります。

    3. 領域「A」の一部が欠落し、間隙が生じる場合
    4. 領域「A」と領域「C」を分割する境界がバグによって領域「A」側にシフトした場合、領域間に間隙ができてしまい、ONE=(A B C D)は成立しない。

      One_a_gap

      これは、本来はAが真となるべき条件の組合せでAが偽となるパターンで、以下の通り。

      One_a_gap_dt

      先ほど同様、欠損は領域「B」「C」「D」にもありえるので、以下の3通りも考えられるが、結局は一つに集約。

      One_gap_dt

      例えば、不等号に「=」をつけ忘れ、見逃したケースが存在するといった誤りがこのバグに該当する。状態を表すノードであれば、初期状態が未定義・不定値だったりする誤りもこのバグかな。

    ==

    このことから、6+1=7通りの組合せがありえないことを示せば、ONE=(A B C D) が成立することの必要条件となるだろう。

    One_na_dt


    でも、実際にありえないことを確認するのって、難しいよなあ。。。

    | | コメント (0) | トラックバック (0)

    原因結果グラフの「制約のテスト」 その2

    原因結果グラフの「制約のテスト」の続きです。

    ==

    制約を含んだ原因結果グラフをデシジョンテーブル変換する際、制約の成立性もあわせてデシジョンテーブルに変換してみようという試みです。原因結果グラフのメリットのひとつである「テスト条件を削減できる」という効果は薄れてしまいますが、前提条件である「制約のテスト」を網羅しやすくなるので、やる価値はあると思います。

    例題として以下のような原因結果グラフを使ってみます。

    Ceg

    1. 制約全体で考える
    2. この原因結果グラフでは2個の制約があります。


      REQ=(B A)     i.e. Bが真であるためにはAが真であることが必要
      ONE=(B C D)    i.e. BとCとDはいずれかひとつが真でなければならない

      この原因結果グラフにおいて「制約が不成立」というのは「REQ制約が不成立」あるいは「ONE制約が不成立」を意味しますので、これはすなわち、

      Ceg_2

      と表現できます。得られるデシジョンテーブルは以下の通り。

      Dt

      言い換えれば、「REQ制約が不成立」を確認するテスト条件ではそれ以外の制約(ここでは「ONE制約」)は成立すると仮定する必要があります。でなければ「制約が不成立」という結果にどの原因が影響したかが不明確になるからです。逆も同様。3列目については「制約が成立」という結果ですので、はじめてテスト対象の原因結果グラフを意識することになります。

    3. REQ制約について
    4. まず「REQ制約が成立するか否か」の原因結果グラフとデシジョンテーブルを作成します。

      Reqceg
      Reqdt

      明記していませんが、ONE制約は成立していることが前提です。「REQ制約が不成立」を確認したいので、#2を使います。

    5. ONE制約について
    6. 次に「ONE制約が成立するか否か」の原因結果グラフとデシジョンテーブルを作成します。「ONE制約が不成立」を確認したいので、#2#3#4#6を使います。

      Oneceg
      Onedt

    7. テスト対象の原因結果グラフについて
    8. 最後にすべての制約が成立することを前提にして、テスト対象の原因結果グラフとデシジョンテーブルを作成します。

      Dt_2

    9. 最終的なデシジョンテーブルについて
    10. 2~4のデシジョンテーブルを結合するとこのような8個のテスト条件が確認できます。

      Dt2

      テスト対象の原因結果グラフの3個と合わせて5個の「制約不成立」の確認をすることになります。

    もう少し検証したらツールに反映します。

    | | コメント (0) | トラックバック (0)

    « 2010年4月 | トップページ | 2010年6月 »