本記事は、Selenium/Appium Advent Calendar 2016の5日目です。
普段は、テストエンジニアとしてエンプラ系Webシステムの開発に携わっています。
はじめに
Seleniumでは負荷試験をはじめとするパフォーマンステストを実施することは非推奨です。
「Seleniumデザインパターン＆ベストプラクティス」にも以下の記述があります。
結局のところ、パフォーマンステストにSeleniumを使うのは、とんでもない解決策です。もっとシンプルでより良い解決策があります。
でも、手元にSeleniumしかない状態で、対象のシステムがなかなか複雑でJMeterのシナリオ書く時間もないなと思ったので、物理的に複数台マシンを確保して、原始的な負荷試験をやってみました。
実現方法
材料
- Selenium Webdriverのプロジェクト・・・ Webページを操作するためのテストコード
- Jenkins ・・・ Mavenを繰り返し実行するためのツール。プラグインと組み合わせて使う(後述)。
仕組み
以下のような構成としました。
Jenkinsは本当はマスタースレーブ構成にすれば、台数も減らせるし、SeleniumGridを使えば単一マシンで複数実行もできるのですが、組み上げること最優先だったので以下のようにしました。
（太田さんとか玉川(紘)さんが聞いたら怒られそうですね、すみません。。。）
役割としては、JenkinsがMavenを実行して、実行間隔や繰り返し実行を行いました。
Seleniumでは、画面操作とスクリーンショット取得しました。
Mavenで実行するためにはJava+SeleniumなWebアプリケーションの自動テストプロジェクト構築を参考にさせていただきました。
Jenkinsでは、Naginatorプラグインを導入して、失敗したときでも再実行されるようにしました。こちらの記事を参考にしました。
その他工夫点
入力文字列にタイムスタンプを入れて、繰り返し実行可能とした
システムによっては入力値が重複することによって、バリデーションがかかったりサーバそれぞれのJenkinsの実行間隔をずらした
あえて、同時アクセスの試験が目的ではなかったため、シナリオをずらして実行するようにしました。
結果
当たり前ですが、台数分の負荷をかけることができました。スケールさせるためには、台数分マシンが必要になるため、あまりお勧めできません。それでも、２台のマシンを同時に実行させて、24h、48h、72hと実行させることでサーバ側のリソースの変化が見れたので、実施して効果はありました。
思いがけぬ収穫としては、特定画面で特定の操作を行った際にSeleniumが落ちるという事象が、見られました。詳しく見てみると、排他制御によるタイミング問題だったことが分かり不具合として報告しました。
まとめ
負荷試験をはじめとするパフォーマンステストには、JMeterを使いましょう。でも、Web画面からSeleniumを長時間かけてみることで、ユーザの手動試験では検出の難しいタイミング不具合などが検出できるかもしれません。