Best Practices für Leistungstests

Entwerfen Sie zuverlässige Testautomatisierungen

Stellen Sie sicher, dass Testfälle robust, datenstabil und frei von Fehlern sind, bevor Sie sie skalieren.

Auswählen von Anlauf- und Dauerstrategien

Nutzen Sie eine schrittweise Hochlaufphase, um einen realistischen Datenverkehr zu simulieren und un realistisch lange oder kurze Peak-Phasen zu vermeiden.

Verarbeiten Sie Testdaten in großem Maßstab

Bereiten Sie parametrisierte Datasets (über Data Fabric) vor, um doppelte Eingaben zu vermeiden, die die Ergebnisse verfälschen könnten.

Vermeiden Sie häufige Fallstricke

• Stellen Sie sicher, dass ausreichend Infrastrukturressourcen vorhanden sind.
• Validieren Sie Tests lokal vor der Veröffentlichung.
• Verwenden Sie die neuesten Paketversionen.

Browser-Automatisierung

Die folgenden Empfehlungen erweitern die allgemeinen Best Practices für Leistungstests, insbesondere für Browserautomatisierungsszenarien. Leistungstests erfordern die gleichzeitige Ausführung mehrerer virtueller Benutzer (VUs) auf derselben Maschine, was Einschränkungen mit sich bringt, die bei der Ausführung mit einem einzelnen Benutzer nicht vorhanden sind.

1. Vermeiden Sie lokale Dateisystemvorgänge.

   Windows-Dateihandles sind für jeden Schritt erforderlich, der aus einer lokalen Datei liest oder in diese schreibt. Windows sperrt ein Dateihandle, wenn es von einem Prozess geöffnet wird, und blockiert alle anderen Prozesse daran, auf dieselbe Datei zuzugreifen. Dies führt zu Fehlern, wenn mehrere VUs gleichzeitig ausgeführt werden.

   Häufige Beispiele:

   • Lesen von Testdaten aus Excel oder CSV – Mehrere VUs können dieselbe Datei nicht gleichzeitig öffnen. Verwenden Sie stattdessen Data Fabric, um Testdaten gleichzeitig ohne Dateihandle-Konflikt zu erstellen.
   • Schreiben von Screenshots in Word-Dokumente – Die Nachweiserfassung ist in der Regel nur für Funktionstests relevant und sollte nicht Teil eines Leistungstests sein. In einem Lasttest werden Hunderte von VUs in Schleifen ausgeführt – jede Iteration würde eigene Dokumente generieren, was schnell zu einer nicht mehr zu bewältigenden Menge an Artefakten führte.
   • Jede andere lokale Dateiinteraktion – Konfigurationsdateien, Protokolldateien, Zwischendatenspeicher – unterliegt alle der Sperre von Dateihandles.
2. Bevorzugen Sie Chromium-API – Vermeiden Sie Hardware-Ereignisse und Computer Vision.

   Ansatz	Beschreibung	Multi-VU-Kompatibilität
   Chromium-API (simulierte DOM-Ereignisse)	Löst Ereignisse direkt auf DOM-Elementen innerhalb der Browserinstanz über Selektoren aus. Auf Betriebssystemebene erfolgt keine echte Eingabe – der Browser verarbeitet die Interaktion intern.	Ausgezeichnet – unabhängig pro Instanz; funktioniert bei Hintergrundfenstern.
   Hardware-Ereignisse	Generiert echte Maus-/Tasten-Eingaben auf Betriebssystemebene. Das Betriebssystem liefert sie im aktuell aktiven Fenster (Vordergrund).	Schlecht – Die Eingabe wird in das Fenster im Vordergrund verschoben, nicht unbedingt in die gewünschte Browserinstanz.
   Computer Vision	Sucht Elemente durch visuellen Musterabgleich auf dem Bildschirm.	Nicht brauchbar – Browserinstanzen im Hintergrund sind für die Bilderkennung unsichtbar.

3. Immer standardmäßig Chromium-API verwenden.

   Chromium-API wird direkt auf dem DOM ausgeführt und funktioniert unabhängig davon, ob sich das Browserfenster im Vordergrund befindet, minimiert oder ausgeblendet ist.

4. Vermeiden Sie Hardware-Ereignisse.

   Hardware-Ereignisse werden vom Betriebssystem an das aktive Fenster übermittelt. Bei mehreren VUs wird ein Hardwareereignis, das für eine Browserinstanz vorgesehen ist, an dasjenige Fenster gesendet, das sich gerade im Vordergrund befindet. Hardware-Ereignisse sind nicht geeignet, wenn mehrere Automatisierungen parallel auf derselben Maschine ausgeführt werden.

5. Vermeiden Sie Computer Vision.

   Computer Vision kann nicht mit Hintergrundfenstern interagieren und ist daher mit der Ausführung mehrerer VU nicht kompatibel. Falsche oder mehrdeutige Selektoren sind der häufigste Grund, warum ein Framework auf Computer Vision zurückgreift. Stellen Sie sicher, dass Selektoren korrekt sind und während der Entwicklung validiert werden. Strikte Selektoren (IDs, Datentestattribute, ARIA-Rollen) funktionieren gut, insbesondere für Anwendungen wie SAP Fiori. Fuzzy-Selektoren sind auch mit Leistungstests kompatibel, solange sie zuverlässig mit dem beabsichtigten Element übereinstimmen, ohne ein Computer Vision-Fallback auszulösen.

6. Empfehlung im Trockenlauf

   Wenn Sie einen Testfall zum ersten Mal zu einem Leistungsszenario hinzufügen, werden Sie vom Tool aufgefordert, einen Leerlauf zu durchführen. Bei einem Leerlauf werden mehrere Instanzen auf derselben Maschine ausgeführt, um zu bestätigen, dass keine Dateisperren, Eingabekonflikte oder Selektorprobleme vorliegen, bevor auf die Volllast skaliert wird.