システムテスト（総合テスト）とは？ 検証内容、種類、手順、技法を紹介

更新：2024.3.26
著者：Ｓｋｙ株式会社

ソフトウェア開発の評価 / 検証で行うシステムテストのご紹介します。具体的にどのような内容を検証するのか、テストの種類や手順も紹介します。

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

システムテストとは、システムの構築が完了し、すべての機能が整った後に、実際の使用状況を想定した環境で実行するテストです。
開発したシステムやソフトウェアがリリース後に不具合やトラブルが起きないよう、さまざまな観点で評価 / 検証します。
開発環境では見つけられなかった不具合が、システムテストによって発覚するケースもあります。全体的なチェックを行うことから、「総合テスト」とも呼ばれます。

システムテスト（総合テスト）と結合テストの違い

開発の最終工程で行われるシステムテストのほかに、開発途中の段階での評価 / 検証として「単体テスト」や「結合テスト」があります。システムを構成する各モジュールを個別に検証するのが単体テスト、それらを結合した時点で行うのが結合テストです。

IPA（独立行政法人情報処理推進機構）では、システムテストを「システム適格性確認テスト」、結合テストを「ソフトウェア適格性確認テスト」と定義しています。システムテストと結合テストの大きな違いの一つとして、前者はクライアントの要件・要望（要件定義）から逸脱していないかを確認するのに対し、後者は基本設計書の内容に則しているかを検証するという違いがあります。

結合テストの内容には、次の2種類があります。

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

受け入れテストとは、開発を依頼した発注元（ユーザー）が、そのシステムを受け入れるかを判断するためのものです。英語では「UAT（User Acceptance Test）」と表記され、「検収試験」と呼ばれることもあります。システムやソフトウェアが実際に使用されるのと同様の環境で、実際の業務と同じ流れでテストを行い、要求どおりの成果物として問題ないかを確認します。

システム全体が要望にかなっているか確かめるという点では、システムテストに似ていますが、受け入れテストはより本番に近い条件で行われます。発注者による納品前の最終チェックが受け入れテストであり、その最終チェックに回しても問題がない品質になっているかどうかを開発側が確かめるのがシステムテストです。

そのため基本的には、システムテストは開発側、受け入れテストは発注者側で計画からテスト実行までを進めるのが理想的とされています。とはいえ、不具合などの問題が存在するのであればそれを発見できなければ意味がないため、作業工数や精度などを考慮して、専門技術を持つ外部業者に委託されるケースもあります。

システムテスト（総合テスト）の確認観点

システムテストで、どういった観点から検証を進めていくのかを決定する際、重要な資料となるのが「要件定義書」です。要件定義は、クライアントが求める機能が実装されているかに関わる「機能要件」と、それ以外を指す「非機能要件」に分けられます。

機能面以外の品質全般に関わる非機能要件を、定義づけるのは難しく感じられるかもしれません。IPAでは、以下の6つの観点を非機能要件の大枠として定義しています。

1. 可用性

そのシステムがどのくらい継続して稼働できるのか、メンテナンスやトラブルからの復旧にかかる時間はどの程度かといった稼働率を示すのが「可用性」です。システムが使用されるシチュエーションや目的によって、要求されるレベルが異なります。

2. 性能・拡張性

導入される業務に対応できるだけの性能がなければ、システムは使命を果たせません。そのため、データを処理する能力や速度が条件を満たしているかを確かめる必要があります。また、将来的に機能を増やすなどシステムを拡張する際に、さらなる性能アップが目指せるかも重要な観点です。

3. 運用・保守性

システムやソフトウェアがユーザーの手に渡り、実稼働が始まれば安全に使い続けられるよう運用・保守していく必要があります。システムの監視や切り替え、バックアップを行う範囲や頻度を検証することで保守性を評価します。

4. 移行性

移行性とは、現行システムから新システムへの移行のしやすさを指し、従来の資産をどのように管理するのかに関わる項目です。保持しているデータの量や種類のほか、今後新しいシステムへ移行する場合の移行方法や、移行にかかる期間を見ていきます。

5. セキュリティ

