ソフトウェアの品質を学びまくるソフトウェアの品質を学びまくる読者になるソフトウェアの品質を学びまくるソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。ツール2月7日、第3回「ソフトウェアテスト技法ドリル」勉強会@ニフティに参加してまいりました。この場を借りて、お礼申し上げます。そのときの様子をお伝えしようかと思いましたが、他の方がTEFにて投稿くださっていることもあり、ここはあえて「予習問題」に対する思考の過程を振り返っておくことにします*1。この記事は、「その1」の続きです。www.kzsuzuki.com予習問題を解いてみる当日に向けて出た宿題は、以下の仕様からCEGTestで原因結果グラフ(以下「CEG」)を描き、デシジョンテーブルを作成せよ、というものでした。呼気1リットルに0.15mg以上のアルコールが検出されると、飲酒と判断。「酒酔い」は、まっすぐに立っていられるか、歩行が困難ではないか、ろれつが回っていないかを調べて判断します。「酒気帯び」は、0.15mg以上のアルコール濃度はあるが、「酒酔いでない」という状態になります。その1にも書いたように、まずは原子的な命題を抽出し、論理関係をまとめると、こんなCEG・カバレッジ表になります。論理式1・2は、結果【飲酒】についての真偽表。論理式3~5は、結果【「酒酔い」】についての真偽表。2つ以上の原因が偽になるケースは省略されています。論理式7~9は、結果【「酒気帯び」】についての真偽表。これらの論理式を、矛盾なきよう詰め込んだのがデシジョンテーブルになっています。DTを日本語に還元このデシジョンテーブルをもう一度日本語に還元して、それが市民感覚に合うものか検証していきましょう。この検証の重要さが、今回の勉強会で学んだことの1つです。自然言語で書かれた仕様が厳密であると期待すべきではない。暗黙の論理関係があると考える方が確実です。#5は、呼気も正常、挙動も正常なので、「酒酔い」でも「酒気帯び」でもないとしてよいでしょう。#4は、酒は飲んでいるが、挙動は正常。「酒気帯び」になります。#1と#3は、酒を飲んでいてかつ、挙動もおかしい。小文字は何者?気になるのは#2です。【「酒酔い」】が「T」である一方、【「酒気帯び」】は「f」になっている。この小文字の「f」とは何者でしょう。ヘルプを見てみましょう。論理上ノードが偽でならざるを得ない(該当する真偽の組合せが論理式にない)。【「酒気帯び」】がTになるためには、【飲酒】はTでなくてはならない。#2は【飲酒】がFであり、その時点で【「酒酔い」】がTだろうとFだろうと、【「酒気帯び」】はTにならない。これが、「偽にならざるを得ない」ということでしょうか。そもそもこの【飲酒】=F、【「酒酔い」】=Tはカバレッジ表にも現れない、優先度低の組み合わせです。#2でわざわざ、【>0.15mg】がFになるような真偽パターンを組み込んでいるのかはわかりませんが、論理式1・2をバランスよく使おうとした結果かな?と考えてもみます。「f」の謎は保留として、#2の日本語解釈に戻りましょう。#2をそのまま読むと、高熱でふらふらしているだけで「酒気帯び」と見なされることになります。冤罪の匂いがしますね。何か、書かれていない論理を見逃していると思われる。最初の文を読み直すと、明示的には書かれていませんが、常識的には飲酒と判断。そのうえで、『酒酔い』は、・・・と考えるのが妥当です。そもそも「まっすぐに立っていられるか・・・を調べて判断します」という文からして、「酒酔い」と見なすのが、「立っていられるなら」なのか「立っていられないなら」なのかも不明、3つの判断条件がORなのかANDなのかも曖昧ですが、そこは常識で判断しているわけです。ORと、【飲酒】をANDで結びたいところですが、CEGのノードではANDとORの混じった論理式の表現ができないので、中間ノード【挙動不審】をおくことにします。これで、デシジョンテーブル#2が、「挙動不審でも、飲酒していないければ無罪放免」という結果になりました。実は、予習問題に対するわたしの回答は、ここで終わっていました。森さんの講義には、先がありました。?たしかに一般的に、まず「酒を飲んでるね」という前提があって、そのうえで「酒酔い」やら「酒気帯び」を判断するのが検査でしょう。この判断の順番は、REQで表現すべきものですね。いうことで、【飲酒】が真になったうえで初めて、挙動不審の判定をするようにします。カバレッジ表では論理式11が、このREQ制約により消されているのに加えて、【挙動不審】が真になる論理式3・4・5の「飲酒」列が真になっています。デシジョンテーブルは以下。【>0.15mg】が偽になるケースが、2個から1個に減りました。常識って・・・?これで、ひと通り終わりです。日本語を単純にCEGに落とし込んだ後に、中間ノードを追加し、REQ制約を追加しました。この2つで十分なのか、逆にこの2つが本当に必要なのかは、実はCEGを作る人が最終判断することではなく、顧客要件を確認することが必要なのだと思います。CEGを描く過程で、このような仕様の漏れ・曖昧に気づくことこそが、CEGを描くことの効用の1つですね。ここで登場したREQ制約、そしてMASK制約は、ONE・INCL・EXCL制約に比べてなかなか使いづらいものです。次回は、これらに関する考察をしたいと思います。www.kzsuzuki.com*1:当日講師をしてくださった森(@mori_ryuji)さんの講義資料を、参考にしております。練習帳』の第4章「組合せテスト」*1...2011-12-05ドリル勉強会第7回、状態遷移図11/21に開催された、第7回ソフトウェアドリル勉強会。その3その1とその2はコチラです。AdSenseを使用しています。AdSenseは、ユーザーの興味に応じた広告を配信するためにCookieを利用しデータを収集しています。Cookieを無効にする設定、およびGoogleアドセンスに関する詳細は、Googleのポリシーと規約をご覧ください。はてなブログをはじめよう!kz_suzukiさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。