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

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

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

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

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

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

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

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

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

ブラウザー操作の自動化

The following recommendations expand on the general best practices for performance testing, specifically for browser automation scenarios. Performance testing requires running multiple virtual users (VUs) simultaneously on the same machine, which introduces constraints that do not exist in single-user execution.

1. Avoid local file system operations.

   Any step that reads from or writes to a local file relies on Windows file handles. Windows locks a file handle when it is opened by one process, blocking all other processes from accessing the same file. This causes failures when multiple VUs run concurrently.

   一般的な例:

   • Reading test data from Excel or CSV — Multiple VUs cannot open the same file simultaneously. Use Data Fabric instead to serve test data concurrently without file handle contention.
   • Writing screenshots into Word documents — Evidence capture is typically only relevant for functional testing and should not be part of a performance test. In a load test, hundreds of VUs run in loops — each iteration would generate its own documents, quickly producing an unmanageable volume of artifacts.
   • Any other local file interaction — Configuration files, log files, intermediate data stores — all are subject to file handle locking.
2. Prefer Chromium API - Avoid Hardware Events and Computer Vision.

   Approach	説明	Multi-VU Compatibility
   Chromium API (simulated DOM events)	Triggers events directly on DOM elements within the browser instance via selectors. No real input occurs at OS level — the browser handles the interaction internally.	Excellent — independent per instance; works on background windows.
   ハードウェア イベント	Generates real mouse/key input at OS level. The OS delivers it to the currently active (foreground) window.	Poor — input goes to whichever window is in the foreground, not necessarily the intended browser instance.
   Computer Vision	Locates elements by visual pattern matching on screen.	Not viable — background browser instances are invisible to image recognition.

3. Always default to Chromium API.

   Chromium API operates directly on the DOM and works regardless of whether the browser window is in the foreground, minimized, or hidden.

4. Avoid Hardware Events.

   Hardware events are delivered by the OS to the active window. With multiple VUs, a hardware event intended for one browser instance will be sent to whichever window is currently in the foreground. Hardware events are not suited when multiple automations run in parallel on the same machine.

5. Avoid Computer Vision.

   Computer Vision cannot interact with background windows and is therefore incompatible with multi-VU execution. Incorrect or ambiguous selectors are the most common reason a framework falls back to computer vision. Ensure selectors are correct and validated during development. Strict selectors (IDs, data-test attributes, ARIA roles) work well, particularly for applications like SAP Fiori. Fuzzy selectors are also compatible with performance testing as long as they reliably match the intended element without triggering a computer vision fallback.

6. Dry Run recommendation

   When you add a test case to a performance scenario for the first time, the tool prompts you to perform a dry run. A dry run runs multiple instances on the same machine to confirm there are no file locks, input conflicts, or selector issues before scaling to full load.