TOPICS

TOP

>

TOPICS

>

システム開発

システムテストの基礎知識|単体・結合・受入の流れと計画書の作り方

更新日: 2025年9月11日

03-65_システムテストの基礎知識|単体・結合・受入の流れと計画書の作り方

システム開発の最終段階では、システムテストを丁寧に進める必要があります。不具合を見逃すと運用開始後に重大なトラブルにつながる恐れがあります。結合テストや受け入れテストとの違いを理解し、計画書に盛り込むべき要素を把握することが重要です。

この記事では、テスト工程の流れや代表的な手法を整理し、実務に役立つ知識についてわかりやすく解説していきます。

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

システムテストは、完成したシステム全体を実際の利用環境に近い条件で検証する工程です。目的によって複数の種類があり、それぞれで役割が異なります。ここでは、結合テストや受け入れテストとの違いについて解説します。

総合テストと結合テストとの違い

結合テストはモジュールをつなげて正しく連携するかを確認する工程です。内部のつなぎ込みや外部システムとのやり取りが意図通りかを確かめます。一方、総合テストは完成したシステム全体を本番に近い環境で検証し、要件定義の通り動作するかを確認する段階です。

結合テストが設計通りの連携を検証するのに対し、総合テストは利用者の要件を満たしているかを広く確かめる点に違いがあります。

総合テストと受け入れテストの違い

受け入れテストは、発注者がシステムを受け入れる前に本番に近い環境で実施する試験です。実データを使い、業務と同じ流れで問題なく使えるかを確認します。総合テストも全体を検証する点では共通しますが、実施者は開発側です。

開発者が要件を満たしているかを確かめ、発注者が実際に使えるかを判断するのが受け入れテストであり、実施主体と目的が異なります。

システムテスト計画書の作り方

システムテスト計画書とは、テストの目的や進め方を事前に整理し、関係者で共有するための文書です。これがなければ工程が属人的になり、漏れや重複が発生しやすくなります。ここでは計画書に盛り込むべき基本要素について解説します。

テスト計画書の基本項目(雛形):

  • 目的/範囲
  • 前提・制約
  • 対象機能
  • 非機能要件(性能・可用性・セキュリティ等)
  • 進め方(方式・観点・優先度付け)
  • 入出力の定義(テスト設計書/ケース/手順/結果報告)
  • 体制と役割(レビュー・承認含む)
  • スケジュール(マイルストーン/クリティカルパス)
  • 環境(本番等価/テストデータ)
  • 欠陥管理(起票項目・重大度・SLA)
  • 入退場基準(Entry/Exit)
  • トレーサビリティ

テスト目的や範囲を明確化する

計画書ではまず、何を確認するためのテストなのかを決めていきましょう。性能を重視するのか、機能の正確性を優先するのかによって観点が変わります。また、対象となる範囲を整理することで、テストの抜け漏れを防ぎます。

曖昧なまま進めると、後戻りが発生しやすいため、最初に目的と範囲を明確にしておくことが重要です。

必要な環境・ツールとスケジュールを整理する

テストを実施する際には、環境や使用するツールをあらかじめ整えておくことが重要です。本番に近い条件を再現するのか、テスト専用のデータを用いるのかで準備内容が大きく変わります。また、いつどのテストを行うのかを工程ごとに整理しておけば、進捗管理がしやすくなります。

適切な環境でテストを進めるには、準備段階で設定や予定を明確にすることが重要です。

リスクや体制、成果物を定義する

システムテストでは、想定外の不具合や遅延といったリスクを事前に洗い出し、対応策を決めておく必要があります。さらに、誰がどの役割を担当するのかを明確にし、体制を共有することも重要です。

あわせて、テスト仕様書やテストケース、不具合報告書など、テスト工程で作成する資料も事前に決めておくと、関係者間でゴールを共有しやすくなります。

システムテストの代表的な種類

システムテストには、目的ごとにさまざまな種類があります。機能や性能だけでなく、利用環境やセキュリティ面まで幅広く確認することが重要です。ここでは、システムテストの種類とその特徴や目的について解説します。

機能テスト|要件通りの動作を確認

機能テストは、システムに実装した機能が設計通り正しく動くかを確認するテストです。

たとえば、ログイン機能や画面遷移、商品購入ボタンなどが想定通り動作するかを1つずつ検証します。未入力や最大文字数入力など、さまざまな条件を試す網羅的なテストも重要です。

実装した機能を全て確認することで、品質を保ち、ユーザーが安定して利用できる状態に仕上げられます。

性能テスト|応答速度や効率を検証

性能テストは、システムが想定通りの処理速度や効率を保てるかを確認するテストです。大量のデータを扱う操作や長時間の利用など、負荷が高い条件を想定して応答時間や処理能力を測定します。

実際の利用環境に近い条件で行うことが重要で、基準を誤るとレスポンスが遅くなりユーザーに不便を与える原因になります。必要に応じて条件を変えながら最適な性能を保てるかを検証します。

構成テスト|利用環境ごとの動作を確認

構成テストは、推奨される環境でシステムが問題なく動作するかを確認するテストです。サーバー環境やパソコンのOS、ブラウザの種類、スマートフォンの機種など、想定される利用環境を変えて検証します。

