Selenium導入ガイドラインなど

Selenium導入ガイドラインなど

本資料の目的

  • プロジェクトにSeleniumによる自動画面テストを導入する際、プロジェクトに導入すべきかどうかの判断材料の提供。
  • 導入時や運用の手引きとなる資料を目指す。

導入方針

Seleniumの向き・不向き

  • [向いている]
    • UIの機能確認
    • 画面遷移確認
    • 繰り返し行うテスト
      • 結合テストにおいて、値を変えて何度も同じ機能をテストするケース
      • 回帰テストなど、プロジェクトのリリース単位で必ず通るテスト
    • 長期間継続的にリリースを行うプロジェクト(寿命の長くなるはずのシステム)
  • [向いていない]
    • UIのデザイン確認
    • 繰り返し行わないテスト
      • キャンペーンなど、一回で使い捨ての機能の結合テスト
    • 1度リリースしておしまいなプロジェクト

IDEとWebDriverの違い

  • IDEについてはこちらを参照
  • WebDriver(Selenium2)についてはこちらを参照
テストケース作成の違い
  • IDEはGUIベースで実際の画面内の要素を選択しながら動作を記録してケースを作成する。
  • WebDriverはxUnitと同じような形式でコーディングを行う(言語はJava、PHP、Ruby、Pythonなど)。
  • IDEでは、記録したケースをxUnit形式に吐き出すことも可能(PHPはFireFoxのプラグインが必要)。

Selenium導入のメリットとデメリット

  • メリット
    • 繰り返し行うテスト(特に回帰テスト)の工数を減らすことができる
      • 一度ケースを作っておけば、時間を経ても何度も実施できる
    • テスト手順の明示化。また、手順を共有しやすい
    • 単調で時間のかかる作業を人が行わなくて済む ☆
      • 自動化した分のリソースを他に回せる
    • メンテナンスが途切れなければ、テストケースを仕様書として扱うこともできる
    • 定期的に回帰テストを回せば品質が担保されるので、想定外のエラーの早期発見ができる
      • 影響範囲の大きい修正を行いやすい
  • デメリット
    • Seleniumを使うこと自体に学習コストがかかる
    • テスト作成の工数がかかる(初回サイクルは手動の3倍以上かかると言われている) ☆
    • 対象の機能が複雑だと、よりテスト作成の工数がかかる
    • メンテナンスの工数が必ず発生する ☆
    • 画面の変更に弱い
    • ブラウザを操作する分、実行に時間がかかる
      • ケースが増えれば増えるほど顕著になる

使用方針

どのテストに利用するか

  • 基本的に結合テスト以降。 Seleniumはあくまで「画面用」のテストツールなので、機能単体レベルはxUnitのテストに任せるべき。
  • テストケース作成にかかるコストを考えると、コストが低く繰り返し行うテストが向いている。
    • 同じ画面で入力パターンの多いフロー
    • クロスブラウザテスト
      • ひとつケースを作れば複数のブラウザをテストできる ☆
  • それ以外でも、年に数回でも必ず実施するテスト(回帰テスト、定期キャンペーン画面テストなど)も対象として向いている。
  • 特に回帰テストのテストケースは、きちんとメンテナンスを行えば品質担保のための大きな財産になる。
  • 繰り返し行わないテスト(バグの暫定対応など)や緊急を要するテストは手動で行ったほうがよい場合もある。
  • Seleniumはその性質上、デザイン的な部分を判定する(文字が枠からはみ出していないかなど)テストは難しいが、画面だけSeleniumでキャプチャを取って目視で確認という合わせ技は可能。

各テストの利用例

  • 回帰テスト
    • 正常系と権限周りの正当性確認
      • 作成コストを考えて最低限の機能に絞る
  • 結合テスト
    • 入力チェックや画面フローのパターンの多いケースについて、条件を変えてループで回す

