Bedeutet ein nötiger “Performance”-Test auch immer einen nötigen “Last”-Test?
Kurz vorweg, die Antwort lautet: „Nein, bedeutet es nicht.“
Dies mag den einen oder anderen Leser zunächst verwundern, da man bei Performancetests meist auch an viele konkurrierende User denkt. Es kann sich bei der Analyse aber herausstellen, dass die “konkurrierende Last” aus folgenden Gründen eine untergeordnete Rolle spielt:
- Wenn es kaum konkurrierende Nutzer gibt und nur einen kleinen Nutzerkreis.
- Wenn es keine Risiken durch schlechte Performance unter „Last“ gibt.
- Wenn „Last“ aus einem anderen individuellen Grund gar nicht im Test einfließen braucht.
- Wenn eine immense Sicherheit in Architektur und Produkt vorliegt, dass ein Risiko für schlechtes Lastverhalten von allen beteiligten ausgeschlossen wird.
Neben konkurrierender Lasttest und Stresstest Messung, ist auch Single-Performance relevant
Lasttest und Performancetests drehen sich ja nicht immer um Webseiten oder um andere Testapplikationen, die stark konkurrierend bedient werden. Es kann auch sein, dass diese Performance unter „Last“ zwar wichtig ist, aber nebenbei auch die “Single Instance Performance” wichtig ist. Beispielsweise falls der „Last“-Test auf Protokoll/Schnittstellen-Ebene stattfindet, kann zusätzlich diese „Single Instance Performance“ inklusive GUI-Client-Performance sehr interessant und gegebenenfalls sogar ausschlaggebend sein. Sprich, auch die Rendering Time (Darstellung) kann sehr wichtig sein.
Diese „Single Instance Performance“ Messung ist möglich, wenn nur wenige Anwender auf ein System zugreifen und nicht die parallele Last im Vordergrund steht. Im den ISTQB Lehrplänen und Begriffsdefinitionen ist der Performancetest somit auch korrekt als Oberbegriff betitelt. “Last”-Tests sind nur eine Kategorie davon.
Testapplikationen bei denen Single-Instance-Performance sehr wichtig ist
Es gibt auch Produkte (oder Prozesse, Services, Projekte) mit sehr wenigen konkurrierenden Anwendern und trotzdem sehr langen Antwortzeiten bei einzelnen Transaktionen, wie beispielsweise das Reporting und Business Intelligence. Dabei steht die Einzel-Performance stark im Vordergrund. Dies gilt auch, falls die Performance nicht abhängig vom Client ist, sondern hier die einzelne Transaktionszeit im Server-Host bzw. speziell in der Datenbank entscheidend ist. Das ist der Fall, wenn die Antwortzeiten eher von einzelnen Anfragen abhängt, welche auch ohne parallele Last eine Antwortzeit von vielen Stunden mit sich ziehen kann. Lasttests, Stresstests und Lastverhalten stehen hier also nicht unbedingt im Vordergrund der Performancetests.
Schlechte Performance auf Client-Seite, hohe Rendering Time
Auch macht ein Abgleich Sinn, ob die End-to-End Antwortzeit einer Applikation die größte Wartezeit auf Clientseite oder Serverseite hat. Sieht man, dass nach erhalten der Daten noch mehr Zeit mit der Verarbeitung der Daten in der Client-Seite verbraucht wird, wird schnell klar, wo in diesem Fall ggf. bessere Ansätze sind die Performance zu optimieren. Besonders in dynamischem Web 2.0 RIA wird die Client-Performance gegenüber traditionellen Webseiten immer wichtiger. Hier kann sein, dass bei schlechter Performance gar nicht die „Last“ Schuld ist, sondern schon die „Single Performance“ hinter den Erwartungen liegt. Denn dann wird es unter „Last“ sicher nicht besser.
