システムテストとV字モデルの対応関係

V字モデルではシステムテスト（System Test）は要件定義・システム設計と対応します。単体テスト・結合テストでモジュールの品質が確認された後、システム全体を対象に「要件定義書に記載された機能が満たされているか」「非機能要件（性能・セキュリティ・可用性）が達成されているか」を包括的に検証するフェーズです。

システムテストはユーザーの視点に近い形でシステムを評価します。画面操作・業務シナリオ・負荷テスト・セキュリティ検査を組み合わせて実施し、リリース判定の根拠となる品質証跡を作成します。

対応する設計フェーズ
要件定義書・システム設計書・非機能要件定義書
テスト対象の粒度
システム全体。画面操作・API・バッチ・外部連携を網羅的に検証
実施タイミング
結合テスト完了後、ステージング環境（本番同等環境）で実施
品質目標
機能要件の全テストケースがパス。性能目標値達成。セキュリティ脆弱性ゼロ（重大）

INPUTドキュメント — 何を読んでテストを設計するか

INPUTドキュメント参照目的確認箇所
システム要件定義書 テストケースの源泉。全機能要件を網羅するテストケースを導出する 機能一覧・業務フロー・画面遷移・ユースケース
非機能要件定義書 性能目標値・可用性目標・セキュリティ要件からテスト合否基準を定める レスポンスタイム上限・同時接続数・RTO/RPO・OWASP Top 10 対応方針
画面設計書・画面一覧 E2Eテストシナリオの操作手順・画面遷移・入力値・表示内容を確認する ワイヤーフレーム・バリデーションルール・エラーメッセージ・画面遷移図
性能要件定義書 負荷テストの目標値（同時接続数・スループット・レスポンスタイム）を定義する 最大同時ユーザー数・ピーク時想定 RPS・レスポンスタイム上限・エラー率上限
セキュリティ要件定義書 セキュリティテストの対象（OWASP Top 10 等）と合否基準を確認する 脆弱性カテゴリ・ペネトレーションテスト範囲・受け入れ基準

💡 システムテスト計画書の重要性

システムテストはスコープが広いため、事前に「テスト計画書」を作成することが不可欠です。テスト計画書にはテスト戦略・スケジュール・担当者・環境・合否基準・リスクを明記し、ステークホルダーの合意を得てからテスト仕様書の作成に着手してください。

作成ドキュメントの構成

① テスト計画書

テスト計画書はシステムテスト全体の設計図です。テストの目的・対象範囲・テスト種別（機能テスト・性能テスト・セキュリティテスト）・実施環境・スケジュール・合否基準・リスクと対策を記載します。計画書はテスト開始前にプロジェクトマネージャ・開発リーダー・品質担当者のレビューを受けます。

② システムテスト仕様書

テスト仕様書はテストケースの一覧です。機能テストでは業務シナリオに沿った操作手順・期待結果を記載します。TestRail などのテスト管理ツールを使うと、テストケースの実行状況・バグ件数・消化率をリアルタイムで可視化できます。

記載項目内容
テストケースID一意の識別子（例：ST-LOGIN-001）
要件ID（トレーサビリティ）対応する要件定義書の要件ID
テスト分類機能テスト / 性能テスト / セキュリティテスト / 回帰テスト
操作手順画面操作・APIコール・バッチ実行の手順をステップごとに記載
期待結果画面表示・レスポンス・DB状態・ログ出力の期待値
実行結果OK / NG / 保留 + NG の場合はバグチケット番号
エビデンススクリーンショット・ログファイル・テスト結果レポートへのリンク

③ テスト結果報告書

テスト終了後に作成するサマリーレポートです。テストケース総数・実行数・合格数・不合格数・未実施数、バグ一覧と対応状況、合否判定とリリース判断の根拠を記載します。ステークホルダーへの報告材料にもなります。

確認ポイント — 機能・性能・セキュリティ

機能テストの確認ポイント

観点確認内容優先度
機能要件の全網羅 要件定義書の全機能がテストケースとして存在し、全てパスすること 必須
業務シナリオ エンドツーエンドの業務フロー（例：注文 → 決済 → 出荷）が正常に完了すること 必須
権限・認証 ロールごとに許可された操作のみが実行でき、禁止された操作は拒否されること 必須
エラーハンドリング 異常入力・タイムアウト・外部サービス障害時に適切なエラーメッセージが表示されること 必須
データ整合性 複雑な業務操作後にデータが一貫した状態であること 推奨

性能テストの確認ポイント

テスト種別目的主な計測値
負荷テスト 想定最大ユーザー数でレスポンスタイムが目標値内に収まること 平均/P95/P99 レスポンスタイム・スループット（RPS）・エラー率
ストレステスト 想定を超える負荷でもシステムが安全に失敗し、回復できること エラーレート急増ポイント・回復時間
耐久テスト 長時間稼働でメモリリーク・コネクションリークが発生しないこと メモリ使用量推移・GC頻度・DBコネクション数

