テスト指針

この文書は主に統合テスト実施者向けの内容です。開発者向けの単体テスト手法やテストの自動化については触れていないので注意して下さい。

• 前提条件
• テストの種類
• デグレード問題
• ブラウザでの動作検証
• 結合テストのポイント
  • 画面の表示
  • フォームの動作
  • 境界値テスト
  • 異常系テスト
  • 有効期限付きアドレス
  • 認証
  • データの取り扱い
  • メール
  • 不正アクセス
  • バッチ処理
• 統合テストのポイント
  • スマートフォン ネイティブアプリ
• 負荷テストのポイント

前提条件

• この文書はテスト実施者が注意すべき項目をまとめたものである。指針の中には本来設計者や開発者が気にとめなければならない項目も含まれているが、得てして彼らは問題を軽視したり、目先の納期に合わせるため対応を後伸ばしする傾向がある。プログラマの書くコードにバグがないという状況はほぼあり得ない。しかしテスト手法を確立することでバグの潜在率を下げることはできる。テスト実施者は起こりえる全ての問題を精査し、テストし、同じミスを繰り返さないよう啓発していくことが役割である。
• テスト実施者はテストに関する次のドキュメントを作成すること。尚、プロジェクトは原則的に フェーズ管理形式 で進められるため、特に結合テスト、統合テストに関してはフェーズ毎での再テストを必要とする。(ドキュメントもフェーズ単位で作成する必要がある)
  • 結合テスト仕様書
  • 統合テスト仕様書
  • 負荷テスト仕様書
  • 障害テスト仕様
• テスト工程は PDCA サイクルで進める。テスト手法に問題が生じる場合は、テスト計画を再考する。
  1. テスト計画 (Plan)
  2. テストの実行 (Do)
  3. テストの評価 (Check)
  4. 改善 (Act)
• 性能テストや障害テストはシステムにより規模やインフラが異なるため、システム構成に精通しているプロジェクトリーダーが協力してテスト仕様を作成する。

テストの種類

システムをリリースするに当たって必要となるテストフェーズを下表に記す。

テストフェーズ	分類	検証内容	主な実施者	基づく仕様書
単体テスト (ユニットテスト)	開発	プログラムモジュールが仕様通り機能しているか	開発者	内部設計仕様書
結合テスト (機能テスト)		個々のモジュールを組み合わせてうまく動作しているか。仕様通りの動作を満たしているか	テスター	結合テスト仕様書
統合テスト (受け入れテスト)	承認	システムとして全ての機能が正常に動作しているか	テスター	統合テスト仕様書
セキュリティテスト	品質管理 (QA)	XSS や SQL インジェクション、CSRF 等によるセキュリティホールがないか	テスター	結合テスト仕様書
性能テスト (負荷テスト)		想定している以上のデータを投入し、システムに影響が起こらないか	テスター	性能テスト仕様書
障害テスト (信頼性テスト)		データベースサーバやキャッシュサーバがダウンするとどうなるか (どのような動作が起こるか)	テスター	障害テスト仕様書
ユーザビリティテスト		システムがユーザにとって使いやすいものであるか	テスター	ユーザビリティ指針

デグレード問題

• デグレードは、ファイルのアップロードし忘れ (アップグレード時に 1 つまたはた複数のファイルを更新し忘れた・リビジョンの更新ミス等) や、コード改修によって想定していない機能にまで影響を及ぼすことで問題となることが多い。このうち後者はソースを改修した後の影響範囲の認識不足 (テストケースの洗い出し不足) という点で開発者のスキルが問題となるが、一概に開発者だけの問題ではない。最終的に動作を保証するのはテスト実施者であるため、リリース後に問題が発覚した場合は実施者のテストが不足していると言える。

ブラウザでの動作検証

• アプリケーションの動作確認は次のブラウザで確認を取ること。
  • PC
    • Internet Exploerer
      • シェア数が多いため、古いバージョンでも動作確認することが望ましい
    • Firefox
    • Chrome
    • Safari
  • スマートフォン (※統合テスト - スマートフォン ネイティブアプリ の項も参照)
    • iPhone
    • Android
  • 携帯
    • docomo
    • au
    • Softbank
• 「動作確認」とは次の動作を意味する。
  • 特定の環境のみ異なる動作や表示されない (動作しない) 問題が起こらないか
  • 特定の環境のみレイアウトが崩れないか
  • 特定の環境のみパフォーマンスが低下しないか
• テスト開始時に各ブラウザのキャッシュをクリアすること。
• 結合テスト以降、スマートフォンや携帯のテストはエミュレータではなく、必ず実機で動作検証を行うこと。
• 動画や音声といったリッチコンテンツはデバイスによって異なる動作を起こす可能性が高い。関連機能の改修後は必ず全デバイスでテストを行うべきである。
  • ファイルサイズやメディアタイプによっても特定のデバイスだけ再生されないといったケースが多々ある
    

