プログラマの思索

昨日開催されたシステムテスト自動化カンファレンス2013の資料で、「モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013」がとても参考になったのでメモ。
ラフなメモ書き。

【参考】
12月1日 システムテスト自動化カンファレンス2013 #stac2013(東京都)

【1】原因結果グラフと他のテスト技法の比較

資料が下記で公開されている。
興味深い点は、設計書で記載された仕様(モデル)として状態遷移モデル、論理モデル、組み合わせモデルの3つがあり、それらをベースとしたテスト技法として、状態遷移テスト、デシジョンテーブルテスト、組み合わせテストに分類されることだ。

設計モデルをベースとしたテストなので、プログラムの内部構造は見ず、入出力び外部インターフェイスによるテストになるから、ブラックボックステストになる。
状態遷移テスト、デシジョンテーブルテスト、組み合わせテストのいずれも、モデルからテストケースを自動生成できる点が魅力的だ。

状態遷移モデルは、UMLのステートマシン図をastahで描いて、astahの品質スイートプラグインから遷移パターンのシナリオを出力できる。

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

状態遷移表プラグインを使って、電話のステートマシン図を作成・改善する ? astah-QualitySuite 1.2 documentation

論理モデルはデシジョンテーブルを作ればいい。
デシジョンテーブルは原因結果グラフと同値であり、CEGTestというツールを使うと、原因結果グラフからデシジョンテーブルを自動生成できる。

ソフトウェアテストの勉強室: 原因結果グラフ

ソフトウェアテスト技法ドリルの感想: プログラマの思索

組み合わせモデルは、HAYST法や直交表、All Pair法を使う。
簡単なツールとしては、PICTや、PICTをExcelマクロに取り込んだツールPictMasterを使えばいいだろう。

データパターンの組み合わせからテストケースを自動生成するツール: プログラマの思索

PICTで出力したテストケースをTestLinkへ取り込む: プログラマの思索
いずれもテストケースの元ネタを作成するツールがあり、かなり使える点が魅力的だと思う。
その中で、興味を持つのは、原因結果グラフだ。

以前から、テストケース生成ツールとして、astah品質スイートプラグイン、PICTを実際に使ってみた。
しかし、エンタープライズ系の業務システムでは、仕様が確定している状況でシナリオベースのテストが多く、その場合はデシジョンテーブルを使う時が多い。

状態遷移テストや組み合わせテストは探索的テストで使うケースが多い。
会員の状態遷移を探索テストしたり、クライアントのOSとブラウザの組合せで回帰テストしたりする時には使えるが、主流のテストではない。
結合テストやシステムテストで、仕様に基づいた外部インターフェイスのテストをしたいのだ。
その時、仕様を原因結果グラフで描いてデシジョンテーブルに落とし、テストケースの品質を上げるという方向を試せるのではないかと考えている。

【2】softest.jp | 原因結果グラフ技法の解説(1)

原因結果グラフの書き方は、CEGTestの作者である加瀬さんの公開資料が分かりやすい。
「ソフトウェアテスト技法ドリル」にも原因結果グラフの説明がある。

原因結果グラフは、初心者にとって難しい。
ソフトウェア開発者は手続き(フロー)の順に考えるのが普通なので、集合ベースで考えるとか、論理回路のような絵で考えるのは、頭の使い方が違うので、すぐには使いこなせないのが普通だと思う。
だから、実際にサンプルを使って、たくさん書いて慣れるのが良いと思う。

原因結果グラフのサンプルとして、下記で色々公開されているので、試してみると面白い。

ソフトウェアテストの勉強室: 原因結果グラフ

【3】CEGTestで原因結果グラフを描く時の注意点をまとめてみた。

CEGTest - 原因結果グラフからテスト条件を作成するツール

