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.

20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」

23,936 views

Published on

システムテスト自動化カンファレンス2013(http://kokucheese.com/event/index/118294/)にて発表した内容です。UI変更に強い自動ブラウザテストの作り方についての資料です。

Published in: Technology

20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」

  1. 1. システムテスト自動化カンファレンス2013 激しいUI変更との戦い テスト自動化研究会 玉川紘子 1
  2. 2. 自己紹介 名前:玉川 紘子(たまがわ ひろこ) 所属:株式会社SHIFT ソフトウェアテスト事業部 コミュニティ:STAR(テスト自動化研究会) 日本Jenkinsユーザ会 2
  3. 3. CI・自動テストなんでも屋さんとして活動中 開発言語:Java/PHP/Rubyなど 業務でよく使うツール:Jenkins/Selenium メイン業務はCI・自動テストに関するなんでもお手伝い Jenkinsってどうやって 使えばいいんだっけ?  運用方針の提案  実際に稼働するCI環境の構築 Seleniumで テストを書いてみたい んだけど…  テストの書き方指南 3
  4. 4. 本日のテーマ GUIベースの自動テストを保守すること • 前提 – GUIを通してエンドユーザ操作を代替する自動テスト – ツールはSeleniumを使用 • 課題 – 自動テストの保守性を高めるにはどうしたら良いか? • アプリケーション変更時のメンテナンスコストが低いこと • メンテナンス作業自体がやりやすいこと • 非プログラマでも対応できること • 本日のスコープ「外」 – 自動テスト初期作成の効率化 4
  5. 5. なぜ保守が大変になってしまうのか? • その1:度重なる仕様変更(UI、文言) これまで動いていたケースの 大部分が動かなくなってしまうことがある – 類似箇所の一斉変更が大変 – 不具合とテストケース不備の切り分けが大変 5
  6. 6. なぜ保守が大変になってしまうのか? • その2:可読性の問題 – 失敗時の対応 – どこで何をやっているかが分かりにくい ありがちなケース • テストケースを書いた人以外は解析してくれない • 「自動テストだから失敗したのでは?」という理不尽な疑い • テストの手順と確認項目がパッと見て分からない 6
  7. 7. 作戦① テストしづらい製品コードは指摘する • 開発者とのコミュニケーションを恐れない – 結果的に、コードも綺麗になる • 例①:要素にIDやclassがない Before <a href=“...”>社員登録</a> <a href=“...”>社員一覧</a> After <a id=“user_register” href=“...”>社員登録</a> <a id=“user_list” href=“...”>社員一覧</a> ◀文言で指定するしかなく変更に弱い • 例②:純粋なテスト対象を切り分けられない Before <li>メールアドレス:xxxxx@example.com</li> ▲この部分だけテストしたいのに… After <li>メールアドレス: <span id=“mail”>xxxxx@example.com</span> </li> 7
  8. 8. 作戦② テストケースの「素」をメンテする • スクリプト自体ではなく抽象化したレベルでメン テナンス – スクリプトはそこから自動生成する – HTML要素のパスなどは一元管理 – 人の目にも読みやすいシナリオ 人が見て分かる テストケース 自動生成 実行可能な テストケース 変換ルール ▲こちらをメンテナンス 8
  9. 9. STEP1 テスト対象のアプリケーションと 会話するための基本動作を定義する • Seleniumの1コマンドである「クリックする」「テキスト を入力する」よりもほんの少しだけ抽象化する – 「メニューを選択する」 – 「編集中のデータの削除を行う」 – 「一覧からデータの検索を行う」 ユーザにとって意味のある単位でまとめると、 多少UIが変わってもこの単位の中で変更すれば 済むことがほとんど 9
  10. 10. STEP2 基本動作と対象を組み合わせて 各機能の操作用言語を作る • 例 – 「社員一覧画面で社員名を確認する」 • 基本動作:特定の場所のテキストの内容を確認する × • 対象:社員一覧画面の中の社員名 – 「社員登録画面で電話番号を入力する」 • パラメタも指定できるようにする – 「社員一覧画面で社員名を確認する(name)」 – 「社員登録画面で電話番号を入力する(phone)」 10
  11. 11. STEP3 個別のテストシナリオを作る • 例 ▼STEP2で定義した 個別機能の操作 ▼操作のパラメタ (複数パターン作成可能) 11
  12. 12. デモ 12
  13. 13. スクリプトの「素」をメンテするメリット • 保守性の向上 – UIが変わってもスクリプトの変更箇所が最低限で済む • 可読性の向上 – どんな操作を行っているかが一目で分かる – 初心者でもメンテしやすい • +αのメリット – ログ出力などの共通処理を入れ込みやすい • 「キーワード駆動テスト」という考え方を参考にして います 13
  14. 14. まとめ • GUIベースの自動テストはUI変更との戦い • 保守性を高めるために – 開発・テスト間のコミュニケーションを取って製品コー ドも改善していく – スクリプトの自動記録に頼らず、変更箇所を少なくまと められるように工夫する • TODO – WebDriver対応 – 脱Excel… 14
  15. 15. ご清聴ありがとうございました。 15

×