システムテスト(総合テスト)とは？目的・種類・標準的な進め方について解説

---

システム開発の最終段階で実施される「システムテスト(総合テスト)」は、品質保証の重要な関門です。個別に動作確認された機能が統合された状態で、システム全体が要求仕様を満たしているかを検証します。本記事では、システムテストの定義から進め方、実践的なテスト技法まで体系的に解説します。

---

システムテスト(総合テスト)とは？

システムテストとは、開発したシステム全体を対象に、要件定義で定めた機能や性能が正しく実装されているかを総合的に検証する工程です。ウォーターフォール型では最後の検証工程として、アジャイルやDevOps環境ではイテレーションごとやCI/CDの中で継続的に実施されます。

システムテストの定義

日本では「総合テスト」とも呼ばれますが、これは和製英語的な俗称であり、JSTQBやISO/IEC/IEEEの標準的なテスト用語体系では「システムテスト（System Test）」が正式なテストレベルの名称です。プロジェクトや組織によって呼称が異なる場合がありますが、その本質的な目的と内容に違いはありません。

---

---

JSTQBの用語集では、「統合されたシステム全体またはシステムの一部が、特定の要求事項を満たしていることを実証するために実施されるテストプロセス」と定義されています。V字モデルで見ると、要件定義フェーズに対応する検証工程として、開発の下流工程に配置されます。

システムテストの目的

システムテストの主な目的は、システムが顧客の期待する品質を満たしているかを開発側の視点で最終確認することです。主に以下の3つの観点から品質を確認します。

1つ目は、要件定義書に記載された全ての機能要件が正しく実装され、意図通りに動作するかを確認します。業務フローに沿った一連の処理や、画面遷移、データの入出力などを検証します。
2つ目は、性能やセキュリティ、使いやすさといった非機能要件が満たされているかを、本番環境に近い条件下で検証します。
3つ目は、システム全体として統合された状態で問題なく動作するかを確認します。個別の機能が正常でも、組み合わさった際に予期せぬ不具合が発生する可能性があるため、システム全体の振る舞いを総合的に評価します。

システムテスト(総合テスト)と結合テストの違い

システムテストの位置づけを理解するには、その前工程である結合テストとの違いを明確にすることが不可欠です。両者は検証の粒度と観点が大きく異なります。
結合テストは、複数のモジュールやコンポーネントを組み合わせた際のインターフェースや連携が正しく機能するかを確認するテストです。例えば、ECサイトであれば「商品検索機能」で入力された商品名をデータベースに問い合わせ、その結果を受け取るといったモジュール間の連携など、部分的な結合に焦点を当てます。一方システムテストでは、ステージング環境など、ユーザーが利用する本番に近い環境でテストを行い、商品の検索機能や決済機能といった機能レベルで正常に動作するかを検証します。

テストの対象範囲
結合テストの対象は、モジュール間やサブシステム間の接続部分です。対してシステムテストは、システム全体を一つの製品として捉え、エンドユーザーの利用シーンを想定した包括的な検証を行います。

テストベース（根拠となる文書）
結合テストは基本設計書をテストベースとし、技術的な観点から設計通りにモジュールが連携しているかを確認します。システムテストは要件定義書や仕様書をテストベースとし、顧客の要求が正しく実現されているかをビジネス的な観点から検証します。ただし、アジャイル開発では詳細な要件定義書が作成されないこともあり、その場合はユーザーストーリーや受け入れ基準がテストベースとなります。

このように、結合テストが「部品の組み合わせ」を検証するのに対し、システムテストは「完成品としての製品」を検証する点が本質的な違いといえます。

システムテスト(総合テスト)と受け入れテストの違い

システムテストと混同されやすいのが、その後工程である受け入れテストです。両者の最大の違いは「誰の視点で、何を確認するか」という点にあります。

テストの目的
システムテストの目的は、開発側が定めた要件や仕様を満たしているかの技術的検証です。受け入れテストは、顧客やエンドユーザーが「自分たちのビジネスに使えるか」を判断するための検証で、実際の業務フローや運用シーンで問題なく利用できるかが評価されます。

視点とチェック項目
システムテストは開発者やテストエンジニアの技術的視点で、仕様書通りの動作を確認します。データの整合性、エラー処理の妥当性など、システムの内部的な正確性に注目します。受け入れテストでは、実際の業務担当者の視点で、操作のしやすさや業務効率の向上、期待する成果が得られるかを評価します。

主な実施者
システムテストは開発ベンダーの開発者やQAチーム等が主体となって実施します。受け入れテストは、発注者である顧客企業が実施し、実用性の観点からの評価が重視されます。
システムテストが「品質保証の最終確認」であるのに対し、受け入れテストは「顧客による検収」という位置づけです。

