ceg2dtツール - 65%くらい完成

今日は深夜メンテナンス。少し休憩。

==

原因結果グラフをデシジョンテーブルにするツールを勉強のために作成しているが、6割くらいできた。未実装なのは、

制約条件（REQとMASK）

Tとt、Fとfの違い

最適化

何とかなりそうな気がしているが、コードがまったくエレガントではないし、長い。。。。

1. サンプル１：チケットの学割
デシジョンテーブル（２） - たまゆら雑記の例を使わせていただきました。

この例だと、なんかあってそうな感じ。でもよくみると、偏ってる。#5は「埼玉に在住でない」「学生証を提示していない」のほうがベターか。

2. サンプル２：ログイン画面

原因結果グラフ - 論理点カバレッジの解剖の例を使ってます。


これは、マス目の埋まっていないところの決め方が偏っているため、テストケース数が多い。最適化の課題か。

3. サンプル３：結婚

結婚できるかどうかの原因結果グラフ。


一見うまくいってそうだが、「16歳以上」「18歳以上」の組み合わせが矛盾。制約条件が中途半端だから。

制約条件からデシジョンテーブルを埋めていく

今日はお風呂を掃除して、近所のスタバのドライブスルーでラテ買ってきて、和室でお勉強。amazonから本も届いたし読むかな。

==

原因結果グラフを元にしてデシジョンテーブルを作成していく手順を自動化して、理解を深めようとしてるのだが、以下の例でいろいろ考え中。

制約条件（男性と女性）

まずは、3つのテストケースを列に組み込んでみた。これは論理接点1～3について、行列を転置したもの。ここで、制約条件（「男性」「女性」はONE制約）から、空欄となっている原因ノード「女性」は自動的に決定される。

制約条件（年齢）

原因ノード「18歳以上」がTrueである場合は、もうひとつの原因ノード「16歳以上」も自動的に決定される（REQ制約）。んー、年齢は「15歳以下」「16歳か17歳」「18歳以上」にしたほうがよかったかな。

たぶん、こういうようにTrue/Falseを決定しつつ、カバレッジ率をあげて、未確定のマス目も埋めていく感じですすめていくかな。

原因結果グラフ→デシジョンテーブル（途中までツール化）

JacaScriptが初心者向けなのかどうかは別として、手ごろだったので原因結果グラフからデシジョンテーブルを作成するツールをJavaScriptでためしに作り中。エクセルVBAとかのが使えるんだろうな。

原因結果グラフ→デシジョンテーブル（v0.2）
# Opera9.26で確認中。まだブラウザによっては動作しないかも。。。

以下、TODOとして。

ブラウザ違いでのチェック

ノードやリンクの入力方法を考える

制約条件の実装

Don't Care状態のマス目対応の実装

検算の実装

原因結果グラフ - 論理点カバレッジの解剖

方針転換。JaSSTの「三賢人、テストを語る」のPDF資料にある、カバレッジ表を読み解く。

また例題。

IDとパスワードを入力して、ログインする画面についての原因結果グラフとします。ここでまず、網羅すべき論理展開式（論理接点、論理点？）がいくつあるかを調べる。これは、それぞれのエッジの交叉点に注目するとわかる。ANDであれば、Tになる1通りとFになるn通りがあるので、(n+1)通り。ORであれば、Fになる1通りとTになるn通りがあるので、(n+1)通り。ということはこのグラフで言えば、3＋3＋3＋3＋2＝14通りとなる。14通りの論理展開式がどのように出現するかをマトリックスにするため、行には論理展開式を、列にはノードを並べた14×10行列を用意する。

ちなみに、薄緑色は原因ノード、イタリックは中間ノード、薄オレンジ色は結果ノード。ここにどんどんT/Fの組合せを記入していく。

ここからは、すべての論理展開式が出現するようにテストケースを組み立てていくのだが、この場合だと4組ですべて網羅した。

出現した論理展開式をチェックするとこんな形のマトリックスが完成する。「x」は1回だけ出現し、「#」は2回以上出現したことを表している。「#」は1回だけ出現し、「x」は2回以上出現したことを表している。

この流れでツールを作ってみるといいかな。ただ、PDF資料だと、最後のテストケースの選び方は割愛されている模様。

原因結果グラフを解剖 - 原因から？結果から？

BlackBerryのメールは本文をBase64にするみたい。

==

