回答。

歴史的に、ソフトウェアのパフォーマンスは、主な機能部分の後にチェックされていました。開発者は手動でスクリプトを実行するか、JMeterのようなツールを使用して測定を行いました。DevOpsおよびCI/CDへの大規模な移行に伴い、これらのプロセスを自動化し、各供給段階でメトリクスを取得する必要が生じました。

問題は、負荷の自動化が単なるテストの実行ではなく、負荷シナリオの微調整、ユーザープロファイルの再現、実ネットワークのエミュレーション、遅延の考慮、テストハードウェアの制限を含むため、複雑化することです。

現代の解決策は、特化したツール（例：Gatling、Locust、k6）の導入、ユーザープロファイルのパラメータ化を伴うシナリオの作成、CIパイプラインへのパフォーマンステストの統合、メトリクスの収集と分析の自動化、パフォーマンスの低下時のアラート設定です。

主要な特徴：

負荷シナリオの正しい設定（再現性と現実に近いこと）。
メトリクスの分析（ベンチマーキング、ストレス、長時間インターバルの分離）とその収集の自動化。
テスト結果が全体の納品品質やSLAの遵守に与える影響の評価。

意地悪な質問。

負荷テストの自動化は本番環境でのみ許可されるのですか？

いいえ。パフォーマンステストとストレステストは、SLAを破らないために専用のステージアプリケーション/スタンドで実行できます。そのため、自動化は本番環境に入る前に行う方が望ましいです。

負荷の自動テストが通過した場合、実際のユーザーエクスペリエンスに自信がありますか？

いいえ—自動テストはあくまで平均的な画像しか提供できません。実際のユーザーの行動はネットワーク状況、使用プラットフォーム、その他の模倣が難しい要因によって異なる場合があります。

応答時間の平均値のみに依存すべきですか？

いいえ。パーセンタイル（例えば95%や99%）を考慮することが非常に重要です。なぜなら、平均値は外れ値によって歪められることがあり、特に尾部の値がUXに対して最も影響を与えることが多いためです。

一般的なエラーとアンチパターン

「ログイン/ログアウト」のような簡単なシナリオのみに焦点を当て、ビジネスオペレーションのエミュレーションを無視する。
最悪のシナリオ（尾部遅延）の分析を無視する。
依存関係（例：サードパーティサービスの未解除やレート制限）の不十分な分析。

実際の例

ネガティブケース

ある会社はシステムログインのみでパフォーマンステストを導入しました：スクリプトは1000回のログインを実行し、平均応答を分析し、問題は解決したと考えました。最初の実際の実行時には大量のタイムアウトが発生しました—並行する「重い」ビジネスオペレーションが考慮されていないことが判明し、APIは負荷に耐えられませんでした。

利点：

単純なシナリオの稼働確認が迅速に行えました。

欠点：

重要なユーザーのシーケンスを無視したためにインシデントが発生しました。
偽の安定感を感じさせました。

ポジティブケース

別のチームでは、全負荷プロファイルが本番環境のモニタリングに基づいて構成され、特定のスクリプトが異なるデバイスやネットワークからのピーク活動をエミュレートしました。すべての結果は自動的にベンチマークと比較され、偏差が5%を超えるとアラートが発生し、リリースが一時停止されました。