特集記事：組み合わせテストをオールペア法でスピーディに！

perl少し覚えた。

==

技術評論社のサイトに組み合わせテストをオールペア法（ＰＩＣＴ）で試す、という記事が掲載されています。なかなか時間が取れなくて読めていないですが、ＰＩＣＴ初心者としてはありがたい特集です！

特集：組み合わせテストをオールペア法でスピーディに！

1. 第1回　組み合わせテストの技法


2. 第2回　PICTの基本的な使い方

もう少しきちんと読めたら、記事書こうっとー。

禁則は回避しないとテストできないのだ

カップスターのギザギザはうそ。

==

さてさて、禁則って実際考慮しないとどうなるんだろうか。

サーバーのポート番号/暗号化の指定について考えてみる。わかりやすくするためチェックボックスだけに注目すると、

1. POP over SSLのチェックボックス


2. SMTP over SSLのチェックボックス


3. POPにおけるSSL2.0のチェックボックス


4. POPにおけるSTARTTLSのチェックボックス


5. SSL接続で、証明書の検証をしないチェックボックス


6. SMTPにおけるSSL2.0のチェックボックス


7. SMTPにおけるSTARTTLSのチェックボックス

2水準因子が7個でちょうどL8直交表が使えるので、素直に割り付けてみる。そうすると、

このように禁則によってテストケース2,3,4,5,6はありえない条件となってしまう。すなわち、このままの状態でテストを実施しても組合せ網羅率は上がらないのだ。HAYST法はこの禁則回避について言及しており、その打開策として、

相互排他因子融合手法

多層化手法

可変因子手法

詳しくはこの教科書に載っているが、今後ここで解説していければいいな。

禁則を勉強して、実践へ その６

今日はフェデラー決勝戦の再放送だ！！

==

禁則を勉強して、実践へ　その１
禁則を勉強して、実践へ　その２
禁則を勉強して、実践へ　その３
禁則を勉強して、実践へ　その４
禁則を勉強して、実践へ　その５
の続き。

メールサーバーの設定には下位に2つの設定パネルがある。まずは、メールサーバー - 詳細。

まずは、サーバーのポート番号/暗号化の指定なのだが、さっきよりも禁則が複雑。

POP over SSLまたはSMTP over SSLがONの場合、証明書の検証をしないをONにできるので、このような5つの禁則マトリクスができると思われる。

割付はまた今度ということで。

禁則を勉強して、実践へ その５

勉強会が終わりました。これからは自分勉強へ。

==

禁則を勉強して、実践へ　その１
禁則を勉強して、実践へ　その２
禁則を勉強して、実践へ　その３
禁則を勉強して、実践へ　その４
の続き。

サーバにメールを残すかどうかの設定が禁則になっていた。禁則グラフから、この3因子をまとめて、「サーバに残す-一定期間で削除-5日後」「サーバに残す-一定期間で削除-0日後」「サーバに残す-一定期間で削除-30日後」「サーバに残す-一定期間で削除しない」の4水準とみなす。この因子を割り付けたあとに、分解して3因子にすればよい。ということは、

最終的にはこのようなマトリクスとなる。

禁則を勉強して、実践へ その４

禁則を勉強して、実践へ　その１
禁則を勉強して、実践へ　その２
禁則を勉強して、実践へ　その３
の続き。

途中まで作ってみた。まずは直交表を変形してみて、

これに禁則以外を割り付ける。

禁則分の割付はまた今度。

禁則を勉強して、実践へ その３

久しぶりの更新。明日の朝は雨かあ。

==

禁則を勉強して、実践へ　その１
禁則を勉強して、実践へ　その２
の続き。

前回2因子間網羅率が56%になってしまって、どうしたもんかと悩んでいましたが、コメントにもあるとおり、指標としては「抽象化した状態での網羅率」を意識すれば十分であるとのこと。「ソフトウェアテストHAYST法入門」にも書いてありました。

なので総当り表を書き換えてみるとこんな具合。

次は、メールサーバーの設定について考えてみる。

送信メールサーバーはテキスト入力なので、正常系（＝smtp.nifmail.jp）、正常エラー系（＝存在しないドメイン名、smtp.softest.jpとか）、空欄として3水準としよう。受信メールサーバーも同様に正常系（＝pop.nifmail.jp）、正常エラー系（＝存在しないドメイン名、pop.softest.jpとか）、空欄の3水準。メールアカウントは「softest@nifmail.jp」「softest@gmail.com（ドメイン名と異なるメールアドレス）」「softest@softest.jp（存在しないメールアドレス）」「空欄」の4水準。パスワードは「正しいパスワード」「間違ったパスワード」「空欄」の3水準。パスワードを保存するチェックボックスは「ON」「OFF」の2水準。

さあ、やっとこさ禁則の登場。

