Software-Performance-Tests: Die richtigen Methoden und Tools

Legen Sie Leistungsanforderungen fest

Stellen Sie sich einen Webbrowser vor, der 20 Minuten zum Rendern einer Webseite benötigt. Oder eine Streaming-Plattform, die Videos perfekt rendert, aber alle drei Minuten die Verbindung verliert. Zwar mag die Funktionalität der Software gegeben sein, aber diese Art von Leistung ist für reale Benutzer kaum gut genug.

Software muss einwandfrei funktionieren und ein akzeptables Leistungsniveau liefern. Ob dies der Fall ist – dies überprüfen Leistungstests. Der Zweck von Performance-Tests besteht darin, die Kapazität und Fähigkeiten einer Anwendung zu checken und zu validieren.

Die Leistung einer Software ergibt sich aus ihrem Design – aus ihrer Codierung und der Effizienz der Anwendungsarchitektur. Die Softwareleistung wird aber genauso von der Betriebsumgebung beeinflusst, zu der Rechenressourcen wie das Netzwerk und die Storage-Hardware gehören. Um die Software-Performance zu messen, müssen die Teams den Build deshalb in einer dedizierten Testumgebung ausführen. Diese sollte den Produktionssystemen ähnlich sein, einschließlich der Hardwaretypen und des Traffic-Aufkommens.

Bevor Sie Software entwerfen und testen, sollten Sie immer abschätzen, wo Probleme auftreten könnten. Im Folgenden finden Sie vier Leistungskriterien, die bei Vorliegen schlechter Werte wahrscheinlich Anlass zur Sorge geben.

Start- oder Ladezeit. Jede Software benötigt eine begrenzte Zeit zum Laden und Starten. Endbenutzer sehen oft Balken oder animierte Cursor, während die Software aufgerufen wird. Komplexere Programme können eine umfangreiche Einrichtung, Konfiguration und interne Tests erfordern, bevor die Benutzer mit der Arbeit beginnen können.

Beispielsweise kann die Software die Abhängigkeiten zu anderer Software prüfen und sicherstellen, dass alle notwendigen Dateien vorhanden sind. Diese Aufgaben verlängern die Ladezeit. Aus Anwenderperspektive sollten die Startzeiten so kurz wie möglich sein – so wie bei mobilen Anwendungen, die in der Regel deutlich schneller sind und innerhalb weniger Sekunden geladen werden. Es ist jedoch nicht ungewöhnlich, dass bei Unternehmensanwendungen Ladezeiten von mehr als einer Minute auftreten.

Reaktionszeit oder Latenz. Die Reaktionszeit oder Latenz ist die Zeitspanne zwischen der Eingabe des Benutzers und dem Zeitpunkt, zu dem die Software auf diese Information reagiert. Im Idealfall sollten die Antwortzeiten einer Software für den Endbenutzer nicht wahrnehmbar sein. Der schlechteste Fall sind extrem lange Ladezeiten: Stellen Sie sich vor, wie frustrierend es ist, wenn Tastatureingaben zehn Sekunden benötigen, um in einem Dialogfeld angezeigt zu werden. Solch lange Antwortzeiten können insbesondere von Abhängigkeiten verursacht werden, wenn etwa Hardwareprobleme wie ein unterdimensioniertes Netzwerk bestehen.

Begrenzte Last oder schlechte Skalierbarkeit. Enterprise-Client/Server-Anwendungen sollten eine limitierte Anzahl gleichzeitiger Benutzer ohne Beeinträchtigung der Softwareleistung bewältigen können. Durch Skalierbarkeit wird sichergestellt, dass die Anwendung über die dafür notwendigen Ressourcen verfügt. Leistungstests evaluieren die Software unter verschiedenen Lastbedingungen. Unzureichende Ressourcen, wie zum Beispiel zu knapp bemessene Serverrechenleistung, können eine schlechte Skalierbarkeit verursachen. Doch das ist nicht alles. Softwareleistung setzt sich grundsätzlich aus Ressourcen plus Design zusammen, und viele Skalierbarkeitsprobleme resultieren aus einer schlechten Anwendungsarchitektur.

Engpässe. Jede Anwendung greift auf eine endliche Anzahl an Ressourcen zu. Dazu gehören zum Beispiel Rechenleistung, Speicherplatz, Netzwerkbandbreite und -durchsatz, Festplattenspeicherkapazität und Input/Output sowie Betriebssystemdienste. Ein Engpass entsteht, wenn eine oder mehrere dieser Ressourcen knapp werden.

