状態の洗い出しへHAYST法かpairwise法の適用

状態遷移モデルを使ったソフトウェアテストを勉強するためのテキストとしてボーリス・バイザーの「ソフトウェアテスト技法」「実戦的プログラムテスト入門」などを読んでみた。手順の最初に出てくるのが、仕様書からの状態とイベントの洗い出し作業。そもそも状態遷移図や状態遷移表を作ることって設計工程のツールなので、上流工程でのこういった作業が作りこみを減らすことにつながる。

で、ソフトウェアテスト技法のほうで状態の数を探るところ(第11章 4.2)があるのだけれど、具体例としてエンジンを題材にして、

ギア   (R、N、1速、2速、3速、4速) = 6要素
進行方向 (全身、後退、停止) = 3要素
エンジン (動作中、停止) = 2要素
トランスミッション (正常、異常) = 2要素
エンジン (正常、異常) = 2要素

合計 = 144要素

という記述がある。ここでいっている不可能な状態への考察って、禁則の考え方じゃないのかしら?だとすると、HAYST法を使って状態を絞り込むことができるのかな。ただ、本質的には同じことだけどHAYST法(=直交表)の特徴である、「どの条件も同じ程度出現する」というのはいらないので、pairwise法のほうが状態数が少なくなるのかな。


| | コメント (2) | トラックバック (1)

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

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

==

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

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


  • 直交表によるソフトウェアテスト 『HAYST法』の解説と学習
  • 著者がHAYST法について、職場向けの資料を作成して、それを公開しているサイト。職場向けの資料ということで、非常に細かい説明が掲載されており、図表や演習問題まで揃っている。

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


    2008/02/04追記:

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


    2008/02/05追記:

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

    | | コメント (4) | トラックバック (0)

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

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

    ==

    さてさて、禁則って実際考慮しないとどうなるんだろうか。
    2_2
    サーバーのポート番号/暗号化の指定について考えてみる。わかりやすくするためチェックボックスだけに注目すると、


    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直交表が使えるので、素直に割り付けてみる。そうすると、
    Photo
    このように禁則によってテストケース2,3,4,5,6はありえない条件となってしまう。すなわち、このままの状態でテストを実施しても組合せ網羅率は上がらないのだ。HAYST法はこの禁則回避について言及しており、その打開策として、

  • 相互排他因子融合手法

  • 多層化手法

  • 可変因子手法

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

    | | コメント (0) | トラックバック (0)

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

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

    ==

    禁則を勉強して、実践へ その1
    禁則を勉強して、実践へ その2
    禁則を勉強して、実践へ その3
    禁則を勉強して、実践へ その4
    禁則を勉強して、実践へ その5
    の続き。

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

    2_2

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

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

    4

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

    | | コメント (0) | トラックバック (0)

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

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

    ==

    禁則を勉強して、実践へ その1
    禁則を勉強して、実践へ その2
    禁則を勉強して、実践へ その3
    禁則を勉強して、実践へ その4
    の続き。

    1_2
    2_2

    Photo

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

    Photo2


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

    | | コメント (0) | トラックバック (0)

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

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

    途中まで作ってみた。まずは直交表を変形してみて、
    L45216
    これに禁則以外を割り付ける。
    1_4
    禁則分の割付はまた今度。


    | | コメント (0) | トラックバック (0)

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

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

    ==

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

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

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

    2


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

    送信メールサーバーはテキスト入力なので、正常系(=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水準

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

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

    1_2
    2_2

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

    1_3

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

    | | コメント (0) | トラックバック (0)

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

    台風きてて、興奮気味。

    ==

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

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

    4321
    4321_2
    Photo_4

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

    Photo_5

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

    | | コメント (0) | トラックバック (0)

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

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

    ==

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

    Photo

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

    Photo_3

    大きく分類すると


    1. 個人情報

    2. メールサーバー

    3. メールの振り分け

    4. 上級者向け


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

    1_2

    因子としては、

  • アカウント名

  • アイコン

  • 名前

  • メールアドレス

  • が考えられる。んで、それぞれの水準選定をしてみよう。アカウント名はごく普通のアカウント名をあらわす訳だが、よくみると(ハードディスク上に作成するフォルダ名)とあるので、別にメールアドレスというわけではないらしい。単機能テストでは、ここでフォルダ名のエラー推測とかやるだろうが、組合せテストではそれらの検証を前提として行うので、「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水準。直交表のサイズはいかに?

    | | コメント (4) | トラックバック (0)

    デフォルトってなんぞや

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


    ==

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

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

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

    | | コメント (2) | トラックバック (0)