はじめに

性能回帰テストを自動化するプロジェクトを開発をしながら隙間を見つけてチームメンバーと行なっておりました。完成して運用している今、下記3つをポイントに紹介していきたいと思います。

どのようにプロジェクトを進めたのか
進める上でどのような課題が出て解決したのか
運用方法

昨年の弊社アドベントカレンダー(性能回帰テストの自動化プロジェクト始めました)にてプロジェクトの進め方を紹介しました。そこから再編集を行い、この記事にて完結編とさせていただきます。

自動化と言う前にやったこと

自動化！！

すごく楽になるそんな夢のような仕組み。

自動化する目的は？自動化して得られる効果は？手段が目的になっていませんか？

技術というのは課題、問題を解決する手段の一つです。

自動化すると言って手を動かす前に、目的を整理する。

自分やプロジェクトが抱えてる課題は本当に自動化で解消、緩和されますか？漠然と自動化すればなんとかなると考えていないですか？

整理した後、フィードバックをオススメします。

目的、手段、背景・課題、効果　この観点で概要をまとめました。

■ 概要説明 ■ 

＜目的＞
テストコストの抑制/削減を行う
    
＜手段＞
・ CI環境に組み込みテスト実行と結果出力を自動化する
・ JMeterでテストシナリオを実行し、レスポンスタイムを計測する
    
＜背景・課題＞
性能改善を実施したが新機能追加、改修を続けながら性能を維持する必要がある。
しかし、そのためには機能開発毎にテストが必須となり、テストコストの増加が予測できる。

＜効果＞
毎日自動でテスト実行することで以下のような効果が得られる

・ 自動化することにより、性能劣化を担保するテストコストを削減することができる。
・ 毎日テストを実行することで、性能劣化の早期発見、早期対応が可能となり、
　 アプリケーションの保守コストを最小限に抑えることができる。

現状把握

目的地までの道順を確認する時、自分の現在地がわからないと道順も出てきません。日常生活の中で何気なくやってる思考が仕事でも十分役立ちます。

CIに組み込むと意気込んだものの、今動いてる環境の構成図ありませんでした。先輩から後輩と一緒レクチャーを受け後輩に構成図を描いてもらいました。

既存の構成図に新しく構築したいものを組み込んで完成！ドキュメント作成はメンバーと認識を共有するするためのものです。毛嫌いする人もいますが、コミュニケーションをとる手段の１つではないでしょうか。

青線が静的解析のフローで、オレンジ線が今回追加しようと動いている性能回帰テストのフローになります。

f:id:misatoki:20190828211105j:plain

どんなテストフローにするのか

人の手でやっているテストを実行するまでの段取りを書き出してみました。

基本的に人が手でやってたことを自動にすることが自動化だと私は理解しています。

いつ(何時から)どんなデータでどのようなテストを行う？

描いたシナリオ

テストデータは毎日作って破棄
全画面のレスポンスを測定するテストシナリオ
0時からテスト開始、8時には完了
レスポンスタイム結果を出力

まず、

1.テストデータは毎日作って破棄

日々新規開発は続いているので、それに合わせると毎日テストデータは作る方がメンテコストが抑えられる。

2.全画面のレスポンスを測定するテストシナリオ

せっかくの自動化なのでテストできるものは全部組み込んでしまおう。

3.0時からテスト開始、8時には完了

弊社の始業時間は9時なので、1時間前までには終わればいいかな程度。8時間あれば終わるでしょうという考え。

4.レスポンスタイム結果を出力

とりあえず出力結果をCSVで出力、レスポンスタイムの平均値とかスループットの表を出力します。可視化もしたいが、まずは結果を出力するまでを行う。

案外ざっくり決めです。

実際にシナリオ流してみた

試しに流してみると、テストデータを作るのに4〜5時間。全画面のテストの3割を流すのに3時間はかかってしまうことがわかったのです。3割で3時間。

このままでは、

全画面テストは想定している時間内で実行できない可能性が高い
テストデータの作成に想定していたより時間がかかる

ということに気づきました。

考えていたストーリーが本当に実現できるのか？というのを早めに試作して検証することをオススメします。新規機能の開発も同じですが、想定外なことが起こることは早めに気づくとリカバリという手段が見いだせます。

課題と課題解決

テストデータの作成に想定していたより時間がかかる
テスト数全体の3割で3時間の実行時間がかかる
テストシナリオの管理、メンテナンスどうするか
日々の結果はどうやって確認するのか

テストデータの作成に想定していたより時間がかかる

テストデータを毎度作成するには不安定であることと、テスト時間に収めるためにあらかじめデータを入れたdumpファイルを作成し、それをrestoreすることにした

テスト数全体の3割で3時間の実行時間がかかる

そもそも全画面のテストを流す必要はあるのだろうか?

テストの目的を考え抜いた結果、テストで最も品質を担保したい画面を選抜することにした。

その結果、テストデータ作成からテスト実行からテスト結果の出力まで、当初考えていた8時までに収めることができた

テストシナリオの管理、メンテナンスどうするか

テストシナリオは資産である

ソースコードと同じで、Gitに新しくシナリオ管理用のプロジェクトを作りバージョン管理
メンテナンスもバージョンごとに必要であれば行い、バージョンごとにタグを打ち、それをメンテナンス完了している印とした

日々の結果はどうやって確認するのか

テスト結果はcsvで出力する

性能劣化が誰が見ても一目でわかるように、横軸を日付、縦軸をレスポンスタイムにして、折れ線グラフで可視化した

テスト結果はデータベースに管理
パーティショニングを使ったテーブル構成
redashというツールを使いテーブルからデータを読み込んでグラフにする

ここまで考えたのですが、タイムアップにより

csvをVBAに読み込ませグラフ化するシェルを手動実行

に留まっており、可視化した結果をチームの有識者が日々確認しています。

運用スケジュール

月曜日から金曜日の深夜12時半から性能回帰テストを実行、朝8時半には完了
土曜日のみ昼12時半から負荷テストを実行、13時半には完了

実は、負荷テストのjobがすでに存在していたため、これを機にCIに組み込み、バージョン管理も始めました。

テストシナリオ、テストデータの配置

サーバーに手動で配置
- 変更することがほとんどないため固定とした

テストがあることのメリット

性能改善を行った時のテストが楽
- 日々の結果をグラフにしているので、改善したコードをmasterにマージした翌日から、改善できたことが一目でわかる
- 正常系のシナリオを作っているので、性能改善以外にもデグレしていないかの担保にもなる
サーバーやOSのリプレイス、MWのメジャーバージョンアップをした時のテストに使える
- バージョンを上げる前のデータを取り直す必要もなく、比較ができるためわざわざテストを組む必要がない
- JenkinsのJobを作って退勤時にボタンをポチッとするだけで、翌朝にはテストが終わって業務時間を有効に使うことができる

人がテストをする必要がなく、より創造的なことに時間を使うことができます。

最後に

『まずは価値を届ける』を軸にこの改善プロジェクトを進めました。

テストがあることのメリットは、実際に運用を始めた後に実務で活用した事例です。タイムアップして手動にとどまった点もありますが、手動の部分があっても十分に性能回帰テストの価値を届けられています。むしろプラスαで活用できています。

今後、手動部分を自動にして少しでも手がかからないようにしていきたいです。

エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。

https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gle
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com