受信したメールをサーバ上に残すをONにすると、一定期間置いてから削除するを選択でき、それをONにすると、X日後の値を設定できる。これは禁則グラフ・禁則マトリックスを使ってみよう。禁則とは何かというと、「ありえない水準の組合せ」といっていい。この考慮は非常に重要で、複雑なシステムにHAYST法を適用しようとする場合、この禁則の考慮がされないと、まったくテストができなくなることがある。

禁則グラフを作ってみると、最後の日数を指定する因子については若干網羅率・出現率が低下するだろう。

割付については次回へ。もう眠たいので。

禁則を勉強して、実践へ その２

台風きてて、興奮気味。

==

禁則を勉強して、実践へ　その１
の続き。

直交表はL16にしましょうか。3つの4水準を多水準化してみる。

ぱぱ～とここまで割り付けちゃいました。ちなみに、イタリック体はダミー水準です。でも、これって8水準あった「アイコン」因子を抽象化してるので、2因子間網羅率が激下がり。。。どのくらい低下したかというと、、、

あーれま。56%になっちゃった。さてさて、どうしたもんかねえ。

禁則を勉強して、実践へ その１

第3回勉強会、おそらくはHAYST法を実践する上で肝となる禁則の回でした。

==

自分の業務に近いケースを考えてみようかな。その１として、僕の使っているメールソフト「秀丸メール」。

業務で秀丸エディタを使ってるので、僕はこれを愛用。その中で、けっこう禁則がありそうな「アカウントの設定」について、考えてみる。

大きく分類すると

1. 個人情報


2. メールサーバー


3. メールの振り分け


4. 上級者向け

の4つに分けられる。まずは、個人情報から攻めるぞ。

因子としては、

アカウント名

アイコン

名前

メールアドレス

が考えられる。んで、それぞれの水準選定をしてみよう。アカウント名はごく普通のアカウント名をあらわす訳だが、よくみると（ハードディスク上に作成するフォルダ名）とあるので、別にメールアドレスというわけではないらしい。単機能テストでは、ここでフォルダ名のエラー推測とかやるだろうが、組合せテストではそれらの検証を前提として行うので、「username@example.com」「Software Taro」「山田太郎」の3水準あたりか。アイコンは、プルダウン選択で「標準」「カスタム1」「カスタム2」「カスタム3」「NetNews用」「RSS用」「Web掲示板用」「HTMLページ更新チェック用」の8水準。ただし、これはアイコン表示という比較的重要度の小さい箇所と考え、グループ化するほうが効率的である。「標準」「カスタム系」「その他系」の3水準で十分じゃないかと。名前は、メール送信時のFromコメント部分に挿入されるであろう名前。なので、「username@example.com」「Software Taro」「山田太郎」「空欄」の4水準。メールアドレスは、形式縛りがあるので、「username@example.com」「notaddress」の2水準。実は、メールアドレス形式でなくても、警告ダイアログをOKとすれば設定可能なのだ。空欄だけはNG。

あれま、禁則とか題名で言っておきながら禁則なしでスタートですか。次は、この画面の組合せを直交表に割り付けてみる。3水準、3水準、4水準、2水準。直交表のサイズはいかに？

デフォルトってなんぞや

昨日は、先日出版された「ソフトウェアテストHAYST法入門」の社外勉強会。

==

「デフォルト」というのは、初期値とか初期設定とか何もしないときの状態とか。ソフトウェアテストでいえば、「特にカスタマイズしていない状態」とか「標準的な値」とか、あるいは「最も利用される値・状態（最頻値）」を指すことが一般的。ただし、これってすごく曖昧な表現なんだということに昨日気づきがあった。「○○のデフォルト」といった場合、形容する○○に従属的な言葉なので、例えば、

OutlookExpressのMIME文字コード変換方式のデフォルト

GmailのMIME文字コード変換方式のデフォルト

だと、同じ「デフォルト」という条件だが、実際は違う。（Bエンコード×ISO-2022-JPだったり、Bエンコード×UTF-8だったり）これは、テスト仕様書に記載されるときに、ちょっとした勘違いや認識違い、考慮漏れを引き起こすのかもしれません。

L2^k直交表からL2^(k+1)直交表が作られる証明

閉店間際に丸善で購入。

けっこうライトな数学本で面白そう。

==

ソフトウェアテストPRESS#2にある「直交表の拡張（100ページ目）」の手順で表を拡張すると、それもまた直交表となる。


こちらのPDF資料を引用させてもらいました。

それを証明してみようかと。（ソフトウェアテストではなく、すでに趣味ですが）ただし、証明とはいってもブログで証明を書くのはしんどいのでポイントだけ。やり方は帰納法で。

• サイズが8（=2^3）へ拡張すると直交表となる
　これは自明。
• 直交表サイズが2^kへの拡張が正しいと仮定

　つまりはL2^k直交表については直交性が成立していると仮定しておく。
• 上記方法で表を拡張し、サイズが2^(k+1)の表を作成する
• この表が任意の2列に対して直交性をもつことを示す

