異常系テストとは、ユーザーの誤操作やシステム障害など仕様外の異常な状況下で、システムがデータ破損・情報漏洩・無応答といった致命的な挙動を起こさないことを検証するテストです。正常系テストが「仕様通りに動くか」を確認するのに対し、異常系テストは「想定外の状況でも壊れないか」を確認します。
異常系テストは、意識的に異常条件を洗い出さない限りテストケースに含まれず、後回しや工数不足での省略が起こりやすい工程です。
そこで本記事では、異常系テストの定義と正常系・準正常系との違いを整理したうえで、4つの観点による網羅的な洗い出し方法、テストケース設計の3ステップ、限られた工数での優先順位の付け方までを解説します。
異常系の洗い出し観点が固まらないまま設計を進めると、本番で初めて表面化する障害を見落としがちです。自社だけで観点を出しきれないと感じたら、標準テスト観点1,000件を体系化したバルテスのソフトウェアテストサービスを、異常系設計の相談先として検討してみてください。
異常系テストとは？ 正常系・準正常系との違い
異常系テストは、仕様から外れた異常な状況でシステムが致命的な挙動を起こさないことを検証するテストです。正常系テスト・準正常系テストとは検証対象が異なり、混同したまま設計すると本来テストすべき異常を検出するために必要なテストが抜け落ちるおそれがあります。
1-1. 異常系テストの定義と目的
異常系テストとは、不正な入力や動作条件の未達など仕様範囲外の状況において、システムがデータ破損・情報漏洩・無応答などの致命的な挙動を起こさないことを検証するテストです。
想定される異常状況には、入力欄への不正な文字列、必要なファイルが存在しない、処理の途中で電源が落ちる、といった仕様として定義されていない状態が含まれます。
目的は、仕様通りに動くことの確認ではなく「致命的な挙動が起きないこと」の確認にあります。正常系テストが機能の正しさを保証するのに対し、異常系テストはシステムの信頼性を保証する役割を担うため、両者は補完関係にあります。
脆弱性の作り込みは今も後を絶ちません。IPAへのソフトウェア等の脆弱性関連情報の届出は2024年だけで合計632件に上り、そのうちウェブサイトが53%を占めています（出典：IPA 独立行政法人 情報処理推進機構「ソフトウェア等の脆弱性関連情報に関する届出状況[2024年第4四半期（10月～12月）]」2025年）。
XSSやSQLインジェクションのように不正な入力を起点とする脆弱性は多く、異常系テストで不正入力を洗い出すことは、こうした脆弱性を作り込まないための基礎的な工程です。
1-2. 正常系・準正常系・異常系の3つの違い
テストは検証対象の性質で3つに分かれます。正常系は「仕様通り動くか」、準正常系は「仕様に規定された、正常ではない入力や状態に対して期待通りに処理されるか」、異常系は「仕様に書かれていない異常でも致命的な挙動を起こさないか」を検証します。違いを整理すると次のとおりです。
| 分類 | 検証対象 | テスト目的 | 具体例（税込価格を表示する機能） |
| 正常系 | 仕様通りの入力・操作 | 期待通りの結果が返るか | 1,000円を入力すると税込1,100円が表示される |
| 準正常系 | 仕様に規定された、正常ではない入力・操作・状態 | 仕様通りのエラー処理や制御が行われるか | マイナス値の入力時、仕様通り「金額は0以上で入力してください」と表示される |
| 異常系 | 仕様に規定のない異常状況 | 致命的な挙動を起こさないか | 数値欄に絵文字や巨大な文字列を送っても、システムが停止せずエラーを返す |
3分類のうち最も混同されやすいのが、準正常系と異常系の境界です。両者を分けるのは「正常ではない入力や状態に対する挙動が、仕様として規定されているかどうか」です。たとえば、仕様に「マイナス値はエラーにする」と定義されていれば準正常系、仕様に定義されていない想定外の入力に対する振る舞いを確認する場合は異常系に当たります。
この区分が現場で曖昧なままだと、テスト設計のたびに「これはどちらか」という議論が発生し、テスト設計が属人化しやすくなります。
異常系テストで何をチェックする？ 4つの観点と具体例
異常系テストの対象は、「入力値」「状態」「環境」「競合」の4観点に大別できます。
異常が起きる原因をたどると、その大半は「外部から渡される値がおかしい（入力値）」「システム内部の状態がおかしい（状態）」「システムが依存する外部環境がおかしい（環境）」「複数処理のタイミングがおかしい（競合）」のいずれかに行き着くため、この4つで異常の発生源の大部分を捕捉できるからです。この分類に沿って洗い出すことで、担当者の経験に頼らず観点の抜け漏れを構造的に防げます。
4観点はこの順にテストが書きやすく、逆に本番での問題発見は難しくなる傾向があります。入力値の異常は単体テストで手早く確認できますが、競合の異常は環境を揃えないと再現すらできません。
2-1. 入力値の異常（境界値・空値・不正文字）
入力値の異常は、境界値・空値・文字種・セキュリティ入力の4カテゴリに大別されます。ユーザーやAPIから届く値は開発者の想定通りとは限らないため、最も基本的でありながら見落としの多い観点です。ここでは境界値と空値、文字種と特殊文字、セキュリティ関連の入力の順に解説します。
なお、境界値や空値、不正文字などへの対応があらかじめ仕様として定義されている場合、その確認は準正常系テストに該当します。ここでは、仕様として定義されていないケースも含め、入力値に起因する問題を洗い出すための観点として整理します。
境界値と空値
境界値は、入力の許容範囲の境目でエラーが起きやすいという経験則に基づく着眼点です。最大値+1、最小値−1、ちょうどゼロといった値を送り込み、範囲外を正しく弾けるかを確認します。空値は、NULL・空文字・スペースのみといった「値が実質的に入っていない」状態を指し、必須項目のチェックが機能するかを検証します。
文字種と特殊文字
文字種の異常は、システムが想定していない種類の文字を送ったときの挙動を確認します。サロゲートペア（一部の漢字や記号）、絵文字、環境依存文字などは、文字数のカウントやデータベース保存でエラーや文字化けを引き起こしやすい値です。これらを許容するのか弾くのかは、あらかじめ期待動作を決めておく必要があります。
セキュリティ関連の入力
セキュリティ入力は、悪意ある文字列を送り込んでも被害が出ないことを確認する観点です。<script>タグを含むXSSの試行や、SQL文を混入させるSQLインジェクションの試行に対し、入力を無害化して処理できるかを検証します。前述のとおり入力処理の不備は脆弱性の主要因であるため、この観点は優先度が高くなります。
代表的なテストケースは次のとおりです。
| カテゴリ | 代表的なテストケース |
| 境界値 | 最大値+1／最小値−1／ゼロ／桁あふれする数値 |
| 空値 | NULL／空文字／半角・全角スペースのみ |
| 文字種・特殊文字 | サロゲートペア／絵文字／環境依存文字／制御文字 |
| セキュリティ入力 | XSS用スクリプト／SQLインジェクション文字列 |
すべての入力パターンを網羅する必要はありません。数値入力欄なら境界値と桁あふれ、自由記述欄なら文字種とセキュリティ入力、というようにテスト対象の特性に応じて選択してください。
2-2. 状態の異常（存在しないリソース・不正な状態遷移）
状態の異常は、システム内部のデータがどんな状態かによって発生する異常で、「存在しないリソースへのアクセス」「削除済みリソースの参照」「処理中リソースの操作」「不正な状態遷移」の4パターンで整理できます。入力値と違い、値そのものは正しくても内部状態が想定と違うことで起きるのが特徴です。
典型例が、REST APIやSPAで頻発する「存在しないIDへのアクセス」です。/orders/99999のように実在しない注文IDを指定したとき、500エラーで落ちるのではなく404を返せるかを確認します。削除済みリソースの扱いも同様で、論理削除ならステータス表示、物理削除なら404というように、削除方式で期待値が変わる点に注意してください。
不正な状態遷移は、業務フローを持つ機能で重要になります。注文ステータスが「作成→確定→発送→完了」と進む設計なら、「作成から確定と発送をスキップして完了にする」ような不正な遷移をリクエストしたとき、システムがそれを拒否できるかをテストします。状態遷移図を描き、許可されない矢印を洗い出すと、この観点のテストケースを漏れなく作れます。
2-3. 環境の異常（ネットワーク障害・DB停止・リソース枯渇）
環境の異常は、システムが依存する外部要素のトラブルで、ネットワーク障害・DB障害・外部サービス停止・リソース枯渇に分類されます。開発環境では再現しにくい一方、本番では必ず発生する種類の異常であり、意識的にテストしない限り漏れます。
ここではネットワークとDBの障害、外部サービス停止とリソース枯渇の順に見ていきます。
ネットワーク障害とDB障害
ネットワーク障害では、応答が返らないタイムアウトや通信の遮断が起きたときに、システムが無限に待ち続けたり落ちたりしないかを確認します。DB障害では、接続そのものができないケースや、複数処理が互いのロックを待ち合うデッドロックを対象にします。いずれもタイムアウト設定とリトライを組み合わせ、一定回数で諦めてエラーを返す設計になっているかがテストの焦点です。
外部サービス停止とリソース枯渇
外部サービス停止は、決済や地図などの外部APIが応答しない、あるいはレートリミットで拒否される状況を指します。特定の外部サービスの障害が自システム全体を巻き込まないよう、サーキットブレーカーで切り離せるかを検証します。リソース枯渇は、ディスクの空き容量やメモリが尽きたときに、データを壊さず安全に処理を止められるかを確認する観点です。
環境異常のテスト漏れが大規模障害を招いた例が、2022年のKDDI通信障害です。メンテナンス作業でのルーターの経路誤設定が発端となり、その後の切り戻し対応を経て61時間25分にわたる通信障害に至り、音声通信で約2,278万人に影響が出ました（出典：KDDI株式会社「7月2日に発生した通信障害について」2022年）。
設定変更やその切り戻しといった「異常時の運用手順」自体も、異常系テスト・検証の対象であることを示す事例です。
2-4. 競合の異常（同時更新・ボタン連打）
競合の異常は、複数の処理が同時に同じデータへアクセスすることで起きる異常で、同時更新とボタン連打が代表例です。単体テストでは1つの処理しか動かさないため発見しにくく、結合テスト以降で顕在化します。特に負荷が絡む競合は、システムテストで重点的に検証します。
同時更新の典型シナリオはこうです。ユーザーAとBが同じ在庫データを画面に表示し、Aが数量を更新した直後にBも自分の画面の古い値で更新する。すると、Aの更新が上書きで消えてしまいます。
対応方式は3つあり、更新時にデータのバージョン不一致を検知してエラーにする楽観的ロック、取得時点でデータをロックする悲観的ロック、後勝ちで単純に上書きする最終更新優先です。どの方式を採るかで期待動作が変わるため、方式を決めてからテストケースを書きます。
ボタン連打は、送信ボタンを素早く2回押すことで同じ注文が二重登録される問題です。対策として、一定時間の連打を無視するデバウンス、送信中はボタンを無効化する制御、同じリクエストを何度受けても結果が変わらない冪等性の担保があります。これらが効いているかを、意図的に連続リクエストを送って確認します。
異常系テストケースはどう設計する？ 3ステップの手順
異常系テストケースは、「異常パターンの洗い出し→期待動作の明確化→テストデータの設計」の3段階で設計します。各段階に判断基準を持たせることで、テスト担当者のスキルや経験への依存を減らせます。
3ステップの流れは次のとおりです。
- 異常パターンの洗い出し（何をテストするかを決める）
- 期待動作の明確化（異常時にどうあるべきかを定義する）
- テストデータの設計と管理（洗い出したパターンを実際のデータに落とす）
各ステップの具体的な作業を順に見ていきます。
3-1. 異常パターンの洗い出し
異常パターンの洗い出しには、境界値分析・同値分割法・エラー推測の3手法を組み合わせます。まず境界値分析は、入力値の境界付近でエラーが起きやすいという経験則に基づき、最大値+1・最小値−1・ゼロといった境目の値を狙ってケース化する手法です。
同値分割法は入力を「同じ結果になるグループ」に分け、各グループから代表値を1つ選ぶ手法で、境界値分析と組み合わせると少ないケースで広い範囲をカバーできます。エラー推測は、過去のバグ傾向から「ここは壊れやすい」という共通パターンを見つける手法です。3手法で洗い出した結果はチェックリスト化し、次のプロジェクトでも再利用してください。
この洗い出しは、先の4観点（入力値・状態・環境・競合）と掛け合わせると精度が上がります。4観点で「どこを」見るかを決め、3手法で「どんな値を」試すかを決める、という二段構えにすると、網羅性を保ちながらケース数を管理できます。
3-2. 期待動作の明確化
異常発生時にシステムが返すエラーコード・エラーメッセージ・ロールバック処理を仕様として定義しなければ、テスト実行時に合否を判定できません。異常系テストが形骸化する主な原因は、期待動作が仕様として十分に定義されていないことです。
Webシステムなら、HTTPステータスコードで期待動作を型として定義できます。入力値の不正は400 Bad Request、存在しないリソースは404 Not Found、同時更新の競合は409 Conflict、サーバー内部のエラーは500 Internal Server Errorというように、異常パターンごとに返すべきレスポンスを対応づけます。
期待動作は、判定できる粒度まで具体化してください「何らかの不具合が起きた場合、エラーを表示する」ではテスト担当者が合否を判断できません。「入力値が最大長を超えた場合、400 Bad Requestと『○文字以内で入力してください』というメッセージが返ること」と書けば、そのままテストの合否基準になります。
3-3. テストデータの設計と管理
異常系テスト用のデータは、正常系テストデータとは別に管理します。不正値・境界値・NULL・巨大文字列といった異常系のデータを正常系データと混在させると、どれが正常でどれが異常かの区別が曖昧になり管理が煩雑になります。
データは一度作って終わりにせず、システム改修や機能追加のたびに更新してください。仕様が変わったのにテストデータが古いままだと、テストは通っても実態を検証しておらず、形骸化します。
テスト設計が属人化しやすく工数もかさむ場合は、標準テスト観点1,000件を体系化したバルテスのテスト設計支援を利用すると、観点の抜け漏れとデータ管理の負担を同時に抑えられます。
異常系テストの優先順位はどう決める？ リスクベースの判断基準
すべての異常パターンをテストすることは、工数の面で現実的に不可能です。だからこそ、影響度と発生確率でリスクを評価し、高リスクの領域から着手するのが、限られた工数での妥当な判断です。
ここでは、優先度を決めるリスクマトリクスの使い方と、単体・結合・システムの各テストフェーズでの分担方法を解説します。
4-1. 影響度×発生確率のマトリクスで優先度を決める
優先順位は、異常の影響度（障害が起きたときの被害規模）と発生確率（その異常がどの程度起き得るか）の2軸で評価します。影響度は、データ破損や情報漏洩を「高」、ユーザー体験の低下を「中」、軽微な表示崩れを「低」と分けます。
発生確率は、日常的に起き得るものを「高」、特殊条件でのみ発生するものを「低」とします。
この2軸で分類すると、着手順が見えてきます。
| 優先順位 | 対象の例 |
| 最優先 | セキュリティ関連の入力、金融・決済などデータ破損を伴う操作 |
| 高 | コアビジネス機能のエラーパス |
| 中 | 境界値、システム間の統合ポイント |
| 低 | レガシー機能のエッジケース |
セキュリティ関連の入力とデータ破損を伴う操作は、影響度が最大になるため最優先で扱ってください。4観点で洗い出した全パターンにこのマトリクスを当てはめ、最優先と高から着手し、どこまでカバーできたかを可視化しながら進めます。
4-2. テストフェーズ別の異常系テストの分担
異常系テストは、単体テストでは入力値の異常を中心に、結合テストでは状態・環境の異常、システムテストでは競合の異常を主に検証します。フェーズごとに担当する観点を分けることで、重複と漏れの両方を最小化できます。
| フェーズ | 主な異常系テスト観点 | テスト手法 | テスト環境 |
| 単体テスト | 入力値の異常（境界値・空値・不正文字） | 関数・メソッド単位のテスト、モック活用 | 開発環境 |
| 結合テスト | 状態・環境の異常（API応答不正・タイムアウト・状態遷移） | コンポーネント間のインターフェーステスト | 結合テスト環境 |
| システムテスト | 競合の異常（同時更新・負荷時の挙動） | 負荷テスト、シナリオテスト | 本番相当環境 |
結合テストのフェーズでは、コンポーネント間のインターフェース上の異常を重点的に扱います。呼び出し先APIが不正なレスポンスを返す、応答がタイムアウトする、といったインターフェースの境界で起きる異常を、この段階で確実に潰しておきます。
フェーズ間で担当スコープを明示的に合意しないと、同じ異常を二度テストしたり、逆にどのフェーズも扱わずに漏れたりします。加えて、一度作ったテストケースも仕様変更で陳腐化するため、フェーズ設計と合わせて定期的な見直しの時期を決めておくと、テストの有効性を保てます。
まとめ
異常系テストは、入力値・状態・環境・競合の4観点で体系的に洗い出し、影響度と発生確率のリスクベースで優先順位を付けて設計します。
この2つを軸にすることで、限られた工数でも本番障害の原因となるテスト漏れを防げます。担当者の勘に頼る洗い出しから、分類と判断基準に基づく設計へ切り替えることが、抜け漏れをなくす近道です。
異常系テストの設計・実行を自社だけで完結させることが難しい場合は、第三者検証の活用も選択肢になります。バルテスは、ISO/IEC/IEEE 29119準拠のテストメソッド「QUINTEE」と標準テスト観点1,000件、導入実績1,300社の知見をもとに、異常系を含む体系的なテスト設計・実行を支援しています。
自社の観点だけでは抜け漏れが不安な場合は、第三者の視点で異常系の網羅性を点検するところから、バルテスのソフトウェアテストサービスに相談してみてください。
