テストとは?

作ったプログラムやシステムをテストすることで、納品に耐えうる十分な品質を担保します。多様なテスト手法を整理しておきましょう。

テストとは、機能の品質が保障されていることを証明するために行う検査です。機能の大きさに応じて、単体テスト、結合テスト、システムテスト(総合テスト)に大きく分類されます。それぞれのテストに応じて、機能に潜在しているバグを発見し、修正することが主な目的です。バグの発見に対しては良くないイメージを抱いてしまいますが、バグを取り除くことが最大の目的であり、品質確保には絶対に欠かせないのです。

  • 単体テスト(UnitTest、UT)
  • 結合テスト(IntegrationTest、IT)
  • システムテスト(SystemTest、ST)

単体テスト(Unit Test)

単体テストでは、モジュールを一つずつ検査します。詳細設計書を元に単体テスト仕様書を作成します。テスターは、単体テスト仕様書に基づいたテストを実施し、バグがあれば実装者にモジュールを修正してもらいます。

インプット アウトプット
  • 詳細設計書
  • 単体テスト仕様書
  •  単体テスト報告書

現在では様々なテストツールが用意され、代表的なものではJUnitが挙げられます。JUnitは単体テストの自動化を目的としたxUnitの一つであり、Javaプログラムのメソッド単位でテストプログラムを実装し、視覚的にテスト結果を得られるというメリットがあります。また、単体テストにはホワイトボックステストとブラックボックステストがあります。

ホワイトボックステスト

モジュールの内部構造に着目してテストします。命令、条件を全て網羅し、モジュールで想定される全てのパターンをテストします。

ブラックボックステスト

モジュールの内部構造には着目せず、モジュールが想定するインプットデータに着目してテストします。インプットデータを同じ意味のあるグループに分け、グループの中の一つのデータを使用する同値分割、インプットデータを真(有効)と偽(無効)に分け、真偽の境目に着目する限界値分析があります。

どちらのテストも着眼点が異なり、目的も異なるため、どちらが良いということはありません。基本的にはブラックボックステストで行うテストであれば、モジュールが果たす機能を全て確認できるはずです。しかし、テスターが詳細設計書を元に作成した単体テスト仕様書には、テストパターンに洩れがある可能性があります。インプットデータに着目したテストでは、インプットとなるパターンを全て網羅していないこと、テスト環境によって動作が異なる場合があること等がリスクとなり得ます。したがって、ホワイトボックステストによって全ての動作を検査することが重要なのです。ホワイトボックステストでは、モジュールが想定するインプットでは起こりえないと考えられるパターンまでテストすることができます。モジュールが想定するインプットでは起こりえないことを保障できれば、ブラックボックステストのみで十分であるとも言えます。


システムテスト(System Test)

システムテストでは、結合テストまでに完成したシステムに対してテストを行います。総合テストとも言います。顧客の動作環境でテストすることもあり、要件定義レベルのシステム要件がきちんと満たされているかを確認します。

インプット アウトプット
  •  要件定義書
  • システムテスト仕様書
  • システムテスト報告書

結合テストをクリアしていれば、おおよそ設計バグのような障害は発生しません。しかし、実際に運用する環境(本番環境)でテストを行うため、システム的な障害や性能問題が発生することがある。特に、性能問題を解決するためには、単体レベルまでモジュールを再テストする必要があり、原因の切り分けと処理の効率を踏まえた上で、プログラム仕様を再設計します。それらにかかるコスト(時間)が、スケジュールを圧迫させる要因です。システムテストに至るまでに、単体テスト、結合テストのタイミングで性能テストを行う必要があります。それでも性能に関するリスクを全て取り除くことは不可能であり、システムテストで発生する障害への対応を踏まえた全体計画が重要です。

受入テスト

受け入れテストは、システム開発を発注した顧客企業側で行うテストです。要求した機能や性能を満たしているかをテストします。開発側で行ったシステムテストと同等のレベルでテストが行われますが、システムテストに顧客が立ち会う場合も多く、システムテストを受け入れテストと見なすこともあります。


受け入れテストをクリアすると、顧客企業へリリースとなります。しかし、出来立てのシステムをフル稼働させることは危険であるため、実験的に、段階的に稼動させていく場合が多いでしょう。