本ブログでは、開発側の最終工程「システムテスト(総合テスト)」についてご紹介します。まずはシステムテストの概要について解説し、検証目的や種類、進め方や重要性について、各工程とともに説明します。
テスト仕様書・計画書作成の方法やガイドをまとめた資料はこちら。 巻末に項目のサンプルも用意しています。
- 目次
システムテストとは
システムテストとは、【ST/PT/総合テスト】ソフトウェアの検証手法のひとつです。
構築したシステム全体をテスト対象とし「要件定義・品質要求を満たしているか」について検証し品質を保証します。
また、システムテストでは本番環境とほとんど同じ環境にてテストが実行されます。

システムテストはシステム開発における開発側の最終テスト工程です。
主にプログラムの設定ごとに検証する「単体テスト」と、プログラムを結合し検証する「結合テスト」完了後に実行され、それぞれに方法やメリットが異なります。
製品リリース前に全体を通したテストを行うことで品質確保とともに、残存するバグなどを最小限に減らし開発サイクルを回すことが可能になります。
次に、システムテスト実行の前段階である「単体テストや結合テストとの違い」について解説します。
単体テストや結合テストとの違い
単体テストと結合テストとの大きな違いは、「テスト対象範囲」です。

単体テスト、コンポーネントテストとも呼ばれますがこれは「単体機能」、結合テストは「それぞれの機能やシステム間」がそれぞれテスト範囲となります。
単体テストでは主に、単体の機能や性能、運用性などの動作確認を行います。
一方で結合テストは画面間のデータ連携や、バッチを起動する際のデータ連携、AとBの異なるシステム間での連携などが成功するかを検証します。
また詳細は省きますが結合テストには内部結合テスト(ITa:Integration Test Aの略)、外部結合テスト(ITb:Integration Test Bの略)の二種類あります。
単体テスト、結合テストについての詳細は下記もご覧ください。
単体テストとは|結合テストとの違いや観点・仕様書の書き方・エビデンスの重要性を解説!
単体テスト仕様書の書き方サンプル|効率的&高品質の仕様書の作り方を解説!
単体テストのやり方と手順|テストを網羅しながら効率よく進めるためのポイントを解説!
単体テストの観点とは|漏れのない洗い出し・網羅性がポイント!
システム開発の結合テストとは?実施方法やテストのポイントを紹介
単体テストと結合テストの違い|目的やテスト方法の種類・注意点を解説!
受け入れテストとの違い
システムテストと受け入れテスト、これらはシステム開発の最終段階において、品質を担保するために不可欠なプロセスですが、その目的と実施主体には明確な差異が存在します。
これらはシステム開発の最終段階において、品質を担保するために不可欠なプロセスですが、その目的と実施主体には明確な差異が存在します。
受け入れテストについて詳細をお知りになりたい方はは下記をご覧ください。
システムの受入テストで考慮すべきポイントとは?
システムテスト
システムテストは、主に開発者側が実施するテストです。
完成したシステムが要件定義書に記載された仕様を満たしているかを検証します。
機能性はもちろん、性能・セキュリティといった非機能要件も含め、多岐の観点からシステム全体の品質を評価します。目的は、本番環境への移行を円滑に進めるために、システム全体の品質を確実にすることです。
受け入れテスト
受け入れテストは、顧客またはエンドユーザーが主体となって実施するテストです。「UAT(User Acceptance Test)」と英語では表記し「検収試験」と呼ばれることもあります。
実際の利用シーンを想定しユーザー視点での評価を行います。システムが業務要件を満たしているか、操作性に問題はないか、そのような評価軸です。
目的は、顧客がシステムに満足し、安心して利用できる状態であることを確認し、最終的な納品判断を行うことです。
両者の違い
項目 | システムテスト | 受け入れテスト |
目的 | システムの品質保証 | ユーザーの利用満足度確認 |
実施主体 | 開発者 | 顧客・エンドユーザー |
テスト内容 | 機能、性能、セキュリティなど | 業務適合性、操作性など |
視点 | システム視点 | ユーザー視点 |
システムテストは受け入れテストの前段階として実施され、両者は補完し合う関係です。
両者共、高品質なシステムをリリースするためには欠かせないプロセスであり、それぞれの役割を理解し、適切に実施することが重要です。
システムテストの目的
システムテストは、開発した製品の品質確保を目的としたテスト手法です。
また、前述の通り、システムテストは開発ベンダー側の最終テスト工程です。
そのため、テスト終了後には「現段階でこの製品に不備はない」と自信を持って言える状態に仕上がっていなければなりません。
万が一システムテストが正確に実行されなかった場合には、要件定義・品質要求が満たされず、発注側の要望が実現されなくなってしまいます。そのような状況に陥った場合、発注側やユーザーからの信頼や満足度を得ることは難しくなるでしょう。これらの不都合を生じさせないためにも、開発の際にはシステムテストを正しい手順且つ丁寧に計画、実行することが重要です。
システムテストの種類
よく行われる代表的なシステムテストの種類は以下の通りです。各種テストを組み合わせて行われます。システム全体をテスト対象とし、要件定義・品質要求に対する検証と品質の保証を行うため、さまざまな種類のテストが求められます。
ここでは基本となる情報を解説します、システムテストの種類の詳細をお知りになりたい方は下記をご覧ください。
システムテストの種類を徹底解説|開発段階ごとのテスト戦略
回帰テスト
ソフトウェアやアプリケーションの変更や修正後、別の部分に不具合が発生していないかを確認します。リグレッションテストとも呼ばれます。
デグレードチェックテスト
ソフトウェアなどの修正後に旧バージョンへの回帰・不具合の再発などが起こっていないかを確認。ソフトウェアのバージョン管理などに役立ちます。
セキュリティテスト
Webサイトやアプリケーション、ソフトウェアに対する外部からの不正アクセス防止、セキュリティホール発見、情報漏えいリスク対策など、セキュリティ面が正常に動作しているかをテストします。
ユーザビリティテスト
想定ユーザーに対象ツールのプロトタイプを操作してもらい、ユーザビリティの目線で操作性をチェックします。これもWebサイトやアプリケーションなどを対象に行います。
障害許容性テスト
対象ツールに関連性の高い、想定される障害やリスクを意図的に発生させて、最低限の機能が正常に動作するかを復旧手順とともに確認します。
機能テスト
機能テストは、ソフトウェアの機能が仕様書通りかを検証するテストです。入力や出力、操作などを確認し、ユーザー要求に沿っているかをチェックします。
性能テスト
性能要件に基づき、実際の処理能力が仕様を満たしているかをテストします。
ロングランテスト
大量アクセスなど、外部から一度に過負荷がかかった際にもシステムが正常に動作するかを検証します。
負荷テスト
性能や耐久性、想定外過負荷に対するシステムの挙動やパフォーマンス、対処法などを検証します。
システムテストの進め方
次は、「システムテストの進め方」について解説します。正しいテストの進め方を把握することは、妥当性の高いテスト実現、ソフトウェアの品質向上において非常に重要です。

