あなたは、システム開発における開発工程の一部であるシステムテスト（総合テスト）について具体的にどのようなことをしているのか、どのように進めたら良いのか気になっているところではないでしょうか。よく比較されがちな単体テストや結合テストと何が違うのか、その辺りも含めてシステム開発会社として25年経つ会社に所属している私が解説します。
本記事を読んでいただき、システム開発におけるシステムテスト（総合テスト）について、少しでも理解に繋がる材料となれると幸いです。
目次
1.システムテスト（総合テスト）とは？
単体テスト、結合テストを一通りクリアしたら、システムテスト（総合テスト）に移ることになります。そんなシステムテストについて、1章ではどんなテストをするのか概要を説明します。
1-1. システムテストは、基本設計書通りにテストすること
システムテストは、基本設計書通りに機能や性能が動作するかテストすることです。別名・「総合テスト」とも呼びます。実際の使用状況を想定して、作業する環境・端末の設定等を整えたうえで多角的にテストしていきます。
システムテストは開発者側の最後のテストになりますので、これまでのエラーはすべて解消させておく必要があります。その後、運用テストとしてクライアントテストのフェーズに入ることになります。
1-2.システムテストは、結合テストの次に位置する
システムテストは、テスト工程の中でも結合テストを終えてからやってくるテスト工程となります。単体テスト、結合テストがクリアできていない状態でシステムテストをやることは有りません。
各工程を以下のように略して呼ぶこともあるので、ここで覚えておくと良いでしょう。
工程 | 略称 |
|
RD | Requirement Definition | |
BD | Basic Design | |
DD | Detail Design | |
UT | Unit Test | |
IT | Integration Test | |
ST | System Test | |
OT | Operation Test |
システム全体の流れについては以下の記事で紹介していますので、ご参考ください。
「システム開発の開発工程とは？10個のフェーズに分けて解説」
1-3.単体テストと結合テストとの違い
それでは、単体テスト／結合テストと何が違うのか紹介します。簡単に表にまとめると以下の通りです。
名称 | 工程 | 対象 | 内容 |
単体テスト | 最初のテスト | 機能単体 | 機能単体で不具合なく動作するかテスト |
結合テスト | 単体テストの次 | 機能単体 ＋ 機能単体 | 機能と機能を組み合わせた時に不具合なく連動して動作するかテスト |
システムテスト （総合テスト） | 結合テストの次 | システム全体 | 要件定義で設定した要件に沿った動作をするかテスト |
上記の通り、テストは3段階に分けて実施していきます。単体テスト、結合テストをクリアしてもシステムテストでエラーになることもあり、その場合は結合テストに戻ってエラーの原因を探りにいくことになります。そのエラーを放置して先に進めると欠陥があるシステムとなってしまうので、エラーは必ず解消しなければなりません。
単体テストと結合テストの詳細は下記を併せてご参照ください。
単体テスト：単体テストとは？テストする観点と結合／総合テストとの違いを解説
結合テスト：結合テストとは？テストする観点と単体／システムテストとの違いを解説
2.システムテストの進め方
2章ではシステムテストの進め方を紹介します。
2-1.システムテストするための仕様書を作成
システムテストを実行する前にシステムテストするための仕様書を作成します。要件定義書等とは異なり、システムテストをするための仕様書が必要になります。
仕様書に記載すべき主な内容は以下の通りです。
- 実施方法（シナリオ）
- テスト環境
- スケジュール
- テストデータやテストケースの項目
- 誰が
- 合格の基準 など
2-2.システムテストするための環境構築
続いて、システムテストするための環境を用意します。システムテストはこれまでと異なり、システムを使用する環境を想定してテストする必要があります。
この環境も本番の環境になるべく近しいものを用意するようにしましょう。
- ハードウェア
- OS
- ブラウザ
- ミドルウェア
- 使用するデータ
2-3.システムテストを実行
2-1で作成した仕様書のシナリオに基づいてテストを実行していきます。エラーが発生したら、そこを修正して再度テストを繰り返していきます。システムが問題なく動作することが確認できたら、クライアントに引き渡すことになります。最後の砦のテストだと思って進めるようにしましょう。
3.システムテストで見るべき観点
システムテストでは、主に3つの内容のテストをすることになります。「確認テスト」「評価テスト」「負荷テスト」。3章ではそれぞれのテストの内容について紹介します。
3-1.確認テスト
＜リグレッションテスト＞
システムを修正したときに、修正していない部分に影響が出ているケースがあります。別の箇所に悪影響が出ていないか確認するテストです。
＜デグレードテスト＞
システムを修正したときに、バージョンが古くなっていないか、過去に修正したエラーが再発していないか確認するテストです。
3-2.評価テスト
＜セキュリティテスト＞
外部からの不正アクセス防止や情報漏洩に関するセキュリティ対策が仕様書通りに動作するか確認するテストです。近年はセキュリティ面が重要視されるので、必ずテストしましょう。
＜ユーザビリティテスト＞
UI/UXのテストをします。どこか使いづらさを感じた場合は、修正を施すようにしましょう。この場合も結合テストに戻ってテストをする必要があります。
＜システムダウンテスト＞
システムが何らかの原因で落ちたときに最低限機能として使えるか確認するテストです。ハードウェアの故障やサーバーダウン、外部攻撃等が考えられます。障害発生から復旧させるまでテストで確認します。
3-3.負荷テスト
＜性能テスト＞
システムの時間効率や資源効率など、条件ごとにレスポンスに掛かる時間を測定して、最適化するテストです。この時間が仕様書通り機能しているか確認します。
＜ロングランテスト＞
長時間、システムを連続的に稼働させます。長時間稼働させてもパフォーマンスが落ちないか確認するテストです。
＜アクセス集中テスト＞
一度に大量のアクセスを行ってシステムがダウンしないか確認します。想定されるアクセス数については、仕様書に記載されているので確認しましょう。記載されている数×1.5倍ぐらいの想定でテストしたほうが安心できるでしょう。
＜キャパシティテスト＞
パフォーマンスを落とさずに処理できる最大のユーザー数やデータ量をテストします。これらの最大数を増やすために、どのように強化させるか確認するテストでもあります。
4.システムテストで失敗を避けるためのポイント
4章ではシステムテストにあたりどのような点に気を付けて進めるべきか解説します。
4-1.余裕のあるスケジュールを設定する
結合テストまでクリアしてもシステムテストでエラーが生じることがあります。システムテストはシステム全体的なテストをするので、エラーが発生するとそのエラーを解消するのに時間が掛かるケースが多いです。システムは1つ変更を加えると様々なところに影響が出やすい性質があります。
システムテストは、時間が掛かりやすいという観点からも他のテストに比べて余裕を持ったスケジュールを引くことが重要になってきます。
4-2.現実的なテストデータを用意する
現実的なテストデータを使用することで、実際のシナリオを正確に仮定することができ、特定の条件下でのみ発生する可能性がある潜在的な問題を発見するのに役立ちます。これは、ユーザーの期待に応えるという意味でも重要です。
テストデータが実際に使用するデータから乖離しているような内容だと、実際に動かした時に思わぬ不具合が発生するかもしれません。
「システムテスト（総合テスト）」まとめ
システム開発におけるシステムテストについて解説してきました。システムテストは開発者側で行うテストの中で最後のテストとなります。この後はクライアント側がテストする運用テストのフェーズに移ります。そのため、クライアントに高い品質をアピールするためにも正確に対応する必要があります。
そんなシステムテストについて記事をまとめましたが、弊社は会社を立ち上げたから25年が経ちます。長年の経験からシステム開発の手段について様々アドバイスできると思います。システム開発で行き詰った時には、どんな些細なことでも、お気軽にお問い合わせいただければと存じます。相談は無料！
