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状態のマス目対応の実装

検算の実装

Don't write redundant tests, and don't write too few tests. - テストは無駄なく漏れなく

昨日は社内では改正される特電法のお勉強会。社外ではWeb自動テストツールのお勉強会。

==

TotT: Too Many Tests by Google Testing Blog

単純な処理を例に挙げて、「テストケースが非常に多いこと」の考察をしている。int型の単純なべき数（＝2^32のパラメータ数分のべき）では、多すぎる。条件分岐がTrueの場合とFalseの場合の2通り（100%ステートメントカバレッジ）は、少なすぎる。境界値と同値クラスを考慮した場合も、少し多そう。最後は、条件分岐（OR条件）がTrueになる場合（＝3通り）とFalseになる場合（＝1通り）を考え、そのサブ処理で各2通りを考えた10通り。

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

方針転換。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にするみたい。

==

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

などと考えてみる。

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

[例題]同値分割・境界値分析観点でテスト設計する

携帯の充電池が膨らんじゃって、ドコモショップに持っていったら、無料交換してくれた！やった！

==

初心にもどって、同値分割、同値クラスを調べてみる。

同値分割とは、入力データを「同じ出力結果が得られるグループ」に分割することをいいます。このグループのことを「同値クラス」と言います。また、正常処理を行う同値クラスを「有効同値クラス」と言い、エラー処理を行う同値クラスを「無効同値クラス」と言います。

同値分割とは何か？ - たまゆら雑記

起こりうるすべての事象をいくつかのグループに分け、各グループから 代表値を選ぶ方法です。 このグループを「同値クラス」といい、同様の出力結果が得られる 入力値の集合です。 ・境界値分析 同値クラスの境界値付近を入力値として選んでテストする方法です。

同値分割、境界値分析

同値分割（equivalence partition）：　仕様上、コンポーネントやシステムの動作が同じと見なせる入力定義域や出力定義域の部分。

JSTQB ソフトウェアテスト標準用語集 日本語版Ver 1.1 PDFファイル

事象をグループ分けして代表元のみテストを実施する。なのでグループ分けは結果が同じになるような入力集合になる。電源ボタン、リセットボタンについては、すでに単機能テストで結果について網羅できそうなので、ここではポイント（上）ボタンについて考えてみる。ポイント（上）ボタンを押すことでスコアボードはどんな結果を生じるか。

上のプレイヤーのポイントが１５増える

上のプレイヤーのポイントが１０増える

上のプレイヤーのポイントが１増える　※タイブレーク時

上のプレイヤー側のアドバンテージ表示となる

DEUCE表示となる

上のプレイヤーの勝利でゲームが終了する（ポイント欄がリセットされる）

これら6つの同値クラスが考えられるため、各同値クラスの代表元を選択して、テストケースとする。

ポイント（下）ボタンについては上下を逆にしたテストケースを考えればよい。番号B-01-03がテストしにくいな。

[例題]単機能テストを設計する

1. [例題]テニスのスコアボード
2. [例題]分析する　- 3色ボールペン版
3. [例題]分析する　- マインドマップ版

仕様分析からテスト設計へ。まずは、単機能テストの設計をしてみる。
・・・
・・・
ふと、単機能テストを検索してみると、けっこう「単機能テスト＝単体テスト、コンポーネントテスト」という記述があったりする。単なる用語の使い方の違い、という考え方もあるけれど、僕の認識では、単機能テストと単体テストは違うテストと思う。単体テストの目的は、「関数・メソッドといった”システムの一部”が正しく実装されているか」であり、やり方によっては組み合わせテストも含まれるし、主にホワイトボックステスト（あるいはグレーボックステスト）で設計されることが多い。一方、単機能テストの目的は「機能が単独で正しい動作をするかどうか」であり、組み合わせテストを含まず、実行結果が注目されるテスト。ブラックボックス的。

# 当然、後者の意味で「単体テスト」と表現する場合もありました。

などと思いをめぐらしながら、例題の単機能テストへ。

1. 電源ボタン

仕様をみてみると、

電源の切り替えができるかどうかが単機能テストであろう。


2. リセットボタン

仕様より、

電源ONの状態で、画面がリセットされるかどうかが単機能テスト。


3. ポイント（上）ボタン

ポイントボタンは仕様がやや複雑であるが、ここではもっとも基本的な動作である、電源ONの状態で、上のプレイヤーのPOINTSが追加されるかどうかを単機能テストとする。GAMESおよびSETSへの反映パターンはここでは考慮しない。という方針。


4. ポイント（下）ボタン

ポイント（上）ボタンと同様。

こんな感じ。このスコアボードはボタンが4つしかなく、減点機能がないため、これらのテストケースの実施順序は最終的に変更する予定。

[例題]分析する - マインドマップ版

例題を作って、テスト設計をしてみる。

[例題]テニスのスコアボード

[例題]分析する　- 3色ボールペン版