不正アクセスや情報漏洩といった問題の発生を防ぐため、システムの安全性が確保されているかを評価します。ログの保存や追跡など、万が一の事故発生時に被害状況の把握や原因究明のための機能についてもチェックします。

6. システム環境・エコロジー

湿度や温度、耐震、電圧といったシステムの設置予定地の状況から、システム側が周囲の環境に与える影響までをチェックします。環境に影響を及ぼす要因の例として、消費エネルギー量やCO2排出量などが考えられます。

システムテスト（総合テスト）の流れ

ソフトウェア検証では、どこに焦点を当て、どのような観点からシステムの評価を決めるべきなのか、細かく検討してからテストを行うことが求められます。そのためシステムテストを実行する際には、次のような手順を踏んで定めた綿密なプランに基づいて作業を進めます。

ここでは、実際にどのような手順で計画や準備を進めればよいのか、各工程のポイントを詳しく見ていきます。

1. テスト計画

膨大なテストケースの中から本当に必要な内容を選び出し、適切なテストを実行するには、事前に指針が明確化されていなければなりません。そのため、まずは要件定義書を参考に、全体の方針をまとめた「システムテスト計画書」を作成します。

計画書には、何を目的としてどのような方法でシステムテストを行うのか、テストの対象とする範囲（スコープ）やスケジュール、リスク管理と対処策、テスト全体としての方向性といった概要を記載します。

2. テスト設計

概要がまとまったら、その内容に基づき「システムテスト仕様書」を用意します。この工程では、テストケースの具体的な項目や各テストの担当者、実行するために必要な環境や使用ツールなど、より詳細な作業内容を決めて滞りなくテストが進められるように土台を固めます。

どのような視点で品質の良し悪しを判断し、どのラインを合格とするのかといったテスト結果の判定基準についても、仕様書の内容に盛り込みます。その後、実際にテストを実行する際の条件や手順をまとめた「システムテスト手順書」を作成します。

3. テスト環境・データ準備

仕様書や手順書の作成が完了したら、いきなりテストに入るのではなく、テストを行うための環境やデータを準備する必要があります。

システムテストを行うために使用する機材や付属ハードウェア、OSなどは、基本的に本番環境と同様のものを用意します。テストデータについても、基本情報から稼働によって蓄積されるデータまで、すべて本番環境を想定したものを採用することで、想定にない動作やトラブルを避けることにつながります。

4. テスト実行・進捗管理

仕様書や手順書に従ってテストを実行します。テストを経て不具合が見つかった場合は、問題点の切り分けを行い、開発者が改修できるよう原因を突き止めます。修正を行ったら、原因が正しく取り除かれているか、新たな問題が発生していないかをチェックするため、再度テストをする必要があります。

また、テストの進捗管理や不具合管理、修正内容や変更点について関係者に報告します。テストの結果や状況を踏まえ、関係各所でリリース可否や不具合修正に関する方向性が検討されます。

5. 分析

あらかじめ想定したすべてのテストケースを実行し、システムが問題なく動作すれば、システムテストは終了となります。完了後にはしっかりとテスト分析を行い、要件定義書やシステム仕様書の内容とも照らし合わせながら、検証結果や改善点についてまとめます。

結果や改善案を整理した「テスト終了報告書」を作成し、今後の開発や品質向上に役立てられるように、関係者に共有します。

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

システムテストでは、初めに作成する「システムテスト計画書」の内容が、その後の方針やテスト品質を大きく左右します。計画書に記載しておくべき内容とは、具体的にどのようなものなのでしょうか。

システムテスト計画書の記載内容としては、主に次のような項目があります。より適切なシステムテストを行うために、これらの項目をしっかりと検討しておくことが重要です。

1. テストの目的や背景
2. テストレベルの定義
3. テストの範囲
4. アプローチの方向性
5. 必要な環境・ツール
6. 開始や終了、中断、再開の基準
7. テストのタスク
8. リスクと対策
9. 体制・スケジュール
10. スタッフのスキル要件、トレーニング計画
11. 各種管理規定
12. テストで得られる成果物のリスト

システムテスト（総合テスト）の代表例

