まず、JMeterはコマンドラインから実行でき、これを行うときに変数を渡すことができるため、CIに含めるのに適しています。私はこのタスクにそれをお勧めします。
ただし、一般的には、Perfを統合します。CIへのテストは困難です。これが理由の多くをすでにリストしているので、制限を理解しているので、すでに途中まで進んでいます。そしてそれは摩擦です:Perfを持つことは可能です。CIでテストしますが、限られた範囲でのみテストします。
良いアプローチは、これらの原則のいくつかに従っていると思います。
CIで全負荷(またはソークまたは容量)テストを実行することはできません。これは実用的ではありません。
結果は主観的なものであり、人間による解釈が必要であり、テストの実行には時間がかかります。ただし、リクエストの応答時間を測定する、より単純で削減された一連のテストを実行してから、次のいずれかの応答時間を評価できます。
- NFRまたは予想される範囲に対して-つまり。1秒未満である必要があります。
- 以前の結果に対して-すなわち。前回のビルドより10%以上逸脱してはなりません。
自動ロード/パフォーマンスを実行することもできます。ビルドプロセスの外部で-フルボリュームで-テストします。「セミCI」。
では、テストを自動化して一晩実行し、午前中に結果を確認することはできますか?
繰り返します。
それを実行して結果を取得し、テストとそれらを時間の経過とともにどのように解釈するかを微調整するだけです。シンプルに保ち、役立つと思われる領域に焦点を合わせます。ファンファーレで立ち上げないでください。プロセスに自信が持てるようになるまで静かにしてから、ビルドに失敗して人々にそのことを伝え始めてください。最初は、多くの偽陰性が発生する可能性があります。
結果を計測する
これを行います。多くの。CIはすべて早期に失敗することであるため、目標を達成するときにそれを採用する場合、それを達成するための最善の方法は、テストを早期に頻繁に実行することですが、それに関する問題は、データに埋もれてしまうリスクです。したがって、データを処理して関連情報を提示するための効果的な方法は、非常に役立ちます。
レッドフラッググリーンフラッグまでのプロセス全体を自動化することはできませんが、可能な限りその道を進むように努める必要があります。
最後に、リードのパフォーマンスから非常に良い話がありました。この主題をカバーするGoogleのテスター。今は少し古いですが、原則はまだ残っています。さらに、数週間以内に、英国のメディア企業であるChannel4が、彼らがこれにどのように取り組んだかについて話し合うミートアップに行きます。スライドをお願いできるかもしれません。