バグがあるときはいつでも、私の最初の作業は、バグが存在することを示す失敗するテストを作成することです。自動化されたテスト スイートに追加すると、このテストはバグが再び発生しないようにするのに役立ちます。
ただし、パフォーマンスのバグにより、これを行うことができません。パフォーマンスの主張は、自分のマシンでのみ正しく、自動化されたテスト スイートにチェックインするのには適していません。これにより、バッグから退行を防ぐための通常のツールが必要になります。
独自のコードでパフォーマンスの低下を防ぐにはどうすればよいですか?
理想的な答え：
素晴らしい質問ですが、難しい問題です。
質問で示したように、問題の核心は環境の違い、つまり開発ボックスとテスト/QA 環境の違いです。
パフォーマンスの低下を軽減するには、テスト環境に自動的に展開するだけでなく、継続的な展開環境をセットアップすることもできます。また、可能な限り最終的な運用環境に類似した操作パラメーターを持つ QA 環境にも展開する必要があります (類似のハードウェアなど)。 、同様のサイズのデータ セットなど)。これは、一般に「1 回のビルドで多数のデプロイ」として知られています。
この継続的な展開システムを配置したら、パフォーマンスの制約を確認するための受け入れテストも含める必要があります。たとえば、システムは、一般的な非機能要件 (NFR) である x ミリ秒/秒以内に要求に応答する必要があります。コードがチェックインされると、これらの環境に対して自動的にテストされるため、パフォーマンスの問題が発生したときにすぐに確認できます。
これらのパフォーマンスの問題をデバッグするために、テストの実行中にパフォーマンス メトリックを記録することも理想的です。これらのテストは、問題が発生している可能性がある場所に関する良い指標を提供する場合があります。たとえば、特定のメソッドが完了するまでに多くの時間がかかっていることを確認できます。
このセットアップを実際に確立するのは困難ですが、「すぐに失敗」し、パフォーマンスの問題をすばやく検出できることは間違いありません。