🌐

Webアプリの期待結果をHTTPレスポンスステータスコードで考える

に公開

テストケースの分類というと「正常系」「準正常系」「異常系」といったものがあると思いますが、私は細かい機能のテストにおいてはこれらの言葉はあまり使わずにHTTPのレスポンスステータスコードで結果を分類してテストケースを考えることが多いです。利点としては、HTTPレスポンスステータスコードは定義がはっきりしており 「何をもって"正常系"とするか?」といった解釈の食い違いが発生しないことが挙げられます。

有名どころのHTTPレスポンスステータスコード

ご存知の方も多いとは思いますが、主にWebアプリケーションを開発する上で比較的登場頻度の高いHTTPレスポンスステータスコードを挙げます。

HTTPレスポンスステータスコード 意味 主な用途
200 OK リクエストが成功 処理が成功した場合
201 Created リクエストが成功し、新しくレコード等が作成された 主にPOSTリクエストへのレスポンス
204 No Content リクエストが成功し、リクエストに対して送るコンテンツがない 主にDELETEリクエストへのレスポンス
301 Moved Permanently リダイレクト(永続的) URLが永遠に置き換わった場合
302 Found リダイレクト(一時的) URLが一時的に置き換わった場合
400 Bad Request クライアントのエラー バリデーションエラーが返された場合
401 Unauthorized 認証エラー APIトークンの不正や未ログインの場合
403 Forbidden アクセス権なし 権限制御で弾く場合
404 Not Found データやURLが見つからない 該当のデータが存在しない場合
500 Internal Server Error サーバーの内部処理エラー 想定しないエラー

他にも色々ありますので、興味のある方はこちらを見てみてください。
https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status

ちょっと多いですが、ざっくり以下のように覚えておくとよいです。

  • 200系:リクエストの成功
  • 300系:リダイレクト
  • 400系:クライアント(リクエストを送信した側)のエラー
  • 500系:サーバー(リクエストを受け取った側)のエラー

HTTP 500系ステータスの扱いについて

まず、テストにおいて 500 系、特に 500 Internal Server Error を期待する結果として含めることは基本的にあまりありません。なぜなら、500 Internal Server Error はサーバーが 予期せぬ問題 に直面し処理が遂行できなかった場合に返すレスポンスであり、仕様上は 意図的に返すものではない からです。

ただし、「万が一500エラーが発生した場合に、画面上に適切なエラーメッセージが表示されるか」「ログや監視に通知が残るか」といった エラーハンドリングの確認 は、別途重要なテストのポイントとして存在します。

HTTPレスポンスステータスコード別テストのポイント

ひとつひとつの機能(画面、API)について考えていきます。

200系

いわゆる「処理に成功した場合」のため、データ周りや出力結果を主に確認します。誰もが確認するところかと思います。

  • 計算処理が期待通りであること
  • DB周りの処理が期待通りであること
    • DBから指定したデータが指定した順番で返されるか?
    • DBに指定した情報が登録されているか?
    • DBの指定した情報が更新されているか?
    • DBの指定した情報が削除されているか?
  • レスポンスが期待通りであること
    • 画面遷移が伴う場合は想定通りに行われているか?
    • 画面に処理の結果が想定通りにレンダリングされているか?
    • APIの場合レスポンスの内容が想定通りか?
    • 出力がCSVやPDFの出力を伴うものだった場合、想定通りに出力されているか?
    • メールが想定通りに送信されているか?
    • ログが想定通りに送信されているか?

300系

  • 遷移先が期待通りか?

400系

「バリデーションに引っかかった場合」や、「ログイン認証が切れている」場合など、バリエーションが豊かです。400系とまとめるより個別の番号で呼ぶことが多いです。

  • バリデーションエラー(400)
    • 仕様で定めているバリデーションが全て実装されているか?
  • 認証エラー(401)
    • ログインセッションが切れている場合、処理が想定しないエラーにならないか?
    • APIトークンが誤っている場合、処理が適切なエラーを返すか?
  • 権限エラー(403)
    • その処理を行うのに必要な権限があり、その権限がついていない場合適切なエラーを返すか?
  • NotFoundエラー(404)
    • 指定された情報が見つからなかった場合に、適切なエラーを返すか?

500系

  • 想定しない問題が生じた場合に、エラーハンドリングは適切か?
  • すぐに検知できるようになっているか?

終わりに

HTTPレスポンスステータスコードを頭に入れておくと、アプリケーションエンジニアと話すときも色々と便利です。

Discussion