==

マインドマップから始めるソフトウェアテストでは、仕様分析～テスト計画～テスト設計～といった流れで、マインドマップをツールとして利用している。ここでは仕様分析＋アプローチといったニュアンスでマインドマップを使ってみた。各メインブランチにふれてみると、

単機能テスト

ここでは、ボタンを押すと仕様どおり（電源が切り替わったり、ポイントが増えたり）動作することを確認すること。スモークテスト的なテストでもいいかも。

同値・境界値テスト

ポイント数、ゲーム数、セット数。ゲームが終わるとき、セットが終わるとき、試合が終わるとき。表示の桁数などなど。

状態遷移テスト

業務シナリオテストに近いイメージ。実際の試合を想定した利用。効果的、効率的なテストを目指す。

組み合わせテスト

この状況でこのボタンを押したら、こうなる。

テストしない

ソフトウェアテストの例題なので、外部環境はできないですね。あと、数字がちゃんと表示されるか。とか。

テニスのルール

スコアのつけかたって、意外に複雑なのだよ。15ずつ増えたり、増えなかったり。タイブレークがあったり、なかったり。

こういうのって数をこなしていくことも重要なのかな。ここ何日かは通勤バスの中でテキストを読んで復習してます。

原因結果グラフを解剖 - 制約記号

原因結果グラフを解剖 - AND/ORなど

引き続き、制約条件を表すグラフをチェック。制約とはありえない組合せを表現するための表記で、ソフトウェアテストではとても重要。

EXCLUSIVE OR（EXC、排他的）

排他的EXCは、原因ノードのうち「T」になれるのはひとつだけ。「NHKを見るか、フジテレビを見るか、それともテレビを見ないか」。

INCLUDE（INC、包含）

包含INCは、原因ノードのうち、少なくともどれかが「T」でなければならない。「自動販売機の、コーヒーを押そうか、お茶を押そうか、それとも両方押しちゃおうか」。

ONE（ONE、一方のみ）

ONE制約は、原因ノードのうち、どれかひとつだけが「T」でなければならない。「じゃんけんの結果は、勝ちか、負けか、あるいはあいこ」。

REQUIRE（REQ、必要）

REQ制約は、原因ノードが「T」ならば、かならず結果も「T」にならなければならない。「充電がなくなれば、携帯電話はつながらない」。ちょっと違うか。

この他にも、隠蔽（M）があるらしいのだが、お目にかかったことがない。どういうときに使う制約なんだろう。

原因結果グラフを解剖 - AND/ORなど

NHKクローズアップ現代でソフトウェア品質のプログラムがこの前やってた。見逃した。

「ソフトウエア危機　～誤作動相次ぐハイテク製品～」

ブログで少し検索したので、リストアップ。

ソフトウェアの欠陥はなぜ無くならないのか

NHKクローズアップ現代 ソフトウェア危機

==

原因結果グラフのテーブル作成をツール化する前に、基礎的なことを復習・まとめてみる。小さなテーブル作成をしているうちに何かいいことが気づけるかなあと。手持ち資料で原因結果グラフを勉強するとなると、マイヤーズ本くらいしかないが、わかりにくい表現が多い。自分なりの言葉でまとめてみる。

IDENTITY(同値)

原因が「T」なら、結果も「T」。原因が「F」なら、結果も「F」。原因と結果が同値な状態をさしていて、デシジョンテーブルも非常にシンプル。

これは中間ノードが入ってもデシジョンテーブルは同じ。

NOT(否定)

原因が「T」なら、結果は「F」。原因が「F」なら、結果は「T」。原因と結果の関係が逆になるケース。

AND(積)

原因が2ノード以上関係して、さらにその論理積で結果を決定するケース。「身長が高くて、学歴が高くて、高収入なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列（結果が「T」＝１、「F」＝３）となる。

単純に考えてみると、原因（真／偽）が3つあるので、全数では2^3＝8列になるはずである。しかし、原因の複数項目が「F」だと、どの原因が結果を決定しているかが判断できない。つまりは、#2、#3、#4の3列は、それぞれノード11、ノード12、ノード13が結果を「F」にする原因となっていることを確認することが目的であるため、下図#5のようなテストケースは適当ではないのだ。これは経路感光（path sensitizing）というそうです。

OR(和)

原因が2ノード以上関係して、さらにその論理和で結果を決定するケース。「医者か、弁護士か、あるいはIT長者なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列（結果が「F」＝１、「T」＝３）となる。

ORとANDは表裏の関係なのがポイント。高校のときに習った、ド・モルガンを思い出せ。

さーて、続きはまた今度。次は制約記号だな＞EXC、ONE、INCなどなど

[例題]分析する - 3色ボールペン版

[例題]テニスのスコアボードのテストをしてみるのだが、まずテスト対象の分析をしてみる。分析をしてどんなテスト設計をするのか、テスト技法を使うのか、などなどを検討する。今回は、ソフトウェアテストPRESS Vol.2　「3色ボールペンで読む仕様書」にならってやってみようかな。

