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

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