単体テストケースはどれくらい作るべき？考え方と実務での目安

Webアプリやシステム開発で避けて通れない「単体テスト」。
しかし、実際にテストケースを作ろうとすると「どのくらいの量を用意すればいいのか？」という壁にぶつかります。テストを増やせば網羅性は上がりますが、その分コストも膨らみます。一方で減らしすぎれば、見落としが多くなり品質を損ねるリスクがあります。

そこで本記事では、単体テストケースの「量の考え方」をわかりやすく整理し、実務での現実的な目安を紹介します。正常系・異常系・境界値の考え方や、リスクベースでの優先順位付けなど、バランスを取るためのヒントを具体例を交えて解説していきます。

単体テストとは？なぜ量が問題になるのか

単体テストとは、プログラムの最小単位（関数やメソッド）が仕様通りに動作するかを確認するテストです。

テストケースの量が問題になるのは以下の理由からです。

  • 入力値の組み合わせが膨大になる
  • 正常な動作だけでなく、異常パターンも考える必要がある
  • 境界値や例外処理まで含めると無限に近いケースが発生する

つまり「やろうと思えばキリがない」のが単体テスト。だからこそ、どこまでやるのかを合理的に決める必要があります。

基本は「正常系＋異常系」を押さえる

テストケースの最小単位は、正常に動作するケース と 異常な入力をした場合のケース の2つです。

例：メールアドレス入力フォーム

  • 正常系
    • user@example.com → 登録できる
  • 異常系
    • userexample.com（@なし） → エラーになる
    • user@@example.com（@2つ） → エラーになる

このように、1つの機能に対して「成功パターン」と「代表的な失敗パターン」を用意するのが最低限です。

境界値テストを忘れない

入力値の上限や下限など、境界値 はバグが発生しやすいポイントです。

例：割引率の入力チェック

  • 割引率 = 0% → 正常（無料にならない）
  • 割引率 = 100% → 正常（無料になる）
  • 割引率 = 101% → エラー（仕様外）

境界値を1つでも見落とすと、重大な不具合につながりかねません。そのため「正常＋異常」に加えて「境界」を意識することが重要です。

ビジネスロジックに依存する部分を優先

単体テストを作る際は、すべてを均等にテストする必要はありません。
重要なのは「バグが出ると影響が大きい処理」に多めのテストケースを割くことです。

  • 優先度が高い機能例
    • ユーザー認証
    • 決済や料金計算
    • 在庫管理や受発注処理
  • 優先度が低い機能例
    • 一部のUI切り替え表示
    • 補助的なメッセージ表示

リスクが高いところに重点を置き、リスクが低い部分は最低限にするのが現実的です。

カバレッジを目安に考える

テストケースの量を数値で判断する方法の一つが コードカバレッジ です。

  • ステートメントカバレッジ
    → 実行された命令文の割合
  • 分岐カバレッジ
    → if文や条件分岐の全パターンを網羅した割合

現場では、70〜80%程度のカバレッジ を目安にすることが多いです。
100%を目指すと工数が爆発するため、コストに見合う範囲で設定するのがポイントです。

実務でのテストケース量の目安

プロジェクトの規模や重要度によって、単体テストの量は変わります。

  • 小規模アプリ（個人開発や社内向けツール）
    • 機能ごとに3〜5ケース程度
    • 正常系1、異常系2〜3
  • 中規模〜大規模アプリ（業務システムや商用サービス）
    • 重要機能は10〜20ケース以上
    • 境界値や例外も積極的に網羅
  • 高リスク領域（金融、医療、認証系）
    • 場合によっては数百ケース規模
    • テスト管理ツールや自動テスト必須

リスクベースで取捨選択する

テストケースを際限なく増やすのではなく、リスクベースのアプローチ が有効です。

  • バグが発生したら 金銭的損害 につながる部分 → テスト厚め
  • バグが出ても ユーザー体験の低下程度 にとどまる部分 → 最低限

これにより「品質」と「コスト」のバランスを保つことができます。

ドキュメント化のポイント

テストケースを増やしていくと、管理が課題になります。ドキュメント化の方法としては次のような手段があります。

  1. ExcelやGoogleスプレッドシート
    • 小規模なら十分対応可能
    • 表形式で「テストID・対象・入力・期待結果」を整理
  2. テスト管理ツール
    • TestRail、Zephyr、Redmineなど
    • 大規模開発や複数人での進行に有効
  3. 自動テスト化
    • PHPUnit、Jest、Pytestなどに落とし込み、CI/CDに組み込む
    • 「テスト仕様書＝実行可能コード」として維持できる

まとめ

単体テストケースの量には「正解の数」はありません。
しかし次の基準を意識すれば、現実的で効果的な範囲を設定できます。

  • 正常系＋異常系＋境界値 を最低限押さえる
  • リスクの高い機能ほど多めにテストする
  • 70〜80%のカバレッジを目安 にする
  • Excel → テストツール → 自動化 と段階的に管理方法を進化させる

やみくもに増やすのではなく、限られたリソースの中で「重要なところに集中する」ことが、単体テストの効率化と品質向上につながります。

タイトルとURLをコピーしました