[書籍]事例とツールで学ぶHAYST法 -正常系と異常系-

正常系テストとか異常系テストとかふだん使ったりします。この本では、機能が働くテストを「正常系」、機能がエラーなどで最後まで働かないテストを「異常系」と表現しています。また、異常に対して正しく実行できたことを確認するテストとして「準正常系」という考え方も紹介されています。何気なく使っているけど、もしかしたら人(文化?)によって定義が異なるかもしれない用語を自分なりに整理してみました。

準正常系

エラーを検知して、それを結果として出すこと。僕の場合は、実装時(ユニットテスト時)ではなるべく最初に確認します。それは、因子の積集合(テスト空間と呼ぶこともある)があって、それを同値分割していくイメージです。たいていの場合は、無効同値クラスを削っていって、削っていって、最後に有効同値クラスがいくつか残ります。防御的プログラミングの視点を意識します。

正常系

機能が働き、正しい結果を期待通り出すこと。僕の場合は、実装時(ユニットテスト時)ではなるべく最後に確認します。準正常系を削った後に残った有効同値クラスを期待する結果でさらに同値分割します。一旦は考えうる同値分割を想像して、ズームアウトしてバランスをとります。

異常系

この本ではエラーによって最後まで機能を果たさないことを確認するテストですが、僕の場合は、実装とは直接関係しない因子と考えています。タイミングの問題やネットワーク状態、負荷など実行しにくい場合が多く、ユニットテスト時には確認しないことが多いです。準正常系や異常系とは異なり、ラルフチャートを思い浮かべて、因子抽出を心がけます。
また、一般的に異常系(あるいは無効値)は一つずつしか確認できないといいますが、すべての因子の無効値を組み合わせた場合は、異常系として確認します。

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

試しに、直交表に割りつけてみた。

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

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

ramenoa

16番目の組合せだけが説明文通りの「食べたいラーメン」だけど、他の15通りで「食べたいラーメン」があるかもしれないー。

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

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

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

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

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

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

==

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

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

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

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

ramenceg

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

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

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

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

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

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

[書籍]ソフトウェアテスト技法ドリル -面で逃さない-

テスト条件がひとつの場合から2個以上になると、テスト設計がぐんと難しくなる。難しくなるというのは、全体のテスト条件の組合せの中から優先的にテストすべきパターンを見つける技法を知らないと、効率が悪くなるということ。第3章で紹介するのは「ドメイン分析テスト」「デシジョンテーブル」「原因結果グラフ」「CFD法」の4つのテスト技法。

実は、このサイトで公開している原因結果グラフの支援ツール「CEGTest(セグテスト)」について、詳しく紹介していただいてます。この場を借りて御礼申し上げます!ありがとうございます!現時点でCEGTestの使い方について最も詳しく書かれているドキュメントだと思います^^;また、CFD法についても書籍として解説しているのはドリル本だけじゃないでしょうか。デシジョンテーブル自体も同じことを言えるのですが、CFD法はテストエンジニアだけでなく実装に携わるエンジニアにも知っておいて損はない技法といえるでしょう。

原因結果グラフのデシジョンテーブル変換については、JaSST’07 Tokyoの「三賢者」資料が一番詳しいです。

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

[書籍]ソフトウェアテスト技法ドリル -線を意識する-

第2章は、変化する値を「線」に見立てて同値分割・境界値分析について。この基本的なテスト技法については大切なことが2つ書かれてます。

一つは、図式化。学校で数直線なるものをよく書いたと思うけど、仕様を「線」や「ベン図・オイラー図」といった図式化することが理解を深める。特に「線」のように一列にすることで、同値クラスと境界を見やすくできる特色がある。ベン図・オイラー図はどちらかというと領域の個数やありえない領域を理解したい場合に使うとよい。

もう一つは、無効同値は単独で確認すること。どんなに小さな単位のテストでも目的があって、無効同値を組み合わせるとその目的がぼやけてしまう。このあたりは論理関係の確認でも同様。このあたりはもしかしたらプログラマのほうが得意なんじゃないかな、実装が見えている分。

本文では簡単な例題がいくつか掲載されているが、例えば境界仕様に自由度をもった仕様(個数単価の仕様をスーパーマーケット側が設定可能な場合)もちょっと考えてみようかな。

それにしても負荷テストは成功しないよなあ。。。

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