オープンソースのPairwise(All-Pair)法のツール「QICT」
オープンソースのPairwise法のツールはいくつか存在しますが、今回紹介する「QICT」は「PICT」の開発者であるMicrosoftのJacek Czerwonkaさんの同僚であるJames McCaffreyさんが開発したものです。「QICT」はPairwise法のツールとしては限られた機能しか備えていません。２つのペアを生成するだけで３つ以上の組み合わせは生成できませんし、制約もサポートしていません。しかしながらソースコードを公開しており、生成アルゴリズムについてかなり詳しい解説が行なわれています。
「QICT」は「PICT」と同じ生成アルゴリズムであるグリーディヒューリスティック手法を採用しています。ヒューリスティックアルゴリズムについては、このブログの記事である 「Pairwise法（All-pairs法）のヒューリスティック手法を試してみる 」 が参考になるでしょう。グリーディなアルゴリズムについて、「QICT」では懇切丁寧な解説が加えられており、これは貴重なものだと思います。
「QICT」についての詳しい解説は以下のサイトで読むことができます。
http://msdn.microsoft.com/ja-jp/magazine/ee819137.aspx
ソースコードは以下のサイトからダウンロードすることができます。
http://archive.msdn.microsoft.com/mag1209TestRun/Release/ProjectReleases.aspx?ReleaseId=3657
「QICT」は C# で書かれています。ビルドすると 8Kbyte の小さなコンソールアプリケーションが作成されます。
あらかじめ「QICT」に読み込ませるモデルファイルが用意されており、コマンドプロンプトからコマンドとして「QICT」を投入することで次のように生成結果が出力されます。
James McCaffreyさんは「QICT」を公開した理由として次のように述べています。
「では、なぜ、わざわざ別の生成ツールを用意したのでしょう。理由はいくつかあります。まず、PICT はすばらしいツールですが、ネイティブ C++ コードで作成されていて、ソース コードを入手できません。このコラムで紹介する QICT ツールは、私が知る限り、マネージ C# コードで作成され、製品レベルの品質を備えた最初のペアワイズ ツールです。コードを無償で入手できるため、独自のニーズに合わせて QICT を変更できます。たとえば、入力を XML ファイルや SQL データベースから直接読み取るように変更したり、結果を独自の出力形式で出力するように変更したりできます。また、制約 (許可されないテスト入力セット) を導入したり、必須のテスト セットを導入したり、テスト セットのコレクションの生成方法を変えてみたりと、ツールのロジックを利用してさまざな試みを行うことも考えられます。」
「QICT」をベースにして必要な機能を追加してみてほしいということでしょう。確かにソースコードには詳しい解説がついていますので機能を追加する上でのしきいは低いと思います。
PictMaster v4.3 をリリースしました。
PictMaster v4.3 をリリースしました。
v4.3 での変更点は以下の通りです。
【機能改善】
・パラメータの最大数を50個、値の最大数を50個に拡張した。
・結果表での結果内容欄を50個に拡張した。
・扱えるテストケースの最大数を30000件に拡張した。
【バグ修正】
・無効値がエイリアスである場合、結果表で指定した時に正しく処理されなかったバグを修正した。
・結果表でのワイルドカードはVBAの仕様上の制限のため、使用不可とした。
・PictMasterのファイルが複数開かれた状態でウインドウ分割のショートカットキーを押すとVBAのエラーとなるバグを修正した。
この修正によりウインドウ分割の処理方式が変更となったため、PictMaster v4.3以降の新しいバージョンとv4.22以前の古いバージョンを同時に開いている場合は、古いバージョンでのウインドウ分割ショートカットキーは無効となります。古いバージョンでウインドウ分割ショートカットキーを使用したい場合は、いったんExcelを終了する必要があります。
PictMaster v4.3 は以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
新規機能と既存機能では障害発生率にどの程度の違いがあるか
ある製品を開発する場合、まったくの新規製品は数少なく、既存の製品を流用し、それに新規の機能を追加したものが大半を占めていると思います。そこで既存の機能を流用したものと新規の機能として開発したものとでは、障害発生率にどの程度の違いがあるか調べてみました。
次のグラフで、ある製品開発における新規機能と既存機能との件数と、それぞれの総合テストにおける障害発生件数を示します。
このグラフの用語の意味は次のとおりです。
・新規機能
文字通りまったく新規に開発した機能
・既存流用
当シリーズ製品の以前の機能をそのまま流用した機能
・他機種改造
異なるシリーズ製品の機能を改造して流用した機能
・既存新規
当シリーズ製品で以前の製品の機能に手を加えて流用した機能
この製品の機能数は３５２となっています。ただし、この総合テストではすべての機能についてテストしている訳ではなく、全体では５００程度の機能となります。新規機能の数は６１となっています。
このグラフを見てすぐに分かることは、新規機能でかなり多くの障害が発生しているということです。そこで１機能あたりの障害発生件数を機能変更分類別に集計したグラフを以下に示します。
このグラフからは、新規機能において他の機能に比べて実に４～５倍多くの障害が発生しているということが分かります。１機能あたり約３．５件の障害が発生しています。他の機能ではいずれも０．７～０．８件と少なくなっています。既存流用では障害が発生しないように考えがちですが、考慮漏れで実際には変更が必要だったり、過去のテストで発見されていなかった潜在バグを発見したことなどが影響しています。
「障害は偏在する」とはよく言われますが、新規機能で多くの障害が検出されることはある意味で理にかなったことではあります。しかし、総合テスト以前の単体テスト、結合テストを十分やりきれていればもっと少ない障害件数となったであろうことは容易に推察できます。しかもこの件数は平均ですので、新規機能の中でははるかに多くの障害が検出される機能があります。そうした機能では１機能あたり２０～３０件もの障害が検出されています。
障害が多く検出されている機能についてはより徹底したテストが必要となります。
テストが進むにつれて２つの要因の組合せで発生する障害が多くを占める
以下に示すのはあるプロジェクトでの総合テストにおいて障害がいくつの要因の組合せで発生したものであるかを表したグラフです。なお、要因の数え方は2010年07月12日の記事 で示した方法で行なっています。
次にテストサイクル別の障害発生要因数を見てみたいと思います。「テストサイクル」とは、ごく単純化して説明すると、例えばテストケースが１００件ある場合、総合テストの期間を５つに分けて、テストケースの１番目、６番目、１１番目・・・は最初のテストサイクルで実施し、２番目、７番目、１２番目は次のテストサイクルで実施し、以降同様に実施し、最後のテストサイクルでは５番目、１０番目、１５番目・・・といった具合に実施するテストケースを期間に応じて分けてテストを実施することを言います。
テストケース数が数万件もある場合、限られたテスト期間で何回も繰り返すことはできません。テストケースを分割することで数回のテストサイクルに分けてテストを実施します。この際重要なことは、各テストサイクルによってテスト内容に偏りが出ないようにすることです。そのためテストサイクル別に飛び飛びにテストケースを実施します。１つのテストサイクルの期間は１ヶ月から２ヶ月です。
総合テストをいくつかのテストサイクルに分けて実施することには大きなメリットがあります。総合テストの早期に障害が多く発生している機能を見つけ出すことができ、早めに問題個所を重点的にテストすることができます。ソフトウェア信頼性成長曲線に最適なデータを得ることができます。総合テスト開始時にすべての機能が完成していればよいですがそうでない場合、テストサイクルが新しくなる時点で新機能をテストに投入することによりテストを管理しやすくなります。
以下にテストサイクル別の障害発生要因数を示します。このプロジェクトではST0～ST4の５つのテストサイクルとなっています。
このグラフからは、大きなトレンドとしてテストが進むにつれて１つの要因だけで発生する障害が少なくなり、２つ以上の要因の組合せで発生する障害が多くなってくるということが読み取れます。このことはテストが進むに従ってソフトウェアの品質が向上していることを示していると考えられます。
次に最後のテストサイクルST4での障害発生要因数を示します
総合テストの最後の段階では、２つの要因の組合せで発生する障害が最も多くなっています。この特長は2010年07月12日の記事
で示した要因組み合わせ数別市場障害発生比率と似た傾向となっています。総合テストの最後の段階で、２つの要因の組合せで発生する障害が最も多くを占めている結果となっていない場合は品質が不十分である可能性が高いと考えられます。
スケーラビリディを向上した新バージョンをリリースする予定です。
パラメータの数 30個まで
値の数 30個まで
取り扱えるテストケース数 10000件まで
今後リリース予定のバージョンでは次のようにより大きなモデルを扱えるようになります。
パラメータの数 50個まで
値の数 50個まで
取り扱えるテストケース数 30000件まで
結果表の「期待する結果」も従来の30件から50件まで指定可能となります。
リリース時期は3月下旬を予定しています。