Web Service Test: Testmethoden
Wie im Artikel über den Systemtest beschrieben, können die qualitativen Eigenschaften mittels Systemtests einer Prüfung unterzogen werden. Für diese Systemtests existieren eine Vielzahl von unterschiedlich automatisierbaren Testmethoden. Im Folgenden wird auf einzelne Testmethoden, die eine Automatisierung erlauben, eingegangen.
Smoke Test
Der Smoke Test wird geprüft, ob die Applikation bereit ist getestet zu werden. Wird bei einem Smoke Test versucht, ein Web Service anzusprechen, der auf die Ansprache nicht reagiert, sind weiterführende Systemtests an dem System under Test (SUT) nicht von Interesse. Vielmehr muss geprüft werden, ob der Web Service dem Tester zur Verfügung steht. Erst wenn der Smoke Test erfolgreich durchlaufen wurde, ist eine weitere Untersuchung des SUT angebracht. [PRE00] (S. 480)
Funktionaler Systemtest
Ziel des funktionalen Systemtest ist es, wie im Abschnitt: Funktionaler Systemtest beschrieben, das SUT auf dessen Korrektheit und Vollständigkeit zu prüfen. Dazu werden alle zu implementierenden Eigenschaften des Web Services meist über JUnit Tests angesprochen und geprüft, ob die Ergebnisse den Sollwerten entsprechen. Existiert keine Übereinstimmung zwischen den Ergebnisse und den Sollwerten, gilt der Test als fehlgeschlagen und der Web Service als nicht korrekt bzw. nicht vollständig. Die implementierte Testlogik des funktionalen Systemtest kann für die Regressionstests direkt übernommen werden. vgl. [LIG00] (S. 94), [BAL98] (S. 537, 538)
Regressionstest
Nach jeder Änderung in der Implementierung eines Web Services muss ein Regressionstest durchgeführt werden. Dieser hat die Aufgabe zu prüfen, ob die Funktionalität des Web Services durch die Änderung nicht negativ Beeinflusst wurde. So kann es durchaus möglich sein, dass Änderung an Komponenten, die vom Web Service nur indirekt verwendet werden, dessen Funktionalität erheblich beeinträchtigen. Regressionstests können mittels des JUnit Frameworks, vergleiche Kapitel 2.4.3, implementiert bzw. automatisiert ausgeführt werden. vgl. [PRE00] (S. 478-479)
Lasttest
Der Lasttest beinhaltet sämtliche Arten von Tests, die das System über eine längere Zeit mit Nutzlast ansprechen. Ziel ist es, die Zuverlässigkeit des SUT zu prüfen. Der Lasttest kann zusätzlich verwendet werden, um die Robustheit des Web Services einer Prüfung zu unterziehen. Dazu werden die Nutzdaten mit fehlerhaften Eingabedaten angereichert. vgl. [ALM01] (S. 291), [BAL98] (S. 539)
- Der Massentest definiert sich als Lasttest mit dem Fokus auf die zu verarbeitenden Datenmengen unter Nutzlast. Der zu testende Web Service wird bei diesem Test darauf geprüft, welche Datenmenge er unter Nutzlast verarbeiten kann. vgl. [BAL98] (S. 539)
- Bei dem Zeittest ist die Antwortzeit des SUT unter Nutzlast von Interesse. Dabei wird festgehalten, mit welcher Antwortzeit der Web Service auf eine Anfrage reagiert. Der Web Service sollte bei einem linearen Wachstum der Anfragen nicht mit einem linearen bis exponentiellen Anwachsen der Antwortzeit reagieren. vgl. [BAL98] (S. 539), [LIG00] (S. 95)
Stresstest
Das Verhalten eines SUT unter Überlast wird mittels des Stresstests einer Analyse unterzogen. Über eine Analyse der erhaltenen Testergebnisse, wie bspw. Antwortzeit, kann auf die Zuverlässigkeit und Stabilität des SUT geschlossen werden. Es wird hierbei dem Leitspruch gefolgt: "Wie weit können wir gehen, bis das System versagt". vgl. [PRE00] (S. 484), [BAL98] (S. 540), [ALM01] (S. 291), [LIG00] (S. 96)
Spike Test
Der Spike Test ist eine Kombination der Testmethoden Last- und Stresstest. Bei diesem wird der Web Service für eine kurze Periode mit einer Last angesprochen, die weit über der im Durchschnitt zu erwartenden Nutzlast liegt. Ziel ist es, die im Internet auftretenden Lastspitzen zu simulieren. Dadurch wird geprüft, ob der Web Service nach einer Spitze (Spike) wieder in das ursprüngliche Antwortverhalten zurückkehrt. vgl. [ALM01] (S. 291)
Sicherheitstest
Darunter kann ein gezielter Einbruch in das SUT durch extreme und einseitige Überlastung verstanden werden. Die Suche nach Schwachstellen in der Implementierung bzw. der Konfiguration wird hierbei von einem Sicherheitsbeauftragten durchgeführt. Alle sicherheitstechnischen Aspekte des Web Services und der Architektur werden von dem Beauftragten geprüft. Eine Automatisierung ist nur bedingt möglich. So kann beispielsweise eine extreme und einseitige Überlastung des Web Services über einen direkt auf den fehlerhaften Web Service spezialisierten Stresstest realisiert werden. vgl. [PRE00] (S. 484)
Referenzen
[PRE00] Pressman, Roger S: Software Engineering a Practitioner's Approach, Fifth Edition, McGraw-Hill Publishing Company, Maidenhead, 2000
[LIG00] Liggesmeyer, Peter: Qualitätssicherung softwareintensiver technischer Systeme, Spektrum Akad. Verlag, Heidelberg, Berlin, 2000, ISBN 3-8274-1085-1
[BAL98] Balzert, Helmut: Lehrbuch der Software-Technik : Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung, Spek-trum Akad. Verlag, Heidelberg, Berlin, 1998
[ALM01] Almeida, Virgilio A. F.; Menascé, Daniel A.: Capacity Planning for Web Services Metrics, Models, and Methods, Prentice Hall, o. O., 2001