1. 赤　－　客観的に見て、最も重要な箇所
今回は、同値分割や境界値などに使えそうな箇所もあげてみた。
2. 青　－　客観的に見て、まあ重要な箇所
実は微妙に青色って難しい。。。
3. 緑　－　主観的に見て、おかしいと感じた箇所
おかしいというか仕様があいまいであったり、矛盾がある箇所としてみた。

次回はマインドマップを分析ツールとして使ってみる。予定。

[例題]テニスのスコアボード

原因結果グラフをデシジョンテーブルにするツールを作ったら、理解が進むかなあ。

==

テスト設計の例題。自分で出して、自分で考える。

テニスのスコアボードのテスト

1. 電源でON/OFF切り替え
2. 電源をONにすると初期状態で起動
3. 電源OFF状態ではどのボタンも無効
4. リセットを押すと初期状態
5. ポイント（上）を押すと上のプレイヤーにポイント
6. ポイント（下）を押すと下のプレーヤーにポイント
7. デュースは「40-40」と表示
8. アドバンテージはリード側に「AD」と表示し、反対側は無表示
9. ゲーム終了時に「0-0」に戻る
10. 5セットマッチ、最終セット以外はタイブレーク
11. 3セット取った状態でポイントを押すと初期状態
12. ポイント減点機能はない
13. 2つ以上のボタンを押したら、後から押したボタンは無効
14. 2つ以上のボタンを同時に押したら、1ボタンだけが有効で、優先順位は、電源＞リセットボタン＞ポイント（上）＞ポイント（下）

まずは、3色ボールペンとかで仕様チェーック、かな。

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

[サイト]ソフトウェアテスト、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追記:

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

[ツール]TestLink - フリーのテスト管理ツール

SQuBOKガイド読み中。お風呂で。

==

昨年、TEF有志による日本語化プロジェクトが発足し、今ではばりばり日本語で利用できるようになったのが、このテスト管理ツール「TestLink」（2008年2月2日現在で、1.7.3版が安定版）。少し休みの日を使って、自分のPCに載せてみたりした。

引用：TEF有志によるTestLink日本語化プロジェクトより

特徴としては、

簡単な導入手順（WindowsでもLinuxでも可）

テストプロジェクト、テスト計画、テストスイート、テストケースの管理支援

テストケースのデータ蓄積、再利用

テストドキュメント生成支援（ノーマルからWord/Excel、メールなど）

などがあげられ、リーダもマネジャーもプログラマもQAも一度は手にとって試してみたいツール。ソースからインポートファイルへの変換ツールが作成されたり、活動的なプロジェクトなのもよいですね。今後はSeleniumとの連携なども予定されているようですし、コードレビューやテストケースレビューなどへの応用など、興味深いプロジェクトです。

C言語の単体テスト、いろいろ

ある意味、餃子ブームだ。

==

メールサーバってCだから、C向けのテスト手法はいろいろと調べたりすることが多いし、自分でツールを作ったりします。せっかく調べたので、C言語をターゲットとした単体テスト/ユニットテストツールを枚挙してみる。

CUnit

http://sourceforge.net/projects/cunit/によるユニットテストフレームワーク。出力に「__FILE__」「__LINE__」を記載して、分析しやすく結果を表現する。XML出力モード（Automatedモード）で実行し、DTDとXSLスタイルシートによって、統計情報が見やすくなる。

CUnit for Mr.Ando

安藤利和さんによる「言語技術者のC言語技術者によるC言語技術者のための C言語テスティングフレームワーク」。ソースはhttp://sourceforge.jp/projects/cunitforando/から入手。関数のスタブ生成でテストを実行していく。ドキュメントには使い方のほかに、単体テストの原理などの記事も。

CCUnit

Cのユニットテストツールはネーミングが特徴的なものが多い。CCUnitは「繰り返し可能なテストを書くため」のフレームワーク。CCUnit クックブックが、適用への近道か。ソースは、こちらから入手。

CuTest

ネーミングは、「C Unit Testing Framework」。このキュートなテストプログラムは、make-tests.shによって生成される。ソースはこちら。

Cutter

マニュアルが充実している。テスト実行の進捗状況を「.」「F」を並べて見やすくしている。その他、テスト結果詳細として、テストケース数、テストパス数、テスト失敗数、テスト異常終了数、テスト保留数などがわかる。ソースはこちらから。

MinUnit

3行だけのユニットテスト。「a minimal unit testing framework for C」は、個人的にはライトで小気味よく、重宝してます。

--

リファレンスやチュートリアルが充実しているのですが、より実践的な例があるといいなーなんて思ってたりして。こういったツールの活用と効果的なテスト設計によって、結合テスト・システムテスト、あるいは静的テストの負荷軽減を図っていこう。