Anwendungen nutzen Ressourcen grundsätzlich zur Ausführung von Anweisungen. Einige Anwendungsdesigns stellen hohe Anforderungen an bestimmte Ressourcen. Eine Anwendung kann beispielsweise Speicher oder CPU für sich alleine nutzen und monopolisieren – und sich weigern, freigegebenen Speicher zurückzugeben. Oder sie kann übermäßig auf Festplatten zugreifen und diese blockieren. Solche Engpässe führen zu Konflikten zwischen Anwendungen, die Ressourcen gemeinsam nutzen, und verlangsamen die Softwareleistung.

Arten von Leistungstests

Angesichts der Vielzahl möglicher Software-Performance-Probleme werden die Qualitätssicherungsteams (Quality Assurance) bei der Bewertung bestimmter Merkmale mit verschiedene Leistungstests unterstützt. Die fünf wichtigsten Typen von Leistungstests sind: Last-, Stress-, Ausdauer-, Spike- und Abhängigkeitstests.

Lasttests. Lasttests für Anwendungen messen im Allgemeinen die Datenbewegung – auch Durchsatz genannt – bei einer bestimmten Anzahl gleichzeitiger Benutzer. Durch Lasttests kann überprüft werden, ob die Software unter typischen Bedingungen eine akzeptable Leistung erbringt.

Die inhaltliche Arbeit selbst ist bei diesen Tests normalerweise nicht relevant. Das Ziel von Lasttests ist es zu gewährleisten, dass wichtige Leistungskennzahlen, wie Datendurchsatz pro Sekunde oder Plattenzugriff pro Sekunde, akzeptabel bleiben, wenn mehrere Benutzer auf normale Weise mit der Software arbeiten. Beeinträchtigt die erforderliche Anzahl gleichzeitiger Benutzer die Leistungsmetriken erheblich, schlägt der Lasttest fehl. Die Entwickler können dann Probleme in nachfolgenden Builds beheben, zum Beispiel durch das Anpassen der Spezifikationen für den Lastausgleich.

Stresstests. Eine Variante des Lasttests ist der Stresstest. Ein Stresstest setzt die Software übermäßigen Lastbedingungen aus. Stresstests decken also Leistungsprobleme einer Software unter Bedingungen mit hohem Datenverkehr oder Datenverarbeitung auf. Bei einigen Stresstests werden die Lastbedingungen absichtlich so lange erhöht, bis die Software ausfällt. Wenn die Entwickler verstehen, wann und wie Software ausfällt, können sie ihre Zuverlässigkeit verbessern.

Ausdauer- oder Endurance-Tests. Ausdauertests sind im Wesentlichen Lasttests, die Fachleute in der Qualitätssicherung über einen längeren Zeitraum durchführen. Das Ziel von Ausdauertest – Englisch: Endurance-Tests oder auch Soak-Tests – besteht darin, zu verifizieren, dass sich die Leistungsmerkmale der Software im Laufe der Zeit nicht verändern. Ausdauertests erkennen Fehler wie beispielsweise ein Speicherproblem, das sich mit der Zeit vergrößert. Solche Probleme treten bei kurzfristigen Lasttests möglicherweise nicht auf.

Spike-Tests. Last-, Ausdauer- und Stresstests verwenden in der Regel relativ statische Bedingungen. Bei Software in der realen Welt treten jedoch häufig unregelmäßige und unvorhersehbare Änderungen der Nutzerlast auf. Spike-Tests simulieren diese plötzlichen Änderungen der Benutzerlast, um die Reaktion der Software zu messen.

Abhängigkeitstests. Software existiert selten allein. Sie ist auf die Interoperabilität mit anderen Anwendungen wie Middleware oder Backend-Anwendungen wie Datenbanken angewiesen. Ein schlechtes Abhängigkeitsmanagement kann die Leistung der Software beeinträchtigen.

Zum Beispiel kann eine gut konzipierte Unternehmensanwendung eine schlechte Leistung erbringen, wenn die integrierte Kundendatenbank von mehreren anderen Anwendungen stark belastet wird. Abhängigkeitstests evaluieren zwar immer noch die Leistung unter einer Last. Die Technik wendet diese Last jedoch auf die Abhängigkeiten an, nicht auf die Software. Zum Beispiel kann das Softwaretestteam verschiedene Datensätze und Volumes mit einer Datenbank verwenden und prüfen, wie die Anwendung, die sich auf diese Informationen stützt, funktioniert.