　任意の2列を選び、左側にある列を列x、右側にある列を列yとする。



1. 列xおよび列yがともにk次因子以下


　k時点での仮定により自明。
2. 列xがk次因子以下、列yが(k+1)次因子


　列yはもともと、k次因子以下の列と左から2^k番目（0と1が交互に現れる列）の列との成分和で表現される。k次因子以下の列は行が2倍に拡張されていて、2^k番目の列は0と1が交互にあわられる性質を持っているため、直交の性質は保存される。（ちょっと端折った）
3. 列xおよび列yがともに(k+1)次因子


　列x、列yともにk次因子以下の列と左から2^k番目（0と1が交互に現れる列）の列との成分和で表現されるので、相殺されて結局はk時点での仮定により成立する。
• したがって、任意のk（k≧3）について成立する

証明中に少し出てくる、「高次因子群同士の交互作用が必ず低次因子群に表れる」という性質は、ソフトウェアテストへの応用という観点でいえば重要かも。

多水準化は計算で求める？線点図で求める？

夏ばて、ばてばて～。

==

N水準系直交表を変形させて、多水準化する手法がある。むやみやたらと列を結合するのではなく、列aと、列bと、列a、bの交互作用列a+bの3列を1列とみなして、4水準列を作ったりする。列a、列b、列c、列a+b、列b+c、列c+a、列a+b+c（順序は見易さで並べました）の7列を1列とみなして、8水準列を作ったりする。

これは直交という性質を維持するためであるが、上記のように交互作用を計算で求める手法と、線点図（田口玄一博士が提唱）を使って機械的に求める手法の2種類があると思っている。（「ソフトウェアテスト HAYST法入門」第5章でもテクニックとして紹介している。）

以前スクリプトで多水準化を作ってみたのだが、どうも線点図で求めたときと結果が違うのだ。。。これって、演繹ではなかなか最適な多水準化ができないってことなのだろうか。特にサイズが大きくなると、だめみたい。

時間があれば作り直すー。

==
2007/08/11 一部修正。取り消し線を追加。きちんと手順を追えば最適解が出せるはず。自作スクリプトが間違ってるみたい。

[書籍]「ソフトウェアテスト HAYST法入門」 で入門してみる

amazonで予約してた本が届きました。

本書はまえがきにもあるとおり3部構成となっている。

ソフトウェアテストの必要性・組合せテストの効果性

直交表とHAYST法、その実践

HAYST法の組織的な展開

技術的な勉強としては2部がメイン。テストPRESS#2での「直交表による組み合わせテスト入門」でわからなかったこと、理解が進まなかったことがあった方には、この書籍はかなりの助けになる。僕も気づきがあったし。テストPRESSとの比較を交えて何点か。

なぜ、すべての組合せをしなくてもいいのか？

直交表はすべてのn因子組み合わせがまんべんなく現れる性質がある、というのは説明されているが、じゃあどうして出現しない組合せをしなくてもいいのか。実は単機能テストや総当り表を使えば、その理由がより理解される。ちなみに2因子組み合わせを100%網羅するという点ではall-pair法も同様に実現できるが、この方法では高次因子間で偏ることも説明されている。

禁則ってどう考えたらいいの？

テストPRESS#2では見開きで2ページ弱だった禁則の解説が、今回は1章分、21ページもある。僕はここが苦手だったので、もう少し深く勉強してみなくては。

線点図と交互作用

線点図を使えば多水準化ができるももちろんだが、2列と交互作用列との3列で4水準列を作成する説明や、独立な因子同士は交互作用列を使いながらサイズ膨張を防ぐなど、より数学的な解説も多くなった。成分表示も追加されてました。（a、a+b、cみたいな）

効果とサイズのバランシング

サブシステムに局所化して、あとから結合する方法である程度の網羅性を犠牲にしつつも、サイズ膨張を防ぎ、効果を維持する手法などはテストPRESS#2にはなかったか。

そのほか、コラムが充実しているし、状態遷移の行列の積による考察もなかなか興味深い。しいて個人的な意見を言わせてもらうと、直交表が効果を持つのは、単機能テスト前提という場合が多いと思う。そのあたりの言及はされていたが、もっとしつこくあってもよかったなあと思った。単機能テストと組み合わせテストは野球で言えばスターターとクローザー、みたいな。どっちも点を取られないように抑えなくちゃいけないが、どちらも特性がある。なーんてね。

今後の期待としては「応用編」「実践編」などの続編（！）や原因結果グラフ・デシジョンテーブルなどの兄弟本も出るといいなあ～

==

今後、勉強会なども開催される予定なので、自分の勉強メモや気づきを書いていきたいです。

HAYST法のサイト

何気なく検索したら、HAYST.comという秋山氏のサイトを発見。
HAYST法や直交表は網羅のための網羅。CEGやCFDは検出のための網羅。ってイメージ。

[書籍]ソフトウェアテストHAYST法入門

さてさて、でますよ。HAYST法＋直交表本。

