あらためて境界値テストを勉強

今日の勉強会で「境界値テスト/境界値分析」について話題に上がったので、家に帰ってから少し復習。テキストはバイザーのブラックボックステスト本。

実践的プログラムテスト入門―ソフトウェアのブラックボックステスト ボーリス バイザー, Boris Beizer, 小野間 彰, 石原 成夫, 山浦 恒央 発売日 : 1997/08 出版社/メーカー : 日経BP社

一般的にバグが境界・端っこに多くあることから、入力や出力を同値分割してそれらの境界・境界の近くを狙ってテストするが、それを「境界値テスト」「境界値分析」と呼んでいる。

バグパターン

話を簡単にするために1次元の数直線を考える（多次元はドメイン分析テスト）。X＜20をドメインB、X≧20をドメインAとした場合、以下のようなバグパターンがある。

	分類	イメージ	テストすべきポイント
1	閉包バグ（closure bug）		ONポイント
2	右への境界移動（boundary shifted right）		ONポイント
3	左への境界移動（boundary shifted left）		OFFポイント
4	境界抜け（missing boundary）		ONポイント、OFFポイント
5	余分な境界（extra boundary）		ONポイント、OFFポイント INポイント、OUTポイント

バグの原因

パターン1は、閉集合・開集合の実装を間違えた場合であり、不等号のつけ間違いなど。パターン2と3は、境界となる値自体を実装間違えした場合。パターン4は、実装者にとっては未知の境界であり、仕様が曖昧な場合に生じる。パターン5は、存在しない境界を作りこんでしまった場合。いずれも単純なプログラムミスもあるが、仕様の見落とし・解釈誤り・曖昧さが原因となることもある。このあたりは、単体テストレベルのテスト分析でつぶしておきたい。

パターン5のために、INポイントやOUTポイントは近傍を選ぶよりは離れたところを選ぶべきなのかな。

--
# パターン5が誤りでしたので、訂正。あきやまさんありがとうございますm(_ _)m

JaSST'11 Niigata に参加

2/18 は新潟市万代島ビルで開催された「JaSST'11 Niigata」に参加してきました。テーマは品質ですが、プロダクトの品質ではなく、品質を作る「体質」改善というテーマでしたので、とても興味深い内容ばかりでした。

JaSST（ソフトウェアテストシンポジウム）は東京以外にも各地域で開催されていて、今回ははじめて新潟・日本海側での開催。今年は他にもいくつかの都市でプチJaSSTが開催されるとのうわさです（巡業？！）。

内容については後日メディアスポンサー「WACATE-Magazine」から記事としてアップされることでしょう。

[書籍]ソフトウェアテスト技法ドリル -立体で捉える- その2

試しに、直交表に割りつけてみた。

「今、食べたいラーメン」
腹が減りました。とてもラーメンが食べたいです。でも、どんなラーメンでもいいわけではありません。以下の条件を参考に、食べたいラーメンになるように原因結果グラフを作成してください。

味はしょうゆか塩か味噌のいずれかが良い。普通の胃袋なので1 杯で十分です。

昨日はステーキを食べたので、こってりではないほうが良い。

しょうゆか塩の場合は、とんこつベースが良い。

味噌の場合は野菜がたっぷり入っているものが良い。

トッピングは絶対に付けたい。金に糸目はつけないので味玉、刻み玉ねぎ、焼き海苔の中から最低１つは付けたい。

16番目の組合せだけが説明文通りの「食べたいラーメン」だけど、他の15通りで「食べたいラーメン」があるかもしれないー。

[書籍]ソフトウェアテスト技法ドリル -立体で捉える-

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 秋山 浩一 発売日 : 2010/10 出版社/メーカー : 日科技連出版社

HAYST法も、デシジョンテーブルや原因結果グラフ、CFD法なども、どちらも組合せテストの一種ととらえることができますが、目的が違います。HAYST法は、関係ないだろうと思われる組合せに潜むバグを見つけるのが目的。デシジョンテーブルや、原因結果グラフ、CFD法は、関係性そのものが仕様書通りかどうかを確認するのが目的。デバッグ工学研究所の松尾谷先生はこれらを「無則」「有則」という言葉で表現しています。

有則とは、動作が定義された入力条件の組。定義されているので、テスト空間も限定されたり、閉じたりしている。これらの組合せを効率的・網羅的に洗い出す技法が、デシジョンテーブル、原因結果グラフ、CFD法といえる。

無則とは、何も影響を及ぼさない入力条件の組。数学的な用語に当てはめると「直交」と言い換えてもいい。この無則に該当するテスト空間は、広大で閉じていないため、万が一バグ（実は影響を及ぼす入力条件の組）がある場合、見つけることがなかなかしんどい。このバグを出現させる入力条件の組を限られた時間で見つけようとする技法が、直交表やペアワイズ（All-Pair）法、HAYST法である。

また、禁則というのは、動作が禁止された入力条件の組合せであり、原因結果グラフでいえば制約と重なる部分ともいえる（禁則⊂制約？）。「微則」という言葉もあるらしいが、どういう意味なのだろうか。。。

==

