CFD法のコツは同値分割にある #GIHOZ
ベリサーブ社のテスト勉強会で、CFD法のコツは同値分割にあると分かったのでメモ。
後半は適当な妄想なので後で消すかもしれない。
【参考】
【明日から使えるテスト技法勉強会】 #4 ~CFD法って、なに?~ - connpass
CEGTest - 原因結果グラフからテスト条件を作成するツール
CEGTestによる原因結果グラフの書き方: プログラマの思索
CFD法は原因結果グラフの別の表記法。
秋山さんの本「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 | 秋山 浩一」にも紹介されていた。
実際はなかなか使いにくい。
テストケースやロジックそのものをANDやOR条件でつなげて原因結果グラフで書くこと自体が難しい。
そして、原因結果グラフで書いたとしても、何が嬉しいのか、分からない感覚があった。
今日の勉強会で良かった点は、テスト仕様を提示して、そこからCFD法で実際に図を描いて、そこからデシジョンテーブル、最後にテストケースを作る、という一連の流れが分かったこと。
実際は、ベリサーブ社が提供するクラウドサービス上でやっていただけ。
でも、GUIが揃っているのは便利。
CFD法のコツは、テスト仕様を同値分割の集合体と考えて、同値分割の集合でグルーピングして、同値分割のグループを原因→結果の流れで矢印を結んで、ロジックを状態遷移図のように一連の流れで示すこと。
同値分割はテスト技法の初歩で出てくる考え方だが、まさに同値関係でテスト仕様をグルーピングするのがCFD法の起点になる。
盲点になる点は、仕様を同値分割でグルーピングした時、補集合を忘れがちなことだ。
ベリサーブ社のツールでは補集合は「その他」として必ず表示されるので、漏れがなくなる。
大体のケースは、システムエラーや例外処理、異常処理のケースが多いだろう。
そういうケースを忘れないように図で示せるのは良い。
すると、CFD法は状態遷移図で表せないか?と思った。
CFD法で描いた図を見ると、同値分割の各グループを状態遷移図の「状態」と捉えることができる。
状態遷移図では、状態の入れ子構造も表現できるから、補集合も内部状態の一つとして表現できる。
そうすれば、状態遷移図を描ければ状態遷移表を自動生成するツールはastahやEnterpriseArchitectなどたくさんあるから、そこからデシジョンテーブルやテストケースを生成することができる。
つまり、状態遷移図に落とし込めれば、状態遷移表を通じてテストケースを自動生成するやり方はツールで既に実現されているし、状態遷移図は組込みソフトウェア開発者であれば見慣れた図なので、理解しやすいからだ。
ただし、このアイデアも、Q&Aで聞いた所、状態遷移図はトリガーやイベントも含む技法なので、CFD法のように原因と結果を結ぶ図とはそもそも観点が異なります、という回答があった。
確かに、全く違うのはその通り。
実際、下記の例題を考えてみよう。
(引用開始)
例題
ベリサーブショッピングモールでは、買い物金額やシネマ鑑賞に応じて、駐車場の料金を割引きするサービスを提供しています
■<駐車場割引サービスの仕様>
パターン 結果
お買い物金額2,000円以上 1時間無料
お買い物金額5,000円以上 2時間無料
お買い物金額10,000円以上 3時間無料※平日限定
シネマ鑑賞 3時間無料※鑑賞本数・上映時間に関わらず上限3時間
割引サービスの判定システムの実装を確認したところ、条件判定はシネマ鑑賞、お買い物金額、曜日の順に実施していました。
このシステムの判定結果が正しいことを確認するためのテストケースを作成してください。
(引用終了)
シネマ鑑賞、お買い物金額、曜日の3項目は、それぞれ同値分割でグルーピングできる。
具体的には、シネマ鑑賞の有無、お買い物金額は金額ごとに4パターン、曜日は平日と平日以外の2パターンに同値分割される。
そして、シネマ鑑賞、お買い物金額、曜日の3項目に対し、同値分割のグループの組み合わせを考えて、それらを原因→結果でつなげると、状態遷移図のような図でCFD法を示すことができる。
同値分割の各グループを状態と捉えて、状態遷移図で表現することは可能だろうと思った。
astahであれば、状態遷移図を描ければ状態遷移表は一発で自動生成できるから、そこからデシジョンテーブルやテストケースを作成すればいい。
CFD法の特徴の一つに、ループ構造がない点だ。
理由は簡単で、原因→結果の1方向しかないからだ。
この特徴を活かせば、状態遷移図や状態遷移表は非常にシンプルに描くことができるはず。
しかし、状態遷移表では前状態x後状態の表をイベントで表すから、CFD法には使えない。
状態遷移パス表なら、状態xイベントの組み合わせでパスをすべて生成するので、テスト仕様が3項目なら、入力3個と出力1個で合計4個のパターンを見なして、状態xイベントを4パターン組み合わせたもので表すことができるはず。
改めて理解できた点は、テスト仕様は同値分割で最小限のテストデータに整理できること。
そして、同値分割の組み合わせを原因と結果の組み合わせで表現する時に、原因と結果を状態に割り当てれば、状態遷移図らしきもので表現できると思う。
ちょっとこのアイデアを試してみようと思う。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
コメント