20140128 tel@cafe selenium編
- 1. CAMP powered by T.E.L@CAFE
テスト自動化のいろはとSSeelleenniiuumm CCAAMMPP
玉川紘子 / 太田健一郎
1
- 6. テスト自動化の誤解その①
「自動化で工数削減!!」
n ⾃自動テストの初回のサイクルは、⼤大体⼿手動の3倍の⼯工数がかかると⾔言
われている(ちなみに⽟玉川の所感では3倍で済めばだいぶいい⽅方。)
出典:
2011年JaSST九州
「テスト自動化の前に
押えておきたい3つのポイント」
6
- 7. テスト自動化の誤解その①
「自動化で工数削減!!」
n 確かに最終的な⽬目的の⼀一つは⼯工数削減
n でも、⾃自動化するコストが⾼高い上にすぐ使い捨て
られてしまうようなテストであれば⼿手動で済ませ
る判断も必要
n コストが低く繰り返し実施するテストが⾃自動化に
向いている
n 必ず通る重要なフロー
n 1つのフローに対してパターンが多いもの
n 例例:ECサイトの商品登録〜~商品購⼊入
n 例例:保険の⾒見見積取得
7
- 9. テスト自動化の誤解その②
「自動化でテストが速くなる」
n スピードではなく、⼈人がいなくても良良いということ
n IEを使ったテストとか結構遅い
n それでも⼟土⽇日・夜間に実⾏行行できることはメリット
n 実⾏行行して終わりではない
n 結果のOK/NGの確認
n NGの場合、どんな事象が起きているのか
n 不不具合なら報告が必要
n 不不具合でないならテストケースの修正が必要
n 逆に⾔言うと、これらの後処理理がなるべく楽になるよう
な⼯工夫をしておくと吉
9
- 10. テスト自動化の誤解その③
「自動化でテストが楽になる」
n テストは実⾏行行だけではない
n 計画、設計、実⾏行行、不不具合報告、分析、…
n (今話している)⾃自動化では実⾏行行しかカバーしない
n ⾃自動化特有の苦労も
n 「レイアウトが崩れていない」ことをどう判定
する?
n 「検索索結果が正しい」ことをどう判定する?
n ⼈人間なら⾃自然にやってくれることをテストケース
で細かく書かなければいけない
10
- 12. 自動化のおいしいポイント
n これまで出来なかったテストができる
n ⼯工数がかかり過ぎて間引きしていたテスト
n 1年年に1回しかできなかったテスト
⇒ 準備⼯工数がかかっても、これが出来ればおいしい
n 単純作業を機械に任せることで、⼈人間はもっと⾼高度度な
活動へ
n 複雑なシナリオの設計
n ユーザビリティテスト
n 正確なオペレーション
n どんなに退屈な単調な作業でも、何度度でも正確にこなしてくれ
る
12
- 13. 何ができれば自動テスト屋さんになれるのか
n ⼤大雑把に分けると2つの役割
n Automation Architect
n ツールの選定、テスト範囲の決定、フレームワーク作りなど
Automation Engineerが活動するための基盤を作る役割
n やや上級のエンジニアスキルが必要
n 開発側の制約と折り合いをつけながら、⼀一から⼟土台を築いてい
く楽しみ
n Automation Engineer
n 定められたフレームワークに従ってテストスクリプトを作成する
n 基本的なプログラミングのスキルがあればOK
n 例例えばSeleniumやSilkTestのようなツールでスクリプトを実装
n 書いたスクリプトがしっかり動いているのを⾒見見る快感
⇒ この後の太⽥田さんのセッションでぜひ!
13
- 15. GUI⾃自動ツールの種類
• キャプチャ&リプレイ
– Selenium IDE
– ブラウザで操作を記録し、再実⾏行行できるよう修正
– それほどプログラミングスキルが無くてもOK
• スクリプト
– Selenium WebDriver
• Java + JUnit + WebDriver
• Groovy + Spock + Geb
– プログラミング⾔言語でテストスクリプトを作成
– プログラミングスキルが必要
• ⾔言語や環境によって難易易度度は異異なる
15
- 16. Selenium IDE
• FireFoxのプラグイン
• テストスクリプトはHTMLで記録される
– WebDriverへの吐き出しもできる
• 簡単な操作でキャプチャ&リプレイできる
• 表形式なので初⼼心者にも分かりやすい
• ただし、
– 変数、分岐、画⾯面遷移、データ駆動などを使おう
とすると結構⼤大変
– JenkinsでCIとかにしようとすると組み込むの
がちょっと⼤大変
– なにより、⼤大きくなるとスクリプトの重複が多く
なるので、メンテナンスが⼤大変
16
- 19. Selenium WebDriver
• WebDriver
– Webブラウザを制御するAPI群
– Webブラウザ毎に実装がある
– Webブラウザの実装の違いは各Driverが吸収する
• テストスクリプト
– WebDriverをサポートする任意のプログラミング⾔言語
• 特徴
– 同⼀一テストスクリプトでドライバを⼊入れ替えること
により別のブラウザのテストができる
– チームのスキルセットにあったプログラミング⾔言語
を選択できる
– テストスクリプトのユニットテストフレームワーク
を使⽤用できるためCIへの組み込みも容易易
19
- 20. Page Objectパターン
• テストスクリプトメンテナンス問題
– 同じ画⾯面で別のデータを使うテスト
• 微妙にフローが異異なる→分岐を使う?→分岐だらけに
– 複数の画⾯面を別々の順番で使うテスト
• 別々のテストスクリプトで作成?→重複→修正コスト⼤大
– Selenium WebDriverを使っても発⽣生
• Page Objectパターン
– ページの要素と操作を表す部品(Page Object)とテ
ストシナリオを分離離
– テストシナリオはPage Objectを呼び出す
– 画⾯面の構造の変化はPage Objectが吸収する
– 複数のテストシナリオからPage Objectを利利⽤用できる
20
- 23. Groovy + Spock + Geb
• Groovy
– Java + Ruby のようなスクリプト⾔言語
– Javaのclassにコンパイルでき、JVMで実⾏行行できる
– Javaより簡易易で分かりやすく記述できる
• Spock
– JUnitのGroovy版みたいなもの
– 同じくJUnitより簡易易で分かりやすく記述できる
• Geb
– WebDriverのGroovy版みたいなもの
– JQueryの書式で画⾯面要素を指定できる
– ダイアログ、フレーム、画⾯面遷移の処理理を劇的に
楽に書ける
23
- 26. キーワード駆動テスト
• Page Objectパターンでも・・・
– 元のテストシナリオの1ステップは業務の⾔言葉葉
– まだ、テストスクリプトの1ステップが技術寄り
– お客様がレビューするのは難しい
• キーワード駆動テスト
– 表で⾃自動テストのテストケースを管理理
– 1⾏行行がテストシナリオの1ステップに対応
– 業務上の基本動作と対象でステップを記述していく
– お客様がレビューできる
– プログラミングスキルが必要なのは基盤を作る⼈人
– Excel -‐‑‒> Selenium⾃自動⽣生成パターンが多い
26
- 27. SSTTEEPP11 テスト対象のアプリケーションと
会話するための基本動作を定義する
• Seleniumの1コマンドである「クリックする」「テキ
ストを⼊入⼒力力する」よりもほんの少しだけ抽象化する
– 「メニューを選択する」
– 「編集中のデータの削除を⾏行行う」
– 「⼀一覧からデータの検索索を⾏行行う」
ユーザにとって意味のある単位でまとめると、
多少UIが変わってもこの単位の中で変更更すれば
済むことがほとんど
27
- 28. SSTTEEPP22 基本動作と対象を組み合わせて
各機能の操作用言語を作る
• 例例
– 「社員⼀一覧画⾯面で社員名を確認する」
• 基本動作:特定の場所のテキストの内容を確認する
×
• 対象:社員⼀一覧画⾯面の中の社員名
– 「社員登録画⾯面で電話番号を⼊入⼒力力する」
• パラメタも指定できるようにする
– 「社員⼀一覧画⾯面で社員名を確認する(name)」
– 「社員登録画⾯面で電話番号を⼊入⼒力力する(phone)」
28