原因結果グラフをデシジョンテーブルに変換する際、まずは小さなテーブル（サブテーブル）を作成してから、全体のテーブルを作っていく手順で僕は行っていたが、サブテーブルはどちらから結合したほうが簡単なのだろうか。ごくごくシンプルな原因結果グラフであれば、中間ノードと結果ノードから大枠をサブテーブル化して、細部を組み立てるほうがわかりやすそうだけれども、制約条件が関係してくると、原因ノードと中間ノードからサブテーブルを作成して、制約条件を先に考慮したほうがよさそうにも思える。

などと考えてみる。

今のところの結論としては、原因側から右側へ結合させていくほうがよさそうに思える。原因ノードと中間ノードについてのサブテーブルを作成する際に、原因ノードと制約条件をもつ原因ノードも一緒にしてしまうといいのではないか。

デシジョンテーブルの結合（具体例）

[サイト]ソフトウェアテスト、HAYST法、などなどのサイト紹介で紹介したサイトにあった、原因結果グラフによるテストケース作成を実際に試してみたが、あきやまさんご指摘のとおり、間違えていた。もう一度順を追ってやり直してみたので、その結果を書いてみた。

==

まずは、原因結果グラフを簡略化してみる。

中間ノードは存在しないので、4つの結果に対するデシジョンテーブルを作成。

そして、これらを単純に結合する。ここまでは素直。太枠の部分がそれぞれのサブテーブルにあたる。

ここでONE制約があるので、必然的にT/Fが決定する部分を埋める。便宜上小文字のt/fとする。

このデシジョンテーブルにはすでに重複する列があるので、それらを除外する。

この時点でデシジョンテーブルを整理してみると、左側7列の中に、最初に作成したサブテーブルの組み合わせが全て出現していることがわかる。ということは残りの#12と#13の空欄をどのように組み合わせても重複する列になってしまうため、除外する。
2008/02/06追記。#2のテストケースの結果が間違っていましたので、修正しています。あきやまさん、ご指摘ありがとうございます。

あとは、ナンバリングしなおして、#7の13のマス目に適当なt/fを埋めて完成。今回は「f」とした。
2008/02/06追記。上図同様#2のテストケースの結果を修正。

==

さて、ここで自分への問題。どうしてテーブルの結合で誤りがあったのか。考えうる原因として、

重複列の判断を間違えた（判断の仕方が適切でなかった）

空欄・DCの考え方が間違っていた

検算を忘れた（サブテーブルの組み合わせの確認）

あたりか・・・

[サイト]ソフトウェアテスト、HAYST法、などなどのサイト紹介

2007年に引き続き、2008年もソフトウェアテストの重要な年になるかも？

==

ブログ更新を怠っていましたが、その間にソフトウェアテストのサイトが立ち上がっているようです。

Software Testing

zohoで作られたソフトウェアテストのまとめ的サイト。主として動的テストに関する記述。体系的でもあり、用語の解説、参考文献なども付記されており、「興味を持ったから参考文献を調べてみよう」といった流れで勉強もできそう。文献以外にもインターえんっ途上に公開されている記事などもリンクされていて、非常にためになります。制御パステスト、テストツールのサイトもある模様。

直交表によるソフトウェアテスト　『ＨＡＹＳＴ法』の解説と学習

著者がHAYST法について、職場向けの資料を作成して、それを公開しているサイト。職場向けの資料ということで、非常に細かい説明が掲載されており、図表や演習問題まで揃っている。

HAYST本とともに、自学用にはとても重要・貴重なサイトであろう。交互作用についての解説も少し載っているのは、HAYST本にはないポイントか。

2008/02/04追記:

ソフトウェアテスト（ブラックボックステスト入門）　- ディノオープンラボラトリ

ソフトウェアテストの社内勉強会資料を公開しているサイト。ブラックボックステストの「同値分割」「境界値分析」「デシジョンテーブル」「原因結果グラフ」についてのPDFが閲覧できます。pukiwikiの更新画面の原因結果グラフ、僕もためしにやってみました。僕はぱぱっとできないから、4テストケース7テストケースに落ち着くのに少し時間がかかりました。。。汗。続きが楽しみ～。

2008/02/05追記:

ちなみに、実際にやってみた感じの画像を貼る予定。（お昼過ぎに作成して一旦アップしたのですが、検算で間違い見つけたので、またやり直し～）

ソフトウェア・テストPRESS #5 - 技法道場をCEGで考えてみる練習

ココログフリーのメンテ終わったー。

==

今回のテストPRESSはおかずが多いですね。マインドマップのテスト本のフォロー記事や、「テスト計画の立て方、書き方、進め方」とか、テストツールとか、チームの話とか。