Voraussetzungen für Performance-Tests

Erfolgreiche Softwareleistungstests kommen nicht von ungefähr. Entwickler und Mitarbeiter in der Qualitätssicherung müssen sich vor der Bewertung der Software mit den Anforderungen an Leistungstests befassen.

Hier sind fünf Voraussetzungen für Performance-Tests:

• Bestimmen Sie einen relevanten Softwarekandidaten;
• Klären Sie die Leistungsziele;
• Erstellen Sie aussagekräftige Testfälle;
• Nutzen Sie geeignete Tools für Leistungstests; und
• Imitieren Sie die Produktivumgebung.

Bewerten Sie jede dieser Voraussetzungen für einen Performance-Test, um einen Ansatz zu entwickeln, der für ein bestimmtes Softwareprojekt funktioniert.

Bestimmen Sie einen relevanten Softwarekandidaten. Nicht jedes Softwareentwicklungsprojekt erfordert das gleiche Ausmaß an Tests. Entwickler sollten die Kandidaten für den Testing-Prozess sorgfältig auswählen, denn alle Tests erfordern Zeit und Mühe.

So benötigen nicht alle Anwendungen notwendigerweise Leistungstests. Lasttests auf einem geschäftskritischen Client/Server-System schützen das Unternehmen vor Risiken, aber die gleichen Tests auf einem weniger wichtigen System rechtfertigen möglicherweise nicht die Investition.

Ein Lasttest für eine Taschenrechner-App ist zum Beispiel wenig sinnvoll. Berücksichtigen Sie also die Anforderungen und Ziele eines Softwareprojekts und entscheiden Sie frühzeitig, ob Leistungstests angewendet werden sollen. Als allgemeine Regel gilt: Leistungstests sind dann erforderlich, wenn das Softwareprojekt bestimmte Leistungsspezifikationen erfüllen muss, wie zum Beispiel die Unterstützung einer Mindestanzahl potenzieller Benutzer.

Klären Sie die Leistungsziele. Legen Sie alle Ziele und Anforderungen für Leistungstests fest. Definieren Sie die Parameter für Leistungstests sowie die Akzeptanzkriterien für jeden einzelnen Parameter. Wenn Sie weder wissen, worauf Sie testen sollen, noch was das gewünschte Ergebnis sein soll, dann sind Leistungstests pure Zeitverschwendung.

Besteht das Ziel eines Projekts beispielsweise darin, eine Shopping-Website zu entwickeln, sind Leistungstests für die Ladezeiten der Seiten sinnvoll. Schließlich ist das Gewährleisten einer schnellen Reaktion der Website wichtig, damit potentielle Kunden zufrieden sind und nicht abwandern. Software-Stakeholder benötigen möglicherweise Ladezeiten unter einer halben Sekunde. Eine solche Metrik muss normalerweise durch Leistungstests validiert werden, bevor die Software ein akzeptabler Release-Kandidat ist.

Erstellen Sie aussagekräftige Testfälle. Leistungstests überprüfen Software im Betrieb. Daher sollten Sie die Voraussetzungen für die Ziele von Leistungstests schaffen. Hier sind einige gängige Beispiele für Testfälle:

• Verifizieren Sie, dass die Software eine Spitzenlast von 2.000 gleichzeitigen Benutzern ohne Fehlfunktion unterstützen kann.
• Die Antwortzeit der Software sollte bei einer Spitzenlast von 2.000 gleichzeitigen Benutzern vier Sekunden nicht überschreiten.
• Dokumentieren Sie die Antwortzeiten der Software unter niedriger, mittlerer und hoher Last.
• Halten Sie die Antwortzeit der Software innerhalb von zwei Sekunden, wenn die Netzwerkkonnektivität langsam ist.
• Führen Sie einen Stresstest der Software durch, um die Gesamtzahl der gleichzeitigen Benutzer − oder den Datenverkehr − zu ermitteln, bei dem die Software nicht mehr funktioniert.
• Dokumentieren Sie die Prozessorlast und die Speichernutzung der Software unter Spitzenlastbedingungen von 2.000 gleichzeitigen Benutzern.
• Bewerten Sie die Antwortzeit der Datenbank, wenn die Software 1.000 Datensätze gleichzeitig liest oder schreibt.

