システムテスト（総合テスト）とは？種類・違い・実際の流れを解説【2024年最新版】

システムテストとは、すべてのサブシステム・プログラムを結合し、システム全体として要件通りに動作するかを検証するテストのことです。

ユーザーが使う本番環境、もしくはそれを想定した環境にシステムを置き、実稼働と同様の負荷をかけて機能・パフォーマンスに問題がないかを確認します。システム開発の成否を決める重要な工程です。

本記事では、システムテスト（総合テスト）を中心に、システム開発のフェーズごとに実施されるテスト工程を徹底解説します。テストの流れ・方法を知ることで、自社が何をすべきなのか把握できます。

※開発したシステムのテストを進めることに不安な方はシステム幹事にご相談ください。専任のアドバイザーがテスト工程も丁寧に対応する会社を厳選してご紹介します！

【無料】おすすめのシステム開発会社を紹介してもらう

システムテスト（総合テスト）とは？

システムテストでは、実稼働時と同様の負荷をかけても機能要件・非機能要件を満たせるか、開発したシステムを総合的に検証します。サブシステムごとの機能検証は結合テストまででほぼ完了しているため、検証結果を補完しつつ総合的に検証するため以下のテストが実施されます。

• 確認テスト
• 評価テスト
• 負荷テスト

システムテストは「要件定義で策定・作成したシステムテスト仕様書通りにシステムが動作するか？」「不具合がないか？」を確認することが目的です。

一般的にシステムテストは、選任のテスターが担当するケースがほとんどで、開発に携わったSEやプログラマーが参加することはあまりありません。

システムテストは、要件定義時に策定・作成された「システムテスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、システムテストと要件定義がリンクしているのはこのためです。

システムテストは開発会社側が実施する最後のテストでもあり、品質の担保された要求通りのシステムを引き渡すための非常に重要性の高い工程です。パフォーマンスも含めた総合的な観点からシステム検証することから「総合テスト」とも呼ばれています。

要件定義についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事：システム開発の要件定義とは？受託開発における重要性や進め方を解説！

テスト工程のみならず、要件定義も正確に行える自信がない方は、システム幹事にご相談ください。専任のアドバイザーが要件定義も丁寧に行うおすすめの会社を厳選してご紹介します。

システムテスト（総合テスト）と受け入れテスト・結合テストの違い

システムテスト（総合テスト）と受入テスト・結合テストは、いずれもソフトウェア開発で行われるテストです。主な違いは以下の表の通りです。

次の見出しから、それぞれの違いについて解説します。

受け入れテストとの違い

受け入れテストは、開発したシステムが本番環境で問題なく機能するか確かめるためのテストです。

システムテストも問題なく機能するか確かめるためのテストですが、実施者が異なります。

システムテストは、完成したシステムに要件通りの機能と性能が搭載されているか開発者が確認します。一方受け入れテストを実施するのは、システム開発の発注者です。

つまりシステムテストは発注者が、受け入れテストは開発者が機能や性能に問題がないか確認するために実施しています。

発注者側で実施するのはシステムテストであり、受け入れテストの実施は不要です。

結合テストとの違い

結合テストは、システムテストの前段階で実施されるテストです。各モジュール（部品）を複数組み合わせた際に、以下2つのテストを実施します。

1. 内部結合テスト：インターフェースの動作確認
2. 外部結合テスト：外部システムの接点やデータ連携の動作確認

システムテストは、要件定義の内容に沿っているかを確認するテストです。一方結合テストは、基本設計書の内容に沿っているかを確認します。

つまりシステムテストと結合テストの違いは、確認の基準となる対象です。

受け入れテスト・結合テストのより詳しい内容は「システム開発のテスト：受入れテスト（ユーザーテスト）」「システム開発のテスト：結合テスト」の見出しで解説しています。

システムテスト（総合テスト）の種類

確認テスト

ここからシステムテスト（総合テスト）で行う作業を解説します。まずは確認テストです。

各モジュール・サブシステムのテスト・修正を経て変更されたプログラムや、プログラム同士の連携に不具合がないか？正しい挙動を示しているか？検証するために実施されるのが「確認テスト」。

