性能検証の自動テストを実装しました
MotionBoardのUIテスト自動化第二弾〜ストップウォッチからの脱却〜
お久しぶりです。
ソフトウェアプロセス＆品質改善部 DEQI G（Data EmpowermentQuality Improvement Group） Automation Teamの佐藤亮です。
今回は正しくはUIテストの自動化ではないのかもしれないのですが、第一弾でのテスト自動化によって、性能検証の部分もテスト自動化で検証ができるようになりました（なので第二弾です）。
現代では、調べ物をするときにはインターネットで検索して調べます。
検索結果がWebページが表示されるまで異常に時間がかかるとすぐに戻るボタンを押して別のページを探す・・・このような経験はありますでしょうか？
Webページにアクセスし、レスポンスが遅いとユーザーはすぐイライラしてしまうものです。
実際に調査されたデータがあり、2秒遅いだけで直帰率は50％になるデータがありました。
ウイングアークのMotionBoard（BIダッシュボード製品）では、開発チームは描画の高速化を意識して開発をしています。
新機能が増えると、ソースコード量も増えるため、速度劣化に繋がる可能性もあります。
QAチームも検証過程の中で、前バージョンからボードの描画速度が遅くなっていないかの検証を実施しています。
今回はこの描画速度が遅くなっていないか？の検証を自動化してみました。
集中力との戦い
今まではストップウォッチで描画速度を測定していました。
ボードにアクセスした瞬間にストップウォッチのスタートボタンを押し、すべてのアイテムが表示されて描画完了となった瞬間にストップボタンを押す検証をしていました。
ストップウォッチでの検証によって
- 「スタートボタンを押すタイミングとどの状態になったらストップボタンを押す」定義が確実に決まっていない
- 人間の反射神経が結果を左右する
結果にノイズが入る曖昧な検証でした。
私は検証フェーズでの性能検証をよく行うのですが、過去バージョンと比較して明らかな遅延が発生したときに、その過去バージョンで比較元の値が問題なかったか再測定を行っていました。
サーバーの状態は正しいか？ログ出力の設定は問題ないか？といろいろ調査をして再測定を行っていたのですが、この検証だけで1ヶ月弱作業を行っていました。
1ヶ月弱ストップウォッチを片手に検証を続けていたのですが、なんでこんな作業をしているんだ・・・と、よくわからないメンタル状態になっていました。
そもそも画面を見続けて、ボタンを押すタイミングを集中して待つのは精神的に辛いです。
このような検証を1日中やっていると後半は集中力が切れてしまい、正しい計測結果を得られなくなってしまう状態が発生すると思います。
ストップウォッチからの脱却！を目標に、テスト自動化でなんとかしたいと思いました。
まずは開発チームに相談。テスト自動化用のモジュール作成をしてくれているメンバーと話し合い、QAで行っている性能検証のやり方を説明して、そのやり方を自動化でカバーできないかを考えました。
MotionBoardではアイテムが描画完了したら次の処理を実行する内部仕様があるため、その機能を利用してタイムスタンプから描画時間を計算するようにしました。
ボードにアクセスして描画完了までの時間をサーバー側で計測し、その情報をSeleniumでサーバーから受け取りデータベースに保存できるようになりました。
大きな流れとしては以下のような図になります。
返ってきた計測結果はJSON形式で返ってくるようにしているため、プログラム側で加工（1回目の計測を除いた5回の計測値の平均値を計算）してデータベースに格納する処理をしています。
データベースにアクセスして計測結果を確認し、描画時間が前バージョンの結果と比較して遅くなっていないかの確認をしています。
いままではストップウォッチで常にパソコンとにらめっこ状態でしたが、自動化によってストップウォッチと戦う必要がなくなりました。
また、人間の反射神経を利用しないので、結果の信用度が上がりました。
今回は性能検証のテスト自動化に挑戦しました。
実際にSeleniumを用いてストップウォッチからの脱却に成功し、とても良かったです。
この性能検証をBVTに組み込めば、早い段階で性能劣化を検知できそうです。
