システムテストとは？Webアプリのテスト仕様書の書き方を具体例で解説

「登録しました」と表示された。でも、一覧に戻ると記録がない。メソッドごとのテストに合格していても、利用者が操作する一連の流れで、このような不具合が起こることがあります。

システムテストでは、組み上がったアプリ全体が要件どおりに動くかを確認します。この記事では、学習記録アプリを例に、要件をテストケースへ分け、事前条件・入力値・操作手順・期待結果をテスト仕様書に書くところから、結果の記録まで具体化します。

本記事は、Schoo「Java入門 中級」第9回「Webアプリケーション設計演習」に対応するステップアップ学習記事です。受講や配布プログラムを前提にしない、テスト設計の記入例です。画面やデータは説明用の例であり、実行済みのテスト結果ではありません。

システムテストとは？利用者の操作とアプリ全体の結果を確認する

例えば登録機能では、ブラウザから送った値がServletへ届き、Modelで入力を確認し、DAOを通してDBへ保存され、JSPで結果が表示されます。Modelは業務上のルールや処理を扱う部分です。単に各部品が動くかではなく、そのつながりを含めて、利用者の目的を満たすかを確かめます。

確認の範囲	このアプリでの例
単体テスト	学習時間を確認する処理が、0を不正と判断するか。
結合テスト	ModelからDAO・DBへ処理がつながり、指定した記録が保存されるか。
システムテスト	ログインした利用者が画面で登録し、自分の一覧で正しい内容を確認できるか。未ログインや入力不備のときも要件どおりか。

「ブラウザを使えば必ずシステムテスト」「システムテストは手動だけ」という区別ではありません。何を対象に、何を確認するかで区別します。ここでは画面から行う機能の確認を中心にしますが、性能・安全性・使いやすさなども、必要な条件を定めて確認します。

既存のJavaの結合テストとは？Model・DAO・データベースの連携を確認する方法は部品間の連携を扱っています。今回は、画面操作から利用者が確認する結果までを対象にします。

例題：今回テストする学習記録アプリ

次の条件は、要件定義とは？Webアプリの具体例で学ぶ、要求の整理と要件の書き方と画面設計とは？Webアプリの画面設計書・画面遷移図の書き方を具体例で解説で決めた例に合わせています。記事を順番に読んでいなくても、以下の条件からテストを考えられます。

要件ID	確認する約束
R-01 ログイン	登録済みの利用者は正しい認証情報でログインできる。不一致ならログイン状態にしない。
R-02 一覧	自分の記録だけを表示する。学習日が新しい順、同日なら登録が新しい順。0件なら「学習記録はまだありません」。
R-03 登録	有効な入力ならログイン中の利用者の記録を1件保存し、「学習記録を登録しました。」と表示する。
R-04 入力エラー	不正な入力なら項目と理由をエラー画面へ表示し、保存しない。登録画面へ戻ると全入力欄は空、カテゴリは未選択。
R-05 未ログイン	一覧表示と登録を許可しない。URLへの直接アクセスや登録リクエストでも、保存せずログイン画面へ案内する。
R-06 ログアウト	ログイン状態を終了する。その後、記録の閲覧・登録には再ログインが必要。

入力項目	有効な条件
学習日	必須。実在する日付で、操作日以前。
カテゴリ	Java・SQL・その他のいずれか。未選択は不可。
学習内容	1〜200文字。空文字・空白だけは不可。
学習時間	1〜480の整数。単位は分。
メモ	任意、500文字以内。空でも登録でき、一覧には「メモはありません」と表示する。

画面番号はS-01がログイン、S-02が一覧、S-03が登録、S-04が登録完了、S-05がログインエラー、S-06が入力エラー、S-07が処理エラーです。編集・削除は今回の機能に含めません。

図解：登録ボタンを押したあとも、保存結果まで確かめる

完了画面だけなら、DBへ保存せずメッセージを表示する不具合を見逃せます。一覧を開き直し、入力した内容が残っているかを確認します。さらに、保存先と所有者が正しいかは、テスト用DBの記録も照合します。

1．テストケースの前に、開始するデータと状態を決める

「登録すると1件増える」とだけ書くと、実行前が何件だったか分かりません。誰が実施しても同じ条件で比べられるよう、共通の初期データD-01を定義します。これはテスト専用の架空データです。

利用者	初期状態D-01
1001：田中	記録101と102の2件。テスト専用パスワード例はTest-1001!。
1002：佐藤	記録103の1件。テスト専用パスワード例はTest-1002!。
1003：山田	記録0件。テスト専用パスワード例はTest-1003!。