システムテストには次のようなものがあり、それぞれ役割が異なります。

システムの検証を行う際には、これらの中からプロジェクトの特性に合ったものを選択し、テストを進めていくことが求められます。この項目では、各テストの目的や特色についてまとめていきます。

機能テスト

前述のとおり、システムテストで確認しなければならない要件は「機能要件」と「非機能要件」に分けられます。機能テストとは、機能要件を満たしているかをチェックするためのテストです。発注者が求めている機能が要望どおりの仕様で搭載され、問題なく使用できるかを確認します。

システムの役割の根本に関わるテストであり、重大な欠陥が発見されることも多い工程のため、見落としがないよう入念に行うことが推奨されます。

性能テスト

性能テストでは、文字どおり性能面の評価を行います。データの処理能力や応答速度、時間効率や資源効率といったパフォーマンスを検証し、要求される性能を満たしているかを確認します。

性能テストの合格基準を低く設定してしまうと、レスポンスが遅いシステムが出来上がり、エンドユーザーにストレスを与えてしまうケースもあります。実際に使用される環境を想定した合格基準を設け、条件ごとに応答時間などを測定して最適化を図ります。

構成テスト

構成テストとは、ソフトウェアを推奨する環境設定で使用した際に、問題なく画面が表示され、プログラムが動作するかをチェックするテストです。環境設定とは、サーバー環境やPCのOS、ブラウザの種類、スマートフォンのデバイスなどを指します。「機種テスト」とも呼ばれています。

負荷テスト

ソフトウェアは、ただ性能を高めることだけを追求すると、負荷に耐えられず正しく動作しなくなるケースがあります。そのため、負荷テストを行って性能と耐久力のバランスが取れているかを検証する必要があります。平時の基本的な動作をチェックする負荷テストのほかに、次のようなパターンがあります。

耐障害テスト

非機能要件として挙げた内容のうち、「運用・保守性」に関わるテストです。「障害許容性テスト」とも呼ばれます。トラブルが発生した際に最低限の機能を維持できるか、復旧にかかる時間や手順、障害発生後にデータを回復できるかなどをチェックします。

想定外の事態が起きた際の対応策や行動手順、代替業務などが定められている場合は、それらの内容についても確認し、問題なく業務を再開できるかを検証します。

セキュリティテスト

セキュリティテストでは、情報漏洩や不正アクセスを防ぐために搭載されている機能が、仕様書どおりに動作しているかを検証します。不特定多数のユーザーが利用する予定のシステムでは、特に必要不可欠なテスト内容です。

データに干渉できるかを試す方法として、サイト間を横断してスクリプトを混入させる「クロスサイト・スクリプティング」、ユーザーの入力領域からデータベースを操作する言語を送り込む「SQLインジェクション」などのパターンがあります。また、ホワイトハッカーと呼ばれる技術者により、意図的にサイバー攻撃を仕掛けることで脆弱性を見つけ出す方法もあります。

シナリオテスト

シナリオテストとは、ユーザーが使用する際の一連の流れに沿って、滞りなくシステムを利用できるかをテストするものです。実際の業務フローを想定したテストシナリオを作成して、その手順どおりに操作を実行します。

このテストを行う場合は、まず必要な業務プロセスを分解・整理し、分岐条件などを確認して、起こりうるパターンを洗い出します。各場面での操作の流れをより正確に判断するため、使用するユーザーの年齢層や知識量、感情などを想定し「ペルソナ」を設定して行う方法もあります。ユーザー目線に立って、要求に合致する成果物になっているかを確認できるテストとなっています。

リグレッションテスト

システムに何らかの修正や変更を加えた場合、その影響で意図していない部分にまで変更が生じ、新たな欠陥が発生するケースがあります。こうした問題が起きていないかを確認するため、システムを修正するたびに再テストが行われます。このテストが「リグレッションテスト」です。「回帰テスト」や「退行テスト」とも呼ばれています。

変更のたびに想定できうるすべてのパターンをテストし直すことは非現実的なため、範囲や優先度をある程度絞って実行するのが一般的とされています。

ユーザビリティテスト

