Downloaded 50 times
Uploaded byHiroko Tamagawa
20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」
システムテスト自動化カンファレンス2013（http://kokucheese.com/event/index/118294/）にて発表した内容です。UI変更に強い自動ブラウザテストの作り方についての資料です。
More Related Content
Similar to 20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」
![テスト自動化ツール[Selenium]を検討してみて](https://cdn.slidesharecdn.com/ss_thumbnails/20160723selenium-160724074540-thumbnail.jpg?width=640&height=640&fit=bounds)
20131201 テスト自動化カンファレンスLT「激しいUI変更との戦い」
- 1.
- 2. 自己紹介 名前：玉川 紘子（たまがわ ひろこ） 所属：株式会社SHIFTソフトウェアテスト事業部 コミュニティ：STAR（テスト自動化研究会） 日本Jenkinsユーザ会 2
- 3.
- 4. 本日のテーマ GUIベースの自動テストを保守すること • 前提 – GUIを通してエンドユーザ操作を代替する自動テスト –ツールはSeleniumを使用 • 課題 – 自動テストの保守性を高めるにはどうしたら良いか？ • アプリケーション変更時のメンテナンスコストが低いこと • メンテナンス作業自体がやりやすいこと • 非プログラマでも対応できること • 本日のスコープ「外」 – 自動テスト初期作成の効率化 4
- 5.
- 6. なぜ保守が大変になってしまうのか？ • その２：可読性の問題 – 失敗時の対応 –どこで何をやっているかが分かりにくい ありがちなケース • テストケースを書いた人以外は解析してくれない • 「自動テストだから失敗したのでは？」という理不尽な疑い • テストの手順と確認項目がパッと見て分からない 6
- 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. 作戦② テストケースの「素」をメンテする • スクリプト自体ではなく抽象化したレベルでメン テナンス –スクリプトはそこから自動生成する – HTML要素のパスなどは一元管理 – 人の目にも読みやすいシナリオ 人が見て分かる テストケース 自動生成 実行可能な テストケース 変換ルール ▲こちらをメンテナンス 8
- 9. STEP1 テスト対象のアプリケーションと 会話するための基本動作を定義する • Seleniumの１コマンドである「クリックする」「テキスト を入力する」よりもほんの少しだけ抽象化する –「メニューを選択する」 – 「編集中のデータの削除を行う」 – 「一覧からデータの検索を行う」 ユーザにとって意味のある単位でまとめると、 多少UIが変わってもこの単位の中で変更すれば 済むことがほとんど 9
- 10. STEP2 基本動作と対象を組み合わせて 各機能の操作用言語を作る • 例 –「社員一覧画面で社員名を確認する」 • 基本動作：特定の場所のテキストの内容を確認する × • 対象：社員一覧画面の中の社員名 – 「社員登録画面で電話番号を入力する」 • パラメタも指定できるようにする – 「社員一覧画面で社員名を確認する(name)」 – 「社員登録画面で電話番号を入力する(phone)」 10
- 11.
- 12.
- 13. スクリプトの「素」をメンテするメリット • 保守性の向上 – UIが変わってもスクリプトの変更箇所が最低限で済む •可読性の向上 – どんな操作を行っているかが一目で分かる – 初心者でもメンテしやすい • ＋αのメリット – ログ出力などの共通処理を入れ込みやすい • 「キーワード駆動テスト」という考え方を参考にして います 13
- 14. まとめ • GUIベースの自動テストはUI変更との戦い • 保守性を高めるために –開発・テスト間のコミュニケーションを取って製品コー ドも改善していく – スクリプトの自動記録に頼らず、変更箇所を少なくまと められるように工夫する • TODO – WebDriver対応 – 脱Excel… 14
- 15.