第6回 カバレージを考慮した機能試験の自動化（その1）：理論的・計画的なWebアプリケーションのテストの実現（1/2 ページ）

今回からより実践的な内容に話を移し、カバレージを考慮した機能試験の自動化について解説する。機能試験の自動化を意義あるものにするにはどうすればよいのだろうか。

[加藤大受，ITmedia]

前回のまとめ

　前回まででドキュメント試験、ユーザビリティ検証、信頼性試験、強制エラー試験などを除き、一般的なテストアイテムについて解説した。説明していないテストアイテムについては具体的な話の中で説明していきたい。

　すでに何度も述べているように、テストはプロジェクト内の1つのサブプロジェクトとして考え、テスト計画書を作成し、工数、タスク、スケジュール、リスク内容、責任範囲などを明確にしてから行うものである。また、プロジェクトの設計フェーズではレビューを行い、できるだけ上位の工程で仕様のあいまいな部分、設計から派生する脆弱性の問題などを見つけ出すようにし、実装フェーズでは検証によって不具合がないことや不具合の修正が他の不具合を引き起こしていないことを検証してほしい。テストとは妥当性（Validation）と検証（Verification）の両面を考慮し、構築しているシステムの品質を測定するものなのである。

　さて、今回からはより実践的な内容に話を移し、カバレージを考慮した機能試験の自動化について解説していこう。

機能試験の自動化について

　xUnitなどを使って単体テストの自動化をすでに行っている方も多くおられることだろう。ユニットテストを作成することで、実装時や修正時のケアレスミスの検証、新規の機能追加の実装時や既存機能の修正時などでほかのモジュールなどに影響を与えていないかなどの検証を行えるだけでなく、複数のプラットフォームで稼働するプログラムの場合ではプラットフォーム間での機能の差違がないかどうかを確認できる。

　では機能テストを自動化した場合はどうだろうか。StrutsなどのMVCフレームワークを利用した場合、コントローラ部分のみユニットテストを実施し、ビューやモデルについてユニットテストを実施していない方も多いのではないだろうか。確かにコントローラ部分のコードだけでもユニットテストを実施することは望ましいが、外部仕様となる機能レベルでのテストを自動化し、何度も実施する方がはるかに品質は向上する。特にアジャイルなどの開発プロセスを導入し、リファクタリングを行っているケースなどでは、機能試験が自動化されていると品質の低下（デグレード）をすぐに発見できるため、大幅な工数の削減につながる。

　また、自動化された機能試験は受け入れテスト（アクセプタンステスト）として利用できる。リファクタリングを繰り返し、精査していくプロセスや同一プログラムを複数のプラットフォームで実施する必要性などがあればあるほど、機能試験の自動化は効果を発揮するだろう。

本当に機能試験を100％網羅しているか

　多くの開発者は機能試験は100％網羅していると言うことが多いが、この100％という数値の根拠はどこにあるのだろうか。この根拠を明確にするにはカバレージ（網羅率）をどのように測定するかの規定が必要となる。

　一般的に機能試験を設計するときにはテスト設計カバレージとテスト実施カバレージを考慮する必要がある。テスト設計カバレージは、テストを行うすべてのパターンを洗い出し、テストケースを作成していく。テストケースを作成するときには優先順位を設定し、できればテスト実施の難易度についても記載しておくのがいいだろう。テスト実施の難易度を3から4段階に分けて設定しておけば、テスト実施工数の算出がしやすくなるだろう。

　ではテスト実施の難易度はどのように設定すればいいのだろうか。一番簡単な方法としては次のような考え方である。

• 実装に時間がかかる機能
• 複数の機能との連携によって動作する機能
• 複雑な条件を必要とする機能

　初めはこのようなルールをベースに各テストケースに難易度を設定し、データを取得しながら徐々にルールを明確にしていくのがいいだろう。

　同様に優先順位の考え方についてだが、こちらはすでにこの連載の中で多少説明しているように、テスト対象となる機能の優先順位をベースに考えればいいだろう。ただし、1つの機能を検証するには複数のテストケースを必要とする。たとえその機能の優先順位が高いからといって、その機能を検証するすべてのテストケースに高い優先順位を与えるべきではない。同一機能のテストケースであっても入力値や条件などによって優先順位を変える必要がある。

　テストケースに優先順位と難易度を設定することで、「テストケースの実施工数＝優先順位×難易度」というルールを策定し、工数を算出してみるのもいいだろう。

　また、予想される不具合についても優先度をベースに次のようなケースを想定し、シミュレートしてみるのもいいだろう。ここでは非常に単純化するために分かりやすい係数を設定している。この係数については実際の不具合が発見されたケースから分析してみるといいだろう。

• 優先順位がAならば50のテストケースで1つの不具合が見つかる
• 優先順位がBならば100のテストケースで1つの不具合が見つかる
• 優先順位がCならば300のテストケースで1つの不具合が見つかる
• 難易度がAの場合は不具合が発見される可能性は優先順位に従い、さらに150％高くなる
• 難易度がBの場合は不具合が発見される可能性は優先順位に従う
• 難易度がCの場合は不具合が発見される可能性は優先順位に従うが50％低くなる

　例えば1500のテストケースにおいて、上記で想定したケースを当てはめてみたシミュレーション例を以下に示す。

優先順位 難易度 テストケース数 A A 100 A B 150 A C 200 B A 50 B B 300 B C 100 C A 100 C B 200 C C 300

　この場合、不具合の発生数は次のように計算できる。

発見される不具合数= 100/50×1.5+150/100+200/300×0.5                     + 50/50×1.5+300/100+100/300×0.5                     +100/50×1.5+200/100+300/300×0.5                     = 15

　テストケースに優先順位と難易度を設定することで不具合の発見数をある程度予想できることが分かるだろう。