Web Service Test: Mögliche Ergebnistypen
Für die Bewertung der Misserfolge eines Systemtests stehen eine Vielzahl von Ergebnistypen zur Verfügung. Sie dienen der Klassifizierung des Fehlverhaltens eines Web Services. Diese ermöglicht es, vordefinierte Maßnahmen zu ergreifen und dadurch den Testprozess zu beschleunigen. Entsprechend der im Artikel Web Service Test: Testmethoden beschriebenen Aktivitäten muss der nicht funktionale Systemtest nach der Umsetzung der Maßnahmen erneut durchgeführt werden. Im Folgenden wird auf die häufigsten Ergebnistypen eingegangen.
Systemabsturz
Grundsätzlich kann davon ausgegangen werden, dass ein Systemabsturz direkt mit dem Testdurchlauf in Korrelation steht. Diese Annahme ist aber nur begründet, wenn ein Hardwareausfall über redundante Mechanismen, wie beispielsweise eine Clusterarchitektur, ausgeschlossen werden kann. Ferner muss ausgeschlossen sein, dass durch eine Fehlkonfiguration Systemgrenzen überschritten wurden. vgl. [KRE03] (S. 18)
Über eine Auswertung der Protokollierungsdateien des System under Test (SUT) und der Aufzeichnung des Verlaufs der Systemleistung ist es möglich, festzustellen, ob das SUT aufgrund einer mangelnden Skalierfähigkeit oder einer Fehlkonfiguration der Java Virtual Machine (JVM) mit einem Totalausfall reagierte. Bei einer mangelnden Skalierfähigkeit muss eine Überarbeitung der Architektur des SUT durchgeführt werden. Ist das Fehlverhalten durch die Konfiguration der JVM begründet, muss die Konfiguration optimiert werden.
Durchsatzbegrenzung
Eine Durchsatzbegrenzung kann einer Vielzahl von Gründen zugeordnet werden. Viele kommerzielle Server Hersteller begrenzen ihre Software für den Entwickler auf maximal eine aktive Clientverbindung. Wird ein Performanztest gegen ein derartiges System durchgeführt, steigt die Antwortzeit ab einem bestimmten Punkt stark an. Eine softwaremäßige Durchsatzbegrenzung kann auch darin begründet sein, dass das Betriebssystem dem Serverprozess maximal 33% der Prozessorzeit bereithält. In beiden Fällen muss die Serversoftware ersetzt bzw. das Betriebssystem konfiguriert werden.
Ist die Durchsatzbegrenzung in den Web Services begründet, bedürfen diese einer intensiveren Überarbeitung. Dazu muss die Implementierung über Debugging-Mechanismen bezogen auf eine Durchsatzbegrenzung analysiert werden. Wird durch die Analyse der Protokollierungsdateien eine netzwerkbasierte Durchsatzbegrenzung festgestellt, ist es notwendig, die Netzwerkarchitektur bzw. die Internetanbindung den Erfordernissen anzupassen. vgl. [KRE03] (S. 20)
Lastverteilung
Ein Misserfolg des nicht funktionalen Systemtests kann auch darin begründet sein, dass eine Lastverteilung zu einem übermäßigen Verwaltungsaufwand führt. Bei Implementierungen der Geschäftslogik, muss der Zustand auf jedem Knoten des Verbundes gleich sein. Bei der Ansprache mehrerer Web Services auf unterschiedlichen Knoten kann dies dazuführen, dass sich die Knoten zunächst untereinander abgleichen. Dies führt zu einem progressiven Wachstum der Kommunikation der einzelnen Knoten untereinander und einer Verlangsamung der Anfragenverarbeitung. Ist dies der Fall, muss die Lastverteilung eingeschränkt bzw. unterbunden oder der Abgleich aufgebrochen werden. vgl. [KRE03] (S. 24)
Langsame Hardware
Langsame Hardware ist tendenziell eher unwahrscheinlich. Wird dies bei der Misserfolganalyse festgestellt, können einzelne Teile der Hardware durch leistungsfähigere Komponenten bzw. die Hardware als Ganzes ersetzt werden. Zusätzlich können Protokollierungsmechanismen deaktiviert und rechenintensive Programmteile überarbeitet werden. vgl. [KRE03] (S. 26)
Überbeanspruchung
Die mangelnde Skalierbarkeit des SUT ist der Hauptgrund einer Überbeanspruchung. In diesem Fall ist eine Änderung in der Architektur des SUT notwendig. Eine exklusive Nutzung des SUT ist für die Testdurchführung sicherzustellen, so darf ein Zugriff nur den für den nicht funktionalen Systemtest benötigten Komponenten gestattet sein. vgl. [KRE03] (S. 28)
Langsames Drittsystem
Bei diesem Ergebnistyp ist das Problem nicht in dem eigenen SUT, sondern bei einem Dienst, welcher nicht im eigenen Einflussbereich liegt, begründet. Ein Dienst kann in diesem Fall ein Web Service oder eine Datenbank darstellen. Um dies zu prüfen, muss festgestellt werden, mit welcher Last das eigene SUT den Dienst anspricht. Ein Lasttest, der den betreffenden Dienst mit der ermittelten Last anspricht, überprüft, ob diese Last ein Fehlverhalten zum Resultat hat. Wird ein Fehlverhalten festgestellt, muss der betreffende Dienst ersetzt werden. vgl. [KRE03] (S. 30)
Referenzen
[KRE03]: Kreider, Martin: Vorlesung 10: Performance- und Stresstestverfahren, o.O., 2003, http://www.aifb.uni-karlsruhe.de/Lehre/Winter2003-04/STQM/STQM-VL10-PerformanceStresstest-Verfahren_v1.06.pdf, Abfragedatum 22.02.2004