・ノードをつないで、原因と結果をつなげる。
・AND、OR制約は、ノードのプロパティから選択できる。
・NOT制約は、線を選択して、ノードを2回クリックして「NOT原因」を表示し、結果とつなげる。
・ONE～MASKの制約は、メニューから選択する。

・CEGTestでは、UNDO、REDOが実装されていない。
　(UNDOはメニューにあるが「未実装」と表示された)
　だから、逐一エクスポートしてバックアップした方がいい。

・原因結果グラフやデシジョンテーブルはCSV出力できる。

・ノードのプロパティにある「観測可能」は、ノードの真偽がテスターが観測できるか否かの判定を表す。
　中間ノードの真偽が決定しない場合に使う。
　使い道はよく分からない。

【4】原因結果グラフの注意点

上記のサンプルを見ると、簡単な例におけるテストケースでもかなり複雑な原因結果グラフになる。
例えば、Meyersの三角形のテストもそうだ。

原因結果グラフが複雑になりやすい理由の一つは、ONE～MASKなどの制約が発生するからだろうと思う。
単なるAND・OR・NOTだけで、テストケースが完成するのではないのだ。

制約の内容については、下記が詳しい。

softest.jp | 原因結果グラフ技法の解説(1)

ONE制約は、唯一つがTRUEの制約。
必ず一つの要素(ノード)が入力条件になる。
例えば、必須のラジオボタン、必須のプルダウン。
男性・女性など。

EXCL制約は、高々一つがTRUEの制約。
0個または1個の要素(ノード)が入力条件になる。
例えば、必須でないラジオボタン。
6歳以下、65歳以上など。

INCL制約は、少なくとも一つがTRUEの制約。
1個以上の要素(ノード)が入力条件になる。
例えば、必須で複数個選択できるチェックボックス。
所有PCの種類として、Windows、MacOS、Linuxなど。

REQ制約は、Aが真であるにはBが真であることが必要という制約。
例えば、商品画面で商品を購入するには、商品ボタンが表示されることが必要。

MASK制約は、Aが真であればBの真偽は不明という制約。
例えば、クリップボードにデータがなければ、右クリックの貼り付け機能はDisableになる。

これらの制約の注意点は下記の記事が詳しい。

原因結果グラフの「制約のテスト」: ソフトウェアテストの勉強室

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その1

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その2

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その3

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その4

原因結果グラフを描くのが難しい理由はいくつかある。
まず、「ソフトウェアテスト技法ドリル」にも書かれているが、中間ノードを見出すのが難しい。
良い中間ノードがでないと、ケースに不備が多い。
解決策としては、結果ノードから原因を追いかけるようにして、中間ノードを作り出す。

そして制約条件を付けるのが難しい。
制約条件を上手く利用すれば、テストケースを減らすことができる。
少なくとも、ONE、EXCL、INCLの制約は使いたい。

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その1において、の『ソフトウェアテスト技法ドリル』の例題「ロック状態の携帯電話を解除するには、指紋認証を行うか端末暗証番号を入力する。」に対し、「A:指紋認証パス」と「B:暗証番号パス」にEXCL制約をつけた場合、カバレッジ表には「AもBも偽」というケースがそもそも現れないと書かれている。
その理由は、EXCL(A + B)とは、AまたBの結果が真でありかつ高々1個という制約だから、AもBも偽であれば、矛盾するからだ。

REQは、前提条件を満たさなければ、結果を選択できない場合に使う。
例えば、注文ボタンの表示や、優遇会員の登録などが思いつく。

MASKは、入力条件を変えると結果ノードがDisableないし非表示になってしまう場合に使う。
例えば、「ソフトウェアテスト技法ドリル」では、期間検索で終日チェックボックスを押すと、時刻テキストボックスが消える例が載っている。
WebのUIで、何かのチェックボックスを選択すると、テキストボックスが消えたり、ボタンが押下不可になる場合があげられるだろう。

原因結果グラフを使いこなした場合、どこまでテストケースの品質を向上できて自動生成できるか考えてみる。