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

21,422 views

Published on

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

Published in: Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
21,422
On SlideShare
0
From Embeds
0
Number of Embeds
17,432
Actions
Shares
0
Downloads
41
Comments
0
Likes
12
Embeds 0
No embeds

No notes for slide

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

×