本ブログでは、単体テストについてご紹介します。まずは単体テストの概要から、結合テスト・システムテストとの違いについて整理。その後、単体テストの観点・仕様書の書き方・エビデンスの重要性などを一挙に解説します。
単体テストとは
単体テスト【Unit Testing/UT/CT/ユニットテスト】とは主に、プログラム作成後においてロジックが比較的小さな単位（ユニット）をテスト対象とし、個々の機能（モジュール）を正常に果たしているのかを検証する方法です。
本ブログでは、単体テストの目的や方法、実際の進め方について詳しく解説。
まずは「結合テストやシステムテストとの違い」についてご紹介します。
結合テストやシステムテストとの違い
システム開発におけるテスト工程は、３種類あります。
- 単体テスト
- 結合テスト
- システムテスト
これら３つの大きな違いは「テスト対象範囲」です。
テスト対象範囲の違い
- 単体テストの対象範囲＝単体機能
- 結合テストの対象範囲＝それぞれの機能やシステム間
- システムテストの対象範囲＝システム全体
上記をテスト対象範囲としています。
さらに単体テストと結合テストは、あくまでテスト環境にて検証を実施するのに対し、システムテストは本番環境と同じ環境を用いて検証を行います。
つぎに各テスト手法の対象範囲について解説します。
まず、単体テストでは「単体の機能や性能、運用性などの動作確認」を行います。
一方、結合テストは「画面間のデータ連携や、バッチを起動する際のデータ連携、AとBの異なるシステム間での連携などが成功するかを検証」します。
最後にシステムテストでは「全プログラムとハードウェアを動かしながら全体を通して、全サブシステムにて想定される一連の処理を実行」していきます。
単体テストの目的
単体テストの目的は「テスト対象のプログラムを一つずつ個別に実行し、不具合を除去すること」です。
また、単体テストは比較的時間や労力、スキルといったコストのかかる作業です。そのため、万が一スケジュールなどの都合で簡易的になった場合に起きる可能性がある不都合として
- その後のテストでの不具合検出
- 的確な修正対応ができない
などが挙げられます。
一方で単体テストは、プログラム作成直後に実行するため、スムーズに妥当性の高いテスト作業を進めることができます。また、単体テストの実施環境は一度整備することで、不具合の修正・確認作業を効率的に進めることが可能です。
これらの利点から、単体テストは品質向上を担う重要なテスト作業であると言えるでしょう。
単体テストの方法
つづいて、単体テストの方法について解説します。
代表的な単体テストの方法
- ホワイトボックステスト
- ブラックボックステスト
ここからは単体テストの各方法について説明します。
まずは「ホワイトボックステスト」から解説します。
ホワイトボックステスト
ホワイトボックステストでは、プログラムの内部構造を理解・意識した上で、
それらが正しい構造で意図した通りに動作しているかを確認します。
具体的には、ソースコードの文・分岐・条件を網羅的にテストします。
そのため、実行にはプログラミングに関する知識が必要不可欠です。
ホワイトボックステストの例
- 命令網羅
- 分岐網羅
- 条件網羅
- 複数条件網羅
| ホワイトボックステストのメリット | ホワイトボックステストのデメリット |
|---|---|
|
|
ホワイトボックステストは、システムの内部構造を網羅するようなテストケースに適しています。主に、テストケースによるプログラム実行結果をテスト品質の指標とし、その網羅率（カバレッジ）を計測・分析します。
ブラックボックステスト
ブラックボックステストでは内部構造を考慮せず、ユーザー要求を仕様通り満たしているかを確認します。
テストすべき項目は仕様書などから洗い出します。多くの場合、開発者以外の第三者によってテストが実行されます。
ブラックボックステストの例
- 同値分割法
- 境界値分析
- デジションテーブル
| ブラックボックステストのメリット | ブラックボックステストのデメリット |
|---|---|
|
|
ブラックボックステストは複数プログラムを組み合わせたシステムの入出力や、ユーザー視点に着目したテストケースに適しています。
単体テストのやり方と手順
ここで、単体テストの基本的なやり方と手順についてご紹介します。
主な手順は以下の通りです。
基本的な手順
- テスト条件を揃える（テスト仕様書作成）
- テスト実行成否の判断
- テスト結果のエビデンス
ここからは、各手順について詳しく解説します。
テスト条件を揃える（テスト仕様書作成）
単体テストの仕様書は、ソフトウェア品質向上のために必要なドキュメントです。
単体テストの実施担当者は、仕様書を基にテストを実行します。つまり、単体テストの成否は仕様書のクオリティにかかっていると言えるでしょう。
また、テストの前提条件を揃える手順は下記の通りです。
テスト条件を揃える（テスト仕様書作成）ためのステップ
- 要件定義書から全ての機能の洗い出し
- テスト観点の整理
- テスト方法の選定
- 条件パターンの網羅
仕様書の作成者とテスト実施担当者が別であることを前提に、どの担当者が読んでも理解しやすい仕様書作成を意識することが大切です。
テスト実行＆成否の判断
この段階では、単体テスト仕様書の内容に基づき、テストを実行していきます。
そして、テストの実行結果から単体テストの成否を判断します。
また、単体テストは作業工数が多いため、テスト範囲をできる限り狭め、作成した側から効率的に実行しましょう。
テスト結果のエビデンスを残す
最後に、テスト結果のエビデンスを残します。
テスト結果のエビデンス取得は下記のような利点があります。
【テスト結果のエビデンスを残す理由】
- テストを行った証拠
- レビュー時の確認資料
- エラーなどが生じた際の原因究明資料
- 結果としてプロジェクト成功、システム品質向上に繋がるため
第三者視点によるレビューを行うことで、テスト担当者が見落としていた不具合を発見できることがあります。さらに後の工程でエラーや障害が発生した時に、最小機能ユニットに立ち返って発生原因を追究することもできます。
組織・企業やプロジェクトのスケジュールなどの特性上、テスト結果のエビデンス取得の必要性は異なることもあるため、このステップは省略される場合もあります。
単体テストを有意義にするためのポイント
単体テストを有意義にするためにはいくつかのポイントがあります。
原則、単体テストは仕様書（テスト設計）を基に実行されるため、テスト設計がテスト成否の生命線となります。万が一内容に不備や手戻りがあった場合、テスト全体が無意味なものになりかねません。
以上のことから、有意義な単体テストを行うためには
- テスト仕様書が明確であること
- テスト観点の網羅性
が重要なポイントになります。
テスト仕様書が明確であること
単体テストでは、仕様書作成者が必ずしもテストを実行するわけではありません。もしも作成者がテスト実施担当者と異なる場合には、「仕様書の明確さ」が大切になります。
テスト仕様書を明確にするためにはまず、テスト観点をわかりやすく記載する必要があります。具体的にはテスト観点に注釈をつけ、曖昧な表現は避けて記入します。また、第三者によるレビューを行うなども効果的です。
【記入例】
- 例)空白の場合○○というメッセージが表示されるか確認
- NG例)空白の場合の動作を確認（←何が正解かわからない）
テスト観点の網羅性
単体テストでは、「テスト観点の洗い出し」も重要です。
より網羅性の高いテスト実現のために、入力チェック系の機能に関する不具合など、特に頻繁に発生しやすいものは漏れなく取り除けるようにしておきましょう。
テスト観点の漏れ防止には、プログラムの処理条件をわかりやすく表現できる「デシジョンテーブルの活用」が望ましいでしょう。
さらに要件定義書の作成者（クライアント）やテスト関係者ともレビューを行うと、多角的な視点でテスト観点を洗い出すことができます。
弊社サービスの紹介
テクバンでは単体テストを漏れなく、スピーディーに行うためにお客様への「ソフトウェアサービス」をご提供しております。
「最終テスト実施に不安がある…」「テスト実行までのノウハウや人的リソースが不足している」といった企業様はぜひ一度、当社コンサルタントにご相談ください。
テクバンの「ソフトウェアテスト」とは？
- 専門チームがテスト業務を内部監査
- プロジェクト立ち上げ～品質改善コンサルまで対応
- 徹底したヒアリングで品質業務の最適化
当社在籍のテストエンジニアがお客様のご要望や、システム・ソフトウェアの特性などをヒアリングした上で、効果的なテスト設計～実行までを全面サポートさせていただきます。
まとめ
いかがでしたでしょうか？今回は、単体テストの全体像について詳しく解説しました。単体テストは、プログラム作成直後に実行する最初の工程です。
単体機能をテスト対象範囲とするため、実際の作業や原因特定なども比較的容易に実行できます。
本ブログを通して「単体テストの概要～方法や手順」などに関する理解が深まり、ソフトウェア品質向上・業務効率化について見直すきっかけとなれば幸いです。