これは、システムが複雑化するほど、1つの修正がほかに影響を与える可能性が高くなるため。確認テストで実施される主要な手法は以下の2つです。

評価テスト

評価テストとは、使い勝手、セキュリティ、障害時の耐性など、システムの性能を評価して検証するテストのこと。評価テストで実施される主要な手法は以下の3つです。

負荷テスト

負荷テストとは、システムに大きな負荷をかけて稼働させ、耐久性やパフォーマンスに問題が生じないかを確認・検証するテストのこと。負荷テストで実施される主要な手法は以下の5つです。

ロングランテスト

ロングランテストとは、一定の期間連続して製品やシステムを稼働させ、その動作や信頼性を確認するテストです。

システムテストの一環として実施され、短時間で起こりにくい不具合や品質劣化、性能の低下などを調べます。

多くのシステムは長時間稼働させるとパフォーマンスの低下につながるため、ロングランテストは品質維持のために欠かせない工程です。

ちなみにロングランテストで検出できる項目は、下記の通りです。

• 品質の劣化
• システムの不具合
• 性能の低下
• 処理能力や稼働率の問題の有無
• 応答速度の低下

ユーザビリティテスト

ユーザビリティテストは、Webサイトやアプリの使い勝手改善のため、実際にユーザーに使ってもらうテストのことです。

ユーザビリティ上の問題点を見つけ、ユーザー視点での行動や心理を把握することができます。

現状の課題を浮き彫りにしたいときに活用できるテストです。

セキュリティテスト

セキュリティテストとは、サーバーやシステム、アプリなどの不具合を検知する工程です。

脆弱性管理や脆弱性の検査などとも呼ばれる場合もあり、脆弱性がないかを診断できます。

また、セキュリティテストには脆弱性診断の他にもペネトレーションテストというテストがあります。

セキュリティの専門家がサイバー攻撃をする人と同じ視点でシステムに侵入し、個人情報などの情報資産を奪取することを試すタイプのテストもあるのです。

回帰テスト

回帰テスト（リグレッションテスト）とは、システム変更時に既存の機能が破壊されていないかを確認する工程です。

システム開発の中でも大切な工程ですが、以下の理由から省略されてしまうこともあります。

• 修正に割く時間
• 工数、納期の都合

ただ、回帰テストを省略してしまうと「システム納品後の画面が開かない」「システムの処理が終わらない」といった具合で、基本機能を損なうリスクがあるので注意が必要です。

【無料】おすすめのシステム開発会社を紹介してもらう

システムテストの観点

機能要件

システムテストの観点での機能要件は、ソフトウェアの機能がエンドユーザー（顧客）が求める通りの動作をするのかを確認するテストです。

そのため、システムテストをする前に、機能要件を理解する必要があります。

非機能要件

非機能テストは、システムテストレベルや受入テストの段階で実施されることが多いですが、単体テストや結合テストなどの各テストの間に行われることもあるテストです。

主に非機能要件を確認するテストでは、

• 性能テスト
• ストレステスト
• 保守性テスト
• 高頻度テスト
• 累積稼働テスト
• 障害対応テスト
• セキュリティテスト
• ボリュームテスト
• ユーザービリティテスト

システムの機能に分類されない全体的な動作や、セキュリティ面でのテストが行われます。

システムテスト実施の流れ

システムテストが実施される流れは、以下5段階です。

1. テスト計画：テストの内容、種類を決める
2. テスト準備：確認したいことを具体化し、テストケースを作る
3. テスト実行：準備した内容をもとに実行する
4. 進捗管理：進捗や不具合、変更などの情報を関係者に共有する
5. テスト完了：テストの結果を分析し終了報告書にまとめる

まずテスト計画を行い、合格基準をまとめます。準備ができ次第計画を確認しながら実行し、異なる結果が出た場合は不具合発生時のフローに従って起票します。

テストが完了したら終わりではなく、結果をテストの合格基準と合わせて終了報告して完了です。

システムテストの観点を洗い出し・設定する方法

