« WACATE2009 冬 にいってきました | トップページ | [JaSST'10Tokyo]原因結果グラフ支援ツールCEGTest »

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

テスト設計で使う原因結果グラフでは、適用するにあたっては前提条件があり、そのひとつとして

 制約のテストは別に実施する

というものがある。

例えば、WEBアンケートフォームで性別を選択するラジオボタンが「男」「女」「登録しない」という3つの選択肢だったとすると、性別に関するノード「男」「女」「登録しない」はONE制約になる。
原因結果グラフを使えば、論理関係を網羅するようなテスト条件は見つけられるが、本当にONE制約が機能しているかどうかは確認できない。もしかしたら、いづれの選択肢を選ばなくてもアンケートに回答できてしまうかもしれない。

では具体的に「制約のテスト」ってどんなテストをするのか?これについても原因結果グラフを使うと面白い結果が出てくる。


ONE制約
A,B,Cという3つのノードに対してONE制約がついているとすると、ベン図では以下のような表現できる。ただひとつだけがTになる領域が3か所ある。

One

これを原因結果グラフで表現してみる。

Onetest
One_dt

結果ノードにあたる「ONE制約が成立」がTの場合を、「正常系」、Fの場合を「異常系」とするならば、一般にN個のノードにONE制約がついた場合の「制約のテスト」は

 正常系: N (回)
 異常系: N * ( N - 1 ) / 2 + 1 (回)

となりそうだ。


EXCL制約
A,B,Cという3つのノードに対してEXCL制約がついているとすると、ベン図では以下のような表現できる。ONE制約の他に全てがFになる領域が増えたもの。

Excl
Excltest
Excl_dt

一般にN個のノードにEXCL制約がついた場合の「制約のテスト」は

 正常系: N + 1 (回)
 異常系: N * ( N - 1 ) / 2 (回)

となりそうだ。


INCL制約
A,B,Cという3つのノードに対してINCL制約がついているとすると、ベン図では以下のような表現できる。全てがFになる領域以外がありえる。

Incl
Incltest
Incl_dt

一般にN個のノードにINCL制約がついた場合の「制約のテスト」は

 正常系: N (回)
 異常系: 1 (回)

となりそうだ。


REQ制約
A,B,Cという3つのノードに対してREQ制約がついているとすると、ベン図では以下のような表現できる。AがFになる領域と、A,B,C全てがTになる領域の2か所。

Req
Reqtest
Req_dt

一般にN個のノードにREQ制約がついた場合の「制約のテスト」は

 正常系: 2 (回)
 異常系: N - 1 (回)

となりそうだ。


MASK制約
MASK制約は厳密にはベン図表現ができないが、REQと同じ要領で原因結果グラフを作成する。

Masktest
Mask_dt

一般にN個のノードにMASK制約がついた場合の「制約のテスト」は

 正常系: 2 (回)
 異常系: N - 1 (回)

となりそうだ。


このデシジョンテーブルを使って、制約に関する未検証条件がないか確かめるとよいかな。

|

« WACATE2009 冬 にいってきました | トップページ | [JaSST'10Tokyo]原因結果グラフ支援ツールCEGTest »

コメント

こんにちは。

とても分かりやすい(網羅性が確認しやすい)説明だと思いました。

ところで、MASKのところですが、

正常系: (2^N)/2(回)
異常系: (2^N)/2(回)

なのではないでしょうか??
softestさんのツールへのインポートデータは、
----------------------------

8,8,0,8,0,
A
B
C
M1
M2
M3
M4
MASK制約が成立


AND,1,1,1,0,0,0,0,,0,1,1,0,0,0,0,,0,0,0,1,0,0,0,,
AND,1,1,1,0,0,0,0,,0,1,0,0,0,0,0,,0,0,0,0,1,0,0,,
AND,1,1,1,0,0,0,0,,0,0,1,0,0,0,0,,0,0,0,0,0,1,0,,
AND,1,1,1,0,0,0,0,,0,0,0,0,0,0,0,,0,0,0,0,0,0,1,,
OR,0,0,0,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
43,51,7,17,
148,52,7,17,
261,57,7,17,
65,175,14,17,
149,170,14,17,
217,169,14,17,
295,170,14,17,
177,339,98,17,

----------------------------

です。

投稿: あきやま | 2010年1月12日 (火) 10:44

>あきやまさん

コメントありがとうございます。
いただいたデータですが、うまくインポートできなかったです^^;
→これを見る限りCEGTestのバグですねぇ・・・

さて、MASKですがあきやまさんのグラフは

(1) M1=A and ¬B and ¬C
(2) M2=A and ¬B and C
(3) M3=A and B and ¬C
(4) M4=A and B and C
(5) MASK制約が成立=M1 or M2 or M3 or M4

でしょうか?

投稿: softest | 2010年1月12日 (火) 14:33

インポート上手くいきませんでしたか。

どうも、途中の改行の数あたりを変えると上手くいったりいかなかったりするようです。

私が書いたグラフは、その通りです。
# 伝わっているので、やはりエクスポート・インポート機能は有益ですね!(^_^)

ちなみに、私のツールの表記では、

----------------------
[Cause Node]
A=
B=
C=

[Middle Node]
M1=(A AND NOT B AND NOT C),
M2=(A AND NOT B AND C),
M3=(A AND B AND NOT C),
M4=(A AND B AND C),

[Result Node]
MASK制約が成立=(M1 OR M2 OR M3 OR M4),

[Constraint]
----------------------

です。

MASK制約は、論理関係と組み合わせて制約になったりならなかったりするので、「正常系+異常系=全テスト数=2^N」になると思います。

それで、何を正常系、異常系と見るかは定義の問題なのかもしれません。

投稿: あきやま | 2010年1月12日 (火) 15:09

>あきやまさん

その表記についてもインポート対応しますねー。
ちなみにノード名に0x20は使えます?

>MASK制約は、論理関係と組み合わせて制約になったり
>ならなかったりするので、「正常系+異常系=全テスト数=2^N」
>になると思います。

うーむ。ということは「全数テストすべき」ってことですかねえ。
REQとMASKは表裏なのでうまく表せないかと。
ここでのテスト条件の分類は「正常系」「異常系」よりは
「成立系」「不成立系」の名称のほうがよいかな。

投稿: softest | 2010年1月12日 (火) 22:33

>softestさん

> その表記についてもインポート対応しますねー。

ありがとうございます。

> ちなみにノード名に0x20は使えます?

制約をノード名をスペースで区切って書く方式(ONE A B C)なので、ノード名には使えません。


> うーむ。ということは「全数テストすべき」ってことですかねえ。

MASK制約に絡む部分の確認は、その後の論理関係で(つまりは原因結果グラフの方法で)省くことはできても、MASK制約だけで少なくすることはできないと思うのですが。

> REQとMASKは表裏なのでうまく表せないかと。

完璧な表裏のMASKとそうでないMASKがありますからね。私は、完璧な表裏のMASKはREQとNOTを組み合わせて使えばいいので、そうでないMASKで実装しています。

> ここでのテスト条件の分類は「正常系」「異常系」よりは
> 「成立系」「不成立系」の名称のほうがよいかな。

私もどちらを正常系と呼ぼうか迷いました。(^_^;)

投稿: あきやま | 2010年1月13日 (水) 06:22

>あきやまさん

MASKは他の制約と違って、2^n個あるパターンの中から「N/A」を省く
わけじゃなくてT/FをMに上書きするので2^n個は変わらない、ということですよね。

投稿: softest | 2010年1月13日 (水) 09:29

> T/FをMに上書きするので2^n個は変わらない、ということですよね。

はい。そういうことです。
取り得る論理展開式がMASK制約によって減るというわけではないということです。

>> その表記についてもインポート対応しますねー。
> ありがとうございます。

と書きましたが、ノードの位置についての情報は、私の表記の中にはないので難しいかもしれません。

(位置情報は、データファイルの中にXML形式で保存しています)

投稿: あきやま | 2010年1月13日 (水) 09:52

>あきやまさん

>ノードの位置についての情報は、私の表記の中にはないので難しいかもしれません。

複雑な原因結果グラフだと見づらいかもしれないですが、深さを計算して
整列させることになると思います。

投稿: softest | 2010年1月13日 (水) 12:03

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/155415/32898158

この記事へのトラックバック一覧です: 原因結果グラフの「制約のテスト」:

« WACATE2009 冬 にいってきました | トップページ | [JaSST'10Tokyo]原因結果グラフ支援ツールCEGTest »