この記事の要点

総合テスト = システムテスト。「単体 → 結合 → 総合 → 受入」の 3 段階目で、システム全体としての要件適合を検証 シナリオベース: 業務フロー（ユーザストーリー）に沿って End-to-End で確認 機能テストに加え、性能（負荷・ストレス） / セキュリティ / 互換性 / 運用性を網羅 自動化: Selenium（古参）/ Cypress / Playwright（現代の主流）/ K6（負荷） 完了判定: 残バグ重要度・カバレッジ・性能基準・セキュリティチェック・受入準備の総合判断

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

総合テストは、開発したソフトウェアを本番に近い構成で全体として動かし、要件定義書に書かれた要件を満たしているかを検証する工程です。英語では System Test または System Integration Test。単体テスト・結合テストを順に積み上げた最終段階で、開発側として顧客に「受入テストへ進められる状態」を示すフェーズです。

テスト 4 段階の位置づけ（V 字モデル）

段階	対象	検証視点	対応する設計工程
単体テスト（UT）	関数・クラス	ロジックの正しさ	詳細設計
結合テスト（IT）	モジュール間 / API 間	連携・I/F の正しさ	基本設計
総合テスト（ST）	システム全体	要件適合	要件定義
受入テスト（UAT）	業務シナリオ	顧客視点の OK	業務要求

総合テストの種類

分類	テストの種類	確認内容
機能	シナリオテスト	業務フロー全体が成立するか
	正常系 / 異常系	境界値・エラーパスの網羅
	回帰テスト（Regression）	既存機能がデグレしていないか
非機能	性能テスト（負荷 / ストレス）	想定 RPS / 応答時間 / リソース消費
	セキュリティテスト	SQLi / XSS / CSRF / 認証回避
	互換性テスト	ブラウザ / OS / 端末
運用	運用テスト	バックアップ / 障害復旧 / 監視通知
	移行テスト	旧→新へのデータ移行
	ユーザビリティ	UI 操作性 / アクセシビリティ

シナリオベーステストの組み方

[シナリオ例: EC サイトの購入フロー]

1. トップ訪問 → 商品検索 → 商品詳細閲覧
2. ログイン（新規登録 or 既存ユーザ）
3. カートに追加 → 数量変更 → カート確認
4. 配送先・支払い方法選択
5. 注文確定 → 注文確認メール受信
6. 管理画面で注文が連携されている
7. 出荷ステータス変更 → 顧客通知

異常パターンも忘れず:
- 在庫切れ商品をカートに → 適切なエラー
- 二重クリックで注文確定 → 二重注文されない
- セッション切れで再ログイン → カート復元
- 決済失敗 → 在庫戻し / 通知

性能テスト

負荷テスト（Load Test）

想定する通常〜ピークの負荷を与え、性能基準を満たすかを確認します。

ストレステスト（Stress Test）

想定を超えた負荷をかけ、システムが崩壊する点と崩壊の仕方（緩やかに劣化するか、急にダウンするか）を確認します。

ソークテスト（Soak / Endurance Test）

長時間（数時間〜数日）負荷を継続し、メモリリーク / DB コネクション枯渇など長時間運用で出る問題を炙り出します。

K6 での負荷テスト例

// k6 run script.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m',  target: 50 },   // 1 分で 50 RPS まで
    { duration: '5m',  target: 50 },   // 5 分 維持
    { duration: '1m',  target: 100 },  // 100 RPS に上昇
    { duration: '5m',  target: 100 },  // 維持
    { duration: '1m',  target: 0 },    // クールダウン
  ],
  thresholds: {
    http_req_duration: ['p(95) < 500'],   // 95 パーセンタイル 500ms 以下
    http_req_failed:   ['rate < 0.01'],   // エラー率 1% 未満
  },
};

export default function () {
  const res = http.get('https://example.com/items');
  check(res, { 'status was 200': r => r.status == 200 });
  sleep(1);
}

セキュリティテスト

項目	確認内容	ツール例
SQL インジェクション	入力値で DB クエリが操作できないか	sqlmap / Burp Suite
XSS（クロスサイトスクリプティング）	JS が任意実行できないか	OWASP ZAP / Burp
CSRF	トークン無しで状態変更できないか	手動 / ZAP
認証・認可	権限昇格・他人データ閲覧	手動シナリオ
セッション管理	セッション固定・Cookie 属性	ZAP / 手動
機密データ保護	HTTPS / パスワードハッシュ / Secrets	SSL Labs / git-secrets
依存ライブラリの脆弱性	既知 CVE 検出	Dependabot / Snyk / Trivy
ヘッダ / CSP	セキュリティヘッダ正しく設定	securityheaders.com

