第３回selenium勉強会の発表資料です。 自動化のスキルを身に付ける為の個人的な取り組みのご紹介です。 みなさまのお役にたてれば幸いです。

1. 2016/02/06 Sat
Naoya Kojima
twitter @jugemix
hashtag #seleniumjp

2. Naoya Kojima 小島 直也
• Job
 Enterprise Web Application Engineer
 単体～システムテスト、設計等を少々
 Java SE/EE, Subversion, Ant
• Career
 Sales 4 years +
 Engineer 4years +
 Java 3 years +
 Selenium 6 months +
 Azure 6 months +

3.  はじめに
 テストの自動化
 ブラウザテストの自動化のはじめ方
 自動化で直面した課題と解決策
 実践的な自動テストに仕上げる為にやったこと

4. テストってどうやってますか
私の知っているテストと違いますか
#seleniumjp

5. Manual Testing
• Excelにスクリーンショットをコピペして証跡残
す作業
• どうしてもモチベーションは下がりがち

6. Automated Testing
• 自動化ツールを使い、テストはコンピュータにお
任せ
• 帰社時／コミット時／定期的に実行するだけ
• 証跡は自動化ツール等がレポートしてくれる

7. 静的なWebサイト
• クロスブラウザで、レイアウトに崩れや動作に問
題が無いかテストをする
動的なWebサイト
• 静的なWebサイトでの確認内容に加え、アプリ
ケーションの振る舞いをテストする

8. 私が取り組んだ理由をお話しします
皆さんの取り組みもぜひ教えてください
#seleniumjp

9.  複数Webサイトに同一のマニュアルテストをし
たときに、Seleniumの存在を知っていたので同
じテストを手動で繰り返すのは非効率な面があ
ると思った
 デプロイの頻度が高い時期があり、終わったば
かりのテストを繰り返すということがあった
 自動化できるスキルがあれば、さらに効率化で
きると考えた

10.  テストの実行をコンピュータに任せられる
 テストをデプロイメントパイプラインに組み込
めば、ビルドしてすぐにバグを見つけることも
出来る

11.  継続的なテストのメンテナンスが必要
• メンテナンスしやすい構成にするスキルが必要
 それなりに学習コストが掛かる
• 本日の内容をお話しできるようになるまで、約4ヶ月かか
りました

12.  アプリケーションの振る舞いテストを自動化する為のツール
 詳細はぜひ、↑こちらの本をご覧ください
 本日登壇、分かりやすく書いてくれています

13. Javaでお話しします
ブラウザテスト＝結合／システムテスト
#seleniumjp

15.  実践Selenium WebDriver
 Seleniumデザインパターン & ベストプラクティス
• O‘reilly japan 様
 ToolsQA
• http://toolsqa.com
 Stack Overflow
• http://stackoverflow.com
• その他多数（英語が多い）
 日本Seleniumユーザ会
• 談話会、Slack
• ぜひユーザ会に参加しましょう

16. 私を含めた初心者にあるある集
－私だけでしょうか…
#seleniumjp

20.  ロケータをxpathで書くことにした
 談話会では、読みやすさからCSSを使うのも有
りという意見も出た
 アプリケーションの設計時には適切なIDを指定
するように規約を設けようと思った

21.  メリット
• テストケースの数だけクラスが出来る
• テストケースを網羅できれば、それをクラスに実装す
るだけなので逆に分かりやすいかも
 デメリット
• 大量にテストを書く必要がある
• 異なるテストケースで同じ処理を何度も実行する場合
があり、同じ処理を含んだクラスが複数実装される

22. ケース名 シナリオ 試験の流れ
TC001 日付を指定して宿泊予約する ログイン→宿泊予約
TC002 部屋を指定して宿泊予約する ログイン→宿泊予約
ケース名 実行順 機能 試験項目 アクション データ名
TC001 1 ログイン Login
TC001 2 日付指定予約 宿泊予約 hizukeYoyaku 001
TC002 1 ログイン Login
TC002 2 部屋指定予約 宿泊予約 roomYoyaku 002
テストケース表
テストステップ表

24. テストステップとして”宿泊予約”を切り出すべき
か？という悩み
１テストの粒度が荒いのでは？と思った。

25.  メリット
• テストシナリオ（テストデータ）を一度作れば、何度でも再利用
できる
• アプリケーションの機能を実行する処理を１つだけ実装すればよ
い為、改修があっても対象の操作をメンテナンスするだけで良い
• 例えば、テストシナリオに表れる”宿泊予約”という処理を１つ実
装する
 デメリット
• テストシナリオを漏れなく作る必要がある
• バージョンの異なるWebアプリケーションが複数ある場合、その
サイト数分テストシナリオを作る必要がある

26. ６との違い
“宿泊予約”の中の”日付入力”部分だけをテストステップと
して独立させるべきか？という悩み
こだわるところじゃないかも…

27.  TestNGのBeforeMethod、AfterMethodを使い、
ロガーの起動、ブラウザのオープン、ブラウザ
のクローズをすることにした

28.  前の処理で出来上がったデータを元に次のテス
トを実施していた
 このことについて、デザパタ本の談話会でスパ
ゲッティにあたるか質問したところ、「そのテ
ストが何を目的としているか」によるという意
見を頂けた

29.  自分だけなら自分の好きな言語を選択
 チームでテストを書くなら、より多くのメン
バーが書ける言語を選択

30. テストはSeleniumに任せたいが、テスト
の初期化の度にブラウザが起動して他の作
業の邪魔をしてくる
自分のPCを使用していないときに流して
みたものの、テストが失敗していて翌日再
度やり直すことになった
Azure VMでテストを実行してみることに
した

31. これまでの登壇者の方から学んだことを
反映するともっと良くなる気がしてます
#seleniumjp

32.  テストデータ（Excel）の読み込み処理
• TestNGのDataProvider機能を使い、テストデータを読み込む処
理をテストと分離した
• データはapache POIで取得した
 任意のブラウザでのテスト実行
• プロパティファイルで実行ブラウザを切り替えられるようにした
 Web Elementが表示されるまでテストの待機処理
 スクリーンショット取得処理
 ロガー
• テストが失敗した原因を調査できるようにした

33.  テストを追加するときに手を加える箇所を、以
下の3か所に限定した
• PageObject
• アプリケーション機能定義部
• アプリケーション機能実装部

34. 構成
Windows 7
PC
Windows
Server 2008
Ubuntu
Linux
Hub Node
ヤフー
Ubuntu
Linux
Ubuntu
Linux
本日のデモは
↑ここから

35. Selenium談話会やSlackでいろいろ教えて
くださった会員のみなさま、誠にありがと
うございました
本日の話が集まられた方の一助となれば幸
いです