本日は完全自分用です。私以外の人間が見ても意味不明かもです(汗)
Contents
大事だと思う考え方
- 負荷テストなどを除くと最終的なケース自体がそう多くないことをまず理解する。(ケースが多すぎると勝手に思い、雑になることが多い。効率のいいパターンを組めば2桁になることはめったにない。)
- データベースが絡んだ場合、検出結果の際を見るとき、複雑に見えても主にSQLを見ながらWHERE句の条件分岐でテストケースを考えるとシステマチックにできる
- 作業ツールはExcel,CSVエディタ,テキストエディタのいいところを組み合わせる
- なるべくユニットテスト中心で考え、無理な場合、画面テストを行う。
- 費用対効果を考える
- 最適化させすぎないこと
- 状況がかわることの想定
- テストをやらないことと＆テスト自体の自己目的化を避ける
- 日ごろのコーディングでテストしやすいように組む。個人的なポイントはとにかく短くする。意味ごとに分割する。引数と戻り値をしっかり定義し、メソッド内部でPOSTをうけとったりしない(WEBを前提としたメソッドを作らない)、早期リターンで分岐を少なくする
実際のテストパターンの作り方について。
検索系
あらかじめ入っているデータが必ず必要。
未チェック時
必ず全レコードが出力されているか
キーワード系 1:Nパターン(主にキーワードなど)
Nに該当しているパターンがあるかどうかの確認。テストケースは必ずNパターンがいる。完全一致と部分一致で入力値を分ける
1:1パターン
通常の検索パターン。ダイレクトに検索ができるかどうか。すべて１つのテストケースにあっても構わないが、一致しないものを考えるために、最低2パターンいる。likeも検索値を分ければよいのでパターン自体は2パターンでも問題ない。
日付パターン(範囲パターン全体)
同日一致パターンは漏れやすい。一致無し、区間一致、同日一致でできれば3パターンほしい。場合によってまたぎパターンなど。
集計系(検索の一部)
基本的に範囲内と範囲外でOK。集計といっても2レコードも200レコードでもシステムの正確性を試すには変わらないことを忘れないこと。
全般的にSQLをみて分岐パターンを考える。境界値付近は必ず値をチェックする。
更新系
基本チェック項目
- エラーになって画面を返す場合、値が正常に保存されているか。
- 更新の場合、最初のページはデータベースから表示され、一度入力値がある場合はエラー発生時、入力値が保存されるか。
- 空白で上書きができるか。
- 値の優先度(データベースから呼び出す場合などや複数の値を参照する場合など)
- ただのテキストは問題ないが日付や数値などは空白値のデータがどのようになるかを確認するとよい
項目チェックパターン
- 必須系のエラー
- 形式エラー(必須かつ形式があるものと、特に必須ではないけれど形式エラーがあるものに要注意)
- 重複や存在確認などDBと参照するタイプのエラー
- 最後のinsertやupdateが正常に行われているかいなかレスポンスが正常に返せているかいなかの確認
入力値
- 正常に値がはいっているか
- nullと空白,0が区別できているか
- 重複チェックなどが出来ているか
上記の3,4パターンが必要。エラーが出るケースは全項目にエラー値を入れればいいのでパターン数は増えない。
残しておくデータに関してはすべてが正常系のものと、空白系の2パターンで基本OK。(その後の特殊なパターンを考えないケース。)
テスト実行前と実行後でデータの状態が変わるのでできれば削除して初期化しておくことが望ましい→(超重要。通常のユニットテストだったらそういう機能がついているが、ついていない場合は日付などで作成日を範囲づけして削除すると便利)
CSV系
- 文字コードや改行コードの選定や対策ができているか
- ファイル存在チェック、形式チェック
- データが一行もない場合にエラーがでるか
- データ自体が不正なものをはじけているか(改行で分割した時に複数行、つまりは配列形式になっているか)
- 列数が正しくないものを正確なエラーメッセージが出せてはじけているか
- 形式が正しくないものを正確なエラーメッセージが出せてはじけているか(メルアドチェックなど)
- DBへの存在チェックで存在しないものをはじけて正確なエラーメッセージが出せているか
- データ入力失敗時にエラーメッセージが出せているか(主に例外系のエラー)
- 危ないタイプのデータ(特に入力すべき値を参照)をチェックできているか
負荷テスト
- 本番に相当する or 近いデータ量でのテストをしておくべき(動くけど、実データいれると使い物にならない・・というケースが起こりがち)
- テスト作成のためにはマクロ、WEBサービスなどがお勧め。作業が頻出かつ必要性がある場合は自分で作成コードを書くのもあり
特に入力すべき値
- 桁数最大値
- 桁数最小値
- 0
- 空白
- null
- 特殊文字(HTMLやエスケープしなくてはいけないタイプの文字など)
- 改行(CSVで特に有効)
- ダブルクオートやカンマ(CSV内で崩れないか特に有効)
自動化に関する覚える書き
- テストのたびにデータベースを初期化できるのが理想(更新系の処理の場合、これをしないと検証できない)
- ただし、上記はフレームワークなしだと難しい。それができない場合データベースを入れ替えするのはかなり大変。都度データを消すのがもっとも現実的。
- データ保存はCSVやExcelでケースをまとめておくのが現実的。特に複雑なケース。簡単なケースであればハードコーディングでいいかも。
- それが難しいケースでは小さいケースでダンプを取り、テスト前にダンプ→テスト実行→リストアを随時行う。
- データベースの入れかえができない場合の更新テストは、重複不可、日付、ナンバリング系の数字のチェックをはずすか対策をとること。データ保存の場合もこの点に注意。