記録・所有者	保存しておく値
101／1001	学習日2026-09-27、Java、Java基礎、30分、メモNULL。登録日時2026-09-27 07:00:00 UTC。
102／1001	学習日2026-09-27、SQL、SQL復習、45分、メモNULL。登録日時2026-09-27 08:00:00 UTC。
103／1002	学習日2026-09-27、Java、例外処理、60分、メモNULL。登録日時2026-09-27 09:00:00 UTC。

この状態なら田中さんの一覧は102、101の順で、103は表示されません。DB全体は3件です。「田中さんの2件」と「全利用者の3件」を混同しないよう、件数には対象範囲を書きます。NULLはメモの値がない状態で、画面には文字列「NULL」ではなく案内文を出します。

パスワード例は検証用だけに使い、実際の運用では使い回しません。前の記事のDB設計どおり、DBには平文ではなく認証用のハッシュ値を保存します。実施記録やスクリーンショットへ実利用者の認証情報を残しません。

共通条件として記録する項目	記入例・注意点
テスト対象の版	アプリのリリース番号やコミットID。要件・画面設計書の版も対応させる。
環境	テスト用URL、DBの識別名、OS・ブラウザとバージョン、画面幅。実施した値を記録する。
日付	この例の操作日は2026-09-28、業務上の日付は日本時間。別日に実施するときは、当日・翌日のテスト値を一緒に置き換える。
データとログイン状態	原則、各ケース開始前にD-01へ復元し、ログアウト状態から始める。担当者・復元方法を決める。
他のテストとの分離	実行中に別の人が同じデータを登録・削除しないようにする。専用DBや利用者を分ける。

復元するのはテスト専用データだけです。本番DBを初期化してはいけません。実施中は前後の結果を保存してから復元します。ST-01の結果をST-02の開始データへ黙って引き継がず、引き継ぐテストなら手順と依存先を明記します。

2．要件を「操作・条件・結果」に分けてケースを作る

R-03の「有効な入力で1件保存する」とR-04の「不正な入力では保存しない」は別の確認です。まず代表的な有効入力D-02を作り、エラーのケースでは、確認したい項目だけを変更します。

D-02：正常登録の入力	値
学習日／カテゴリ	2026-09-28／Java
学習内容	例外処理の復習
学習時間	30
メモ	空欄

1. R-03から「D-02を登録すると、田中さんの記録が1件増える」をST-01にする。
2. R-04から「D-02の時間だけ0へ変えると、理由が表示され、記録は増えない」をST-02にする。
3. R-02から「田中さんで一覧を開くと、佐藤さんの103が含まれない」をST-03にする。
4. 各ケースへ、事前条件と具体的な手順を加える。最後に要件IDを対応させて抜けを確かめる。

時間を0にし、日付も空にしてしまうと、日付の確認だけで処理が止まり、0を拒否できたか分かりません。複数不備の表示順を確認するケースは別に作り、1項目の入力確認と混ぜないようにします。

3．テスト仕様書の記入例：ST-01 正常に登録できる

テスト仕様書は、確認対象だけでなく、実施する人が同じ操作と判定を再現できる文書です。表計算でも管理ツールでも構いません。横に長い表にする代わりに、ここでは1ケースを縦に展開して示します。

項目	ST-01の記入例
対応要件・目的	R-01・R-02・R-03。ログインから登録・再表示までを通して、1件だけ正しく保存されることを確認する。
事前条件	テスト用環境が動作し、D-01へ復元済み。田中2件、佐藤1件、山田0件。ログアウト状態。
入力値	利用者1001とその正しいテスト用パスワードでログインする。登録内容はD-02。
手順1	S-01でログインする。S-02に田中さんの名前と、記録102・101だけがこの順で表示されることを確認する。
手順2	「登録画面へ」を選ぶ。S-03の入力欄は空で、カテゴリは未選択であることを確認する。
手順3	D-02を入力し、「登録」を1回押す。S-04に「学習記録を登録しました。」と表示されることを確認する。
手順4	「一覧へ」を選び、一覧を取得し直す。田中さんの記録が3件で、新しい記録、102、101の順に表示されることを確認する。
画面の期待結果	新しい行は2026-09-28、Java、例外処理の復習、30分。「メモはありません」と表示される。佐藤さんの103は表示されない。
DBの期待結果	実行前の3行は変更されない。user_id1001で入力どおりの行が1行だけ追加され、memoはNULL。田中3件、佐藤1件、山田0件、全体4件になる。
記録する証跡	実施した環境・版・日時・担当者、完了画面、再表示した一覧、DBの実行前後の照合結果。
後片付け	結果を記録してから、テスト専用データをD-01へ復元する。ログアウトする。

