Sie sind hier: Startseite » Kapitel 5 - Projekt Campus Management » Performance-Test Planung 

5 Projekt Campus Management

5.4 Entscheidungen für die Performancetests

Die vorliegende Systemarchitektur, die geforderten Nutzerzahlen und der enge Terminplan führten nach einer Recherche der Funktionen und Leistungen verschiedenster Lasttesttools zu folgenden Möglichkeiten:

• Black-Box-Test
  • Einfaches Protokollieren und Analyse der Response-Zeiten
    • kann selbst implementiert werden
    • keine Bottleneck-Analyse und bedingt aussagekräftige Performanceanalyse
• White-Box-Test
  • Aufzeichnung und Auswertung von Performancezählern
    • höherer Zeitaufwand, kann nicht mehr selbst implementiert werden
    • bedingt vollständige Bottleneck-Analyse
• Black-Box-Test mit Hierarchien
  • höherer Zeitaufwand, kann nicht mehr selbst implementiert werden
  • gute Performance- und Bottleneck-Analyse

Anforderungen die Lasttesttools aus verschiedenen Kategorien erfordern:

• Möglichst realistisches Nutzerverhalten simulieren
  • erfordert den Kauf eines Lasttesttools der Kategorie 2
• Stresstest, dass heißt Bestimmung der Systemgrenzen
  • erfordert den Kauf eines Lasttesttools der Kategorie 2
• Auffinden von Systemengpässen und Monitoring von einzelnen Netzwerk-Komponenten
  • erfordert den Kauf eines Lasttesttools der Kategorie 2 und eventuell eines Tools zum Analysieren der Daten der Performancezähler
• Gleichzeitiges Testen der SAP-GUI und des Webinterfaces
  • erfordert den Kauf eines Lasttesttools der Kategorie 1

Der Einfluss der Nutzer, die über die SAP-GUI auf das System zu greifen, ist laut SAP vernachlässigbar und es wurde die Entscheidung getroffen, das System nur über die Webschnittstelle zu testen. Somit sind die Kosten für ein Lasttesttool der Kategorie 1 nicht gerechtfertigt. Nachdem aus zeitlichen Gründen eine Implementierung, eines den Anforderungen gerecht werdenden Tools - 15000 parallele Nutzer mit realistischen Workload - nicht möglich war, wurde sich für das Lasttesttool Neoload von der Firma Neotys entschieden.

Aus projekttechnischen und -terminlichen Gründen wurden weitere Einschränkungen für die Durchführung der Performancetests getroffen:

• Die Stresstests der Testphase I der Performancetests werden auf dem Produktivsystem durchgeführt, die Tests der Testphase II auf dem Qualitätssicherungssystem.
  • Die Möglichkeit von Abweichungen der Performance auf dem Produktivsystem sind bewusst. Durch die ähnliche Struktur der beiden Systeme - das Produktivsystem stellt bestimmte Server mehrfach zur Verfügung - ist dieser Kompromiss akzeptabel.
• Als anwendungsspezifische Daten werden nur Dummy-Daten im System vorhanden sein, die nicht vollständig dem Umfang der Daten im späteren Betrieb entsprechen.
  • Dies kann zu deutlichen Abweichungen in der Performance führen und sollte bei der Empfehlung für den Live-Betrieb beachtet werden.
• Da die erwartete Spitzenlast von 10000 parallelen Nutzern nur sehr selten erreicht wird, werden die Lasttests zuerst nur bis zu einer parallelen Nutzerzahl von 1000 durchgeführt. Der Stresstest wird so vorbereitet, dass bis zu 15000 Nutzer gleichzeitig auf das System zu greifen können.

5.5 Planung der Performancetests

Für die Durchführung der Performancetests im Hinblick auf die mögliche Bottleneck-Analyse wurde sich für die Durchführung von Grey-Box-Tests mit Hilfe von Hierarchien entschieden, wobei nur die Beobachtung der Performancezähler während der Test in die Performanceanalyse einfließen.

Es werden verschiedene Tests durchgeführt, Lasttests sowohl als auch Stresstests. Sie unterscheiden sich in Art (qualitativ), Anzahl (quantitativ) und Ausführungsumgebung (lokal).