Sie sind hier: Startseite » Kapitel 5 - Projekt Campus Management » Testphase I I - Vorbereitung, Durchführung und Auswertung

5 Projekt Campus Management

5.7 Testphase II

Da die Aussagen der vorangegangenen Tests, aufgrund der stark eingeschränkten Zeit für die Performancetests, nicht zufrieden stellend waren, wurden weitere Tests im Qualitätssicherungs-system geplant. Es sollten erneut Stress- und Lasttests durchgeführt werden, um die Probleme aus der Testphase I zu klären und um durch eine komplette Bottleneck-Analyse, Fehlerquellen zu identifizieren und zu beseitigen.

Da das Qualitätssicherungssystem dem Produktivsystem nur ähnlich ist, werden die ersten Tests dazu dienen, Parallelen zu den vorangegangenen Tests im Produktivsystem zu ermitteln, um eventuell Auswirkungen der unterschiedlichen Systemarchitektur zu identifizieren. Für diese Zwecke soll die Anwendung (der SAP-Testmandant) aus dem Produktivsystem ins Qualitätssicherungssystem übertragen werden. Damit wird garantiert, dass die gleichen Testszenarios mit den gleichen Testdaten und die gleiche Version der Anwendung für die folgenden Tests benutzt werden, damit nur die Unterschiede in der Architektur sichtbar werden.

Nach diesen Tests werden Tests durchgeführt, die durch ihre Struktur und Durchführung einzelne Bereiche der Systemlandschaft extrahieren und es dadurch ermöglichen, Aussagen über einzelne Komponenten (Server) zu treffen, um Engpässe zu erkennen.

Dazu werden erneut Testhierarchien aufgebaut, wobei sich in der ersten Phase auf die Systemlandschaft - hier geben verschiedene Netzwerkeinstiegspunkte die lokale Hierarchie vor - beschränkt wird. Dadurch werden Komponenten des Netzwerkes extrahiert und ist möglich durch Vergleich der Testergebnisse, Rückschlüsse zuziehen, welche Netzkomponenten möglicherweise zu den schlechten Ergebnisse führen.

Die zweite Phase extrahiert auf Anwendungsebene einzelne Komponenten des Netzwerkes. Dies wird durch den Aufbau einer Hierarchie bezüglich der qualitativen Unterschiede erreicht. Zum Beispiel wird das Schreiben der Anwendungsdaten in die Datenbank durch nicht Bestätigen der Modulbuchung unterbunden.

5.7.1 Planung der Performancetests

Für die Tests der zweiten Phase muss das Qualitätssicherungssystem für die Last- und Performancetests aufgebaut werden. Die entscheidenden Schritte werden im nächsten Abschnitt aufgeführt. Da die Anwendung seit der Testphase I weiterentwickelt wurde, müssen auch die gesamten Testfälle an die neue Struktur des Webinterfaces angepasst werden.

5.7.2 Vorbereitung

Vorbereitungsschritte, die für die Testphase II durchgeführt werden müssen:

Das Testsystem auf der Qualitätssicherungsumgebung muss zur Verfügung stehen. Dazu muss der Testmandant aus dem Produktivsystem im Qualitätssicherungssystem zur Verfügung stehen und von den definierten Netzwerkeinstiegspunkten erreichbar sein.
Die Teststudenten müssen angelegt sein und auch die entsprechenden Authentifizierungsmechanismen für das Qualitätssicherungssystem müssen konfiguriert sein.
Die Testdaten und die Anwendungen dürfen sich während der Testphase II nicht ändern.
Die Testumgebungen an den definierten Netzwerkeinstiegspunkten müssen eingerichtet sein. Dazu sind mindestens 10 PCs, auf denen die Loadgeneratoren arbeiten, notwendig und müssen während der Testdurchführung nutzbar sein.
Ein PC (mindestens 1GB RAM und 10 GB HD) wird als Steuerungsinstanz für das Lasttesttool Neoload benötigt. Beziehungsweise muss ein solcher PC zur Vorbereitung und nicht notwendigerweise der selbe zur Durchführung der Tests vorhanden sein.
Das Lasttesttool Neoload muss ebenfalls für die Vorbereitungszeit vorhanden sein.
Das Lasttesttool Neoload von der Firma Neotys muss mindestens noch für eine weitere Woche gemietet werden.
Das Qualitätssicherungssystem muss auch von den Testumgebungen aus erreichbar sein, die außerhalb des FU-Netzes ( ebenfalls ein Netzwerkeinstiegspunkt ) liegen. Die benötigten Sicherheitseinstellungen müssen konfiguriert werden.
Es sollte möglich sein auf die Log-Dateien und Server der Architektur zu schauen. Dazu sind die entsprechenden Berechtigungen zu vergeben.

