システムテストの全体像をまとめて解説丨種類・手法・観点・手順が分かる！

システムテストの目的は、欠陥を事前に検出し、システム全体の品質を確保することです。実際の利用環境を想定した条件下で動作を確認するため、ユーザーの利用時に想定されるトラブルや使いにくさを事前に把握することが可能です。

また、システムの完成後に実施されるため、機能間の整合性だけでなく、ユーザビリティや性能に関する問題も網羅的に検出できます。明らかとなった問題を修正することで、システムの完成度をより高められます。

システムの欠陥は、ユーザー体験の低下につながります。実際、当社が実施したアプリの欠陥に対する印象の調査では、9割以上のユーザーがストレスを感じていることがわかりました。

Q.アプリやWebサイトなどの利用時に欠陥が起きると、どの程度ストレスを感じますか？

機能要件とは、システムが提供すべき具体的な機能やユーザーの操作などを記載した条件です。一般的に要件定義書や仕様書に定められ、システムテストではそれらに沿ってシステムの振る舞いや機能を確認します。

たとえば、エンタープライズサーチの場合は、キーワード検索が正しく機能するか、利用ログは取得できるか を確認します。とくに、ユーザーの期待に応じた機能が実装されているかをテストすることで、客観的なシステム品質の担保が可能です。

非機能要件とは、機能以外にシステムが備えるべき特性や振る舞いに関する基準です。IPA（独立行政法人情報処理推進機構）は、以下のように非機能要件を定めています。

1：可用性
2：性能・拡張性
3：運用・保守性
4：移行制
5：セキュリティ
6：システム環境・エコロジー

各項目について解説します。

1：可用性
可用性とは、システムがどれくらい中断なく利用できる状態を維持できるかといった継続性を示す項目です。システムテストでは、通常運用のほか、障害や災害が発生した際を想定し、復旧にかかる時間や利用が停止する時間なども確認します。

2：性能・拡張性
性能はシステムのパフォーマンス、拡張性はスケーラビリティを評価する項目です。システムテストの性能に関しては、業務のピーク時・通常時で期待するシステムの性能目標をもとに、応答速度やデータ送信量などを確認します。

また、拡張性に対しては、将来的なシステムの性能向上のために、機能追加がしやすいかを評価します。

3：運用・保守性
運用・保守性は、システムを安定して使い続けるために必要な管理体制や対応力を指します。システムテストでは、監視機能の動作やシステム障害時の対応手順などを確認します。

4：移行制
移行性とは、既存のシステム資産を新しい環境へ問題なく引き継ぐために求められる条件を指します。データの種類や量に応じた移行手段の選定に加え、適切な期間設定や手順の設計が必要です。システムテストでは、移行する際の手順やトラブル発生時の対応などを評価します。

5：セキュリティ
セキュリティは、情報資産を不正なアクセスや情報漏えいから守るために必要な対策全般を評価する項目です。

システムテストでは、ユーザーごとのアクセス制御や通信の暗号化の方法、不正行為を追跡できるシステムログの保存期間、不正アクセスを検知する仕組みなどを確認します。

6：システム環境・エコロジー
システム環境・エコロジーは、システムの設置環境や環境負荷に関する要件です。システムテストでは、設置環境の耐震構造や温度・湿度の管理など、機器が安定して稼働できる空間かどうかを確認します。

電力消費の最適化や二酸化炭素排出量の抑制といった環境配慮も重要な確認項目です。

機能テストは、発注者の期待どおりに動作や機能がシステム上で正しく実現されているかを確認するテストです。たとえば、ボタンを押した際に正しい画面へ遷移するか、入力内容が要求どおりに振る舞うかといった確認が挙げられます。

ここからは、機能テストの一種であるシナリオテストについて解説します。

■ シナリオテスト
シナリオテストは、実際の使用環境や一連の操作手順を想定し、ユーザーがシステムを問題なく利用できるかを確認するテストです。操作の分岐や例外処理も含め、ユーザーが遭遇しうるさまざまな状況を想定したシナリオに沿って確認を行います。

実施にあたっては、ユーザーの年齢や知識、心理状態などを想定した人物像を設定すると、より実践的な確認が可能です。

性能テストは、システムの処理能力や応答速度などの性能要件を確認するためのテストです。応答遅延によるユーザーのストレスを軽減し、快適なユーザビリティを提供するうえで欠かせません。

具体的には、データ処理の負荷や動作時間、リソース使用率などを確認し、利用環境に応じた性能があるかどうかを確認します。

負荷テストは、通常の業務量に相当する負荷を発生させた際に、システムが安定して動作するかを確認するテストです。たとえば、多数のユーザーが同時にログインしたり、大量のデータが扱われたりする状況を想定し、適切に機能するかどうかを確認します。

ここからは、34つの負荷テスト の種類を紹介します。

■ キャパシティテスト
キャパシティテストは、システムが性能を維持したまま対応できる最大の負荷量を明らかにするためのテストです。ユーザー数やデータ量が増加した際に、どの時点で動作が不安定になるかを見極め、ボトルネックや許容限界を把握します。

スケールアップに備えるうえで重要なテストであり、システム全体の拡張性を検討する際の判断材料としても活用されます。

