Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GUI自動テストの保守性を高めるには

21,946 views

Published on

2014/12/14に開催された「システムテスト自動化カンファレンス2014」(http://connpass.com/event/9618/)の発表スライドです。

Published in: Software
  • Be the first to comment

GUI自動テストの保守性を高めるには

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

×