結合テストのポイント

このセクションでは Web アプリケーションの単体テスト仕様を作成する上で最低限必要なチェックリストをまとめる。

画面の表示

• 画面レイアウト
  • 仕様書に従って機能が配置されているか。
  • ページに設置されたリンクは正しい画面遷移を行うか。
    • ページ内の全ての URL、メールアドレスにハイパーリンクが張られているか。
    • サイト内の存在しないページへアクセスするとどうなるか。(通常は 404 エラーを返すだけではなく、ユーザにページが存在しないことを警告するメッセージを表示するべきである)
• ブラウザのウィンドウをリサイズするとどうなるか。(レイアウトが再調整されるか)
• PC の解像度を変更し、サイトのレイアウトが崩れないことを確認する。
• 表記
  • 使用されている文言に誤字・脱字がないか。(各種通知メッセージやメール文言を含む)
  • 使用されている語句に表記揺れがないか。
• ユーザデータの表示 (2012/05/23 追加)
  • フォームから登録された文字列 (ログイン名、メッセージ等) が極端に長い場合、サイト内でその文字列を表示した際にレイアウトが崩れない (適切に調整される) ことを確認する。
    • リストページ等で長い文字列を表示する場合、末尾に「...」を付けて一部のみ表示する手法も検討する。
  • (仕様書に特別な記載がない限り) ユーザデータの文字列内に URL やメールアドレスが含まれる場合、適切にアンカーが貼られることを確認する。

フォームの動作

• 各フィールドに対するチェック項目
  • text、textarea フィールド
    • 許可されない文字の入力
      • メールアドレスフィールドへのカナ文字の入力等
    • 任意項目を未入力にする
    • 必須項目を未入力にする
    • 機種依存文字の入力: "①" や "㈱" など
    • 絵文字の入力
      • 入力した絵文字が文字化けせずサイト内で反映されているか
        • iOS はバージョン 5 以降 Unicode 6.0 に対応しているため、絵文字をフォームで入力することができる (また今後 Unicode 6.0 に対応するデバイスは増えることが想定される)
      • アプリケーションが外部サービスへユーザ情報 (アクティビティ、プロフィール等) を自動投稿する場合、絵文字は投稿先サイトでどのように扱われているか (外部サイトは絵文字をサポートしていない可能性も高い)
    • XSS 対策: HTML メタ文字 ("<"、"&" など) がエスケープされるか
    • SQL インジェクション対策: "'" (シングルクォート) 等の文字を入れて誤動作が起こらないか (詳しくは専門のサイトを参照)
    • 文字列フィールド (境界値テスト の項も参照)
      • 許可される最小文字数の入力
      • 許可されない最小文字数未満の入力
      • 許可される最大文字数の入力
      • 許可されない最大文字数超の入力
      • マルチバイト文字の入力
        • 例えば入力フィールドが 5 文字まで許可される場合、全角・半角文字を含め合計 5 文字までを許容する。
      • 比較値の入力: パスワードの再確認など
    • 数値フィールド (境界値テスト の項も参照)
      • 許可される最小値の入力
      • 許可されない最小値未満の入力
      • 許可される最大値の入力
      • 許可されない最大値超の入力
        
      • プラス値、マイナス値、ゼロ値が正しく処理されるか
      • 小数点数値を入れるとどうなるか
  • 日付フィールド
    • 日付以外の文字を入力するとどうなるか
    • 無効な日付を入力するとどうなるか
      • 閏年が考慮されているか
  • file フィールド
    • 許可されないファイル (拡張子) のアップロード
      • 拡張子がないファイルがアップロードされた場合にどうなるか。
    • 不正フォーマットファイルのアップロード
      • MIME タイプとバイナリが異なる (拡張子偽装)、CSV であればカラムフォーマットが不正等
    • ファイルサイズの 境界値テスト を行う
      • ここでの「サイズ」とは、ファイルサイズのほかに、画像であれば「縦」と「横」の必須ピクセル、動画であれば再生時間等を含む (仕様に準拠すること)
    • 写真や動画のアップロード
      • 横向き、または縦向きで撮影されたデータが正しい向きでアップロードされるか。基本的にはサーバサイドで向きを調整するべきだが、重力センサに対応していないデバイスからの投稿 (または Orientation 属性が保持されていないデータ) の場合、データの向きを検知することができない。データの用途によっては、傾きを調整する機能をサイト上で提供するべきである。
    • ファイル名の検証
      • HTML メタ文字を含めた場合、ファイル名を表示した際にエスケープされるか。
      • 長いファイル名 (255 文字以上) を持つファイルをアップロードすると表示の際にどうなるか。
    • ファイルアップロード中における例外 (2012/05/25 更新)
      • ファイルをアップロードしている際中に、対象ファイルを削除するとどうなるか。
  • radio、checkbox、select フィールド
    • 任意指定に対する未指定
    • 必須指定に対する未指定
    • 複数のチェックが有効な場合
      • 必須指定数以下のチェック
      • 必須指定超のチェック
  • submit、button
    • フォームを再送信 (POST) することで二重に処理が走るようなロジックが組み込まれていてはならない。特に会員登録や決済処理といった場面では細心の注意を払う。(※二重処理が発生した場合のテストケースは必ず作成すること)
      • ブラウザの「戻る」ボタンで前画面に戻り、再度送信を行うとどうなるか。
    • ファイルのアップロード途中でブラウザを閉じたり他の画面に遷移するとどうなるか。
