久しぶりの勉強会参加。
今回の勉強会は演習だったというのに、PC持たずに参加という暴挙をやらかしました。(><)
Mac貸して頂いた@nemorineさんありがとうございました。<(_ _)>
今回の勉強会は、CEGTestというツールを使用して、デシジョンテーブルを自動で作成する演習。
Webアプリだけど、zipファイルでツール一式ダウンロード出来るので、ローカルでも実行可能。これならセキュリティにうるさい厳しい仕事でも使用できそう。
CEGとはCause-Effect Graph(原因結果グラフ)のこと。
CEGTestは、原因(の組み合わせ)と結果を元にして、デシジョンテーブルを自動で生成してくれるツール。
以下、画面例。
この例だと、「ユーザ名が正しい」「パスワードが正しい」が原因、「ログイン」が結果。
この原因と結果のグラフを描くと、その組み合わせに対応するデシジョンテーブルとカバレッジ表が自動で作成される。
以下、演習問題と感想など。
ニートの定義をデシジョンテーブルで表す
ニートの定義は以下
・15歳～34歳、未婚であって家事・通学をしていない人
・学籍はあるが、実際は学校に行っていない人
・既婚者で家事をしていない人
(注：これは現在の厚生労働省のニートの定義とは異なるようです)
この定義に対して、自分が最初に作ったのはこんな図。
※ 条件と結果の間のオレンジ線は否定(False)条件
条件が3種類あるので、これに合わせて結果のボックスも3つ別個に用意したけど、原因と結果の間に、中間結果を置くことで、最終的な結果を一つにすることが出来るそう。
中間結果を置いた図はこんな感じ。
作成されたデシジョンテーブル見ると、このニート定義の曖昧さが見えてくる。
デシジョンテーブルからテスト項目を作るのにも便利だけど、、仕様に抜けがないかを確認することにも使えそうだなと思った。
なお、作成されたデシジョンテーブルの小文字tの意味はここに、
論理上ノードが真でならざるを得ない(該当する真偽の組合せが論理式にない)。
とあるので、小文字のtやfがデシジョンテーブルに出てきたら、真偽の組み合わせが抜けていると判断した方がよさそう。
オフサイドの定義をデシジョンテーブルで表す
オフサイドというルールは、「オフサイドポジションにいる選手に対して、パスを出す事を禁止する」というものである。
ここで「オフサイドポジション」とは以下の条件を全て満たした位置の事を指す。
・相手陣内にいる
・ボールより前にいる
・相手の2番目に後ろの選手よりゴールラインに近い位置にいる
サッカー観戦を趣味としてる者として絶対に間違うことが出来ない問題。
なので問題そのものは楽勝でした。
この問題を解いてた時に思ったのが、中間結果の抽出・名前付けは、仕様整理にも使えそうだな、ということ。
問題文にある「オフサイドポジション」という単語を使わずにオフサイドの条件を書くと、
「オフサイドというルールは、相手陣内にいて、ボールよりも前、かつ、相手の2番目に後ろの選手よりゴールラインに近い位置にいる選手に対してパスを出す事を禁止するものである」
のような、すぐに理解するのは難しい文章になる。
これを、「オフサイドポジション」という中間結果を定義付けすることで、問題文のように、
「オフサイドというルールは、オフサイドポジションにいる選手にパスを出すことを禁止するものである」
「オフサイドポジションとは．．．」
のように、オフサイドとオフサイドポジションの説明を段階的に記載することが出来る。この方が理解し易い。
複雑な条件のときは、条件の組み合わせに対して名前付け(中間結果の定義)を積極的にやってみると分かりやすくなるかも、と。
チケット割引率をデシジョンテーブルで表す
杜王町の美術展の入場料には以下のような割引がある。
18歳以下は学割で10%割引である。
65歳以上のシニアの人はシニア割で20%割引である。
19歳以上、64歳以下は特に割引はない。
またクーポンを持参している人は10%割引である。
ただし、割引が重複した場合は合算した割引率を適用する。
CEGTestでは、条件に対する幾つかの制約を使用することが出来る。この問題ではONE制約を使用。
自分が描いた図は以下。
が、クーポン割引のみのパターンを上げ忘れてた事に後から気がついた。
勉強会後に@nemorineさんに確認したところ、このパターン抜けをツールで検出する方法はないです、とのこと。
抜けがないかは、各ボックスから引かれてる線の数などから確認するような方法になるそう。
自分の書いた図を確認してみると、「18歳以下」と「65歳以上」からは2本線が引かれてるのに、「19歳～64歳」から引かれてる線は1本なので、他と合ってなさそうなのが分かる。
複雑なパターンだと抜けも発生しやすくなるだろうから、条件抜けがないかの確認は重要ということで。
試験パターンの網羅性を確認するのに、今までの仕事ではマトリクスを用いた試験条件の掛け合わせを用いてたけど、このツールを使った方が便利そう。
次の試験項目抽出には是非使ってみよう。
主催者の@nemorineさんのblog： http://ameblo.jp/sendai-test/entry-11598615485.html