その中で、池田さん＆鈴木さんの技法道場が連載化したようです。今回はくす玉マシンを題材に、状態遷移図→シナリオを作成する手順を詳しく紹介しています。少し強引ですが、原因結果グラフで解いてみようと思い、少し考えてみました。この場合、残された1枚のメモだけが仕様であり、こんな感じ。

くす玉マシンは、くす玉の昇降とくす玉を開封する機能を提供する

くす玉が下がっている状態でコントローラの「くす玉ボタン」を押すとくす玉が上がる

くす玉が上がっている状態でコントローラの「くす玉ボタン」を押すとくす玉が開く

くす玉が上がっている状態、かつ、くす玉が開いている状態でコントローラの「くす玉ボタン」を押すとくす玉が下がる

くす玉の昇降中、コントローラの「くす玉ボタン」と「電源ボタン」は無効

開いているくす玉は人が閉める必要がある（自動で閉じる機能はない）

電源ボタンはくす玉が止まっているときに有効

電源が入っている状態で「電源ボタン」を押すと、くす玉が割れていなくても、割れていても下に降りる

くす玉が降りている状態で「電源ボタン」を押すと、電源が切れる

電源が入っていない状態で「電源ボタン」を押すと、くす玉が下がっている状態とする

原因ノードはこんな感じかなあ。

結果はこんな感じ。「そのまま」という結果ノードも作ってみた。

んで、原因結果グラフを作っていたが、全てをまとめるのが難しかったので、各結果ノードに対する原因ノードの関係、というくくりで作ってみた。制約とかの表示は割愛しちゃいましたが。

中間ノードが31～34まで出現したが、31＝くす玉が昇降中、って感じだが、それ以外の名前がイマイチつけられない。（それって中間ノードとして怪しいのかも。。。）今日はこの辺で。けっこうエイヤーで考えたから、あとできちんと見直して、そしてデシジョンテーブルに落とし込むかな。

どんな単体テストをしますか？ - for文のホワイトボックステスト その２

ずいぶん、亀自己レス。

==

for文を含むプログラムでは具体的にどうやってホワイトボックス的アプローチをするのか。ループする回数を同値分解するのはどうだろうか。0回、1回、無限回（実際に無限回はありえないので一般的な大数か）とか。んで、今回のソースはmonthという入力条件があるので、

month=0のとき（for文を経由しない、monthパラメータの無効クラス）

month=1のとき（for文を1度経由する、monthパラメータの有効クラス）

month=13のとき（for文を複数回経由するが、monthパラメータの無効クラス）

の3条件は少なくともチェックしたい。まあ、こうもいかないループもありそうだけど。。。

==
2007/06/17追記。
よく考えたら、month=12のがいいな。そうすればループ内のswitch文でcase 1～case 12までを経由できるし。

どんな単体テストをしますか？その５

家から確認作業、夜は長いぞ。

==

どんな単体テストをしますか？その４の原因結果グラフを修正。

この分岐はいたってシンプルなので、こう眺めてみると原因結果グラフを明記しなくても、デシジョンテーブルに落とし込むことはできそだな。少し余裕が出たときにサンプルの関数全体をホワイトボックステストで設計するのと、グレーボックステストで設計するのをやるかな。グレーボックステストは今までのまとめっぽいけど。

==

例のMC/DCについて。まだ読み中。

引用：NASA/TM-2001210-876, A Practical Tutorial on Modified Condition/Decision Coverage

MC/DCというカバレッジ基準は図にあるように比較的高レベルなカバレッジ基準といえる。他の資料には、高信頼性を求めるシステム、リアルタイム性が求められる組込み系ソフトウェアなどで使われるらしく、この引用元も米国の航空・宇宙関連システムにおける資料のようだ。ただし、「ここの条件が独立して結果に影響を及ぼす」ことを示すためのカバレッジという点では、原因結果グラフでの網羅を意識した設計が、とても似ていると感じた。（n個のAND条件では、n+1回の条件、など）

もう少し読み込んでみようっと。

どんな単体テストをしますか？その４

「どんな単体テストをしますか？その３」の続き。

関連記事はこちら。コメント欄にも目を通すと理解が進むかも。

どんな単体テストをしますか？

どんな単体テストをしますか？その２

どんな単体テストをしますか？その３

ホワイトボックステストの視点で、daycount関数（年月日を指定して、元旦からの日数をカウントする関数）を単体テスト設計してみるのだが、テスト設計は「なるべく少ないコストで」という意識ですすめるほうがいい。ということで、今回は原因結果グラフから導いたデシジョンテーブルで、テストケースを洗い出してみる。全部やるのは後にして、まずは最初の、

