[書籍]ソフトウェアテスト技法ドリル -立体で捉える-

HAYST法も、デシジョンテーブルや原因結果グラフ、CFD法なども、どちらも組合せテストの一種ととらえることができますが、目的が違います。HAYST法は、関係ないだろうと思われる組合せに潜むバグを見つけるのが目的。デシジョンテーブルや、原因結果グラフ、CFD法は、関係性そのものが仕様書通りかどうかを確認するのが目的。デバッグ工学研究所の松尾谷先生はこれらを「無則」「有則」という言葉で表現しています。

有則とは、動作が定義された入力条件の組。定義されているので、テスト空間も限定されたり、閉じたりしている。これらの組合せを効率的・網羅的に洗い出す技法が、デシジョンテーブル、原因結果グラフ、CFD法といえる。

無則とは、何も影響を及ぼさない入力条件の組。数学的な用語に当てはめると「直交」と言い換えてもいい。この無則に該当するテスト空間は、広大で閉じていないため、万が一バグ(実は影響を及ぼす入力条件の組)がある場合、見つけることがなかなかしんどい。このバグを出現させる入力条件の組を限られた時間で見つけようとする技法が、直交表やペアワイズ(All-Pair)法、HAYST法である。

また、禁則というのは、動作が禁止された入力条件の組合せであり、原因結果グラフでいえば制約と重なる部分ともいえる(禁則⊂制約?)。「微則」という言葉もあるらしいが、どういう意味なのだろうか。。。

==

と、第4章については一旦ここで中断。
先日、この本の勉強会の第3回目が開催されたのだが、そこで出題された原因結果グラフの演習問題が以下の問題。

「今、食べたいラーメン」
腹が減りました。とてもラーメンが食べたいです。でも、どんなラーメンでもいいわけではありません。以下の条件を参考に、食べたいラーメンになるように原因結果グラフを作成してください。

  • 味はしょうゆか塩か味噌のいずれかが良い。普通の胃袋なので1 杯で十分です。
  • 昨日はステーキを食べたので、こってりではないほうが良い。
  • しょうゆか塩の場合は、とんこつベースが良い。
  • 味噌の場合は野菜がたっぷり入っているものが良い。
  • トッピングは絶対に付けたい。金に糸目はつけないので味玉、刻み玉ねぎ、焼き海苔の中から最低1つは付けたい。

僕が作った原因結果グラフとデシジョンテーブルはこちら(勉強会の時は「一杯」がなかったので追加)。

ramenceg

最初は、トッピングにONE制約をつけていましたが、「最低一つ」だったのでつけるならINCL制約のが適切。でもそうすると、かならず「トッピングあり」が真になってしまって、個人的には気に入らなかったので、制約を外して、トッピングがない場合も出現するようにした。(制約をつける目的は、テスト条件を減らすことであり、実際にINCL制約をつけると列が減ります。)

でもでも、本当にこれでいいのだろうか?トッピング2個の組合せで、実は嫌いなパターンがあるかもしれない。とんこつベースのしょうゆ味なら、こってりが合うのかもしれない。他にもテストしたくなる。これは、原因結果グラフが食べたいラーメンの説明文の「有則」部分を網羅しているだけで、説明文には見えてこない関係性が気になるということになるだろう。「無則」部分に隠れた定義があるように感じる。

なので、「有則」を確認する組合せとともに、ここで「無則」に関するテスト設計が必要になってくる。HAYST法をここで適用するのは、単に「無則」を組み合わせるだけではなく、隠れた因子を見つけることにもつながる。勉強会に参加された方も、ぜひ同じ問題を、今度はHAYST法で分析してほしい~。

ということで、次回はこの問題をドリル本に沿った手順でテスト設計していきたいと思います。まずは、テスト対象の因子・水準の整理をしまーす。

# んー、自分が作った直交表割付ツールが見当たらない。。。

※この記事は こちら からの転載です。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です