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

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

2014.12.14

伊藤望(TRIDENT)

自己紹介

伊藤望

「システムテスト自動化標準ガイド」12章執筆

会社

株式会社TRIDENT 代表取締役

テスト自動化の支援を行うベンチャー

www.trident-qa.com (ブログあり)

コミュニティ

「日本Seleniumユーザーコミュニティ」を主宰

http://www.trident-qa.com/



保守性

今日のテーマ

テストのメンテナンス工数はこれまで、テスト自動化の多くの試みを死に追いやった。

「システムテスト自動化標準ガイド」

GUI(画面)自動テストのコスト

テスト作成コスト最初の1回

テスト保守コストテストを実行する限り

テストが失敗したときの原因調査

テスト対象システムのUI変更に伴うスクリプト修正

保守コストをいかに減らしていくか

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のコードを生成

生成ロジックは自作するケースが多い



メリット

プログラムを読み書きする必要がない

デメリット

プログラミング言語ほど柔軟な処理が書けない

メジャーなツールが無いため、独自仕様になりがち

バージョン管理システムとの親和性がイマイチ

それぞれのメリット・デメリット

Selenium IDEで記録したスクリプトをそのまま使うのはやめた方がいいです。

非プログラマによる利用

柔軟な処理

スクリプト共通化

IDEキャプチャリプレイ ○ × ×

IDE表形式管理 ○ △ △

プログラム × ○ ○

Excel等 ○ △ △

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

グリーンに保つための3ステップ

「テストをグリーンに保つ」 = 「失敗したテストを放置せず、きちんとメンテナンスし続ける」

3ステップ

1. できるだけ失敗させない

2. 失敗したら原因を突き止める

3. 原因が分かったら修正する

１．できるだけ失敗させない

１．できるだけ失敗させない

テストはなぜ失敗するのか

テスト対象システムのバグ

テスト対象システムの仕様変更

テストツール自体のバグ

それ以外

一番よく見かけるのは、、

「不安定テスト」「環境準備失敗」「DB定義変更作業ミス」「テストデータ不整合」等

「それ以外」

バグを見つけるためにテストしているわけで、バグが出るのは悪いことではない

対策

静的解析、単体テスト、APIテストの方が失敗時の時間ロスが少ないので、そちらを先に実行する

１．できるだけ失敗させない「テスト対象システムのバグ」

対策

仕様変更に強い方法で要素指定

テスト対象システムが、id属性などをできるだけ提供

「APIテスト」などの仕様変更に強いテストを増やす

１．できるだけ失敗させない「テスト対象システムの仕様変更」

画面操作の実行エンジンは、非常に実装難易度が高く、バグがつきもの

対策

実績のある実行エンジン(Selenium WebDriver等)を選び、リスクを軽減する

１．できるだけ失敗させない「テストツール自体のバグ」

主な原因

画面ロードが完了する前に操作を始めてしまう

不安定なネットワーク

対策

テストスクリプトに適切に待ち処理を入れる

失敗したらリトライ処理を入れる

１．できるだけ失敗させない「その他」 - 「不安定テスト」

主な原因

コンパイル&デプロイ作業手順ミス

テスト用サーバの再起動失敗

対策

コンパイル&デプロイフローから手作業を排除。不安定な箇所は地道に改善

環境準備チェック用テストをいくつか最初に流し、失敗したらそこでやめる

１．できるだけ失敗させない「その他」 - 「環境準備失敗」

主な原因

「SQL適用」「コンパイル」「サーバ再起動」の時間差で発生

SQLのCommit/Push忘れ

対策

コンパイル&デプロイフローから手作業を排除。

「Commit/Push忘れ」は、あまりいい解決策が。。

１．できるだけ失敗させない「その他」 - 「DB定義変更作業ミス」

主な原因

誰かが、手動テストのために設定を書き換えた

テスト失敗の原因調査に流したテストで、ゴミデータが作られた

「次回から気を付けましょう」で終わることもあり、テンションが下がる。。

対策

「テスト環境は毎回クリーンなものを使用」「テスト実行前に前回のゴミデータを削除」などの工夫

１．できるだけ失敗させない「その他」 - 「テストデータ不整合」

１．できるだけ失敗させないバグ以外の原因でのテスト失敗が多いと

どうせまたバグ

じゃないんだろ調査が後回しに

1時間かけて調査したのに、DB不整合が原因とか…

自動化の

やる気減退

２．失敗したら原因を突き止める

テスト結果に誰でも簡単にアクセスできる

メールやブラウザ上で見られると結果確認が簡単

チーム全体で結果を共有し、テスト失敗への関心を高める

Seleniumだと、Jenkins等と組み合わせるのがお勧め

２．失敗したら原因を突き止めるすみやかに原因を突き止めるには

画面キャプチャ・動画・サーバーログなど、エラー調査に必要なデータを残す

テストを再実行しての原因調査は、心理的ハードルが高く後回しになりがち

テスト結果を見てすぐ原因が分かれば、対応する気がおきやすい


エラーになったテストだけを手元で流して確認できる

短い、独立したテストを多数作る

「1時間かけて先頭から全部流さないと結果確認できない」だと、調査が辛い

テストスクリプトはバージョン管理し、誰でも手元に取得できるように


３．原因が分かったら修正する

３．原因が分かったら修正する

修正を容易にするためには

スクリプトを共通化し、

メンテナンスの負荷を減らす

保守性の高いスクリプトを作る技術は、保守性の高いプログラムを作る技術と多くの共通点がある。



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("[email protected]"); 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

伊藤望 [email protected] テスト

… … …

… … …


データ

まとめ

各種Seleniumツールには可読性・保守性の面でトレードオフがある

保守性を高めるために重要なこと

テストの失敗要因を減らす

失敗調査コストを減らす

共通化する

「ページオブジェクトデザインパターン」は効果的な手法

宣伝

1. 読みやすさと柔軟性のトレードオフ

プログラマだって表形式のテストスクリプトは読みやすい

でも、プログラムで書く方が柔軟な記述ができる

2. 読みやすさと共通化のトレードオフ

同じ処理は共通化した方がメンテナンスコストが下がる

でも、共通化しすぎるとスクリプトが読み辛い

今日登場した問題

Sahagin

Sahagin

オープンソースで作りました

テストスクリプト&テスト結果のHTMLレポート

1. 各メソッドに@TestDocで説明をつける

2. テストを実行する

Sahagin 何ができるか

3. Jenkins上で、スクリプトを表形式で確認できる


画面キャプチャは

自動取得

4. ネストしたメソッド呼び出しも見られる

5. 共通化しても、スクリプトの内容が分かりやすい


Sahagin

https://github.com/SahaginOrg

バージョン0.1ではJavaのみ対応

ドキュメントまだなので、この後作ります

リリース作業まだなので、この後やります




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

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

Software