この部分。この分岐に関して、原因結果グラフを作成すると、こんな感じ。

これをデシジョンテーブルに落とし込むのだが、まずは３つの中間ノードについてデシジョンテーブルを作成する。３つともEXC制約を考慮して、こんな感じ。

そして、全体のデシジョンテーブルはこんな感じで。

この３つのデシジョンテーブルを結合すると、テストケース数は７つ。

作ってみて、ブラックボックステストの視点でテストケースを洗い出したときも原因結果グラフを使っているので、似ている。違う点は、コーディングの構成を知っているので、「0」や「-1」などの特異値については考慮されない点だ。

さて、この調子で関数全体のテストケースを作る。が、それはまた今度。MC/DCについても今度調べて記事にするか。

JaSST資料にあるカバレッジ表に近づいている？

ブログのデザインを変更したらコメントできなくなってしまった。。。ので記事としてアップ。

==

前の記事でコメントがあったとおり、#2は不要となる。それを確認するためにチェックリストをくっつけてみた。

論理展開式をどのテストケースがカバーしているかをチェックしてみた。なんだか、JaSSTの原因結果グラフのところのカバレッジ表に似てきた気もするが、気にしなーい。＾＾

#2がカバーしている論理展開式は他のテストケースによってカバーされていることがわかる。が、同時に#1でも同じことが言えるように見える。ただし、違うところは、もし#1をテストケースに含めないとすると、（年俸1000万円以上、セ・リーグ所属）＝（T、F）という論理展開式のカバー数が1になってしまう点だ。（#2をテストケースに含めない場合はそういったことはない）

どちらをテストケースに含めない、としてもいいが、#2のほうがベター、といったところか。かな。

デシジョンテーブルの結合をマトリックスにしてみる

とことん勉強してやる。

==

原因結果グラフの局所的なデシジョンテーブルを結合するときの手順はこんな感じで行っている。原因は僕が適当に考えたもの。

まずは下位にあるデシジョンテーブルを作成しておく。この図でいうと、中間ノード①についてはT＝1通り、F＝3通り。中間ノード②についてはT＝2通り、F＝1通り。次にそれら中間ノード（①と②）を条件とするデシジョンテーブルを作成する。結果はT、F、Fの3通り。それぞれについて中間ノード①と中間ノード②の真理値で、多い方の組み合わせ数を採用する。これは論理展開式を網羅するため。例えば、①＝T、②＝Tの場合、2通りとなり、①＝F、②＝Tの場合、3通りとなるわけだ。そうすると自然と網羅しながら最終的なデシジョンテーブルを作成できる。

と、僕は認識している。

ここで、#3～#5の「年俸1000万円以上」「セ・リーグ所属」の真理値の組み合わせは、別の組み合わせもある。必要なのは中間ノード②のデシジョンテーブルを網羅しているかどうか。

※JaSST'07のパネルセッションにあった原因結果グラフの資料（PDFファイル）を参考にマトリックスを作ってみた。

【改^2】原因結果グラフ デシジョンテーブル作成

原因結果グラフからデシジョンテーブルを作成する、の巻。その３。

==

（１）　原因と結果の洗い出し
（２）　原因結果グラフ作成
（３）　原因結果グラフ修正

では、まずは前回作成したグラフは以下のとおり。

煩雑さをなくすために原因にあたる６つの条件を①～⑥とする。

途中の手順は何度も書いているので省略しちゃう。受信に関するデシジョンテーブルと一時拒否に関するデシジョンテーブルはこれ。

んで、何度も直している拒否に関するデシジョンテーブルは以下のとおり、中間ノードaを中継して作成。

最後にそれらを結合し、

同一のテストケースや集約できるものは集約するとこんな感じ。

#2について

　#9に集約される。

#6について

　#5に集約される。

#7について

　#1と同一なので省略。

#10について

　#3と同一なので省略。

#11について

　#4と同一なので省略。

３度目の正直。これであってる、、、はず。
正直言うと、中間ノードaに関するデシジョンテーブルと拒否に関するデシジョンテーブルを合成するロジックがまだ納得度50%くらい。（⑥、a）＝（F、T）の割り付け方が他にもあるんだけれど、なぜこれでいいのか。。。
マイヤーズの本に沿ったやり方だと、やはりテストケースも違うものになるのだろうか。。。