In der Praxis geben die Projektbeteiligten oder erfahrene Entwickler Zahlen vor, um vage Begriffe wie „erhebliche Benutzerlast“ oder „erwartete Last“ exakt zu quantifizieren.

Wählen Sie Leistungstest-Tools aus. Für Softwareleistungstests sind in der Regel ein oder mehrere verwandte Test-Tools oder -Suiten erforderlich. Solche Tools für Leistungstests bieten verschiedene Vorteile. Testteams verwenden Tools, um realistische Eingaben für die Software zu erstellen. Mit Unterstützung von Tools können Teams wichtige Kennzahlen für die Leistungsprüfung, wie zum Beispiel Prozessorlast und Speichernutzung, festlegen, verfolgen und melden.

Es gibt mittlerweile eine Unzahl von Leistungstest-Tools, darunter:

• HP LoadRunner
• NeoLoad
• WebLOAD
• Apache JMeter
• IBM Rational Performance Tester
• LoadNinja
• Silk Performer
• Gatling
• Flood

Imitieren Sie die Produktivumgebung. Um aussagekräftige Ergebnisse von Leistungstests zu erhalten, sollte das Qualitätssicherungsteam die Software in einer Testumgebung bewerten, die der Produktivumgebung so nahe wie möglich kommt.

Diese Umgebung umfasst Software, Hardwareressourcen und Netzwerkkonfigurationen. Wenn Sie beispielsweise eine Anwendung auf dem Laptop eines Entwicklers mit einer Wi-Fi-Netzwerkverbindung ausführen, funktioniert die Software möglicherweise anders als auf einem Server der Enterprise-Klasse mit 10-Gigabit-Ethernet-Konnektivität. Abhängigkeiten wirken sich auch auf die Genauigkeit von Leistungstests aus. Überprüfen Sie beispielsweise die Version des Server-Betriebssystems und der Datenbank. Dokumentieren Sie die Testbedingungen und Werkzeugkonfigurationen, damit Leistungstests wiederholbar und einfach zu validieren sind.

Metriken für Leistungstests

Was genau messen Performance-Tests? Es gibt unzählige Metriken für Performance-Tests – je nach Art und Komplexität der zu testenden Software.

Für allgemeine Leistungstests sollten Sie folgende Metriken berücksichtigen:

