20140128 tel@cafe selenium編

9,456 views

Published on

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,456
On SlideShare
0
From Embeds
0
Number of Embeds
7,716
Actions
Shares
0
Downloads
24
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

20140128 tel@cafe selenium編

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

×