第3回日本Seleniumユーザーコミュニティ勉強会に参加したので当日メモ #Seleniumjp

スポンサードリンク



2016/2/6に開催された、第3回日本Seleniumユーザーコミュニティ勉強会に参加してきました。
当日(座って聞けた部分については)メモを残したりしてたので、加筆&整形して残しておこうと思います。

開会あいさつ TRIDENT 伊藤さん

  • 今回は参加者が多い。最終的に、スタッフ除いて100人程度となった。
  • 『Selenium実践入門』発売記念も兼ねて開催。そのため、この本にまつわる話もたくさん。
  • ユーザコミュニティとしては今Slackが活発で、気軽に質問もできる雰囲気:日本Seleniumユーザーコミュニティ
  • 勉強会申し込み時のアンケートを見ると、利用言語としてはJavaが多いが、最近はRuby等他の言語も増えてきている
  • 同じくアンケートの結果、Seleniumの利用目的はテストが多い。少しWebスクレイピングも。

SHIFT 太田さん&玉川さん 「Seleniumデザインパターン&ベストプラクティス」の勘所

書籍の特徴

  • IDEで記録したいけてないコードから始めて改善していくような内容

自動テストウェアのアーキテクチャ

自動テストやるときって作らないといけないものがいろいろある

  • UIMapとか
  • ライブラリとか

これらがないと、保守・メンテが大変になる。
長期運用しやすいように考えよう。

いけてないテストスクリプトの例

ECサイトの商品コメント欄の仕様として「同じ内容のコメントは複数投稿できない」と定まっているのに、テストスクリプトが毎回同じ文字列をコメントに書くような作りになっている
→1回動かしたら2回目以降失敗する

アンチパターン

record and playbackパターン

操作記録してそのまま実行する。
始めるにははやいが、スクリプトがわかりにくい

Sphagettiパターン

テストケース間の依存があるパターン。あるケースの失敗が原因で以降が動かないなど。

ChainLinkedパターン

多少構造化したものの、依存関係があるパターン

BigBallofMadパターン

独立性はあって順番関係なく実行はできるが、構造化してないパターン

よいパターン

DRYテストパターン

DRY = Don’t repeat yourself!
DRYを維持し続けるにはそれなりのスキルが必要となる。

Hermeticテストパターン

依存関係をなくしたパターン。
テスト間の依存関係を無くすためにデータ準備等の処理が入るので、テストの実行時間が長くなる場合も。
トレードオフで考えよう。

ランダム実行順序原則

テストケースをランダムな順序で実行する。
順序依存になっていないかがわかる。

太田さんデモ

実際の良いパターンといまいちなパターンを見比べながら、実行

TRIDENT 伊藤さん「Selenium実践入門」で学ぶテスト自動化の世界

Seleniumテスト自動化の世界

一昔前は・・・

  • CIとかあんまりやってる人がいない
  • SeleniumRC/IDEがあまり安定してない
  • 事例もツールベンダのWebページにちょっとあるくらい
  • 開発プロセスから分離された自動テスト

その後

  • 2010, 2011あたりから商用とオープンソースのトレンドが移り変わってきている
  • CIがメジャーになった
  • オープンソースの存在感が増した
  • 国内ユーザ企業からの事例発信が増えた
  • 開発プロセスと統合された自動テスト

本の立ち位置

Seleniumだけの使い方にとどまらない内容

  • コマンドの解説はJava
  • 巻末チートシートに主要コマンド文法

初心者が読んで終わりではなく、ずっと手元におきたい1冊になるようにした。
本ならではのコンテンツで、APIドキュメント読んだだけではわからない部分が書かれている。たとえば

  • ファイルダイアログ
  • Basic認証
  • HTTPヘッダ

など。

運用や事例の章もある。
Geb、FluentLeniumなどの便利ラッパの紹介。

第一章(テスト自動化とそのメリット)では基本的な内容が書かれているが、買った人が読むというよりは、買った人が上司や後輩に「とりあえずこれ読んどいて」的な使い方を想定しているため。

Yahoo 太田さん E2Eテストフレームワークを使用したテスト自動化事例

どうやって使うフレームワークを決めたか

各チームによって言語がまちまちで要件いろいろ。
その中で

  • Nightwatch.js
  • Protractor

を候補に調査。

Nightwatch.jsのよかったところ

スクリプトやログが見やすかった

Protractorのよかったところ

自動待機機能があり、明示的に待機を書かなくてよかったのでスクリプトがシンプルに。

E2Eテストとは

利用者の視点に立ってサービスが正しく動いているかどうか確認する

