パフォーマンス テストのベスト プラクティス

信頼性の高いテスト オートメーションを設計する

スケーリングする前に、テスト ケースが堅牢でデータの安定性があり、信頼できない要素がないことを確認します。

ランプ アップおよび期間の戦略を選択する

段階的なランプ アップを使用して現実的なトラフィックをシミュレートし、現実ではありえないほど長いピーク フェーズや短いピーク フェーズを避けます。

大規模なテスト データを処理する

パラメーター化されたデータセットを (Data Fabric を使用して) 準備し、重複する入力があるために結果に偏りが発生することがないようにします。

陥りやすい落とし穴を回避する

• 十分なインフラストラクチャ リソースがあることを確認します。
• パブリッシュする前にテストをローカルで検証します。
• 最新のパッケージ バージョンを使用します。

ブラウザー操作の自動化

以下の推奨事項は、パフォーマンス テスト、特にブラウザー操作の自動化のシナリオの一般的なベスト プラクティスを拡張したものです。パフォーマンス テストでは、複数の仮想ユーザー (VU) を同じマシン上で同時に実行する必要があります。このため、シングルユーザー実行には存在しない制約が生じます。

1. ローカル ファイル システムの操作は避けてください。

   ローカル ファイルの読み取りまたはローカル ファイルへの書き込みを行うステップは、Windows ファイル ハンドルに依存します。Windows は、ファイル ハンドルが 1 つのプロセスによって開かれるとロックし、他のすべてのプロセスが同じファイルにアクセスできないようにします。これにより、複数の VU が同時に実行されるとエラーが発生します。

   一般的な例:

   • Excel または CSV からテスト データを読み取る — 複数の VU で同じファイルを同時に開くことはできません。代わりに Data Fabric を使用すると、ファイル ハンドルの競合なしにテスト データを同時に提供できます。
   • Word 文書へのスクリーンショットの書き込み — 証拠のキャプチャは通常、機能テストにのみ関連し、パフォーマンス テストの一部にしないでください。ロードテストでは、何百ものVUがループで実行され、反復ごとに独自のドキュメントが生成され、管理できない量のアーティファクトがすぐに生成されます。
   • その他のローカルファイルインタラクション (設定ファイル、ログファイル、中間データストア)はすべて、ファイルハンドルロックの対象となります。
2. Chromium API を優先 - ハードウェア イベントや Computer Vision を避けます。

   アプローチ	説明	Multi-VU の互換性
   Chromium API (シミュレートされた DOM イベント)	セレクターを使用して、ブラウザー インスタンス内の DOM 要素に対してイベントを直接トリガーします。OSレベルでは実際の入力は行われず、ブラウザが内部でインタラクションを処理します。	優秀 — インスタンスごとに独立しています。バックグラウンド ウィンドウで動作します。
   ハードウェア イベント	実際のマウス/キー入力を OS レベルで生成します。OS は、現在アクティブな (フォアグラウンド) ウィンドウに配信します。	Poor — 入力はフォアグラウンドにあるウィンドウに送られますが、必ずしも意図したブラウザインスタンスではありません。
   Computer Vision	画面上の視覚的なパターン マッチングによって要素を検索します。	実行不可能 — バックグラウンドのブラウザーインスタンスは画像認識から見えません。

3. 常に既定で Chromium API が使用されます。

   Chromium API は DOM 上に直接動作し、ブラウザー ウィンドウがフォアグラウンド、最小化、非表示のいずれであっても動作します。

4. ハードウェア イベントを回避します。

   ハードウェア イベントは 、OS によってアクティブ ウィンドウに配信されます。複数の VU がある場合、1 つのブラウザー インスタンスを対象としたハードウェア イベントが、現在フォアグラウンドにあるウィンドウに送信されます。ハードウェア イベントは、複数のオートメーションを同じマシン上で並列に実行する場合には適しません。

5. Computer Vision は避けてください。

   Computer Vision はバックグラウンド ウィンドウと対話できないため、マルチ VU の実行に対応していません。フレームワークが Computer Vision にフォールバックする最も一般的な理由は、誤ったセレクターやあいまいなセレクターです。開発中にセレクターが正しく、検証されていることを確認します。厳密セレクター (ID、データテスト属性、ARIA ロール) は、特に SAP Fiori などのアプリケーションで適切に機能します。あいまいセレクターは、Computer Vision のフォールバックをトリガーすることなく、意図した要素と確実に一致していれば、パフォーマンス テストにも適しています。

6. ドライランの推奨事項

   パフォーマンス シナリオにテスト ケースを初めて追加すると、ツールによってドライ ランを実行するように求められます。ドライ ランでは、同じマシン上で複数のインスタンスを実行し、ファイル ロック、入力の競合、セレクターの問題がないことを確認してから、全負荷にスケーリングします。