Webページ性能計測自動化の改善

はじめに

こんにちは。TeamSpritEX開発チームQAエンジニアの長尾です。
Webページ性能計測の自動化のアップデートを行いました。
今回はその内容についてまとめました。

Webページ性能計測について

そもそもWebページ性能計測とはどのようなもの？
→実際にユーザが利用する際のWebページの表示速度を計測する。
というのが一般的かと思います

測定の方法は様々な方法がありますが、今回私が対応したものは、ブラウザにて手動で確認することも可能な以下の時間（Finishのタイム）を想定したもの。

Chromeブラウザのデベロッパーツール

データ計測のメリット

顧客満足度に直結する大事な指標となることは当然のこと、計測データを利用することによって、他の製品との性能比較、ロード時間の長さに関する課題の顕在化など、アプリケーションを開発する上で様々な目的や課題の解決のための指標として利用することが可能と考えています。

Webページ性能計測（自動化）の仕組み

私のチームでは、前述したデータの計測を自動化し、蓄積したデータをグラフ化し開発メンバーに共有しています。ここではその方法について記載します。
今回はgas-webpagetestというGoogle Apps Scriptで動作するパフォーマンス計測ツール使用しました。
また、計測対象となるテスト環境についてはJenkinsを利用し毎日Masterブランチのデプロイを実行し、各チームの修正が取り込まれる状態にしています。

公開されているリポジトリgithub.com

図解すると以下の通り

WebPageTest自動化

改善の背景

実装の仕組みについては前述したとおりですが、
実は、私がチームスピリットに入社するより以前から、既に自動化は運用され計測結果も収集している状態でした。
問題なく動いてはいましたが、運用していく中で改善課題も上がっていたため、今回私の方でその課題に対応するために改修することとなりました。
課題としては主に２点

• Salesforceの上のパッケージ開発における開発可能な範囲に絞った性能速度の計測ができていない。
• ユーザーの利用頻度の高いユースケースに対応したテストシナリオになっていない。（初回実行時のキャッシュ無しを想定した計測となっていた）

そのため、まずは現在の自動化の実装フローがどのようになっているのかを理解。その後対応方法を検討していきました。

どんな改修を実施したのか

結果として以下のような対応を実施。

1. Salesforceのロード時間を除いた計測に変更
   　→Visualforceページのみ計測対象とすることで自社内で対応できる機能に絞り込んで計測することができた
   
2. ページリロード時の計測に変更（キャッシュ有りの利用を想定）
   　→WebPageTestの実行スクリプトを修正し、より利用頻度の高いシチュエーションにおけるロード完了時刻の測定に絞り込むことができた
   

性能テスト自動化のメンテナンス作業を通して

前述した通り、私が対応し始めた段階ではある程度自動化の仕組みは構築され既に定期実行で計測する運用はされていました。
そのため、途中から運用を引き継ぐ形で対応することとなったのですが、
今まで利用したことのなかったGoogle Apps Scriptを利用した運用方法であったこともあり、
内容を理解するのはなかなか大変でした。

社内の有識者に質問攻めの状態でなんとかやりとげることができましたが、 今回一番やってよかったと思ったのは、トライアンドエラーで何度も実装したことです。
仕組みの全貌を理解できたのは、１つずつ自分で試してみて１通りの実装が終わった段階でした。
引き継ぎの段階で一通りの説明をもらい、その後少し期間が空いてからメンテを始めようと思うも時既に遅し。何をすればよいか全く分からなくなりました。
初回説明の段階で全く理解してなかったからだと思います・・・。
実際にやってもいないのに理解したつもりでいることの怖さを改めて感じるのと同時に、理解したことを実行して身につけることの重要性に気づきました。

苦労した点も多かったですが、結果的に品質基準として定めていたページ読み込み時の速度目標を改定することとなり、
弊社のパッケージ開発の目標としてより妥当な品質基準を設定できたと感じています。

解決できていない課題について

現時点の課題として具体的には以下のようなものが存在しています。

• 複数バージョンのパッケージ製品の計測に対応していない
  　→弊社では同一製品でも複数のバージョンを提供しているため、それぞれに対応した性能テストの自動化を目指したい（現在１バージョンのみ実装）

• 一定のタイミングで計測が停止、計測ツール（WebPageTest）の計測サーバの混雑度合いなどを考慮できていない
  　→定期実行スクリプトが稀に停止しその後計測が止まってしまうことがある

顕在化していない問題も含めるとまだまだ改善の余地があるものかと思うので、今後もこういった課題を１つずつ解決していきたいと思っています。

最後に

性能テストの目的は”ユーザがストレス無く快適に利用できる製品を作りだすこと”だと思っています。
私はQAエンジニアなので、現時点ではこの情報の抽出の部分に注力していますが、当然ながら計測しただけでは意味がないと思っています。

• 開発エンジニアに性能評価を意識した開発を進めてもらうにはどうすればよいか
• マーケティングの指標としてどのように活用していけるか
• 更に効率的な性能テストの自動化の仕組みを検討（利用するツールの統一化など）

などなど、やるべきことはたくさんあると思っています。

テストを実施することが目的になりがちなQAエンジニアですが、
今回のような非機能要件の検証に関わることも、大きなやりがいの一つです。
チームスピリットでは、これ以外にも様々な技術検証を行っているので、
今後もいろいろなことに挑戦していきたいと思います。