システムテストの観点とは、システムが正しく動作するため「どの部分にどのようなテストを実施すべきか」の定義をまとめたものです。

システムテストの観点を考える際、重要となるのは以下の要素です。

1. 機能要素：検証する機能・動作を要件定義書から洗い出す
2. 検証方法：対象のシステム・機能をどのようにテストするか
3. 入力条件：テスト対象に何をインプットするか
4. 出力結果：テスト対象の何を観察するか

上記4つの要素を組み合わせて、観点が設定されます。

システムテストの観点の洗い出し・設定について分からないことがある場合も、システム幹事にご相談ください。システムテストの観点につきましても、無料でサポートさせていただきます。

【無料】おすすめのシステム開発会社を紹介してもらう

システムテスト計画書の書き方

「テスト方針」の記述内容

テスト方針書の記述内容は下記のとおりです。

• テストのフェーズ全体構成
• 各テストの位置づけや目的
• テスト方針やテストの開始・完了基準
• テストケースの定義方法
• テストスケジュール
• テストを実施する組織計画

テストチーム全体で共通認識ができるよう、テスト設計と実施する内容を具体的、かつ分かりやすく記述しなくてはなりません。

「要員・体制」記述内容

テスト計画書の「要員・体制」の項目には、各要員の役割や組織体制が記載されています。具体的には下記の内容です。

• テストを実行する方法や各役割
• 各人員同士のコミュニケーション方法

「スケジュール」記述内容

準備からテストの設計・実行・修正確認などの工程が存在するため、それぞれの工程でスケジュールを決めるのがコツです。

主にスケジュールの書き方はガントチャートなどで表現されます。テストの進捗を正確に測るために、全体のテストシナリオ、テストケースの総数などを考慮し、具体的な日程に落とし込みましょう。

テストプランはひとつに絞らず、複数のシナリオを作成し、効率的に行うことが求められます。

「テスト環境・ツール」記述内容

テスト環境・ツールには、テスト自動化ツールと、テスト管理ツールに分けられます。

テスト自動化ツールは、開発におけるテストを自動化するためのツールです。対応デバイスには、デスクトップからモバイルアプリなどさまざま。

テスト計画書に記述する内容は、テスト環境のほか、テスト端末、テスト自動化ツールなどを記述します。

「各種管理規定」記述内容

各種管理規定において記述する内容は、不具合管理や進捗管理の基準と手法などです。

特に、テストレベルに固有しない各種ルールを定義して、進捗や品質のモニタリング、不具合管理などが含まれます。

テストを円滑に管理するためにも、テストケースの仕様書を規定しておくと良いでしょう。

システムテスト以外のシステム開発のテスト・流れ

システム開発におけるテストの役割は、開発したプログラム・システムが問題なく動作するか、不具合がないかをチェックして修正すること。
人の手が介在するシステム開発では、バグがないということはあり得ません。不具合を解消し、問題なくシステムを活用するためにもテスト工程は必須です。

たとえば、システム開発の現場でもっともポピュラーな開発モデル「ウォーターフォール型」を採用している場合、「単体テスト」「結合テスト」「システムテスト（総合テスト）」「受け入れテスト（ユーザーテスト）」の、大きく4つのテスト工程が実施されます。

テストが4つの工程に分かれているのは、以下2つが大きな理由です。

・設計時にシステムを細かいモジュールに分解し、プログラムごとに開発を進める
・テスト工程ごとに目的・重要性が異なる

具体的な手法とともに、それぞれのテスト工程における目的・重要性を解説していきましょう。

ウォーターフォール型システム開発についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事：ウォーターフォール型システム開発とは？開発工程・メリット・アジャイル型との違いを解説！

【無料】おすすめのシステム開発会社を紹介してもらう

システム開発のテスト：単体テスト

単体テストとは、分割されたモジュール（部品を集めて機能を持たせたもの）・プログラム単体ごとに実施するテストのこと。部品・構成要素（Component）、構成単位（Unit）ごとに実施されるため、コンポーネントテスト、ユニットテストと呼ばれる場合もあります。

選任のテスターが担当する場合もありますが、基本的にはモジュールのプログラミングを担当したシステムエンジニア（SE）・プログラマーが単体テストを実施します。