きました。直交表についての書籍はいろいろ出版されているけど、ソフトウェアテストへの応用に特化したのは、あんまり見かけないかな。これは、必読でしょ。HAYST法ともなると、ウェブ上のJaSSTの資料とテストPRESS2巻くらいしかお目にかかったことがないや。ちょー楽しみ！！！

FTFI -どうして2因子間網羅なのか-

しつこいようだが、ソフトウェアテストは、いかにして少ない手数で多くの欠陥を見つけるか、がキーである。

どこに欠陥が入り込みやすいか、という問いにはいくつかの解答があるだろうが、直交表・HAYST法・All-pair法などを勉強する場合、勘所は組み合わされる条件の個数になることが一般的。なぜか。

ソフトウェア・テストPRESSでもネットにも資料があるのだが、欠陥の多くは単因子の場合と2つの因子による場合とでほとんどが構成される。

（引用元：　http://www.jasst.jp/jasst05w/pdf/S4-3.pdf）

ちなみに、NetscapeやApacheなどは2因子まででは欠陥混在数が収束せず、3因子の関係も考慮する必要があるプロダクトといえる。これはプロジェクトが大規模でメンバーが数多い場合には、多数因子の組み合わせでも欠陥が少なくない、との見方がされる。

2因子あるいは3因子までの組み合わせを考慮すれば、ほとんどの欠陥は検出できる、というのはこの経験則によるところが大きいと思われる。（田口博士による、バグの数は因子数で指数的に小さくなるという理論もあるかな）

==

ここからは私見。

All-pair法は2因子間網羅を特に意識しているが、テスト実施者＝開発担当者であれば、2因子間網羅すら間引いてもいいんじゃないかって思う。抽象化・グルーピングによって2因子間網羅率は低下するだろうが、先の条件下であれば極端な品質低下にはつながらないし、効率もいいのかな、と。ホワイトボックス的なアプローチができるはずなので。

タグチメソッド for ソフトウェアテスト ≠ HAYST法 と思ってます

久しぶりに直交表/HAYST法関連のブログ記事～。

==

以前ご紹介したブログで直交表やHAYST法についての考察が出された。

マイリストに「ソフトウェアテストにおける直交表(HAYST法、All-pair法)の利用」をアップ by つれづれなる技術屋日記

・ソフトウェアテスト開発技術者やソフトウェアテスト技術者にとって未知の世界
・タグチメソッド自体が賛否両論
・直交表自体の学習の難しさ
　・実験計画法の記述のほとんどが、数式と表
　・ベースとなる統計や代数・幾何

直交表とかタグチメソッドとかいう名前を会社の上司に話したとしても、知ってる程度で実際に直交表の書かれた紙や画面を見せると、苦笑い、といったことが多い。これは指摘の通り、未知の世界だということが大きいかも。今や大学在籍時の専攻が理学系だったとしても、なかなか数学って敬遠されがちな分野。行列とかベクトル空間とかあんまり記憶にないのが現実。だから、「直交(orthogonalかな？)」という概念もすぅ～っと頭に入りにくい。

僕はちなみに数学を主専攻にしていたので、大学時代ぶりの数式を見るとけっこう楽しい。ツボだね。それは同僚からすると意外に稀有な存在に映るらしい。

・タグチメソッド（品質工学）との間隙

（中略）

　・SN比など重要な概念が、電気・機械・化学等の計測した数値の場合が多い
　・体系が、電気・機械・化学等の事例をベースに確立されている

タグチメソッドについて浅学すぎて議論についていっていないかもしれないが、ここで僕の考えは少し違う。そもそもタグチメソッドを利用したソフトウェアテストという体系と、直交表を使ったソフトウェアテストという体系は別物だと考えてます。どういう理屈からかというと、、、

# 以下、浅学なため見当違いの意見を含むかもしれませんので、ご指摘を。。

タグチメソッドとはいかに分散を抑えるかが目的

タグチメソッドを説明するサイトで多く見られるのが、平均値が正確な技術と分散が小さい技術、どちらを優秀と評価するか、といった例が挙げられている。このメソッドによって、例えばどういった環境とどういったデータでソフトウェアは想定した動作をするかを評価はできる。あるいは、サーバのCPU性能、メモリ搭載量、ディスク性能といったパラメータがどのように処理性能に影響するかを評価するときに利用できる。

直交表の性質から、効率的な組み合せパターンを作成できる

直交表は任意の2列が直交という性質を持っていて、それをテスト条件の因子に当てはめると、効率的なテストケースのパターン作成に役立つ。例えば、ON/OFFの2種類の条件が7つあった場合、組み合せ数は2の7乗＝128通りが想定できるが、任意の2条件についてすべて網羅できるという制約をつければたった8通りのテストケースで網羅できる。また、ソフトウェアによっては3条件以上の網羅を必要とする場合があるが、それも田口博士の工夫によって網羅率を高める方法が存在する。