DBが採番する新しい記録IDは、必ず104になるという合否条件にしません。重複しないIDが与えられたことを記録し、所有者・学習日・内容などで追加行を照合します。時刻も実際の登録時刻を記録し、例の固定時刻になるとは判定しません。

画面だけで所有者の保存値や行の重複を断定できないときは、テスト用DBを参照できる担当者が、管理ツールなどで照合します。study_logsの全行とuser_id別の行を比べ、増えた行の各列と既存行が変わっていないことを記録します。DB確認手段がないまま、仕様書に「DBも確認済み」とは書けません。

4．テスト仕様書の記入例：ST-02 不正な入力を保存しない

項目	ST-02の記入例
対応要件・目的	R-04。サーバーへ届いた0分の登録を拒否し、エラーを示して保存しないことを確認する。
事前条件	D-01へ復元済み。田中2件、DB全体3件。1001でログインしS-03を表示。0がサーバーへ送信されたことを確認できること。
入力値	D-02の学習時間だけ0へ変更する。他の必須項目は有効なまま、メモは空欄。
操作	上の入力で「登録」を1回送信する。S-06の表示を確認し、続けてDBを実行前のD-01と照合する。
画面の期待結果	S-06へ移り、「学習時間は1〜480の整数で入力してください。」と「登録画面へ戻る」を表示する。登録成功とは表示しない。
DBの期待結果	追加・更新・削除はいずれもない。田中2件、佐藤1件、山田0件、全体3件のまま。記録101・102・103の内容も変わらない。
戻る操作の期待結果	「登録画面へ戻る」を選ぶとS-03。学習日・内容・時間・メモは空、カテゴリは未選択。
実施できない場合	ブラウザが送信を止め、サーバーに届かなかった場合は、その結果だけでST-02を合格にしない。送信経路を用意するまで未実施とし、理由を記録する。

ブラウザの入力制限とサーバー側の拒否は別の確認です。0を送れない画面なら、ブラウザが拒否した記録は別ケースへ残します。サーバー側は、テスト環境で用意した登録リクエストを再送する方法などで確認します。仕様書に実際の送信先URL・POSTなどの送信方法・項目名・値・ログイン状態の引き継ぎ方を添付し、誰が送っても同じ条件にします。

この段階でURLや項目名がまだ決まっていないなら、仮の名前で「実施可能」と扱わず、実装担当者へ確認して埋めます。ブラウザの通信記録で送信値と応答を確認する際も、パスワードやセッションIDは証跡に残さないようにします。

図解：エラー画面が出ても、記録が増えていたら不合格

画面で拒否していても、先に保存してからエラーを出す実装なら、データは増えてしまいます。図はその見逃しを表しています。前の記事で示したDB制約も実装されていれば防げる不正値ですが、画面だけを見て制約が働いたと判断しないことが大切です。

5．他の利用者と未ログインのケースも、手順まで書く

田中さんのデータしか入っていない環境では、「全利用者の記録を表示する」という不具合に気づけません。別の利用者のデータと、記録0件の利用者も初期データへ含めておきます。

ケース・対応要件	事前条件・操作・期待結果
ST-03 利用者の分離／R-02	D-01から1001でログインし、102・101だけを確認する。ログアウト後、1002でログインし直すと103だけになる。田中の101・102は表示されない。DB全体は3件のまま。
ST-04 記録0件／R-02	D-01から1003でログインする。「学習記録はまだありません」と「登録画面へ」を表示する。他人の記録を埋め合わせて表示しない。
ST-05 ログアウト後／R-05・R-06	D-01から1001でログインし、一覧のURLを控える。「ログアウト」でS-01へ。控えた一覧URLを直接開き、新しいリクエストでもS-01へ案内される。記録は表示されない。
ST-06 未ログインの登録／R-05	D-01から1001で登録画面を開き、D-02を入力する。同じセッションを共有する別タブでログアウトし、元の登録画面から送信する。保存せずS-01へ。全体3件のまま。

ST-06では、普通の別ウィンドウやタブがログイン情報を共有することに注意します。「別タブを開いたから未ログイン」ではありません。別タブでログアウトの処理を実行したあとに送信します。別利用者の同時操作を調べるなら、ブラウザプロファイルなどを分けてセッションを分離します。

ST-05は、履歴に残った画面を見るだけではなく、ログアウト後の新しいアクセスが拒否されるかの確認です。ブラウザの戻る操作で機密情報が残らないかも別ケースとして整理し、キャッシュや履歴の表示とサーバーのアクセス制御を混同しないようにします。