【改】原因結果グラフ デシジョンテーブル作成

原因結果グラフ　デシジョンテーブル作成はコメントで指摘されたように間違ってるところがあって、また作り直してみました。
#2007/03/17 コメントをいただいたので修正アゲイン！
#2007/03/17 再チャレンジでも正解にたどりつけてないので、整理してからリベンジ予定～

==

（１）　原因と結果の洗い出し
（２）　原因結果グラフ作成
（３）　原因結果グラフ修正

では、まずは前回作成したグラフは以下のとおり。

煩雑さをなくすために原因にあたる６つの条件を①～⑥とする。
１つ目の結果「正常に受信される」について。

これを成立させるためには、

　①、かつ、not④、かつ、not⑤、かつ、not⑥

となるので、ここの局所的なデシジョンテーブルは、

という５つのテストケースになる。AND条件のデシジョンテーブル作成方法は後ほど記事にしたいな。

２つ目の結果は「メールが一時拒否される」について。

これは単純である。

３つ目の結果は「メールが拒否される」についてだが、これは中間ノードaがある。

ここでの局所的なデシジョンテーブルは

　②、または、③、または、④、または、⑤
　中間ノードa、かつ、not⑥

という満足条件なので、

#2007/03/17 画像差し替えしました。

この２つを結合してみる。

#2007/0/17 画像追加しました。

最後にこれらすべてのデシジョンテーブルを結合するとこんな感じ。になると思う。

ここでテストケースの集約をしてみる。まずは、5列目と7列目はまったく同じなので、7列目を削除。3列目と10列目、4列目と11列目も同様に削除できる。また、6列目は5列目に吸収でき、2列目は8列目と9列目と同等となる。（制約Oがあるため）
#2007/03/17 コメントを修正します。

2列目

8列目と9列目と同値（制約O）なので削除

6列目

5列目と同値なので削除

7列目

1列目と同値なので削除

10列目と11列目

それぞれ3列目、4列目と同値なので削除

さあ、見やすくしてみるとこんな感じのデシジョンテーブルが完成する。

#2007/03/17 画像を差し替えました。中間ノードについても記載。

なんか、チョーそれっぽいテーブル♪あってるかなあ。
そういえば、中間ノード名つけるの忘れちゃった～

原因結果グラフ デシジョンテーブル作成

#2007/03/12 コメントにあるとおり一部デシジョンテーブルに誤りがありますのであとで修正しますー。
#2007/03/16 【改】原因結果グラフ　デシジョンテーブル作成で再度チャレンジしてみました！

==

さて、自分で問題を作ってデシジョンテーブルまで作成する、という勉強も架橋に。

（１）　原因と結果の洗い出し
（２）　原因結果グラフ作成
（３）　原因結果グラフ修正

今回はこのグラフからデシジョンテーブルを作成してみる。ただし、2点だけカンニングポイント。

テストケースは6個

一部なぜそうなるのかをまだ解決できていない

では、まずは前回作成したグラフは以下のとおり。

煩雑さをなくすために原因にあたる６つの条件を①～⑥とする。
１つ目の結果「正常に受信される」について。

これを成立させるためには、

　①、かつ、not④、かつ、not⑤、かつ、not⑥

となるので、ここの局所的なデシジョンテーブルは、

という５つのテストケースになる。ただし、条件の割り付け方はこちらを参照させてもらいましたが、なぜそうなるのかはいまいち理解不足。もう少し勉強を進めないと。

２つ目の結果は「メールが一時拒否される」について。

これは単純である。

３つ目の結果は「メールが拒否される」についてだが、これは中間ノードaがあるので、まずはそちらに注目する。

ここでの局所的なデシジョンテーブルは

　②、または、③、または、④、または、⑤

という満足条件なので、

となる。ここでいくつか考慮する点がある。まずは、制約Oが①と②と③の間に存在すること。②と③が確定しているのなら①も確定する。

また、残り２つのテストケースについては制約上ありえないケース（禁則）になる。したがってデシジョンテーブルは前半3つだけが残る。

では今度は、中間ノードaと⑥について考えてみる。

ここでは、

　中間ノードa、かつ、not⑥

なので局所的なデシジョンテーブルはこんな感じ。

このテーブルに先の中間ノードを結果に持つデシジョンテーブルを埋め込むとこうなる。

こうなると、あとは不要なテストケースを削除していけばいい。下記の灰色のテストケースが不要。

すっきりさせれば出来上がり。

==

僕はこれであってると思っているんだが。。。検算の仕方ってあるのかな。