パフォーマンステストはビルドツールで計測する必要がありますか？

Question

パフォーマンステストは、ビルドプロセスの一部としてビルドツールによって計測する必要がありますか、それとも完全に外部に存在する必要がありますか？外部の場合、展開パイプラインのどこに配置する必要がありますか？

現在、統合テストのライフサイクルフェーズにパフォーマンステストが添付されています。今のところは問題ありませんが、これは正しくないように思われるので、これらのパフォーマンステストをどこにアタッチして実行するかについて実際の答えを見つけるのに苦労しています。

質問のために、CIにJenkinsを使用し、ビルドツールとしてMavenを使用する環境を想定できます。スクラムSDLCを想定することもできます。

Josh Johnson · Accepted Answer

通常、パフォーマンス/負荷テストについて心配する理由は2つあります。チームが単純なアルゴリズムを作成するのに問題があるか、特定のパフォーマンス要件がSLAの一部であるかのいずれかです。 3番目の理由は、チームのメンバーがパフォーマンス、別名早期最適化について心配したいということです。

パフォーマンステストを単体テストの一部にすることはできません。ユニットテストは、定義上、ユニットの正確さをテストするためのものです。バブルソートとクイックソートはどちらも、ソート要件の有効な実装です。パフォーマンス要件がある場合でも、その要件はユニットではなく、システムの垂直スライスにあります。ボトルネックがこのユニットであると想定することは、想定しすぎです。また、単体テストの実行に時間がかかりすぎる場合（理想的には、1秒未満、10を超えない）、それらは役に立たなくなります。開発者は、それらの実行頻度を減らすか、まったく実行しないか、テストの作成を停止します。これには2つの選択肢があります。

パフォーマンステストをデプロイメントパイプラインの一部にします。パフォーマンステストは、すべてのコミット（またはパイプラインをトリガーするアクション）の一部として、ユニットテストと統合テストの後に実行されます。それらはビルドされたアーティファクトで実行されます。 a SLAが特定のパフォーマンス特性を要求する場合、またはチームのコード品質に問題がある場合は、このルートに進んでください（ "ジミーがコミットするたびに、サーバーは高負荷でひざまずきます。問題のデバッグに何日も費やしています！」）。

夜間にパフォーマンステストを実行します。パフォーマンステストは、1日の特定の時間に実行するようにスケジュールされています。これは、パフォーマンス/負荷テストに時間がかかる場合に適しています。前のルートに行ったかもしれませんが、これらのテストは、必要な頻度でリリースする際のボトルネックになりつつあります。それらをより頻繁に実行する習慣を身に付けたので、おそらくあなたのチームは単純なアルゴリズムを書くのが上手になったでしょう。たぶん今、あなたはあなたの負荷テストを「私たちが本番環境に展開する前に絶対に必要なテスト」と「私たちを良い状態に保つがそれらの問題はそれほど表面化しないテスト」に分けることができます。

Doc Brownが述べたように、パフォーマンステストの実行には1週間かかる可能性があります。しかし、それはそのようなエッジのケースです。そこに着いたら、それを理解するためにあなたに任せます。調査結果をここに報告してください。

統合テストフェーズの一部としてパフォーマンステストを実行するのは適切ではありません。パフォーマンステストと負荷テストは、通常、アプリケーションの垂直スライスの問題を追跡するために使用されます。これにより、どこに飛び込むかがわかります。パフォーマンスは気まぐれな獣であるため、サービスをモックアウトする価値はあまりありません。これらのサービスは、さまざまな負荷の下でさまざまに応答します。ただし、サンドボックスを提供できないサードパーティのエンドポイントが存在する可能性は確かにあります。たぶん、あなたは生産の応答時間を取り、それらを適切にスタブ化することができます。新しいデータが毎日届くので、その応答時間は自動化することさえできます。

ワンサイズですべてに対応できるわけではありません。前進すると、新しいソリューションに出くわすと思います。

Doc Brown · Answer

自問してみてください。どのようなパフォーマンステストがあり、どのくらいの頻度で実行されますか必要ですか実行されますか？

「日常使用」のテスト？次に、それらを単体テストの一部にします。
すべてのリリース/展開のQAサイクルだけですか？それらを統合テストの一部として保持します（これらのテストはリリース/デプロイメントごとに実行されると想定しています）。
アプリケーションの分離された部分をテストします。最適化の目的で一度だけ必要で、その後は二度と必要ありませんか？次に、それらをCIサイクルから除外します。

これらのテストの実行時間はおそらく要因になります。パフォーマンステストに必要な時間が20分未満の場合は、CIサーバーの「ナイトリービルド」にそれらを統合するのにそれほど問題はありません。完全に実行するのに1週間必要な場合は、明らかに別の戦略が必要です。

そして私の理解では、「スクラム」のようなアジャイルモデルを使用することは、構築しているソフトウェアにプロセスを適応させることを意味し、その逆ではありません。したがって、「パフォーマンステストをどこに配置するか」の決定は最終的なものではない可能性があります。最初に非常に高速なテストがあり、時間の経過とともに拡張するほど遅くなる場合は、プロセス内でテストを再配置したり、分割したり、ニーズに合わせて変更したりする必要があります。