CFD法の流れ図の見つけ方

CFD法の補習会を企画中。

==

drawCFDではデシジョンテーブルを自動生成するわけではなく、作成者が「流れ」を描くことでデシジョンテーブルの1列(1ルール)が追加されていく。秋山浩一さんに教わった流れ図の描き方を下記の例題で試してみる。

1.横浜ベイクォーター
1店舗3,000円(税込)以上のお買上げで1時間無料 ※駐車券を売場でご提示ください。 2店舗目以降も各店舗3,000円(税込)以上のお買上げで 1時間の駐車サービス券をお渡しします。

2.そごう横浜店

2,000円(税込)以上のお買上げで1時間30分無料
※駐車券を売場でご提示ください。

Cfd3

# 前回の記事とはちょっとだけデシジョンテーブルの順番が違ったり、有効・無効が違いますが、描き方の例としては問題ないかと。



  1. 結果は何か

  2. 今回は駐車料金、特に「駐車料金がどれだけ無料になるか」を確認することが目的。1時間無料、1時間半無料、2時間無料、・・・、無料でないといった結果が考えられる。2時間無料以降は、N時間無料とした(Nは2以上の正数、以後も同じとする)。ということで、「N時間無料」「1時間半無料」「1時間無料」「無料でない」の4つの結果をお得な順序で上から配置した。


  3. 有効結果と無効結果を決める

  4. 4つ結果すべて有効結果ともみなせる(無料でない場合は、次にいくらになるかの処理に進むため)が、今回は「無料でない」は無効結果とした。drawCFDでは右クリックで有効結果・無効結果を切り替えられる。


  5. 横浜ベイクォーターでの買い物に関する同値図を描く

  6. 仕様ではまず、「横浜ベイクォーター」での買い物金額について言及しているので、この条件を(完全)同値分割する。

    この入力条件が引き起こす結果としては、「1時間無料券がN枚」「1時間無料券が1枚」「無料でない」の3つ。ということは同値分割も3つになりそうだ。ということで「N店舗で3000円以上買い物」「1店舗で3000円以上買い物」「どの店舗でも3000円未満の買い物」となる。文言は少し変えました。


  7. 横浜そごうでの買い物に関する同値図を描く

  8. 次に判定するのは、「横浜そごう」での買い物金額について。ここでの買い物が影響を及ぼす結果としては、「1時間半無料」「無料でない」の2種類。ということで、「2000円以上の買い物」「2000円未満の買い物」の(完全)同値分割を考えた。同じく、文言は少し変えました。


  9. 有効系同値クラス、無効系同値クラスを決める

  10. どれも有効系同値クラスとした。


  11. 流れを描く

  12. 流れ図は、結果から探していく。上に配置された結果からそこにつながる流れを以下の手順で見つけていった。


    N時間無料」の結果になるのは?


    仕様から、横浜ベイクォーターでN店舗で3000円以上の買い物をした場合、とわかる。横浜そごうでの買い物は関係しないので、
    IF ベイクォーター is N店舗3000円以上
     THEN N時間無料



    N時間無料」の結果になるのは?


    他の条件はない。ということで「N時間無料」に結ばれる流れはこれでおしまい。


    「1時間半無料」の結果になるのは?


    仕様から、横浜そごうで2000円以上の買い物をした場合、とわかる。では、そのひとつ前の「ベイクォーター」同値図のどこから結ばれるか?
    「N店舗3000円以上」だと、結果が「N時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。ということで、
    IF ベイクォーター is 1店舗3000円以上 AND 横浜そごう is 2000円以上
     THEN 1時間半無料



    1時間半無料」の結果になるのは?


    仕様から、横浜そごうで2000円以上の買い物をした場合、とわかる。では、そのひとつ前の「ベイクォーター」同値図のどこから結ばれるか?
    「N店舗3000円以上」だと、結果が「N時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。でもさっき通った。
    「3000円を超えない」だと、ありえる。ということで、
    IF ベイクォーター is 3000円を超えない AND 横浜そごう is 2000円以上
     THEN 1時間半無料



    1時間半無料」の結果になるのは?


    他の条件はない。ということで「1時間半無料」に結ばれる流れはこれでおしまい。


    「1時間無料」の結果になるのは?


    横浜そごうで2000円以上の買い物をした場合、1時間無料ではなくなるので、「2000円を超えない」を通ることがわかる。では、そのひとつ前の「横浜ベイクォーター」同値図のどこから結ばれるのか?
    「N店舗3000円以上」だと、結果がN時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。ということで、
    IF ベイクォーター is 1店舗3000円以上 AND 横浜そごう is 2000円を超えない
     THEN 1時間無料



    1時間無料」の結果になるのは?


    横浜そごうで2000円以上の買い物をした場合、1時間無料ではなくなるので、「2000円を超えない」を通ることがわかる。では、そのひとつ前の「横浜ベイクォーター」同値図のどこから結ばれるのか?
    「N店舗3000円以上」だと、結果がN時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。でもさっき通った。
    「3000円を超えない」だと、ありえない。ということで、他の条件はない。


    無料でない」の結果になるのは?


    横浜そごうで2000円以上の買い物をした場合、ありえないので、「2000円を超えない」を通ることがわかる。では、そのひとつ前の「横浜ベイクォーター」同値図のどこから結ばれるのか?
    「N店舗3000円以上」だと、結果がN時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、結果が1時間無料」となるので、ありえない
    「3000円を超えない」だと、ありえる。ということで、
    IF ベイクォーター is 3000円を超えない AND 横浜そごう is 2000円を超えない
     THEN 無料でない



    無料でない」の結果になるのは?


    他に条件はない。ということで終了。




