Die 10 Gebote des Lasttest

Hier noch ein etwas älterer Text von mir, der aber noch immer seine Gültigkeit hat. Er ist eine schöne Grundlage für das Thema Last- und Performancetest. Es sind unsere 10 Gebote des Lasttestens. Diese sollten freilich nicht mit religösem Eifer betrachtet werden, aber sie sind ein guter Anhaltspunkt um sich selbst zu überprüfen.

1. Du sollst wissen, wie Dein Testtool funktioniert.

https://performanceblog.org/?p=91

2. Du sollst verstehen, wie das System in der Realität benutzt wird.

http://performanceblog.org/?p=97

3. Du sollst testbare Anforderungen haben.

http://performanceblog.org/?p=105

4. Du sollst einen Testplan ( Konzept ) schreiben.

https://performanceblog.org/?p=110

5. Du sollst gegen den „ worst case“ testen.

Teste nicht mit den Transaktionsraten eines durchschnittlichen Tages. Teste gegen den schlimmsten Tag, den es jemals
gab bzw. den schlimmsten Tag, der realistisch anzunehmen ist. Verwende SiS um das Risiko abzuschätzen, und/oder
füge noch einen Sicherheitsaufschlag dazu.
Den Failover testen? Ein Server fällt nicht um Mitternacht aus, wenn keiner die Anwendung verwendet ( Würde uns das
überhaupt interessieren? ). Ein Server fällt mitten am Tag aus, wenn viele reale Leute Ihn verwenden.

6. Du sollst Deine Testumgebung und Infrastruktur monitoren.

Es musste einmal geschrieben werden, denn es gibt immer noch genug Menschen, die dies nicht tun. Mit den Monitoring
Daten von den getesteten System ist es nicht nur viel einfacher herauszufinden, was das Problem des getesteten Systems
ist, manchmal ist es ohne sie gar nicht möglich. So kannst Du auch so hübsche Beobachtungen machen wie: „ Die
Antwortzeiten der neuen Version sind gleich geblieben, aber der CPU-Verbrauch am Application- Server ist um 10%
gestiegen.” Und wenn ich sage: “ Monitore Dein Testsystem” , dann schließt das Deine Lastgeneratoren natürlich ein.

7. Du sollst auf kontrollierten Umgebungen testen.

Das Endsystem, dass Du testest, sollte das sein, das produktiv eingesetzt werden soll. Gleiche Software, gleiche Version,
gleiche Konfiguration. ( Produktionsäquivalentes Testsystem) . Es passiert schnell, dass man den Überblick verliert,
wogegen man testet, wenn ständig irgendwelche Leute unkontrollierte Änderungen an der Testumgebung vornehmen.
Oder auch wenn Leute Tuning-Maßnahmen durchführen, ohne dabei festzuhalten, was sie da ändern. Führe immer eine
Liste mit vorgenommenen Änderungen, auch wenn Du unter Zeitdruck stehst. Und vor allen Dingen stelle immer sicher,
dass Du weißt, wogegen Du testest.

8. Du sollst die Fehler dokumentieren.

Ein nicht dokumentierter Fehler ist ein wenig wie ein Baum, der im dichten Wald umfällt. Niemand interessiert sich für ihn.
Einen Fehler zu dokumentieren und auf die im Projekt übliche Weise zu „ publizieren “ ( Bug Tracking Tool, XLS Sheet,
E-Mail, etc.) lässt jeden wissen, dass hier ein Problem ist. Es ergibt auch ein hübsches Repository um nach zu verfolgen,
was getan wurde, um den Fehler zu beseitigen.

9. Du sollst einen Fehler zuerst bei Dir selbst suchen, bevor Du ihn eskalierst.

“ Oops, mein Fehler!” ist ein hervorragender Weg, den Respekt der Leute zu verspielen, die die Fehler beseitigen sollen.
Wenn man Dich nicht respektiert, dann wirst Du viel härter davon überzeugen müssen, dass das Problem, dass Du siehst
ein Systemfehler ist, und kein Fehler in Deinem Skript. Habe aber auch nicht so viel Angst davor einen Fehler zu machen,
daß Du um die Systemfehler „herum testest“ ( So wie Leute, die einen HTTP500 Fehler unter Last sehen, und diesen
„ beseitigen “, indem Sie weniger Last auf das System geben. ) Es ist immer hilfreich, wenn Du das Gebot Nummer 1
befolgt hast: Du sollst wissen, wie Dein Testtool funktioniert.

10. Du sollst Dein Wissen weitergeben.

Schreibe einen Test-Report. Damit meine ich nicht, exportiere einen Web-Report aus dem Loadrunner oder Silk
Performer. Lasse das Management/den Kunden wissen, was Du gefunden (und gefixt ) hast. Tue das so, dass das
Management/der Kunde es versteht. Erstelle ein paar Powerpoint-Slides und veranstalte ein Meeting. Lasse die
Produktionsmonitoring Gruppe wissen, welche Metriken Du verwendet hast, und welche sinnvoll zu monitoren sind. Lasse
sie Deine Scripte wiederverwenden für das End To End Monitoring. Hinterlasse auch etwas Dokumentation für künftige
Tester: Lasse Sie nicht wieder die Anforderungen und Transaktionsraten zusammensuchen. Helfe Ihnen, Deine Skripte zu
verstehen, dass sie sie nicht aus Unwissenheit neu machen. Behalte Deine Testergebnisse so lange, bis Du absolut
sicher bist, dass niemand jemals wieder danach fragen wird.

Diese „Gebote“ sind mehr wie Faustregeln zu verstehen. Ich denke wir werden in zukunft auch nochmal genauer auf die einzelnen Gebote und ihre Bedeutung in der Praxis eingehen.

1 Gedanke zu “Die 10 Gebote des Lasttest”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.