システムテスト(総合テスト)とは?その目的・観点・種類、実務で使える手順について解説

  • ソフトウェアテスト・品質保証

システムテスト(総合テスト)とは?その目的・観点・種類、実務で使える手順について解説

お役立ち資料

Introduction

システムテストは、システム構築後、すべての機能が揃った状態で、全体として予定通りの機能や性能を満たしているかどうかを検証するテストです。今回は、その目的・観点について、結合テストや受け入れテストとの違いを踏まえて説明します。また、システムテストの流れ・手順や必要なテストの種類について、テスト実務に役立つ情報をお送りします。

目次

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

システムテスト(ST:System Testing)は、「総合テスト」とも呼ばれており、要件定義で作成した要件の内容に沿っているかを確認するテストのことです。システムテストは結合テストの後工程で行われ、すべての機能が揃った状態でハードウェアや通信回線なども含め、ソフトウェアのシステム要件に準拠しているか、機能間の連携は取れているか、運用や保守が実現可能であるかなどを評価する目的で行われます。独立行政法人 情報処理推進機構(IPA)の定義では、「システム適格性確認テスト」とされています。

V字モデルの図

システムテスト(総合テスト)の観点

システムテストの観点は、要件定義書に記述されている内容に沿っているかということになります。具体的には機能要件と、機能以外(利用や使用、性能や拡張、運用や保守、移行、セキュリティ、エコロジー)の非機能要件に対して、動作や振る舞いが合っているかを確認します。

非機能要件①「可用性」

システムやサービスなどを利用者が継続的または必要なときに使うことができるかを確認する。また、保守によるメンテナンスや障害による利用停止時間、復旧方法や復旧にかかる時間なども確認する。

非機能要件②「性能・拡張性」

システムの処理速度やデータ量などのパフォーマンス、ピーク時や縮退時の処理能力などを確認する。また、将来のシステム拡張、システムの機能追加や性能向上に対し、対応のし易さなどを確認する。

非機能要件③「運用・保守性」

システムの納品後、運用や保守を行うなかでバッチ処理やバックアップなどにかかる時間などを確認する。また、運用監視やシステム切替(BCP:事業継続計画)の観点でも確認する。

非機能要件④「移行性」

現システムに関わる移行期間や移行方法、資産管理、データの種類や量などを確認する。

非機能要件⑤「セキュリティ」

不正利用や不正アクセスなどのセキュリティ診断や、認証や利用制限などを確認する。また、不正監視(監視・検知・追跡・ログ)などを確認する。

非機能要件⑥「システム環境・エコロジー」

システムの設置環境の耐震や免震、温度や湿度、スペース、電圧などを確認する。

システムテスト(総合テスト)と結合テストの違い

結合テスト(IT:Integration Testing)とは、「連結テスト」、「統合テスト」とも呼ばれており、単体テストの後工程で行われるテストのことです。各部品(モジュール)を複数組み合わせた場合に、接点(インターフェース)が意図通りに動作するかを確認する内部結合テスト(ITa:Integration Test A)と、外部システムなどの接点やデータ連携が意図通りに動作するかを確認する外部結合テスト(ITb:Integration Test B)があります。IPAの定義では、「ソフトウェア適格性確認テスト」とされています。前述の通り、システムテストが、要件定義の内容に沿っているかを確認するのに対し、結合テストでは基本設計書の内容に沿っているかを確認することになります。テスト環境に関しても、システムテストがハードウェアや通信回線なども含め本番同様の環境で行うのに対し、結合テストでは開発環境にてテストデータを使用します。

システムテスト(総合テスト)と受け入れテストの違い

受け入れテスト(UAT:User Acceptance Test)とは、「検収試験(AT:Acceptance Test)」とも呼ばれており、要求分析で作成した要求仕様書の内容に沿っているかを確認します。システムテスト同様にシステム全体として意図通りに機能するかを確認しますが、より実運用に近いテストを行うため、システムテストに合格したものを実際に業務で使用する環境におき、実データを用いて実際の業務と同じ操作でテストを行います。一般的にシステム発注元(ユーザー)が完成したシステムを受け入れるかどうかのテストですが、元請ベンダーが外部ベンダーに開発を委託したシステムを確認するテストに対して用いることも多いです。

ソフトウェアテスト入門講座

※ご登録いただくとその場で無料動画の視聴が可能です。
株式会社SHIFTが運営するソフトウェアテスト・品質保証の人材育成を手掛けるヒンシツ大学のお試し講座「ソフトウェアテスト入門」をご視聴いただけます。ソフトウェアテストの目的、役割といった基礎知識を学びたい方におすすめの入門動画です。

※ご登録いただくとその場で無料動画の視聴が可能です。
株式会社SHIFTが運営するソフトウェアテスト・品質保証の人材育成を手掛けるヒンシツ大学のお試し講座「ソフトウェアテスト入門」をご視聴いただけます。ソフトウェアテストの目的、役割といった基礎知識を学びたい方におすすめの入門動画です。