以上のような考え方で作成しました。最後に確かめ作業があるのだろうが、いまいちわからなかった。。。

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

CFD法で同値図の順序を変えてみた

頭痛い。

==

1.横浜ベイクォーター 1店舗3,000円(税込)以上のお買上げで1時間無料 ※駐車券を売場でご提示ください。 2店舗目以降も各店舗3,000円(税込)以上のお買上げで 1時間の駐車サービス券をお渡しします。

2.そごう横浜店
2,000円(税込)以上のお買上げで1時間30分無料
※駐車券を売場でご提示ください。

この駐車場の無料特典をCFD法で表現してみた。「横浜ベイクォーターの買い物金額」と「横浜そごうの買い物金額」の二つの同値図があるので、順番を入れ替えて2個作ってみた。


Cfd1

Cfd2

1個目のほうがデシジョンテーブルが小さい。

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

CFD法の同値図の順序を考える

CFD法は、処理順序を AND とみなして、同値図を横に並べる。テストエンジニアではなく、設計も担うエンジニアの場合は、CFDを描きながらよりよいプログラム設計を作れる可能性がある。具体的な例を使って、処理順序がデシジョンテーブルにどんな形で影響を及ぼすかを考えてみたいと思う。

横浜ベイクォーターの駐車場料金の無料サービス
横浜ベイクォーターと隣接する横浜そごうで買い物をする無料になるシステム。

1.横浜ベイクォーター 1店舗3,000円(税込)以上のお買上げで1時間無料 ※駐車券を売場でご提示ください。 2店舗目以降も各店舗3,000円(税込)以上のお買上げで 1時間の駐車サービス券をお渡しします。

2.そごう横浜店
2,000円(税込)以上のお買上げで1時間30分無料
※駐車券を売場でご提示ください。

続きはまた今度。

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

JaSST'11 Tokyo にて「CEGTest」を使って発表してきました。

マイコミジャーナルに記事として取り上げていただきました。

【レポート】「CEGTest」開発者が語る、原因結果グラフ技法の応用テクニック - JaSST


1月25-26日、東京都目黒区の目黒雅叙園にてソフトウェアテストをテーマにした技術カンファレンス「JaSST(Japan Symposium on Software Test) 2011」が開催された。ここでは、25日の午後に行われたニフティ 加瀬正樹 ...... Read more

この場を借りて、発想やアドバイスをいただいた秋山さん、にしさんに御礼したいと思います。

原因結果グラフは、基本的にはツリー構造になっていて、その枝分かれしている中間ノードに着目すると、分割(partitioning)やズームアウトができる、というのが今回の論文の発想です。規模に応じてテスト対象を分割する手法はにしさんのスライドなどによく登場しますし、秋山さんのソフトウェアテストHAYST法入門ではズームインとともにズームアウトが紹介されています。今回、明確な定義を与えて、原因結果グラフを分割し、どんな効果があるかなどを考察しました。考え方自体は、原因結果グラフに特化したものではないので、もう少し考えてみたい。

分割可能点の多い少ないでグラフの複雑度が数値化できるかなあ。


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

[書籍]ソフトウェアテスト技法ドリル -面で逃さない-

テスト条件がひとつの場合から2個以上になると、テスト設計がぐんと難しくなる。難しくなるというのは、全体のテスト条件の組合せの中から優先的にテストすべきパターンを見つける技法を知らないと、効率が悪くなるということ。第3章で紹介するのは「ドメイン分析テスト」「デシジョンテーブル」「原因結果グラフ」「CFD法」の4つのテスト技法。

実は、このサイトで公開している原因結果グラフの支援ツール「CEGTest(セグテスト)」について、詳しく紹介していただいてます。この場を借りて御礼申し上げます!ありがとうございます!現時点でCEGTestの使い方について最も詳しく書かれているドキュメントだと思います^^;また、CFD法についても書籍として解説しているのはドリル本だけじゃないでしょうか。デシジョンテーブル自体も同じことを言えるのですが、CFD法はテストエンジニアだけでなく実装に携わるエンジニアにも知っておいて損はない技法といえるでしょう。

原因結果グラフのデシジョンテーブル変換については、JaSST'07 Tokyoの「三賢者」資料が一番詳しいです。


==

# 2010/10/10 修正
CFD法については「ソフトウェア開発・検証技法」にも説明があるようです。また、ソフトウェア・テストPRESSにも特集がありましたね^^;すっかり抜けていました。

| | コメント (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)

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

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

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

というものがある。

例えば、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 (回)

となりそうだ。


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

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

ceg2dtツール - 65%くらい完成

今日は深夜メンテナンス。少し休憩。

==

原因結果グラフをデシジョンテーブルにするツールを勉強のために作成しているが、6割くらいできた。未実装なのは、

  • 制約条件(REQとMASK)

  • Tとt、Fとfの違い

  • 最適化
  • 何とかなりそうな気がしているが、コードがまったくエレガントではないし、長い。。。。

    1. サンプル1:チケットの学割
    2. デシジョンテーブル(2) - たまゆら雑記の例を使わせていただきました。 Ceg2

      この例だと、なんかあってそうな感じ。でもよくみると、偏ってる。#5は「埼玉に在住でない」「学生証を提示していない」のほうがベターか。

    3. サンプル2:ログイン画面

    4. 原因結果グラフ - 論理点カバレッジの解剖の例を使ってます。
      Ceg3

      これは、マス目の埋まっていないところの決め方が偏っているため、テストケース数が多い。最適化の課題か。

    5. サンプル3:結婚

    6. 結婚できるかどうかの原因結果グラフ。
      Ceg4

      一見うまくいってそうだが、「16歳以上」「18歳以上」の組み合わせが矛盾。制約条件が中途半端だから。

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

    制約条件からデシジョンテーブルを埋めていく

    今日はお風呂を掃除して、近所のスタバのドライブスルーでラテ買ってきて、和室でお勉強。amazonから本も届いたし読むかな。

    ==

    原因結果グラフを元にしてデシジョンテーブルを作成していく手順を自動化して、理解を深めようとしてるのだが、以下の例でいろいろ考え中。
    Ceg2
    Ceg

  • 制約条件(男性と女性)

  • まずは、3つのテストケースを列に組み込んでみた。これは論理接点1~3について、行列を転置したもの。ここで、制約条件(「男性」「女性」はONE制約)から、空欄となっている原因ノード「女性」は自動的に決定される。

  • 制約条件(年齢)

  • 原因ノード「18歳以上」がTrueである場合は、もうひとつの原因ノード「16歳以上」も自動的に決定される(REQ制約)。んー、年齢は「15歳以下」「16歳か17歳」「18歳以上」にしたほうがよかったかな。


    たぶん、こういうようにTrue/Falseを決定しつつ、カバレッジ率をあげて、未確定のマス目も埋めていく感じですすめていくかな。

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

    原因結果グラフ→デシジョンテーブル(途中までツール化)

    JacaScriptが初心者向けなのかどうかは別として、手ごろだったので原因結果グラフからデシジョンテーブルを作成するツールをJavaScriptでためしに作り中。エクセルVBAとかのが使えるんだろうな。

    原因結果グラフ→デシジョンテーブル(v0.2)
    # Opera9.26で確認中。まだブラウザによっては動作しないかも。。。

    以下、TODOとして。

  • ブラウザ違いでのチェック

  • ノードやリンクの入力方法を考える

  • 制約条件の実装

  • Don't Care状態のマス目対応の実装

  • 検算の実装

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