以上のように、ソフトウェアテストへの応用について言えば、タグチメソッドと直交表とは区別したほうがいいのではないか。と、私見ではあるが考える。

少ない利用事例

・タグチメソッド自体、ソフトウェアでの利用事例発表が少ない
・HAYST法利用での発表も同様
・All-pair法利用での発表は皆無（特に日本。参考文献5は貴重）

ほんっとに、少ない。ソフトウェアテスト全般に活用できるとは思っていないが、局所的にはすごく便利なツールなのでもっと文献や資料、事例がないと、なあ。タグチメソッド(というかSN比)の活用については、負荷分析に利用できる、といった示唆はあったが、それくらい。

・ソフトウェアテストのイメージ（困難な直交表経験者の流用）

（中略）

　・従来のタグチメソッド用ツールが使えない（HAYST法のツールはソフトウェア専用。たぶんAll-pairも）
　・逆にソフトウェア直交表ツールを、ハードウェアのタグチメソッドに使えない

お互いのツールがお互いを意識していないから、だろうか。

・ホワイトボックステストへの利用

（中略）

function funcA(a1, a2:integer)
　：
　：
function funcA(b1, b2, b3:integer)
　：
　：
function funcA(c1, c2:integer)
　：
　：

　　funcA～funcCを因子へ
　　a1～c2を水準へ

なるほど。この考え方は僕にとっては新鮮でした。単体テストケースで直交表を利用するというのはやってみたいな。ただし、関数I/Fが変更された場合はおそらくゼロから単体テストケースを作り直す必要はありそうだ。

==

いや～、ＰＤＦ７６ページの大作。読みごたえあり。すべてについて感想や意見を書く時間はなかったけれど、何かアクションしたかったので記事にしてみました。直交表って魔法に見えたり、難解なパズルに見えたり、いろんな顔を持ってるので、感じ方も千差万別かな。

組み合わせテストケース作成ツール（サンプルその3）

前回よりも直交表の割り付け方を工夫したので、サイズも小さいし、多因子間網羅率も高いはず。。。

テストケース作成ツール（サンプル）

次の課題は、2因子間網羅率の計算と、3因子間網羅率の計算、かな。とりあえず今日はここまで。

直交表における分割実験の意義に関する考察

今週は上司との上期成果の評価面談。特に目立った成果がないのだが大丈夫かな。。。製品検査で99点もらったのと、社外ワーキンググループのパネラーになったのとかを全面に出してみるかな。

==

直交表を左から低次な順に並べることで、右側の列に3因子間網羅率100%な列が集中することは、前に書いた。もうひとつ左側に並ぶ低次列に着目すると、0と1が比較的バラバラに出現することはなく、ある程度まとまって出現している。これは観点の違いによってメリットであったり、デメリットでもあったりする。

メリット

因子によっては容易に変更しがたいもの(OS, 接続環境, etc)があったりすると、頻繁に条件を変えてテストを実施するのが難しい。そこでこのように左側(1次因子)に変更の難しい因子を割り付けることで、テスト実施の効率化がはかれる。図では左から1次因子、2次因子、3次因子というように並んでいる。

デメリット

Webサービスでのソフトウェアテストではあまり考慮されないが、実際の実験では同じ条件で実験すると慣れてきてしまい、実験結果に影響することがある。(実験器具の扱いなど)この直交表の順番だと1次因子が同じ条件で8回実験を行うことになるため、通常は図でいえば16行をランダムに並び替えてから実験を行うことが一般的である。

以上のように、低次な順に並べることでメリットとデメリットがあるが、Webサービスの組み合せテストという観点でいえばメリットを享受できることが多いと思われる。

※本記事はあきやまさんのコメントを参考にしながら書きました。

直交表における2因子間網羅率の考え方

直交表をソフトウェアテストの条件組み合せ抽出に利用する最大の目的は、多因子間網羅率を100%にすることである。ソフトウェアの特性にもよるが、まずは2因子間の組み合せ網羅率を100%にすることが考えられる。この100%とはどういうことか。

上記のような単純な2次元マトリクスを利用することですべての組み合わせは交叉のマス目に出現する。同じ因子同士の組み合せは対角線上に出現し、2因子の順序を入れ替えた組み合わせは対角線を対称軸として上下に出現するので、必要なマス目は限られてくる。そして、このマス目数が2因子間全組み合せ数(53通り)となる。図では水準のグルーピングなどの手法を使ったため、直交法に出現しない組み合わせが4通り存在する(白色のマス目)。2因子間網羅率とは図でいう直交表に出現した黄色いマス目(49通り)の出現割合となるので、この場合は92.45%ととなる。

この網羅率を100%にするほうほうはいたって単純で、白色のマス目で表される組み合わせのテストケースを追加するだけである。

3因子間の全組み合わせを視覚的に上手に表現した表はまた今度紹介します。

直交表の高次群同士の排他的論理和は低次群に出現することについての考察

