Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Mehr von SHIFT Inc.
20140128 tel@cafe selenium編
- 1. CAMP powered by T.E.L@CAFE テスト自動化のいろはとSSeelleenniiuumm CCAAMMPP 玉川紘子 / 太田健一郎 1
- 2. 今日のTTOOPPIICC n テスト自動化概論（担当：玉川） n Seleniumデモ（担当：太田） 2
- 3. なぜテストを 自動化するのか 3
- 5. 5
- 6. テスト自動化の誤解その① 「自動化で工数削減！！」 n ⾃自動テストの初回のサイクルは、⼤大体⼿手動の3倍の⼯工数がかかると⾔言 われている（ちなみに⽟玉川の所感では3倍で済めばだいぶいい⽅方。） 出典： 2011年JaSST九州 「テスト自動化の前に 押えておきたい3つのポイント」 6
- 7. テスト自動化の誤解その① 「自動化で工数削減！！」 n 確かに最終的な⽬目的の⼀一つは⼯工数削減 n でも、⾃自動化するコストが⾼高い上にすぐ使い捨て られてしまうようなテストであれば⼿手動で済ませ る判断も必要 n コストが低く繰り返し実施するテストが⾃自動化に 向いている n 必ず通る重要なフロー n １つのフローに対してパターンが多いもの n 例例：ECサイトの商品登録〜～商品購⼊入 n 例例：保険の⾒見見積取得 7
- 8. テスト自動化の誤解その② 「自動化でテストが速くなる」 n 実⾏行行⼯工数がゼロになるわけではないことに注⽬目 （ふたたび）出典： 2011年JaSST九州 「テスト自動化の前に 押えておきたい3つのポイント」 8
- 9. テスト自動化の誤解その② 「自動化でテストが速くなる」 n スピードではなく、⼈人がいなくても良良いということ n IEを使ったテストとか結構遅い n それでも⼟土⽇日・夜間に実⾏行行できることはメリット n 実⾏行行して終わりではない n 結果のOK/NGの確認 n NGの場合、どんな事象が起きているのか n 不不具合なら報告が必要 n 不不具合でないならテストケースの修正が必要 n 逆に⾔言うと、これらの後処理理がなるべく楽になるよう な⼯工夫をしておくと吉 9
- 10. テスト自動化の誤解その③ 「自動化でテストが楽になる」 n テストは実⾏行行だけではない n 計画、設計、実⾏行行、不不具合報告、分析、… n （今話している）⾃自動化では実⾏行行しかカバーしない n ⾃自動化特有の苦労も n 「レイアウトが崩れていない」ことをどう判定 する？ n 「検索索結果が正しい」ことをどう判定する？ n ⼈人間なら⾃自然にやってくれることをテストケース で細かく書かなければいけない 10
- 11. 11
- 12. 自動化のおいしいポイント n これまで出来なかったテストができる n ⼯工数がかかり過ぎて間引きしていたテスト n 1年年に1回しかできなかったテスト ⇒ 準備⼯工数がかかっても、これが出来ればおいしい n 単純作業を機械に任せることで、⼈人間はもっと⾼高度度な 活動へ n 複雑なシナリオの設計 n ユーザビリティテスト n 正確なオペレーション n どんなに退屈な単調な作業でも、何度度でも正確にこなしてくれ る 12
- 13. 何ができれば自動テスト屋さんになれるのか n ⼤大雑把に分けると２つの役割 n Automation Architect n ツールの選定、テスト範囲の決定、フレームワーク作りなど Automation Engineerが活動するための基盤を作る役割 n やや上級のエンジニアスキルが必要 n 開発側の制約と折り合いをつけながら、⼀一から⼟土台を築いてい く楽しみ n Automation Engineer n 定められたフレームワークに従ってテストスクリプトを作成する n 基本的なプログラミングのスキルがあればOK n 例例えばSeleniumやSilkTestのようなツールでスクリプトを実装 n 書いたスクリプトがしっかり動いているのを⾒見見る快感 ⇒ この後の太⽥田さんのセッションでぜひ！ 13
- 14. Seleniumデモ 14
- 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
- 24. Groovy + Spock + Gebデモ 24
- 26. キーワード駆動テスト • Page Objectパターンでも・・・ – 元のテストシナリオの1ステップは業務の⾔言葉葉 – まだ、テストスクリプトの1ステップが技術寄り – お客様がレビューするのは難しい • キーワード駆動テスト – 表で⾃自動テストのテストケースを管理理 – 1⾏行行がテストシナリオの1ステップに対応 – 業務上の基本動作と対象でステップを記述していく – お客様がレビューできる – プログラミングスキルが必要なのは基盤を作る⼈人 – Excel -‐‑‒> Selenium⾃自動⽣生成パターンが多い 26
- 27. SSTTEEPP11 テスト対象のアプリケーションと 会話するための基本動作を定義する • Seleniumの１コマンドである「クリックする」「テキ ストを⼊入⼒力力する」よりもほんの少しだけ抽象化する – 「メニューを選択する」 – 「編集中のデータの削除を⾏行行う」 – 「⼀一覧からデータの検索索を⾏行行う」 ユーザにとって意味のある単位でまとめると、 多少UIが変わってもこの単位の中で変更更すれば 済むことがほとんど 27
- 28. SSTTEEPP22 基本動作と対象を組み合わせて 各機能の操作用言語を作る • 例例 – 「社員⼀一覧画⾯面で社員名を確認する」 • 基本動作：特定の場所のテキストの内容を確認する × • 対象：社員⼀一覧画⾯面の中の社員名 – 「社員登録画⾯面で電話番号を⼊入⼒力力する」 • パラメタも指定できるようにする – 「社員⼀一覧画⾯面で社員名を確認する(name)」 – 「社員登録画⾯面で電話番号を⼊入⼒力力する(phone)」 28
- 29. SSTTEEPP33 個別のテストシナリオを作る • 例例 ▼STEP2で定義した 個別機能の操作 ▼操作のパラメタ （複数パターン作成可能） 29