Letztes Mal habe ich über die Bedeutung von repräsentativen Leistungstests gebloggt. Produktionsähnliche Eigenschaften für Hardware, Betriebssystem, JVM, App-Server, Datenbank, externe Systeme und simulierte Benutzerlast sind unerlässlich, um böse Leistungsüberraschungen bei der Inbetriebnahme zu vermeiden. Darüber hinaus habe ich beschrieben, wie Cloud Computing genutzt werden kann, um bei Bedarf hohe Lasten zu erzeugen, ohne sich um die Infrastruktur kümmern zu müssen. Kontinuierliche Leistungstests Mit einem repräsentativen Test als einem der letzten Schritte vor der Live-Schaltung verhindern wir, dass in der Produktion teure Überraschungen mit schlechter Leistung auftauchen. Allerdings werden die gleichen Überraschungen auftreten, nur früher und mit weniger Auswirkungen. Um Kosten zu sparen und umfangreiche architektonische Überarbeitungen zu vermeiden, ist es wichtig, so früh wie möglich auf Leistung zu testen. Das ist wie bei allen anderen Softwarefehlern und der Qualitätssicherung: Je später im Entwicklungsprozess Fehler entdeckt werden, desto kostspieliger sind diese Fehler. Bei einem beliebten Webshop stand ich vor folgender Herausforderung: schrieben wir die Leistungstests erst am Ende der sechswöchigen Release-Periode, nachdem die funktionalen Tests stattgefunden hatten und die funktionalen Fehler behoben waren. Wenn schwerwiegende Leistungsmängel auftauchten, wurde ein Krisenstab einberufen und wir befanden uns in einer stressigen Situation. In der Regel reichte die Zeit nicht aus, um den Fehler vor dem Veröffentlichungsdatum zu beheben, so dass ich manchmal empfahl, das Veröffentlichungsdatum zu verschieben. Allerdings war eine Verschiebung des Erscheinungstermins oft nicht möglich, weil Fernseh- oder Radiozeit gekauft wurde, um die neue Funktionalität zu bewerben. Wie konnte man dieses Dilemma also lösen? Wir fanden die Lösung in der Anwendung agiler Prinzipien: Testen Sie die Funktionen so früh wie möglich, und das Team ist dafür verantwortlich. Wir haben die Erfüllung der Leistungsanforderungen in die Definition von "done" in jeder neuen oder geänderten Funktion einzeln aufgenommen. Der Entwicklungsprozess beinhaltete bereits ein automatisches Build, wie es heutzutage üblich ist. Unit-Tests für eine Funktion wurden wie üblich vom Entwickler geschrieben. Wir haben nun Leistungstests in das Spektrum aufgenommen: Der Entwickler schreibt das Leistungstestskript für sein Feature (Dienst oder Webseite) in JMeter, Seite an Seite mit seinen Unit-Tests für die Klassen. Nach dem nächtlichen Build mit Maven wird die Anwendung auf WebSphere bereitgestellt und die Leistungstests werden von dem JMeter Ant-Skript ausgeführt. Dieses Skript erstellt einen Bericht, der per E-Mail an die Beteiligten gesendet wird. Auf diese Weise erhält die IT-Abteilung frühzeitig Einblick in neue und geänderte Funktionen, sie kann ihren Kurs schneller anpassen, sich frühzeitig von einer unglücklichen Architektur oder einem unglücklichen Ansatz abwenden, Überraschungen minimieren und auch die Kosten senken. Ein weiterer Vorteil ist, dass das Schreiben von Testskripten schneller vonstatten geht als früher, weil der Entwickler alle Details der neuen Funktion noch frisch im Gedächtnis hat. Diese Details sind zum Beispiel die Bedingungen, unter denen der Dienst aufgerufen werden kann und mit welchen Parametern, in welchen Variationen und Sonderfällen. Der übliche Kommunikationsaufwand zwischen einem Performance-Tester und einem Entwickler über diese Details wird drastisch reduziert, was die Produktivität weiter steigert. Kontinuierliches Performance-Testen wird meiner Meinung nach zu oft unterschätzt und nicht anerkannt, dabei hat es wirklich eine ganze Reihe von Vorteilen und ist gar nicht so schwer zu erreichen. Das nächste Mal werde ich über Schritt 5 bloggen : Überwachung und Diagnose.
Verfasst von
Jeroen Borgers
Unsere Ideen
Weitere Blogs
Contact