単体テスト設計は詳細設計で作成

単体テストは、V字モデルに沿った「詳細設計」で策定・作成された「単体テスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、単体テストと詳細設計がリンクしているのはこのためだといえるでしょう。

単体テストの目的は、詳細設計書通りにモジュール・プログラムが動作するか？不具合がないか？確認すること。

システムの最小単位であるモジュール・プログラムなら、不具合を発見しても修正が容易。不具合を取り除いておけば、その後の問題切り分けもにも有利です。テスト工程全体をスムーズに進めるためにも、最初のステップである単体テストの重要性は高いのです。

関連記事：システム開発の詳細設計とは？プロジェクトの位置付け・役割をわかりやすく解説！

単体テストの手法

単体テストでは、インターフェース（操作画面）がない「ドライバ」など、一時的に制作されたプログラムをテストする場合がほとんど。このため、単体テストではプログラム内部に着目した「ホワイトボックステスト」という手法を中心にしたテストが実施されます。

ホワイトボックステスト

ホワイトボックステストとは、制作されたプログラムが設計通りの処理を実行できるか？網羅的に検証するテストのこと。あくまでもプログラムの内部構造や処理を検証するテストであり、設計時の仕様が正しいかどうかを検証するものではありません。

このことから、ホワイトボックステストはプログラムを「開発側の視点」に立って検証するテストだといえるでしょう。

具体的には、プログラムの「条件」「条件の分岐」「分岐後の命令」などを確認する制御フローテスト、プログラム内で定義した変数・固定値が適切に使用されているか確認する、データフローテストなどが挙げられます。

【無料】おすすめのシステム開発会社を紹介してもらう

システム開発のテスト：結合テスト

結合テストとは、テストの完了したモジュールをサブシステムとして結合し、意図した通りに動作するかを検証するテストのこと。多くの場合で選任のテスターが担当しますが、プログラミングを担当したSE・プログラマーがテストする場合もあります。

結合テスト設計は基本設計で作成

結合テストは、基本設計時に策定・作成された「結合テスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、結合テストと基本設計がリンクしているのはこのため。

結合テストの目的は、基本設計書通りにサブシステムが動作するか？不具合がないか？確認することです。

モジュール単体では問題なくても、組み合わせた場合に起こり得る、想定外のエラーを排除するためにも、結合テストは重要性の高い工程だといえるでしょう。システム内部のサブシステムを検証する「内部結合テスト」以外に、外部システムとの連携を検証する「外部結合テスト」が実施される場合もあります。

基本設計についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事：システム開発の基本設計とは？重要性・発注者としての関わり方を解説！

結合テストでは、サブシステムへの入力に対する正しい出力データが得られているか？正常なデータが引き渡されているか？結合したモジュール・プログラム間の連携を検証します。

テスト手法としては単体テストでも紹介した「ホワイトボックステスト」に加え、「ブラックボックステスト」「トップダウン・ボトムアップテスト」が代表的です。

ブラックボックステスト

ブラックボックステストとは、結合されたサブシステムにデータを入力し、正しい出力データが返ってくるかを検証するテストのこと。ホワイトボックステストとは逆に、プログラムの内部構造は検証せず、サブシステムが仕様書通りに動作するかを検証するものです。

このことから、ブラックボックステストはプログラムを「発注側・利用側の視点」に立って検証するテストだといえるでしょう。

ブラックボックステストは、プログラムの内部に着目した単体テストでは見逃してしまう、仕様の不備や設計ミスなどを探しだし、修正していくために欠かせないテスト工程です。

トップダウン・ボトムアップテスト

結合テストを実施する方法としては、サブシステムの上位モジュールから順番に検証していく「トップダウンテスト」、逆に、サブシステムの下位モジュールから順番に検証してく「ボトムアップテスト」の2つがあります。

優先度の高い機能からテストできるボトムアップ、仕様書との違い・機能のモレを発見しやすいトップダウンという特性があり、状況に応じて使い分けられています。