直交表の拡張の仕方が違うと列の順序も違ってくることに関する考察の続きです。題名が漢字ばっかり。。汗

==

田口玄一博士の工夫「低次の列から並べる」というのはどういうことか。例えば、基底aとbからなるL4直交表を左からa、b、a+bとする。これを次の大きさの直交表＝基底a、b、cからなるL8直交表へ拡張するとき、図のようにc、c+a、c+b、c+a+bと高次群の4列を追加すると、左から「低次」の順に並ぶ。すると、追加した4列はすべての列が基底cを含んでいるため、その中から任意の2列を抽出して排他的論理和を計算すると基底cが相殺されて、基底cのない左側3列のいずれかになることがわかる。つまり、高次の4列の中で抽出した2列の交互作用は必ず左側に出現し、当然3因子間網羅率が100%となるのである。

これはL16直交表、L32直交表、L64直交表・・・と同じ仕組みで成立する性質である。

組み合わせテストケース作成ツール（サンプルその2）

テストケース作成ツール（サンプル）

ひとまず、サンプル2号を作成。でも、やってみると直交が崩れてる。。。ショック。。。

今日はもうおしまい。

==

自分で試してみた。因子数は14個、いくつかは多水準化が必要な場合でやってみたらサイズが128に膨れてしまった。この大きさは妥当なのだろうか。それに、テストケースは出来上がってるけど、本当に網羅してるのかってのが一目じゃわかりにくいな。何か検算機能をつけてみるかな。

直交表は「有効」であっても「万能」ではない(2)

最近は直交表というキーワードでこのブログにたどり着く方も多いかと思います。僕も同じく徘徊している一人ですから。

==

HAYST法／直交表に関する教育や実践での問題 by つれづれなる技術屋日記

HAYST法の推進者からは、更に数の多い因子への対応法の話が出る。つまり、そのままだとより大きなサイズの直交表を小さなサイズの表にする手法の話。頭では理解できるものの、上記の抵抗感と同様にふと疑問が湧いてしまう。抵抗感は何かと以前から考えていたが、”直交性”が保てるかとの疑問かもと思うようになった。
”直交性”は相関の逆数で、大きければ大きいほど直交表としてはいいと言える。ただし、具体的な算出方法が思いつかない。２つの因子で、各因子の水準が数値なら出来なくはない。が、因子が増えると計算が面倒。まして、水準が離散的とかOn/Offのようなケースをどう考えたらいいのか？？？

直交表を組み合わせで利用するときのメリットは2因子間、3因子間といった多因子間の組み合せ網羅率100%な組み合わせを効率的に作成できる、といったことだと思っています。なので、「直交表としてよい」という指標としては例えば「2因子間網羅率」だとか「3因子間網羅率」でいいのかな、と。もちろん、網羅率だけを品質の指標として使うのは危険であり、直交表やHAYST法が万能ではないというのはそのためである。

６）HAYST法を救世主・絶対視する人達の存在。 HAYST法の推進者がそうだとは思わないが、HAYST法や直交表でテスト件数が相当減るとか品質が上がると思っている人達がいる。従来のテストを行う事自体を否定する事すらある。

直交表やHAYST法という名前だけが一人歩きしてしまったり、「直交」といういかにも数学的な用語がついていることから、ブログの著者が指摘するような危惧はぬぐえない。僕の認識としては、勘や経験だけで考えるよりも効率的に、効果的にテストケースが作成できる、といったイメージは持っています。品質が上がるというのはどちらかというと間接的な効果くらいかな、と。

よし。これからも、ブログのタイトル通り、日々勉強と反芻を繰り返していくぞ。そして実務にも活かしたい！

直交表の拡張の仕方が違うと列の順序も違ってくることに関する考察

直交表と交互作用で直交表における交互作用列がどこに現れるかについて言及したところ、あきやまさんから「右半分を使えば3因子間網羅率100%になる」というご指摘をいただいた。しかし、実際は僕の作った直交表ではそうならなかった。これはいったいどういうことなのか、について検証してみようと思う。（図はこのPDF資料を引用）

ソフトウェアテストPRESS Vol.2では、基本となる列の要素を倍に増やし、0と1が交互に現れる列とのXORを右に並べていくことで直交表を拡張している。具体的には下の図のように左から基本3列、0と1の交互列、基本3列のXOR列で構成される7列のL8直交表が完成する。

この拡張ルールで直交表を作成すると、右半分（4～7列）に属する任意の2列については交互作用が必ず左側（1～3列）に出現することになる。これは3因子間網羅率を100%にするという目的から考えれば、視覚的にわかりやすい形をした直交表といえるだろう。

対して僕の直交表の作成方法は、L2^k直交表の場合は、k列の基底a1、a2、...、akの線形結合の組み合わせでその他の列を生成している。
これはプログラムを使って直交表を作成するという観点からすると、シンプルなアプローチではあるが、上記の拡張方法とは異なり、いちいち交互作用列を見つけ出す必要がある。

