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