お役立ち資料
目次
IT化が急速に進む中で、システムの需要は急激に増えています。システムをリリースするためには事前にテストを行い、予定していた機能や性能を搭載できているかを確認しなければなりません。「システムテスト」はそのテストのひとつで「総合テスト」とも呼ばれています。システム構築後、すべての機能が揃った状態で、全体として予定通りの機能や性能を満たしているかどうかを検証するテストです。システムテストは、可用性・性能・運用・セキュリティなど多様な観点で実施されるものであり、それぞれの特性に応じてさまざまな種類のテストを使い分ける必要があります。
本記事では、システムテストの概要や結合テストとの違い、システムテスト計画書の書き方や技法について解説します。
株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
システムテスト（総合テスト）とは？
システムテスト（ST：System Testing）は、「総合テスト」とも呼ばれており、要件定義で作成した要件の内容に沿っているかを確認するテストのことです。
システムテストは結合テストの後工程で行われます。すべての機能が揃った状態で以下の目的で評価します。
・ハードウェアや通信回線なども含め、ソフトウェアのシステム要件に準拠しているか
・機能間の連携は取れているか
・運用や保守が実現可能であるか など
独立行政法人 情報処理推進機構（IPA）の定義では、「システム適格性確認テスト」とされています。
システムテスト（総合テスト）と結合テストの違い
結合テスト（IT：Integration Testing）とは、「連結テスト」、「統合テスト」とも呼ばれており、単体テストの後工程で行われるテストのことです。
各部品（モジュール）を複数組み合わせた場合に、次の2つのテストを実施します。
・内部結合テスト（ITa：Integration Test A）
接点（インターフェース）が意図通りに動作するかを確認する
・外部結合テスト（ITb：Integration Test B）
外部システムなどの接点やデータ連携が意図通りに動作するかを確認する
IPAの定義では、「ソフトウェア適格性確認テスト」とされています。
前述の通り、システムテストが要件定義の内容に沿っているかを確認するのに対し、結合テストでは基本設計書の内容に沿っているかを確認します。
テスト環境に関しても、システムテストがハードウェアや通信回線なども含め本番同様の環境で行うのに対し、結合テストでは開発環境にてテストデータを使用します。
システムテスト（総合テスト）と受け入れテストの違い
受け入れテスト（UAT：User Acceptance Test）とは、「検収試験（AT：Acceptance Test）」とも呼ばれており、要求分析で作成した要求仕様書の内容に沿っているかを確認します。
システムテスト同様にシステム全体として意図通りに機能するかを確認します。より実運用に近いテストを行うため、システムテストに合格したものを実際に業務で使用する環境におき、実データを用いて実際の業務と同じ操作でテストを行います。
一般的にシステム発注元（ユーザー）が完成したシステムを受け入れるかどうかのテストですが、元請ベンダーが外部ベンダーに開発を委託したシステムを確認するテストに対して用いることもあります。
システムテストは、要件通りの機能と性能を有しているかを開発者がチェックするテストなのに対し、受け入れテストは本番環境で問題なく機能するかを発注者がチェックするものです。テストの実施者に違いがあることを覚えておきましょう。
システムテスト（総合テスト）の観点
システムテストの観点は、要件定義書に記述されている内容に沿っているかということです。
具体的には機能要件と、機能以外（利用や使用、性能や拡張、運用や保守、移行、セキュリティ、エコロジー）の非機能要件に対して、動作や振る舞いが合っているかを確認します。
非機能要件①「可用性」
システムやサービスなどを利用者が継続的または必要なときに使うことができるかを確認します。また、保守によるメンテナンスや障害による利用停止時間、復旧方法や復旧にかかる時間なども確認します。
非機能要件②「性能・拡張性」
システムの処理速度やデータ量などのパフォーマンス、ピーク時や縮退時の処理能力などを確認します。また、将来のシステム拡張、システムの機能追加や性能向上に対し、対応のし易さなどを確認します。
非機能要件③「運用・保守性」
システムの納品後、運用や保守を行うなかでバッチ処理やバックアップなどにかかる時間などを確認します。また、運用監視やシステム切替（BCP：事業継続計画）の観点でも確認します。
非機能要件④「移行性」
現システムに関わる移行期間や移行方法、資産管理、データの種類や量などを確認します。
非機能要件⑤「セキュリティ」
不正利用や不正アクセスなどのセキュリティ診断や、認証や利用制限などを確認します。また、不正監視（監視・検知・追跡・ログ）などを確認します。
非機能要件⑥「システム環境・エコロジー」
システムの設置環境の耐震や免震、温度や湿度、スペース、電圧などを確認します。
システムテスト（総合テスト）の流れ
システムの開発におけるテストの流れは、「テスト計画」、「テスト設計」、「テスト準備（環境・データ）」、「テスト実行」、「テスト実行進捗管理」、「テスト完了」のプロセスから構成され、開発の設計・実装工程と並行して行います。
1. テスト計画
2. テスト準備（環境・データ）
3. テスト実行
4. テスト実行進捗管理
5. テスト完了
その流れはシステムテストも同様です。テスト計画ではテストにおける全体の概要と目的やテストのスコープ（対象範囲や影響範囲）、観点、環境、および体制（役割）、スケジュールを記載するとともにテストにおける合格基準をまとめます。
テスト計画が決まれば、次に実際のテストで確認するテストケースを設計していき、その後、テスト環境とテストデータを準備していきます。
準備が整い次第、テスト実行者はテスト設計を確認しながら各テストケースを実行します。確認すべき項目と異なる結果を確認した場合には、不具合が発生した際のフローに従い不具合を起票します。
このような一連の流れを経て不具合およびテストケースが完了した後、テスト合格基準とともに終了報告を行いテストは完了です。
①テスト計画
- 何をテストするのか、どのような種類のテストをするのかを決定します。
- テスト方針の立案
- テスト基準の決定
- 要員・体制の決定
- スケジュールの決定
- テスト環境・ツールの決定
- 各種管理基準の設定
最初にテスト計画を作成します。テスト計画では、何をテストするのか、どのような種類のテストをするのかといったテストの方針を決め、それに従って要因や体制、スケジュール、管理方法などを検討します。これらをシステムテスト計画書としてまとめていきます。
②テスト準備(環境・データ)
- テストで確認したいことを具体的に詰め、テストケースを作成します。
- テストケースの作成
- テスト仕様書の作成
- テスト手順書の作成
上記3つを、システムテスト計画に基づいて作成し、テスト実行に必要な一連の準備を行います。テストケースや手順の作成などシステムテスト計画をさらに具体化していきます。テストデータの準備やテスト環境の構築などもあわせて行います。
③テスト実行
- テスト実行準備で用意したものを基にテストを実行します。
- テストケース実行
- 問題点切り分け
- 原因追及
作成したテストケース・テスト仕様書・テスト手順書に従ってテストを実施する工程です。テストにおいて不具合を発見した場合、その原因を突き止めて開発者が改修に取り掛かれるようにまとめていきます。
④テスト実行進捗管理
- テスト実行の進捗を基にプロジェクトの方向性を判断する情報を提供します。
- 不具合管理
- 進捗管理
- 変更管理
- 障害収束（の見極め）
テスト実行の進捗状況や、発見された不具合、それに対する修正や変更点などをまとめ、関係者に情報共有を行います。これらの情報にもとづいて不具合改修やリリース可否の判断など、プロジェクトの方向性が検討されます。
⑤テスト完了
- テスト実行の終了を報告します。
- テスト分析
- テスト終了報告書の作成
テストが完了したらテスト分析を行い、テスト実行の結果や不具合の改修状況、改善案といった内容をテスト終了報告書としてまとめ、終了報告を行います。ここで報告された内容は、今後の追加開発やほかのプロジェクトの品質向上などで活用されます。
システムテスト計画書の書き方
テスト計画はシステムテスト上で、適切なテストを行い、品質を担保するために非常に重要です。
その内容をテスト計画書にまとめる際は、仕様変更のタイミングや優先すべき仕様などについて確認し、ゴールや対象範囲、体制などを決めることで、工数やコストの削減、スケジュールの短縮を図ることができます。
記述内容①「テスト方針」
テストの概要と目的、テストのスコープ、観点
記述内容②「要員・体制」
各要員の役割や体制図
記述内容③「スケジュール」
各工程のスケジュール
記述内容④「テスト環境・ツール」
テスト環境のほか、テスト端末、ツールなど
記述内容⑤「各種管理規定」
不具合管理や進捗管理の基準、手法
システムテスト（総合テスト）の種類
システムテストでは、機能要件と非機能要件に沿ったテストが必要となるため、主に以下の種類のテストからプロジェクトの特性に応じて選択し行うことになります。
・機能テスト
・構成テスト（機種テスト）
・リグレッションテスト（回帰テスト、退行テスト）
・シナリオテスト
・性能テスト
・ロングランテスト
・ユーザビリティテスト
・耐障害テスト
・セキュリティテスト
機能テスト
システムの機能要件に基づき、本番環境と同等の状態でシステム要件を満たしていることを確認するテストです。機能要件通りにシステムが動作すること、追加修正した機能およびその他現行機能が満たされていることを確認します。
構成テスト（機種テスト）
システムが推奨している環境設定（LAN環境、サーバー環境、PCのOS・ブラウザ、および、携帯、スマートフォンの種類）において、画面表示や基本動作が問題なく実施できることを確認するテストです。
リグレッションテスト（回帰テスト、退行テスト）
プログラムの追加・変更・削除などにより、システムの未変更部分に新たな欠陥（「リグレッション」「デグレード」などと呼ぶ）が入り込んだり発現したりしないことを確認するためのテストです。未変更部分に変更や問題がないことを確認します。
実際には、変更の度に全コンポーネントに対してテストを行うことは現実的ではありません。影響がおよぼされる可能性のある範囲や重要度の高い範囲を優先して実施されることが一般的です。
リグレッションテストについてはこちらもご覧ください。
＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説のページへ
シナリオテスト
業務を想定したシナリオに基づいて実施するテストです。業務フローに則ったテストシナリオを作成し、業務が滞りなく行えるか確認します。
シナリオテストについてはこちらもご覧ください。
＞＞シナリオテストとは？業務をどうやって分解していくの？のページへ
性能テスト
テスト対象に対して繰り返し長時間、要求された処理を行った場合に、正しく動作することを確認するテストです。
ロングランテスト
性能要件を充足していることを確認するテストです。
＜単体性能＞
単画面、単バッチの性能を確認します。
＜負荷テスト＞
システムに平時の負荷を与えた場合において、正しい動作を行うことを確認します。
負荷テストについてはこちらもご覧ください。
＞＞負荷テストとは？目的や種類ごとの観点、実施の流れについて解説のページへ
＜高負荷テスト＞
システムに高負荷を与えた場合（大容量データや多数のデータを与えた場合、一定時間内に多数の処理を行う場合など）に、正しい動作を行うことを確認します。
また、更なる高負荷を与え、メモリやサーバーなどの可用性が低減した場合においても、正しい動作を行うことを確認します。
ユーザビリティテスト
追加修正した機能が理解しやすく、使いやすいものになっているか、視認性や操作性、統一性を確認するテストです。
ユーザビリティテストについてはこちらもご覧ください。
＞＞ユーザビリティテスト（ユーザビリティ評価）とは？基礎知識や具体的な方法まで解説のページへ
耐障害テスト
保守要件（異常個所の早期検出能力、トラブル発生時の解決時間の短さ、調査資料の十分性など）を充足していることを確認するテストです。
障害が発生した場合においても実行レベルを維持できること、障害発生後に実行レベル再確立やデータ回復ができることを確認します。
また、コンティンジェンシープランや代替業務を定めている場合は、定めた方針や手順通りに業務再開ができることを確認します。
セキュリティテスト
信頼や安全、保全要件を充足していることを確認するテストです。
＜クロスサイトスクリプティング（XSS）＞
サイト間を横断して悪意のあるスクリプトを混入させ、不正な動作をさせたりデータを盗んだりできるかを確認します。
クロスサイトスクリプティングについてはこちらもご覧ください。
＞＞クロスサイトスクリプティング（XSS）とは？手口や被害事例、対策をわかりやすく解説のページへ
＜SQLインジェクション＞
アプリケーションのユーザー入力領域からSQL文を混入させ、データを盗んだりデータを削除できたりするかを確認します。
SQLインジェクションについてはこちらもご覧ください。
＞＞SQLインジェクションとは？手口や被害事例、対策をわかりやすく解説のページへ
関連サービスについて
機能要件テストの技法
機能要件を確認するテストは、コンポーネントテストや結合テストと同様にブラックボックステスト技法を用いて実施します。
・同値分割法
・境界値分析
・デシジョンテーブルテスト
・状態遷移テスト
・ユースケーステスト
・組み合わせテスト
技法①「同値分割法」
同値分割法は、同値領域から代表値を抽出し、実行するテストケースを設計するもので、少ないテスト回数で広い範囲の検証をカバーする方法です。
同様の結果となる値をそれぞれ「同値クラス」として分類し、クラスごとに代表値をテストします。代表値の結果が、同じクラスのほかの値にも同様の結果をもたらすという考え方です。
技法②「境界値分析」
境界値とは、同値分割した同値クラスの両端にあたる値のことです。この境界値をもとにテストを実施する技法を境界値分析といいます。
例えば、「以上」「未満」などが境界値にあたり、境界付近の値は間違いが起こりやすい傾向にあります。この境界値に焦点を当ててテストを行うことで、効率的に不具合を確認することができるのです。
技法③「デシジョンテーブルテスト」
デシジョンテーブルとは、対象が取り得るステータスや動作・入力値といった条件を組み合わせ、それぞれがどのような結果を得られるかを表にまとめたものです。このデシジョンテーブルを活用して行うテスト技法をデシジョンテーブルテストと呼びます。
条件が多数存在し、その条件によって結果が変わるシステムの場合は、条件と結果の複雑な組み合わせを捉えることが難しくなります。しかし、このデシジョンテーブルを用いることで条件と結果を整理し、網羅的にテストを行うことが可能となります。
技法④「状態遷移テスト」
状態遷移テストとは、システムの状態があらゆる条件によって変化する様子を図で表した状態遷移図と状態と状態が遷移する条件を表でまとめた状態遷移表を用いて行うテストのことです。
・状態遷移図
丸や四角といった図形や矢印を用いて表現されるため、ビジュアルで状態遷移を捉えることができる。
・状態遷移表
表の縦軸に状態、横軸に状態が遷移する条件を用い、その組み合わせの結果（状態）をマトリクスでまとめたもの。状態と条件の組み合わせを網羅的に捉えることができる。
このような状態遷移図や状態遷移表をもとに、状態遷移が正しく行われているかどうかを確認するテスト技法を、状態遷移テストといいます。
技法⑤「ユースケーステスト」
ユースケーステストとは、アクター（ユーザー）がシステムに期待する目的を達成するまでの操作手順などの流れをまとめたユースケースを使用したテストです。
ユースケースは、ユースケースドキュメントやユースケース図で表現され、これらをもとにテストケースを設計していきます。
技法⑥「組み合わせテスト」
組み合わせテストとは、ある入力条件（因子）と値（水準）を組み合わせて行うテストです。ただし、すべての組み合わせをテストしようとすると膨大な数となり、実施することが非現実的なケースがあります。
そのため、オールペア法（n因子間網羅）や直交法などテストケースの削減手法を活用し、大幅にケース数を減らしてテストを実施することが一般的です。
システムテストならSHIFTへご相談を
システムテストは、完成したシステムが要件を満たした機能・性能を有しているかを確認するテストです。ひと口にテストといっても多くの種類が存在しており、プロジェクトの特性に応じて選択する必要があります。開発したシステムに適した方法でシステムテストを行い、品質を担保できるようにしましょう。
SHIFTでは、開発プロジェクトの上流工程から下流工程まで、一気通貫で対応いたします。部分的なご依頼・ご依頼も可能です。
システム開発にお悩みをおもちの方は、ぜひSHIFTへご相談ください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
監修
永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数
――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――
この記事を書いた人
ご支援業種
- 製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント
など多数
関連コラム
-
- ソフトウェアテスト・品質保証
QAエンジニアとは？テストエンジニアとの違いや業務、必要なスキル・資格を解説
2024.04.10
詳しく見る
-
- ソフトウェアテスト・品質保証
ソフトウェアテストを効率化するには？テスト設計・テスト実行それぞれの方法を解説
2024.02.29
詳しく見る
-
- ソフトウェアテスト・品質保証
ソフトウェアテストの7原則とは？正確なテストを行うために必要な考え方も解説
2024.02.22
詳しく見る
-
- ソフトウェアテスト・品質保証
ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説
2024.02.05
詳しく見る
-
- ソフトウェアテスト・品質保証
負荷テストとは？目的や種類ごとの観点、実施の流れについて解説
2024.01.23
詳しく見る
-
- ソフトウェアテスト・品質保証
品質保証（QA）とは？品質管理との違いや具体的な業務内容について解説
2024.01.22
詳しく見る
-
- ソフトウェアテスト・品質保証
SREとは？意味やDevOpsとの違い、実現できることを解説
2024.01.16
詳しく見る
-
- ソフトウェアテスト・品質保証
PMOとは？PMとの違いや職種別の役割・業務内容について解説します
2024.01.12
詳しく見る
-
- ソフトウェアテスト・品質保証
DevOpsとは？アジャイル開発との違い、導入するメリット・デメリットについて解説
2024.01.12
詳しく見る
-
- ソフトウェアテスト・品質保証
verificationとvalidationの違いとは？ソフトウェア開発における意味・定義を解説
2024.01.12
詳しく見る