以上のように、直交表の作成方法によって若干性質も変わってくるのである。

直交表は「有効」であっても「万能」ではない

東京地方は大雨な一日になりそうです。

==

直交表という組み合せテストの手法を勉強していて、以下のようなブログ記事に遭遇。

直交表の功罪 by つれづれなる技術屋日記

その人は、ソフトウェアでの組み合わせテストを直交表で作る事になっているんだが、成果としてもう○ヶ月近くモノが出ない。たった一つの直交表すら出来てこない。そもそもどんな組み合わせテストをするかで、細かい部分とおおざっぱな部分とで粒度がいい加減。因子と水準はそれなりに抽出しているが、機能のための因子が相当足りない。

(中略)

直交表の功罪かもと思った１日。ソフトウェアテストでの直交表の利用自体は、喜ばしい事だが、人によってはそれによって万事解決と思う人もいるみたい。

ソフトウェアにおける統合テスト・機能テストは、さまざまな条件を変えてシステム動作が仕様どおりに動作するかを確認する必要がある。単純に「条件の個数×条件の振り幅」で組み合わせを考えると非現実的な組み合わせをテストケースとして考慮しなくてはならない。でも、一般的には1条件、2条件〜3条件の組み合わせが網羅されているだけで、ソフトウェア内の不具合のほとんどが検出できると言われている。（何条件まで検証が必要かはそのプロジェクトの特製、コストや要求される品質によって変わる）

ソフトウェアテストで直交表を利用するというのは、2条件、あるいは3条件の組み合せ表をなるべく少ないテストケースで網羅しよう、というアプローチのことで、このブログの著者がいっているように「万能」な道具というわけではない。適切な因子と水準の抽出ができなければ不具合の検出が少なくなるだろうし、直交表を適用できない場合もなくはない。

今作成しているツールでも直交表を利用した組み合せテストケースが登場するが、やはりツール利用者の経験量・知識量などが因子と水準の抽出に影響するので、アウトプットに品質のブレが発生する可能性がある。「テストケース作成における生産性」は向上しても品質が追いつかないとまずいな。この問題の解決手段としては、今のところ「サジェスト機能」くらいか。もう少し工夫が必要かも。

また、直交表の話になってしまったが、とりあえず今朝邂逅したブログ記事についてでした。

直交表と交互作用

直交表を用いることで2水準間網羅率を100%にすることは可能。3水準間網羅率を100%にするにはどうしたらよいか。そこで登場するのが交互作用という概念である。

L8の場合、8＝2の3乗なので基底となる列が3つ存在し、それを左からa、b、cと名前をつける。そのとき交互作用のあらわれる列がこの直交表でいうと4列目、これはすなわちa＋bの列である。この3列（オレンジ色）を見比べてみるとパターンは4パターンしかない。2水準の因子が3つなので実際は8パターン出現しなくては網羅率は100%にはならない。したがって、この場合は4列目（＝a＋bの列）を除外することで網羅率を上げることができる。（ある資料にある言葉を借りれば「強度が増す」と表現されるかな）

L16の場合、L32の場合も同様である。

テストケース作成ツールを作ろう

天気予報では午後から晴れるっていってたから、今日は傘なし。やっと晴れてきた〜。

==

直交表の性質も少しずつ理解が深まってきた。ふと、ツールを使って簡単にテストケースって作れないかと思い、昨日からいろいろ勉強中。といって、JavaScriptとスタイルシートですが。力技で作ってしまえ的な勢いです。機能的にはこんな感じのツールをイメージ。

因子と水準を入力して、テストケースマトリックスを表示

せっかくなので、水準値はサジェスト機能付き(境界値分析とかエラー推測)

グルーピングや多水準化も当然やる

n因子間網羅率の計算もしたい

仕事の合間にコツコツと。

現実的なサイズは L32 か

最近ネタが直交表ばかりです。僕が今週はちょうどシステムテスト週間だからちょうどいいか。。。

==

先日紹介したよくわかる実験計画法を元に2水準系の直交表をエクセルで作成してみた。L32の直交表に対応する交互作用の一覧表までは作って、あとはL64のサイズだけ〜・・・と思った。が、よく考えてみると今までソフトウェアテストとしては直交表ってL32までしか使ってないな。冷静になってみれば因子数が64ってありえないし、多水準化したとしてもL32であれば十分な因子数が確保できる。ググってみても64なんてサイズはあんまり見ないしな。

懸念としては、交互作用が発生しないように列を選択して3因子間網羅率をあげる工夫をすると、サイズが足りなくなるのかもしれない。

次のプロジェクトで試してみるか。

水準数が2の場合の3因子間網羅率

直交表を使うことで2因子間の網羅率を100%にすることができる。それは直交という性質の効果でもある。それでは3因子間網羅率はどうだろうか。これについては交互作用の現れる列を選択しないように上手に組み合わせを行うことで網羅率をアップさせることができる。各列に対する交互作用の現れる列を指し示した図は交互作用一覧表と呼ばれており、少し手間がかかるが直交表と同様に作成することができる。

