総合テスト（システムテスト）とは？結合テストとの境目と観点・発注者が見る成果物

総合テストは、単体テストと結合テストを終えたシステムを全体として動かし、要件定義書どおりに機能し、必要な性能や安全性を備えているかを開発会社が確かめる工程です。多くの現場でシステムテストと同じ意味で使われ、位置は受入テストの直前です。本記事では、結合テスト・受入テストとの境目、機能と非機能の両面で確かめる観点、計画から完了報告までの流れを整理します。後半では、発注者が総合テストの成果物をどう読み、どこで判断を誤りやすいかを具体的に解説します。

まとめ：総合テストは開発会社が要件どおりかを全体で確かめ発注者は報告書で判断する工程

総合テストの実施者は開発会社です。要件定義書を基準に、業務の流れを端から端まで通す機能テストと、応答時間・同時アクセス・障害時の復旧・セキュリティといった非機能テストを、本番に近い環境で行います。

発注者が手を動かす工程ではありません。それでも、テスト計画書で範囲と終了基準を、完了報告書で不具合の収束と未解決の欠陥を確認することは発注者の仕事です。結合テストとの境目や「総合テスト」という言葉が指す範囲は会社によって違うため、見積もりの段階で定義をそろえてください。非機能要件が数値で決まっていない案件では、総合テストで合否を判定できないことも押さえておく必要があります。

総合テストとは何か｜システムテストと同じ工程を指す呼び名とV字モデル上の位置

総合テストは、テスト工程のうち開発会社が担う最後の段階です。言葉の定義と、現場での呼び名の揺れから確認します。

総合テストの定義｜システム全体の振る舞いを要件定義書に照らして確かめる

国際的なテスト技術者資格の教材であるJSTQBのFoundation Levelシラバス（V4.0・2023年4月12日版）は、2.2.1節でシステムテストを、エンドツーエンドのタスクに対する機能テストや品質特性に対する非機能テストといった、システムやプロダクト全体の振る舞いや能力に焦点を当てるテストレベルと説明しています。一部の非機能品質特性は本番相当の環境で、すべてそろったシステムを使ってテストするのが望ましいとも書かれています。

V字モデルに当てはめると、総合テストは要件定義（とくにシステム要件）と対になる工程です。単体テストが詳細設計を、結合テストが基本設計を確かめるのに対し、総合テストは「要件定義書に書いたことが、完成したシステムで実現しているか」を確かめます。テスト工程全体の並びとV字モデルの対応はシステム開発のテスト工程とは？種類・流れとV字モデルで解説しています。

総合テスト・システムテスト・ST・システム試験という4つの呼び名の違い

「総合テスト」「システムテスト」「ST」「システム試験」は、ほとんどの現場で同じ工程を指します。ただし例外があり、会社によっては総合テストに運用テストや本番環境での確認まで含めたり、逆に外部システムとの連携確認を結合テストに入れたりします。

この揺れは、見積書の工数と責任範囲に直結します。開発会社Aの「総合テスト」が性能テストを含み、開発会社Bの「総合テスト」が機能テストだけなら、同じ名前の工程でも中身と費用が違うということです。相見積もりを取る段階で、総合テストに含まれるテストの種類と、実施する環境（開発環境か本番相当の検証環境か）を一覧で出してもらうと比べられます。

総合テストと結合テスト・受入テストの境目｜実施者・基準文書・環境の比較

総合テストは前後の工程と名前が似ており、境目が分かりにくい工程です。違いを属性ごとに並べると、役割の線引きが見えてきます。

単体・結合・総合・受入の4工程を実施者と基準文書で並べた比較表

JSTQBシラバスは、テストレベルどうしの重複を避けるため、テスト対象・テスト目的・テストベース・欠陥・アプローチと責務の5つの属性で区別するとしています。受託開発の一般的な分担に当てはめると、次のとおりです。

総合テストと受入テストは、対象も環境もほぼ同じです。違いは物差しで、総合テストは「要件定義書どおりか」、受入テストは「業務に使えるか」を問います。受入テストの進め方と合否基準は受入テスト（UAT）とは？進め方と合否基準・システムテストとの違いで詳しく扱っています。

外部システム連携はどちらに入るか｜結合テストとの境目が揺れる理由

