- 検証・テスト
システムテストとは｜結合テストとの違いと観点一覧
システムテスト（総合テスト）は、組み上がったシステム全体を、本番に近い環境で、要件定義で決めたとおりに動くかを確かめるテストです。 結合テストが「部品どうしがつながるか」を見るのに対し、システムテストは「業務として使えるか」と「性能や障害のときの動き（非機能）が決めたとおりか」を見ます。
| 結合テスト | システムテスト（総合テスト） | 受入テスト | |
|---|---|---|---|
| 確かめること | 画面・API・DB などの部品がつながって動くか | システム全体が要件どおりか（機能＋非機能） | 発注者・利用者が、業務に使えると判断できるか |
| もとにする文書 | 基本設計書・詳細設計書 | 要件定義書（機能要件・非機能要件） | 要件定義書・業務の手順 |
| 行う人 | 開発チーム | 開発チーム・テストチーム | 発注者・利用部門 |
| 環境 | 開発・テスト環境 | 本番に近い環境（構成・データ量） | 本番に近い環境・本番 |
| 単位 | 機能・画面のつながり | 業務の流れ（シナリオ） | 業務の流れ |
V字モデルでは、システムテストは「要件定義」と向かい合う工程です。 そのため、テストの観点は要件定義書から出します。設計とテストの対応は、関連記事「V字モデルとは？設計とテストの工程対応表とW字モデルとの違い」で扱っています。
確認日：2026年10月12日。品質特性は ISO/IEC 25010、非機能の観点は IPA「非機能要求グレード」の大項目を参照しています。観点一覧・基準の例は、システム開発のテスト工程で使われる考え方をもとにした整理です。
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
（記載例）出典：株式会社RJC「システムテストとは｜結合テストとの違いと観点一覧」
機能の観点一覧
機能の観点は「1つの画面が動くか」ではなく、「業務が最初から最後まで流れるか」で見ます。
| 観点 | 確かめること | 例（受注のシステム） |
|---|---|---|
| 業務シナリオ | 業務の流れが最初から最後まで通るか | 受注 → 在庫引当 → 出荷指示 → 請求 → 入金消込 |
| 業務のパターン | 例外の流れも通るか | キャンセル、返品、分納、取消後の再受注 |
| データの整合 | 画面・DB・帳票の数字が合うか | 受注の合計 ＝ 請求の合計 ＝ 売上集計 |
| 権限 | 役割ごとに、できること・できないことが分かれているか | 一般社員は承認できない、管理者は全社分を見られる |
| 帳票・CSV | 内容・レイアウト・改ページ・文字コード | 100行を超える請求書、全角文字を含む CSV |
| 外部連携 | 連携先とのやり取り、相手が止まったとき | 決済サービスの応答なし、ファイル連携の取り込み失敗 |
| バッチ | 夜間・月次の処理と、その結果を使う画面 | 月末の締め処理 → 翌月の画面に繰り越し残高 |
| 日付・期間 | 月末・年末・年度替わり・うるう年 | 3月31日の受注が新年度の集計に入らないか |
| 移行データ | 移行した既存データで動くか | 以前の形式のデータ・欠けた項目のある顧客 |
「データの整合」と「日付・期間」は、システムテストで特に意識したい観点です。 部品ごとのテストでは、別の機能が作ったデータを使う場面や、月をまたぐ処理を通しにくいからです。
非機能の観点一覧
非機能の観点は、要件定義の非機能要件で決めた値を、本番に近い環境で測って確かめます。 IPA の「非機能要求グレード」は、非機能要求を「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つの大項目に分けています。
| 大項目 | システムテストで確かめること | 例 |
|---|---|---|
| 可用性 | 障害が起きたときに、決めた時間で戻るか | サーバーを1台止めても業務が続く、バックアップから戻せる |
| 性能・拡張性 | 決めた応答時間・処理件数を満たすか | 画面の応答 3 秒以内（90%）、月次バッチが 2 時間以内に終わる |
| 運用・保守性 | 監視・ログ・ジョブの運用ができるか | エラーで監視に通知が届く、ジョブを再実行できる |
| 移行性 | 移行の手順と時間が計画どおりか | 本番相当のデータ量で、移行が決めた時間内に終わる |
| セキュリティ | 認証・権限・通信・ログが要件どおりか | パスワードの失敗でロック、操作ログが残る |
| システム環境 | 決めたブラウザ・端末・OS で動くか | 指定のブラウザの版で表示が崩れない |
| 種類 | 中身 |
|---|---|
| 性能テスト | 普段の件数で、応答時間を測る |
| 負荷テスト | 想定の最大の件数・同時アクセスで、応答時間とエラーを見る |
| 障害テスト | サーバー停止・ネットワーク断・ディスク満杯などを起こし、検知と復旧を確かめる |
| 運用テスト | 運用手順書どおりに、起動・停止・バックアップ・リカバリができるか |
性能・負荷テストのやり方は、関連記事「負荷テストの進め方とk6の使い方｜スクリプト例と結果の読み方」で、非機能要件の決め方は「非機能要件一覧｜IPA非機能要求グレード6大項目と定義書テンプレート」で扱っています。
ISO/IEC 25010 の品質特性で抜けを確かめる
観点の抜けを確かめるときは、ソフトウェア製品の品質の国際規格 ISO/IEC 25010 の品質特性と照らし合わせます。2011年版は次の8つで、2023年版では特性の数が9つになりました（Safety（安全性）が加わり、使用性は Interaction capability、移植性は Flexibility に名前が変わっています）。
| 品質特性（2011年版） | システムテストの観点の例 |
|---|---|
| 機能適合性 | 要件の機能がすべてあり、結果が正しいか |
| 性能効率性 | 応答時間・処理件数・資源の使い方 |
| 互換性 | ほかのシステム・ソフトと一緒に動くか |
| 使用性 | 操作が分かりやすいか、入力の誤りを防げるか |
| 信頼性 | 障害のときに続けられるか、戻せるか |
| セキュリティ | 認証・権限・改ざん防止・記録 |
| 保守性 | ログ・設定の変更のしやすさ |
| 移植性 | 環境が変わっても動くか（入れ替え・移行） |
開始基準と終了基準
システムテストを「いつ始めて、いつ終えるか」は、計画書で先に決めておきます。 決めておかないと、結合テストの不具合が残ったまま始まり、終わりの判断も人によって変わります。
| 基準の例 | |
|---|---|
| 開始基準 | 結合テストが終了基準を満たした／重大度「高」の不具合が残っていない／テスト環境・テストデータ・テスト仕様書がそろった |
| 終了基準 | 予定したテストケースを全件消化した／重大度「高」の不具合が0件、「中」は対応方針が決まっている／非機能要件の測定値が目標を満たした／不具合の見つかる数が落ち着いている |
不具合の見つかる数が落ち着いているかは、日ごとの「見つかった件数」と「直した件数」をグラフにして判断します。テスト計画書の項目は、関連記事「テスト計画書の書き方と項目一覧｜開始基準・終了基準のテンプレート」、進み具合の管理は「テスト進捗管理表テンプレート｜消化率の計算とバグ曲線の読み方」で扱っています。
シナリオテストの書き方（テンプレート）
システムテストのテストケースは、業務の流れ（シナリオ）を1件の単位にすると、何を確かめたかが関係者に伝わりやすくなります。
| 項目 | 記入例 |
|---|---|
| シナリオID | ST-ORD-003 |
| シナリオ名 | 分納の受注から、2回に分けた出荷・請求まで |
| 対応する要件 | REQ-012（分納）、REQ-020（請求） |
| 前提条件 | 商品Aの在庫 5 個、顧客 C001 は掛け売り |
| 手順 | ① 商品Aを 8 個受注 ② 在庫 5 個を引当・出荷 ③ 入荷 3 個 ④ 残り 3 個を出荷 ⑤ 月末締め |
| 期待結果 | 出荷は2回、請求書は1枚に2行、売上集計は 8 個分 |
| 確かめる場所 | 出荷画面、請求書（PDF）、売上集計の CSV |
「対応する要件」を必ず書くと、要件のうちテストしていないものが一覧で分かります。要件とテストの対応表は、関連記事「トレーサビリティマトリクスの作り方 要件・設計・テスト対応表」で扱っています。
環境とデータ
| 項目 | 気をつけること |
|---|---|
| 構成 | サーバーの台数・ネットワーク・外部連携先を、本番と同じ形にする（違いは一覧にしておく） |
| データ量 | 本番相当の件数で、検索・帳票・バッチの時間を測る |
| データの中身 | 個人情報は加工してから使う |
| 時刻 | 月末・年度替わりを試すため、システム日付を変えられるようにしておく |
テストデータの作り方と個人情報の加工は、関連記事「テストデータの作り方｜生成SQLとマスキング手法一覧・匿名化の手順」で扱っています。
よくある質問
Q. システムテストと総合テストは同じですか。 A. 同じ工程を指すことが多い呼び方です。会社やプロジェクトによって、「総合テスト」に受入テストの一部を含めるなど範囲が違うことがあるので、計画書で「何を確かめる工程か」を書いておきます。
Q. 結合テストで確かめたことを、もう一度やる必要がありますか。 A. 同じテストを繰り返すのではなく、観点を変えます。結合テストは「つながるか」、システムテストは「業務として通るか」「非機能が満たされるか」です。ただし、結合テストのあとに直した箇所は、リグレッションテストで確かめます。範囲の決め方は、関連記事「リグレッションテストの範囲の決め方｜影響範囲の調べ方」で扱っています。
Q. 受入テストとの線引きが分かりません。 A. システムテストは「作った側が、要件どおりかを確かめる」、受入テストは「使う側が、業務に使えると判断する」です。受入テストの観点は、関連記事「受入テストの観点チェックリストとUATシナリオの書き方」で扱っています。
Q. 自動化はできますか。 A. 業務シナリオのうち、毎回同じ手順で通すものは、画面の自動テスト（Playwright など）にできます。帳票の見た目や、障害を起こすテストは、手順書で手を動かして確かめることが多いテストです。
まとめ
- システムテストは、システム全体が要件どおりかを、本番に近い環境で確かめる工程
- 結合テストは「つながるか」、システムテストは 「業務として通るか」「非機能を満たすか」
- 機能は 業務シナリオ・データの整合・日付・権限・帳票・連携・バッチで見る
- 非機能は 非機能要求グレードの6大項目と ISO/IEC 25010 で抜けを確かめる
- 開始基準・終了基準を先に決め、テストケースには対応する要件を書く
参考・出典
確認日はいずれも 2026年10月12日です。
- ISO「ISO/IEC 25010:2023 Systems and software engineering — Product quality model」：https://www.iso.org/standard/78176.html
- arc42 Quality Model「ISO 25010 update 2023」：https://quality.arc42.org/articles/iso-25010-update-2023
- IPA「非機能要求グレード」セミナー資料（6つの大項目）：https://www.ipa.go.jp/files/000066192.pdf
- IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
（記載例）出典：株式会社RJC「システムテストとは｜結合テストとの違いと観点一覧」
株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。
WE ARE HIRING
RJCで一緒に開発しながら、
成長を楽しみませんか？
RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください！
- 127日年間休日
- 12時間平均残業時間
- 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ！
ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨（休暇 or 金一封）、11期連続の黒字決算。
