正常ケースだけで十分？｜テスト設計・境界値・網羅率・回帰テスト

一度正しい金額が出れば、注文機能は正しいといえるのでしょうか。数量の上限、会員割引の境目、不正な入力、外部サービスとの連携は別の条件です。何を確かめるかと、正しい結果を先に決めます。

事例：数量と会員区分から注文金額を計算する

商品は一個100円です。数量は1〜99の整数だけを受け付けます。会員が10個以上買うと商品金額を10%割引し、会員以外や10個未満は割引しません。税・送料はこの金額には含めません。

単体の金額計算関数には、整数の数量と真偽値の会員区分を渡します。入力欄の空白や文字列から整数へ変換する処理は別の対象です。入力の型と業務上の範囲を混ぜないようにします。

同値分割で、まず入力のまとまりを作る

同じ種類の動作を期待する入力をグループへ分け、その代表を選びます。数量なら、0以下、1〜99、100以上を分けます。会員割引を扱うなら、有効範囲の中も1〜9と10〜99へ分ける必要があります。

1. 有効クラス

   仕様が受け付ける値のまとまりです。割引の条件でさらに分ける場合があります。

2. 無効クラス

   仕様が拒否する値のまとまりです。下限未満と上限超過などを分けます。

3. 期待結果

   受付・拒否だけでなく、金額、保存、外部呼出し等の必要な観測を定めます。

同じ範囲の代表を何件も増やすより、違う動作が必要な範囲を漏らさないことが先です。ただし、代表一件だけでグループの全入力の正しさを証明できるわけではありません。

境界値は、境目の直前・直後も使う

数量の受付境界には0・1・2と98・99・100を選べます。会員割引の境目には、会員の数量9・10・11を追加します。どの境界を対象に、どの方式で値を選ぶかを記録します。

例えば「数量99を受け付ける」が「99未満を受け付ける」へ変わっていても、数量1と10だけのテストでは気付きません。境界値は<と<=などの取り違えを見つける助けになります。

複数の不正条件を一つのテストへ詰めると、どの入力検証で拒否されたか分かりにくくなります。他の条件を有効にして、一つの無効クラスを検証する方法も使います。

掲載コードの二つの判定を追う

