どんな単体テストをしますか？その４
「どんな単体テストをしますか？その３」の続き。
関連記事はこちら。コメント欄にも目を通すと理解が進むかも。
ホワイトボックステストの視点で、daycount関数（年月日を指定して、元旦からの日数をカウントする関数）を単体テスト設計してみるのだが、テスト設計は「なるべく少ないコストで」という意識ですすめるほうがいい。ということで、今回は原因結果グラフから導いたデシジョンテーブルで、テストケースを洗い出してみる。全部やるのは後にして、まずは最初の、
この部分。この分岐に関して、原因結果グラフを作成すると、こんな感じ。
これをデシジョンテーブルに落とし込むのだが、まずは３つの中間ノードについてデシジョンテーブルを作成する。３つともEXC制約を考慮して、こんな感じ。
そして、全体のデシジョンテーブルはこんな感じで。
この３つのデシジョンテーブルを結合すると、テストケース数は７つ。
作ってみて、ブラックボックステストの視点でテストケースを洗い出したときも原因結果グラフを使っているので、似ている。違う点は、コーディングの構成を知っているので、「0」や「-1」などの特異値については考慮されない点だ。
さて、この調子で関数全体のテストケースを作る。が、それはまた今度。MC/DCについても今度調べて記事にするか。
| 固定リンク
この記事へのコメントは終了しました。
コメント
あ。＜と＞の半角がタグとみなされて、なにがなんだかわからない文章になってしまいました。
以下に、書き直します（前の書き込みは削除していただけると幸いです）。
----
＃４～＃７の「1900≦year≦2100」のセルはＦではなくＴですね。
そちらは単純な転記ミスなので良いのですが、本質的な話をしますと、ホワイトボックステストなので、「1900≦year≦2100」という原因ノードを追加するのはお勧めできません。
シンプルに、「year＜1900」、「year＞2100」、「month＜＝0」、「month＞＝13」、「day＜＝0」、「day＞＝32」の６つを原因ノードにして、それを∨（OR）で結び「エラー判定」を結果ノードにして、year, month, dayごとにEXC制約を掛けて条件を洗い出した方が、コードと１対１対応するのでベターと思います（結果はsofttestさんのデシジョンテーブルから、ソースコードに無い条件の行を除いたものと同じになります）。
「year＜1900」、「year＞2100」の両方がＦの時に、「1900≦year≦2100」のデータを用意するというのが気持ち的に引っかかると思いますが、論理関係を整理することと、その後にテストデータを考えることは分離した方がよいです。
その理由は、原因結果グラフでできたデシジョンテーブルの１列が１テストケースとは限らないからです。
例えば、softtestさんの＃１の列で、
(year, month, day) = (1900, 1, 1)
と、
(year, month, day) = (2100, 12, 31)
の２つのテストケースを実行することは良い考えです。
英語ですみませんが、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のエラーの３つがＴになってしまいます。
したがってEXCの方です（おそらく…）。
> 3つの中間ノードは必要だったのでしょうか。
今回のケースでは中間ノード不要です（分かりやすさのためにあっても良いですが、ソースコードに括弧がついていないので無い方がいいでしょう）。
投稿: あきやま | 2007年5月20日 (日) 11:48
＞あきやまさん
「本文にある9原因ノードのグラフの場合には」という意味でONE制約かな、
と思ったのです。すいません、言葉足らずで。。。
> ソースコードに括弧がついていないので無い方がいいでしょう
了解ですー。今回も詳細なコメントありがとうございました！
投稿: softest | 2007年5月20日 (日) 12:06
いえいえ。
「すいません」なんてことは、何も無いのですが、９原因ノードというのは、「1900≦year≦2100」等を除いた、６原因ノードのことでしょうか？
６個全部がＦのケースが出て欲しいので、６原因ノードにまとめて制約を掛ける場合にもONEだとどれかひとつがＴになってしまうので、まずいと思います。
# なお、今回のケースでは制約はつけなくても構いません。
投稿: あきやま | 2007年5月20日 (日) 15:38
＞あきやまさん
そうか、ONEだと6原因がすべてFにはならなくなってしまいますね。。
やっと理解しました。
投稿: softest | 2007年5月20日 (日) 16:12