資料を漁ってたら、３年前くらいに"単体テスト項目書"を作成するにあたってのレクチャーを受けた時のメモが出てきたので、ここにまとめておきますね。
単体テスト項目書の作成の流れ
ここでいう単体テスト(モジュールテスト)とは、実装したメソッド(モジュール)に対して、仕様通りの動作となっているかを確認することです。
単体テスト項目書は、テスト項目(どんなオペレーションをして、何を確認するか)を明記した資料です。
ブラックボックステスト
ブラックボックステストって何を確認するの？
ブラックボックステストとは、データの出力パターンを確認するテストです。
入力値と、実行した結果を、仕様と比較することによって、入力と出力の関係/関連が仕様通りかを確認します。
また、無差別に入力データを決定すると、本来必要なパターンが抜けたり、余分なパターンが紛れ込んでしまうため、
そんな無駄を防ぐために、試験として妥当なパターンを定義します。
ブラックボックステストの粒度とは？
ブラックボックステストの粒度は、観点に対するテスト項目の数で決まります。
入力データの選定
仕様に定義されているモジュールの引数の仕様より、入力値(テストデータ)を決めます。
入力値を決める際に、下記の観点にて洗い出すことで、効率的な入力値を設定できます。
境界値
- 期待する範囲の最大値、最小値(例：月の場合、1と12)
- 変数の最大値や最小値
固定値
- 期待する区分値
異常値
- 期待する区分値以外の、null、0、半角/全角スペース、ブランク文字などの、よくあるやっといて損はないだろう値
- 期待する範囲の最大値、最小値の外側(例：月の場合、0と13)
- 変数の最大値や最小値の外側
- 数値を期待する場合、数値以外の文字列
出力値ってどこからわかるの？
仕様に定義されているはずです。
もし記されていない場合は、仕様を決めた人、または自分の心に聞きましょう。
必要なnullチェックとか忘れてたなら、いさぎよくバグ票を起票しましょう・・・
ホワイトボックステスト
ホワイトボックステストって何を確認するの？
ホワイトボックステストとは、構造化プログラミングにおける、順次、分岐、繰り返しのルートをすべて実行するテストパターンを用意し、意図したルートを通っているか確認するテストです。
ソースコードの全行を網羅することで、意図しない処理や実行エラーの発生がないかを確認します。
ホワイトボックステストの粒度とは？
下記パターンを確認して、パスの通過(カバレッジ=網羅率)を高めるテストを行うことで、プログラムの細部までの保障が可能となります。
カバレッジパターン
- C0レベル ・・・ 処理経路を構成するすべての命令を最低1回実行します。
- C1レベル ・・・ すべての条件分岐の真と偽の両方を最低1回実行します。
- C2レベル ・・・ 条件分岐の真と偽のすべての組み合わせを実行します。繰り返しも複数回実行します。
アプリケーションの修正によって、分岐が追加になったり消えたりした場合は、対象メソッドについてホワイトボックステストのパターンを洗い出し直して、全てやり直します(自動テスト化してあると楽です)
そもそもどうやって確認するの？
分岐ごとにデバッグログを埋め込んで、正しいパターン表示となっているかを確認します。
public String hoge(String argString1) { // デバッグログ(メソッド名_パス階層分の連番) logger.debug("hoge_1"); // 定義 String returnString = "引数は "; // 引数の状態を表示する if ( argString1 == null ) { // デバッグログ(メソッド名_パス階層分の連番) logger.debug("hoge_1-1"); returnString += "null"; } else if ( "".equals(argString1) ) { // デバッグログ(メソッド名_パス階層分の連番) logger.debug("hoge_1-2"); returnString += "blank"; } else { // デバッグログ(メソッド名_パス階層分の連番) logger.debug("hoge_1-3"); returnString += "文字列"; } // デバッグログ(メソッド名_パス階層分の連番) logger.debug("hoge_2"); returnString += " でございます。"; return returnString; }
または、djUnitなどのカバレッジ測定ツールを使用する方法もあります。
djUnit - dJWiki
試験項目書の作成
次に、ホワイトボックスとブラックボックスの観点から、テストの確認事項を洗い出してみましょう。
パス一覧と出入力表を作成します。
パス一覧の作成
ホワイトボックステストの観点での確認をパス一覧にします。
ソースコードの分岐箇所を元に、C2レベルでパスのパターンを一覧に起こします。
通過ログをもとに、
パス1
1
1-1
2
パス2
1
1-2
2
...
といった具合にあげていきます。
出入力表の作成
次に、ブラックボックステストの観点での確認を出入力表にします。
出力パターンを一覧にして、それに対する入力パターンを並べます。
出力パターンとは、正常系出力、業務異常系出力(期待しない結果、またはエラー)、実行時異常系出力(エラー)のことです。
| 出力 | 入力 |
|---|---|
| "引数は null でございます。" | null |
| "引数は brank でございます。" | "" |
| "引数は 文字列 でございます。" | "1" |
| "引数は 文字列 でございます。" | "0" |
| "引数は 文字列 でございます。" | "あああ" |
といった問い合った具合にあげていきます。
両表を紐づけて、試験項目書とする
その後、パス一覧と出入力相対表を紐づけます。
| 試験ID | 出力 | 入力 | パス |
|---|---|---|---|
| 1 | "引数は null でございます。" | null | 1 |
| 2 | "引数は brank でございます。" | "" | 2 |
| 3 | "引数は 文字列 でございます。" | "1" | 3 |
| 4 | "引数は 文字列 でございます。" | "0" | 3 |
| 5 | "引数は 文字列 でございます。" | "あああ" | 3 |
といった具合に紐づければ、試験項目書の完成です！
作成中の気を付けるコト
試験項目の抜け漏れを防ぐために、以下で確認します。
- ソースコードと処理パターン表を突合せて、全通過パターンを網羅できているかを確認します。
- ソースと入出力相対表を突合せて、出力と入力のパターンが網羅されているかを確認します。
- パス一覧と入出力相対表を突合せて、全てのパターンが紐づけされているかを確認します。
- 出入力相対表と試験項目書を突合わせて、全てのパターンが書き出されているかを確認します。
おわりに
以上の作業を、末端のモジュールから行っていきます。
この作業をすると、ソースをじっくり読むので、机上レビューをついでに行えますー。
が、仕様通りの実装かは確認できるのですが、仕様が正しいかという観点での確認は行えませんです。。
あとは、境界値のバリエーションが増えたらいいなぁー。
追記(2014/06/11)
心優しい先輩が突っ込んでくれたので、色々直してすます。
文章って難しい。。