• ページを読み込んだ (または再読み込み) 際に、必要な項目にデフォルトで入力、チェックが付いているか。
  • フォームでエラーが発生した場合、ユーザが入力した (あるいはあらかじめ入力されていた) 情報が保持されていることを保証する。ただしパスワードやクレジットカード番号など、機密情報に関する情報はこれに当てはまらない。逆に言えばこれらの情報が保持されている場合、そのプログラムは危険なものとなる。
• メールアドレスやパスワードといった入力文字が想定されるフィールドで、あらかじめ IM のデフォルトモードが指定されているか。
  • 特にスマートフォンや携帯では入力モードの切り替えが面倒となる。サイトのユーザビリティを高める上でも (簡単に対応できるので) 対応が必要である。

境界値テスト (2012/05/23 更新)

• 境界値テストは、データが取りうる値の境界内・境界付近で対象値が適切に処理されるかチェックするテスト手法である。例えば仕様に「アップロード可能なファイルサイズは 1MB までとする」と記載されている場合、論理的には 1,048,576byte (1024*1024) までのファイルサイズが許容されることになる。この時、1,048,576 - 0〜1byte のファイルは許可されるが、1,048,576 + 1byte のファイルはアップロードされてはならない。境界値付近は、開発者が判定条件を間違えて (「未満」と「以下」、「以上」と「超」)、バグを生み出す可能性が非常に高い。Web アプリケーションの場合、ファイル許容サイズのバグは致命的な問題に繋がる可能性が高いため、必ずテストを行う必要がある。
• ファイルサイズに関する代表的なテスト項目は次の通り。
  • 許容サイズより -1byte 小さなファイルをアップロードする
  • 許容サイズと同じサイズのファイルをアップロードする
  • 許容サイズより 1byte 大きなファイルをアップロードする
  • 0byte のファイルをアップロードする
  • サイトが許容するファイルサイズより極端に大きなファイルをアップロードする
• 任意のファイルサイズを生成するツール
  • Windows には fsutil、Linux には dd という任意のファイルサイズを生成するコマンドが標準で付属している。ファイルサイズテストを実施する際はこれらのコマンドを使ってファイルを生成すると良い。

異常系テスト (2012/06/8 追加)

• システムが想定していないと思われる行動パターンをとった際に、アプリケーションがどのような動作を行うか検証する。異常系テストの内容はシステムにより異なるが、ここではいくつかのテストケースを紹介する。
  • 会員登録
    • 退会済みのユーザが以前と同じメールアドレスで再登録できるか。
  • ショッピングカート
    • 商品 A の在庫が 1 個の状態で、ユーザ a、b が同時にショッピングカートに商品を追加したとする。購入手続きまで進んだ時、商品はどのように扱われるか。
  • ファイルアップロード
    • ユーザ単位で最大 10 ファイルまでのアップロードを許可したシステムの場合、9 ファイルアップロードされた状態で複数ブラウザから 2 ファイル同時にアップロードするとどうなるか。
    • アップロードされたファイルのフォルダ移動や名前変更、削除を繰り返す。

有効期限付きアドレス

• 会員登録認証やパスワード再発行認証で発行する URL には有効期限を設ける必要がある。有効期限は長ければ長いほど第三者に不正認証されるリスクが高まる。
• 既に無効な (使用済みの) アドレスを再度開くとどうなるか。
• アドレスに含まれる文字列 (ハッシュ値) の一部を書き換えてアクセスするとどうなるか。
• 有効期限後に URL をクリックした際は、そのアドレス自体無効扱いとする。
  • URL だけでなく一時的に発行されるメールアドレス等も同じ

認証

• サイト内の分かりやすい位置にログアウト機能が提供されているか。
• スマートフォン (外部連携)
  • OAuth や OpenID に対応したサイトと連携する場合、連携自体を解除する機能が提供されているか。
  • 認可時にパーミッションを拒否するとどのような遷移が発生するか。
  • 認証しようとした外部アカウントが別のアカウントと紐付いていた場合はどうなるか。
