ソフトウェアの品質を学びまくる2.0

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

原因結果グラフとCEGTestに関する考察 - その2

 2月7日、第3回「ソフトウェアテスト技法ドリル」勉強会@ニフティに参加してまいりました。この場を借りて、お礼申し上げます。
 そのときの様子をお伝えしようかと思いましたが、他の方がTEFにて投稿くださっていることもあり、ここはあえて「予習問題」に対する思考の過程を振り返っておくことにします*1。なおこの記事は、「その1」の続きです。

www.kzsuzuki.com

予習問題を解いてみる

 当日に向けて出た宿題は、以下の仕様からCEGTestで原因結果グラフ(以下「CEG」)を描き、デシジョンテーブルを作成せよ、というものでした。
呼気1リットルに0.15mg以上のアルコールが検出されると、飲酒と判断。
「酒酔い」は、まっすぐに立っていられるか、歩行が困難ではないか、ろれつが回っていないかを調べて判断します。
「酒気帯び」は、0.15mg以上のアルコール濃度はあるが、「酒酔いでない」という状態になります。
 その1にも書いたように、まずは原子的な命題を抽出し、論理関係をまとめると、こんなCEG・カバレッジ表になります。

2-6

2-2

 論理式1・2は、結果【飲酒】についての真偽表。
 論理式3~5は、結果【「酒酔い」】についての真偽表。2つ以上の原因が偽になるケースは省略されています。
 論理式7~9は、結果【「酒気帯び」】についての真偽表。

 これらの論理式を、矛盾なきよう詰め込んだのがデシジョンテーブルになっています。

2-3

DTを日本語に還元

 このデシジョンテーブルをもう一度日本語に還元して、それが市民感覚に合うものか検証していきましょう。
 この検証の重要さが、今回の勉強会で学んだことの1つです。元々、自然言語で書かれた仕様が厳密であると期待すべきではない。暗黙の論理関係があると考える方が確実です。
 #5は、呼気も正常、挙動も正常なので、「酒酔い」でも「酒気帯び」でもないとしてよいでしょう。#4は、酒は飲んでいるが、挙動は正常。「酒気帯び」になります。#1と#3は、酒を飲んでいてかつ、挙動もおかしい。「酒酔い」ですね。

小文字は何者?

 気になるのは#2です。
 まず、【「酒酔い」】が「T」である一方、【「酒気帯び」】は「f」になっている。この小文字の「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-4

2-5

 これで、デシジョンテーブル#2が、「挙動不審でも、飲酒していないければ無罪放免」という結果になりました。

さらに、常識からもう1つ追加

 実は、予習問題に対するわたしの回答は、ここで終わっていました。ですが、森さんの講義には、先がありました。
普通呼気の検査をして、ひっかかった人に対して「酒酔い」を判断するんじゃ?
 ! ?
 たしかに一般的に、まず「酒を飲んでるね」という前提があって、そのうえで「酒酔い」やら「酒気帯び」を判断するのが検査でしょう。
 この判断の順番は、REQで表現すべきものですね。ということで、【飲酒】が真になったうえで初めて、挙動不審の判定をするようにします。

2-6

2-7

 カバレッジ表では論理式11が、このREQ制約により消されているのに加えて、【挙動不審】が真になる論理式3・4・5の「飲酒」列が真になっています。
 デシジョンテーブルは以下。【>0.15mg】が偽になるケースが、2個から1個に減りました。

2-8

でも、常識って・・・?

 これで、ひと通り終わりです。
 日本語を単純にCEGに落とし込んだ後に、中間ノードを追加し、REQ制約を追加しました。ですが、この2つで十分なのか、逆にこの2つが本当に必要なのかは、実はCEGを作る人が最終判断することではなく、顧客要件を確認することが必要なのだと思います。
 CEGを描く過程で、このような仕様の漏れ・曖昧に気づくことこそが、CEGを描くことの効用の1つですね。
 さて、ここで登場したREQ制約、そしてMASK制約は、ONE・INCL・EXCL制約に比べてなかなか使いづらいものです。次回は、これらに関する考察をしたいと思います。
 
 その3はコチラ。

www.kzsuzuki.com

*1:当日講師をしてくださった森(@mori_ryuji)さんの講義資料を、参考にしております。