はじめに
前回の投稿いつ？そんなこと愚問です。
性能回帰テストを自動化するプロジェクトっぽいことをやっているので、今日までの取り組みをお話しできればと思います。
技術要素というより、どのように考えて進めているのかがメインです。
自動化と言う前にやったこと
自動化！！
すごく楽になるそんな夢のような仕組み♡やりたい！！自動化、Automation、ジドウカ、judoka
はい。一旦、冷静に一呼吸置いて落ち着きましょう。
自動化する目的は？自動化して得られる効果は？手段が目的になっていませんか？
エンジニアが突っ込まれてテンションが下がる言葉ですが、、、
技術というのは課題、問題を解決する手段の一つです。
自動化すると言って手を動かす前に、目的を整理する。
自分やプロジェクトが抱えてる課題は本当に自動化で解消、緩和されますか？
漠然と自動化すればなんとかなると考えていないですか？
整理した後、フィードバックをもらうといいと思います。
私が整理した内容です。言うほど大したことないです。
目的、手段、背景・課題、効果 この観点で概要をまとめました。
■ 概要説明 ■
＜目的＞
テストコストの抑制/削減を行う
＜手段＞
・ CI環境に組み込みテスト実行と結果出力を自動化する
・ JMeterでテストシナリオを実行し、レスポンスタイムを計測する
＜背景・課題＞
性能改善を実施したが新機能追加、改修を続けながら性能を維持する必要がある。
しかし、そのためには機能開発毎にテストが必須となり、テストコストの増加が予測できる。
＜効果＞
毎日自動でテスト実行することで以下のような効果が得られる
・ 自動化することにより、性能劣化を担保するテストコストを削減することができる。
・ 毎日テストを実行することで、性能劣化の早期発見、早期対応が可能となり、
アプリケーションの保守コストを最小限に抑えることができる。
現状把握
目的地までの道順を確認する時、自分の現在地がわからないと道順も出てきません。
日常生活の中で何気なくやってる思考が仕事でも十分役立ちます。
話がやや脱線しましたが、、
CIに組み込むと意気込んだものの、今動いてる環境の構成図ありませんでした。先輩から後輩と一緒レクチャーを受け後輩に構成図を描いてもらいました。あなたは何をしたの？もちろん温かく後輩ちゃんを見守っていました(^^)
既存の構成図に新しく構築したいものを組み込んで完成！ドキュメント作成はメンバーと認識を共有するするためのものです。毛嫌いする人もいますが、コミュニケーションをとる手段の１つではないでしょうか。
青線が静的解析のフローで、オレンジ線が今回追加しようと動いている性能回帰テストのフローになります。
どんなテストフローにするー？
人の手でやっているテストを実行するまでの段取りを書き出してみました。
基本的に人が手でやってたことを自動にすることが自動化だと私は理解しています。
いつ(何時から)どんなデータでどのようなテストを行う？
私が描いていたシナリオ
- テストデータは毎日作って破棄
- 全画面のレスポンスを測定するテストシナリオ
- 0時からテスト開始、8時には完了
- レスポンスタイム結果を出力
まず、
1.テストデータは毎日作って破棄
日々新規開発は続いているので、それに合わせると毎日テストデータは作る方がメンテコストが抑えられる。
2.全画面のレスポンスを測定するテストシナリオ
せっかくの自動化なのでテストできるものは全部組み込んでしまおう。
3.0時からテスト開始、8時には完了
弊社の始業時間は9時なので、1時間前までには終わればいいかな程度。8時間あれば終わるでしょうという考え。
4.レスポンスタイム結果を出力
とりあえず出力結果をCSVで出力、レスポンスタイムの平均値とかスループットの表を出力します。可視化もしたいが、まずは結果を出力するまでを行う。
案外ざっくり決めです。
実際にシナリオ流してみた
試しに流してみると、テストデータを作るのに4〜5時間。全画面のテストの3割を流すのに3時間はかかってしまうことがわかったのです。3割で3時間って、、、。
あれ？？あれれれれれぇ〜。
※名探偵○ナンくんばりでご想像ください。
このままでは、全画面テストって無理。
しかもテストデータの作成に想定していたより時間がかかる。
ということに気づきました。
考えていたストーリーが本当に実現できるのか？
というのを早めに試作して検証することをオススメします。
新規機能の開発も同じですが、想定外なことが起こることは早めに気づくとリカバリという手段が見いだせます。
課題解決
- テスト数全体の3割で3時間の実行時間がかかる
- テストシナリオの管理、メンテナンスどうするか
- 日々の結果はどうやって確認するのか
ごめんなさい、現在進行中です（笑）
テストは間引く方向で考えています。そう至った経緯ですが、
今年の初めにJaSST'18 Tokyo ソフトウェアテストシンポジウムでの
GoogleのJohn Micco氏の基調講演を思い出したからです。
内容を掻い摘むと以下
- Googleでは全てのテストは自動化してる
- とはいえ、全部のテストを実行してリリースするのは、コストがかかるし、時間もかかるから、間引いてる
- 自動化すると、なぜテスト結果NGなのかわからないものもでてくる(自動化による新たな課題)
詳しい内容は弊社の技術者ブログ（JaSST'18 Tokyo 参加レポート）をご覧ください。私が執筆したわけじゃごさいません。
そんなセッションを聴いた当時の私の感想は、
自動テストをどう効率化するかで悩むとか、悩みの次元が違うな。
くらいにしか捉えていませんでした。
今回似たような課題に出くわし、次元は一緒でした。
- 自動化することによって、効率化、時間を有効に使えるが、テスト実行に必要な時間は単純に短くならない(自動化は魔法ではない。1日24時間は変えることはできない。)
- 限られた時間内に効率良くやりぬく策を見出すしかない
- テストによって保証したいことは何か
テスト自動化しても、テストに対する本質って変わらない。
それが自動化したとしても見失ってはならないものと気づかされました。
まずは価値を届ける
今回私がこのプロジェクトっぽいことを進める上での軸です。進めていると、あれやりたい、これやりたい！！と、どうしても欲が湧いてきます。でも、使える時間は限られてます。そんな時、ぐっとこらえて、それをやらないと自動化できないか？目的は達成できないか？を考えます。そして、泣く泣くやりたいリストの中にそーっとしまうのです。
どんなに豪華にしても、価値を届けられないと自己満足で終わってしまいます。
最後に
これからプロジェクトは佳境に向かっていきます。まだきっとこれから、想定してない出来事が待ってると思います。ワクワクしますね（笑）
3ヶ月後、結末をお届けできるよう頑張ります。