環境構築

テスト時に専用環境が自動構築される。

PhantomJS

ヘッドレスブラウザとしてPhantomJSも使った。画面出さないけどスクショが取れる。

↑このへん、自分も近いことを思いました。描画しない分早いとか、画面側のテストとJavascriptのテストを分けてるとか?

結局このPhantomJSはうまく行かなかったので、リアルブラウザ(Firefoxとか)をヘッドレス化してつかうことにした。
Xvfbを使って。

Qiitaにこんな情報ありますしね。↓

Xvfb を利用したヘッドレスブラウザテスト

DeNA 平田さん STFとAppiumをもちいたAndroidアプリの自動テスト

STFを初めて聞きました。SmartphoneTestFarmの略らしいです。

Fastest device testing Smartphone Test Farm

検証用端末をブラウザから操作できて、ほぼリアルタイム。

STFを聞いたことあるひとー!

10人くらい?ぽつぽつ

Appium聞いたことあるひとー

40人くらいが手を挙げた

Androidアプリの自動テストでの課題

  • まず、何使う?
     → Googleからいろいろ提供されだしているので、あまり迷うことはなくなってる

環境面倒

  • 実行端末が環境に繋がれてないといけない
  • 端末で実行されているかの判断がいる
  • Jenkinsマシンにスマホを繋がないといけなかったり
  • どのテストをどのスマホでやるかを固定しないといけなかったり

そこでSTF(smartphone test farm)

  • リモートデバッグもできる

Androidアプリの自動テストは STF+Jenkins+Appium+Docker

小島さん Azureを使って手軽にブラウザテストをはじめよう

エクセルにエビデンスをコピペする簡単なお仕事・・・は辛いですよね

効率よくしたい、辛いと思って自動化を始めた

自動化で悩んだポイント

いわゆるあるある。
ただこれからやる人には参考になるはず。

PooSunnyさん Gebに実践入門するために

Selenium実践入門にも書いてあるGebについての紹介

Gebのメリット

普通に書くとこんなに長いところが、Gebを使うと・・・こんなにすっきり!

Gebのデメリット

環境構築まわりが大変

Monocrea 桑原さん エビデンス取るのも自動化したい!

テストエビデンスとるの嫌だよね!
→会場から大きな拍手

だからブラウザの自動テストツールつくりました、エビデンスを自動で取ってHTMLレポート出力してくれるよ!というお話。
SIT-WT

サイボウズ 宮田さん Seleniumアンチパターン

サイボウズの事例はSelenium実践入門にも。

アンチパターン1:なんでもSelenium

とにかくSeleniumでなんでも自動化だ!と始めたものの、開発者の気まぐれでテストケースが追加されたり、自動化されているテストされていないテストが整理されてなかったり・・・
そうこうしているうちにメンテ工数増大してばーん

解決策・・・

Seleniumを避けることを考えよう。

  • 静的解析
  • 単体テスト
  • APIテスト
  • 手動テスト

など、最適なものを選ぼう。あえて自動化しないのも選択肢。

「自動化してほしい」という顧客の要望があっても、本質は「効率化したい」のはず。自動化エンジニアの経験から、本当にお客さんにとって効率化・省力化に繋がる方法を提案すべき。(たとえそれが「自動化しない」であったとしても)

アンチパターン2:手動テストのかわり

開発プロセスの手動テスト部分にそのままSeleniumでの自動テストを追加
→最終的に破綻

工数削減だけが目的だとつらい

常に繰り返し実行すること、につきる。
放置するとメンテ工数が増えていって手がつけられなくなる。

アンチパターン3:クロスブラウザがんばりすぎ

解決策・・・

IEはアレですよね
→会場が同意
ブラウザを絞ろう。過去にブラウザ依存の不具合がどれだけ出ているかなどで判断しよう。

戸田さん 薄っすい話百八式

テストでダメだったときにショウ君(VoiceText)に「○○さんのコミットでテストが失敗したみたいっす」って喋らせたりするなど。とにかく面白い話。

参加者の方のまとめ記事

スポンサードリンク







コメントを残す

ABOUTこの記事をかいた人

都内でテストエンジニア&ブロガーをやっている@yoshikiitoです。 ソフトウェアエンジニアの学習方法や成長するための考え方、会社に依存せず自分の力で生きていけるエンジニアになる方法などについて興味があります。 こういった方法や考え方、自分が試したことなどをブログを通じて発信します。 仕事は主にソフトウェアテストやテスト自動化。 趣味は浦和レッズと読書と技術書を買って積むこと。 技術評論社から本を出すのが夢