メディア

テスト設計の基本とさまざまなテスト技法-1：ソフトウェアテスト・エンジニアの本音（2）（2/2 ページ）

» 2004年12月03日 12時00分公開

[大西建児，株式会社豆蔵]

前のページへ 1|2 　　　　　　

解説パート

テスト設計の基本、重要な3つの観点

　モデルベースのテスト技法の話をする前に、テスト設計の基本を知っていただくための、重要な3つの観点について説明しましょう。

より少ないテストケースで
より多くバグが見つかるようにして
テスト対象を漏れがないように網羅する

　これらを満たしたテストを設計するために、テスト技法を活用します。ここではいくつか基本的なテスト技法を紹介しましょう。なお、テスト技法について詳細を知りたい方はボーリス・バイザー著の「ソフトウェアテスト技法」（日経BP）を読まれることをお勧めします。

　「より少ないテストケース」にするために必要な考え方の基本として「同値クラス」があります。同値クラスは、テストに使う入力値が、同様の結果をもたらす場合、その入力値を「同値」と呼ぶことからきています。例えば、1けたの整数2つを足し算するプログラムがある場合を考えてみましょう。「1+1」「1+2」……と全整数のパターンを網羅するテストしようとすると……、9×9=81パターンのテストが考えられます。

　この場合、1けたの数字と1けたの数字を足して整数が結果として返っているだけですから「1+1=2」と返ってくれば、論理的に考えると「2+2」も「3+5」もそのほかも正しい結果が返ってくると考えられます。つまり、足し算の処理は同様の結果をもたらしているといえます。従って、すべての入力が同様の結果をもたらすならば、代表をいくつか選んでテストすれば81回もテストをしなくてよいという考え方が成り立ちます。同値クラスの考えでは、このような発想に基づき、同じ性質を持つ値を一まとめにして扱います。

　「より多くのバグが見つかる（を見つける）」ための基本的な技法として「境界値テスト」があります。同値クラスの中から代表を選ぶときに「端っこ」、つまり、境界の値を選ぶため、こういう呼び方になりました。なぜ、端っこの値を狙ったテストで、多くのバグを見つけられるのか考えてみましょう。答えは意外と簡単で、境界の値の定義は要求分析から実装のどの段階でも勘違いしたり、間違えたりしやすいからです。不等号である「＞」と「＝＞」の定義ミスによる間違いというのは誰でも経験したことがあると思います。例えばある数字「以上」と仕様書には記載してあるのに、開発者が「未満」だと思い込んで作り込むケースがあったとします。この場合、「端っこ」の値をテストすれば簡単にバグを見つけることができるはずです。

　“不等号の間違い”という単純なミスをすることなど考えもしないかもしれません。その結果、こういったテストをせずにテスト作業そのものを終わらせてしまい、後で痛い目をみることになります。このような不幸を防ぐためのテストが境界値テストです。

　基本的なテクニックを紹介したところで、本題であるモデルベースのテスト設計の考え方について解説しましょう。

さまざまなテスト技法の解説

　テスト対象を漏れなく網羅するための技法には、テスト対象の仕様をすべてリストアップし、テストの漏れや抜けを防ぐ「リスト網羅」や、テストの要素を行と列の表で表現することで同様の効果を狙う「マトリクス網羅」があります。シンプルなアプローチでは表現しにくい仕様、つまりモデル化された仕様をテストするために用いるのがモデルベースのテスト技法です。仕様書などで、テスト設計前にモデルが存在している場合もあれば、テストを設計するエンジニアがテストのために、仕様書や設計書などからモデリングする場合もあります。

　よく使われる代表的な技法に、状態遷移テストがあります。状態遷移テストは、ソフトウェアの振る舞いをUMLでのステートチャート（ステートマシン図）のようなモデルに表現して、そのノードとリンクを網羅することです。携帯電話を例に考えてみましょう。携帯電話は待受状態のときに電話がかかってくると着信状態になり、着メロが鳴ります。「着信中に着メロが鳴る」という状態（ノード）は「電話がかかる」というイベント（リンク）によって導かれます。しかし、通話中であれば「電話がかかる」というイベントがあっても着メロにはならず、キャッチ状態になります。

　このように、同じイベントでも前の状態により次に「遷移する」状態は異なります。従って「前の状態とイベント」ごとに導かれる状態が正しい結果になっていることを網羅しないとテストとしては不十分になります。そうならないようモデルを使って網羅するのが「状態遷移テスト」です。

