GUI自動テストの保守性を高めるには
- 1. GUI自動テストの保守性を高めるには 2014.12.14 伊藤 望(TRIDENT)
- 2. 自己紹介 伊藤 望 「システムテスト自動化標準ガイド」12章執筆 会社 株式会社TRIDENT 代表取締役 テスト自動化の支援を行うベンチャー www.trident-qa.com (ブログあり) コミュニティ 「日本Seleniumユーザーコミュニティ」を主宰
- 3. 保守性 今日のテーマ
- 5. GUI(画面)自動テストのコスト テスト作成コスト 最初の1回 テスト保守コスト テストを実行する限り テストが失敗したときの原因調査 テスト対象システムのUI変更に伴うスクリプト修正 保守コストをいかに減らしていくか Seleniumを題材に話します
- 6. 今日のトピック Seleniumとその保守性 いかにしてテストをグリーンに保つか テストスクリプトの共通化
- 8. よく見るSelenium利用パターン3つ 1.キャプチャーリプレイ 2.プログラミング言語で記述 3.Excel等からスクリプト生成
- 9. １．キャプチャーリプレイ
- 11. １．キャプチャーリプレイ 手動画面操作を記録してスクリプト生成 Selenium IDE Selenium Builder (使用性に課題…)
- 12. １．キャプチャーリプレイ メリット 画面を操作するだけでスクリプト生成 デメリット 読みにくいスクリプトになりがち スクリプト共通化が行われないので、スクリプト修正の作 業が大変
- 13. よくある素晴らしいテストツールのデモサイト １．キャプチャーリプレイ 読みにくいスクリプト なんか読みやすそう! 記録
- 14. 現実世界のウェブサイト １．キャプチャーリプレイ 読みにくいスクリプト 記録 よく分からない https://twitter.com/
- 15. 1.「送信ボタンのデザイン変えました」 2.送信ボタンをクリックしているスクリプト全修正 １．キャプチャーリプレイ スクリプト修正の作業が大変
- 16. 記録した後、スクリプトの手直しがかなり必要 Selenium IDEの利点は、記録機能よりも、 見やすい表形式でスクリプトを管理・編集 プログラムを書くのに比べ、覚えることが少ない インストール&利用が簡単 １．キャプチャーリプレイ
- 17. Selenium IDEを使った表形式管理の課題 複雑なロジックを書くのは結構大変 If文, For文, Try-catch文 SelBlocksプラグイン 処理の共通化 UIマップファイル 「明日の日付の取得」などの処理 JavaScriptを駆使 だんだんプログラムを書いているのと変わらなくなる １．キャプチャーリプレイ
- 18. ２．プログラミング言語で記述
- 19. ２．プログラミング言語で記述 Java、Ruby等々のプログラミング言語でテストスクリ プトを記述 Selenium WebDriverや、それをラップしたツール
- 20. ２．プログラミング言語で記述 メリット 共通化の技法を駆使して、メンテナスコストを減らせる If文, For文, Try-catch文等の柔軟な処理の記述が容易 統合開発環境(Eclipse等)のコード補完、文法チェック、リ ファクタリングなどの機能を活用できる デメリット プログラムが読み書きできる必要がある
- 21. ２．プログラミング言語で記述 様々な周辺オープンソースツール・クラウドサービス との親和性が高い エディタ テストフレーム ワーク バージョン 管理 CI 実行端末 クラウド SauceLabs BrowserStack Travis CI
- 23. Excelファイルから、Selenium IDEやSelenium WebDriverのコードを生成 生成ロジックは自作するケースが多い ３．Excel等からスクリプト生成
- 24. ３．Excel等からスクリプト生成 メリット プログラムを読み書きする必要がない デメリット プログラミング言語ほど柔軟な処理が書けない メジャーなツールが無いため、独自仕様になりがち バージョン管理システムとの親和性がイマイチ
- 25. それぞれのメリット・デメリット Selenium IDEで記録したスクリプトをそのまま 使うのはやめた方がいいです。 非プログラマ による利用 柔軟な 処理 スクリプト 共通化 IDEキャプチャリプレイ ○ × × IDE表形式管理 ○ △ △ プログラム × ○ ○ Excel等 ○ △ △
- 28. グリーンに保つための3ステップ 「テストをグリーンに保つ」 = 「失敗したテストを放置 せず、きちんとメンテナンスし続ける」 3ステップ 1.できるだけ失敗させない 2.失敗したら原因を突き止める 3.原因が分かったら修正する
- 29. １．できるだけ失敗させない
- 30. １．できるだけ失敗させない テストはなぜ失敗するのか テスト対象システムのバグ テスト対象システムの仕様変更 テストツール自体のバグ それ以外 一番よく見かけるのは、、 「不安定テスト」「環境準備失敗」「DB定義変更作業ミス」 「テストデータ不整合」等 「それ以外」
- 31. バグを見つけるためにテストしているわけで、バグ が出るのは悪いことではない 対策 静的解析、単体テスト、APIテストの方が失敗時の時間 ロスが少ないので、そちらを先に実行する １．できるだけ失敗させない 「テスト対象システムのバグ」
- 32. 対策 仕様変更に強い方法で要素指定 テスト対象システムが、id属性などをできるだけ提供 「APIテスト」などの仕様変更に強いテストを増やす １．できるだけ失敗させない 「テスト対象システムの仕様変更」
- 33. 画面操作の実行エンジンは、非常に実装難易度が 高く、バグがつきもの 対策 実績のある実行エンジン(Selenium WebDriver等)を選び、 リスクを軽減する １．できるだけ失敗させない 「テストツール自体のバグ」
- 34. 主な原因 画面ロードが完了する前に操作を始めてしまう 不安定なネットワーク 対策 テストスクリプトに適切に待ち処理を入れる 失敗したらリトライ処理を入れる １．できるだけ失敗させない 「その他」 - 「不安定テスト」
- 35. 主な原因 コンパイル&デプロイ作業手順ミス テスト用サーバの再起動失敗 対策 コンパイル&デプロイフローから手作業を排除。不安定な 箇所は地道に改善 環境準備チェック用テストをいくつか最初に流し、失敗し たらそこでやめる １．できるだけ失敗させない 「その他」 - 「環境準備失敗」
- 36. 主な原因 「SQL適用」「コンパイル」「サーバ再起動」の時間差で発生 SQLのCommit/Push忘れ 対策 コンパイル&デプロイフローから手作業を排除。 「Commit/Push忘れ」は、あまりいい解決策が。。 １．できるだけ失敗させない 「その他」 - 「DB定義変更作業ミス」
- 37. 主な原因 誰かが、手動テストのために設定を書き換えた テスト失敗の原因調査に流したテストで、ゴミデータが作 られた 「次回から気を付けましょう」で終わることもあり、テンショ ンが下がる。。 対策 「テスト環境は毎回クリーンなものを使用」「テスト実行前 に前回のゴミデータを削除」などの工夫 １．できるだけ失敗させない 「その他」 - 「テストデータ不整合」
- 38. １．できるだけ失敗させない バグ以外の原因でのテスト失敗が多いと どうせまたバグ じゃないんだろ 調査が後回しに 1時間かけて調査し たのに、DB不整合 が原因とか… 自動化の やる気減退
- 39. ２．失敗したら原因を突き止める
- 40. テスト結果に誰でも簡単にアクセスできる メールやブラウザ上で見られると結果確認が簡単 チーム全体で結果を共有し、テスト失敗への関心を高める Seleniumだと、Jenkins等と組み合わせるのがお勧め ２．失敗したら原因を突き止める すみやかに原因を突き止めるには
- 41. 画面キャプチャ・動画・サーバーログなど、エラー調 査に必要なデータを残す テストを再実行しての原因調査は、心理的ハードルが高く 後回しになりがち テスト結果を見てすぐ原因が分かれば、対応する気がお きやすい ２．失敗したら原因を突き止める すみやかに原因を突き止めるには
- 42. エラーになったテストだけを手元で流して確認できる 短い、独立したテストを多数作る 「1時間かけて先頭から全部流さないと結果確認でき ない」だと、調査が辛い テストスクリプトはバージョン管理し、誰でも手元に取得で きるように ２．失敗したら原因を突き止める すみやかに原因を突き止めるには
- 43. ３．原因が分かったら修正する
- 44. ３．原因が分かったら修正する 修正を容易にするためには スクリプトを共通化し、 メンテナンスの負荷を減らす
- 47. テストスクリプトの共通化 DRY(Don’t Repeat Yourself)の原則は、テストスクリプ トの場合にも有効 テスト対象のUIが変わった場合のスクリプト修正の 負荷を軽減 しかし、安直な共通化は、問題を引き起こす
- 48. 共通化の問題① やりすぎると分かりにくいスクリプトに @Test public void 分かりにくいスクリプトの例() { goToMainMenu("新規予約"); setRequiredInfo("伊藤望","イトウノゾミ",0,1); setAllMailCheck(false); goNextAndConfirm(); }
- 49. 共通化の問題② 目的の共通関数を見つけられず、同じものを何個も 作ってしまうことも よく分かんないし、 自分で書いちゃう方 が早いな… 探しにくい共通ライブラリの例
- 50. Selenium界隈で広く利用されている 画面情報を1つのクラスに集約 １つのページに対し1つのページオブジェクトクラス テスト対象画面 テストスクリプト ページオブジェクトクラス ページオブジェクトデザインパターン
- 51. ページオブジェクトデザインパターン テスト対象画面 ページオブジェクトクラス ContactPage +setUserName(user) +setMailAddress(mail) +setOrganization(organization) +setSubject(subject) +setContent(content) +send()
- 52. ページオブジェクトデザインパターン テストスクリプトはこんな感じになる テストスクリプト ContactPage contact = new ContactPage(driver); contact.setUserName("伊藤望"); contact.setMailAddress("xxx@xxx.com"); contact.setSubject("テスト"); contact.setSubject("テスト投稿です"); contact.send();
- 53. ページオブジェクトデザインパターン メリット HTML要素の記述を隠蔽し、スクリプトが読みやすくなる 共通化基準がシンプルで明確なので、「誰かが作った使 いにくい共通メソッド」になりにくい。 ページ単位で共通メソッドがまとまっているので、目的の メソッドを見つけやすい
- 54. ページオブジェクトデザインパターン デメリット 直接スクリプトを書くのと比べ手間がかかる Selenium WebDriverのページオブジェクト生成ツールを 見つけたが、あまり使いやすくなかった。。 swd-recorder http://unmesh.me/2013/08/29/pageobject- generator-utility-for-selenium-webdriver/
- 55. ページオブジェクトのメソッドは、画面のUI構成に依 存しないように ページオブジェクトデザインパターン よりUI変更に強くするためには +setReserveYear(year) +setReserveMonth(month) +setReserveDay(day) UI変更 うまくいかなくなる! このページで行いたいのは「宿泊日を指定すること」 メソッドは「setReserveDate(year, month, day)」か 「setReserveDate(date)」がよい
- 56. 例) データ駆動テスト ページオブジェクトデザインパターン 他の共通化とも組み合わせられる contact.setUserName(user); contact.setMailAddress(mail); contact.setSubject(subject); contact.send(); user mail subject 伊藤望 xxx@xxx.com テスト … … … … … … テストスクリプト データ
- 57. まとめ 各種Seleniumツールには可読性・保守性の面でトレード オフがある 保守性を高めるために重要なこと テストの失敗要因を減らす 失敗調査コストを減らす 共通化する 「ページオブジェクトデザインパターン」は効果的な手法
- 58. 宣伝
- 59. 1.読みやすさと柔軟性のトレードオフ プログラマだって表形式のテストスクリプトは読みやすい でも、プログラムで書く方が柔軟な記述ができる 2.読みやすさと共通化のトレードオフ 同じ処理は共通化した方がメンテナンスコストが下がる でも、共通化しすぎるとスクリプトが読み辛い 今日登場した問題
- 60. Sahagin
- 62. 1.各メソッドに@TestDocで説明をつける 2.テストを実行する Sahagin 何ができるか
- 63. 3.Jenkins上で、スクリプトを表形式で確認できる Sahagin 何ができるか 画面キャプチャは 自動取得
- 65. Sahagin https://github.com/SahaginOrg バージョン0.1ではJavaのみ対応 ドキュメントまだなので、この後作ります リリース作業まだなので、この後やります
- 66. ご清聴ありがとうございました