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

1. GUI自動テストの保守性を高めるには 2014.12.14 伊藤望(TRIDENT)

2. 自己紹介 伊藤望 「システムテスト自動化標準ガイド」12章執筆 会社 株式会社TRIDENT 代表取締役 テスト自動化の支援を行うベンチャー www.trident-qa.com (ブログあり) コミュニティ 「日本Seleniumユーザーコミュニティ」を主宰

3. 保守性今日のテーマ

4. テストのメンテナンス工数はこれまで、テスト自動化の多くの試みを死に追いやった。「システムテスト自動化標準ガイド」

5. GUI(画面)自動テストのコスト テスト作成コスト最初の1回 テスト保守コストテストを実行する限り テストが失敗したときの原因調査 テスト対象システムのUI変更に伴うスクリプト修正 保守コストをいかに減らしていくか Seleniumを題材に話します

6. 今日のトピック Seleniumとその保守性 いかにしてテストをグリーンに保つか テストスクリプトの共通化

7. Seleniumとその保守性 いかにしてテストをグリーンに保つか テストスクリプトの共通化

8. よく見るSelenium利用パターン3つ 1.キャプチャーリプレイ 2.プログラミング言語で記述 3.Excel等からスクリプト生成

9. １．キャプチャーリプレイ

10. キャプチャーリプレイはテスト自動化ではない「システムテスト自動化標準ガイド」

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

22. ３．Excel等からスクリプト生成

23. Excelファイルから、Selenium IDEやSelenium WebDriverのコードを生成 生成ロジックは自作するケースが多い３．Excel等からスクリプト生成

24. ３．Excel等からスクリプト生成 メリット プログラムを読み書きする必要がない デメリット プログラミング言語ほど柔軟な処理が書けない メジャーなツールが無いため、独自仕様になりがち バージョン管理システムとの親和性がイマイチ

25. それぞれのメリット・デメリット Selenium IDEで記録したスクリプトをそのまま使うのはやめた方がいいです。非プログラマによる利用柔軟な処理スクリプト共通化 IDEキャプチャリプレイ ○ × × IDE表形式管理 ○ △ △ プログラム × ○ ○ Excel等 ○ △ △

26. ここからは、「プログラミング言語で記述」する場合の話

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. ３．原因が分かったら修正する 修正を容易にするためにはスクリプトを共通化し、メンテナンスの負荷を減らす

46. 保守性の高いスクリプトを作る技術は、保守性の高いプログラムを作る技術と多くの共通点がある。「システムテスト自動化標準ガイド」

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

61. Sahagin オープンソースで作りました テストスクリプト&テスト結果のHTMLレポート

62. 1.各メソッドに@TestDocで説明をつける 2.テストを実行する Sahagin 何ができるか

63. 3.Jenkins上で、スクリプトを表形式で確認できる Sahagin 何ができるか画面キャプチャは自動取得

64. 4.ネストしたメソッド呼び出しも見られる 5.共通化しても、スクリプトの内容が分かりやすい Sahagin 何ができるか

65. Sahagin https://github.com/SahaginOrg バージョン0.1ではJavaのみ対応 ドキュメントまだなので、この後作ります リリース作業まだなので、この後やります

66. ご清聴ありがとうございました

View stunning SlideShares in full-screen with the new iOS app!

SlideShare for iOS

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

Nozomi Ito (10 SlideShares)

Views

Actions

Embeds 0

Report content

Transcript