1 境界値テストの概要
1.1 定義と目的
境界値テストとは、入力値や内部状態が「境界（限界値、分岐点、許容範囲の端）」に到達したときに、仕様どおりの振る舞いを行うことを検証するソフトウェアテスト手法である。通常は境界そのもの、境界の直前、境界の直後といった複数点をテストケースとして設計し、境界周辺で起きやすい実装上の取り違えや例外処理漏れを早期に検出する。
目的は、条件分岐の欠落、範囲判定の誤り、境界付近での丸めや変換による挙動差、数値計算に伴う過不足などを、少ないケース数で効率よく見つけることにある。仕様として上限・下限、段階（ステップ）、長さ、分量、許容誤差が明示されている領域ほど、網羅性と再現性が高まりやすい。
1.2 対象となる「境界」の種類
1.2.1 数値範囲の境界
数値範囲における境界は、最小値・最大値、または区間の両端で表される。たとえば「0以上100以下」のように条件が定義される場合、境界値（0、100）とその直近（許容される最小未満の値、最大を超える最小値）を中心に確認する。分割された区間がある場合は、各区切り点について同様の観点を持つ。
加えて、入力値が計算結果により間接的に境界へ到達する場合も対象となる。例えば、税額や割引後の金額が上限に触れるケースなど、入力から算出された値が分岐点に入る状況を想定することが重要である。
1.2.2 文字列長や件数の境界
文字列長や件数の境界は、格納・送信・処理の制限として仕様に現れやすい。例として、最大文字数、最小文字数、上限件数、バッチサイズの上限などが挙げられる。境界値そのもの（ちょうど最大長、ちょうど最大件数）に加え、直前（最大長-1、最大件数-1）と直後（最大長+1、最大件数+1）を確認することで、バッファ処理、切り詰め、検証ロジックの誤りを検出できる。
また、文字種による取り扱いの違いも境界の一部として扱うことがある。コードポイント数、バイト長、正規化後の長さなど、システムが用いる単位が異なると、境界判定の意図がずれるためである。
1.2.3 列挙値・状態遷移の境界
列挙値・状態遷移の境界は、取り得る値や状態の集合の端、あるいは遷移の分岐点として現れる。たとえば、状態が「開始」「処理中」「完了」「失敗」のように並び、許可される遷移が定義されている場合、「処理中から完了へ移行できる条件」や「失敗へ移行できる条件」の境界を点検する。
列挙値では、最小の列挙や最大の列挙、未定義値（存在しない数値、将来拡張を見越した未知値）が境界として重要になる。状態遷移では、遷移の可否に関わるガード条件の境界を確認し、例外時の扱い（無視、エラー、リトライ可能性）まで含めて観測するのが一般的である。
1.3 他手法との関係
1.3.1 同値分割との組み合わせ
同値分割は、入力空間を「振る舞いが同じになる範囲」に分け、代表値を選ぶ設計手法である。境界値テストは、同値分割で代表値を選んだあとに、境界周辺へ追加ケースを設けて不確実性を減らす目的で組み合わせられることが多い。
典型的には、同値クラスの中心だけでは発見しにくい「境界での分岐」や「境界判定の取り違え」を、境界値側の追加ケースで補完する。結果として、網羅性を高めつつ、ケース数の増加を抑える設計が可能になる。
1.3.2 因果関係ベーステストとの違い
因果関係ベーステストは、入力や前提条件から期待される結果までの因果関係を整理して網羅する考え方である。境界値テストが境界という“座標”に焦点を当てるのに対し、因果関係ベースでは「条件の組合せ」と「その結果」を主軸にする点が異なる。
両者は排他的ではない。境界値テストは条件分岐の境界周辺を手厚くするために有効で、因果関係ベースは複数条件の組合せで生じる論理的な経路漏れを減らすのに向く。実務では、仕様の表現形式に応じてどちらを主にし、もう一方を補助として用いることが多い。
2 テスト設計の基本
2.1 境界値の選び方
2.1.1 直前・境界・直後の考え方
境界値テストの基本は、境界そのものと、その直前・直後の値を用意することである。下限がLで上限がUのように区間が与えられるなら、少なくとも次の観点を作る。
- 下限Lが受理されること（境界値の正当性）
- 下限の直前（Lより小さい側）が拒否されること、あるいは別処理されること
- 上限Uが受理されること（境界値の正当性）
- 上限の直後（Uより大きい側）が拒否されること、あるいは別処理されること
直前・直後の具体値は、離散的な入力か連続的な入力かで決まる。たとえば整数入力なら「L-1」「U+1」が自然な直近になる。一方、実数で小数点以下が意味を持つ場合は、表現可能な刻み幅（フォーマット、丸め規則）に合わせて“最も近い側”を選ぶ必要がある。
2.1.1.1 下限側のテスト観点
下限側では、「受理される最小」「拒否される最小未満」「境界に到達したときの副作用」を確認する。受理される最小値では、保存・計算・表示のいずれにも同じ定義が適用されるかを見ていく。
拒否される側では、エラーメッセージ、例外の種類、ステータスコード、要求データの扱い（部分的な反映が起きないか）など、仕様に沿った挙動を観測項目として持つことが重要である。下限の値が後続処理の前提になる場合は、その前提が崩れたときの防御的挙動も対象になる。
2.1.1.2 上限側のテスト観点
上限側では、「受理される最大」「拒否される最大超過」「境界超過時の抑制メカニズム」を検証する。受理される最大値では、上限での丸め、桁あふれの回避、配列やバッファの境界における安全性などを点検する。
上限超過時は、入力を切り詰めてしまうのか、明確に拒否してエラーにするのか、といった仕様の分岐を確認する。さらに、上限値が閾値として後段の計算に影響する場合、境界超過がもたらす派生結果（課金、請求、承認フローなど）への波及を観測しておくと、実装の取り違えが見つかりやすい。
2.1.2 マージン（許容幅）の扱い
許容幅が仕様に含まれる場合、境界の扱いは単純な端点検査だけでは不十分になり得る。たとえば「±0.01以内」や「許容誤差E」などがある場合、中心値からの距離が境界に達する点を境界として扱う。
整数の範囲ではなく浮動小数点の領域では、表現誤差や丸め規則により、見かけ上の直近が実際には別の値になっていることがある。よって、テストデータは仕様に対応する“入力形式”（小数の桁数、計算前の丸めの有無）とセットで設計し、観測側も同じ正規化ルールで比較するのが基本となる。
2.2 テストケースの粒度と優先度
2.2.1 重要度に基づく選定
境界値テストは効果が高い一方で、対象となる境界が多いとケースが膨らむ。そこで重要度に基づいて選定する。重要度は、障害が与える影響範囲（安全性、金銭、データ保全、利用者体験）、頻度（どれくらい遭遇し得るか）、修正コスト（検出時の対応が容易か）などで評価する。
上限・下限に触れる確率が高い入力経路、または境界が複数の部品へ波及する箇所（入力検証→永続化→再計算→表示）を優先すると、少ないケースで不具合を回収しやすい。加えて、過去に欠陥が出た領域は優先度を上げると効率が良い。
2.2.2 自動化を前提にした設計
自動化を前提とする場合、境界値の定義をコードや設定として管理可能にし、期待結果の判定も機械的に行える形に落とし込む必要がある。例えば、受理の場合のレスポンス項目、拒否の場合のエラーコード、ログの出力条件などを形式知にする。
また、自動化では再利用性が重要になる。境界値の生成ルール（直前・境界・直後の算出）、境界の単位（長さの定義、数値の丸め規則）を共通化し、仕様変更時にテストの更新が局所化される設計にすると運用負担が小さくなる。
3 よくある失敗パターン
3.1 範囲チェックの不備
3.1.1 「含む／含まない」の取り違え
範囲判定で頻発する誤りは、「境界を含むか」を取り違えることである。仕様が「0以上」の場合に「0より大きい」として扱ってしまう、あるいは「100未満」を「100以下」と解釈するなどの例がある。これらは境界値テストで発見しやすい。
さらに、異なる場所で別の解釈が混在することもある。入力受付の層では含む定義なのに、後段の計算層では含まない定義になっているなど、整合性の欠如が潜むと、境界での不一致が顕在化する。
3.1.2 条件分岐の順序依存
条件分岐の順序が結果を左右する実装もある。たとえば「if（範囲A）… else if（範囲B）…」の設計で、範囲Aと範囲Bが重なっていたり、境界が条件の切り替え点にあると、意図した分岐に到達しないことがある。特に「境界に対してどちらの条件が先に評価されるか」が問題になる。
境界値テストでは、境界を含む／含まないに加えて、重なりがあり得る範囲設計の有無を意識し、順序に依存する経路を選ぶことで検出率を高められる。
3.2 型・単位・丸めの問題
3.2.1 型変換による値の変形
入力が数値として取り込まれるまでの過程で、型変換が行われる場合がある。文字列から整数への変換、整数から小数へのキャスト、あるいは別形式（符号付き・符号なし、桁数制限付き）への変換で値が変わり、境界判定が意図と一致しない。
たとえば、上限を超えたはずの値が変換後に縮退して境界内として扱われる、逆に境界のはずが切り下げられて拒否されるといった事象が起こり得る。境界テストでは入力の表現形式と、内部表現の変換点をセットで考えることが有効である。
3.2.2 単位換算と丸め誤差
単位換算（メートルからセンチ、秒からミリ秒など）が挟まる場合、境界が換算後の値にどのように現れるかが問題になる。丸め規則（切り捨て、四捨五入、銀行丸めなど）によって、境界の直近が別の側に寄ることがある。
また、丸め誤差が繰り返し計算で累積し、境界判定の時点でズレが発生することもある。したがって、境界に触れるケースでは、変換後の期待値がどのように丸められるべきかを明確にし、それに基づいて観測結果を定めることが必要になる。
3.3 実装差による境界逸脱
3.3.1 サーバとクライアントの差
境界検証がクライアント側とサーバ側の双方に存在する場合、実装差により挙動が揃わないことがある。クライアントでは「入力段階で弾く」一方、サーバでは「別の閾値で検証する」など、境界の定義が一致していないケースがある。
さらに、クライアントの型（JavaScriptの数値表現など）とサーバの型（整数演算、浮動小数点の精度）で挙動が変わることもある。境界値テストは、両側の経路を通した統合確認として設計すると、差異の検出に効果がある。
3.3.2 API仕様と実装の不一致
API仕様書に示された境界と、実装で実際に用いられている検証条件が一致しないこともある。仕様が「最大長はN」と書いているにもかかわらず、実装が別の単位で長さを数えている、あるいは例外時のステータスが異なるなどが起こり得る。
この場合、境界値テストは仕様と実装のギャップを可視化する手段になる。観測項目を応答コード、エラーメッセージ、データの保存可否などに分解し、仕様書の記述と突合することで不一致の位置を特定しやすい。
4 実施と運用
4.1 テストデータの準備
テストデータは、境界を構成する値そのものと、直近の値、ならびに拒否時の期待挙動を担保できる入力形式で準備する。数値では桁数や符号、文字列ではエンコーディングや長さの定義、状態では遷移に必要な前提データを含める。
また、境界値テストでは“境界の定義”をデータに埋め込むだけでなく、テストの根拠となる仕様（上限・下限、許容幅、丸め規則）をメタ情報として保持することが望ましい。これにより、後から理由付きで更新しやすくなる。
4.2 実行手順と観測項目
4.2.1 正常系の期待結果
正常系では、受理されるべき境界値が入力として成立し、処理結果が仕様どおりになることを確認する。例えば、保存が行われるか、計算結果が期待範囲に収まるか、返却値の形式（桁、単位、表示）にズレがないかを観測する。
加えて、境界付近では副作用が起きやすい。上限でのログ出力、キャッシュ更新、上限到達をトリガーにした後処理など、仕様に含まれる動作がある場合はそれも正常系の一部として扱う。
4.2.2 異常系の期待結果
異常系では、拒否されるべき入力に対して正しいエラー処理が行われることを確認する。観測の中心は、エラーコード、HTTPステータス、例外の種別、メッセージの内容、入力データの反映有無、そしてログに残る情報の整合性である。
境界逸脱の種類が複数ある場合（値が小さすぎる、値が大きすぎる、形式不正、許容誤差外など）、それぞれの分類に対応する期待結果を分けると、誤った統一処理（すべて同じエラーにしてしまう等）も検出しやすい。
4.3 再現性と回帰テスト
4.3.1 失敗時の切り分け観点
失敗が起きた場合、境界値そのものの解釈、変換と丸め、範囲判定の実装、さらに分岐の順序や例外処理の経路を順に切り分ける。たとえば同じ境界の値でも、経路（クライアント起点か、サーバ起点か、バッチ経由か）で結果が違うなら、どこで定義が変わっているかを疑う。
また、再現性の確保として、環境依存要因（タイムゾーン、ロケール、精度設定、設定値の違い）を記録する。境界判定が設定値や外部サービスの応答に依存する場合、失敗の再現に必要な条件をテストログに残しておくと後の修正が速くなる。
4.3.2 境界値の変更管理
仕様変更により境界が変わると、関連テストも更新が必要になる。変更管理では、境界値の定義を一元化し、変更箇所と影響範囲（どのテストケースが対象か、どのモジュールに影響するか）を明確にするのが重要である。
運用上は、テストケースの自動生成に必要な仕様データをバージョン付きで保持し、変更履歴と期待結果の差分が追えるようにする。これにより回帰テストの信頼性が向上し、境界周辺での品質劣化を継続的に抑えやすくなる。