6．境界値・初期表示・戻る操作を追加する

ここまでのケースは代表例です。入力ルールや画面の分岐を読み、次のように追加します。表で複数の値を並べている行も、実施時は値ごとに別の結果を残します。「0／1／480／481を確認：合格」の1行では、どの値が未実施か分からなくなります。

ケース・条件	期待結果と確認方法
ST-07a〜d：時間0／1／480／481	毎回D-01へ戻し、D-02の時間だけ変更。1・480は1件保存して全体4件。0・481は拒否して全体3件。サーバーまで届いたことも区別する。
ST-08a〜c：時間未入力／1.5／abc	他の入力は有効。各値を別ケースにし、拒否・理由表示・未保存を確認。数値欄から送れない値は、ST-02と同じく送信方法を別途用意する。
ST-09a〜c：学習日当日／翌日／実在しない日付	例の操作日なら2026-09-28は可、2026-09-29と2026-02-30は不可。後二つは保存しない。存在しない日付の送信方法も記録する。
ST-10a〜d：内容200文字／201文字／空欄／空白だけ	200文字は可、他は不可。試験用文字は「あ」を指定数、空白だけは半角スペース1文字と具体化する。実施時は入力した文字列も保存する。
ST-11a〜c：メモ500文字／501文字／空欄	500文字と空欄は可、501文字は不可。空欄はDBのmemoがNULL、画面が「メモはありません」。
ST-12a・b：カテゴリ未選択／選択肢以外	D-02のカテゴリだけ変更。どちらも拒否・未保存。選択肢以外を送るケースは、テスト用送信手順を用意する。
ST-13：入力途中で一覧へ戻る	D-01でログインし、S-03へD-02を入力するが登録せず「一覧へ戻る」を選ぶ。件数は増えない。再びS-03を開くと入力欄は空・カテゴリ未選択。
ST-14：誤ったパスワード	1001に対して誤ったテスト用パスワードを入力。S-05を表示する。続けて一覧URLへ直接アクセスしてもS-01へ案内され、ログイン状態になっていない。
ST-15：同じ学習日の並び順	D-01で1001の一覧を開く。ともに9月27日だが登録が新しい102が101より先。登録時刻まで同じデータを用意する場合は、DB設計の記録ID降順も別途確認する。

この表の文字数確認は「あ」や半角スペースで条件を固定した例です。絵文字などの数え方まで合意したことにはなりません。要件で未確定なら、数え方を決めてから別のケースを追加します。

入力の全組み合わせを画面から繰り返すことだけが方法ではありません。細かな入力パターンを単体テストで確認し、システムテストでは画面から値が正しく渡り、エラー表示・保存・戻り先までつながるかを確認する、と役割を整理します。ただし下位のテストがあるという理由だけで、重要な利用者操作を省略しません。

7．実施結果は「期待どおり」だけで済ませない

期待結果は実行前に仕様から決めるものです。実際の結果は操作後に観察した事実です。以下は書き方を示す架空の実施例で、このアプリを実際に動かした記録ではありません。未実施の表に、この値を実測値として転記してはいけません。

項目	架空の実施記録：ST-01
対象と実施者	例：アプリ版build-001、設計第1版、テスト環境T-01、D-01使用。2026-09-28 14:00 JST、担当者A。実際の記録ではブラウザ等の環境情報も具体値で残す。
画面の実際の結果	完了メッセージを確認。一覧に「例外処理の復習／30分」が先頭へ追加され、空メモの案内も一致。103は表示されなかった。
DBの実際の結果	田中2→3件、佐藤1→1件、山田0→0件、全体3→4件。追加行のuser_idは1001、学習日2026-09-28、カテゴリJava、内容一致、時間30、memoはNULL。既存3行は不変。
判定と証跡	合格。例：ST-01-complete.png、ST-01-list.png、ST-01-db-before-after.csvを添付。これらの名前は記入例で、記事の配布ファイルではない。

項目	架空の実施記録：ST-02
実際の結果	0がサーバーへ届き、S-06に正しいエラー文言を表示。しかし田中2→3件、全体3→4件となり、0分の行が1件追加された。
判定	不合格。画面の期待結果は満たしたが、「保存しない」を満たしていない。
不具合票	BUG-001「0分の登録でエラー表示後も学習記録が保存される」。対象版、D-01、送信値、再現手順、期待結果、実際の結果、証跡を関連付ける。
原因の扱い	「保存前の確認漏れ」などと推測だけで断定しない。観察した事実を報告し、原因調査は別に行う。