5.7.3 Ablaufplanung

Nach Erfüllung der unter Vorbereitung definierten Punkte werden folgende Tests durchgeführt:

Alle folgenden Punkte werden an den definierten Netzeinstiegspunkten einzeln, aber auch korreliert ausgeführt. Bei korrelierter Ausführung der Tests werden die Nutzerzahlen auf die beteiligten Netzeinstiegspunkte aufgeteilt.

5.7.3.1 Ermittlung des Rauschwertes

72 Stunden Test zur Ermittlung eines Rauschwertes. Es wurde ein Testszenario erzeugt, dass ein gleichmäßiger Mix aus den Teststudenten war und einem kompletten Anmeldeprozess der Webschnittstelle mit anschließendem Rücksetzen entsprach. Dieses Testszenario erzeugt eine sehr geringe Last auf dem System. Es wird alle 10 min. für jeweils 2 min. eine Last von 10 parallelen Nutzern simuliert, die alle 3 Sekunden eine neue Anfrage abschicken.

5.7.3.2 Ermittlung der Referenzdaten

Es werden jede Stunde kurze Testläufe gestartet. Es wird für die 12 verschiedenen Teststudenten jeweils eine Iteration des Testszenarios mit Buchung und Rücksetzen ausgeführt. Diese Daten werden in einer SQL-Datenbank gespeichert. Nach einer Woche, wird das Mittel der Antwortzeiten jeder Seite berechnet und somit der Referenzwert definiert.

5.7.3.3 Stresstest

Der erste Stresstest wird der Ausgangstest der Testphase I sein. Für ihn wurde angesetzt, dass das identische Testszenario, das auch für den Referenztest verwendet wurde, dazu benutzt wird, die parallele Nutzerzahl von 100 auf bis zu 1000 zu steigern. Dazu werden alle 30 min. die parallelen Nutzer um 100 erhöht.

Bei erfolgreicher Durchführung des Tests mit bis zu 1000 parallelen Nutzern, wird beim nachfolgenden Stresstest bei 1000 parallelen Nutzern gestartet und die Anzahl der Nutzer wird stetig (alle 10 min.) um weitere 1000 Nutzer erhöht. Als Abbruchbedingungen werden das Erreichen der parallelen Nutzerzahl von 15000 bei Einhaltung der definierten Antwortzeiten sowie eine Fehlerquote von über 10% oder ein Überschreiten der geforderten Antwortzeiten von 100% über den erwarteten Antwortzeiten gewählt. Als erwartete Antwortzeiten wird die Referenzzeit multipliziert mit dem Akzeptanzfaktor gesetzt, welcher abhängig von der Zahl der parallelen Nutzer definiert wurde.

5.7.3.4 Lasttests

Für jeden Testlauf ist als Zeitaufwand zum Initialisieren, Vorbereiten und nachfolgendem Sammeln der protokollierten Daten eine Stunde zusätzlich zu der Dauer des Tests einzuplanen.

Durchführung der Tests ohne Buchungen (es werden beide Kategorien gemischt)
- 100 Nutzer a 2 Stunden
- 300 Nutzer a 2 Stunden
- 500 Nutzer a 2 Stunden
- 1000 Nutzer a 2 Stunden
Durchführung der Tests mit Buchungen
- 100 Nutzer (mit Rücksetzen) a 2 Stunden
- 300 Nutzer (mit Rücksetzen) a 2 Stunden
- 500 Nutzer (mit Rücksetzen) a 2 Stunden
- 1000 Nutzer (mit Rücksetzen) a 2 Stunden
- 100 Nutzer (ohne Rücksetzen) 1 Iteration
- 300 Nutzer (ohne Rücksetzen) 1 Iteration
- 500 Nutzer (ohne Rücksetzen) 1 Iteration
- 1000 Nutzer (ohne Rücksetzen) 1 Iteration
- (hiernach müssen die "Warenkörbe" gelöscht werden)
Validierungstest mit 1000 Nutzern über mindestens 5 Stunden für den Testfall Buchungen mit Rücksetzen.