Webアプリの単体テストケースのドキュメントへのまとめ方

Webアプリの開発において、単体テストは欠かせない工程です。
しかし「どのようにテストケースをまとめればよいのか」「どんな形式でドキュメント化すればよいのか」と悩む方も多いのではないでしょうか。

この記事では、単体テストをドキュメントとして整理する方法を解説します。入力値バリデーション、データベース処理、計算処理、API連携、画面表示といった代表的な機能ごとの具体的なテストケース例を表形式で紹介し、効率的にテストを管理するためのドキュメント化手法もまとめました。

テストケースを作成する際の基本項目

テストケースは「どんな状況で、どんな入力をしたら、どうなるべきか」を整理したものです。
ドキュメントとしてまとめる際には、以下の項目を入れると分かりやすくなります。

この形式を守ることで、誰が見ても理解できるテスト仕様書を作ることができます。

ユーザーが入力するデータは、必ずしも正しい形式とは限りません。バリデーションテストでは正常系・異常系をセットで確認することが重要です。

テストID	テスト対象	前提条件	入力値	期待結果	備考
VAL-001	会員登録フォーム	ユーザー未登録	user@example.com	正常に登録できる	正常系
VAL-002	会員登録フォーム	ユーザー未登録	userexample.com	「不正なメール形式」エラー	異常系
VAL-003	会員登録フォーム	ユーザー未登録	user@@example.com	「不正なメール形式」エラー	異常系

登録・更新・削除といった処理が正しくデータベースに反映されるか確認します。

テストID	テスト対象	前提条件	入力値	期待結果	実行結果	備考
DB-001	ユーザー削除処理	ユーザーID=100が存在	100	該当ユーザーが削除される		正常系
DB-002	ユーザー削除処理	ユーザーID=999が存在しない	999	「該当ユーザーなし」エラー		異常系

料金計算や割引処理などの数値ロジックは境界値を含めてチェックすることが大切です。

テストID	テスト対象	前提条件	入力値	期待結果	実行結果	備考
CAL-001	割引計算関数	価格5000円	価格=5000, 割引率=10%	4500円		正常系
CAL-002	割引計算関数	価格5000円	価格=5000, 割引率=150%	エラー		異常系

外部サービスとのやり取りは成功だけでなく失敗時の動作も確認が必要です。

テストID	テスト対象	前提条件	入力値	期待結果	実行結果	備考
API-001	天気API呼び出し	API稼働中	正常リクエスト	JSONレスポンスが正しく整形される		正常系
API-002	天気API呼び出し	APIダウン	正常リクエスト	「サービス利用不可」エラー		異常系

UIの切り替えが正しく動作するかを確認することも単体テストの一部です。

テストID	テスト対象	前提条件	入力値	期待結果	実行結果	備考
UI-001	トップページ表示	ユーザーがログイン済み	セッションあり	「マイページ」リンクが表示される		正常系
UI-002	トップページ表示	ユーザーが未ログイン	セッションなし	「ログイン」ボタンが表示される		正常系

テストケースを作成した後は、どのように管理するかが重要です。

ExcelやGoogleスプレッドシート
- 小規模なプロジェクトなら表形式で十分。
- フィルタや条件付き書式を使えば実行状況も追いやすい。
テスト管理ツール
- TestRail、Zephyr、qTest、Redmineなど。
- 複数人で進行管理する場合や大規模開発で有効。
自動テストとリンク
- PHPUnit、Jest、Pytestなどのフレームワークに落とし込み、CI/CDに組み込む。
- 「テスト仕様書＝実行可能コード」として維持できる。