ソフトウェアテスト基本テクニック

第3回 ホワイトボックステスト

この記事を読むのに必要な時間:およそ 3 分

はじめに

プロジェクトの終盤にさしかかるテスト工程では,期間的にも予算的にも切迫した状態となる場合が多いのではないでしょうか。そういった状況ではとくに,どんなテストで何を確認するか,というテストケースは無駄なくそして漏れなく作成したいものです。連載の第3回目となる今回は,テストケース作成技法の1つ,ホワイトボックステストについて取り上げます。

ホワイトボックステストとカバレッジ

ホワイトボックステストは,テスト対象の構造に着目してテストケースを作成する技法です。設計や実装の内容から内部構造(処理経路)を網羅するようにテストケースを作成します。そして,作成したテストケースは,どれくらい処理経路を網羅しているかを評価することが重要です。この処理経路の網羅度合についての基準をカバレッジ(網羅率)といい,ホワイトボックステストでは,目標とするカバレッジを満たすように効率よくテストケースを設計していきます。

たとえば,単体テストではテスト対象の構造とはソースコードそのものとなり,命令文や条件判定を行っているif-else文など各コードが実行されるようにテストケースを考えます。このソースコードに着目する場合のカバレッジをコードカバレッジといい,命令文や判定条件の網羅度合に応じていくつかの種類があります※1)。本稿では,リスト1のJavaのサンプルコードを例に,表1に挙げた3つのコードカバレッジとそれに対応するテストケースについて説明していきます。

※1)
文献によって各カバレッジの定義は異なる場合があります。

表1 本稿で取り上げるコードカバレッジ

コードカバレッジの種類 説明
ステートメントカバレッジ ソースコード中の命令文が実行されたかどうかに着目したカバレッジ
ブランチカバレッジ ソースコード中の判定条件の結果に着目したカバレッジ
コンディションカバレッジ ソースコード中の条件文の結果に着目したカバレッジ

リスト1 本稿で利用するサンプルコード

public boolean[] doSample01(String param) {

    boolean[] result = new boolean[] {false,false};
    //条件① 引数がnullか文字列長が2文字未満の場合
    if (param == null || param.length() < 2) {
        throw new IllegalArgumentException("param is illegal.");
    }

    //条件② 引数の文字列の1文字目が「a」の場合
    if (param.charAt(0) == 'a') {
        result[0] = true;
    }

    //条件③ 引数の文字列の2文字目が「b」で,かつ最後の文字が「z」の場合
    if (param.charAt(1) == 'b' && param.charAt(param.length()-1) == 'z') {
        result[1] = true;
    }
    return result;
}

ステートメントカバレッジ

ステートメントカバレッジは命令網羅とも呼ばれ,テスト対象のすべての命令文(ステートメント)について,テストによってどれくらい実行されたかを評価します。開発現場ではC0カバレッジと呼ばれることが多いでしょう。サンプルコードの場合では,表2のような2つのテストケースを作成すると命令文がすべて実行され図1),ステートメントカバレッジが100%となります。

図1 サンプルコードのフローチャート

図1 サンプルコードのフローチャート

表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%になります。

図2 サンプルコードのフローチャート

図2 サンプルコードのフローチャート

表3 ブランチカバレッジが100%となるテストケース

テストケース番号 入力引数paramの値 判定条件①の結果 判定条件②の結果 判定条件③の結果 戻り値 (出力結果)
TC1 null true 例外
TC2 abz false true true 配列 {true,true}
TC3 ccc false false false 配列 {true,true}

著者プロフィール

木村聡宏(きむら あきひろ)

NTTデータ先端技術株式会社勤務。
大手SI企業で約8年間JavaによるWebアプリケーションの開発に携わった後,現職へ。現在はテストプロセスの改善を行う業務で,主に単体テスト支援ツールの開発に従事している。

コメント

コメントの記入