たとえば、異なるOSで画面表示が崩れないか、複数のブラウザで正常に操作できるかを確かめます。実際のユーザー環境に合わせて実施することで、利用者全体に安定した品質を提供できます。

耐障害テスト|復旧性を確認

耐障害テストは、システムに障害が発生したときでも、最低限の機能を維持し、復旧できるかを確認するテストです。サーバー障害や通信トラブルなど、想定される問題を再現し、復旧手順やデータ回復が適切に行えるかを検証します。

あらかじめ代替手順や業務再開の方法を決めている場合は、その方針通りに動作できるかも確認し、安定した運用を実現するための重要なテストです。

セキュリティテスト|脆弱性を検証

セキュリティテストは、システムが不正アクセスや情報漏えいの危険から守られているかを確認するテストです。クロスサイト・スクリプティングやSQLインジェクションなど、攻撃を想定した手法を用いて、脆弱性を洗い出します。

実際の運用環境を意識し、権限設定やデータ保護機能が仕様通りに動作するかを検証することで、安全で信頼性の高いシステムを実現できます。

シナリオテスト|業務フローを再現

シナリオテストは、実際の業務フローを想定した操作手順でシステムを利用し、滞りなく業務を遂行できるかを確認するテストです。業務シナリオを事前に作成し、その手順に沿って画面遷移や入力操作を行います。

複数の分岐条件や利用者の操作パターンを想定することで、現場での利用時に問題が起きないかを総合的に検証できます。

リグレッションテスト|変更影響を確認

リグレッションテストは、システムに修正や機能追加を行った際、他の機能に予期しない不具合が発生していないかを確認するテストです。「回帰テスト」や「退行テスト」とも呼ばれます。

たとえば、ログイン機能を改修したときに、会員登録やパスワード設定の動作に影響が出てないかを検証します。全てを網羅的に再テストするのは非現実的なため、影響範囲や重要度を考慮して優先順位をつけて実施するのが一般的です。

ユーザビリティテスト|使いやすさを検証

ユーザビリティテストは、ユーザーにとってシステムが使いやすいかどうかを確認するテストです。操作性や画面の見やすさ、案内のわかりやすさなどを検証し、実際の利用者視点で問題がないかをチェックします。たとえば、ボタンの位置や文言、操作手順が直感的に理解できるかを確かめることが重要です。

使いにくい箇所を見つけて改善することで、ユーザー満足度の向上やサービス品質の強化につながります。

システム開発テストの流れと進め方

システム開発では、テスト工程を順序立てて進めることが品質を確保する上で重要です。単体テストから始まり、総合テストへと段階的に進むことで不具合を早期に発見しやすくなります。ここでは各テスト工程の流れと進め方を解説します。

1.不具合を早期に洗い出す単体テスト

単体テストは、開発したモジュールを結合する前の段階で行います。ここで不具合を見つけられれば、後工程での手戻りを防ぎ、修正コストを抑えられるためです。設計書を基にテストケースを作成し、正常系だけでなく誤入力や例外パターンも網羅します。

実施時は結果を記録し、異常があれば原因を切り分けて開発者へ共有することが重要です。

2.モジュール連携を確認する結合テスト

結合テストは、単体テストを終えたモジュールを組み合わせる段階で行います。ここで連携不具合を見つけることで、システム全体への影響を最小限に抑えられます。テスト範囲を事前に明確に定義し、影響範囲の大きい部分から優先的に検証することが重要です。

結果をこまめに記録し、問題があれば原因を特定できるよう丁寧に作業を進めていきます。

3.要件通りに動作するか検証するシステムテスト

システムテストは、全ての機能を統合した状態で本番に近い環境を構築し、最終的な動作を確認する工程です。この段階で不具合を見つけると影響範囲が大きいため、結合テストでの結果を踏まえ、重要な機能から優先的に実行します。

テスト中は不具合を迅速に報告し、開発者と連携しながら修正と再検証を繰り返す体制が必要です。

4.実運用を想定して全体を確認する総合テスト

総合テストは、実際の業務フローを想定し、本番環境と同じ条件で行います。リリース前の最終工程にあたるため、操作手順やデータ処理、外部システム連携などを実シナリオに沿って1つずつ確認します。

結果を詳細に記録し、想定外の不具合を見逃さないよう関係者と情報を共有します。ここで動作に問題がなければリリース判断に進む流れです。

まとめ

システム開発では、テスト工程を正しい順序で進めることで品質を高められます。品質を安定させるには、各工程の進め方や管理法も常に見直し、改善を意識することが重要です。

しかし、現場では想定外の不具合やスケジュール遅延に直面することも多く、柔軟に対応できる体制を整えておく必要があります。

そのためには、作業を細かく分解し、進行状況を可視化できる仕組みが欠かせません。WBSの基本と作成方法をまとめた資料を参考に、効率的な管理体制を整えていきましょう。

>>作業漏れゼロ!プロジェクトを完全管理!WBS 基本と実践

WBS(Work Breakdown Structure)について、基本の解説と、作成方法を具体的にご紹介いたしました。

現場で使える内製アジャイル導入ノウハウをまとめた実践ガイド。小さく始めて大きく育てるための考え方や導入チェックリスト付きで、失敗を防ぎ成功へ導きます。