判定は少なくとも、合格・不合格・未実施を区別します。DBへ接続できず確認できなかった場合も「画面は合っていたから合格」とせず、実施不可の理由を残します。仕様が未確定で期待結果が決められない場合は、要確認として設計担当者へ戻します。

BUG-001を直したら、修正版と実施日を記録し、D-01に戻してST-02を再実施します。過去の不合格記録を消さず、再テスト結果を追加します。さらに、修正で正常入力も拒否するようになっていないか、ST-01や1分・480分のケースも確認します。

8．「どこまで確認したか」を要件と対応させる

ケースを何十件書いても、ログアウトの要件が丸ごと抜けているかもしれません。次のように、要件から対応するケースをたどれる表を作ります。

要件	対応するケースの例
R-01 ログイン	ST-01、ST-14：成功と認証情報不一致。
R-02 一覧	ST-01、ST-03、ST-04、ST-15：再表示、利用者分離、0件、並び順。
R-03 登録	ST-01、ST-07b・c、ST-09a、ST-10a、ST-11a・c：正常・境界・任意項目。
R-04 入力エラー	ST-02、ST-07a・d、ST-08、ST-09b・c、ST-10b〜d、ST-11b、ST-12：拒否と未保存。
R-05 未ログイン	ST-05、ST-06、ST-14：直接アクセスと登録リクエスト。
R-06 ログアウト	ST-05、ST-06：ログアウト後も閲覧・保存できない。

要件ごとにケースが1件あるだけで、全条件を満たしたことにはなりません。ケースの有無、実施状況、合否、未解決の不具合を分けて確認します。この対応表は要件の確認漏れを見るもので、コードの実行割合を測るカバレッジとは別です。

残してはいけない曖昧さ	今回の例での扱い
DB障害を0件扱いしていないか	S-07などの処理エラーと区別するケースを追加する。安全に障害を再現できるテスト環境・担当・復旧手順を決め、稼働中の本番DBを止めない。
登録直後の連打・通信切断後の再送	未決事項Q-03。何件保存を正しいとするか、画面でどう案内するかを合意してから期待結果を確定する。確認不要という意味ではない。
性能・スマートフォン・安全性	想定件数、同時利用者数、許容時間、端末・画面幅などの条件と担当を決めて別途確認する。今回の機能ケースだけで公開可とは判断しない。
テストを終える条件	必須ケースが実施済みであること、重大な未解決不具合がないこと、残る課題と影響を責任者が確認することなどを、開始前に合意する。

最後に「テスト完了」と書くときは、対象版・確認した範囲・結果・残る課題を報告します。未実施のケースや未決事項を消して合格率だけを上げても、利用者が安全に使える根拠にはなりません。

確認問題

1. ST-01を「登録完了画面が表示されれば合格」としました。D-01からD-02を登録する場合、一覧とDBについて、何を期待結果へ加えますか。
2. ST-02で0分を入力するとブラウザが送信を止めました。DBも増えていません。サーバーが0分を拒否するテストを合格にしてよいですか。記録と次の対応を答えてください。
3. 「自分の記録だけを表示する」を確認するため、田中さんの2件だけを用意しました。D-01に合わせて追加するデータと、田中・佐藤それぞれの一覧の期待結果を答えてください。
4. ログアウト後、ログイン画面が出たことだけを確認しました。閲覧と登録について、追加する操作と、保存件数の期待結果を書いてください。
5. ST-02で正しいエラー文言が出ましたが、田中さんの記録が2件から3件へ増えました。判定、不具合の記録内容、修正後の再確認方法を答えてください。

演習後の確認：こちらのページを使って、自分で考えた内容を見直せます。

まとめ

• 要件から条件と操作を取り出し、具体的な入力値・画面・保存結果をテストケースへ書く。
• ケース開始前のデータとログイン状態をそろえ、件数には対象利用者の範囲を付ける。
• 完了・エラーの画面だけでなく、保存内容・未保存・他利用者の非表示まで確かめる。
• 期待結果と実際の結果を分け、未実施を合格にせず、証跡と対象版を残す。
• 要件との対応、未実施、未解決不具合、未決事項を確認して完了を判断する。

関連記事

• 要件定義とは？Webアプリの具体例で学ぶ、要求の整理と要件の書き方
• 画面設計とは？Webアプリの画面設計書・画面遷移図の書き方を具体例で解説
• データベース設計とは？テーブルの分け方と関連付けを具体例で解説
• Javaの結合テストとは？Model・DAO・データベースの連携を確認する方法