本ブログでは、単体テストのやり方についてご紹介します。まずは「単体テストの目的・種類」から、テスト手法・やり方と手順について解説。それらを理解した上で、「質の高い単体テストを行うポイント」をご紹介します。
「単体テストのやり方を知りたい」「効率的に、抜け漏れなくテストしたい」という方は是非ご一読いただき、高品質な単体テストの計画・実行に繋げていただければ幸いです。
単体テストの目的
単体テスト【Unit Testing/UT/CT/ユニットテスト】とは、
プログラム作成後において「ロジックが比較的小さな単位(ユニット)を対象とし、個々の機能(モジュール)を正常に果たしているのかを確認するテストです。
単体テストを行う目的は「テスト対象のプログラムをひとつずつ個別に実行し、不具合を除去すること」が挙げられます。どの単位で検証するのかは開発者、プロジェクトの規模感・特性により定義が異なります。
テストの種類
次は、「システム開発におけるテストの種類と内容」について解説します。
テストの種類 | 内容 |
---|---|
単体テスト | プログラム作成後、ロジックが比較的小さなユニット(単位)で実行し、 画面を構成する個々の機能に問題がないかを検証 |
結合テスト | 単体テスト後、複数モジュールを組み合わせプログラム間のデータのやり取り、 連携に滞りがないかを確認 |
システムテスト | 結合テスト後のシステム全体をテスト対象とし、要件定義を満たしているかと 機能・性能が品質要求を満たしているかを検証 |
上記をふまえて「単体テストの重要性」は、以下のメリットがあります。
- プログラム作成直後に行うため、スムーズに妥当性の高いテストが実施できる
- 実施環境を一度整備することで、不具合の修正・確認作業を効率的に進めることが可能
最小単位ユニットの検証である単体テストは、プログラム品質向上を担う重要なテストであると言えるでしょう。
単体テストの手法
つぎは、「単体テストの手法」についてご紹介します。
単体テストの手法
- ホワイトボックステスト
- ブラックボックステスト
以上をふまえ、ここからは「ホワイトボックステスト/ブラックボックステスト」の順に、各テスト内容について具体例と共にご紹介します。
ホワイトボックステスト
ホワイトボックステストとは、プログラムの内部構造を理解・意識した上で、それらが正しい構造で意図した通りに動作しているかを確認するテストです。
ホワイトボックステストの例
- 命令網羅
- 分岐網羅
- 条件網羅
- 複数条件網羅
ホワイトボックステストのメリット | ホワイトボックステストのデメリット |
---|---|
|
|
ブラックボックステスト
ブラックボックステストとはプログラムの内部構造を考慮せず、ユーザー要求を仕様通り満たしているかを確認するテストです。
ブラックボックステストの例
- 同値分割法
- 境界値分析
- デジションテーブル
ブラックボックステストのメリット | ブラックボックステストのデメリット |
---|---|
|
|
単体テストのやり方と手順
つづいて「単体テストの基本的なやり方(手順)」についてご紹介します。
単体テストの基本的な手順は、以下3段階に大別されます。
基本的な手順
- テスト条件を揃える(テスト仕様書作成)
- テスト実行&成否の判断
- テスト結果のエビデンス
以上をふまえた上で、ここからは上記3段階の業務内容について説明します。
まずは、「1. テスト条件を揃える(テスト仕様書作成)」について解説します。単体テストを成功させるためにも、正しいやり方と手順を理解しておきましょう。
テスト条件を揃える(テスト仕様書作成)
単体テストを行う際にはまず、「テスト仕様書」というドキュメントを作成します。
テスト仕様書は「網羅的な単体テストの実行・システム品質向上への寄与」のために必要です。ソフトウェアテストにおいては仕様書を作成し、あらかじめテスト条件を揃える必要があります。
テスト条件を揃えるためのステップ
- 顧客側が作成した「要件定義書」をもとに、機能を洗い出す
- テスト観点を定義・記載
- テスト方法を定義・記載
- 条件パターンの網羅
テスト仕様書作成の際は、仕様書の作成担当者とテスターが別であることを前提に、どのメンバーが読んでも理解しやすいドキュメント作成が大切です。
テスト実行&成否の判断
テスト仕様書を作成した後は、テスト実行に備えて各モジュールのテスト準備(ドライバ・スタブ)を行います。その後、テスト準備が整い次第、実際に単体テストを実行します。
単体テスト実行を担う際は、あらかじめ作成した各テストケースを都度確認しながら、順次一つひとつ丁寧に進めていきましょう。
途中で不具合・バグを検出した際には、プログラムコードの修正を実施します。修正完了後は、必ず修正したプログラムコードの影響範囲を確認した上で再テストを行いましょう。
また、このステップにおいて求められる点としては、作業工数が比較的多いこともあり「作業効率と正確性」が挙げられます。単体テストでは以上の作業を一通り正しく実施し、テストの成否を判断します。
テスト結果のエビデンスを残す
テスト完了後、結果に問題がなかった場合はエビデンスを残します。
テスト結果のエビデンスを残す理由
- テストを行った証拠
- レビュー時の確認資料
- エラーなどが生じた際の原因究明資料
- 今後のテスト作業再考・改善に役立てる資料
これらを実施すると2つ利点があります。
- 実施したテストを第三者視点でレビューすることが、テスターの見落としがちな問題発見に役立つことがある。
- この後のステップにおいてエラーや不具合が発生した際に、今一度最小機能ユニットに立ち返り原因が究明できるという点です。また、今後のテスト再考・改善にも役立つことがある。
エビデンスを残す必要性に関しては、組織や企業・プロジェクトによって度合いが異なることを留意しておきましょう。
質の高い単体テストを行うポイント
ソフトウェア開発において質の高いテストを行うためには、「テストの網羅性・効率性」が大きなポイントとなります。中でもテストの網羅性は、テストの成否だけでなく製品・サービスの品質を左右する重要なポイントです。
しかし現実的には、網羅性ばかりを追求した結果、作業工数が増えてしまうことにも繋がりかねません。このような場合、膨大な時間的ロスがかかってしまうため、単体テストを行う上では効率性を重視しつつ、「どこまで検証するのか?」の判断が重要となります。
網羅性と効率性のバランスを意識しながら、テストの質を向上しましょう。
単体テストの自動化(効率化)
今回は「質の高い単体テストを行うポイント」として、
単体テストの自動化(効率化)についてご紹介します。
ソフトウェア開発における最小単位ユニットの検証である「単体テストの自動化」は、数多くのテスト作業を効率よく、さばくことができます。
単体テストの自動化に際しては、多数のフレームワークが存在します。
単体テストを自動化できるフレームワーク
Java言語 …… JUnit
C/C++言語 …… CppUnit
NET言語 …… NUnit
SAS 言語 ……FUTS
しかし上記フレームワークには、テストケース作成などの機能はありません。
本来はテストの網羅性をカバーするものではないことを留意しておきましょう。
弊社サービスの紹介
近年、迅速かつ継続的な製品・サービスのリリースが求められる中、開発ライフサイクル全体に信頼性の高いテストが求められています。そのため、上記背景における課題を解決すべく、単体テストの自動化やテストの網羅性を自動化・簡略化できるサービスの提供も進んできています。
テスト自動化サービスが数多くあり、「どれを選べばよいかわからない」という方も多いのでは?
そこで今回は、テクバンが提供するテスト自動化サービス「mabl(メイブル)」をご紹介します。
「mabl」導入で実現する、優れた4つのメリットとは?
自動テストのクラウド実行
ノーコード/ ローコードでの簡単実装
AIによるテストスクリプトの自動修復
詳細なテスト結果
さらに詳しいサービスの詳細は下記リンクをご覧ください。
まとめ
いかがでしょうか?
今回は「単体テストのやり方と手順」について、基礎知識(目的/種類/手法)~網羅性・効率性の重要性やテスト自動化までご紹介しました。
本記事を通して、効率的な単体テストの進め方を正しく理解し、自動化ツール導入による業務効率化の検討も視野に、より質の高いテスト実現への意識向上に繋げていただければ幸いです。本記事を最後までお読みいただき、ありがとうございました。