ダウンロード

システムテスト(総合テスト)の流れ

ソフトウェアの開発におけるテストの流れは、「テスト計画」、「テスト設計」、「テスト準備(環境・データ)」、「テスト実行」、「テスト実行進捗管理」、「テスト完了」のプロセスから構成され、開発の設計・実装工程と並行して行います。その流れはシステムテストも同様です。テスト計画ではテストにおける全体の概要と目的やテストのスコープ(対象範囲や影響範囲)、観点、環境、および体制(役割)、スケジュールを記載するとともにテストにおける合格基準をまとめます。テスト計画が決まれば、次に実際のテストで確認するテストケースを設計していき、その後、テスト環境とテストデータを準備していきます。準備が整い次第、テスト実行者はテスト設計を確認しながら各テストケースを実行していき、確認すべき項目と異なる結果を確認した場合には、不具合が発生した際のフローに従い不具合を起票します。このような一連の流れを経て不具合およびテストケースが完了した後、テスト合格基準とともに終了報告を行いテストは完了となります。

テストの流れの図

テスト計画

何をテストするのか、どのような種類のテストをするのかを決める。
テスト方針の立案
テスト基準の決定
要員・体制の決定
スケジュールの決定
テスト環境・ツールの決定
各種管理基準の設定

テスト準備(環境・データ)

テストで確認したいことを具体的に詰め、テストケースを作成する。
テストケースの作成
テスト仕様書の作成
テスト手順書の作成

テスト実行

テスト実行準備で用意したものを基にテストを実行する。
テストケース実行
問題点切り分け
原因追及

テスト実行進捗管理

テスト実行の進捗を基にプロジェクトの方向性を判断する情報を提供する。
不具合管理
進捗管理
変更管理
障害収束(の見極め)

テスト完了

テスト実行の終了を報告する。
テスト分析
テスト終了報告書の作成

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

テスト計画はシステムテスト上で、適切なテストを行い、品質を担保するために非常に重要です。その内容をテスト計画書にまとめる際は、仕様変更のタイミングや優先すべき仕様などについて確認し、ゴールや対象範囲、体制などを決めることで、工数やコストの削減、スケジュールの短縮を図ることができます。

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

テストの概要と目的、テストのスコープ、観点

記述内容②「要員・体制」

各要員の役割や体制図

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

各工程のスケジュール

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

テスト環境のほか、テスト端末、ツールなど

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

不具合管理や進捗管理の基準、手法

システムテスト(総合テスト)の種類

システムテストでは、機能要件と非機能要件に沿ったテストが必要となるため、主に以下の種類のテストからプロジェクトの特性に応じて選択し行うことになります。

①「機能テスト」

システムの機能要件に基づき、本番環境と同等の状態でシステム要件を満たしていることを確認するテスト。機能要件通りにシステムが動作すること、追加修正した機能およびその他現行機能が満たされていることを確認する。

②構成テスト(機種テスト)

システムが推奨している環境設定(LAN環境、サーバー環境、PCのOS・ブラウザ、および、携帯、スマートフォンの種類)において、画面表示や基本動作が問題なく実施できることを確認する。

③リグレッションテスト(回帰テスト、退行テスト)

プログラムの追加・変更・削除などにより、システムの未変更部分に新たな欠陥(「リグレッション」「デグレード」などと呼ぶ)が入り込んだり発現したりしないことを確認するためのテスト。未変更部分に変更や問題がないことを確認する。実際には、変更の度に全コンポーネントに対してテストを行うことは現実的でないため、影響がおよぼされる可能性のある範囲や重要度の高い範囲を優先して実施されることがある。

④シナリオテスト

業務を想定したシナリオに基づいて実施するテスト。業務フローに則ったテストシナリオを作成し、業務が滞りなく行えるか確認する。

⑤性能テスト

テスト対象に対して繰り返し長時間、要求された処理を行った場合に、正しく動作することを確認するテスト。

⑥ロングランテスト

性能要件を充足していることを確認するテスト。

<単体性能>

単画面、単バッチの性能を確認する。

<負荷テスト>

システムに平時の負荷を与えた場合において、正しい動作を行うことを確認する。

<高負荷テスト>

システムに高負荷を与えた場合(大容量データや多数のデータを与えた場合、一定時間内に多数の処理を行う場合など)に、正しい動作を行うことを確認する。また、更なる高負荷を与え、メモリやサーバーなどの可用性が低減した場合においても、正しい動作を行うことを確認する。

⑦ユーザビリティテスト

追加修正した機能が理解しやすく、使いやすいものになっているか、視認性や操作性、統一性を確認する。

⑧耐障害テスト