セキュリティテストの確認ポイント

脆弱性カテゴリ（OWASP Top 10）確認内容
インジェクション（SQL / LDAP / コマンド）悪意ある入力でDBや OS コマンドが実行されないこと
認証の不備セッション管理・パスワード強度・多要素認証が適切に実装されていること
機密データの露出パスワード・個人情報が暗号化され、ログに出力されないこと
XSS（クロスサイトスクリプティング）ユーザー入力がエスケープされ、スクリプトが実行されないこと
不適切なアクセス制御認可されていないリソースへのアクセスが拒否されること

利用ツール — Playwright / JMeter / OWASP ZAP / TestRail

Playwright（E2E テスト）

Playwright は Microsoft が開発した E2E テストフレームワークです。Chromium・Firefox・WebKit（Safari）をサポートし、クロスブラウザテストが可能です。ネットワーク傍受・モックAPI・スクリーンショット・動画録画機能を標準で持ちます。Cypress と比べてより複雑なシナリオ（複数タブ・ファイルダウンロード・マルチドメイン）に対応しており、CI/CD との統合も容易です。

Playwright
クロスブラウザ対応・並列実行・ネットワーク傍受が強力。TypeScript/JavaScript/Python/Java 対応。
Cypress
開発者体験が高い。ダッシュボードでテスト結果を可視化。主に Chromium ベース。
Selenium
長年の実績と豊富なエコシステム。多言語対応。Grid で分散実行も可能。
Allure Report
テスト結果をリッチな HTML レポートで可視化。スクリーンショット・ログを自動添付。

Apache JMeter（性能テスト）

JMeter は Java ベースの負荷テストツールです。HTTP・REST・SOAP・JDBC・LDAP など多様なプロトコルに対応し、シナリオを GUI で設計できます。CLI モード（non-GUI）での実行が本番負荷テストでは推奨されます。Gatling（Scala DSL）や k6（JavaScript）も同様の用途に使えます。k6 は軽量で CI 統合が容易なため、近年採用が増えています。

OWASP ZAP（セキュリティテスト）

OWASP ZAP は OWASP が提供するオープンソースの動的アプリケーションセキュリティテスト（DAST）ツールです。プロキシとして動作し、画面操作中の通信を傍受してセキュリティ問題を検出します。自動スキャン機能を CI/CD に組み込むことで、プルリクエストごとにセキュリティチェックを自動実行できます。商用ツールとしては Burp Suite があります。

TestRail（テスト管理）

TestRail はテストケース・テスト実行・バグトラッキングを一元管理するツールです。テストケースの消化率・合格率・欠陥密度をダッシュボードで可視化でき、Jira・GitHub との連携で検出したバグを自動チケット化できます。小規模プロジェクトでは Excel や Backlog のテンプレートでも代替できます。

よくある落とし穴と対策

⚠️ 非機能要件のテストを後回しにする

性能テスト・セキュリティテストは「後でやろう」と後回しにされがちですが、システムテスト計画に最初から組み込むべきです。性能問題は早期発見ほど修正コストが低く、セキュリティ脆弱性はリリース直前の発覚でも対処に多大な工数がかかります。

⚠️ テストケースのトレーサビリティ欠如

テストケースと要件定義書の対応関係（トレーサビリティマトリクス）がないと、テストが完了しても「どの要件を検証したか」が不明になります。テストケースIDと要件IDを紐付け、全要件がテストケースで網羅されているかをマトリクスで確認してください。

⚠️ 本番と異なるテスト環境での性能テスト

性能テストはできる限り本番環境に近いスペックで実施する必要があります。開発環境では問題なかった性能が、本番のデータ量・ネットワーク構成・ミドルウェア設定の違いで目標値を満たせないケースは頻繁に発生します。

まとめ

システムテストフェーズで定義すべき3つのポイントを整理します。

  • INPUT：システム要件定義書・非機能要件定義書・画面設計書・性能要件・セキュリティ要件
  • 作成ドキュメント：テスト計画書・テスト仕様書（機能/性能/セキュリティ）・テスト結果報告書
  • 確認ポイント：機能要件の全網羅・業務シナリオ・権限制御・性能目標値・OWASP Top 10 対応

E2E テストは Playwright、性能テストは JMeter または k6、セキュリティテストは OWASP ZAP を CI/CD に組み込み、テスト管理は TestRail で一元化することで、品質の可視化とリリース判断の根拠を確実に作成できます。

✅ 次のステップ

システムテスト仕様書の作成が完了したら、次は「受け入れテスト仕様書」へ。ユーザー視点でビジネス要件の充足を確認する最終テストフェーズに進みます。