■ ロードテスト
ロードテストは、利用が集中する時間帯においてもシステムが安定して動作し続けるかを確認するテストです。負荷が高まっても応答時間に著しい低下が見られないか、快適に利用できる状態を保てるかを判定します。

■ ロングランテスト
ロングランテストは、システムを長時間連続して稼働させ、安定性やパフォーマンスを確認するためのテストです。時間の経過とともに発生するリソースの枯渇や応答遅延、意図しない停止などの異常を早期に見つけることが目的です。

通常運用に近い状態で継続的に稼働させることで、短時間のテストでは見逃されがちな問題点を確認します。

■ ストレステスト
ストレステストは、通常より高い負荷を意図的にかけ、限界を超えた際のシステムの挙動を検証する試験です。処理数や同時アクセス数を増やし続けた際、サーバーやネットワークがどの時点で性能の限界に達するか、想定どおりのエラーが返されるかなどを確認します。

ストレステストによって、障害発生の引き金となる要因や処理が遅れる箇所を把握できます。

ユーザビリティテストは、システムが直感的に操作できるかどうか、ユーザーの立場から確認するための試験です。画面構成や操作手順のわかりやすさ、視認性の高さなどを実際の使用状況に近い環境で評価します。業務効率や顧客満足度に直結する重要なテストです。

耐障害テストは、システムに予期せぬ障害が発生した場合でも、機能を維持しながら復旧可能かを確認するテストです。障害発生後に業務を継続するための代替手段や対応手順、データの復元可否などを確認します。

セキュリティテストは、サイバー攻撃や情報漏えいを防ぐために、セキュリティ機能が正常に機能しているかを確認するテストです。

スクリプトを不正に埋め込む手法や入力欄から意図しないデータベース操作を行う攻撃など、現実的なリスクを想定したテストを通じて脆弱性を洗い出します。

構成テストは、特定の動作環境においてシステムが正常に作動するかを確認するテストです。利用されるサーバーの設定やパソコンのOS、スマートフォンの機種ごとに表示の乱れや動作の欠陥がないかを確認します。

リグレッションテストは、機能追加やアップロードを行った際に、既存の機能や性能に悪影響がないかを確認するテストです。リスクの発生確率や影響度をもとに、優先度の高いものから順に実施します。

同値分割法は、同じ出力になる入力値をグループ（同値パーテーション）に分類し、各グループの代表的な値を確認するテスト技法です。代表値のみを抽出して確認するため、テスト効率を高められます。

境界値分析は、仕様にある未満や以上といった判定条件の境界付近にあたる値を確認するテスト手法です。境界となる前後の値はコードの欠陥が生じやすく、重点的に確認することで欠陥を効率良く見つけ出せます。

デシジョンテーブルテストは、入力条件の組み合わせに対する動作結果を表に整理する手法です。表形式で可視化することで、条件が多いシステムにおける確認の漏れや重複を防ぎます。また、通常では起こりえない条件の組み合わせも見つかりやすく、仕様の改善にも役立ちます。

状態遷移テストは、特定の条件下でシステムが仕様どおりに振る舞うかを図や表で整理する手法です。図解形式の「状態遷移図」は流れを視覚的に把握しやすく、一方「状態遷移表」は条件ごとの挙動を体系的に整理できます。複雑なプログラムにおける抜け漏れを未然に防ぎます。

ユースケーステストは、ユーザーが目的を達成する過程に注目し、操作の一連の流れをもとに確認する手法です。実際の利用シーンを踏まえて、アクターの行動やその結果をユースケースとして整理し、テストシナリオを作成します。

画面遷移や操作順序など、実用的な観点からシステムの動作を評価するため、ユーザー視点での品質確保に貢献します。

組み合わせテストは、複数の条件や設定値の組み合わせによって発生する欠陥を効率的に見つける手法です。因子間の代表的な組み合わせだけを抽出する「ペアワイズ法」などを用いて、現実的な範囲でテストケースを絞り込みます。

最初に全体のテスト計画を立案します。具体的には、対象とする範囲や目的、担当者の割り振り、実施期間などを定めます。また、テスト開始と終了の基準を設定することで、無駄なテストを減らせるため、工数の削減が可能です。

テスト計画をもとにテストの種類や要件を明確にし、具体的なテストケースへと落とし込みます。正常な操作に対する動作確認はもちろん、誤操作や異常な入力による動作も想定し、幅広い状況を網羅するテスト項目を設計します。設計書と照合し、抜け漏れのないテストケースを作成することが重要です。

テスト環境の構築は、本番と同様の条件で確認するために欠かせません。OSや周辺ツール、データを実運用に近づけることで、実際の利用シーンに即した欠陥の検出が可能となります。

要件定義書に従い、期待どおりにシステムが機能するかを確認します。検出された欠陥は内容を記録し、開発チームと速やかに連携を取ることが大切です。

テストがすべて完了した後は、記録結果をもとに分析し、実施の妥当性や抜け漏れの有無を確認します。必要に応じて第三者のフィードバックを受け、品質の見落としがないか精査が必要です。

テストケースの漏れや修正確認の不足、あるいは完了基準を満たしていない箇所が見つかった場合は再テストを行い、最終的に合格と判断された場合にシステムテストは終了です。