保守要件(異常個所の早期検出能力、トラブル発生時の解決時間の短さ、調査資料の十分性など)を充足していることを確認するテスト。障害が発生した場合においても実行レベルを維持できること、障害発生後に実行レベル再確立やデータ回復ができることを確認する。また、コンティンジェンシープランや代替業務を定めている場合は、定めた方針や手順通りに業務再開ができることを確認する。

⑨セキュリティテスト

信頼や安全、保全要件を充足していることを確認するテスト。

<クロスサイト・スクリプティング(XSS)>

サイト間を横断して悪意のあるスクリプトを混入させ、不正な動作をさせたりデータを盗んだりできるかを確認する。

<SQLインジェクション>

アプリケーションのユーザ入力領域からSQL文を混入させ、データを盗んだりデータを削除できるかを確認する。

関連サービスについて

機能要件テストの技法

機能要件を確認するテストは、コンポーネントテストや結合テストと同様にブラックボックステスト技法を用いて実施します。

技法①「同値分割法」

同値分割法は、同値領域から代表値を抽出し、実行するテストケ-スを設計するもので、少ないテスト回数で広い範囲の検証をカバーする方法です。同様の結果となる値をそれぞれ「同値クラス」として分類し、クラスごとに代表値をテストします。代表値の結果が、同じクラスの他の値にも同様の結果をもたらすという考え方です。

技法②「境界値分析」

境界値とは、同値分割した同値クラスの両端にあたる値のことで、この境界値をもとにテストを実施する技法を境界値分析といいます。例えば、「以上」「未満」などが境界値にあたり、境界付近の値は間違いが起こりやすいため、この境界値に焦点を当ててテストを行うことで、効率的に不具合を確認することができます。

技法③「デシジョンテーブルテスト」

デシジョンテーブルとは、対象が取り得るステータスや動作・入力値といった条件を組み合わせ、それぞれがどのような結果を得られるかを表にまとめたものです。このデシジョンテーブルを活用して行うテスト技法をデシジョンテーブルテストと呼びます。
条件が多数存在し、その条件によって結果が変わるシステムの場合は、条件と結果の複雑な組み合わせを捉えることが難しくなりますが、このデシジョンテーブルを用いることで条件と結果を整理し、網羅的にテストを行うことが可能となります。

技法④「状態遷移テスト」

状態遷移テストとは、システムの状態があらゆる条件によって変化する様子を図で表した状態遷移図と状態と状態が遷移する条件を表でまとめた状態遷移表を用いて行うテストのことです。

状態遷移図:丸や四角といった図形や矢印を用いて表現されるため、ビジュアルで状態遷移を捉えることができます。
状態遷移表:表の縦軸に状態、横軸に状態が遷移する条件を用い、その組み合わせの結果(状態)をマトリクスでまとめたものです。状態と条件の組み合わせを網羅的に捉えることができます。

このような状態遷移図や状態遷移表をもとに、状態遷移が正しく行われているかどうかを確認するテスト技法を、状態遷移テストといいます。

技法⑤「ユースケーステスト」

ユースケーステストとは、アクター(ユーザー)がシステムに期待する目的を達成するまでの操作手順などの流れをまとめたユースケースを使用したテストです。ユースケースは、ユースケースドキュメントやユースケース図で表現され、これらをもとにテストケースを設計していきます。

技法⑥「組み合わせテスト」

組み合わせテストとは、ある入力条件(因子)と値(水準)を組み合わせて行うテストです。
ただし、すべての組み合わせをテストしようとすると膨大な数となり、実施することが非現実的なケースがあります。そのため、オールペア法(n因子間網羅)や直交法などテストケースの削減手法を活用し、大幅にケース数を減らしてテストを実施することが一般的です。

まとめ

・システムテストは、システム全体としてシステム要件に準拠しているかを確認するテストのこと。

・システムテストの観点としては、要件定義で作成した要件定義書の内容に沿っているかであり、機能要件と非機能要件に対して、動作や振る舞いが合っているかを確認する必要があること。

・システムテストは、「テスト計画」、「テスト設計」、「テスト準備(環境・データ)」、「テスト実行」、「テスト実行進捗管理」、「テスト完了」のプロセスから構成されていること。

・システムテスト計画書には、「テスト方針」、「テスト基準」、「要員・体制」、「スケジュール」、「テスト環境・ツール」、「各種管理規定」などを記述し、当該計画に沿ってテストを行い、品質を担保すること。

資料ダウンロード/動画視聴

関連コラム

Top
緊急アイコン

緊急対応が必要な方

お客様からクレームが発生している、不具合が頻発しているなど、緊急で対策が必要な方はすぐにご連絡ください。

TEL 0120-142-117

受付時間 平日9:00 - 18:00

TEL 03-6809-2979

フリーダイヤルをご利用できない場合は、
上記電話番号におかけください。