『システムテスト自動化標準ガイド』通称ギア本では「キャプチャリプレイは自動化ではない」なんてことが書いてあったりします。
キャプチャリプレイツール(レコードプレイバックツールとも言う)を使って「これで自動化はバッチリ」と思うのは危険がいっぱいです。
キャプチャリプレイツールとは、や、利点などは「テストツールまるわかりガイド」のP62を見ていただくと良いでしょう。
http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf
ここでは、私が思う気をつけるべきポイントを書いておきます。
記録した操作は”もろい”
キャプチャリプレイツールを使って記録した操作は、基本的に同じ条件下で再生すれば同じように動いてくれるはずです。しかし、少しでもテスト対象に変化があると、すぐに動かなくなってしまいます。
前回の記事などでは、このブログを対象に操作を記録・再生していました。この過程で
click css=p:nth-child(37)
という行があります。
これは「Selenium」でブログ検索をしたときに表示される一覧の中から、特定の記事をクリックする操作を記録したものです。
ブログの記事は日々増えたり減ったりするため、この操作だと記事の追加や削除のたびにクリックする対象の記事が変化することになります。
テストの内容によっては、この変化によって操作の途中でエラーになる場合もあります。
記録したテストのメンテや改修が必要
上で説明したように、記録しただけのテストコードは変更に弱いので、記録してから数日後に実行したり、別の環境で実行したりするとうまく動かないことが多々あります。
そんなときには想定通り動くようにメンテしてあげる必要が出てきます。
また、「環境やデータの変更のたびにメンテするのは手間だから、最初から変更に強いテストコードにしよう!」と考えると、記録されたテストコードを見て弱そうなポイントを改修していく必要があります。
(そうこうやっていくと「あれ?結局WebDriver使って自分でコードガリガリ書いたほうが速いんじゃ・・・」ってなるんですよね
役に立つシチュエーションもある
↑ここまでだとSelenium IDE結局不要そうな印象を与えてしまうかもしれませんが、使い所を考えて使えば有用なツールです。
たとえば、
- 画面がもう固まっていて変更が入らないところに対して、コーディング苦手なテスターが自動テストを書く
- 短期間に何度か実行して終わり、というテストを自動化する
- メンテナンスをせずに都度記録しなおしてもコストが見合うようなところを自動化する
などなど。つまりは、記録するコストと、動く状態を維持するためのコストと、自動化することによって得られる効果を比べて、メリットがあるなら使いましょう、ですね。