試しに、直交表に割りつけてみた。
「今、食べたいラーメン」
腹が減りました。とてもラーメンが食べたいです。でも、どんなラーメンでもいいわけではありません。以下の条件を参考に、食べたいラーメンになるように原因結果グラフを作成してください。
- 味はしょうゆか塩か味噌のいずれかが良い。普通の胃袋なので1 杯で十分です。
- 昨日はステーキを食べたので、こってりではないほうが良い。
- しょうゆか塩の場合は、とんこつベースが良い。
- 味噌の場合は野菜がたっぷり入っているものが良い。
- トッピングは絶対に付けたい。金に糸目はつけないので味玉、刻み玉ねぎ、焼き海苔の中から最低１つは付けたい。
16番目の組合せだけが説明文通りの「食べたいラーメン」だけど、他の15通りで「食べたいラーメン」があるかもしれないー。
※この記事は こちら からの転載です。
HAYST法も、デシジョンテーブルや原因結果グラフ、CFD法なども、どちらも組合せテストの一種ととらえることができますが、目的が違います。HAYST法は、関係ないだろうと思われる組合せに潜むバグを見つけるのが目的。デシジョンテーブルや、原因結果グラフ、CFD法は、関係性そのものが仕様書通りかどうかを確認するのが目的。デバッグ工学研究所の松尾谷先生はこれらを「無則」「有則」という言葉で表現しています。
有則とは、動作が定義された入力条件の組。定義されているので、テスト空間も限定されたり、閉じたりしている。これらの組合せを効率的・網羅的に洗い出す技法が、デシジョンテーブル、原因結果グラフ、CFD法といえる。
無則とは、何も影響を及ぼさない入力条件の組。数学的な用語に当てはめると「直交」と言い換えてもいい。この無則に該当するテスト空間は、広大で閉じていないため、万が一バグ（実は影響を及ぼす入力条件の組）がある場合、見つけることがなかなかしんどい。このバグを出現させる入力条件の組を限られた時間で見つけようとする技法が、直交表やペアワイズ（All-Pair）法、HAYST法である。
また、禁則というのは、動作が禁止された入力条件の組合せであり、原因結果グラフでいえば制約と重なる部分ともいえる（禁則⊂制約？）。「微則」という言葉もあるらしいが、どういう意味なのだろうか。。。
==
と、第4章については一旦ここで中断。
先日、この本の勉強会の第3回目が開催されたのだが、そこで出題された原因結果グラフの演習問題が以下の問題。
「今、食べたいラーメン」
腹が減りました。とてもラーメンが食べたいです。でも、どんなラーメンでもいいわけではありません。以下の条件を参考に、食べたいラーメンになるように原因結果グラフを作成してください。
- 味はしょうゆか塩か味噌のいずれかが良い。普通の胃袋なので1 杯で十分です。
- 昨日はステーキを食べたので、こってりではないほうが良い。
- しょうゆか塩の場合は、とんこつベースが良い。
- 味噌の場合は野菜がたっぷり入っているものが良い。
- トッピングは絶対に付けたい。金に糸目はつけないので味玉、刻み玉ねぎ、焼き海苔の中から最低１つは付けたい。
僕が作った原因結果グラフとデシジョンテーブルはこちら（勉強会の時は「一杯」がなかったので追加）。
最初は、トッピングにONE制約をつけていましたが、「最低一つ」だったのでつけるならINCL制約のが適切。でもそうすると、かならず「トッピングあり」が真になってしまって、個人的には気に入らなかったので、制約を外して、トッピングがない場合も出現するようにした。（制約をつける目的は、テスト条件を減らすことであり、実際にINCL制約をつけると列が減ります。）
でもでも、本当にこれでいいのだろうか？トッピング2個の組合せで、実は嫌いなパターンがあるかもしれない。とんこつベースのしょうゆ味なら、こってりが合うのかもしれない。他にもテストしたくなる。これは、原因結果グラフが食べたいラーメンの説明文の「有則」部分を網羅しているだけで、説明文には見えてこない関係性が気になるということになるだろう。「無則」部分に隠れた定義があるように感じる。
なので、「有則」を確認する組合せとともに、ここで「無則」に関するテスト設計が必要になってくる。HAYST法をここで適用するのは、単に「無則」を組み合わせるだけではなく、隠れた因子を見つけることにもつながる。勉強会に参加された方も、ぜひ同じ問題を、今度はHAYST法で分析してほしい～。
ということで、次回はこの問題をドリル本に沿った手順でテスト設計していきたいと思います。まずは、テスト対象の因子・水準の整理をしまーす。
# んー、自分が作った直交表割付ツールが見当たらない。。。
※この記事は こちら からの転載です。
テスト条件がひとつの場合から2個以上になると、テスト設計がぐんと難しくなる。難しくなるというのは、全体のテスト条件の組合せの中から優先的にテストすべきパターンを見つける技法を知らないと、効率が悪くなるということ。第3章で紹介するのは「ドメイン分析テスト」「デシジョンテーブル」「原因結果グラフ」「CFD法」の4つのテスト技法。
実は、このサイトで公開している原因結果グラフの支援ツール「CEGTest（セグテスト）」について、詳しく紹介していただいてます。この場を借りて御礼申し上げます！ありがとうございます！現時点でCEGTestの使い方について最も詳しく書かれているドキュメントだと思います＾＾；また、CFD法についても書籍として解説しているのはドリル本だけじゃないでしょうか。デシジョンテーブル自体も同じことを言えるのですが、CFD法はテストエンジニアだけでなく実装に携わるエンジニアにも知っておいて損はない技法といえるでしょう。
原因結果グラフのデシジョンテーブル変換については、JaSST’07 Tokyoの「三賢者」資料が一番詳しいです。
※この記事は こちら からの転載です。
第2章は、変化する値を「線」に見立てて同値分割・境界値分析について。この基本的なテスト技法については大切なことが2つ書かれてます。
一つは、図式化。学校で数直線なるものをよく書いたと思うけど、仕様を「線」や「ベン図・オイラー図」といった図式化することが理解を深める。特に「線」のように一列にすることで、同値クラスと境界を見やすくできる特色がある。ベン図・オイラー図はどちらかというと領域の個数やありえない領域を理解したい場合に使うとよい。
もう一つは、無効同値は単独で確認すること。どんなに小さな単位のテストでも目的があって、無効同値を組み合わせるとその目的がぼやけてしまう。このあたりは論理関係の確認でも同様。このあたりはもしかしたらプログラマのほうが得意なんじゃないかな、実装が見えている分。
本文では簡単な例題がいくつか掲載されているが、例えば境界仕様に自由度をもった仕様（個数単価の仕様をスーパーマーケット側が設定可能な場合）もちょっと考えてみようかな。
それにしても負荷テストは成功しないよなあ。。。
※この記事は こちら からの転載です。
テスト技法といえば、G・J・マイヤーズの「ソフトウェア・テストの技法」やボーリス・バイザーの「ソフトウェアテスト技法-動化、品質保証、そしてバグの未然防止のために」など古典が有名。理論的な内容だけど、なかなか難しいという印象が強いともいえる。それに対して、この本が「ドリル」という形で読者に訓練・経験を促すのは、勉強しただけで使えていないテスト技法をより実践的なスキルにするため。テスト技法はそれひとつでは銀の弾丸にはなり得ないが、組み合わせて使えば十分強靭な武器になる。自分も含めて、知ってると思っている技法についても振り返りながら演習を解いてみたい。
第1章は「点に注意を向ける」という副題。章のトビラページにはポリアの「いかにして問題をとくか」の言葉が添えられている。ここでは問題解決のための突破口となるコツが「例示」「間」「類推」「外側」「意地悪」というキーワードで紹介されている。こういったキーワードで整理されることによって、枚挙という作業がより効果的になるような気がする。そして「技（わざ）」が「術（すべ）」に変わるのだ。
バグ票をシャワーのように浴びることがよい訓練になる、という記述がある。昔から言われていることだが、プログラマにとっては自分以外のコードを読むことも似たような訓練になるよね。怪しいところを見つける「想像力」のトレーニングに通じる。自分はどうやってコードを読んでるのだろうか。
そういえば、コツは「骨」のことらしい。第1章はまさにテスト技法の骨格といってもいい。
※この記事は こちら からの転載です。