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

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つ書かれてます。

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

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

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

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

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

[書籍]ソフトウェアテスト技法ドリル -点に注意を向ける-

テスト技法といえば、G・J・マイヤーズの「ソフトウェア・テストの技法」やボーリス・バイザーの「ソフトウェアテスト技法-動化、品質保証、そしてバグの未然防止のために」など古典が有名。理論的な内容だけど、なかなか難しいという印象が強いともいえる。それに対して、この本が「ドリル」という形で読者に訓練・経験を促すのは、勉強しただけで使えていないテスト技法をより実践的なスキルにするため。テスト技法はそれひとつでは銀の弾丸にはなり得ないが、組み合わせて使えば十分強靭な武器になる。自分も含めて、知ってると思っている技法についても振り返りながら演習を解いてみたい。

第1章は「点に注意を向ける」という副題。章のトビラページにはポリアの「いかにして問題をとくか」の言葉が添えられている。ここでは問題解決のための突破口となるコツが「例示」「間」「類推」「外側」「意地悪」というキーワードで紹介されている。こういったキーワードで整理されることによって、枚挙という作業がより効果的になるような気がする。そして「技(わざ)」が「術(すべ)」に変わるのだ。

バグ票をシャワーのように浴びることがよい訓練になる、という記述がある。昔から言われていることだが、プログラマにとっては自分以外のコードを読むことも似たような訓練になるよね。怪しいところを見つける「想像力」のトレーニングに通じる。自分はどうやってコードを読んでるのだろうか。

そういえば、コツは「骨」のことらしい。第1章はまさにテスト技法の骨格といってもいい。

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

デシジョンテーブルの解説

デシジョンテーブルとは

デシジョンテーブルとは、決定表(JIS X 0125)[1]として規格が定義されています。論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールの組合せます。プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。

図1. デシジョンテーブルの例(駐車場料金の割引計算)

図1. デシジョンテーブルの例(駐車場料金の割引計算)

デシジョンテーブルを作成する手順は一般的に以下の通りです。

  1. 分析対象・テスト対象の持つ条件・原因を洗い出し、それぞれを行として追加します
  2. 処理・動作・結果を洗い出し、それぞれ行として追加します
  3. 起こりうる条件・原因の組合せを作成し、それぞれ列として追加します
  4. 作成した列のうち、集約可能な列の組を圧縮します
  5. 組合せの作成と圧縮についての検算をします

デシジョンテーブルを使うことで以下のようなメリットが挙げられます。(作成中)

しかし、以下のような分析対象・テスト対象を扱う場合は注意が必要です。(作成中)

 

デシジョンテーブルの構成

デシジョンテーブルは以下のような要素で構成されています。

    • 条件記述部(condition stub)

考慮すべき条件・原因を列挙する部分で、図2では「3000円以上10000円未満」「シネマ利用」などが該当します。制限指定の場合は、記述した語句が真であるか偽であるかが明確になるように命題形式で記述するとわかりやすいです。拡張指定の場合は、記述した語句が数値や複数選択肢を持つことが明確になるように変数形式で記述するとわかりやすいです。原因結果グラフ技法で使われるデシジョンテーブルは、制約指定のように命題形式で記述します。

図2. 条件指定部

図2. 条件指定部

 

    • 動作記述部(action stub)

考慮すべき動作・結果を列挙する部分で、図3では「30分無料」「3時間30分無料」などが該当します。制限指定の場合は、記述した語句が実施されるかされないか(真であるか偽であるか)が明確になるように命題形式で記述するとわかりやすいです。拡張指定の場合は、記述した語句が実施される動作そのものや結果そのものを記述するとわかりやすいです。原因結果グラフ技法で使われるデシジョンテーブルは、制約指定のように命題形式で記述します。

図3. 動作指定部

図3. 動作指定部

 

    • 条件指定部(condition entry)

それぞれの条件・原因を特定の値・意味で指定し、ひとつのルールと関連付けをします。条件指定部には表1のような書き方をします。すべての条件・原因の値・意味が指定されるとひとつのルールが定められ、自動的に動作・結果が決定されます。また、ひとつのルールは他のルールと一致しないように値・意味の組合せをとります。

JIS X 0125 では規定していませんが、列挙される条件・原因の順序が判定順序などの意味を持つ場合もあります。ただし、原因結果グラフ技法で使われるデシジョンテーブルの場合は、順序に関するREQ制約などを用いて判定順序を表現し、特にCEGTestでは列挙される順序を論理点の検証順序として利用しています。

表1. 条件指定について

表記 ルールで関連付ける意味 CEGTest
表記
Y
(Yes)
この行に対応する条件・原因が真であることを意味します。 T、t
N
(No)
この行に対応する条件・原因が偽であることを意味します。 F、f
値、語句など この行に対応する条件・原因が記述された値であったり、語句を満たすことを意味します。

#
この行に対応する条件・原因が無関係であることを意味します。また、特に他の条件・原因の組合せによってこの行に対応する条件が起こり得ないことを「#」で表記する場合もあります。

図4. . 条件指定部

図4. . 条件指定部

 

    • 動作指定部(action entry)

それぞれの動作・結果を特定の値・意味で指定し、ひとつのルールと関連付けをします。

列挙される動作・結果の順序は、実行される動作(生じる結果)の順序を表現しています。動作指定部には表2のような書き方をします。もし、順序の異なる動作・結果がある場合には、必要な順序組合せの個数分だけ動作指定部を記述する必要があります。

表2. 動作指定について

表記 ルールで関連付ける意味 CEGTest
表記
X
(eXecute)
この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じることを意味します。 T、t
この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じないことを意味します。 F、f
値、語句など この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が記述された値であったり、語句を満たすことを意味します。

図5. 動作指定部

図5. 動作指定部

 

デシジョンテーブルの具体例

(作成中)

 

参考文献・引用文献

[1] JIS X 0125 決定表, 日本規格協会