システム全体が要件どおりに動作するかを確認するテスト。
システムテストとは、開発したプログラムの部品(モジュール)をすべて1つに組み上げた後に、システム全体が要件どおりに動作するかを総合的に確認するテストです。総合テストとも呼ばれます。
ソフトウェア開発のテストは、小さい単位から大きい単位へ段階的に進みます。
・単体テスト:部品ごとに単独で動くか確認する
・結合テスト:部品どうしをつないで連携を確認する
・システムテスト:全部まとめてシステム全体を確認する
身近な例で考えると、自動車の組み立てに似ています。エンジンやタイヤを単体で点検し(単体テスト)、それらをつないで動くか確かめ(結合テスト)、最後に完成した1台の車を実際に走らせて性能や安全を確かめる──この「完成車として走らせる確認」がシステムテストにあたります。
システムテストの対象は、結合テストまでを終えて1つにまとまったシステム全体です。プログラムだけでなく、それが実際に動く環境ごとまとめて確認します。
具体的には、次のような要素を含めて本番に近い環境でテストします。
・ソフトウェア:開発したプログラム一式
・ハードウェア:実際に使うサーバや機器
・ネットワーク:通信経路や他システムとの連携
・データ:本番に近い量・内容のデータ
ポイントは、機能が単に「動くか」だけでなく、要件定義で決めた仕様(=発注者と取り決めた満たすべき条件)を全体として満たしているかを見ることです。部品単位では問題なくても、全体をつないだときに初めて表れる不具合を見つけるのが目的です。
| テスト種別 | 確認すること |
|---|---|
| 機能テスト | 要件で決めた機能が正しく動くか |
| 性能(負荷)テスト | 想定する処理量・速さを満たすか |
| 耐久(連続稼働)テスト | 長時間動かしても安定しているか |
| セキュリティテスト | 不正アクセスや改ざんに強いか |
| 例外(異常系)テスト | 誤った入力や障害時に正しく対処するか |
システムテストでは、機能が正しいかを見る機能テストに加えて、性能・耐久・セキュリティといった「使い物になるか」を測る観点も合わせて確認します。これらは部品単位では確かめにくく、全体を動かして初めて測れるものです。
たとえば性能テストでは、大量のデータや多数の同時アクセスを与えて、目標の応答時間や処理件数を満たすかを調べます。耐久テストでは何日も連続稼働させ、メモリ不足などで徐々に不安定にならないかを確かめます。
身近な例では、新しくオープンする飲食店の開店前リハーサルに似ています。料理が作れるか(機能)だけでなく、満席の混雑をさばけるか(性能)、終日営業し続けられるか(耐久)まで通しで確かめておく──こうして要件を全体として満たすことを確認してから、発注者による受入テストへ進みます。
なぜ単体テストや結合テストでは不十分で、システムテストが必要なのか?それは、部品ごとには問題なくても、全部をつないだときに初めて現れる不具合があるからです。
たとえば「部品A」も「部品B」も単独ではOKでも、両方をつなぐとデータの受け渡し方がずれていたり、処理の順番が意図と違っていたりすることがあります。こうした「組み合わせの問題」は全体を動かさないと見えてきません。
・部品テストで見る視点:「この部品は単独で正しく動くか」
・システムテストで見る視点:「全体として使えるものになっているか」
身近な例で考えると、オーケストラのリハーサルに似ています。各奏者が個別練習でうまく弾けても、合奏すると音がずれることがあります。全員で合わせてみて初めて分かる問題を見つけるのがシステムテストの役割です。
システムテストは、開発者が実施する最後のテスト工程です。単体テスト・結合テストと積み上げてきた後に行い、ここで合格してから発注者(お客様)による受入テストへ進みます。
開発サイクルの中でのシステムテストの意義を整理すると次のとおりです。
・単体テスト(部品ごと)→ 結合テスト(部品の連携)→ システムテスト(全体の要件確認)→ 受入テスト
・システムテストは、発注者に「完成品」として渡す前の最終チェックにあたる
・ここで不具合を見つけることで、発注者に問題のある製品を渡すリスクを防ぐ
ソフトウェア開発では、後の工程で不具合を見つけるほど修正コストが大きくなるといわれます。システムテストで見落とした不具合が受入テストや本番稼働後に発覚すると、手直しの影響範囲が広がり、対応に時間もコストもかかります。だからこそ、発注者に渡す前にシステムテストでしっかり確認することが重要なのです。