と、第4章については一旦ここで中断。
先日、この本の勉強会の第3回目が開催されたのだが、そこで出題された原因結果グラフの演習問題が以下の問題。

「今、食べたいラーメン」
腹が減りました。とてもラーメンが食べたいです。でも、どんなラーメンでもいいわけではありません。以下の条件を参考に、食べたいラーメンになるように原因結果グラフを作成してください。

味はしょうゆか塩か味噌のいずれかが良い。普通の胃袋なので1 杯で十分です。

昨日はステーキを食べたので、こってりではないほうが良い。

しょうゆか塩の場合は、とんこつベースが良い。

味噌の場合は野菜がたっぷり入っているものが良い。

トッピングは絶対に付けたい。金に糸目はつけないので味玉、刻み玉ねぎ、焼き海苔の中から最低１つは付けたい。

僕が作った原因結果グラフとデシジョンテーブルはこちら（勉強会の時は「一杯」がなかったので追加）。

最初は、トッピングにONE制約をつけていましたが、「最低一つ」だったのでつけるならINCL制約のが適切。でもそうすると、かならず「トッピングあり」が真になってしまって、個人的には気に入らなかったので、制約を外して、トッピングがない場合も出現するようにした。（制約をつける目的は、テスト条件を減らすことであり、実際にINCL制約をつけると列が減ります。）

でもでも、本当にこれでいいのだろうか？トッピング2個の組合せで、実は嫌いなパターンがあるかもしれない。とんこつベースのしょうゆ味なら、こってりが合うのかもしれない。他にもテストしたくなる。これは、原因結果グラフが食べたいラーメンの説明文の「有則」部分を網羅しているだけで、説明文には見えてこない関係性が気になるということになるだろう。「無則」部分に隠れた定義があるように感じる。

なので、「有則」を確認する組合せとともに、ここで「無則」に関するテスト設計が必要になってくる。HAYST法をここで適用するのは、単に「無則」を組み合わせるだけではなく、隠れた因子を見つけることにもつながる。勉強会に参加された方も、ぜひ同じ問題を、今度はHAYST法で分析してほしい～。

ということで、次回はこの問題をドリル本に沿った手順でテスト設計していきたいと思います。まずは、テスト対象の因子・水準の整理をしまーす。

# んー、自分が作った直交表割付ツールが見当たらない。。。

原因結果グラフの演習でコツをつかもう

先日2/7に、TEF主催の第3回「ソフトウェアテスト技法ドリル」勉強会がありました。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 秋山 浩一 発売日 : 2010/10 出版社/メーカー : 日科技連出版社

勉強会は「原因結果グラフ」をテーマにして、講義と演習の2時間でした。2年前に同じようにTEF主催で原因結果グラフ＆デシジョンテーブル勉強会をしたときは、講義と演習を用意して全4回（のべ8時間）とかなりヘビーなものでした。ということで、今回はテキストであるドリル本と予習問題を用意して、事前に参加者に学習をしてもらってかなり時間短縮できました。

でも、参加者によってはついていけなかったり、会場ででてきた質問もあまり理解できなかった、といった声も少し聞かれました。ということで、2年前の勉強会で扱った例題・演習問題・宿題をまとめて、参加者の理解度に応じて解いていけるようなページを作ろうと思いました。（アイデアは秋山浩一さん）

原因結果グラフの演習

今のところ、問題数は18問。半分の9問については、解答例を付けました。あとで自分なりの解説も付けようかとは思っていますが、鈴木三紀夫さんが解説ページをつくるかも？！

たまゆら雑記

# このブログタイトルは、テスト技法を勉強している人には有名ですよね。デシジョンテーブルを勉強すると、この名前の旧ブログにたどり着きますから！

ということで、完成までは今しばらくお待ちくださいm(_ _)m

JaSST'11 Tokyo にて「CEGTest」を使って発表してきました。

マイコミジャーナルに記事として取り上げていただきました。

【レポート】「CEGTest」開発者が語る、原因結果グラフ技法の応用テクニック - JaSST

1月25-26日、東京都目黒区の目黒雅叙園にてソフトウェアテストをテーマにした技術カンファレンス「JaSST(Japan Symposium on Software Test) 2011」が開催された。ここでは、25日の午後に行われたニフティ 加瀬正樹 ...... Read more

この場を借りて、発想やアドバイスをいただいた秋山さん、にしさんに御礼したいと思います。

原因結果グラフは、基本的にはツリー構造になっていて、その枝分かれしている中間ノードに着目すると、分割（partitioning）やズームアウトができる、というのが今回の論文の発想です。規模に応じてテスト対象を分割する手法はにしさんのスライドなどによく登場しますし、秋山さんのソフトウェアテストHAYST法入門ではズームインとともにズームアウトが紹介されています。今回、明確な定義を与えて、原因結果グラフを分割し、どんな効果があるかなどを考察しました。考え方自体は、原因結果グラフに特化したものではないので、もう少し考えてみたい。

分割可能点の多い少ないでグラフの複雑度が数値化できるかなあ。

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方 吉澤 正孝/秋山浩一/仙石太郎