はじめに
プロジェクトの終盤にさしかかるテスト工程では、期間的にも予算的にも切迫した状態となる場合が多いのではないでしょうか。そういった状況ではとくに、どんなテストで何を確認するか、という「テストケース」は無駄なくそして漏れなく作成したいものです。連載の第3回目となる今回は、テストケース作成技法の1つ、ホワイトボックステストについて取り上げます。
ホワイトボックステストとカバレッジ
ホワイトボックステストは、テスト対象の構造に着目してテストケースを作成する技法です。設計や実装の内容から内部構造(処理経路)を網羅するようにテストケースを作成します。そして、作成したテストケースは、どれくらい処理経路を網羅しているかを評価することが重要です。この処理経路の網羅度合についての基準をカバレッジ(網羅率)といい、ホワイトボックステストでは、目標とするカバレッジを満たすように効率よくテストケースを設計していきます。
たとえば、単体テストではテスト対象の構造とはソースコードそのものとなり、命令文や条件判定を行っているif-else文など各コードが実行されるようにテストケースを考えます。このソースコードに着目する場合のカバレッジをコードカバレッジといい、命令文や判定条件の網羅度合に応じていくつかの種類があります[1]。本稿では、リスト1のJavaのサンプルコードを例に、表1に挙げた3つのコードカバレッジとそれに対応するテストケースについて説明していきます。
表1 本稿で取り上げるコードカバレッジ
コードカバレッジの種類 |
説明 |
ステートメントカバレッジ |
ソースコード中の命令文が実行されたかどうかに着目したカバレッジ |
ブランチカバレッジ |
ソースコード中の判定条件の結果に着目したカバレッジ |
コンディションカバレッジ |
ソースコード中の条件文の結果に着目したカバレッジ |
ステートメントカバレッジ
ステートメントカバレッジは命令網羅とも呼ばれ、テスト対象のすべての命令文(ステートメント)について、テストによってどれくらい実行されたかを評価します。開発現場ではC0カバレッジと呼ばれることが多いでしょう。サンプルコードの場合では、表2のような2つのテストケースを作成すると命令文がすべて実行され(図1)、ステートメントカバレッジが100%となります。
表2 ステートメントカバレッジが100%となるテストケース
テストケース番号 |
入力引数paramの値 |
判定条件①の結果 |
判定条件②の結果 |
判定条件③の結果 |
戻り値(出力結果) |
TC1 |
null |
true |
- |
- |
例外 |
TC2 |
abz |
false |
true |
true |
配列 {true,true} |
ブランチカバレッジ
ブランチカバレッジは分岐網羅とも呼ばれ、テスト対象のすべての判定条件について、テストによってどれくらい実行されたかを評価します。開発現場ではC1カバレッジと呼ばれることが多いでしょう。各判定条件については、複数の条件文がANDやORなどで組み合わされる場合、個々の条件文を結合した結果が「true」の場合と「false」の場合の両方が実行されれば網羅されたことになります。
先ほどのステートメントカバレッジの2つのテストケース(表2)では、条件②と条件③の結果がfalseになる場合が実行されていませんので、ブランチカバレッジは100%になっていません。そこで、表3のように3つのテストケースを作成すると、(個々の条件文を結合した)各判定条件の「true」と「false」が実行され(図2)、ブランチカバレッジが100%になります。
なお、このサンプルでもわかるとおり、ブランチカバレッジはステートメントカバレッジよりも強い評価基準となり、ブランチカバレッジが100%の場合は、必然的にステートメントカバレッジも100%になります。
表3 ブランチカバレッジが100%となるテストケース
テストケース番号 |
入力引数paramの値 |
判定条件①の結果 |
判定条件②の結果 |
判定条件③の結果 |
戻り値
(出力結果) |
TC1 |
null |
true |
- |
- |
例外 |
TC2 |
abz |
false |
true |
true |
配列 {true,true} |
TC3 |
ccc |
false |
false |
false |
配列 {true,true} |
コンディションカバレッジ
コンディションカバレッジは条件網羅とも呼ばれ、テスト対象のすべての判定条件が、テストによってどれくらい実行されたかを評価しますが、判定条件部分の網羅基準がブランチカバレッジとは異なります。コンディションカバレッジでは、複数の条件文が組み合わされている場合、個々の条件文について「true」の場合と「false」の場合の両方が実行されれば、網羅されたことになります。
サンプルコードの場合では、表4のような4つのテストケースを作成すると、個々の条件文について「true」と「false」がすべて実行され、コンディションカバレッジが100%となります。なお、表4の例ではコンディションカバレッジは100%となるものの、ブランチカバレッジは100%とならないことに注意してください。
表4 コンディションカバレッジが100%となるテストケース
テストケース番号 |
入力引数paramの値 |
判定条件① |
条件②の結果 |
判定条件③ |
戻り値(出力結果) |
条件①-1の結果 |
条件①-2の結果 |
条件③-2の結果 |
条件③-1の結果 |
条件③-2の結果 |
TC1 |
null |
true |
false |
- |
- |
- |
例外 |
TC2 |
a |
false |
true |
- |
- |
- |
例外 |
TC3 |
abc |
false |
false |
true |
true |
false |
配列{true,false} |
TC4 |
xyz |
false |
false |
false |
false |
true |
配列{false,false} |
本稿では説明しきれませんでしたが、もっと評価基準の厳しい、複合条件カバレッジやパスカバレッジなどがありますので、状況に応じて使い分けるのがよいでしょう。
ホワイトボックステストを活用しよう
さて、ホワイトボックステストとカバレッジは、実際のテストの中でどのように活用できるでしょうか。
まず、目標とするカバレッジに沿って、効率よくテストケースを設計することができます。本稿ではコードカバレッジとともに単体テストの例を取り上げましたが、統合テスト(結合テスト)やシステムテスト(総合テスト)といった他のテストレベル(工程)においても利用することができます。たとえば、統合テストではモジュール間の呼び出しに、システムテストではサブシステムやユースケース間の処理経路に着目したテストケースを作成できます。
ホワイトボックステストでどの処理経路に着目するかは各テストレベルによって異なりますが、すべてのテストにおいて効率的なテストケースの作成に活用することができます。
また、カバレッジ計測によってテストが実行されない部分を発見できるため、
- 作成したテストケースに漏れがないか
- 不要な処理経路はないか
といったことが確認できます。さらに、数値化されたカバレッジをテスト対象の品質やテストの終了条件などの1つの判断基準としても利用することができます。
ただ、ホワイトボックステストはあくまで内部構造に対するテストであり、「仕様通りに動作する」ためのテストではありません。まずは「仕様通りに動作する」ことのテストをしっかり行ったうえで、カバレッジと組み合わせてテストケースの漏れを補うといった形で利用するのがよいでしょう。
カバレッジ計測ツール
最後に、Javaのコードカバレッジを計測するツールを2つご紹介します。他にも様々なカバレッジ計測ツールがありますので、言語やプロジェクトの特性を考慮して利用しやすいツールを採用してください。
メソッドレベルまでのカバレッジを確認することができ、ソースコードの実行状況(テスト対象の網羅度合)が3色でハイライト表示されます。Eclipse プラグインとして利用できるEclEmmaも提供されており、こちらはEclipseCon 2008にて、Best Open Source Eclipse-Based Developer Toolに選ばれています。
Antタスクあるいはコマンドラインからバッチ実行することができるので、開発サーバ上で定時実行などを行いやすいカバレッジ計測ツールです。実行結果はXML又はHTML形式でレポート出力されるため、定時実行された結果をプロジェクトサイト上などに自動反映し、メンバ間で共有するような環境も容易に構築できます。
まとめ
テストケース作成技法の1つであるホワイトボックステストは、カバレッジと組み合わせることで効率よくテストを進めることができます。作成したテストケースについて漏れや重複が気になる方はぜひ活用してみてください。
次回は、「仕様通りに動作する」ことを確認するためのテストケース作成技法、「ブラックボックステスト」について紹介します。