Was ist Performance Testing? 

Der Performance Test ist ein systematischer Testansatz, um die Leistung einer Anwendung unter Last zu validieren, in Bezug auf Reaktionsfähigkeit und Stabilität. Es kann auch dazu dienen, andere Qualitätsattribute des Systems, wie Skalierbarkeit, Zuverlässigkeit und Ressourcennutzung, zu untersuchen, messen, validieren und verifizieren.

Es ist ein besonderer QA-Prozess, der nach dem Abschluss einer Entwicklungsrunde, genutzt werden kann, um Engpässe zu finden. Anschließend wird ein Bericht über qualitative und quantitative Metriken generiert.

  

Performance Testing Arten

  • Load Test: die einfachste Form von Leistungstests. Ein Lasttest wird normalerweise durchgeführt, um das Verhalten des Systems unter einer bestimmten erwarteten Belastung zu verstehen. Diese Last kann die erwartete gleichzeitige Anzahl von Benutzern in der Anwendung sein, die eine bestimmte Anzahl von Transaktionen innerhalb der festgelegten Dauer ausführen. Dieser Test gibt die Reaktionszeiten aller wichtigen geschäftskritischen Transaktionen an. Die Datenbank, der Anwendungsserver usw. werden während des Tests ebenfalls überwacht, dies hilft bei der Identifizierung von Engpässen in der Anwendungssoftware und der Hardware, auf der die Software installiert ist.
  • Stress Test: wird verwendet, um die oberen Kapazitätsgrenzen innerhalb des Systems zu verstehen. Diese Art von Test wird durchgeführt, um die Robustheit des Systems in Bezug auf extreme Lasten zu bestimmen, und hilft Anwendungsadministratoren festzustellen, ob das System ausreichend funktioniert, wenn die aktuelle Last deutlich über dem erwarteten Maximum liegt.
  • Soak Test (Endurance Test): wird durchgeführt, um festzustellen, ob das System die erwartete Dauerbelastung aushalten kann. Während Soak-Tests wird die Speicherauslastung überwacht, um potenzielle Lecks zu erkennen. Ebenfalls wichtig, aber oft übersehen, ist der Leistungsabfall, z.B. sicherzustellen, dass der Durchsatz und/oder die Antwortzeiten nach einer längeren Dauer anhaltender Aktivität so gut oder besser sind als zu Beginn des Tests. Es geht im Wesentlichen darum, ein System über einen längeren, signifikanten Zeitraum einer erheblichen Last auszusetzen. Ziel ist es, herauszufinden, wie sich das System bei Dauereinsatz verhält.
  • Spike Test: wird durchgeführt, indem die von einer sehr großen Anzahl von Benutzern erzeugte Last plötzlich erhöht oder verringert und das Verhalten des Systems beobachtet wird. Das Ziel besteht darin, festzustellen, ob die Leistung darunter leidet, das System ausfällt oder dramatische Laständerungen bewältigen könnte.
  • Breakpoint Test (Capacity Test): ähneln Stresstests. Eine inkrementelle Last wird über die Zeit angelegt, während das System auf vorbestimmte Ausfallbedingungen überwacht wird. Die maximale Systemkapazität kann bestimmt werden und prüfen, ob das System die erforderlichen Spezifikationen oder Service-Level-Agreements (SLA) erfüllt – so eine Art Überwachung der Qualitätskriterien. Die Ergebnisse der Breakpoint-Analyse, die auf eine feste Umgebung angewendet werden, können verwendet werden, um die optimale Skalierungsstrategie festzustellen.
  • Regression Test: sollte sicherstellen, dass die eventuellen Änderungen der Testobjekte keine fehlerhaften Zustände und keine Performance Verschlechterung eingebaut haben.
  • Configuration Test: Anstatt die Leistung aus Lastperspektive zu testen, werden Tests erstellt, um die Auswirkungen von Konfigurationsänderungen an den Systemkomponenten auf die Leistung und das Verhalten des Systems zu bestimmen. Ein gängiges Beispiel wäre das Experimentieren mit verschiedenen Methoden des Loadbalancings.
  • Isolation Test: ist nicht nur Leistungstests vorbehalten, sondern umfasst die Wiederholung einer Testausführung, die zu einem Systemproblem geführt hat. Solche Tests können oft die Fehlerdomäne isolieren und bestätigen.
  • Volume Test: eine besondere Art Performance Testing, mit dem Ziel, das Verhalten des Systems zu testen, wenn die Last mit erheblichen Datenmengen/sehr großen Dateien erzeugt wird.
  • Scalability Test:  überprüfen die Fähigkeit des Systems erweitert zu werden, um die geforderte Anforderung erfüllen zu können.
  • Resilience Test: die Fähigkeit einer Lösung, die Auswirkung eines Problems auf einen oder mehrere Teile eines Systems zu absorbieren und gleichzeitig ein akzeptables Serviceniveau bereitzuhalten.

 

Mehr zu Performance Testarten hier:

 