　モデルを基にしたテストを英語で書くと、Model-Based Testingと表します。MicrosoftのHarry Robinson氏が運営しているModel-Based TestingというWebサイトをご参照ください。

　人間が手でテストを実施するのは時間の制約で無理な場合があります。実際、状態遷移表によってテストを設計すると、テスト項目が数千とか数万になるということもあります。そこで、テスト実行を自動化することで、大量のテストケースをこなしたり、テストケースの数を論理的に減らすというアプローチ（直交表がこれに該当します）を取ることになります。もう少し具体的に説明しましょう。

　状態遷移モデルの場合、モデル化することでイベントとアクションと状態が論理的に明確になります。論理的に定義し切れているため、テストケースを自動生成することができます。これに入力データと期待出力結果があれば、テストの自動実行も可能となります。市販のテストツールにもこういった機能を有する製品は存在します。

　次にテストケースの数を減らす方法ですが「より多くバグを見つける」テストケースを選択して優先的に実施する方法があります。このためにはモデルの中からバグが出そうなところを見つける必要があります。

　「変則パス」と呼ばれるイレギュラーなパターンを探す方法もあります。イレギュラーなパターンとは、正しく処理されずにエラーになっていったときのパターン（いわゆる例外処理）などのことを指します。

　バグの傾向を分析して、どんな間違いをしやすいかを見つけていく方法もあります。これは、実際のバグの発生傾向がプロジェクトによってまちまちだという考えに基づくものです。バグを分析すると、特定部分（機能やモジュール）に集中していることは多いでしょう。その原因はさまざまです。実は開発担当者がよく入れ替わっていたとか、レビュー不足のままコーディングに入っていたりとか、開発者の個人の資質に基づくものであったりしますが、人的要因か外的／内的要因なのか結局はケースバイケースです。バグの発生原因に傾向があるならば、きちんと分析すれば特定部分を見つけることができます。いい換えれば、バグが多いテスト対象の弱点を集中的にテストすることで、効率よくバグを見つけることができるようになるのです。

グラフ（モデル）を見たら……網羅せよ！

　テストケースの自動生成や自動実行をする／しないにかかわらず、モデルベースでテスト設計を行うことは、合理的に網羅性を確保するための必須テクニックです。

　例えば、システムテストで行われる、業務フローやユーザー手順に沿ったテストでは、業務フローをフローチャートやUMLでのユースケース図、アクティビティ図に表し、モデル化します。モデル化された仕様をテストするには、それに応じたテスト技法が必要となります。

　制御パステストならば、プログラムのパスをフローとして表したものを網羅するためのテストですから、いい換えるとコードをモデル化して網羅していることといえるでしょう。先ほど紹介した「ソフトウェアテスト技法」を著したボーリス・バイザーの言葉にこのようなものがあります。「グラフ（モデル）をみたら……網羅せよ！」

　モデルベースのテスト技法を使いこなすには、テスト設計をするエンジニア自身が、仕様書や設計書にあるモデルを理解したり、そこからテストに必要なモデルを導き出すスキルが要求されます。貧弱なモデルをベースにテスト設計しても、貧弱なテストケースしか作れません。それどころか、肝心な仕様が「ごそっと」漏れているモデルに頼ると、当然、必要なテストが「まるまる」抜けてしまうことになるでしょう。

　モデルベースのメリットやデメリットは、前回記事「モデル駆動型ソフトウェアテストの可能性」の解説パートで触れたとおりでモデルを基にしたテスト設計にも限界があります。特に性能やセキュリティなどの非機能要件はモデルでは表現できません。だからこそ人間でなければできない高度な検証というのは、これからも残っていきます。モデルベースでテストを設計し、実施するエンジニアにはこれまで以上のモデリングスキルが要求されるようになることでしょう。

参加者

［JaSST 実行委員会］

共同実行委員長古川善吾（香川大学）

共同実行委員長西康晴（電気通信大学）

［実行委員］

秋山浩一（富士ゼロックス）

大月美佳（佐賀大学）

大西建児（豆蔵）：本記事取りまとめ担当

大野晋（日立ソフトサービス）

片山徹郎（宮崎大学）

榊原彰（日本IBM）

鈴木太平（プラネット）

鈴木三紀夫（TIS）

高橋寿一（ソニー）

野村絵里（JaSST）

古長由里子（日本IBM）

松岡正人（日本IBM）

湯本剛（サイクス）

和田憲明（富士通）

敬称略（50音順）

「ソフトウェアテスト・エンジニアの本音」バックナンバー