Selenium WebDriver + python で E2Eテスト自動化

53 views

Published on

JustTechTalk#08 Webフロントエンドでやってみた2017の資料2本目です。

Published in: Engineering
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
53
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • それでは、Selenium WebDriverとPythonでE2Eテスト自動化のお話しをさせていただきます。小池です。よろしくお願いします。
  • まず簡単に自己紹介ですが、私自身はBtoB向けのWebアプリケーションの開発を行っていました。
    直近1年ほどは営業管理システムのJUST.SFAの品質保証担当になり、その一環としてテスト自動化の検討から実施までを行っています。

    JUST.SFAですが、不具合によってはユーザーの業務が止まってしまうこともあるので、品質は非常に重要です。
    また、様々な機能が使えてかつ用途に合わせたカスタマイズができる、という商品性のため、設定できる組み合わせが膨大となっています。
    さらに、昨年7月にリリースした商品であることもあり、今後機能追加をどんどん行うため、リリース頻度を上げたいという要件もあります。

    そのため、テストの自動化が望まれますが、多機能で組み合わせ多数ということもあり、単体テストだけではカバーが難しいため、
    E2Eテストの自動化を行うことになりました。
    E2Eテストとは、画面上の操作から画面上のアウトプットでの検証のことで、外部仕様を満たすことを確認するものになります。
  • E2Eテストの自動化ですが、難しいものです。

    まず、操作を「実装する」必要があると言うことが上げられます。
    よくある誤解として、ブラウザ上での操作を記録・再生するだけではないのか?という考えを持っている人がいますが、実際は
    「どの要素」を「どう操作するか」の実装をしていく必要があります。

    たとえば、保存ボタンをクリックするためには、保存ボタンをCSS SelectorやXpathで取得し、その要素に対してクリックを実行する
    というのをスクリプトで書いていくことになります。
    また、操作は1つの操作で完結することはなく、基本的にはステップを踏むものになります。
    たとえば、編集画面を表示して、フォームの入力値を変更して、保存ボタンを押して、閲覧画面が表示される、といった形です。
    このときに、タイミング問題として、次の操作をするときにまだ描画が完了していない、ということが発生することがあります。
    編集画面を表示した後、まだ表示されていない入力フォームにキー入力しようとすると、要素が見つからずにテストが失敗してしまいます。
    これは操作と操作の間にwaitを入れることで回避しますが、このような問題でテストが失敗する場合がある、というのは
    前提として考えておく必要があります。
  • また、何を正解とするか?どう検証するか?を検討して実装する必要がある、というのも難しさの1つです。
    よく出てくる話として画像比較がありますが、これは肉眼では全く同じに見える場合でもピクセル単位のずれが多く発生してしまう場合が多々あり、安定しません。
    そのため、要素から取得される値を比較する必要がありますが、このためには操作と同様の実装に加えて、その値がどうなっていればテストOKとするか、というのを検討する必要があります。
  • これらを踏まえると、方針としては「操作」「検証」の内容を限定することが重要になります。
    この中で効果を出すために、データのパターンに対して同じ操作手順を繰り返し行う必要があるようなテストに限定します。
    操作手順をシナリオとしてスクリプトで実装し、そこにデータを食わせていくことで、手動では困難な膨大なパターンに対するテストを自動で行える様になります。
  • ここからはタイトルの内容について、実装部分を説明します。
  • まず、Selenium WebDriverですが、これは自動化ツールとして最もメジャーなものですが、ブラウザ上の操作を実現するライブラリと考えると良いと思います。
    主要言語で提供されています。
  • テストスクリプトはブラウザとは完全に切り離して実装するため、好きな言語を使えます。
    今回の場合、Pythonを選択しました。

    それと、自動テストなのでテストフレームワークを利用すると良いです。
    今回はpytestを利用します。
    pytestはテスト結果をjUnit形式で出力してくれるので、CIと連携して結果の表示もできます。
  • フォルダ構成としてはこのようになっています。
    テストランナーで、テストケースを表すデータを読み込み、対象のシナリオで実行します。
    また、Seleniumの王道のデザインパターンであるPageObjectパターンも利用します。
    画面をオブジェクトと扱うことで、特定の要素に対する操作を一元管理できます。

    今回、テストケースに関してはyamlで記述します。
    シナリオはそれぞれスクリプトで書いていきますが、共通処理をかいたClassを全シナリオに継承させる、ということをしています。
  • 具体的なスクリプトも紹介したいのですが、時間の都合上省略します。発表資料は後程公開しますので、詳細はそちらでご確認ください。
  • このように実装したものを、以下のコマンドで実行できます。
    JUnit形式の結果出力をオプションで指定しています。

    Jenkinsではこのように結果を一覧で見ることができます。
  • これをCIに組み込むことですが、自動テストを形骸化させないために、非常に重要になります。
    1日1回自動実行させるようにして、テストNGがあれば担当者に通知します。
    テストNGを必ず解決することも重要です。
  • 最後に、E2Eテストのポイントをまとめておきます。
    以上です。ありがとうございました。
  • Selenium WebDriver + python で E2Eテスト自動化

    1. 1. Selenium WebDriver + Python で E2Eテスト自動化 2017年3月24日 株式会社ジャストシステム EPS事業部商品開発部 小池恵理
    2. 2. 背景 1 自己紹介 BtoB向けWebアプリケーションの開発担当(主にフロント)。 JUST.SFAの品質保証担当。一環としてテスト自動化の検討~実施。 JUST.SFA 営業管理システム(クラウドサービス) ユーザー企業の業務に直結。品質重要。 多機能で用途に合わせてカスタマイズできる。組み合わせが膨大。 機能拡張・追加したい。リリース頻度上げたい。 E2E(End to End)テストを自動で実行~検証することで、 外部仕様どおりの動作を保証しながら開発を進めたい。
    3. 3. 2 E2Eテスト自動化の難しさ① 操作を「実装する」 • 「手動テストをそのまま繰り返し実行できる」わけではない • よくある誤解 • 「記録・再生するだけ」という認識の人への説得が必要 • 「どの要素」を「どう操作するか」の実装 • 例:「保存ボタン」を「クリックする」 • 画面上からの要素取得(CSS Selector、XPath) • タイミング問題(waitの設定) • バグではなくてもテストが失敗する場合はある
    4. 4. 3 E2Eテスト自動化の難しさ② 何を正解とするか?どう検証するか? • 正解データとする画像との比較 → 安定しない • 要素から取得される値の比較 検証したい内容について、どの要素の値がどうなっていれば 正解とするかを検討し実装する必要がある。
    5. 5. 4 方針 「操作」「検証」の内容を限定することが重要。 同じ「操作」「検証」を実装し、入力値を変えることで、手 動テストでは困難な多くの組み合わせについての自動検証を 可能とする。(データ駆動テスト) login(username,password) open_panel(panel_id) assert_panel_name() シナリオ データ # username password panel_id 001 user0001 11111111 1 002 user0002 22222222 2 ・ ・ ・ ・ ・ ・ ・ ・ 入力
    6. 6. 5 本発表のタイトル Selenium WebDriver + Python で E2Eテスト自動化
    7. 7. Selenium WebDriver ブラウザ上の操作を実現するライブラリ。 ブラウザ自動テストツールとして最もメジャーで、フリーで使える。 主要言語で提供されている。 Java / C# / Ruby / Python / Javascript 6
    8. 8. 7 Python テストスクリプトはプロダクトとは完全に切り離して実装するため、プ ロダクトと同一言語である必要はない。 テストフレームワークを利用する。 • 標準のunittestは使いづらいのでpytestを採用。 • 結果をJUnit形式で出力してくれる。 • Jenkinsと連携して結果表示できる。
    9. 9. フォルダ構成 8 rootdir/ ├test_runner.py ├data/ │ ├case_A001.yaml │ ├case_A002.yaml │ └… ├senario/ │ ├base.py │ ├senarioA.py │ ├senarioB.py │ └… └page/ ├login.py ├main.py └… テストランナー テストケースA001のデータ(yaml) シナリオの継承元。シナリオ間共通処理。 シナリオA(「操作」「検証」のフロー) ログイン画面のページオブジェクト メイン画面のページオブジェクト PageObjectパターンの適用
    10. 10. テストランナー 9 test_runner.yaml
    11. 11. データ 10 data/case_A001.yaml data/case_A002.yaml
    12. 12. シナリオ 11 senario/senairoA.py senario/senairoB.py
    13. 13. シナリオ(継承元) 12 senario/base.py
    14. 14. ページ 13 page/main.py
    15. 15. 14 実行~結果の確認 以下のコマンドでテストを実行。 Jenkins上で結果表示までできる。
    16. 16. CIに組み込む 自動テストを形骸化させないために、重要。 15 検証対象環境 自動テスト実行環境担当者 ①データの初期化、最新版への更新 ②テスト実行 ③テスト結果 レポート ④NGあれば アラート
    17. 17. E2Eテスト自動化 ポイント 16 特徴 「操作」「検証」の実装が必要。 バグではなくてもテストNGとなる場合はある。 方針 自動検証の範囲を限定する。 スクリーンショットで検証しない。(エビデンスとして利用) 保守性を考慮した設計にする。(データ駆動テスト、PageObject パターン) CIに組み込み、テストNGを放置せずに解決する。(NGケースを再 実行できる設計、担当者のアサイン)

    ×