Ziele:

Leistungstests können verschiedenen Zwecken dienen:

  • können nachweisen, dass das System die Leistungskriterien (Performance AKs) erfüllt
  • können zwei Systeme vergleichen, um herauszufinden, welches die bessere Leistung erbringt
  • können messen, welche Teile des Systems oder welche Arbeitslasten dazu führen, dass das System schlecht funktioniert

Viele Leistungstests werden durchgeführt, ohne dass hinreichend realistische, zielorientierte Leistungsziele gesetzt werden. Die erste Frage aus geschäftlicher Sicht sollte immer lauten: „Warum führen wir Performance Tests durch?“. Die Leistungsziele unterscheiden sich je nach Technologie und Zweck des Systems, sollten aber immer einige der folgenden Punkte beinhalten:

  • Parallelität und Durchsatz

Wenn ein System Endbenutzer durch irgendeine Art von Anmeldeverfahren identifiziert, dann ist ein Parallelitätsziel höchst wünschenswert. Definitionsgemäß ist dies die größte Anzahl gleichzeitiger Systembenutzer, die das System voraussichtlich zu einem bestimmten Zeitpunkt unterstützt. Der Arbeitsablauf einer skriptgesteuerten Transaktion kann sich auf echte Parallelität auswirken, insbesondere wenn der iterative Teil die Anmelde- und Abmeldeaktivität enthält.

Wenn das System kein Endbenutzerkonzept hat, basiert das Leistungsziel wahrscheinlich auf einem maximalen Durchsatz oder einer maximalen Transaktionsrate.

  • Antwortzeit des Servers

Ein einfaches Beispiel wäre eine HTTP-‚GET‘-Anforderung vom Browser-Client an den Webserver. Es könnte relevant sein, Server-Antwortzeitziele zwischen allen Knoten des Systems festzulegen.

  • Performance-Anforderungen

Es ist wichtig, die Performance-Anforderungen (Service-Level-Agrements und non-functional-requirements, SLA & NFR) detailliert zu beschreiben und sie in einem Performance-Test-Plan (Last Test Konzept) zu dokumentieren.

Häufig werden die Performance Tests nicht anhand einer Spezifikation durchgeführt, z. B. hat niemand spezifiziert, was die maximal akzeptable Antwortzeit für eine gegebene Population von Benutzern sein sollte. So werden die Tests als Teil des Optimierungsprozesses des Leistungsprofils verwendet. Die Idee dahinten ist, das „schwächste Glied“ zu identifizieren – es gibt zwangsläufig einen Teil des Systems, der, wenn es schneller reagiert, dazu führt, dass das Gesamtsystem schneller läuft.

 

Performance Anforderungen sollten mindestens die folgenden Fragen stellen:

  • Was ist der Leistungstestumfang im Detail? Welche Subsysteme, Schnittstellen, Komponenten usw. sind in diesem Test enthalten und welche nicht?
  • Wie viele gleichzeitige Benutzer werden für die beteiligten Benutzeroberflächen (UIs) jeweils erwartet (Spitze vs. Nominalwert angeben)?
  • Wie sieht das Zielsystem (Hardware) aus (sind alle Server- und Netzwerkgerätekonfigurationen spezifiziert)?
  • Wie sieht der Anwendungs-Workload-Mix der einzelnen Systemkomponenten aus? (Beispiel: 20 % Anmeldung, 40 % Suche, 30 % Artikelauswahl, 10 % Kasse)
  • Was ist der System-Workload-Mix? [Mehrere Workloads können in einem einzigen Leistungstest simuliert werden] (Beispiel: 30 % Workload A, 20 % Workload B, 50 % Workload C)
  • Wie hoch sind die Zeitanforderungen für beliebige/alle Back-End-Batch-Prozesse (Peak vs. Nominal angeben)?

Voraussetzungen

Ein stabiler Build des Systems, der der Produktionsumgebung so ähnlich wie möglich sein muss.

Um konsistente Ergebnisse zu gewährleisten, sollte die Performance Test Umgebung von anderen Umgebungen wie Benutzerakzeptanztests (UAT) oder Entwicklung isoliert werden. Als bewährte Methode ist es immer ratsam, eine separate Performance Test Umgebung(PTE) zu haben, die der Produktionsumgebung so weit wie möglich ähnelt.

Testbedingungen

Bei Performance Test ist es oft entscheidend, dass die Testbedingungen der erwarteten tatsächlichen Nutzung ähneln. In der Praxis ist dies jedoch schwer zu arrangieren und nicht vollständig möglich, da Produktionssysteme unvorhersehbaren Arbeitslasten ausgesetzt sind.

Zeitliche Koordinierung

Je später ein Leistungsmangel erkannt wird, desto höher sind die Kosten für die Behebung. Dies gilt für Funktionstests, aber noch mehr für Performance Tests, da deren Umfang Ende-zu-Ende ist. Es ist entscheidend, dass ein Performance-Test Team so früh wie möglich eingebunden wird, da es zeitaufwendig ist, die Testumgebung und andere wichtige Performance Test Voraussetzungen zu beschaffen und vorzubereiten.