E2E テスト自動化ツール比較

ツール	言語	特徴
Selenium	多言語	古参、WebDriver 標準。やや低レベル
Cypress	JS/TS	開発者体験良好、リアルタイム再実行、デバッグ快適
Playwright	JS/TS/Py/C#/Java	★ 現代の主流。Chromium / Firefox / WebKit 同時対応、並列高速
Puppeteer	JS	Chromium 専、軽量、スクレイピングにも
Appium	多言語	モバイルアプリ向け
Katalon Studio	GUI	非エンジニア向け

Playwright サンプル

// tests/login.spec.ts
import { test, expect } from '@playwright/test';

test('ユーザがログインしてダッシュボードを見られる', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.fill('input[name="email"]', 'test@example.com');
  await page.fill('input[name="password"]', 'password123');
  await page.click('button[type="submit"]');

  await expect(page).toHaveURL(/.*dashboard/);
  await expect(page.getByRole('heading', { name: 'ようこそ' })).toBeVisible();
});

// playwright test --workers=4   // 4 並列実行
// playwright test --project=chromium,firefox,webkit

テスト環境

環境	用途
開発（dev / local）	個人 PC、頻繁に壊れる前提
結合（int / dev）	結合テスト、開発者で共有
ステージング（stg / staging）	★ 本番同等構成での総合テスト
本番（prd / production）	顧客環境

総合テストは原則ステージングで実施。本番と同一の OS / ミドルウェア / DB バージョン / インフラ構成であることが大前提です。本番データを使うときは個人情報のマスキングを忘れずに。

テストケース管理

ツール	用途
TestRail / Qase / Zephyr	商用 TMS（Test Management System）
Notion / Confluence + スプレッドシート	小規模チームの定番
GitHub Issues / Projects	OSS / アジャイル
JIRA Xray	大規模エンタープライズ

リリース判定基準

総合テスト完了時、次工程（受入テスト or 本番リリース）へ進めるかを判定します。典型的なチェック項目:

• テスト消化率: テストケース総数の 100% を実施完了
• 残不具合: Critical / High はゼロ、Medium 以下は承認済み
• 不具合検出曲線: 検出が収束していること（落ち着いた飽和）
• 性能基準: NFR（非機能要件）の RPS / 応答時間を満たす
• セキュリティ: 脆弱性診断結果が問題なし
• 運用準備: ロールバック手順 / 監視 / オンコール体制
• 顧客承認: ステアリングコミッティでの GO 判定

不具合管理のメトリクス

- 検出バグ数 / 重要度別（Critical / High / Medium / Low）
- 修正率（Fix Rate） = 修正済 / 検出
- 残バグ密度（Bug Density） = 残バグ / KLOC
- 不具合検出曲線（バーンダウン / 累積）
- リグレッション率 = 過去機能でのバグ / 全バグ

代表的な GO 判定例:
- Critical / High バグ = 0
- Medium 以下のバグ ≤ 20 (合意済の Workaround あり)
- 不具合検出が 1 週間以上収束
- 性能 SLA 100% 達成
- 主要セキュリティ脆弱性なし

典型的なつまずき

• テストデータが本番と乖離 → 開発者は気付かない異常が顧客環境で発生
• 性能テストを後回し → リリース直前で要件未達発覚 → 大幅手戻り
• ステージングが本番と違う構成 → 環境差でしか出ない障害
• セキュリティテストを社内ペネトレ無しで省略 → 公開後に脆弱性発覚
• 自動化を後回し → 回帰テストが手作業で膨大化、リリース頻度低下

FAQ

Q: 総合テストと結合テストの境界は？
A: 結合テストは「複数モジュールの連携」、総合テストは「全システム + 外部システム連携 + 非機能」を含む全体検証。プロジェクトにより呼び方の差はあります。

Q: アジャイル開発で総合テストは要る？
A: スプリント単位で部分的に行いつつ、リリース前に全体回帰として総合テストを実施するのが一般的。自動 E2E が前提です。

Q: 自動化はどこから手を付ける？
A: ①ログイン →主要画面遷移 → 重要な購入/申込フロー、の順。Smoke Test → 主要シナリオ →網羅、と広げます。100% 自動化は目指さず ROI で判断。