1

激しい UI 変更との戦い

テスト自動化研究会玉川紘子

システムテスト自動化カンファレンス 2013

2

自己紹介

名前：玉川 紘子（たまがわ ひろこ）所属：株式会社 SHIFT 　ソフトウェアテスト事業部コミュニティ： STAR （テスト自動化研究会）　　　　　　　日本 Jenkins ユーザ会

3

CI ・自動テストなんでも屋さんとして活動中

開発言語： Java/PHP/Ruby など業務でよく使うツール： Jenkins/Selenium

メイン業務は CI ・自動テストに関するなんでもお手伝い

運用方針の提案

実際に稼働する CI 環境の構築

テストの書き方指南

Jenkins ってどうやって使えばいいんだっけ？

Selenium でテストを書いてみたい

んだけど…

4

本日のテーマGUI ベースの自動テストを保守すること

• 前提– GUI を通してエンドユーザ操作を代替する自動テスト– ツールは Selenium を使用

• 課題– 自動テストの保守性を高めるにはどうしたら良いか？

• アプリケーション変更時のメンテナンスコストが低いこと• メンテナンス作業自体がやりやすいこと• 非プログラマでも対応できること

• 本日のスコープ「外」– 自動テスト初期作成の効率化

5

なぜ保守が大変になってしまうのか？

• その１：度重なる仕様変更（ UI 、文言）

– 類似箇所の一斉変更が大変– 不具合とテストケース不備の切り分けが大変

これまで動いていたケースの大部分が動かなくなってしまうことがある

6

なぜ保守が大変になってしまうのか？

• その２：可読性の問題– 失敗時の対応– どこで何をやっているかが分かりにくい

ありがちなケース• テストケースを書いた人以外は解析してくれない• 「自動テストだから失敗したのでは？」という理不尽な疑い• テストの手順と確認項目がパッと見て分からない

7

作戦①　テストしづらい製品コードは指摘する

• 開発者とのコミュニケーションを恐れない– 結果的に、コードも綺麗になる

• 例①：要素に ID や class がない

• 例②：純粋なテスト対象を切り分けられない

<a href=“...”> 社員登録 </a><a href=“...”> 社員一覧 </a>

<a id=“user_register” href=“...”> 社員登録 </a><a id=“user_list” href=“...”> 社員一覧 </a>

◀ 文言で指定するしかなく変更に弱いBefore

After

<li> メールアドレス： xxxxx@example.com</li>

<li> メールアドレス：<span id=“mail”>xxxxx@example.com</span>

</li>

Before

After

▲ この部分だけテストしたいのに…

8

作戦②　テストケースの「素」をメンテする　

• スクリプト自体ではなく抽象化したレベルでメンテナンス– スクリプトはそこから自動生成する– HTML 要素のパスなどは一元管理– 人の目にも読みやすいシナリオ

人が見て分かるテストケース 実行可能な

テストケース変換ルール

自動生成

▲ こちらをメンテナンス

9

STEP1 テスト対象のアプリケーションと会話するための基本動作を定義する　

• Selenium の１コマンドである「クリックする」「テキストを入力する」よりもほんの少しだけ抽象化する– 「メニューを選択する」– 「編集中のデータの削除を行う」– 「一覧からデータの検索を行う」

ユーザにとって意味のある単位でまとめると、多少UI が変わってもこの単位の中で変更すれば済むことがほとんど

10

STEP2 基本動作と対象を組み合わせて各機能の操作用言語を作る

• 例– 「社員一覧画面で社員名を確認する」

• 基本動作：特定の場所のテキストの内容を確認する　　 ו 対象：社員一覧画面の中の社員名

– 「社員登録画面で電話番号を入力する」

• パラメタも指定できるようにする– 「社員一覧画面で社員名を確認する (name) 」– 「社員登録画面で電話番号を入力する (phone) 」

11

STEP3個別のテストシナリオを作る

• 例▼STEP2 で定義した　個別機能の操作

▼操作のパラメタ　（複数パターン作成可能）

12

デモ

13

スクリプトの「素」をメンテするメリット

• 保守性の向上– UI が変わってもスクリプトの変更箇所が最低限で済む

• 可読性の向上– どんな操作を行っているかが一目で分かる– 初心者でもメンテしやすい

• ＋ αのメリット– ログ出力などの共通処理を入れ込みやすい

• 「キーワード駆動テスト」という考え方を参考にしています

14

まとめ

• GUI ベースの自動テストは UI 変更との戦い

• 保守性を高めるために– 開発・テスト間のコミュニケーションを取って製品

コードも改善していく– スクリプトの自動記録に頼らず、変更箇所を少なくま

とめられるように工夫する

• TODO– WebDriver 対応– 脱 Excel…

15

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