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回の条件、など）

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