Performance Skripten

Performance Tests werden hauptsächlich in zwei Hauptkategorien unterteilt. Performance Skripten befasst sich hauptsächlich mit der Skripterstellung der Arbeitsabläufe der wichtigsten identifizierten Geschäftsprozesse. Dies kann mit einer Vielzahl von Tools erfolgen. Die meisten Tools ermöglichen etwas  „Record & Replay“, bei dem der Performance Tester das Testtool startet, es in einen Browser oder Thin Client einbindet und alle Netzwerktransaktionen erfasst, die zwischen Client und Server stattfinden. Dabei wird ein Skript entwickelt und erweitert/modifiziert, um verschiedene Geschäftsszenarien zu emulieren.

Performance monitoren

Die zweite Kategorie befasst sich mit „monitoring“. Beim Performance-Monitoring wird das Verhalten und Antwortverhalten der zu testenden Anwendung (SUT) beobachtet. Die folgenden Parameter werden normalerweise während der Ausführung eines Performance-Tests überwacht:

Server Hardware Parameters: CPU-Auslastung, Speicherauslastung, Festplattenauslastung, Netzwerkauslastung.

In einem ersten Schritt liefern die von diesen 4 Parametern generierten Muster einen guten Hinweis darauf, wo der Engpass liegt. Um die genaue Ursache des Problems zu ermitteln, können weitere Metriken verwendet werden. Zusätzlich können Tools wie Profiler verwenden werden, um zu messen, welche Teile eines Geräts oder einer Software am meisten zur schlechten Leistung beitragen, oder um Durchsatzniveaus (und Schwellenwerte) für eine akzeptable Antwortzeit festzulegen.

 Technology

Die Performance Test Technologie verwendet einen oder mehrere Rechner/VMs, die als Injektoren fungieren um einer Anzahl von Benutzern zu emulieren und jeweils eine automatisierte Abfolge von Interaktionen auszuführen (aufgezeichnet als Skript oder als eine Reihe von Skripts, um verschiedene Benutzertypen zu emulieren). Normalerweise fungiert ein separater Rechner/VM als Testleiter, der Metriken von jedem der Injektoren koordiniert und sammelt und Leistungsdaten für Berichtszwecke zusammenstellt.

Mögliche Performance Test Unteraufgaben:

  • Entscheiden, ob interne oder externe Ressourcen zur Durchführung der Tests eingesetzt werden sollen, je nach internem Fachwissen (oder dessen Mangel)
  • Sammeln Performance Anforderungen von Benutzern und/oder Geschäftsanalysten
  • Entwickelung  eines übergeordneten Performance Plan (Projektauftrag), einschließlich Anforderungen, Ressourcen, Zeitplänen und Meilensteinen
  • Entwickelung eines detaillierten Performance Test Konzept (einschließlich detaillierter Szenarien und Testfälle, Workloads, Umgebungsinformationen usw.) mit allen Abhängigkeiten und zugehörigen Zeitleisten
  • Performance Testwerkzeug(e) auswählen
  • Die erforderlichen Performance  Testdaten vorbereiten und den Aufwand realistisch einschätzen (oft übersehen, aber für die Durchführung eines gültigen Performance Test unerlässlich)
  • Entwickelung eines Proof-of-Concept-Skripte für jede zu testende Anwendung/Komponente
  • Injektoren/Controller installieren und konfigurieren
  • Konfigurieren die Performance Testumgebung (idealerweise produktionsnahe)
  • Probelauf der  POC Performance Testskript – Vor der eigentlichen Ausführung des Lasttests mit vordefinierten Benutzern wird ein Probelauf (Smoke Performance Test) durchgeführt, um die Korrektheit des Skripts zu überprüfen.
  • Performance Test Ausführung  – wahrscheinlich wiederholt (iterativ), um zu sehen, ob ein nicht berücksichtigter Faktor die Ergebnisse beeinflusst
  • Ergebnisse Analyse – entweder bestanden/nicht bestanden oder Untersuchung des kritischen Pfads und Empfehlung von Korrekturmaßnahmen

 Methodik

  • Performance Testumgebung identifizieren
  • Performance Akzeptanzkriterien und SLAs identifizieren
  • Testobjekte identifizieren, Testdesign und Testszenarien planen
  • Performance Test Umgebung konfigurieren inklusive Testdaten bereitstellen (synthetisch oder Anonymisierung produktiver Testdaten)
  • Lastmodel ausarbeiten und Workload definieren
  • Testdesign implementieren
  • Skripterstellung und Skript/Szenario Ausarbeiten
  • Performance Test ausführen und monitoren
  • Tests und Testdaten validieren und die Ergebnisse erfassen
  • Ergebnisse analysieren, Tune, Re-Test
  • Reporting

 Verwandte Artikel: