« どんな単体テストをしますか?その3 | トップページ | どんな単体テストをしますか?その5 »

どんな単体テストをしますか?その4

どんな単体テストをしますか?その3」の続き。

関連記事はこちら。コメント欄にも目を通すと理解が進むかも。

  • どんな単体テストをしますか?

  • どんな単体テストをしますか?その2

  • どんな単体テストをしますか?その3
  • ホワイトボックステストの視点で、daycount関数(年月日を指定して、元旦からの日数をカウントする関数)を単体テスト設計してみるのだが、テスト設計は「なるべく少ないコストで」という意識ですすめるほうがいい。ということで、今回は原因結果グラフから導いたデシジョンテーブルで、テストケースを洗い出してみる。全部やるのは後にして、まずは最初の、

    Daycount7

    この部分。この分岐に関して、原因結果グラフを作成すると、こんな感じ。
    Daycountceg1

    これをデシジョンテーブルに落とし込むのだが、まずは3つの中間ノードについてデシジョンテーブルを作成する。3つともEXC制約を考慮して、こんな感じ。
    Daycountdt1

    そして、全体のデシジョンテーブルはこんな感じで。
    Daycountdt2

    この3つのデシジョンテーブルを結合すると、テストケース数は7つ。
    Daycountdt3

    作ってみて、ブラックボックステストの視点でテストケースを洗い出したときも原因結果グラフを使っているので、似ている。違う点は、コーディングの構成を知っているので、「0」や「-1」などの特異値については考慮されない点だ。

    さて、この調子で関数全体のテストケースを作る。が、それはまた今度。MC/DCについても今度調べて記事にするか。


    |

    « どんな単体テストをしますか?その3 | トップページ | どんな単体テストをしますか?その5 »

    コメント

    あ。<と>の半角がタグとみなされて、なにがなんだかわからない文章になってしまいました。

    以下に、書き直します(前の書き込みは削除していただけると幸いです)。
    ----
    #4~#7の「1900≦year≦2100」のセルはFではなくTですね。

    そちらは単純な転記ミスなので良いのですが、本質的な話をしますと、ホワイトボックステストなので、「1900≦year≦2100」という原因ノードを追加するのはお勧めできません。

    シンプルに、「year<1900」、「year>2100」、「month<=0」、「month>=13」、「day<=0」、「day>=32」の6つを原因ノードにして、それを∨(OR)で結び「エラー判定」を結果ノードにして、year, month, dayごとにEXC制約を掛けて条件を洗い出した方が、コードと1対1対応するのでベターと思います(結果はsofttestさんのデシジョンテーブルから、ソースコードに無い条件の行を除いたものと同じになります)。

    「year<1900」、「year>2100」の両方がFの時に、「1900≦year≦2100」のデータを用意するというのが気持ち的に引っかかると思いますが、論理関係を整理することと、その後にテストデータを考えることは分離した方がよいです。

    その理由は、原因結果グラフでできたデシジョンテーブルの1列が1テストケースとは限らないからです。
    例えば、softtestさんの#1の列で、
    (year, month, day) = (1900, 1, 1)
    と、
    (year, month, day) = (2100, 12, 31)
    の2つのテストケースを実行することは良い考えです。

    英語ですみませんが、MC/DCについては、
    http://techreports.larc.nasa.gov/ltrs/PDF/2001/tm/NASA-2001-tm210876.pdf

    が参考になると思います。

    投稿: あきやま | 2007年5月20日 (日) 06:17

    >あきやまさん

    1件目のコメントは削除させていただきました。

    ご指摘ありがとうございます、書き間違えました。。小文字の「t」「f」
    とかで、きちんと埋めようと思ったのですが、途中でやめちゃいました。
    あと、「1900≦year≦2100」を含んだ場合の原因結果グラフについて言えば
    「EXC」ではなく「ONE」が正しいかも?

    また、「1900≦year≦2100」は不要というご指摘ですが、無意識的に
    「year」「month」「day」引数で分けて考えているふしがあるようです。
    なくしたもので再度作成してみます。

    もうひとつで確信が持てなかった箇所があるのですが、3つの中間ノードは
    必要だったのでしょうか。目視で考えると、中間ノードの有無は
    デシジョンテーブルの結果には影響しないように見えるのですが、
    ご指摘のあった「ホワイトボックステスト」という視点だと無駄なのかと
    思いました。

    MC/DCの資料、ありがとうございます。

    投稿: softest | 2007年5月20日 (日) 10:51

    > 「EXC」ではなく「ONE」が正しいかも?

    ONEにしてしまうと、「year<1900」と「year>2100」のどちらか必ず一つ選ばれてしまいます。
    monthもdayも同じですのでyearのエラー、monthのエラー、dayのエラーの3つがTになってしまいます。
    したがってEXCの方です(おそらく…)。

    > 3つの中間ノードは必要だったのでしょうか。

    今回のケースでは中間ノード不要です(分かりやすさのためにあっても良いですが、ソースコードに括弧がついていないので無い方がいいでしょう)。

    投稿: あきやま | 2007年5月20日 (日) 11:48

    >あきやまさん

    「本文にある9原因ノードのグラフの場合には」という意味でONE制約かな、
    と思ったのです。すいません、言葉足らずで。。。

    > ソースコードに括弧がついていないので無い方がいいでしょう

    了解ですー。今回も詳細なコメントありがとうございました!

    投稿: softest | 2007年5月20日 (日) 12:06

    いえいえ。

    「すいません」なんてことは、何も無いのですが、9原因ノードというのは、「1900≦year≦2100」等を除いた、6原因ノードのことでしょうか?

    6個全部がFのケースが出て欲しいので、6原因ノードにまとめて制約を掛ける場合にもONEだとどれかひとつがTになってしまうので、まずいと思います。

    # なお、今回のケースでは制約はつけなくても構いません。

    投稿: あきやま | 2007年5月20日 (日) 15:38

    >あきやまさん

    そうか、ONEだと6原因がすべてFにはならなくなってしまいますね。。
    やっと理解しました。

    投稿: softest | 2007年5月20日 (日) 16:12

    コメントを書く



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




    トラックバック

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

    この記事へのトラックバック一覧です: どんな単体テストをしますか?その4:

    « どんな単体テストをしますか?その3 | トップページ | どんな単体テストをしますか?その5 »