トップダウンテストでは機能漏れ、仕様の認識違いは検証できますが、開発とテストの同時進行が難しいことが欠点。一方のボトムアップテストは開発とテストを同時並行できるものの、やり直しが発生する可能性があります。そのため、トップダウンテストとボトムアップテストを併用することがあるのです。

【無料】おすすめのシステム開発会社を紹介してもらう

システム開発のテスト：受入れテスト（ユーザーテスト）

受け入れテストとは、完成したシステムが要件を満たす機能・性能を保持しているか？発注側が総合的に検証するテストのこと。総合的にテストするという意味ではシステムテストと同様ですが、ユーザーである発注側がテストを担当するため、ユーザーテストと呼ばれる場合もあります。

受け入れテスト設計は要求定義・要件定義で作成

受け入れテストは、要件定義時に策定・作成された「受け入れテスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、受け入れテストと要件定義がリンクしているのはこのため。

本来、受け入れテストは「要求定義」とリンクされるべきではありますが、要求定義をもとにシステム要件（システム化するもの、しないものを決める）を定義したものが要件定義書・仕様書であるからです。

関連記事：システム開発における要求定義の重要性｜要件定義との違いや要求定義の実態・改善ポイントを解説！

受け入れテストは、目的・ゴールを達成できるシステムが納品されたのか？後々のトラブルを避けて確実に検収するためにも非常に重要性の高いテスト工程です。本来であれば、システムテストと同様、総合的なテストを念入りに実施することがベター。

ただし、システムテストで完了しているテスト項目もあるため、受け入れテストでは機能・ユーザビリティテストを中心に検証するケースが一般的。運用テストとして負荷テストを実施する場合もありますが、システムテストほど念入りに実施されないこともあります。

受入れテスト（ユーザーテスト）の手法

機能テスト（正常系・異常系）

機能テストとは、要件定義書・仕様書通りの機能要件を満たしているか？実稼働時の状況を想定しながらシステム全体の動作を検証するテストです。

具体的には、通常稼働時を想定したデータ入力・使い方をした場合に、正しい値が返されるか？動作に問題がないか？検証する正常系機能テスト。イレギュラーなデータが入力された、間違った使い方をした場合に、システムがどのような挙動を示すのか？検証する異常系機能テストが実施されるケースがほとんど。

正常系・異常系ともに、さまざまな条件を想定したテストデータを用意したうえで実施されます。

ユーザビリティテスト

ユーザビリティテストとは、実際の業務、あるいはそれを想定したシナリオを用意してシステムを稼働させ、ユーザーの使用感・操作感などをチェック・検証するテストのこと。

たとえば、ボタンの位置や大きさなどのインターフェース関連のほか、入力不備があった際のエラーメッセージの内容がわかりやすいか？ユーザー自身で問題解決できる操作感が得られるか？などが検証されます。

疎通テスト

疎通テストとは、外部システムなどと問題なく疎通（リクエストに対するレスポンス）できるか？検証するテストのこと。外部システムとの連携が要件として定義されているならば、すでに結合テストで実施済であるため、最終確認の意味合いで実施されるケースが多いようです。

セキュリティテスト

システムテストでも実施されるセキュリティテストは、本番環境に置かれた受け入れテストでも再度実施されます。外部攻撃を想定した不正な値、攻撃コードを用意し、システムがキチンと回避できるかどうかを検証することが一般的です。

負荷テスト

システムテストで実施される負荷テストは、運用テストとして受け入れテスト時に追加で実施される場合もあります。

システムテストに準拠した内容で行われる場合もありますが、性能テスト、キャパシティテストなどに限定するケースも。受け入れテストにおける負荷テストは、比較的プライオリティを低めに設定する場合が多いといえるでしょう。

受け入れテストには開発会社の協力が欠かせない

納品されたシステムが、仕様書通りの機能要件・非機能要件を満たしているか？確認するうえでも重要な受け入れテストですが、すべての発注側企業がテスト体制を整えられているわけではないでしょう。あらかじめデータを用意する必要もあるため、どのように対処していいのか困惑してしまう方も多いかもしれません。

