機能テストって何かしら
- ブラックボックステスト
- アプリケーションを実際に操作してテストする
- 受け入れテストとも言う
テストの種類
- RAT
- FAST
- TOFT
- FET
- 境界条件テスト
- 探索型テスト
RAT (Release Acceptance Test) リリース時受け入れテスト
スモークテストとも言う。
アプリケーションがとりあえず動作、機能テスト可能な状態にあるかどうかを確認するテスト。 なので実は機能テストではない。
アプリケーションを起動できるか、文法エラーで動かないところはないか、動作に必要なリソース（データベース等）に接続できているか、といったレベル。
FAST (Functional Acceptance Simple Test) 受け入れ時簡易機能テスト
広く浅い範囲を対象とした最低限の機能テスト。 軽量なので一回のテストにかかるコストが少なく、素早く実行できる。
対象は以下のとおり。
- リンク
- UIコントロール（入力、ナビゲーション）の挙動
- 追加、削除、更新などのデータ変更テスト
- ログイン、ログアウトなどのその他主要機能
すでにテスト環境で完全なテストを通っているものを他の環境（本番環境や開発環境など）へリリースした際に行ったりする種類のテスト。
TOFT (Task-Oriented Functional Test) タスク指向機能テスト
プログラムの機能を確認するいわゆる正常系のテスト。
ユーザがタスクを完了できるかどうか、実行される各タスクの完全性を確認する
- 様々なデータの入力に対してデータ出力が常に適切であるかどうかをチェック
- 他の関連する機能と組み合わせた場合の完全性
網羅性が要求される。
FET (Force-Error Test) 強制エラーテスト
いわゆる異常系のテスト。
エラーを意図的に発生させ、エラー処理が正しく機能しているかどうかをテストする。 エラーによってアプリケーションが不安定になったり、データが破損することがないことを確認する。
- エラーを意図的に発生させる
- エラー検出の確認
- エラー処理の確認（エラーから復帰できるか、データ等に異常は発生してないか）
- エラー通知の確認（エラーメッセージが表示されたか、内容は適切か）
- エラーによるそのほかの障害が発生していないか探す（エラー処理に抜けがないか等）
境界条件テスト
TOFTやFETの延長線上にあるテスト。 テストに用いる各変数の境界値をテストする。
等価クラスから境界値を分析してテスト変数を絞る。
テスト変数を絞ることはリスクだが、リソース節約のメリットの方がはるかに大きい。
等価クラス
どの値を入力しても結果が同じように処理される。それらの値は等価クラスとしてひとまとめにできる。
- 数の範囲（2桁の数字 10-99 など）
- グループ（日付、時刻、国名など）
- 不正な入力（半角数字のみ許可のところに半角英字、記号、全角文字など）
- 等価な動作環境（同じバージョンのOSの別々のマシン）
境界値
等価クラスから別の等価クラスへ移行する境界 境界値付近ではエラーが起こりやすいので、
- 許容される入力値と許容されない入力値の境界
- サポートされるシステム要件とサポートされないシステム要件の境界
ひとつの境界値からは多くとも最大9のテストケースが得られる。
- 有効値の範囲
- 有効値の最小
- 有効値の最小+1
- 有効値の最小-1
- 有効値の最小-α（確実に有効値より小さい）
- 有効値の最大
- 有効値の最大+1
- 有効値の最大-1
- 有効値の最大+α（確実に有効値より大きい）
他に文字列の等価クラスや小数点や前ゼロのついた数字のような特別なクラスなどが存在する。 ひとつのフィールドの値に関して等価クラスがたくさんあれば境界値もそれだけ増える。
境界値を使ったテストケースの作成
- 等価クラスを見つける
- 境界を見つける
- 有効な入力に対する出力結果を予想する
- 不正な入力に対するエラー処理を予想する
- テストケース一覧の作成
探索型テスト
アプリケーションを操作して未知のバグを見つけ出すためのテスト。 学習、計画、実行を同時に行う。
どのテストを使うか
- 継続的インテグレーションにともなう完全なテスト -> TOFT, FET, 境界条件テスト
- テスト済みアプリケーションのリリース時 -> FAST
- リリース前の積極的なデバッグ作業 -> 探索型
機能テストの自動化
なんでもかんでも自動化すればいいってもんでもない。
- 自動化にはしっかりとした計画が必要
- 自動化の前にテスト容易性を強化したほうがよい
- ダメな自動化は無駄
- 自動テストが複雑すぎるとテスト自体にバグが
- でもやっぱ好き
- 複数人で作る場合は命名規約などのガイドラインがあったほうがよい
作成コストと保守コスト
- アプリケーションの規模が大きくなるほど作成コストがかさむ
- アプリケーション更新のプロセスに組み込まないとすぐに陳腐化する
- つまり保守コストもかかる
- 保守コストがアプリケーションの開発速度に影響する
- UI変更で全滅したりする
保守性の高いテスト
- ちょっとした文言変更くらいには影響されない
- 他のテストの変更に影響されない
機能テストを減らす工夫
- ユニットテストにまかせる
- モデルのバリデーションテストなど
- フレームワークを利用する
- フレームワークが面倒見てくれる部分のテストは割愛
- テストを書きやすいフレームワークもある Railsとか
テストライブラリ構築上の注意
- 複雑すぎる処理はそれ自体にバグが埋まる可能性
- 整理しておかないと同じようなものがいくつも作られて混乱の元に
テスト容易性
可視性
- ソースコード
- ログ出力
- デバッグ出力
エラーの原因がすぐに追跡できること。わかること。
操作性
- エラーシミュレーション
- 診断コマンド
- テスト用API
エラーの状態を再現しやすいこと。
自動テストの対象としてGUIがいいかテスト用APIがいいかは意見が分かれる。 SeleniumはGUI
参考文献
新しいブログへ移行しました！こちらもよろしくお願いします。