結合テストと総合テストの境目が最も揺れるのは、会計システムや決済サービス、既存の基幹システムとのつなぎ込みです。JSTQBシラバスは統合テストを、コンポーネント同士をつなぐ「コンポーネント統合テスト」と、他のシステムや外部サービスとのインターフェースを確かめる「システム統合テスト」に分けています。日本の現場では前者を結合テスト、後者を総合テストの一部として扱うことが多い一方、連携先の検証環境が用意できる時期によって順番が入れ替わります。

連携先の都合で総合テストの終盤まで本物の外部システムにつなげない案件では、模擬の応答で済ませた範囲と、本物で確かめた範囲を分けて記録してもらってください。この区別が無いまま進むと、受入テストで初めて本物の連携先につなぎ、文字コードや締め時刻の食い違いが見つかります。画面からデータベースまで通しで確かめるE2Eテストとの関係はE2Eテストとは？結合テストとの違いとエンドツーエンドテストのベストプラクティスにまとめています。

総合テストで確かめる観点｜業務を通す機能テストと性能・安全性の非機能テスト

総合テストの観点は、機能と非機能の2系統に分かれます。量が多いのは機能テストですが、手戻りが大きいのは非機能テストのほうです。

機能テストの観点｜業務シナリオの通し・権限・帳票・夜間バッチの確認

総合テストの機能テストは、画面単位ではなく業務の流れ単位で組みます。受注から出荷、請求、入金消し込みまでを1本のシナリオとして通し、途中の画面や帳票、メール通知、夜間バッチの結果がつながっているかを確かめます。

見落としが出やすいのは、権限と日付です。営業・経理・管理者といった役割ごとに見える画面と操作できるボタンが要件どおりか、月末・年度末・うるう年をまたぐ処理で集計が崩れないかは、結合テストまでの段階では確かめにくい観点です。テストケースにこれらが入っているかは、テスト仕様書の段階で確認できます。テストケースの項目と書き方はテスト仕様書とは？書き方とテストケースの項目・発注者がレビューで見る観点で解説しています。

非機能テストの種類｜ISO/IEC 25010の品質特性とテストの対応表

JSTQBシラバスの2.2.2節は、ISO/IEC 25010が非機能の品質特性として挙げる7つ（性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性）を示し、非機能テストはシステムが「どのようにうまく振る舞うか」を確かめるものと説明しています。総合テストで行う代表的なテストと対応させると次のとおりです。

すべてを同じ厚さで行う必要はありません。利用者が社内の数十人に限られる業務システムなら負荷テストは軽くし、個人情報や決済を扱うなら脆弱性診断を厚くする、という配分を計画書で決めます。負荷テストの具体的な手順はk6とは？Grafana k6の使い方と負荷テストの書き方を、外部への診断依頼は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を参照してください。

非機能要件が数値で無い案件は総合テストで合否を判定できない理由

非機能テストには、合格の線が要ります。「レスポンスが速いこと」としか要件定義書に書かれていなければ、応答が2秒でも8秒でも、開発会社は不合格と判定できません。総合テストで性能や可用性の不具合が「見つからない」のは、品質が高いからではなく、判定の基準が無いからということがあります。

IPAが公開している非機能要求グレードは、可用性、性能・拡張性、運用・保守性、セキュリティ、システム環境・エコロジーなど6つの大項目で非機能要求を整理したツール群です。2018年4月25日付の非機能要求グレード2018 改訂情報によれば、全体236メトリクスのうち2メトリクスを新規追加し、20メトリクスを修正しています。総合テストの直前で慌てないよう、要件定義の段階でこの項目一覧を使い、応答時間・稼働率・復旧時間を数値で決めておいてください。数値化の方法は非機能要件とは？6大項目の数値化とk6での閾値テストで解説しています。

総合テストの進め方｜計画から不具合の収束、完了報告までの5つの手順

総合テストは、結合テストの完了を待ってから準備を始めると間に合いません。開発会社の作業の流れは、おおむね次の5手順です。

1. 総合テスト計画書を作り、範囲・環境・体制・開始基準と終了基準を決める
2. 要件定義書の項目ごとにテストケースを起こし、テスト仕様書にまとめる
3. 本番相当の検証環境とテストデータ、外部連携先の接続を準備する
4. テストを実施し、見つかった不具合を記録して修正と再テストを繰り返す
5. 終了基準を満たしたことを確かめ、完了報告書を発注者に提出する