テスト作成のポイント

  • テストが増えるとそれだけメンテナンスコストがかさむため、できるだけ無駄なテストは書かない。
  • テスト対象のHTMLタグのIDは指定しやすい形(一意)にしないとSeleniumから要素が取りにくいので、Webデザイナーとの意識合わせは重要。
  • また、仕様変更によるメンテナンスが必ず発生することを前提として作業を進める。
  • テストケースをxUnit形式でコーディングする場合、Selenium公式でも推奨されているページオブジェクトパターンを利用するとよい。
  • 以下の規則を守りつつ、テストコードをシナリオとページオブジェクトの二つに分けることで、可読性と保守性が向上する。
  • 参考:http://softwaretest.jp/labo/tech/labo-292/
    • publicメソッドは、ページが提供するサービスを表す
    • ページの内部を公開しないこと
    • 原則としてassertionを行わないこと
    • メソッドは他のPageObjectsを返す
    • ページ全体を表す必要はない
    • 同じアクションに対して異なる結果となる場合には異なるメソッドとしてモデル化する
  • テストを何度が実行して、成功するときとしないときがあるケースがあるが、これはSeleniumのテスト実行速度が速いために、指定要素が表示されない状態でテストが実施され、要素が見当たらないエラーになるため。
  • 対策は以下。
    • IDEならwaitFor○○や○○AndWaitコマンドで要素が出現するまで待つなどする
    • WebDriverなら クラスの設定による暗黙的待機
    • // 初期設定(一度だけでOK)
       WebDriver driver = new FirefoxDriver();
       driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
       
       // 個々のテストケース(特に記述を加える必要は無し)
       WebElement element = driver.findElement(By.id("some_button"));
      
    • もしくは waitクラスによる明示的待機
    • WebDriver driver = new FirefoxDriver();
       // 第二引数で最大の待機時間(秒)を設定
       WebDriverWait wait = new WebDriverWait(driver, 5);
       
       By buttonRegister = By.id("register");
       By textMessage = By.id("message");
      
       driver.findElement(buttonRegister).click();
       // 要素のテキストが変更されるまで待つ
       wait.until(ExpectedConditions.textToBePresentInElement(
                 textMessage, "登録しました"));
       assertThat(driver.findElement(textMessage).getText(), is("登録しました"));
      
    • を利用する。 参考:Selenium WebDriverのwaitを活用しよう

アンチパターン

  • 全てSeleniumを使ってテストする。
    • →テスト戦略なしに闇雲にSeleniumを利用すると、コスト(メンテナンスや実行時間)だけがかさんで本末転倒になる
    • →Seleniumに任せる部分とそれ以外の切り分けをはっきりさせる
    • →前述のように、Seleniumは作った後にメンテナンスが必ず発生する
  • テストを書く・メンテナンスのタイミングが曖昧。
    • →コケる状態のテストが放置されがちになり、Seleniumのメリットを捨てているようなもの

実施例

  • Aサイト
    • SeleniumIDE(Selenium1)で作成、実施。
    • リリース直前の回帰テストに使用。機能ごとに人が手動で実行。
    • クロスブラウザの確認は行わないが、FireMobileSimulatorでガラケー、スマホの確認を行う。
    • ユーザー登録・変更や商品購入など、最低限の機能(正常系のみ)を保障する。
    • テストデータ登録はSeleniumでスクリプトを作り、画面側からユーザーなどを作成するようにしている。
    • →Selenium実行時にJavascriptを利用し、テストに使う登録値(ユーザー名)などが入力できる。
  • Bサイト
    • SeleniumIDE(Selenium1)で作成、実施。
    • jenkinsと連携して、各自ローカルから内部評価環境へコミットする際にSeleniumを走らせて機能的なデグレチェックを行う。
    • 開発サイクルは1週間1リリース。
    • 現在クロスブラウザの確認は行わないが、後々WebDriverに移行して実施予定。
    • 走らせるケースは大まかに3つ。
    1. 全ての画面を表示する
    2. プロジェクトの利益(コンバージョンなど)につながる機能の動作確認
    3. ユーザーの権限ごとのアクセス許可不許可範囲の網羅確認
    • 全ての機能パターンを網羅することはコスト的に厳しいので作らない。
    • キャンペーンなど一時的だがビジネス的に大きく打ち出すものはSeleniumでもテストケースを作成する。
    • テストデータはSeleniumのスクリプトを利用し、画面側からユーザーなどを作成するようにしている。
    • テスト仕様書なしでテストケースを作成しており、レビューは行う。
    • 元々少人数で作っていたためにドキュメントがない現場だったが、開発人数が増えるに従って仕様の共有が行き渡らずデグレが増えてきたため、自動テストの採用に至る。

Seleniumの準備

IDE

WebDriver

運用

運用を上手く回すために

  • Seleniumを前提としたテスト戦略をきちんと持つ。
    • →上記で書いてきたように、どこで、どのように、何のために利用するのか
    • →IDEを使うのか、xUnit形式のWebDriverを使うのか
  • 既存プロジェクトに導入する場合は、まず対費用効果の高そうな箇所から小さく導入していく。
    • →クロスブラウザテスト
      • →ひとつケースを書けば複数のブラウザテストを実施できる
    • →入力値パターンを変えて処理を繰り返すテスト
  • メンテナンスをきちんと工数に入れ込む
    • →仕様変更などが原因でSeleniumがコケた場合は必ず修正を行う
    • →コケるテストが放置されるとそのケース自体が使われなくなってしまう。また、使えないテストは混乱の元になるので、早期対応は必須
      • →「置いてあるテストケースが正しい動作である」という先入観があるため
  • テストデータ(DB値や入力ファイル)をSelenumで画面側から作成する場合、数が多くなるとそれだけ実行時間が増えることに留意する。
    • →基本的にSelenium以外のスクリプトを使ってテストデータの準備を行ったほうが早い

