アドベントカレンダー２４日目 第３章 面で逃さない（２）
こんにちは。リリカルです。気づいたらWACATEが直前に迫っていますが、今日も今日とて予習をします。
WACATE2016 夏 満員御礼！と 予習内容について - WACATEブログ
第３章 面で逃さない
前回の続きです。第３章ではドメイン分析テスト、デシジョンテーブルの他に原因結果グラフについて扱われています。
なぜ原因結果グラフを使うのでしょうか？それは、「条件の数が増えすぎてデシジョンテーブルが巨大になってしまった時に、テストの設計意図が把握できない」という問題を解決するためです。テストの設計意図がわからなければ、なぜこのテストケースが必要なのかということが理解できないため、例えば担当者から引き継いだ時に流用できなくなります。
ドリル本では、加瀬正樹氏が開発した、原因結果グラフをデシジョンテーブルに変換するソフトウェア"CEGTest"についても解説されています。
原因結果グラフの概要
そもそも原因結果グラフとはどんなテスト技法なのでしょうか。
ドリル本 p.47によると、原因結果グラフは以下の手順で作成します。
① 原因と結果の因果関係の抽出
② ノードの配置とリンク
③ 制約条件の書き込み
なのでまずは仕様書から因果関係の抽出を行う必要があります。ドリル本では、論理関係を示す日本語（「かつ」「または」「ではない」「両方」など）に着目してマークしておくとよいと言われています。
具体的に問題を例に挙げて説明していきます。以下、p.88の演習問題を引用します。
3.2
個人情報保護法では、個人情報を管理する義務を有する人・会社等を「個人情報取扱事業者」としている。「個人情報取扱事業者」となる条件は以下の通りである。
CEGTestを用いて原因結果グラフとデシジョンテーブルを作成せよ。
(ア) 個人情報をデータベース化している
(イ) 事業に使用している
(ウ) ただし、次に掲げる者を除く
① 国の機関
② 地方公共団体
③ 独立行政法人等
④ 個人情報の合計が5,000 を超えない者
※ 問題を簡単にするため実際の個人情報保護法から一部表現を簡略化している。
まずここで「条件は以下の通り」として(ア)〜(ウ)が記載されていますから、ここにAND条件があることになります。
さらに「ただし〜除く」という表現がありますから、ここにも論理関係があります。
具体的にCEGTestで描いてみたのがこちらです。
(ウ)についてはフラグを用意して、OR条件でそれがON/OFF切り替わることにしました。
次に制約について書いていきます。 CEGTestでは以下の制約が使えます。
ONE制約：唯一。どれか一つを必ず選択する。
EXCL制約：排他。選択しても高々一つである。
INCL制約：包含。少なくとも一つは選択する。
REQ制約：「これのためには〜を満たしていなければならない」というような要求事項、前提事項。あるノードが真になるために、事前に真になっていることが必要になる。
MASK制約：隠蔽。あるノードが真になると、MASK制約で指定された２つ目以降のノードの真偽は確認できなくなる。（マスク、隠蔽される）
上のものに制約をつけてみたのがこちらです。
※上のグラフ、一度間違えて消しちゃいました。こまめに「クラウドに保存」ボタンを活用すると良いです。その際、名前をつけていないと「どれだよ！」ってなるので気をつけてください。ユーザ登録すると、自分が保存したのがどれかわかりやすいのでオススメです。
なぜわざわざ制約をつけるのかというと、それは（本来自明である）不要なテストパターンを出力したくないためです。
自動化全てにおけることですが、このCEGTestのようなツールを利用してテストパターンを出力しようとするとき、こう言った制約を全く定めずに適用するととんでもないことになります。例えば上の例だと、「国の機関」かつ「地方公共団体」ということは論理的にありえません。こういったパターンは自分が手作業で洗い出していく中では自然と除外されますが、ツールの入力として使いたい場合はこの制約も明確にしておく必要があります。
その他制約、原因結果グラフの詳細な説明や、CEGTestの使い方についてはドリル本を参照してください。
いよいよ6/18はWACATE
いよいよ近づいてまいりました。せめてHAYST法のおさらいはやっておきたいなあ。
セキュリティテストの本なんかも読んでおこうと思ったけど、それは行きの電車の中でですかね。
いずれにせよ、実行委員の方々ありがとうございます！とても楽しみです！
