2024.07.04
ソフトウェア開発におけるテスト工程は、不具合流出によるユーザーからの信頼の失墜を防ぐうえで重要な意味を持ちます。なかでも「システムテスト」は、ソフトウェアの種類にかかわらず品質の保証に欠かせない工程です。
今回は、システムテストの目的・観点、単体テストや結合テストなどの他テストとの違いについて詳しく解説します。
またシステムテストフェーズで実施する主な7種類のテストや、実務で活かせる大まかなテストの流れもご紹介。ぜひ最後までご覧ください。
- もくじ
1．システムテストとは
システムテストとは、あらゆる構成要素を含んだソフトウェア全体の品質を確かめるテストのことです。システムテストは「総合テスト」と呼ばれることもあります。
ここでは、システムテストの目的や特徴、混同されやすい結合テストなどとの違いについて解説します。
1-1 システムテストの目的
システムテストの目的はいくつかありますが、主に以下の2つが挙げられます。
- ソフトウェア全体の動作・振る舞いや能力が、要件・仕様通りであるか確認すること
- ソフトウェアの不具合をリリース前に検出し、信頼を維持すること
ソフトウェアをリリースするうえで、求められる要件や仕様を満たしていることは大前提となります。ソフトウェア全体の振る舞いや能力を要件や仕様と照らして確認することが、システムテストの重要な目的の1つです。
また、機能単体では動作・振る舞いに問題がなくても、別の機能やサーバーなどと組み合わせることで不具合が生じる場合もあります。こうした不具合の流出による顧客やエンドユーザーからの信頼失墜を防ぐ意味でも、ソフトウェア全体としての振る舞いを検証することが重要です。
1-2 システムテストの特徴
システムテストの特徴としては、主に以下の2つが挙げられます。
- 開発側での最終工程のテスト
- 実運用を想定して行うテスト
システムテストは開発側での最終工程のテストであり、リリース後には顧客のもとで「受け入れテスト」が行われます。受け入れテストは、発注側が実際の運用に近しい環境で使用して不具合がないかを検証します。
リリース後の不具合流出を防ぐためにも、システムテストは実運用を想定して実施することが重要です。そうすることで、テスト用の仮想環境では検出できない不具合を検出でき、信頼の失墜を防ぐことにつながります。ですから、できるだけ本番環境に近い環境でテストすることが理想です。
1-3 システムテストとその他テストの違い
システムテスト以外にも複数のテストが存在するため、それぞれの違いを把握しておきましょう。システムテストや前述の受け入れテストも含めて、下の表のようにさまざまなテストがあり、1つの開発プロジェクトにおいて記載順序通りにテストが実施されます。
| テストの種類 | 概要 |
|---|---|
| 単体テスト（コンポーネントテスト） | 関数やモジュールなど、単一要素における振る舞いの妥当性を確認する。 |
| 結合テスト（統合テスト） | 2つ以上の要素を組み合わせて、インターフェースや相互処理の妥当性を確認する。 |
| システムテスト（総合テスト） | すべての要素を組み合わせて、ソフトウェア全体の振る舞いや能力の妥当性を確認する。 |
| 受け入れテスト | 顧客側でソフトウェアを試用し、顧客やエンドユーザーの要求を満たしているか確認する。 |
上記のように、テストによって確認対象や実施目的はさまざまです。システムテストは、顧客側で実施する受け入れテストを除いて、最も対象範囲の広いテストであることがわかります。
2．システムテストの観点
システムテストは、ソフトウェア全体の動作・振る舞いや能力が、機能要件・非機能要件に合致しているかという観点で実施します。機能要件と非機能要件では観点が大きく異なるため、それぞれの違いを把握しましょう。
2-1 機能要件
機能要件とは、ソフトウェアに求められる機能、つまり「ソフトウェアが何を提供するのか」に関する要件のことです。システムテストにおける機能要件のテストケースでは、ソフトウェアの機能が顧客やエンドユーザーが求める通りであるのかを確認します。
開発現場にもよりますが、機能要件は「仕様書」や「要件定義書」といった文書に明記することが一般的です。機能要件のテストケースは、こうした文書の内容に沿って作成します。
2-2 非機能要件
非機能要件とは、ソフトウェアに求められる性質、つまり「ソフトウェアがどのように振る舞うのか」に関する要件のことです。システムテストにおける非機能要件のテストケースでは、ソフトウェアの性質が妥当であるかを確認します。
応答速度といった性能、操作性・視認性といったユーザビリティなど、非機能要件はさまざまです。機能要件とは違い、仕様書や要件定義書などの文書に明記されないことが少なくありません。しかし、非機能要件の欠陥は顧客満足度の低下につながるため、抜かりないテストが求められます。
3．システムテストフェーズで行うテストの主な7つの種類
開発工程の最終段階としてシステムテストを行うことは、これまでにお話してきました。このフェーズでは、機能要件を対象にしたテスト以外にもさまざまなテストを行います。ここでは主な7種類を紹介します。
3-1 要件・仕様ベースのテスト
機能要件を確認するうえでは、要件・仕様ベースのテストが欠かせません。ソフトウェアの振る舞いを、仕様書や要件定義書といった文書に沿って確認します。機能が正しく動作するのかだけでなく、画面上のオブジェクトが正しい位置にあるのか、といった表示面も確認対象です。
一般的に「システムテスト」は、この要件・仕様ベースのテストを指すことが多いです。
要件・仕様にマッチしない動作や表示がある場合は、顧客から承認を得ることは難しいでしょう。要件・仕様ベースのテストは、ソフトウェアをリリースするための大前提として確認が必須です。
3-2 性能テスト
性能テストは、リクエストに対する応答速度や処理できるデータ量など、ソフトウェアの性能面に着目した非機能要件のテストです。実運用を想定してソフトウェアを稼働させ、一定水準の性能が出せているのかを主に確認します。
ソフトウェアの機能は要件・仕様通りでも、あまりに応答速度が遅いようなことがあれば、エンドユーザーのクレームにつながりかねません。性能テストは、エンドユーザーが快適に使えるソフトウェアであることを保証するために不可欠です。
3-3 負荷テスト
負荷テストは、「ソフトウェアがどれだけの負荷を許容できるのか」に着目した非機能要件のテストです。一度に大量のデータを処理させる、同時に大量のリクエストを送る、といったテスト内容が挙げられます。
通常運用における想定以上の負荷を与えた際にも、ソフトウェアが正しく振る舞うのか、確認が大切です。なお負荷テストは、前述した性能テストの一種と捉えられる場合もあります。
3-4 ロングランテスト
ロングランテストは、長時間にわたりソフトウェアを連続稼働させたときの振る舞いを確認するテストです。連続稼働によって機能が正しく動作しなくなったり、応答速度が著しく低下したりといった問題が生じないかを確認します。
プログラムレベルの軽微な問題は、一度のテスト実施だけで顕在化しないことが少なくありません。しかし連続稼働させることで、こうした問題が積み重なって顕在化する場合があります。問題の内容はケースバイケースで、機能要件・非機能要件のどちらも考えられます。
3-5 ユーザビリティテスト
ユーザビリティテストは、ソフトウェアのユーザビリティ（使いやすさ）に着目した非機能要件のテストです。ユーザー目線でソフトウェアを動かし、操作性や視認性に問題がないかを確認します。
ソフトウェアの仕様上は想定していなくても、エンドユーザーが行う可能性がある操作は確認が必要です。たとえば、慣れたエンドユーザーだと、複数の機能を同時に利用することもあるでしょう。エンドユーザーがどのようにソフトウェアを扱うかを、広く想定しなければなりません。
3-6 セキュリティテスト
セキュリティテストは、ソフトウェアのセキュリティ性に着目した非機能要件のテストです。情報漏洩やデータ破壊、不正アクセスなど、セキュリティ上の問題が生じないかを確認します。ユーザー権限に応じた機能のオンオフ切り替えや、失効したパスワードの無効化など内容はさまざまです。
また、悪意を持ったユーザーによるサイバー攻撃を想定したテストケースも必要です。たとえば、悪意のあるプログラムコードが入力されても無効化できるか、といったテスト内容が挙げられます。サイバー攻撃が多様化する現代において、重要性が増しているテストといえるでしょう。
3-7 回帰テスト（リグレッションテスト）
回帰テスト（リグレッションテスト）は、ソフトウェアの変更によって、既存機能に影響が生じていないかを確認するテストです。一般的には、対象機能において過去に実施済みのテストケースを再実施します。
変更のたびにすべてのテストケースを再実施するのは負担が大きいため、変更内容から影響範囲を見定めたうえでテスト範囲を決めることが一般的です。
4．システムテストの大まかな流れ
システムテストは、大まかに5つのステップがあります。ここでは、各ステップについて順番に解説します。
①テスト計画
まずは、テストに関する基本事項を固め、どのように進めていくか明確にします。テストの範囲や目的、担当者、スケジュールなどを決め、「テスト計画書」などの文書にまとめることが一般的です
また、テストの開始基準や終了基準も明確にしましょう。開始基準が満たされないままテストを開始しても、妥当な結果が得られず工数が無駄になってしまいます。終了基準は、後述するテスト完了の判断基準となります。
②テスト設計
テスト設計では、どのようなテストを実施するかを明確にし、テストケースに落とし込みます。テスト設計で作成される文書としては、「テスト設計書」「テスト仕様書」「テストケース」などが一般的です。
また、テストの実施に必要なパラメータを洗い出したり、テストケースに優先順位を付けたりする作業も含まれます。
③テスト実装
テスト実装では、テストデータの用意といったテスト実行に必要な一連の準備作業を行います。サーバーの接続や設定、周辺ソフトウェアの導入など、適切な条件下でテスト実行するための環境構築が必要です。必要であれば、テストプログラムの実装やテスト自動化ツールの導入・設定も行います。
④テスト実行
テスト実行では、テストケースに沿って実際にソフトウェアのテストを実行します。手動のテスト実行では、テスト担当者によるソフトウェアの操作や、期待結果との確認作業が必要です。テスト実行で検出した問題は内容を正確に記録し、関係者へ迅速に情報共有します。
なお、本格的なシステムテストの前に「スモークテスト」を実施することがあります。スモークテストとは、致命的な問題を早期に検出するために、本番の前段階で行う公式性の低いテストのことです。スモークテストでは、最低限ソフトウェアが動くかを大まかに確認します。
⑤テスト完了
最後にテストを完了するために必要な一連の作業を行います。テスト結果をもとに、すべての問題がクローズしていることの確認が欠かせません。また、次期開発に向けての振り返りや、流用できるテストデータなどの整理もあわせて実施します。クローズできない性能面の問題などは、関係者と協議して対応方針を決める必要があるでしょう。
まとめ
システムテスト（総合テスト）とは、あらゆる構成要素を含んだソフトウェア全体の品質を確かめるテストのことです。
単体テスト → 結合テスト → システムテスト → 受け入れテストの工程で実施されます。
開発側での最終テスト工程であり、システムテストで検出できない不具合は、顧客やエンドユーザーのもとに流出するリスクがあります。そのため、システムテストは実運用を想定し、適切な流れで進めていくことが重要です。
システムテストフェーズでは主に以下の7つのテストが実施されます。
- 要件・仕様ベースのテスト
- 性能テスト
- 負荷テスト
- ロングランテスト
- ユーザビリティテスト
- セキュリティテスト
- 回帰テスト（リグレッションテスト）
またテストの流れは以下の通りです。
①テスト計画 → ②テスト設計 → ③テスト実装 → ④テスト実行 → ⑤テスト完了
ソフトウェアの種類にかかわらず、システムテストは品質保証に欠かせません。ソフトウェアの品質向上を見据えるのであれば、今一度システムテストについて見直してみてはいかがでしょうか。