システムテストの進め方
以下の流れで行い、開発の設計・実行工程と同時並行で行われます。
- テスト設計
まずは「開発したシステムやソフトウェア全体が要件定義を満たしているか」というテスト観点を用いて、テストの方向性を整理したテストケースを作成します。
- テスト環境準備
作成したテストケースに基づき、システムテストの実行環境が本番環境と同様に仕上がるように準備します。
- テスト実行
仕様書をもとに、システムテストを実行します。
- エラーの修正
システムテストの途中で不具合検出した際には、その内容を管理台帳に記載して修正対応を行います。
テスト設計
システムテストを正しく実行するためには、環境構築前の「テスト設計」が重要です。
テスト設計では要件定義書に基づき、システムテスト全体の目的・範囲・テスト環境・スケジュールなどの方針を定めます。ソフトウェア単体のみではなく関連するモジュールなどへの抜け漏れ防止のメリットもあります。
注意点としては、要件定義を満たすことができるよう、あくまでもユーザー目線・品質要求に沿ったテスト設計を行うことが重要です。また、作成したテスト設計は、関係者全員に共有しましょう。
テスト環境準備
次は、テスト設計に基づき「テスト環境準備」に取り掛かります。
システムテストでは原則として「可能な限り本番環境と同様の環境を準備する」必要があります。そのため、本番と同じ機器やハードウェアを用意し、システム全体の動作検証をひと通り実施することが重要です。
さらにデータに関しても、本番の稼働環境と同様のもの(マスターデータ、トランザクションデータ)を準備することで、予期せぬ欠陥や不具合がないかを抜け漏れなく確認する必要があります。
ここでの注意点としては効果的なテスト実行に向け、
「できるだけ本番稼働環境に近い環境を構築すること」「テスト設計に基づき、バグが残存しないようシステム全体を通して細心の注意を払うこと」が挙げられます。
テスト実行
次は、実際にシステムテストを実行します。
システムテスト実行の際には、必ず要件定義書に沿った手順とテスト手法を確認し、正確に行います。
万が一システムテストの途中で不具合を検出した場合には、管理台帳を作成し、詳細を記入します。
また、管理台帳は不具合が完全に解消されるまで保管しておきましょう。
そして、見つかった不具合の修正完了次第にテストを再開します。計画書に記載のテスト工程を全て実施し、問題なくシステムの動作が確認でき次第、テスト完了です。
ここでの注意点としては、「要件定義書に沿ったプロセス、方法で正しくテストを行うこと」や「不具合やバグの検出時には、それらを放置せずに必ず修正・復旧後にテストを再開すること」を常に意識しておくことが重要です。
エラーの修正
システムテストでは、修正作業が予期せぬ箇所に影響を与えることが多々あります。そのため、エラー発生時には管理台帳への記入はもちろん、迅速な修正対応を要します。
具体的には不具合検出時に修正・対処方法を考慮し、再検討を行います。
また、エラー修正後には周囲への影響を考慮・分析し、抜け漏れなくフィードバックすることが重要です 。
ここでの注意点としては、あらかじめ「テスト工程を自動化」することにより、テスト作業のスケジュールに余裕を持たせておくことが挙げられます。
自動化によるシステムテスト効率化は、エラー発生時の迅速な対応だけでなく、ヒューマンエラー防止を可能にします。
また、これらの作業を丁寧に行うことは、顧客満足度の高いソフトウェア開発に大きく貢献します。
システムテストの確認時の観点
システムテストは、開発されたシステムが要件定義書通りに動作するかを検証する重要なプロセスです。ここでは、システムテストを実施する際に確認すべき主要な観点について解説します。
1. 可用性
システムの可用性とは、必要な時にシステムが正常に利用できる状態を指します。システムテストでは、システムの稼働時間、障害発生時の復旧時間、冗長構成などを確認し、システムの可用性を評価します。
2. 性能・拡張性
システムの性能は、応答速度、処理能力、スケーラビリティなどを指します。システムテストでは、負荷テストやストレステストを実施し、システムの性能を評価します。また、将来的なシステム拡張に備え、拡張性についても検証します。
3. 運用・保守性
システムの運用・保守性は、システムの運用管理の容易さ、保守作業の効率性などを指します。システムテストでは、システムの監視機能、ログ出力、バックアップ・リストア機能などを確認し、システムの運用・保守性を評価します。
4. 移行性
システムの移行性とは、既存システムから新システムへの移行の容易さを指します。システムテストでは、データ移行、システム連携、ユーザー教育などを確認し、システムの移行性を評価します。
5. セキュリティ
システムのセキュリティは、不正アクセス、情報漏洩、ウイルス対策などを指します。システムテストでは、脆弱性診断、侵入テスト、セキュリティポリシーの遵守などを確認し、システムのセキュリティを評価します。
6. システム環境・エコロジー
システムのシステム環境・エコロジーは、システムの動作環境、消費電力、環境負荷などを指します。システムテストでは、システムの動作環境の適合性、消費電力の測定、環境負荷の評価などを実施します。
これらの観点を網羅的に確認することで、システムテストはシステムの品質を確保し、本番環境への移行を円滑に進めるための重要な役割を果たします。
システムテスト仕様書の記載項目
システムテスト仕様書には、以下の項目を記載します。
- テスト概要:
テスト内容について、どのメンバーも理解できるようにシンプルな書式で記載します。 - テストの実施環境:
本番環境に近いどのような環境(ハードウェア、ソフトウェアなど)でテストするのかを記載します。 - テストケース:
どのようなテストを実行し、どのような結果を得ることが目的なのかを記載します。システムテストの基盤となる種類も記載します。 - テスト手順:
テストケースのプロセスを実際に用いるデータとともに順次記載します。 - テストスケジュール:
システムテストのスケジュールを記載します。仕様書のレビューやテスト環境構築・使用データなどを明らかにしましょう。また、テストスケジュールは関係者全員への共有が必須です。 - テスト担当者:
システムテストを実行するメンバーを記載します。また、実施者とは別にテスト結果を確認するメンバーも記載します。
システムテスト仕様書の書き方のサンプル
テスト仕様書・計画書作成の方法やガイドをまとめた資料はこちら。 巻末に項目のサンプルも用意しています。
システムテストでは、「非機能要件に関する検証作業」の比率が高くなります。
そのため、実行の際には「機能要件だけでなく、非機能要件に対する検討と定義」が大切です。何故ならば、システムテストでの不具合残存は、発注側に渡った次の段階では検出が困難であるためです。
その他には、「関係者間での情報共有」や、「どのメンバーが読んでもわかりやすい仕様書作成」も重要です。
まとめ
今回は「システムテスト」について解説しました。
本ブログを通して、システムテストに関する知識が深まり、プロジェクト前進の参考となれば幸いです。
テクバンではお客様への「システムテスト支援サービス」も行っております。
- 専門家のよる徹底した要求ヒアリングを実施
- 非機能要件まで考慮、実利用性のあるテスト実施による品質保証
- 当社独自のノウハウを活かした、効果的なテスト内容の決定
IT人材の需要が高まる中、外部のベンダー企業の活用シーンも増えてきました。
当社在籍のテストエンジニアがお客様のご要望や、システム・ソフトウェアの特性などをヒアリングした上で、効果的なテスト設計~実行までを全面サポートさせていただきます。
貴社プロジェクトにおける品質向上にお役立てください。