知っておきたい！単体テストとは

単体テストとはシステム開発の工程で下流工程に位置します。単体テストではプログラミングによって生成されたコンポーネント※1やモジュール※2が、単体で機能を発揮するのかテストを行います。単体テストではプログラムの多くの不具合を洗い出し、取り除くことが目的です。

この工程で不具合が解消されない場合、結合テスト、運用テストといったそのあとに続くシステム全体のテスト工程にも影響します。本記事では知っておきたい単体テストのポイントについて説明します。

1.システム開発の過程で行われるテストの種類と役割　

単体テスト

単体テストとは、システム内の個々のコンポーネント※1やモジュール※2を個別にテストすることです。通常、単体テストではプログラムの関数やクラス※3などのテストが対象となり、各コンポーネントやモジュールが他の要因の影響を受けずに単独で正常に機能することをテストします。
単体テストの目的は、個々のコンポーネントやモジュールが設計通りに動作し、正しく機能するかどうかを確認することです。プログラムの関数やメソッドなどの個々のコンポーネントが、入力データに対して適切な出力を生成するか否かを確認します。

結合テスト

結合テストとは、複数のコンポーネントやモジュールが組み合わせ、結合した際に意図した通りに動作するか検証するテストのことです。単体テストで個々のコンポーネントやモジュールが正常に動作することを確認後、システム全体が設計通りに動作するかを確認します。
結合テストでは複数のコンポーネントやモジュール間のインタフェース※4が正常に機能するか、データのやり取りを正常に行うことができるのか、連携などが設計通りに機能するかなどを確認します。

運用テスト

運用テストとは、システムが実際の運用環境で正常に機能し、要件を満たすことを確認するためのテストです。運用テストでは想定された運用環境や想定される負荷の発生条件下で、開発したシステムが正常に動作するかどうかを確認します。
また、障害発生時のバックアップ、復旧手順、セキュリティ機能、負荷をかけるストレステストやパフォーマンスなどに関わるテストも行います。

d.受け入れテスト

受け入れテストとは、ユーザー側の利用環境においてシステムが問題なく稼働し、要件や期待に沿った動作をするか確認するためのテストです。受け入れテストは発注者側やシステムのユーザー側が行うことがポイントです。受け入れテストは、システム開発の一連の工程において最終段階のテストになります。
受け入れテストでは、最終ユーザーが実際の業務環境（stg環境や検証環境ともいう）でシステムを使用して、要件や期待に沿った動作を行うかを確認します。通常、ユーザビリティテスト、ユーザーインタフェースのテスト、ユーザーの実際の業務に関わるテストなどが含まれます。

2.単体テストはいつ、誰によって行われるか　

作成されるコードを知っているチームの技術メンバー

単体テストは、開発側で作成されるコードを知っているチームの技術メンバーが行います。テストケースを作成して、プログラムにさまざまな値を入力し、プログラムが処理を行った結果、期待される出力が行われるかを確認します。
単体テストでは想定されるあらゆるテストパターンや入力する値を準備し、不具合が出尽くすまで行います。

開発のフローのどこで実施されるか

単体テストは、プログラミングの後工程、結合テストの前工程で行われます。単体テストで不具合の洗い出しや改修が行われなかった場合、結合テストなどの後工程で予期せぬトラブルの原因となったり、不具合の切り分けや原因究明が困難化する場合があります。結合テストや運用テストで発生する不具合の多くは単体テストの不備に起因すると言えるでしょう。

3.単体テストについて、依頼元はどこまで分かっている必要があるか　

発注者側の企業は、単体テストを外注先に一任して問題はありません。

ただし、単体テストのクオリティが低いと次工程に開発が進むにつれて、不具合が発生した際の修正負荷が大きくなります。前工程に戻って修正を行う手戻りの負荷が高くなり、修正作業の工数も増加します。結果的に開発コストの増加やスケジュール延期が発生しかねません。そのため単体テストを行う際は外注先との確認やすり合わせなどは密に齟齬のないように丁寧に進めることが大切です。

4.よくある単体テストで発覚する設計ミス　

よくある設計ミス

単体テストによって、設計書の記載内容の抜け漏れや誤りが発覚することがあります。例えば、設計後に仕様変更が発生した場合、設計書に変更内容を抜け漏れなく反映する必要があります。しかしそれを怠っていた場合、設計書とは異なるプログラムが生成されてしまいます。テスト工程では設計書がインプットとして使われるため、設計書の抜け漏れや誤りがあった場合、後工程で大きな問題に発展する可能性があります。

ミスを生み出さない工夫

単体テストでミスを生み出さないためには、異なる方法でテストを行うとよいでしょう。単体テストの方法には、2つの方法があります。1つ目は「ホワイトボックステスト」で、2つ目は「ブラックボックステスト」です。

ミスが起きてしまった際の対応

単体テストで設計書の抜け漏れやミスが発覚した場合は、設計書の内容に立ち帰り、修正を行わなくてはなりません。

また、ミスを防ぐためには設計すべき内容を網羅したテンプレートを利用することで、設計漏れを防ぐことができます。設計書の品質は設計者の技術力やスキルによっても異なるため、テンプレートを用いて一定の品質を担保し統一感のある設計書を作成すると良いでしょう。

万が一設計ミスが発生した場合も、今後の対策としてテンプレートに盛り込むことで、再発防止にも繋がります。

5.まとめ

システム開発の工程の中で、単体テストそれ自体は影響範囲の規模が比較的小規模なテストです。単体テストはシステム開発を担う外注先に一任しても構いませんが、テストの前後工程での確認や単体テストに関わる確認事項は、発注者側と開発者側で齟齬が無いように行いましょう。

単体テストを軽視したことによって後工程で致命的な不具合が発見され、開発スケジュールに遅れが生じるケースもあります。単体テストはシステム全体が設計通りに機能するために必要な大切な要素です。しっかりと適切に行うことが最終的な成果物の品質にもつながります。

本コラムでは単体テストのポイントについて解説しました。情シスナビでは、本コラム以外にも、情報システムの開発に関わるさまざまなコンテンツを提供しています。是非確認してみてください。