システムテスト(総合テスト)の標準的な進め方

システムテストを効果的に実施するには、計画から終了まで体系的なプロセスに沿って進めることが重要です。ここでは、3つの主要フェーズに分けて解説します。

計画フェーズ：テスト戦略の確立と合意

計画フェーズでは、システムテスト全体の方向性と実施方針を定めます。要件定義書や基本設計書を精査し、テストすべき範囲を明確にします。ビジネスへの影響度や技術的リスクを評価し、優先順位をつけることが効率的です。

次に、テスト環境の要件を定義します。本番環境と同等の構成が必要かを検討し、環境構築のスケジュールを立てます。テスト完了の判定基準も明確にしておきます。「重要度Highの不具合ゼロ」「カバレッジ90%以上」など、定量的な基準を設定することで、関係者間の認識を統一できます。ただし、カバレッジの目標値はシステムのドメインやリスクに応じて決定すべきです。医療・航空・金融などの高リスクドメインでは非常に高いカバレッジが求められる一方、リスクの低い環境では70%程度で十分と判断されることもあります。

設計・準備フェーズ：テストベースに基づく設計

設計フェーズでは、計画に基づいて具体的なテストケースを作成します。要件定義書の各項目に対して、どのような条件でどのような結果を期待するかを詳細に記述します。要件とテストケースの対応関係を示すトレーサビリティマトリクスを作成すると、テストの網羅性を確認しやすくなります。

テストデータの準備も重要な作業です。正常系だけでなく、境界値や異常値を含む多様なパターンを用意します。並行してテスト環境の構築を進め、環境が整ったら簡単なスモークテストで基本的な機能の動作を確認してから本格的なテストに入ります。

実行・終了フェーズ：報告と判断

実行フェーズでは、作成したテストケースに従ってテストを進めます。各ケースの結果を記録し、不具合を発見した場合は再現手順や期待結果との差異を詳細に記録します。不具合は重要度と優先度で分類し、開発チームにフィードバックします。修正後は再テストとリグレッションテストを実施します。

全てのテストケース実行が完了したら、テスト結果を集計・分析します。実施したテスト件数、合格率、検出した不具合の件数などの指標をまとめ、テスト報告書として文書化します。計画フェーズで定めた完了基準を満たしているかを評価し、判定会議で受け入れテストへの移行可否を決定します。

システムテスト(総合テスト)の主な観点

システムテストの設計では、多角的な観点からテストケースを洗い出すことが網羅性の高い検証につながります。ここでは、特に重要な3つの観点を紹介します。

観点１：機能要件の観点

機能要件の観点では、システムが提供すべき機能が正しく実装されているかを確認します。要件定義書に記載された各機能について、正常系（期待通りの操作）と異常系（エラー条件や不正な入力）の両方を検証対象とします。単一機能の動作確認だけでなく、複数機能を跨ぐ業務フロー全体が問題なく遂行できるかも重要な確認ポイントです。

観点２：非機能的な観点(システムの品質特性)

非機能要件とは、機能以外のシステムの品質特性を指します。システムの品質を評価する国際標準であるISO/IEC 25010では、非機能要件を明確化するための品質特性モデルが定義されており、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の7つの品質特性が挙げられています。

性能面では、レスポンスタイムや同時アクセス数の上限、大量データ処理の速度などを測定します。セキュリティでは、不正アクセスへの耐性、データの暗号化、権限制御の妥当性を確認します。使用性（ユーザビリティ）では、画面の操作性や情報の見やすさ、エラーメッセージの分かりやすさを評価します。

これらの非機能要件は定性的になりがちですが、具体的な数値目標を設定することで客観的な評価が可能になります。例えば「画面表示は3秒以内」「ヘルプを見ずに操作できるユーザーが80%以上」といった基準を定めます。

観点３：リスク・網羅性の観点

リスクベースの観点では、システム障害が発生した際のビジネスへの影響度と、不具合の発生しやすさを掛け合わせてリスク値を算出し、高リスク領域を重点的にテストします。例えば、金銭処理や個人情報を扱う機能、複雑なロジックを持つ機能は優先度を高く設定します。

網羅性の観点では、テストケースが要件を十分にカバーしているかを確認します。要件カバレッジ、コードカバレッジ（可能な場合）、組み合わせカバレッジなどの指標を用いて、テストの抜け漏れを防ぎます。特に、システムの状態遷移や入力パラメータの組み合わせなど、考慮すべきパターンが多い領域では、テスト技法を活用して効率的に網羅性を高めます。