• Committed Memory (Zugesicherter Speicher). Die Menge oder der Prozentsatz des verwendeten virtuellen Speichers.
• Disk Queue Length (Länge der Festplatten-Warteschlange). Die Gesamtzahl der Lese-/Schreibanforderungen, die auf den Plattenzugriff warten. Eine größere Anzahl von Warteschlangen bedeutet, dass die Festplatte ausgelastet ist und ein Plattenfehler oder Softwareabsturz zu Datenverlust führen kann.
• Disk Utilization (Festplattenauslastung). Die Menge oder der Prozentsatz der Zeit, die eine Festplatte mit der Bearbeitung von Lese-/Schreibanforderungen verbringt; ein allgemeines Maß für die Plattenauslastung.
• Hit Ratios (Trefferquoten). Das Verhältnis der im Cache befindlichen Daten zu den Daten, die die Anwendung von der Festplatte anfordert. Eine hohe Trefferquote bedeutet, dass Daten häufig im Cache gefunden werden, was die Leistung verbessern kann. Eine niedrigere Trefferquote bedeutet, dass sich die Software mehr auf den Festplattenzugriff verlässt, der langsamer als der Cache-Zugriff ist und daher die Leistung verringert.
• Hits per Second (Treffer pro Sekunde). Die Anzahl der Anfragen, die pro Sekunde an einen Webserver gestellt werden. Eine höhere Zahl bedeutet mehr Datenverkehr und eine bessere Leistung.
• Interrupts per Second (Unterbrechungen pro Sekunde). Die Rate der Hardware-Interrupt-Anforderungen, die der Prozessor bearbeitet. Hohe Unterbrechungsraten wirken sich auf die Leistung aus, da der Prozessor ständig durch die Unterbrechungen abgelenkt wird.
• Memory Utilization (Speicherauslastung). Die Menge oder der Prozentsatz des Speichers, den Arbeitsprozesse beanspruchen oder sperren; ein allgemeines Maß für die Speicherlast.
• Network Queue Length (Länge der Netzwerkwarteschlange). Die Anzahl der Pakete, die darauf warten, an das Netzwerk gesendet zu werden. Eine größere Anzahl von Warteschlangen bedeutet, dass das Netzwerk – insbesondere die lokale Netzwerkschnittstelle – ausgelastet ist.
• Network Utilization (Netzwerkauslastung). Die Menge oder der Prozentsatz der verfügbaren Bandbreite der Netzwerkschnittstelle, die aktiv Daten austauscht (in Bytes pro Sekunde); ein allgemeines Maß für die Netzwerklast.
• Page Faults per Second (Seitenfehler pro Sekunde). Der Prozentsatz, mit dem angeforderte Daten nicht im Speicher gefunden werden, wodurch das System aufgefordert wird, nach den auf der Festplatte zwischengespeicherten Daten zu suchen.
• Pages per Second (Seiten pro Sekunde). Die Anzahl der Memory Pages, die auf der Festplatte zwischengespeichert oder von der Festplatte gelesen werden – dies erfolgt in der Regel, wenn der Speicher nicht ausreicht. Eine hohe Anzahl von Pages per Second bedeutet, dass die Software häufig nach Daten sucht, die nicht im Arbeitsspeicher zwischengespeichert sind – entweder aufgrund begrenzter Speicherressourcen oder aufgrund eines ineffizienten Software-Designs.
• Processor Utilization (Prozessorauslastung). Die Menge oder der Prozentsatz der Zeit, die der Prozessor mit der Arbeit an aktiven Threads oder Prozessen verbringt. Diese Metrik ist ein allgemeines Maß für die Prozessorauslastung.
• Response Time (Reaktionszeit). Die Latenz zwischen dem Empfang einer Anforderung durch die Software und dem Beginn ihrer Antwort. Kürzere Reaktionszeiten deuten auf eine bessere Leistung hin.
• Throughput (Durchsatz). Die Rate, mit der Softwareanfragen gestellt und abgeschlossen werden, normalerweise pro Sekunde. Niedrigere Durchsatzzahlen bedeuten eine schlechtere Leistung.

Die Testumgebung hat großen Einfluss auf die endgültigen Metriken für Leistungstests. Variabler Datenverkehr oder Datensätze können unterschiedliche Testergebnisse liefern. Wenn Sie beispielsweise Tests ausführen, die nur einfache Anforderungen an lokal zwischengespeicherte Daten stellen, sehen die Ergebnisse theoretisch gut aus. Diese Ergebnisse spiegeln allerdings nicht die Fähigkeiten der Software in der realen Welt wider, wodurch die Leistungstests praktisch unbrauchbar werden. Führen Sie deshalb eine Ergebnisanalyse durch, um sicherzustellen, dass Sie genaue und hilfreiche Daten erhalten.

Verfeinern Sie den Plan für Performance-Test

Die Erstellung von Leistungstests ist sowohl Kunst als auch Wissenschaft. Der eigentliche Prozess für Performance-Tests beruht auf einer Kombination von Techniken. Zum Beispiel verwenden Tester häufig Skripte und Aufzeichnungs- und Wiedergabe-Tools, um Benutzerverhalten wie Menüauswahl und Checkout zu simulieren. Bei diesen Methoden werden oft bereits vorhandene Datensätze abgerufen. Diese Daten können zum Beispiel Kopien von tatsächlichen Datenbanken aus dem Produktionssystem sein. Damit erhalten sie reale Testdaten für die Software, mit der sie arbeiten.

Leistungstests können auch mehrere Tools erfordern. Einige Tools sind auf bestimmte Aktivitäten von Performance-Tests spezialisiert, wie zum Beispiel die Skalierung von Netzwerklasten oder Skalierbarkeitstests.

Diese Techniken erfordern eine klare Strategie für Leistungstests. In der Praxis sind keine zwei Pläne für Leistungstests identisch. Der von einem Qualitätssicherungsteam gewählte Testplan oder die Testtechnik muss die Ziele dieses Testzyklus widerspiegeln.

Diese Leistungskriterien – das Design, Normal- und Spitzenlasten, Systemressourcen, Abhängigkeiten, Auslastungsmerkmale und Zeit – sind Voraussetzungen für Leistungstests und sollten Teil jeder Strategie sein.

