2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

テストtips

2
Last updated at Posted at 2026-01-27

はじめに

とある現場でAPI/画面1機能の単体テストで100項目ほど書いた経験があり、実務の中で人によってテストの観点や定義がチグハグだと感じたので、学習がてら以下についてまとめてみました。

  • テストケースの定義
  • 単体テスト・結合テストの役割
  • テストケース設計の正しい考え方
  • 実務で評価される書き方

1. テストケースとは何か

テストケースとは、

特定の条件下で、
ソフトウェアが期待通りに動作するかを確認するための
入力・操作・期待結果を定義したもの

です。

重要なのは、

  • 誰が実行しても同じ結果・判断になること
  • なぜそのテストが必要か説明できること

2. 単体テストと結合テストの役割

単体テスト(Unit Test)

  • 対象:機能・モジュール・API単体
  • 目的:ロジックが仕様通りかを確認
  • 観点:
    • 入力値チェック
    • 境界値
    • 異常系
    • 戻り値・状態変化

点の確認


結合テスト(Integration Test)

  • 対象:複数機能の連携
  • 目的:機能同士が正しくつながるかを確認
  • 観点:
    • 状態遷移
    • データ連携
    • 業務フロー
    • エラー後の復帰

線の確認


3. テストケース設計の基本原則

原則① 全数網羅は不要

入力条件や組み合わせをすべて試すことは、
理論上も実務上も非現実的です。

代わりに以下を用います。

  • 同値分割
  • 境界値分析
  • 代表値選択

原則② 観点は「壊れ方」から考える

テストは仕様のなぞり書きではありません。

考えるべきは、

  • 通ってはいけないものが通らないか
  • 失敗時に状態が壊れないか
  • 想定外入力で落ちないか

原則③ 単体と結合の責務を分ける

  • 単体で見るべきものを結合に持ち込まない
  • 結合でしか見られない流れを単体に詰め込まない

責務分離がテスト設計力


4. テストケースの基本構成

実務で一般的な構成は以下です。
【テストID】
【テスト観点】
【前提条件】
【入力値】
【操作】
【期待結果】

特に重要なのは、
期待結果を具体的に書くこと


5. 単体テストの正しい考え方

単体テストで必ず確認する観点

  • 正常系(最小限)
  • 必須項目未入力
  • 不正形式
  • 境界値
  • 異常系(存在しないIDなど)

ケース数の目安(1タスク)

  • 5〜15ケース程度

少なすぎると観点不足、多すぎると責務過多になります。
※ 機能の複雑度により増減する


6. 結合テストの正しい考え方

結合テストで確認すべき内容

  • 業務フローが成立するか
  • 状態が正しく引き継がれるか
  • エラー後に復帰できるか
  • データの一貫性が保たれるか

ケース数の目安

  • 単体テストより少なくてよい
  • 代表的な正常ルート+事故りやすい分岐

7. チェックボックス・検索系の考え方

全組み合わせ網羅は原則不要

チェックボックスが n 個ある場合、
組み合わせは 2ⁿ − 1 通りになります。

これは単体テストの責務を超えます。

代表ケースで十分

  • 条件なし
  • 単一指定
  • 複数指定(代表)
  • 全指定

ロジックが成立することを確認するのが目的
※ 排他・依存関係がある場合は例外的に増やす


8. 全網羅しない場合は方針を書く

全網羅しない場合、理由を明示します。
ーーーーーーーーーーーーーーーーーーーーー
条件の組み合わせは指数的に増加するため、
本テストでは代表的なケースを用いて
ロジックの正当性を確認する方針とした。
ーーーーーーーーーーーーーーーーーーーーー

これだけでレビュー耐性が大きく向上します。


9. 良いテストケースの記述例

【テスト観点】
未ログイン状態で誤った認証情報を入力した場合、
ログインできず、認証情報が発行されないこと

【前提条件】
未ログイン状態

【操作】
メールアドレスと誤ったパスワードを入力しログイン実行

【期待結果】
・エラーメッセージが表示される
・認証情報が保存されない
・ログイン画面に留まる


10. まとめ

  • テストケースは量ではなく説明力
  • 単体は点、結合は線
  • 全網羅しないなら理由を書く
  • 「壊れ方」を想像できるテストが強い

おわりに

テストケースは、
コードを書く力以上に「考える力」が表れる成果物です。

「なぜこのテストが必要なのか」を説明できることが、
実務で信頼されるエンジニアの条件です。

参考

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?