左図は、L8直交表と交互作用一覧表の一例である。一例と但し書きしたのは、基底（図のa、b、cのこと）の取り方によって、あるいは合成列の順番によって交互作用一覧表の値も変わるからである。

列1(a)と列5(b+c)と列7(a+b+c)が交互作用の関係になるのは、列7が列1と列5の和で表されるためである。すなわち、直交という性質が崩れてしまうのである。

ただし、この手法は水準数が2の場合の話。多水準化した場合はどうしたらいいだろうか。それについてはまた
別の機会に書こうと思う。

[本]よくわかる 実験計画法

直交表についてもう少し深い理解をしようと思って、購入。お値段も手軽でグッドです。ソフトウェア・テストPRESSでも直交表・ダミー水準・多水準化といった手法を載せてたけど、こちらはもう少し理論の裏づけを交えながらの解説でした。ベクトルを持ち出すことで直交という概念がより数学的になっている気がします。ちなみに、タイトルからわかるようにメインとなるのは「実験計画」の手法なので、ソフトウェアテストのテストケース作成には必要ない情報も含まれます。

直交表（L8～L64まで）

L8直交表＋交互作用一覧表

L16直交表＋交互作用一覧表

L32直交表＋交互作用一覧表

キーワード：実験計画法, ラテン方格, グレコ・ラテン方格, 超グレコ・ラテン方格, 直交表, 主効果, 交互作用,
　　　　　　線点図, 擬水準, 2乗化

直交表を利用したソフトウェアテスト→HAYST法とか

2007/08/07下部に追記。

==

ブログを検索していたら、僕と同じように直交表について書いているブログを発見。

効果的なテストケース生成
直交表 - ソフトウェア・テスト手法 (あるＳＥのつぶやき)
ソフトウェアテストへの直交表の応用

同じことを勉強しようとして、Google先生に教えてもらうとやっぱり似たようなサイトを参考に勉強するんだなあ、と再認識。僕も買いましたよ、ソフトウェア・テストPRESSを。

直交表というのは任意の2つの列に関して直交している表のこと。この場合の直交とは0/1の値を持つ条件について、2条件組み合せが平均して出現するような性質のことをいいます。テストケース作成において重要なポイントは3つあって、

できるだけ少ない数のテストケースで

できるだけ多くのバグを

できるだけテスト対象を網羅してテストを行う

を満たすテスト設計が優秀とされています。直交表を利用することで、より少ないテストケースで網羅率をアップすることができるのです。ただし、直交表にも欠点があり、

大きな水準数(条件の取りうる値の数)の因子を割り付けることが難しい(多水準割り付け)
2因子間網羅率は100%であるが、3因子以上の網羅率は100%を保証しない(多因子網羅率)

という課題がありました。ここで登場するのがHAYST法と呼ばれるテスト手法です。この手法は富士ゼロックスの秋山氏が開発した組み合せ手法のひとつで、多水準割り付けも課題を解決しています。具体的な多水準割り付け方法については以下の資料が参考になるかと思います。

直交法を活用したソフトウェアテストの効率化-HAYST法の活用-(PDF)

あるいは、ソフトウェア・テストPRESS Vol.2でも同じ解説が載っています。

直交表というなかなか取っ付きにくいツールに加えて、線点図など新たな語句が登場して、さらに敷居は高くなった気がしますが、実際に試してみれば理解と実践方法が馴染んでくると思います。おそらくうちの社内勉強会のときもケーススタディを用意して実際に体験してもらうのが一番じゃないと思ってますし。

残るは多因子間網羅率の課題です。プロジェクトの性質によっては2因子間組み合わせの網羅だけで十分な品質が得られる場合もありますし、3因子間網羅率を100%にする列を使うといった手法も秋山氏は取り上げられいますが、この課題については、僕らへの宿題かな、なんて思っていろいろ作戦を考えてる最中だったりします。

アイデアとしては、因子を2種類くらいに分類して単純に組み合わせる手法で今は多因子間網羅を実現しようとしてます。当然、テストケースはかなり膨張しちゃうんですが。。。

==
2007/08/07
ソフトウェアテストに直交表を用いたテスト手法「HAYST法」についてのバイブル！日科技連出版「ソフトウェアテスト HAYST法入門」が出版されました。

僕も購入して読んでみましたので、こちらをご参考にしてもらって興味があれば、さあ入手だ！

[本]ソフトウェア・テストPRESS Vol.2

テスト専門誌。内容はというと、上流工程でのインスペクションや直交表による組み合せテストの手順など。HAYST法による水準数拡大の手順も詳しく掲載してあって、Goodですな。うちの開発チームでもこのHAYST法を改良して、活用していこうと動き中。

ちょうどこのVol.2が出てすぐに JaSST '06 Tokyo があって、内容がかなりかぶってた。

==