ユーザビリティテストは、ユーザーにとって使いやすい製品になっているかを確かめるテストです。操作性や画面の見やすさ、わかりやすさ、学習性などを確認し、使いにくいと感じる部分があれば改善します。

少ない労力でスムーズにやりたいことができるかという点は、実際に利用するユーザーの満足たびに深く関わり、十分なテストを実施することで競争力のある質の高い製品を生み出すことにつながります。

システムテスト（総合テスト）で用いられる技法

内部構造を考慮せず、入力した内容と出力された結果のみに重点を置くテスト技法のことを「ブラックボックステスト」といいます。システムテストで機能要件を満たしているかをチェックする際には、このブラックボックステストの技法が用いられることが多いです。

ブラックボックステストの手法として、ここでは次の6種類をご紹介します。

同値分割法

同値分割法では、データの範囲をいくつかのグループに分け、各グループの代表的な値を使ってテストを実行します。同様の結果が得られる範囲を「同値クラス」として分類するのが原則で、代表値の結果が得られれば、同値クラスのほかの値についても同じ結果になると考えます。

各グループ最低1回のテストを実行すれば済むため、テスト回数を少なく抑えながら広範囲の検証を行え、効率的に問題点を発見できるという利点があります。

境界値分析

同値分割法と同様に、データの範囲を「同値クラス」にグループ分けした後、クラス同士の境界（各クラスの両端）の値を使用して検証する手法のことを「境界値分析」と言います。

いわゆる「未満」や「以下」と表される部分にあたることから、境界値には不具合が起こりやすい傾向があるとされています。不具合が偏在する場所に焦点を当てることで、限られた時間や予算でも問題を検出しやすい方法となっています。

デシジョンテーブルテスト

デシジョンテーブルとは、起こりうるステータスや動作、入力値といった条件の組み合わせをまとめた表を指します。デシジョンテーブルテストでは、この表を活用してテストを進めます。

仕様を整理し、あらゆるパターンを網羅するテストを行うため、作成・実行に手間がかかるというデメリットはあるものの、テストケースの抜け漏れを防げるという利点があります。多数の条件が存在する場合や、その条件によって結果が変わってしまうケースに向いている手法です。

状態遷移テスト

状態遷移テストでは、図形や記号などを用いてビジュアル的にシステムの状態変化を示す「状態遷移図」と、条件に応じてどのようにシステムの状態と結果が変化するのかを表にまとめた「状態遷移表」を使用します。

状態遷移図と状態遷移表を照らし合わせることで、何らかのイベントが発生した際に、想定どおりにシステムの状態が変化するかを確かめられます。

ユースケーステスト

ユースケーステストは、ユーザーが目的を達成するために行う操作の流れを整理し、テストケースに落とし込んでいく手法です。ユースケースはドキュメントや図で表され、これらを参考にテストケースを立案します。

ユーザーによる実際の操作の流れに沿って行う点がシナリオテストに似ていますが、ユースケーステストはより限定的な条件下での不具合を検出するために行われる手法であり、ユーザーや発注者の狙いを反映しやすいという特徴があります。

組み合わせテスト

組み合わせテストとは、入力条件（因子）と因子ごとに発生しうる値（水準）との組み合わせについて、網羅するようにテストを実行していく方法です。

すべての組み合わせを検証することは、テストケースが膨大になり非現実的であるとされています。そのため、複数の因子の中から任意の因子を選ぶことでポイントを絞る「オールペア法（All Pair法）」や「直交法」を活用することで、テストケースの削減を行うことが多くなっています。

まとめ

システムテストの種類や手法は幅広く、対象となるソフトウェアの特徴によって、重視するべき観点や合格基準も変わります。また、結合テストや受け入れテストとの違いをひもとくことで、システムテストの役割をより明確に意識できるのではないでしょうか。

より安全で使いやすい、品質の高い製品を開発していくには、適切なシステムテストを行うための知識や環境が必要不可欠です。Ｓｋｙ株式会社では、このような業務の委託にも対応しておりますので、システム検証についてお困りの際はぜひご相談ください。

ソフトウェア評価・テストに関するお問い合わせはこちら

お問い合わせはこちら