これら3つの観点を組み合わせることで、バランスの取れた効果的なテスト設計が実現できます。

検証すべき主なシステムテストの種類(テストタイプ)

システムテストでは、検証の目的に応じて様々なテストタイプを実施します。ここでは、代表的なテストタイプを分類して紹介します。

機能要件の検証に関わる種類

機能テストは、システムが仕様通りの機能を提供できるかを確認する最も基本的なテストです。画面操作、データの入出力、計算処理、帳票出力など、ユーザーから見える機能の動作を検証します。

例えば、ログイン機能であれば、正しいID・パスワードでのログイン成功だけでなく、誤ったパスワードの入力時のエラー表示、連続失敗によるアカウントロック、セッションタイムアウト後の再ログインなど、様々なシナリオで動作を確認します。

ユースケーステストも機能検証の一種で、エンドユーザーの実際の利用シナリオに沿ってテストを実施します。例えば「新規顧客が会員登録して商品を購入し、領収書を印刷する」といった一連の業務フローを通して検証することで、機能間の連携や実用性を確認できます。

非機能要件の検証に関わる種類

非機能要件の検証では、システムの品質特性を多角的に評価します。代表的なテストタイプとその目的は以下の通りです。

テストタイプ	検証内容	主な確認項目
性能テスト	システムが要求される性能基準を満たしているかを測定	レスポンスタイム、同時アクセス数の上限、負荷時の動作、ストレス耐性、システムの限界値
セキュリティテスト	不正アクセスやデータ漏洩のリスクに対する防御能力を評価	認証・認可機能・SQLインジェクション等の脆弱性、通信データの暗号化、パスワードポリシー、ペネトレーションテスト
ユーザビリティテスト	システムの使いやすさを評価	画面レイアウトの直感性、操作手順の分かりやすさ、エラーメッセージの適切性、タスクの完遂率、ユーザー満足度
回復(リカバリ)テスト	システム障害や異常終了が発生した際に適切に復旧できるかを確認	データベースの自動バックアップ、トランザクションのロールバック、障害検知とフェイルオーバー、復旧手順の実効性

これらのテストタイプを適切に組み合わせることで、システムの非機能品質を総合的に保証できます。

その他の重要な種類

リグレッションテスト（回帰テスト）

リグレッションテストは、プログラムの修正や機能追加によって、既存の正常に動作していた機能に悪影響が出ていないかを確認するテストです。システムテスト期間中に不具合修正を繰り返すため、修正の都度、関連機能の動作確認が必要になります。効率化のため、自動化ツールを活用して定型的なテストケースを自動実行する手法が一般的です。ただし、極小規模のプロジェクトやUI/UXが頻繁に変更されるシステムでは、自動化の費用対効果が合わないケースもあります。自動化はプロジェクトの規模や変化の頻度に応じて判断しましょう。

構成テスト

構成テストでは、システムが様々な環境や構成で正しく動作するかを確認します。異なるOSバージョン、ブラウザの種類とバージョン、画面解像度、デバイス（PC、タブレット、スマートフォン）での互換性を検証します。また、他システムとの連携が必要な場合、連携先のバージョン違いによる影響も確認対象です。

これらのテストタイプを適切に組み合わせることで、多面的な品質保証が可能になります。

機能要件テストの技法：機能テストの具体的な手段

機能テストを効率的かつ効果的に実施するには、体系的なテスト設計技法を活用することが重要です。ここでは、実務でよく用いられる6つの代表的な技法を紹介します。

技法１：境界値分析

境界値分析は、入力値の有効範囲の境界付近で不具合が発生しやすいという経験則に基づく技法です。例えば、年齢入力欄が0～120歳という範囲を持つ場合、境界値として「-1, 0, 1」「119, 120, 121」といった値でテストします。境界値での不具合は、プログラムの比較演算子の誤り（<と<=の混同など）が原因で発生することが多く、この技法により効率的に検出できます。

技法２：同値分割法

同値分割法は、入力値の範囲を「同じ結果を返すはずのグループ」に分割し、各グループから代表的な値を1つ選んでテストする技法です。先ほどの年齢の例では、有効範囲を「0～17歳（未成年）」「18～64歳（成人）」「65歳以上（高齢者）」のように分割し、各グループから代表値（例：10, 30, 70）を選びます。この技法により、テストケース数を削減しながら効果的な検証が可能です。

技法３：組合せテスト

組合せテストは、複数の入力パラメータの組み合わせによる不具合を検出する技法です。実務において、不具合の多くは「特定の2つのパラメータの相互作用」によって発生するという経験則があります。この特性に基づき、全ての2つの組み合わせを少なくとも1回はテストすることを保証するのが「ペアワイズ法」です。

