プログラムのコーディングが完了した直後のテスト「単体テスト」。
単体テストは、プログラムを書いたことのある人なら誰しもが経験をしたことのあるテストだろう。
しかしながら、テストの観点やエビデンスの採取」について悩んだこともあるはずだ。
そこで今回は、単体テストの基本的な知識を記載したので参考にしてほしい。
単体テストの目的
単体テストの目的は、コーディングしたプログラムを1本ずつ個別に実行し、不具合（ロジックのミス）を取り除くことである。
一般的には、ロジックの条件分岐を網羅するテストを行うため、結合テストや総合テストなどの他のテスト工程と比較しても、圧倒的にテストケースが多くなる。
ダメなプロジェクトマネージャは、「単体テストは少なめにして、結合テスト以降で不具合を抽出すればいい」と言うが、これは絶対にやめよう。
各テスト工程は、それぞれでテストの観点が異なるため、単体テスト工程の不具合を結合テストでは検出しきれないからだ。
単体テストの観点と手法
前述したように、単体テストは一般的にホワイトボックステストの条件分岐の網羅の観点からテストを行う場合が多い。
条件分岐を網羅しておけば、プログラム単体の品質はほぼほぼ確保できたと言えるからである。
しかしながら、条件分岐を網羅したとしても、一定の不具合が残ってしまう場合もある。
これはホワイトボックステストの”他の観点“が漏れてるからだ。
そこで、ここではホワイトボックステストの”他の観点“についても紹介しておこう。
観点と技法（ホワイトボックス）
| テストの観点 | テスト技法 |
|---|---|
| ロジックの条件分岐に着目する | 条件網羅テスト |
| 変数の定義→参照→消滅に着目する | データフローテスト |
| 状態（実行前/実行中/実行後)に着目する | 状態遷移テスト |
| リソース（メモリやディスク）に着目する | リソーステスト |
ホワイトボックステストというと、条件分岐網羅の印象が強いが、それ以外にもテストの観点はある。
基本的には、条件網羅を実施しておけば良いだろうが、開発するプログラムによってはどの観点を追加で実施するかは考えた方がいいだろう。
ホワイトボックスとは別に、プログラムの内部に着目しないテスト技法として”ブラックボックステスト“というものもある。
入力の有効値と無効値に着目したテストケースを設けるのが一般的だ。
単体テスト仕様書の項目と書き方
単体テストを実施するにあたって、単体テスト仕様書（単体テストケース）を作成する。
基本的には、過去のプロジェクトの成果物をもとに作成することになるだろうが、ここでは一般的な項目や書き方について紹介しておく。
単体テスト仕様書には、下記の項目を記載する。
・分類
・テストケース
・確認内容
・テスト実施者、確認者
・テスト実施日
分類、テストケース、確認内容の3つをプログラム毎に考えることになる。
| 分類 | テストケース | 確認項目 |
|---|---|---|
| 画面遷移 | 画面を表示 | 画面表示の初期値が設計書通りになっていること |
| 権限 | ユーザー毎に表示 | 権限に応じて画面表示が切り替わっていること |
| カーソル | タブ入力 | タブ入力でカーソルが移動すること |
| カーソル | エンター入力 | エンター入力によって機能が実行されないこと |
| メッセージ | 照会正常 | メッセージが設計書通りであること |
| メッセージ | 照会件数オーバー | メッセージが設計書通りであること |
実際のテスト仕様書では、もっと具体的に書いた方がいいだろう。
テストケースは、「照会を正常実施」という記載では、どのような照会かが分からない。検索条件ぐらいは記載しよう。
また、確認内容も「設計書通りであること」という記載では、設計書を見ないと結果が分からないので、想定される結果を記載した方がいいだろう。
単体テスト結果のエビデンス
単体テストを実施する際に最も面倒なのが、エビデンスを取ることだ。
テストを実施する以上に、エビデンスを採取していくのには時間を要する。
「エビデンスを印刷して紙で残す」という文化があれば、地獄のような作業時間が必要になるだろう。
エビデンスを残すのは、下記のような理由があるとされる。
・レビュー時の確認資料
・障害発生時の原因分析資料
まず1つ目だが、悪い担当者だとテストを実施していないにも関わらず、「テスト完了」とする可能性があるため、テスト実施の証拠としての効果がある。
2つ目は、第三者がテスト結果を確認することで、担当者が気づかないような不備を検出できる可能性がある。
そして3点目は、後続のテスト工程で障害が発生した際に、「なぜ単体テストで気づかなかったのか？」という原因分析をするのだが、その際の分析資料として利用できる。
このように、単体テストのエビデンスを取ることは一定の効果があると言える。
ただ、冒頭で述べたように単体テストは、他のテスト工程と比べてもテストケースが多くなるため、エビデンス採取の時間も多くなってしまう。
絶対に避けたいのは、エビデンスを取得する時間に追われて、テストが不十分になること。
エビデンスを取る必要があるのかは、組織のルールや契約によってことなると思うので、状況によって判断してほしい。
さいごに
単体テストの目的や観点など、基本的な知識を説明してきた。
単体テストは、他のどのテスト工程よりもテストケースが多いこともあり、最も不具合を検出できるテストだと言える。
手戻りの発生を抑えるためにも、しっかりと単体テストを実施しておきたい。
テスト関係の記事はこちら。
コメントを残す