そのためにも、パートナーとなるシステム開発会社との協力関係構築が重要。「受け入れテスト仕様書」策定・作成を依頼する以外にも、テストデータ作成、単体〜システムテストまでのテスト結果共有、テストツールの活用など、あらゆる面で協議を重ねておく必要があります。もっとも上流の工程となる、要件定義フェーズが非常に重要なポイントとなります。

【無料】おすすめのシステム開発会社を紹介してもらう

アジャイル型システム開発のテスト工程

ここまでで、大きく4つに分類できるシステム開発のテスト工程を解説してきました。ただし、これはあくまでも「ウォーターフォール型システム開発」における一般的な例。システム開発の手法によっては、本記事の解説が当てはまらない場合もあります。

たとえば、システムをおおまかな機能に分割し、設計・開発・テスト・リリースを繰り返して（イテレーション）完成系を目指すアジャイル型の場合はどうでしょう？

イテレーションのサイクルに「テスト」が含まれていることからもわかるように、アジャイル型にもテスト工程は存在します。ただし、小さな機能ごとに短期間でのリリースを繰り返すため、ウォーターフォール型のように綿密なテストは実施されません。テストに時間をかけていては、アジャイル型の特徴（俊敏な開発）を活かせないからです。

そのため、アジャイル型におけるテスト工程は「ツールを活用した自動化」が目指されており、発注側はテストとリリース後のレビューを通じて、開発側にフィードバックを伝える役割を担う場合が一般的です。

関連記事：アジャイル開発とは？メリット・デメリット、発注側の注意点を解説

【参考】システム開発会社の評価チェックリスト

発注者がシステム開発会社とやり取りするのはテスト工程だけではありません。そもそも、どのシステム開発会社に依頼するか検討・比較する際に役立つチェックリストを紹介します。上のような項目を比較し、最も自社に合いそうな開発会社を選ぶと良いです。開発会社を選ぶときは下記の記事も参考になりますので、ぜひご覧ください。

システム開発会社の選び方10ポイント｜依頼の準備と注意点も解説【2024年最新版】 | システム幹事 システムの新規開発、リニューアルを外注する会社の選び方を7つに絞って紹介します。開発会社の公式サイトの見方、開発会社に問い合わせたときの選定ポイントに分けて解説...

【無料】おすすめのシステム開発会社を紹介してもらう

システムテスト（総合テスト）まとめ

システムテストとは、開発したシステムがクライアントの要望通りに動作するかを検証するテストです。ユーザーが使う本番環境、もしくはそれを想定した環境にシステムを置き、実稼働と同様の負荷をかけて機能・パフォーマンスに問題がないかを確認します。

・単体テストの目的は、モジュール・プログラムが動作するか？不具合がないか？確認する
・結合テストの目的はサブシステムが動作するか？不具合がないか？確認する
・システムテストの目的は、「システムテスト仕様書」通りにシステムが動作するか？不具合がないか？機能要件や非機能要件を満たしているか？確認すること
・受け入れテストは、目的・ゴールを達成できるシステムが納品されたのか？後々のトラブルを避けて確実に検収するためのテスト

実際に発注側として作業に携わるのは受け入れテストだけですが、全体的なテスト工程を知っておくことで、テスト工程をスムーズに進められるでしょう。

関連記事：システム開発の検収トラブルを防ぐには？検収方法・契約内容・疑問を解説！

システム開発会社をお探しの方へ

現在、システム開発の外注をお考えの方はシステム幹事にご相談ください。

システム開発は会社によって得意・不得意が分かれることが多く、少ない情報から見極めるのは大変です。依頼をしようにも料金が書かれていないことが多く、どこの会社に問い合わせればいいのか迷っている方も多いでしょう。

少なくない時間と予算がかかるので、会社選びの失敗は絶対に避けたいところです。専門のコンサルタントがあなたの要望を丁寧にヒアリングし、予算にあった最適な開発会社を選びます。

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

業界の相場や開発会社の選び方などWebサイトには載っていない情報をご提供します。

必ず開発会社に発注する必要はありません。システム開発の相場の情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください。

【無料】おすすめのシステム開発会社を紹介してもらう