製品のリリースサイクルが1年くらいだったのが、
随時パッチをリリースする体制に代わったので、テストを行う回数が増えてきた。
GUIぽちぽちするのは苦痛でしかないので、
今後自動化するためのベストな設計、運用について考えました。
試作段階なので変更するかもしれませんが、今のところの構成です。
デザインパターン
GUIは変化する可能性が高く、テストは定期的に実施します。
メンテナンスしやすい構成にしたいので、Page Object Design Patternを採用しました。
※Seleniumテストの定番構成のようです。
この辺を参考にさせてもらいました。
https://www.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern
http://ninoseki.hatenablog.com/entry/2013/01/09/212424
http://www.assertselenium.com/automation-design-practices/page-object-pattern/
Page Object Design Pattern(ページオブジェクトパターン)とは
テスト対象ページ毎のクラスとテストケースクラスを分離し、変更に強いテストを作成するための仕組み。詳しくは上記リンク先が参考になりますが、
実際にSeleniumのメソッドで画面の要素を指定したりするのは〇〇Pageクラスを作成する。
〇〇Pageクラスは基本的には画面ごとに作成する
〇〇Testクラスで〇〇Pageのメソッドを使用してテストする。ページごと要素を指定するクラスを作成することで、
様々なテストケースで使いまわせるようになる。というのがポイントではないかと思います。
- ソッドがページ遷移を伴わず、文字列等を返さない場合はvoid
- メソッドがページ遷移を伴う場合は遷移先のPageObjectを返す
- publicメソッドはそのページが提供するサービスを表す
- ページ内部を隠蔽する
- アサーションを書かない
- メソッドは他のPageObjectを返す
- ページをまるっとPageObjectで表現する必要はない
- 同じアクションが異なる結果を返す場合、異なるメソッドとして実装する
テストの成功/失敗の判断
テスト結果の判断も、表示した画面に特定の要素があるかなどで判断できますが、
画面の表示崩れまでは分かりません。GUIは人の目で見ておかしくないか判断したいのので、
テスト結果のスクリーンショットを取って、結果は人の目で確認することにしました。
複数ブラウザーの切り替え
Seleniumでは使用するドライバーを変えることで、同じテストコードで複数ブラウザーを使用したテストを実行できます。
DRIVER = new ChromeDriver();//Chromeのオブジェクトのような記述で仕様したいブラウザーのドライバーオブジェクトを生成します。
ここは柔軟に切り替えたいので、
使用するブラウザーは設定ファイルで指定できるようにします。
その他にも、URLやスクリーンショットの保存ディレクトリなど、変更の可能性があるものは、設定ファイルに切り出して読み込むようにします。
要素の指定
一つ一つ設定するのは大変ですが、地道に指定しするしかないようです。
他に方法があるといいのですが。
できるなら開発時にカスタムデータでテスト用に属性を作成しておくと
GUIの変更に強くなりそうです。
参照
ブラウザーごとの切り替え
http://www.seleniumeasy.com/selenium-tutorials/simple-page-object-model-framework-example
カスタムデータ属性の指定
https://qiita.com/okitan/items/eb8f8e253d0811777215