• 携帯 (かんたんログイン)
  • かんたんログインの解除機能が提供されているか。

データの取り扱い

• 削除 (退会) 済みのデータにアクセスするとどうなるか。
• データの重複はシステム内でどのように扱われるか。
  • 例えば会員登録時にメールアドレスが必要な場合、他のユーザが同じアドレスを使って登録しようとするとどうなるか。また、一度システムから退会したユーザのアドレスを再登録時に使用できるかどうか。

メール

• 機種依存文字 (絵文字を含む) が含まれたメールを受信するとどうなるか。
• メールテンプレートに差し込み変数が許可される場合、変数のデータが正しく展開されるか。
• 件名
  • 文字列長は適切か。携帯では一度に見られる情報が限られる。件名が長くなる場合は末尾を "..." 等に丸める。
• 本文
  • 文字列は適切な長さで折り返されるべきである。
    • 一般的に一行辺りの長さは 76 文字程度に抑えるべきである。
    • URL を折り返してはならない。
  • 妥当な署名 (配信元情報、配信停止手続き等) が付いているか確認する。
• 各種メーラーの検証
  • Web メール (gmail、Yahoo! 等)
    • サイトからのお知らせメールが迷惑メールフォルダに入らないか。
  • スマートフォン・携帯
    • PC 用のメールテンプレートが使用されていないか。
      • 画面が狭いため、レイアウトが崩れる可能性がある。
    • docomo SP メールによる送信、受信が可能か。
    • ドメイン指定受信に関する注意書きが記されているか。
      • ユーザは特定ドメインからのみメールを受信するよう設定している可能性がある。
    • DNS に SPF レコードが登録されているか。
    • ファイルの添付送信
      • (端末が複数ファイルの投稿に対応している場合) 複数のファイルを添付するとどうなるか。
      • 1 つ以上のファイルにエラーが含まれるとどうなるか。
      • (重力センサに対応した端末の場合) 横向きで撮影した写真 (動画) を添付するとどうなるか。

不正アクセス

• GET (または PATH_INFO) パラメータを書き換えるとどうなるか。(例えば数字パラメータを英字パラメータに書き換える、大きい数字に書き換える等)
  • 有効アドレス "http://{fqdn}/download.do/key/abc" に対し検証すべき URL アクセスのパターン例
    • パラメータの一部を取り除く
      • http://{fqdn}/download.do/key
    • パラメータの一部を改ざんする
      • http://{fqdn}/download.do/key/def
    • パスの改竄
      • http://{fqdn}/
  • 不正な URL にアクセスした場合はエラーメッセージを表示することが望ましい。
• 認証が必要なページに (ログインしていない状態で) ダイレクトアクセスするとどうなるか。
  • ログイン中にユーザのセッション (Cookie) を削除するとどうなるか。
• ウィザード形式のページ (例: 登録フォーム→確認画面→登録完了) がある場合、不正な遷移 (例の場合は登録完了ページへのダイレクトアクセス) を行うとどうなるか。

バッチ処理

• プログラムがバックグラウンドで動作するバッチと連携する場合、バッチ処理後に結果を確認する。
  • バッチの実行間隔が長い場合、結合テスト時であれば時間を変更して確認しても良い。(ただし間隔を変更することで予期せぬ問題が起こる可能性もあるため、必ずプロジェクトリーダーに確認を取ること

統合テストのポイント

スマートフォン ネイティブアプリ

• デバイスを横向きにすることでレイアウトが崩れないか。
• アプリが起動した状態でデバイスをスリープ化、再度アプリを復帰させるとどうなるか。
• 通信を伴うアプリ
  • 圏外エリアでアプリを起動し、アプリが通信を行おうとするとどうなるか。
  • 通信中に圏外エリア (または通信回線の切り替え) へ移動するとどうなるか。

負荷テストのポイント

• ステージング環境のサーバにはプロダクション環境と同等 (またはそれ以上) のデータ数を投入しておく。
• 負荷となるような処理 (例えば検索) を短時間で繰り返し行い、サーバからの反応が極端に遅くなることがないか。
• フロントエンドアプリケーションはユーザに迅速にレスポンスを返す設計が必要である。通常は 1 秒以内、どれほど遅い処理であっても 3 秒以上かかる処理は問題とする。(ここでのレスポンスは、クライアントに全ての出力を終えるまでの時間を指している)
• JavaScript を多用しているページはクライアントブラウザの負荷となりやすい。動作テストを行う際は CPU モニタを立ち上げ、極端に負荷の高いページ (CPU 使用率 10% 以上が続くなど) がないか確認する必要がある。 尚、JavaScript の動作についてはブラウザによって左右されやすいので注意が必要である。