Softwarearchitektur. Testentwickler müssen die Systeme, Schnittstellen, Module und andere Teile der Software verstehen. Es gibt viele Systemkomponenten und verschiedene Arten der Nutzung der Software. Legen Sie am besten einen Testbereich fest, um den Fokus einzugrenzen und die empfindlichsten oder wichtigsten Teile der Software zu untersuchen. Betrachten Sie das Testen von Schnittstellen als Beispiel. Eine Testrunde kann sich unter anderem auf Stresstests einer API konzentrieren, um die Fähigkeit der Software zu prüfen, Anfragen und Antworten zu Stoßzeiten zu verarbeiten.

Normal, Peak und Break. Ein wichtiger Teil der Leistungstests ist die Benutzerlast – egal ob normal, Spitzenlast oder Überlast. Übermäßiger Netzwerkverkehr, viele gleichzeitige Benutzer sowie viele Anfragen und Antworten tragen alle zur Auslastung bei. Um die normale Auslastung vorhandener Software zu bestimmen, nehmen Sie einen Durchschnitt aus einem bestimmten Betriebszeitraum, beispielsweise aus den letzten sechs Monaten. Die Spitzenlast kann aus der höchsten Nutzung abgeleitet werden, die das Team im letzten Jahr aufgezeichnet hat. Und eine Überlast sollte typische Nutzungsmuster darstellen, jedoch bei einem Volumen, das die Leistung beeinträchtigt.

Hosting-Ressourcen. Die Tester müssen über ein umfassendes Verständnis der zugrunde liegenden Systemhardware und des Netzwerks verfügen. Das Betriebssystem, die Serverressourcen, die Netzwerkkomponenten und andere Elemente der Infrastruktur wirken sich auf die Leistung aus. Wenn die Software beispielsweise Funktionen des Betriebssystems benötigt, die nicht vorhanden sind, oder wenn eine inkompatible Version im Betriebssystem der Testplattform vorhanden ist, kann die Software eine schlechte oder gar keine Leistung erbringen. Sie sollten also die zugrunde liegende Umgebung verstehen, um sicherzustellen, dass alle Softwareanforderungen und -abhängigkeiten vorhanden sind.

Dependency Requirements (Abhängigkeitsanforderungen). Software der Enterprise-Klasse erfordert Zugang zu Middleware und Backend-Prozessen. Pläne für Leistungstests sollten alle Abhängigkeiten berücksichtigen und auch die Verzögerungen oder Latenzen, die diese Prozesse bei Normal- und Spitzenbelastungen verursachen. Wenn die Software zum Beispiel auf eine Datenbankanwendung zugreift, können Leistungstests eine einzige Messung umfassen, um die tatsächliche Antwortzeit der Datenbank im Vergleich zur Gesamtantwortzeit der Software auf die Abfrage zu messen. Diese Messung ermöglicht es den Testern, Probleme des Softwarecodes oder der Ressourcen von Abhängigkeitsproblemen zu unterscheiden.

Workload Composition (Zusammensetzung der Arbeitslast). Software führt eine Vielzahl von Funktionen aus, aber sie führt die Funktionen in der Regel nicht alle auf einmal oder nicht die ganze Zeit aus. Entwerfen Sie Tests, die die Arbeitslast jeder Softwarefunktion widerspiegeln.

Wenn das Team beispielsweise erwartet, dass die zu testende Software fünf Prozent ihrer aktiven Zeit mit der Bearbeitung von Anmeldungen und Benutzerauthentifizierung benötigt, 50 Prozent mit der Verarbeitung von Datensätzen, zehn Prozent mit der Erstellung von Berichten, 20 Prozent mit der Durchführung von Suchvorgängen und 15 Prozent mit anderen Aktivitäten, dann sollten die Tests diese Arbeitsverteilung widerspiegeln. Geben Sie sich die größte Mühe, um die Leistung von Aufgaben mit hoher Nutzung zu testen.

Time Available (Verfügbare Zeit). Die Komplexität, die Art und der Umfang von Leistungstests wirken sich dramatisch auf die für die Aufgabe aufgewendete Zeit aus. Einige Leistungstests erfordern mehr Zeit als andere. Beispielsweise dauert die Prüfung auf CPU-Engpässe bei Normal- und Spitzenlasten nur wenige Minuten. Dauertests hingegen können Tage in Anspruch nehmen. Die Testzeit wirkt sich auf Entwicklungspläne und Iterationszyklen aus.