テスト技法を解説した本ならこれ
近年になってテストへの関心の高まりとともに、ソフトウェアテストに関する書籍の出版が増えてきました。
Amazonの詳細検索でタイトルに「ソフトウェアテスト」が含まれているものという条件で検索すると４４件がヒットしました。
では「テスト技法」で検索した場合どうかというと１７件でした。この１７件のほとんどはソフトウェアテスト技法に特化した専門書です。
このうちわたしが買ったのが、リー・コープランド著の「はじめて学ぶソフトウェアのテスト技法」です。この本はタイトルこそ初心者向けのような印象を受けますが、内容は初心者向けはもちろん、奥の深い話題も扱っています。
- はじめて学ぶソフトウェアのテスト技法/リー・コープランド
- ￥2,520
- Amazon.co.jp
この本は、他の本では取り上げられることが少ない「直交表」や「All-Pair法」についても多くのページを割いて説明しています。これは他の本にはない特色でしょう。
テスト技法を専門に扱った本のなかでこの本は売れ行き上位から２番となっています。１番はホワイトボックステストのみを扱った本です。
参考になると思いますのでおもな目次の構成を示します。
第１章 テストのプロセス
第２章 ケーススタディの説明
Section I ブラックボックステスト技法
第３章 同値クラステスト
第４章 境界値テスト
第５章 デシジョンテーブルテスト
第６章 ペア構成テスト
第７章 状態遷移テスト
第８章 ドメイン分析テスト
第９章 ユースケーステスト
Section II ホワイトボックステスト技法
第１０章 制御フローテスト
第１１章 データフローテスト
Section III テストのパラダイム
第１２章 スクリプトテスト
第１３章 探索的テスト
第１４章 テストの計画
Section IV 支援技法
第１５章 欠陥の分類
第１６章 テストの終了判定
Section V 最後の考察事項
これらの目次から大体の内容は推測できるのではないでしょうか。各章はいきなり理論的な説明から始まるのではなく、簡単な例を用いて説明が行なわれます。
わたしはこの本でテスト技法についての理解を深めることができました。
それでは、また。
ソフトウェアの品質を示す新しい指標の提案 （10月2日内容追加）
テスト対象のソフトウェアシステムの品質を示す指標にはいろいろあります。
・残存障害件数がいくつあるか
・システムダウンなどの重大障害が最近発生していないか
・ソフトウェア信頼度成長曲線の数値
製品出荷判定の際は、これらのデータを総合的に判断して可否を決定することになります。
そこでソフトウェアシステムの品質を示す新しい指標を提案したいと思います。
皆さんも経験されているかもしれませんが、製品出荷後に市場で発見される障害は、その障害がいくつの要因の組み合わせで発生しているかを分析すると、２つ以上の要因の組み合わせで発生した障害が大部分を占めています。
実例として、わたしのチームが総合テストを担当した製品の市場出荷後に発見された障害がいくつの要因の組み合わせで発生するものであるかをグラフで示します。
このグラフでは、障害数が少ないため大雑把な傾向しか分かりませんが、要因が２つの障害が最も多くなっています。この製品では、要因が３つの場合が思ったほど多くありません。この理由にはいろいろ考えられますがここでは取り上げません。要因が１つの障害はかなり少なく、要因が２つ以上の組み合わせで発生する障害が市場障害の大部分を占めいていることが分かります。
この理由は直感的にも分かることでしょう。たかだか１つの要因で発生する障害は、総合テストの段階であらかた発見され、修正されているからです。それに対し、２つ以上の要因が組み合わさった場合に発生する障害は、１つの要因だけで発生する障害に比較してその発見はかなり難しいものだからです。
総合テストでテストを繰り返すうちに、発見される障害は徐々に少なくなります。このことはソフトウェアシステムの品質が良くなったことを直接には意味しません。仮に同じテスト仕様書でテストを繰り返すならば発見された障害は修正され、次のテストでは障害ではなくなります。しかし、テスト仕様書に漏れがある場合は、発見されないままの障害が残ることになります（殺虫剤のパラドックス）。
先に述べたように、市場で発見される障害は２つ以上の要因の組み合わせによるものが多くを占めています。もし、１つの要因による障害が多いなら、その製品のテストはかなり不十分だったということになります。
このことから、総合テストで発見された障害がいくつの要因の組み合わせで発生するものであるかを、時期を区分してデータを取ることで、ソフトウェアシステムの品質を知ることができるのではないかということです。
ここで実例をあげてみます。このデータはあるビジネスホンシステムの総合テスト期間を前期、中期、および後期の３つに区切り、それぞれの期間で発見した障害がいくつの要因の組み合わせで発生するものであるかを示した表です。
この表から、テストが進むにつれ、要因が１つの障害が減少し、２つ以上の障害が増加していることが分かります。この表をグラフで表すとさらに特徴が良く分かると思います。
ソフトウェアシステムの品質は、１つの要因で発生する障害が、全障害に対してどれだけ少ない割合になっているかが指標として使えるのではないかと思います。
このグラフでは、テストを繰り返すうちに１つの要因による障害と２つの要因の組み合わせによる障害の数がほぼ等しくなっています。理想的には２つの要因の組み合わせによる障害が最も多くなることだと思います。それだけ漏れの少ないテストを行なっているということが言えます。
この方法が適用できるのは、比較的規模の大きなテストの場合に限られます。テスト期間として６ヶ月程度が最低ラインのように思います。
データの期間の区切り方などに詰めが必要ですが、１つの指標として参考になるのではないでしょうか。
それでは、また。
AllPairII 1.1 をリリースしました。
ＡｌｌＰａｉｒＩＩ 1.1 をリリースしました。1.0 のバグフィックスがメインですが若干の機能改善も行ないました。
以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
おもな変更点は以下のとおりです。
機能改善
・サブモデル欄の記入フォーマットを簡略化しました。
バグ修正
・生成エンジンがJennyの場合、制約表が表示されていない状態で、パラメータが記入されたパラメータ欄に対応する制約表のパラメータ欄に空白の欄があると、「○○行目のパラメータ欄に記入がありません」とのエラーメッセージが表示される場合があるバグを修正しました。
・生成エンジンがPICTの場合、制約表が表示されておらず、確認表のみ表示されていると、確認表の機能が正常に動作しないバグを修正しました。
以上です。
それでは、また。
訂正： デシジョンテーブルテストと組み合わせテストの統合
テスト対象が複雑な論理を含み、同時に他のパラメータとの組み合わせをテストする必要がある場合、DTの各ルールに対して組み合わせをテストすることになります。
DTのルール数が多いと、そのまま組み合わせを行なったのではテストケース数が多くなりすぎます。例えば、DTのルールが１０個で、それと組み合わせるパラメータが３つあり、それぞれ５個の値を持つとした場合、単純に組み合わせると、５×５×５×１０=１２５０件にもなってしまいます。
そこで、テストケース数を合理的に削減するために、DTのルールも組み合わせテストのパラメータの１つとして扱い、全体を組み合わせテストの対象とします。この方法ではDTの各ルールが値になります。
こうしてAllPairIIで組み合わせテストを行なうと、全体のテストケース数は５０件となります。このときDTの各ルールは、他のパラメータとの２パラメータ間の組み合わせを網羅したものとなります。
別の方法として、DTはパラメータから除き、３つのパラメータだけで組み合わせテストケースを作成し、それとDTの各ルールを全数組み合わせるという方法もあります。この方法では、全体のテスト件数は２５×10=２５０件となります。テスト件数は多くなりますが、DTの各ルールは、他のパラメータとの３パラメータ間の組み合わせを網羅したものとなります。パラメータの組み合わせ数が少ない場合は、この方法が良いかもしれません。
※ ユーザーズマニュアルの「デシジョンテーブルテストと組み合わせテストの統合」という章で、メンドウな方法が書かれていますが、それは無視して下さい。次のバージョンではマニュアルの記述を修正します（苦笑）。
AllPairIIの既知の問題点
・確認表が正常に動作しない場合がある。
生成エンジンがPICTで、制約表が表示されておらず、確認表のみ表示されている状態では、確認表の機能が正常に動作しません。
このバグへの対処は、確認表を使用する場合、制約表も表示しておくことで回避できます。
他の問題点については過去のテーマ「最新Ver.既知の問題」の記事を参照ください。
このバグは、次回のバージョンアップ時に対処します。