手順1と2は、開発の後半と並行して進めるのが一般的です。発注者が関わるのは主に手順1・2・5の成果物で、その読み方は次の章で扱います。

開始基準と終了基準｜結合テスト完了と未解決不具合の件数で区切る

JSTQBシラバスは2.2節で、シーケンシャルな開発モデルでは、あるテストレベルの終了基準が次のレベルの開始基準の一部になるように定義されることが多いと述べています。総合テストに当てはめると、結合テストの終了基準を満たしたことが総合テストの開始条件になります。

開始基準の例は「結合テストの重大な不具合が0件」「検証環境の構築と外部連携先の接続が完了」です。終了基準の例は「計画したテストケースの実施率100%」「重大な未解決不具合0件」「直近1週間で新たな重大不具合が出ていない」となります。修正のたびに周辺機能を流し直す範囲の決め方はリグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化と実施判断にまとめています。

発注者が確認すべき総合テストの成果物｜計画書・仕様書・完了報告書の読みどころ

総合テストを発注者が自分で実施することはありません。代わりに、開発会社が作る3つの文書を受け取り、それぞれで決まった点を確かめます。

総合テスト計画書｜範囲から外したテストと終了基準の数値を見る

計画書で最初に見るのは、何をテストするかよりも、何をテストしないかです。性能テストを行わない、特定のブラウザは対象外、外部連携は模擬の応答で確かめる、といった除外事項が書かれていれば、そのリスクを発注者が受け入れるか、受入テストで補うかを決められます。除外事項の欄が無い計画書は、範囲を決めていないのと同じです。

次に、終了基準が件数や割合で書かれているかを確かめます。「品質が十分と判断した時点で終了」のような書き方なら、数値に直すよう求めてください。

総合テスト仕様書｜要件定義書の各項目にテストケースが対応しているか

仕様書は全件を読む必要はありません。見るのは、要件定義書の項目とテストケースの対応関係です。要件番号ごとにテストケース番号が振られた対応表（トレーサビリティマトリクス）があれば、テストケースが1本も紐づいていない要件をすぐに見つけられます。

とくに確認したいのは、非機能要件と、例外的な業務の扱いです。応答時間や同時接続数の要件にテストケースが無い、返品・キャンセル・取消のシナリオが無い、という抜けは、仕様書の段階なら追加の依頼だけで済みます。

総合テスト完了報告書｜不具合の収束状況と未解決欠陥の一覧を確かめる

JSTQBシラバスの5.3.2項は、典型的なテスト完了レポートの内容として、テスト概要、テスト計画書に基づくテストとプロダクト品質の評価、計画からの逸脱、テストの阻害要因と回避策、テストメトリクス、未解決のリスクと修正されなかった欠陥、学んだ教訓を挙げています。発注者が優先して読むのは、次の4点です。

• 修正されなかった欠陥の一覧と、それぞれの重大度・回避策・修正予定日
• 日ごとの不具合の検出件数の推移（終盤に新規の検出が減っているか）
• 計画からの逸脱（実施しなかったテストケースとその理由）
• 終了基準の各項目に対する実績値

検出件数の推移は、終盤になっても新しい不具合が毎日同じペースで見つかっているなら、品質が安定していない兆候です。その状態で受入テストへ進むと、業務担当の時間が不具合の報告で消えます。受入テストの開始を遅らせてでも、開発会社に総合テストの延長を求める判断が要ります。

総合テストで発注者が判断を誤る場面｜短縮・丸投げ・二重化の3つの型

総合テストの失敗は、テスト技法よりも発注者の判断で起きます。採るべきでない進め方を、条件付きで挙げます。

納期を守るために総合テストを短縮し受入テストで拾う計画の失敗

開発が遅れたとき、総合テストの期間を削って稼働日を守り、残りは受入テストで見つければよいという計画が出ることがあります。この計画は採りません。受入テストの担当は業務部門の社員で、要件定義書と突き合わせて機能の誤りを網羅的に探す訓練を受けていないためです。性能や障害回復のような非機能の不具合は、受入テストの操作ではまず見つかりません。

稼働日を動かせないなら、総合テストを短縮するのではなく、稼働時の機能範囲を絞る交渉をします。後から追加する機能を決め、その分の総合テストを稼働後に回すほうが、品質の判断がつきます。

完了報告書を「完了しました」の一言で受け取り中身を確かめない失敗