これにより、品質を保ちつつテストケース数を削減することができます。例えば、3つのパラメータがそれぞれ3つの値を取る場合、全ての組み合わせを網羅すると27通りになりますが、ペアワイズ法を用いれば9通りに削減できます。

技法４：デシジョンテーブルテスト

デシジョンテーブル（決定表）テストは、複数の条件とその組み合わせによる処理結果を表形式で整理し、テストケースを導出する技法です。複雑なビジネスルールや条件分岐が多い処理に適しています。例えば、割引計算のロジックが「会員種別」「購入金額」「キャンペーン期間」の3つの条件で決まる場合、それぞれの条件の真偽の組み合わせと、その結果適用される割引率を表にまとめます。これにより、すべての条件の組み合わせから矛盾する組み合わせを取り除くことができ、より詳細なテストケース数を導き出すことができます。

技法５：状態遷移テスト

状態遷移テストは、システムが複数の状態を持ち、イベントによって状態が遷移する場合に用いる技法です。状態遷移図を作成し、全ての状態遷移パスをカバーするテストケースを設計します。例えば、注文管理システムでは「注文受付」「決済待ち」「配送準備中」「配送完了」「キャンセル」といった状態があり、「決済完了」「出荷」「受取確認」「キャンセル申請」といったイベントで状態が遷移します。有効な遷移だけでなく、無効な遷移も正しくエラー処理されるかを確認することが重要です。

---

---

技法６：ユースケーステスト

ユースケーステストは、エンドユーザーの実際の利用シナリオに基づいてテストケースを設計する技法です。ユースケース図や業務フロー図をもとに、典型的な操作の流れと代替フロー、例外フローを洗い出します。例えば、「オンライン予約システム」のテストでは、「空き情報を確認して予約する」というようなフローがあるとします。「空き状況を確認→日時を選択→個人情報を入力→確認→予約完了」という基本フローに加え、「満席の場合」「入力エラーの場合」「予約変更」「予約キャンセル」といった様々なシナリオをテストします。

これらの技法を単独または組み合わせて使うことで、限られたリソースで最大の効果を発揮するテスト設計が可能になります。

効果的なシステムテストのための実践的なポイント

システムテストの品質と効率を高めるために、実務で特に重要とされる3つのポイントを解説します。

テストの独立性を確保する

テストの独立性とは、各テストケースが他のテストケースの実行結果に依存せず、単独で実行できる状態を指します。例えば、「ユーザー削除」のテストが「ユーザー登録」のテスト実行を前提とする場合、独立性が保たれていません。

独立性を確保するには、各テストケースの開始前にテストデータを準備し、終了後にクリーンアップする仕組み（テストフィクスチャ）が有効です。ただし、必ずしも完全な独立性が必要なわけではありません。テスト自動化を実施している環境では、テストケース間の依存関係を明確に文書化し、実行順序を適切に管理することで効率的なテスト運用が可能です。

テストベースとトレーサビリティの確保

テストベースとは、テストケースを作成する際の根拠となる情報全般（要件定義書、仕様書など）を指します。テストベースを明確にすることで、何を確認すべきかが明確になり、テストの網羅性が向上します。トレーサビリティ（追跡可能性）は、要件とテストケースの対応関係を管理することです。トレーサビリティマトリクスを作成し、各要件に対してどのテストケースで検証するかを明記します。これにより、全ての要件がテストでカバーされているか、逆に不具合が見つかった際にどの要件に影響するかが即座に把握できます。

リスクベースドテストによるカバレッジの設計

限られた時間とリソースで最大の効果を得るには、リスクベースドアプローチが有効です。システムの各機能や領域について、「ビジネスへの影響度」と「不具合の発生しやすさ」の2軸でリスクを評価し、高リスク領域を重点的にテストします。例えば、金銭処理や個人情報を扱う機能は影響度が高く、複雑なアルゴリズムや新規技術を使用した部分は不具合が発生しやすいため、これらを優先的にテストします。リスク評価に基づいて、高リスク領域は詳細なテストケースを作成し、低リスク領域は代表的なシナリオのみをテストするなど、メリハリをつけることで効果的です。

まとめ

システムテストは、開発したシステム全体が要求仕様を満たしているかを検証する重要な工程です。結合テストとの違いは対象範囲とテストベース、受け入れテストとの違いは目的と実施主体にあります。

システムテストには機能テストや性能テスト、セキュリティテストなど多様な種類があり、プロジェクトの特性やリスクに応じて適切に組み合わせることが重要です。境界値分析やデシジョンテーブルテストといったテスト技法を活用し、効率的かつ効果的な検証を進めましょう。

---