5 Projekt Campus Management
5.6 Testphase I
Die Testphase I im Projekt Campus Management dient zur Entscheidungsfindung, ob dieses Projekt zum geplanten Termin ausgeliefert werden kann. Aus termintechnischen Gründen wurden als Tests keine Lasttests angesetzt, sondern nur Stresstests, welche nachweisen sollten, dass das System mit dem erwarteten Nutzeraufkommen in keine kritischen Bereiche hineinläuft.
Die Lasttests und die Bottleneck-Analyse werden erst in der Testphase II durchgeführt werden.
5.6.1 Voraussetzungen
Zur Vorbereitung der anstehenden Tests wurden Voraussetzungen definiert, die bis zum Durchführungstermin erfüllt sein sollten. Sie umfassen technische und zeitliche Aspekte, die unabdingbar mit den bevorstehenden Stresstests verbunden sind.
5.6.1.1 Technische Voraussetzungen
- Ein funktionales Testsystem steht bereit und ist erreichbar von den definierten Testumgebungen.
- Die Testdaten sind aufbereitet und stehen in einem Mandanten, der an das Webinterface gebunden ist zur Verfügung.
- Die Testdaten sind vor jedem Test dahin bereinigt, dass die Ausgangsdaten der Testaufzeichnung vorhanden sind.
- Die Testdaten sowie das funktionale Webinterface stehen während der gesamten Testphase in gleicher Form zur Verfügung. Änderungen an den Testdaten und dem Webinterface sind nur vor der Durchführung der geplanten Tests erlaubt und nur in der Art, dass die erstellten Testszenarios davon nicht beeinflusst werden. Dies beinhaltet, dass die Reihenfolge und Parametrisierung der Anfragen nicht verändert werde, da dies ein erneutes Erstellen der Testszenarios zur Folge hätte. Änderungen während der Durchführung der Tests würden die Analyse und Interpretation der Testergebnisse stark erschweren.
5.6.1.2 Terminliche Voraussetzungen
- Nach Erfüllung der technischen Voraussetzungen sind 2 Wochen zur Erstellung verschiedenster Testszenarios erforderlich.
- Das Lasttest-Tool Neoload von der Firma Neotys muss für den gesamten Testzeitraum zur Verfügung stehen. Zur Erstellung der Testszenarios und dem Ermitteln der Referenzzeiten reicht die Evaluierungsversion. Für die Durchführung der Tests muss die Vollversion gemietet bzw. gekauft werden.
5.6.2 Vorbereitung
Die Erfüllung der im letzten Abschnitt definierten Voraussetzungen benötigten viele Absprachen, Arbeiten an verschiedenen Stellen im Projekt und einige Zeit.
5.6.2.1 Einrichten der Testumgebung
Als Testumgebung wurde ein Rechnerpool aus 20 Rechnern gewählt. Diese Rechner befinden sich in der unter 5.5.3 ii) definierten Umgebung und sollten für die Testphase I die einzigen Testclients bleiben.
Alle Testclients sind Rechner mit Intel Pentium 4 CPUs mit 3GHz, 1 GB Arbeitsspeicher und Microsoft Windows Server 2003 Enterprise Edition mit Service Pack 1 als Betriebssystem.
Ein Testclient wurde als Server für die Steuerungsinstanz des Lasttesttools gewählt. Auf diesem wurde die Steuerungssoftware von Neotys' Neoload installiert. Auf den anderen Testclients wurden die Neoload Agenten installiert, die von der Steuerungsinstanz angesprochen werden, um die Last auf dem zu testenden System zu erzeugen.
5.6.2.2 Erstellung der Testdaten
Da die Stresstests nachweisen sollen, ob das System das erwartete Nutzeraufkommen problemlos bewältigen kann, werden die bevorstehenden Tests mit möglichst realistischen Nutzerdaten durchgeführt. Dies soll zu einer realitätsnahen Last auf dem System führen. Da aus datentechnischen und auch aus projekttechnischen Gründen die Nutzung der originalen Nutzerdaten nicht möglich war, wurden spezielle Testnutzer angelegt. Die Erstellung der Testdaten hat als Basis die Daten der funktionalen Tests. Die dort definierten Teststudenten und Teststudiengänge dienten als Vorlage der Testdaten der Last- und Stresstests.
5.6.2.2.1 Studiengänge und Module
Die für die funktionalen Tests des Systems angelegten Studiengänge, werden ebenfalls für die Last- und Performancetests benutzt. Mit einem gewählten Studiengang sind Module verknüpft, die ein Teststudent auswählen kann.
Zu Berücksichtigen ist bei der Interpretation der Testdaten, dass die hier verwendeten Studiengänge nicht dem Umfang der späteren Daten entsprechen, sondern um einiges größer sein werden.
5.6.2.2.2 Teststudenten
Während der funktionalen Tests wurden 15 Teststudenten angelegt, die ein möglichst weites Spektrum der später realen Nutzer repräsentieren. Es wurde kein Wert darauf gelegt, alle Studiengänge zu repräsentieren, sondern jeder der 15 Teststudenten repräsentiert eine mögliche Kombination von Status des Studenten, Möglichkeiten der Modulauswahl und bereits absolvierten Modulen. Die Auswahl der 15 Teststudenten orientierte sich an den unterschiedlichen Testfällen, die durch die Strukturen des Campus Management Projektes vorgegeben werden.
Die definierten Vorgaben sahen vor, dass bis zu 1000 parallele Nutzer für die Lasttests und bis zu 15000 für die Stresstests simuliert werden sollen. Mit diesen Angaben und den unterschiedlichen Testfällen, die nicht immer die Daten der Teststudenten in den ursprünglichen Zustand versetzen können, um für den nächsten Testlauf zur Verfügung stehen zu können, wurde die Entscheidung getroffen, einen großen Pool an Teststudenten zu generieren. Dafür wurde aus den 15 Basisstudenten ein Pool von 15000 Teststudenten angelegt. Die Abschätzung der Häufigkeit des Auftretens der möglichen Kombinationen der Testfälle wurde bei der Generierung der Teststudenten beachtet. Die Erstellung der Teststudenten wurde mit einem Programm durchgeführt, welches für dieses Projekt geschrieben wurde.
5.6.2.2.3 Programm zur Generierung der Teststudenten
Die Voraussetzung für die Generierung der Teststudenten waren die 15 Teststudenten aus den funktionalen Tests. Die Daten dieser Teststudenten lagen in mehreren Exceltabellen vor. Für den Import der Teststudenten in das System mussten diese Daten an ein SAP-Interface angepasst werden, welche die generierten Teststudenten in das System einliest.
Die Aufgabe des Programms war es, die Daten aus den Exceltabellen einzulesen, notwendige Daten an das SAP-Interface anzupassen und diese im vorgeschriebenen Format abzuspeichern.
Bei der Implementierung des Programms wurde darauf geachtet, dass es durch Bearbeiten einer Konfigurationsdatei möglich war, für jeden der 15 Teststudenten festzulegen, wie häufig dieser Testfall repliziert werden sollte.
Die Basisdaten lagen in 3 Exceltabellen vor, welche die Daten der 15 Teststudenten enthielten.
Persönliche Daten:
Matrikelnummer, Art, Titel, Namenszusatz, Nachname, Vorname, Geburtsdatum, Geburtsort, Geburtsname, Geschlecht, Nationalität
Adressdaten:
Matrikelnummer, AdrArt, VerarbKennz, Straße Hausnummer, Zusatz, Land, Postleitzahl, Ort, Telefonnummer, E-Mail
Studienverlaufsdaten:
Matrikelnummer, Studiengang, Semester, VerarbKennz, Anzahl Studiengangsemester, Modulangebot 1, Modulangebot 2, Modulangebot 3, Modulangebot 4, Vertiefungsrichtung, Rückmeldestatus, Beurlaubungsgrund, Hörerstatus, Exmatrikulationsgrund, Exmatrikulationsdatum, Datum der Einschreibung, Datum der Rückmeldung
Das SAP-Interface erforderte ebenfalls 3 Dateien in Textformat, um die Daten über einen SAP-Report in das System zu importieren. Eine Zeile aus diesen Dateien beschreibt einen Teststudenten und sieht wie folgt aus:
100000*Z001*A*Grunewaldstr. 34a*Zimmer A*DE*14195*Berlin*030-20050809*virtualstudent_cm@gmx.de
Es wurde festgelegt, das für alle Teststudenten die Matrikelnummer auch gleichzeitig der Loginname ist und alle Teststudenten das selbe Passwort erhalten. Dies erleichterte die Erstellung der Testdaten und die Konfiguration der notwendigen Authentifizierungsmechanismen, die den Zugriff auf das Projekt Campus Management regeln.
Ein Ausschnitt der Konfigurationsdatei zeigt, die Möglichkeiten zur Steuerung der erzeugten Testdaten.
|
startMatrNummer=100000 |
// definiert den Beginn des Bereiches für die Matrikelnummern der Teststudenten |
|
studentcount=15 |
// definiert die Anzahl der verwendeten Basisteststudenten |
|
student.0.matnr=3973257 |
// definiert den Testfall_0 für den Basisstudenten mit der angegebenen Matrikelnummer |
|
student.0=1200 |
// definiert die Anzahl der Replikationen für den Testfall_0 |
|
student.1.matnr=3973324 |
// definiert den Testfall_1 für den Basisstudenten mit der angegebenen Matrikelnummer |
|
student.1=1050 |
// definiert die Anzahl der Replikationen den Testfall_1 |
|
... |
5.6.3 Erstellung der Testszenarios
Nachdem die Testdaten in das Testsystem importiert wurden, konnte mit der Erstellung der Testszenarios für den geplanten Stresstest begonnen werden. Als Basis wurden 12 von den 15 Teststudenten und ihre Modulbuchungen gewählt. Weiterhin wurde festgelegt, dass für den Stresstest der Testfall mit Buchungen und zusätzlichem Herstellen der Ausgangsvoraussetzung benutzt wird. Dies erzeugt eine höhere Last, als später im Live-Betrieb wahrscheinlich ist, unterstützt aber das Argument, der Durchführung eines Stresstests im Worst-Case.
Für jeden der 12 Teststudenten wurde ein Testfall mit dem Lasttesttool Neoload aufgezeichnet. Ein Testszenario umfasst das Buchen eines Moduls, Auswahl der Lehrveranstaltungen, Abschicken des Warenkorbes, sowie anschließendes Löschen der Modulbuchung.
Nach Aufzeichnung der Testfälle, konnten diese mittels des Lasttesttools parametrisiert werden. Es wurden die Daten der vervielfältigten Teststudenten an die aufgezeichneten Daten angepasst.
Es mussten leider auch Daten in den Konfigurationsdateien von Neoload angepasst werden, da die verwendeten Authentifizierungsmechanismen nicht von Neoload repliziert werden konnten. So musste zum Beispiel die Form der Session-Id, welche direkt im Pfad einer Anfrage .../sap(<session-id>)/asp/... verschluesselt war, ausgelesen und auf folgende Anfragen übertragen werden. Auch die komplizierte Verwendung des "Pluggable Authentication Service (PAS) für den SAP Internet Transaktion Server (ITS)" machte dem Tool Neoload Problem und musste durch manuelle Nacharbeit konfiguriert werden.
Nachdem die überarbeiteten Testfälle fehlerfrei funktionierten, wurde für die Lasttests ein gleichverteiltes Testszenario aus den 12 Testfällen erstellt.
5.6.3.1 Aufbau des Testsystems
Das Testsystem ist eine komplexe Multischichtarchitektur. Um die Nutzung des Campus Management Projektes zu ermöglichen, müssen alle Server - Webserver, Webdispatcher, Datenbanken, Applikationsserver und die entsprechenden Authentifizierungsmechanismen konfiguriert sein. Zu den Servern für die Authentifizierung gehören, wie ebenfalls in der Abbildung des Projekt Campus Management Netzwerkes sichtbar, der Internet Transaction Server, ldap-Server und Radius Server und einige Firewalls. Speziell die Authentifizierung muss auch für die angelegten Testnutzer in der Testumgebung vorgenommen werden.
5.6.4 Testdurchführungsplan
In Anbetracht des Projektzeitplans und den Anforderungen zur Durchführung der Last- und Performancetests ist in Zusammenarbeit ist folgender Testablauf entstanden, für den 2 Wochen einzuplanen waren:
- Miete des Lasttesttools Neoload für die Woche der Durchführung der Stresstests.
- Sammlung der Referenzdaten für das erstellte Testszenario und Ermittlung des "Rauschens" in der Testumgebung, durch einen Testlauf über einen Zeitraum von 72 Stunden, wobei alle 10 Minuten, das Testszenarios mit einer Nutzerlast von 10 ausgeführt und die Daten protokolliert werden.
- Nach Auswertung der Rauschermittlungsaufzeichnungen, werden Stresstests mit bis zu 15000 parallelen Nutzern durchgeführt. Je nach Häufigkeit und Stärke des Rauschens wird entschieden, ob die Tests nur zu Zeiten des Hintergrundrauschens oder auch während Spitzenlasten durchgeführt werden oder ob sie vernachlässigbar gering sind und die Durchführung der Stresstests nicht beeinflusst wird.
- Analyse und Auswertung der Daten und ihre Interpretation, wie sich das Verhalten des Systems bei sehr hoher Last (Stresstest bis 15000 paralleler Nutzer) verändert. Hierzu werden die Stresstestdaten mit den Referenzdaten verglichen und der "reale Lastfaktor" errechnet.
Performancetest Bottleneck Testtool Mercury Virtuelle User Testverfahren