総合テストの完了を口頭やメールの一言で受け、報告書を求めないまま受入テストに入る進め方も避けてください。修正されなかった欠陥の一覧を受け取っていなければ、受入テストで見つかった不具合が既知のものか新しいものか区別できず、判定会議が混乱します。

社内に報告書を読める担当がいない場合は、発注者側に立って要件定義からテスト計画・報告書のレビューまでを支える体制を外部に求める方法があります。一創の要件定義・RFP作成・PMO支援では、非機能要件の数値化から、総合テストの計画書・完了報告書のレビュー、受入テストの準備までを発注者側で支援しています。

第三者検証を入れるべき案件と総合テストとの二重化で過剰になる案件

開発会社の総合テストに不安があるとき、別の検証会社に同じ範囲をもう一度テストさせるのは、多くの場合過剰です。同じ要件定義書から同じようなテストケースを作れば、見つかる不具合も重なります。

第三者検証を入れる価値があるのは、決済や個人情報を扱い脆弱性診断の専門性が要る場合、利用者が数万人規模で負荷テストの設備が要る場合、開発会社の報告書で不具合の収束が確かめられない場合です。それ以外の業務システムなら、総合テストの計画書と完了報告書のレビューを厚くするほうが費用を抑えられます。役割分担と費用の決まり方は第三者検証とは：開発会社のテストとの役割分担・費用の決まり方・発注のタイミングで解説しています。

総合テストの期間・費用・実施者について発注者からよくある質問

総合テストの計画や見積もりについて、発注者から寄せられやすい質問に回答します。

総合テストとシステムテストは違うものですか？

多くの現場では同じ工程を指しています。システムテストを日本語にしたものが総合テストで、ST、システム試験と呼ぶ会社もあります。ただし、会社によっては総合テストに運用テストや本番環境での確認まで含めることがあり、範囲は一律ではありません。見積もりや計画の段階で、どのテストの種類と環境を含むのかを一覧で確認しておくと、開発会社ごとの違いを比べられます。

総合テストの期間はどれくらいが目安ですか？

一律の目安はなく、テストケースの件数、非機能テストの有無、不具合の修正と再テストの回数で決まります。期間を見積もるときは、テストケースを一巡する日数に加えて、修正版での再テストと周辺機能のリグレッションテストの日数を含めているかを確かめてください。性能テストや外部連携の確認は、検証環境や連携先の準備が整う日に左右されるため、計画書でその前提を明記してもらうと遅れの原因を追えます。

総合テストは発注者も立ち会う必要がありますか？

立ち会いは必須ではありません。総合テストは開発会社が要件定義書に照らして行う工程で、発注者の役割は計画書・仕様書・完了報告書の確認です。ただし、業務シナリオのテストケースに抜けがないかを確かめるために、仕様書のレビューには業務担当にも入ってもらうほうが安全です。主要なシナリオの実施日に限って画面を一緒に見る程度の立ち会いなら、受入テストの準備にも役立ちます。

総合テストの費用は開発費のどれくらいを占めますか？

決まった比率はなく、非機能テストの範囲と自動化の有無で大きく変わります。見積書でテスト工程がまとめて1行になっている場合は、単体・結合・総合の工程別に分け、総合テストに含まれるテストの種類と人日を出してもらってください。負荷テストや脆弱性診断を外部に依頼する場合は、その費用が見積もりに入っているかも確認が要ります。

アジャイル開発でも総合テストは行いますか？

行いますが、形が変わります。スプリントごとに機能を作るたびに、その機能のテストと既存機能のリグレッションテストを自動化して回し、リリースの前にシステム全体の通しのシナリオと非機能テストをまとめて行う進め方が一般的です。請負契約で発注する場合は、スプリントごとの確認とは別に、リリース前の総合テストの範囲と終了基準を契約か計画書で決めておきます。

関連記事

• システム開発の品質管理とは？工程別レビュー・テスト管理とメトリクス判定の手順：総合テストの完了報告書で使うメトリクスの読み方を、品質管理の全体像から解説しています。
• 機能要件とは？業務要件・非機能要件との違いと書き方、機能一覧の記載例：総合テストの基準になる要件定義書の書き方を整理しています。
• ウォーターフォール開発とは？工程・V字モデルと契約、向く案件を発注者目線で解説：総合テストが置かれる工程の並びと契約の関係をまとめています。