レポート

モバイルでもクラウドでもSelenium「第2回日本Seleniumユーザーコミュニティ勉強会」レポート

この記事を読むのに必要な時間:およそ 5 分

ハイパフォーマンスSeleniumテスト@サイボウズ(宮田淳平氏)

宮田淳平氏

宮田淳平氏

サイボウズの宮田淳平氏より,kintoneの開発でSeleniumをどのように使用しているか?パフォーマンスをあげるためにどのような対策を採ったかについて発表がありました。

Seleniumテストの問題点

Seleniumはブラウザを使用してネットワーク経由でテストを行うため,実行時間がどうしても長くなります。kintoneでは,Gitのメインブランチにマージされるたびに,すべてのSeleniumテストが実行されます。たとえばこのテストが1時間かかった場合,混雑している状態ですと問題が発生してしまいます。現在は実行時間30分ほどで一応回ってはいるが,コミットが集中する時期だとやはり混雑してしまうので,理想で言えば20分に抑えたいとのことです。

問題の解決策

その解決策として挙げられていたのは,余計なテストを極力作らず,Seleniumテストを本当にコアな部分のメインシナリオのみに絞って行うことです。パフォーマンスが悪く時間のかかるテストだと1日に何度も実行できません。いつでも何度でもすばやくテストを実行できるのがテスト自動化の利点であり,自動テストが開発のボトルネックになってしまうことは避けなければなりません。余計なテストを作らないためには,単体テストでしっかりカバーを行うのが良いとのことでした。

次の解決策として挙げられていたのは,SeleniumGridを使用した並列化です。並列化を行う場合,ブラウザは1マシンに1つにするのが良いとのことです。複数起動も可能ですが,フォーカスの関係などでうまく動かないことが多いとのことです。

並列実行環境の構築方法

クラウドサービスの利用

Sauce LabsTestingBotBrowserStackなど,予算があれば一番お勧めです。あらゆる実行環境に加え,実行録画機能などもあります。Sauce Labsのサービスはフリーで試してよさそうだったのですが,想定よりも費用が高かったのであきらめました。各サービスの比較表を誰か詳しい人が書いてくれるとうれしいです。

VM

クラウドサービスをあきらめた場合,自分たちでマシンを用意する必要があります。最初に思いつくのはやはりVMです。kintoneチームではVM(Virtual Machine,仮想マシン)テンプレートを作って量産を行っています。テンプレートを使えばある程度環境を量産できますが,環境を作り直したり設定を変えるなどの作業を行うと途端に手間がかかるようになります。マシンリソースも,ある程度ブラウザテストができるマシンとなると,それなりのスペックが必要となり大変です。

Docker

Dockerは高速デプロイでき,かつ軽量です。ただし環境はLinuxだけなのでChromeとFirefoxのみに限られてしまい,Internet Explorerのテストはできません。次期バージョンのWindowsではDockerが対応するようなので期待をしています。

並列実行について

並列実行を行った際,以下の点に注意し,必要であれば改善していく必要があるとのことでした。

  • (全テストの実行時間の合計)÷(並列実行時間)(並列数)となっていれば理想
  • 実際の並列数より極端に小さい値のときは改善余地がある
  • 時間の長いテストケースを最初に実行できれば理想値に近づく。それにはテストランナーに手を加える必要があるかもしれない

個々のテストの高速化

テストの高速化については,実行時間の長いテストは普段からわかるようにしておき,極端に長いテストは改善したほうが良いとのことです。また,多くのテストで共通の処理で時間がかかっているところは改善していく価値がある(初期データの作成,ブラウザ起動,認証処理など)ところです。

初期データの作成

初期データを作成する方法はいくつかありますが,ブラウザ操作を使うと不安定になるし,DBダンプを使うとスキーマ更新時にメンテナンスの手間が発生します。APIを使う方法ならばそこそこ速いので,環境が整っているのであれば一番お勧めです。

安定性

宮田氏のチームでは,リトライを3回まで行い,ネットワークの問題などで失敗した場合でも救済されるようにしている。リトライされたテストはどこかに不安定な部分がある可能性が多いので,わかるようにして後で直すと良いとのことです。また,findElementなどは不安定に失敗することがあるので,条件付きのWaitを使うようにしているとのことです。

メンテナンス性

メンテナンス性が低いと,手動テストのほうがよいのではないかというネガティブな意見が現場から出てくることになります,また,メンテナンス性が低いことによって,徐々に自動テストが困難になっていき,実際チーム内でも一度メンテナンス不能になってしまったことがあるとのことでした。

メンテナンス性を上げるために必要なこととして以下の点を挙げていました。

  • PageObjectパターンの利用。UI(User Interface)変更があるならば必須
  • 失敗時のスクリーンショットの記録,録画などで原因調査が楽になる
  • テストコードにも規約を作ることが重要。レビューも行う

まとめ

  • Seleniumテストの運用はパフォーマンスとの戦い
  • 自動化するテストは重要なものに絞る
  • 実行時間短縮は並列化してその効果を最大限まで活かしきるのが一番効果的
  • 安定性やメンテナンス性も大事

Seleniumの事例は少ないので今回は発表しようと思いました。今後もこういう事例がたくさん発表されるとうれしいとのことでした。

Q&A

Q:どうやってチームでテストを書く運用を整えたのですか?
A:一時,WebDriverテストがメンテナンス不能状態になりました。継続的デリバリーの社内勉強会を実施し,CI(Continuous Integration,継続的インテグレーション)の重要性を再認識しました。
Q:Seleniumテストの録画はどうやって実現しているのですか?
A:vnc2flvというPythonのライブラリを使用し実施しています。テストが失敗したときのみ保存を行います。

宮田氏の発表時のブログではQ&Aの補足もされていますので,より詳しく内容を知ることができます。

著者プロフィール

矢野聡(やのあきら)

株式会社オープンストリームにおいて,SEとして開発案件に従事。テスト嫌いだったので,何とかする方法はないかと思い「日本Seleniumユーザーコミュニティ」に参加。継続的インテグレーション,継続的デリバリーなどの単語が絡むものが好物。