def quote(quantity, member):
    if quantity < 1 or quantity > 99:
        return {"status": "invalid", "price": None}
    subtotal = quantity * 100
    if member and quantity >= 10:
        return {"status": "ok", "price": subtotal * 9 // 10}
    return {"status": "ok", "price": subtotal}

ここでは二つのifの真・偽という四つの判定分岐を数えます。数量0は最初の真、数量10の会員は最初の偽と次の真、数量1の非会員は次の偽を通ります。この三件で四つの判定結果を通れます。

分岐を全部通っても、全入力や全経路の検証ではありません。最初のorの「数量>99」が真になるケースは、この三件にはありません。境界値や仕様の組合せを別に加えます。

命令・分岐・条件の網羅率を読み分ける

命令網羅は対象の実行文を通った割合、分岐網羅は対象の分岐を通った割合です。条件網羅は、複合判定の個々の条件が真と偽を取るかを扱います。分母の定義と計測対象を明記して比較します。

member and quantity>=10では、memberが偽なら右側を評価しない言語もあります。判定全体の真・偽だけを通っても、個々の条件をすべて実際に評価したとは限りません。

複数の条件が真偽を取るだけでは、判定結果が両方にならない組合せもあります。条件網羅と分岐網羅を同じ意味で使わず、必要なら条件の組合せや影響も確認します。

期待結果を、実装と独立に作る

数量10の会員なら10×100×0.9=900円です。仕様からこの期待値を作り、実装の出力と比べます。実装と同じ計算式を別の場所へコピーするだけでは、同じ誤りを見逃す場合があります。

拒否ケースなら不正の結果に加え、注文や支払が作られていないことも対象になります。エラー表示だけ合っていても、裏で請求していたら要件を満たしません。どこまでを対象とするテストかを決めます。

時刻、外部応答、データの初期状態を固定すると再現しやすくなります。一方、外部サービスを置き換えるテストだけでは、実際の接続や項目の対応付けまで確認したことにはなりません。

単体から結合へ、確認対象を広げる

金額関数の単体テストでは、入力と戻り値を確認します。結合テストでは、注文から渡す数量・会員区分、金額の保存、支払APIへ渡す金額、失敗時の扱いなどを確かめます。

外部APIがタイムアウトした場合、実行されなかったのか、実行後の応答だけ失ったのかを区別できない場合があります。二重請求を避ける識別子と再試行の設計も、連携のテストで確認します。

バグ修正後は、どのテストを戻す？

修正確認では、元の不具合を再現する条件で直ったことを確かめます。回帰テストでは、修正によって他の正常な動作を壊していないかを確認します。この二つは対象が違います。

数量100を受け付けていた不具合なら、100が拒否されることに加え、99は引き続き受け付けるか、会員10の割引は維持されるかなどを確認します。影響範囲に合わせて選びます。

合格件数だけで十分と判断せず、どの仕様・リスク・分岐を検証したかを残します。網羅率100%でも、実装されていない要件、誤った期待値、同時実行や外部連携の条件まで自動で保証されません。

演習1：同値クラス

条件：数量は1〜99の整数だけ有効です。

問い：数量を受付条件で三つへ分けてください。

解答例：0以下、1〜99、100以上です。

根拠：下限未満、有効範囲、上限超過で期待動作が変わります。

誤答の理由：有効値だけを小・中・大に分けても、拒否する入力の確認が不足します。

演習2：割引の境目

条件：会員は数量10以上で10%割引されます。

問い：境目を確かめる三つの数量と期待金額を示してください。

解答例：9で900円、10で900円、11で990円です。

根拠：9は割引なし、10と11は商品金額の90%となります。

誤答の理由：数量10だけでは、9にも誤って割引していないかを確認できません。

演習3：判定分岐の数

条件：掲載関数の二つのifの真・偽を分母にします。数量0と会員10の二件を実行しました。

問い：四つの判定分岐のうち、いくつを通りましたか。

解答例：最初の真・偽と次の真、計3個で75%です。

根拠：不正数量では次のifへ進まず、会員10では割引側へ進みます。

誤答の理由：テストが二件なので50%という計算は、件数と分岐数を混同しています。

演習4：分岐網羅の限界

条件：数量0、会員10、非会員1で二つのifの四結果を通りました。

問い：上限検証も十分ですか。

解答例：十分ではありません。99の受付と100の拒否などを追加します。

根拠：数量>99が真になる条件は、この三件に含まれていません。

誤答の理由：分岐網羅100%だから入力境界もすべて正しいと判断するのは不十分です。

演習5：期待値の作り方

条件：数量11の会員について、実装の戻り値をそのまま期待値として保存します。

問い：何が不足しますか。

解答例：仕様から独立に作った期待値990円との比較が不足します。

根拠：実装の誤った結果を期待値にすると、同じ誤りを合格として扱います。

誤答の理由：テストを何回繰り返しても、誤った期待値そのものは正しくなりません。

演習6：修正と回帰

条件：数量100を拒否するよう修正しました。

問い：修正確認と回帰の例をそれぞれ挙げてください。

解答例：修正確認は100の拒否、回帰は99の受付や会員10の900円を確認します。

根拠：不具合の条件と、影響を受ける既存の正常動作の両方を調べます。

誤答の理由：100だけを確認して完了すると、上限を99未満に変えた等の新たな不具合を見逃します。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

ISTQB：テスト技法・網羅率・修正確認と回帰

Python公式：期待結果とテストの構成

関連テーマを続けて学ぶ

要求と入力検証

同時実行の失敗条件