Seleniumのケースを書くタイミング

  • 理想的には仕様が固まったタイミング。
    • →現実的には難しいので、回帰テストにSeleniumを使う場合は結合テストが完了した後や、結合テストに使う場合は単体テストが完了した後など、前段階の作業が確定したタイミングで書くのがよい

Seleniumのケースを書くタイミング

  • 理想的には仕様が固まったタイミング。
    • →現実的には難しいので、回帰テストにSeleniumを使う場合は結合テストが完了した後や、結合テストに使う場合は単体テストが完了した後など、前段階の作業が確定したタイミングで書くのがよい

jenkins連携

  • jenkinsと連携が可能。
  • jenkinsにプラグインをインストールすれば、ビルド後に指定したSeleniumテストを実行できる。
    • →svnのフックスクリプトを利用してコミットごとにjenkinsからSeleniumを実行すれば、デグレが素早く発見・修正できる
  • 詳しくはjenkins導入資料参照

プロジェクトへの導入の流れとポイントのまとめ

新規プロジェクト開始時に確認すること

  • プロジェクト体制の確認
    • テスターと実装者が分かれている場合(外部に委託など)、機能実装者とテスターの担当範囲や連携をどう行うか、検討の必要がある
    • テストに不具合があった際はどちらが修正するのか、報告のフローなど

テスト戦略策定

  • 画面や機能の仕様を元に、Seleniumを導入すると効果的な範囲と対象テストなどを検討する
  • テスト作成の時間とリリーススケジュールの兼ね合いにより以下を決める
  • 対象の機能
    • テストの自動化により品質担保する機能
  • 対象テスト
    • 回帰テストか
    • 結合テストか
  • 担保する品質レベル
    • 正常系のみか異常系も含めるかなど
    • ホワイトボックス?ブラックボックス?
    • 網羅性
  • Seleniumのテストを書くタイミング
    • 仕様確定後か単体テスト完了後かなど
  • Seleniumの実施タイミング
    • 各テストごとに手動実行
    • jenkinsを利用してCIする
  • 成果物の検討
    • スクリーンショット
    • 結果レポート(プラグインなど利用)
    • jenkins連携なら結果メールやjenkins上での結果統計

環境構築時に決めること

  • テストケースの置き場所
    • バージョン管理システムのディレクトリ決める
    • もしくは共有フォルダに置くか
  • テスト環境
    • テストの種類や実施ごとのテスト環境より分け
      • 一例として、回帰テストはステージング環境、結合テストは開発環境など
    • テストを回す際のテストデータの構築も考慮、ルール化する
      • テストの度に一度まっさらにするのか、または各テスト実施時に作ったデータをやりくりするのか
      • まっさらにする場合はデータ投入スクリプトを作る
      • 場合によっては通常の動作確認用とSeleniumテスト用のDBを分けるのもアリ
  • jenkinsを利用してCIする場合の検討・注意事項
    • 基本的な連携プラグイン以外にも、実行結果出力など有用なプラグインの検討
    • テストケースがSVNやGITで管理されていれば、ビルド実行時にテストケースのアップデートを行うように設定する
    • 自動実行され続けるものなので、できれば環境は専用のものを用意したほうがよい

機能実装

  • テスト対象のHTMLの各要素にIDを振っておいたほうがSeleniumのコードを作りやすい
    • →HTML実装者との意識共有

テスト実装

  • 確定した仕様とテストルールを元にSeleniumのテストを書く
  • xUnit形式の場合はページオブジェクトパターンの採用も検討

テスト

  • バグなどでテストケースの修正が必要な場合は必ず直す。プロジェクトがシステムの機能追加・修正の場合も必ず既存テストケースを修正する。
    • →動かない・使われない=混乱の元となるテストケースは残さない

リリース後のバグ発覚

  • 影響範囲調査などに使えないか検討
    • →入力パラメータを変更してSeleniumを回す

リリース後のバグ修正

  • テスト時と同じように、バグ修正で影響するテストケースは必ず直す

プロジェクトに途中でSeleniumを導入する場合の注意事項

  • テスト対象のHTMLの要素にidを振ってないと、テストケースを作成する際に要素が取得しにくい
  • 導入初回時のテスト工数の見積もりは既存テストの3倍はかかるよう見積もる
    • →3倍で済めばよいほう


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/224308/60572739

この記事へのトラックバック一覧です: Selenium導入ガイドラインなど:

コメント

コメントを書く



(ウェブ上には掲載しません)