Last-Testing und Performance-Tuning · George W. Anderson, Michael Mißbach Projekthandbuch Last-Testing und Performance-Tuning

George W. Anderson, Michael Mißbach

ProjekthandbuchLast-Testing und

Performance-Tuning

5Inhalt

Inhalt

Vorwort zur deutschen Ausgabe 15

Vorwort zur englischen Ausgabe 17

1 Einführung 19

1.1 Warum haben wir dieses Buch geschrieben? .............................................. 191.1.1 Besonderheiten von SAP-Systemen ................................................ 201.1.2 Vorbehalte gegen Last-Testing und Performance-Tuning ............ 21

1.2 Wie haben wir dieses Buch geschrieben? .................................................... 23

1.3 Für wen haben wir dieses Buch geschrieben? ............................................ 261.3.1 Der Wasserfall .................................................................................... 261.3.2 Die Kunst, ein Boot jederzeit flott zu halten ................................. 271.3.3 Reaktionszeit und Durchsatz ............................................................ 29

1.4 Wie ist dieses Buch zu lesen? ........................................................................ 291.4.1 Aufbau dieses Buches ....................................................................... 301.4.2 Der SAP-Tuning-Werkzeugkoffer .................................................... 32

2 Last-Testing und Performance-Tuning 35

2.1 Besonderheiten im Umgang mit SAP-Systemen ......................................... 352.1.1 Gründe für Änderungen an mySAP-Lösungen ............................... 372.1.2 Erarbeiten von Performance-Tuning-Zielen ................................... 39

2.2 Last-Testing ....................................................................................................... 432.2.1 Argumente für Last-Tests ................................................................. 442.2.2 Was genau sind Last-Tests? .............................................................. 452.2.3 Weitere Formen von Last-Tests ....................................................... 482.2.4 Vergleichbarkeit von Last-Tests ....................................................... 502.2.5 Alternative Verfahren für Last-Tests ................................................ 50

2.3 Performance-Tuning ........................................................................................ 512.3.1 Statische Systeme vs. Adaptive Computing ................................... 522.3.2 Anwendungsübergreifende Geschäftsprozesse ............................. 532.3.3 Erkennung und Behebung von Engpässen ..................................... 542.3.4 Benchmarking .................................................................................... 552.3.5 System-Baselining .............................................................................. 56

2.4 Return on Investment vs. Return on Information ...................................... 57

Inhalt6

3 Testen von SAP-Lösungen 61

3.1 SAP-Technologie ............................................................................................... 613.1.1 SAP-Basis ............................................................................................ 623.1.2 SAP Web Application Server als neue Basis ................................... 623.1.3 SAP Exchange Infrastructure und SAP Master

Data Management ............................................................................. 643.1.4 SAP NetWeaver und mySAP-Lösungen .......................................... 65

3.2 Last-Tests von SAP-Lösungen und -Produkten ........................................... 663.2.1 R/3-System und SAP ERP Central Component .............................. 673.2.2 SAP Enterprise Portal ........................................................................ 703.2.3 SAP Business Information Warehouse ............................................ 723.2.4 SAP Strategic Enterprise Management ............................................ 763.2.5 mySAP Customer Relationship Management ................................ 773.2.6 mySAP Product Lifecycle Management .......................................... 783.2.7 mySAP Supply Chain Management ................................................. 793.2.8 mySAP Supplier Relationship Management ................................... 803.2.9 SAP Exchange Infrastructure ............................................................ 813.2.10 SAP xApps ........................................................................................... 833.2.11 SAP Internet Transaction Server ...................................................... 83

3.3 SAP-Systemlandschaften ................................................................................ 843.3.1 Typische Landschaften für mySAP-Lösungen ................................. 863.3.2 Empfehlung ........................................................................................ 88

4 Konkrete Ziele als Erfolgskriterien 89

4.1 Ziele, Geschäftsprozesse und Daten im Detail ........................................... 904.1.1 Ermittlung von Lösungsmerkmalen ................................................. 914.1.2 Ermittlung relevanter Geschäftsprozesse ........................................ 934.1.3 Ermittlung relevanter Daten ............................................................. 944.1.4 Entwicklung einer Projektplanvorlage ............................................. 95

4.2 Verschiedene Last-Test-Methoden ............................................................... 974.2.1 Testen einzelner Hardwarekomponenten (Stufe 1) ...................... 974.2.2 Standard-Benchmark-Tests für SAP-Systeme (Stufe 2) ................. 984.2.3 Kundenspezifische Stress-Tests (Stufe 3) ........................................ 101

4.3 Entwicklung von Erfolgskriterien .................................................................. 1034.3.1 Messungen mit der Stoppuhr .......................................................... 1044.3.2 Reaktionszeiten von Transaktionen und Geschäftsprozessen ...... 1064.3.3 Messung von Systemleistung und -durchsatz ................................ 1074.3.4 Leistung des Plattensubsystems ....................................................... 108

7Inhalt

5 Zusammensetzung des Test- und Tuning-Teams 111

5.1 Technologie trifft Business ............................................................................. 111

5.2 Best Practices für die Teamzusammenstellung ........................................... 1125.2.1 Taktische Überlegungen für einzelne Projekte .............................. 1135.2.2 Langfristige und strategische Überlegungen .................................. 1145.2.3 Zusammenhang zwischen Werkzeugen und Teams ...................... 1145.2.4 Einsatz externer Ressourcen ............................................................. 1155.2.5 Methoden zum schnellen Lernerfolg .............................................. 1165.2.6 Herausforderungen durch neue Lösungen und Systeme ............. 118

5.3 Unterstützung des Change-Management-Teams ....................................... 1195.3.1 Taktisches Change-Management ..................................................... 1195.3.2 Strategisches Change-Management ................................................ 120

6 Auswahl der Testwerkzeuge 125

6.1 Bewertung von Testwerkzeugen ................................................................... 1266.1.1 Kriterien für Testwerkzeuge ............................................................. 1266.1.2 Beschaffung von Pilotsoftware ......................................................... 1276.1.3 Test von Testwerkzeugen ................................................................. 127

6.2 Betriebssystemspezifische Werkzeuge ......................................................... 1286.2.1 CheckIt von Smith Micro .................................................................. 1286.2.2 Werkzeuge von Hardwareherstellern ............................................. 1296.2.3 Werkzeuge für Webserver ................................................................ 1306.2.4 NetBench und WebBench von VeriTest ......................................... 1316.2.5 Benchmark Factory von Quest ........................................................ 1326.2.6 OpenSTA von CYRANO .................................................................... 1336.2.7 Chariot und QCheck von NetIQ ...................................................... 1336.2.8 Windows Media Player von Microsoft ........................................... 1346.2.9 Norton AntiVirus LoadSim von Symantec ...................................... 134

6.3 Test-Werkzeuge für Plattensubsysteme ...................................................... 1346.3.1 SQLIO von Microsoft ........................................................................ 1356.3.2 SQLIOStress von Microsoft .............................................................. 1366.3.3 NTiogen von Symbios ....................................................................... 1386.3.4 Iometer ............................................................................................... 1396.3.5 Nbench ............................................................................................... 1396.3.6 Performance Assessment Tool von Hewlett-Packard ................... 1406.3.7 SQL Profiler von Microsoft ............................................................... 140

6.4 Generische Scripting-Werkzeuge .................................................................. 1416.4.1 Perl, Visual Test und andere ältere Scripting-Werkzeuge ............ 1426.4.2 AutoIT von HiddenSoft ..................................................................... 1436.4.3 PrimalScript von Sapien .................................................................... 1446.4.4 TxShuttle von WinShuttle ................................................................ 145

6.5 SAP API-fähige Scripting-Werkzeuge ........................................................... 1456.5.1 AutoTester ONE von AutoTester ..................................................... 147

Inhalt8

6.5.2 TestPartner von Compuware ............................................................ 1486.5.3 QALoad von Compuware ................................................................. 1496.5.4 WinRunner for R/3 und QuickTest Professional von

Mercury Interactive ........................................................................... 1506.5.5 LoadRunner von Mercury Interactive ............................................. 150

6.6 Werkzeuge und Ansätze von SAP .................................................................. 1516.6.1 SAP eCATT .......................................................................................... 1526.6.2 Lasterzeugung mit SAP CCMS ......................................................... 1536.6.3 Anwendungsübergreifende Last-Tests ............................................ 1536.6.4 Last-Tests von SAP BW und SAP SEM ............................................ 1536.6.5 Last-Tests von SAP EP und mySAP SRM ......................................... 1556.6.6 Weitere Überlegungen ...................................................................... 1556.6.7 Tipps und Tricks ................................................................................. 156

7 Überwachungswerkzeuge 157

7.1 Überwachungswerkzeuge von SAP ............................................................... 1577.1.1 SAP CCMS .......................................................................................... 1587.1.2 Central Monitoring System .............................................................. 1607.1.3 SAP Solution Manager ...................................................................... 161

7.2 Tools zur Dokumentation der Konfigurationsdaten ................................... 1637.2.1 WinMSD von Microsoft .................................................................... 1647.2.2 Systems Insight Manager von Hewlett-Packard ............................. 1647.2.3 CheckIt von Smith Micro .................................................................. 1657.2.4 MonitorIT von Breakout Software ................................................... 1657.2.5 Configuration Auditor von Ecora ..................................................... 1667.2.6 Patch Manager von Ecora ................................................................. 1667.2.7 Survey von Hewlett-Packard ............................................................ 1677.2.8 GetConfig von Hewlett-Packard ...................................................... 1687.2.9 AssetDB von Compulsion Software ................................................. 1697.2.10 Windows Management Instrumentation von Microsoft .............. 169

7.3 Monitor-Utilities und Betriebssystem-Applets .......................................... 1707.3.1 Tools für Plattensubsysteme ............................................................. 1707.3.2 UNIX-Betriebssystem-Tools .............................................................. 1717.3.3 Betriebssystem-Tools für Microsoft Windows ............................... 1747.3.4 Management-Tools für Oracle und Microsoft SQL Server ........... 1757.3.5 IBM Insight für SAP und Oracle ....................................................... 1767.3.6 Überwachungs-Tools für periphere Geräte .................................... 176

7.4 Lab-Utilities ....................................................................................................... 1767.4.1 PsTools von Sysinternals ................................................................... 1777.4.2 EventComb von Microsoft ............................................................... 1787.4.3 Administrator's Pak von Winternals ................................................ 1797.4.4 Weitere Lab-Utilities ......................................................................... 179

7.5 Anwendungen zum Enterprise-Management .............................................. 1807.5.1 Patrol for SAP Solutions Suite von BMC ......................................... 1817.5.2 Unicenter Application Management von

Computer Associates ......................................................................... 1827.5.3 OpenView Operations von Hewlett-Packard ................................. 182

9Inhalt

7.5.4 Tivoli Monitoring for Applications von IBM .................................. 1837.5.5 AppManager für das R/3-System von NetIQ ................................. 183

8 Vorbereitung für einen guten Start 185

8.1 Hardwareressourcen für Test und Tuning .................................................... 1858.1.1 Sandbox-Systeme .............................................................................. 1858.1.2 Capacity-on-Demand-Systeme ........................................................ 1868.1.3 Hilfssysteme der Testinfrastruktur ................................................... 187

8.2 Erfassen der Baseline ....................................................................................... 1878.2.1 Dokumentationstiefe der Baseline-Konfiguration ......................... 1888.2.2 Einfrieren der Baseline ...................................................................... 190

8.3 Vorbereitung des Testsystems ....................................................................... 191

9 Festlegung einer Testkombination 195

9.1 Ermittlung eines repräsentativen Testmix ................................................... 1959.1.1 Charakterisierung der Arbeitslast ..................................................... 1969.1.2 Ermittlung der am häufigsten ausgeführten Transaktionen ......... 1979.1.3 Definition von Lastpaketen .............................................................. 1979.1.4 Baselines für Testkombinationen ..................................................... 2009.1.5 Weitere Überlegungen zu Input-Daten .......................................... 201

9.2 Testkombinationen für technische Komponenten ..................................... 2039.2.1 Serverhardware .................................................................................. 2039.2.2 Plattensubsysteme ............................................................................. 2049.2.3 Betriebssysteme ................................................................................. 2049.2.4 Datenbanken ...................................................................................... 205

9.3 Test durchschnittlicher Systemlasten ........................................................... 207

9.4 Test von Spitzenlasten .................................................................................... 2089.4.1 Datengrundlage und Datenbeschaffung ......................................... 2099.4.2 Zusammenstellung des Last-Mixes .................................................. 2099.4.3 Einschränkungen im Hinblick auf End-to-End-Tests ..................... 210

9.5 Spezifische Herausforderungen der verschiedenen SAP-Komponenten ........................................................................................... 211

10 Automatisierung von Last-Tests 215

10.1 Grundlagen im Überblick ................................................................................ 215

10.2 Praxistaugliche Ansätze ................................................................................... 21710.2.1 SAP-Benchmark-Kits als Vorlagen ................................................... 21710.2.2 Top-10-Ansatz ................................................................................... 21810.2.3 Nutzung des SAP Batch Schedulers ................................................ 21910.2.4 Skripte für das Grundrauschen ........................................................ 22010.2.5 Mandantenkopien ............................................................................. 220

Inhalt10

10.3 Vorbereitung von Skripten ............................................................................. 22010.3.1 Tests mit realen Benutzern ............................................................... 22110.3.2 Tests mit virtuellen Benutzern ......................................................... 22210.3.3 Infrastruktur für die Entwicklung von Last-Test-Skripten ............. 223

10.4 Praxistipps für die Skripterstellung ............................................................... 22410.4.1 Skripte testen und bearbeiten .......................................................... 22510.4.2 Skript für die Erfassung der Daten und Statistiken ........................ 22610.4.3 Skript für das SAPLOGIN .................................................................. 22810.4.4 Zeitversetzte Anmeldung am SAP GUI ........................................... 22910.4.5 Weitere Tipps und Tricks .................................................................. 23010.4.6 Regelmäßige Kommunikation .......................................................... 23210.4.7 Utility-Skripte ..................................................................................... 233

10.5 Standard-Subroutinen für Last-Tests ............................................................ 23310.5.1 Variablen und Eingabedaten ............................................................ 23310.5.2 Tuning virtueller Benutzer ................................................................ 23410.5.3 Andere nützliche Subroutinen ......................................................... 236

11 Abschließende Vorbereitungen und letzte Korrekturen 239

11.1 Implementierung der simulierten Benutzer ................................................. 24011.1.1 Installation der Support-Infrastruktur für die Client-Emulation .. 24011.1.2 Installation des SAP GUI ................................................................... 24211.1.3 Softwareinstallation für die Client-Emulation ................................ 242

11.2 Konfiguration der Werkzeuge für die Client-Emulation ............................ 24311.2.1 Testen von Testpaketen .................................................................... 24411.2.2 Aspekte in Hinblick auf die Arbeitslast ........................................... 245

11.3 Einfrieren der Testplattform ........................................................................... 245

11.4 Überlegungen zur Überwachung des Last-Tests ........................................ 24611.4.1 Überwachung der Testläufe .............................................................. 24711.4.2 Automatisierte Prozesse, Dienstprogramme und

Transaktionsskripte ............................................................................ 248

11.5 Ende der Testwoche ......................................................................................... 251

12 Ausführung von Last-Tests 253

12.1 Sicherstellung der Wiederholbarkeit ............................................................ 25312.1.1 Mehr als ein Test ................................................................................ 25412.1.2 Änderungen immer nacheinander vornehmen .............................. 254

12.2 Praxistipps für Testläufe .................................................................................. 25512.2.1 Checklisten ......................................................................................... 25512.2.2 Zeit zwischen Testläufen reduzieren ............................................... 25512.2.3 Zurücksetzen der Datenbank ........................................................... 25612.2.4 Neustart aller Systeme ...................................................................... 25912.2.5 Systemprüfung vor dem Test ........................................................... 259

11Inhalt

12.3 Start des Last-Tests ......................................................................................... 260

12.4 Überwachung des Testlaufs ........................................................................... 26112.4.1 Automatisierte Datensammlung ...................................................... 26112.4.2 Überwachung durch SAP-Monitoring-Transaktionen ................... 26212.4.3 Überwachung durch den SAP CCMS Alert Monitor ..................... 26312.4.4 Transaktion STAD .............................................................................. 26412.4.5 Weitere SAP CCMS-Transaktionen ................................................. 26512.4.6 Überwachung durch betriebssystembasierte Tools ....................... 266

12.5 Beenden von Testläufen .................................................................................. 26612.5.1 Ordnungsgemäßes Ende eines Testlaufs ......................................... 26712.5.2 Beenden durch Schleifenzähler ....................................................... 26712.5.3 Harter Abbruch .................................................................................. 268

13 Analyse von Last-Tests 271

13.1 Überblick über die wichtigsten Leistungsdaten ......................................... 272

13.2 Einsatz von SAP CCMS .................................................................................... 27413.2.1 Performance-Log der SAP-Anwendung .......................................... 27413.2.2 Performance der Datenbank ............................................................ 27513.2.3 Updates, Sperren und die Leistung des Plattensubsystems ......... 27613.2.4 Speicherverwaltung ........................................................................... 27913.2.5 Tabellenpuffer .................................................................................... 28013.2.6 Betriebssystemmonitor ..................................................................... 28313.2.7 Detailanalysen der Antwortzeit und Arbeitslast ............................ 285

13.3 Aufbereitung der Messdaten ......................................................................... 28713.3.1 Datentransfer mit Transaktion ST03 ............................................... 28813.3.2 Datenexport aus dem SAP GUI ....................................................... 28913.3.3 Aufbereiten der Ausgabeprotokolle ................................................ 28913.3.4 Import der Ausgabedaten in Excel .................................................. 290

13.4 Darstellung der Ergebnisse ............................................................................ 29213.4.1 Zielgruppen ........................................................................................ 29213.4.2 Daten in Informationen umwandeln .............................................. 292

14 Iteratives Testen und Tunen 295

14.1 Postrun-Analyse ............................................................................................... 296

14.2 Bewertung von Änderungen während eines Testzyklus ........................... 29714.2.1 Methodenwechsel während des Last-Tests ................................... 29714.2.2 Änderungen an Clients ..................................................................... 29814.2.3 Änderungen der Testplattform ........................................................ 29814.2.4 Änderungen der Arbeitslast ............................................................. 299

14.3 Tuning von SAP-Systemen .............................................................................. 29914.3.1 Tuning des Plattensubsystems und des SAN ................................. 30014.3.2 Datenbank-Tuning ............................................................................. 302

Inhalt12

14.3.3 SAP-Anwendungs-Tuning ................................................................. 30514.3.4 SAP-Frontend-Tuning ....................................................................... 306

14.4 Erfahrungen aus der Praxis ............................................................................. 30714.4.1 Windows Server-Konsolidierung für SAP ....................................... 30814.4.2 SAN-Konsolidierung und Plattensubsystem-Upgrades ................. 30914.4.3 Release-Upgrades .............................................................................. 311

15 Besondere Nutzenfaktoren 313

15.1 Verfügbarkeit .................................................................................................... 31315.1.1 Zusammenhang von Konsistenz und Verfügbarkeit

eines SAP-Systems ............................................................................. 31415.1.2 Single Points of Failure ...................................................................... 31515.1.3 Failover-Tests ..................................................................................... 31815.1.4 Wartungsfenster und Hochverfügbarkeit ....................................... 31915.1.5 Test von Desaster-Recovery-Lösungen ........................................... 32115.1.6 Schutz gegen Inkonsistenz der Datenbank ..................................... 323

15.2 Skalierbarkeit .................................................................................................... 32415.2.1 Scale-up- und Scale-out-Skalierbarkeit ........................................... 32515.2.2 Ermittlung der tatsächlichen Belastbarkeit ..................................... 32715.2.3 Smoke-Tests ....................................................................................... 328

15.3 Einfluss von Last-Tests auf die SAP-Systemadministration ...................... 328

15.4 Proaktives Testen ............................................................................................. 32915.4.1 Von der Transaktion zum anwendungsübergreifenden

Geschäftsprozess ................................................................................ 32915.4.2 Charakterisierung der Zusammensetzung der Systemlast ............ 33015.4.3 Neue Technologien und Ausführungsfenster ................................. 331

15.5 Ein guter Rat zum Schluss .............................................................................. 331

A Musterskripte 333

A.1 Zeitversetztes Anmelden ................................................................................. 333

A.2 Systemabmeldung ............................................................................................ 334

A.3 Grundrauschen .................................................................................................. 335

A.4 Daten aus Textfile einlesen ............................................................................ 336

A.5 Daten aus Microsoft Excel einlesen .............................................................. 337

A.6 Seriennummern-Generator ............................................................................. 337

A.7 Zufallszahlen-Generator .................................................................................. 338

A.8 Logische Verzweigung ..................................................................................... 338

A.9 SAP GUI-Meldungen erfassen ........................................................................ 342

A.10 ST03-Monitoring .............................................................................................. 342

A.11 Aufzeichnung von Messdaten ........................................................................ 347

13Inhalt

B Tools-Matrix 349

Die Autoren 355

Index 357

15Vorwort zur deutschen Ausgabe

Vorwort zur deutschen Ausgabe

»If you can’t measure it – you can’t manage it.«

Unternehmen sind aus guten Gründen bestrebt, die von ihnen betriebe-nen EDV-Systeme möglichst unverändert zu betreiben. Auf diese Weiseist die Stabilität der Systeme am einfachsten gewährleistet und die Kostenbleiben unter Kontrolle. Der globale Wettbewerb macht es jedoch not-wendig, Geschäftsprozesse schnell an die sich ständig wandelnden Bedin-gungen des Marktes anzupassen. Damit müssen sich aber auch die Soft-waresysteme ständig verändern, die diese Prozesse in vielen Fällen erstermöglicht haben. Die »Agilität« der EDV-Systeme wird damit zum Wett-bewerbsfaktor.

Auf der anderen Seite legt der zum Sprichwort gewordene Rat, »Nevertouch a running system«, nahe, dass jede Veränderung ein Risiko für dieimmer komplexer werdenden Systemlandschaften birgt. Die zuneh-mende Durchdringung der Geschäftsprozesse durch SAP-Lösungenmacht Unternehmen immer abhängiger von diesen Systemen, eine aus-reichende Systemleistung und Verfügbarkeit – auch und gerade unter Last– werden zunehmend wichtiger.

In Systemlandschaften im Umfeld von SAP NetWeaver erstrecken sichGeschäftsprozesse über mehrere SAP-Systeme. Mit der Enterprise ServicesArchitecture (ESA) können in kürzester Zeit Funktionalitäten von mehre-ren Systemen zu einem übergeordneten Geschäftsprozess zusammenge-führt werden. Wenn aber nur eines der beteiligten Systeme ausgerechnetwährend der Hauptsaison oder zum Jahreshauptabschluss eine völligungenügende Leistung zeigt oder gar zum Stehen kommt, ist guter Rat imwahrsten Sinne des Wortes sehr teuer – wenn er überhaupt auf dieSchnelle zu erhalten ist.

Der Betrieb von SAP-Infrastrukturen erfordert daher den konsequentenEinsatz von Best Practices und Verfahren, wie sie z.B. in der InformationTechnology Infrastructure Library (ITIL) niedergelegt wurden, sowie in ihrerWeiterentwicklung, dem IT Service Management Reference Model (ITSM).Heute gilt ITSM als Industriestandard für den professionellen Betrieb ver-teilter Rechnerumgebungen und seine Bedeutung für den Betrieb vonSAP-Umgebungen steht außer Frage.

Vorwort zur deutschen Ausgabe16

Allerdings beschreiben ITIL und ITSM nur den groben Rahmen, ohne aufdie praktische Implementierung einzugehen. In vielen Gesprächen habeich von Kunden immer wieder gehört, dass vor allem für den zumChange- und Performance-Management gehörenden Bereich »Testenund Tunen von SAP-Systemen« Bedarf nach einem praxisrelevanten Leit-faden besteht.

In Ergänzung zu meinen Büchern über Adaptive Hardware-Infrastruktu-ren und den Systembetrieb für SAP, die in den letzten Jahren bei SAPPRESS veröffentlicht wurden, habe ich daher dem Verlag eine Überset-zung des Buches mySAP Tool Bag for Performance Tuning and Stress Testingmeines US-amerikanischen Kollegen George W. Anderson vorgeschlagen.Das übersetzte, deutschte Manuskript habe ich – in enger Abstimmungmit ihm – aktualisiert, teilweise umgeschrieben und Besonderheitengekürzt, die nur den amerikanischen Markt betreffen. Ich hoffe, dass Siein diesem Buch Konzepte sowie Tipps und Tricks finden, die Ihnen helfen,die SAP-Systeme Ihres Unternehmens immer fehlerfrei und performantzu halten.

Die deutsche Bearbeitung dieses Buches ist in vielen Nacht- undWochenendstunden während meiner Freizeit entstanden. Darum ist die-ses Buch meiner Frau Sabine und meinem Sohn Richard gewidmet, dieviel Zeit ohne meine ungeteilte Aufmerksamkeit verbringen mussten.Bedanken möchte ich mich auch bei Florian Zimniak und Stefan Prokschsowie dem ganzen SAP PRESS-Team, die dieses Buch in gewohnt profes-sioneller Weise realisiert haben.

Dr.-Ing. Michael Mißbach, im Mai 2005SAP HP Competence Center, Walldorf

17Vorwort zur englischen Ausgabe

Vorwort zur englischen Ausgabe

»This book is about a whole lot more than performance tuning and testing.«

In diesem Buch geht darum, Geld zu sparen und Geld zu verdienen – inBezug auf das Kapital Ihres Unternehmens, das Budget Ihrer Kunden undsogar Ihre persönlichen Mittel. Zwei Faktoren sind dazu entscheidend:Die Anfangsinvestitionen in eine SAP-Systemlandschaft müssen möglichstschnell wieder zurückfließen und das System muss wie eine gut geölteMaschine funktionieren, damit es auch langfristig Gewinn abwirft. Dasgeht im Prinzip ganz einfach, indem Sie dafür sorgen, dass die Benutzerdes SAP Business Information Warehouse stets mit aktuellen Informatio-nen versorgt sind, Ihr Customer-Relationship-Management-Team pro-duktiv bleibt und Ihre R/3-User immer beschäftigt sind. Im Gegenzugprofitiert Ihr Unternehmen von den Vorteilen eines schnellen Informati-onszugriffs, besseren Vertriebszahlen und vielem mehr – positive Auswir-kungen im Hinblick auf Finanzen, Job und Karriere.

Dieses Buch beschäftigt sich auch mit den Gefahren, die dem wohl wich-tigsten Faktor der heutigen Geschäftswelt innewohnen und die ein sorg-fältiges Last-Testing und Performance-Tuning so unabdingbar machen:Veränderung. Die Art und Weise, in der Veränderungen gehandhabt wer-den – oder anders gesagt: wie ein Unternehmen sicherstellt, dass Verän-derungen sich nicht negativ auf die Leistung oder Verfügbarkeit unter-nehmenskritischer SAP-Systeme auswirken –, macht den Unterschiedzwischen einem durchschnittlichen und einem wirklich erfolgreichenUnternehmen aus. Im Umkehrschluss gilt natürlich auch: Ein jahrzehnte-lang vernachlässigtes Change-Management kann eine Lawine auslösen,die auch erfolgreiche Organisationen mit sich reißt und nur diejenigenverschont, die genügend Anpassungsfähigkeit zeigen. Schon häufig sindgroße Unternehmen und Institutionen über scheinbare Kleinigkeiten insStolpern geraten.

Die Vergangenheit zeigt, dass die Erfolgsaussichten für ein gutes Change-Management viel versprechend sind. Ein Blick auf die Liste der 2.000größten Unternehmen weltweit belegt, dass die Anpassungsfähigkeit anVeränderungen das Überleben selbst in Zeiten einer schlechten globalenWeltwirtschaftslage sichern kann. Die erfolgreichsten Unternehmen indieser Liste setzen Testverfahren und Tuning-Methoden ein, die den hier

Vorwort zur englischen Ausgabe18

vorgestellten ähneln – sie betrachten ihre SAP- und Unternehmenssys-teme als Ganzes, um die Leistung zu steigern, Ausfälle zu verringern unddie Risiken zu minimieren, die Veränderungen mit sich bringen. Ausgenau diesem Grund habe ich dieses Buch geschrieben: Ich möchte Ihnenverschiedene Ansätze vorstellen, mit denen Sie den Veränderungen derheutigen Geschäftswelt begegnen können, damit Ihr Unternehmen nichtnur überlebt, sondern auch wachsen kann.

Danksagung Das Wort Veränderung lässt mich an die Durchführung von System-Upgrades, das Verwalten und Installieren von SAP Support-Packages undan das Aufspielen von Patches und Fixes denken. Ich denke darüber nach,was auf dem Spiel steht – die Leistung und Verfügbarkeit eines Systems,von dem die Arbeit tausender Menschen abhängt –, und ich erkenne dieTragweite meiner Arbeit und der meines Teams. Gleichzeitig ruft dasWort Veränderung jedoch auch andere, persönliche Gefühle hervor. Die-ses Wort beinhaltet auch die tief greifenden Veränderungen, die einMensch durch Gott erfahren kann. Verstehen Sie mich nicht falsch: Ichbin kein Geistlicher oder Prediger, sondern ich habe einfach nur meinenWeg im Glauben gefunden und versuche seither, mein Leben nach christ-lichem Vorbild zu gestalten.

Dies vorausgeschickt muss ich nicht betonen, dass ich für meine Familieund meinen Arbeitsplatz dankbar bin, sowie für meine Kunden, die mitihrer Erfahrung ebenfalls zu diesem Buch beigetragen haben. Von Herzendanken möchte ich meiner Familie – meinen Kindern Phillip, Ashley undMeagan und ganz besonders meiner Frau und besten Freundin Michelle.Ein großes Dankeschön gilt außerdem meinen vielen Kunden in Nord-amerika, speziell in Houston, Cleveland, Austin, Cranston und Rochester– vielen Dank für die gute Zusammenarbeit und die Möglichkeit, vonein-ander zu lernen. Meinen SAP-Kollegen bei HP, SAP, Microsoft, Oracle,Capgemini und anderen Unternehmen danke ich für die langjährige unduneingeschränkte Unterstützung und Freundschaft. Ein herzlicher Dankfür ihre großartige Hilfe geht auch an meine Testkollegen bei AutoTester,Compuware, Mercury Interactive, SAP, Microsoft und vielen weiteren.Schließlich möchte ich mich bei meinen engsten Freunden und allenanderen bedanken, mit denen ich tagtäglich zusammenarbeite. Für eureUnterstützung, Zuverlässigkeit und Freundschaft werde ich euch immerdankbar sein.

George W. Anderson, im Juni 2004Hewlett-Packard, Houston

215Grundlagen im Überblick

10 Automatisierung von Last-Tests

Die Automatisierung der Systembelastung betrifft die Daten-eingabe und -verarbeitung. Die Emulation der Arbeitslast durch die Simulation der Eingabe von Daten und Abfragen ist der eigentliche Kern jedes Last-Tests. Ohne ein Verfahren zur Automatisierung dieser Eingaben, sodass sie weitgehend ohne ständige Überwachung, aber kontrolliert selbstständig ablau-fen, sind Stress-Tests kaum realisierbar.

Dieses Kapitel ist der Automatisierung der Lasterzeugung gewidmet.Basierend auf unseren praktischen Erfahrungen werden u.a. Verfahren fürdie Automatisierung beschrieben und Tipps vermittelt, damit Sie mög-lichst schnell funktionsfähige Skripte erstellen können. Ferner werden dieAlternativen für die Automatisierung der Testlast genannt, die Ihnen hel-fen werden, wenn Sie Ihrem Team oder Ihren Vorgesetzten gegenüberAutomatisierungsmethoden rechtfertigen und schmackhaft machen müs-sen.

10.1 Grundlagen im ÜberblickWiederholbarkeit und Konsistenz

Bei der Automatisierung der Systemlast durch einen Last-Mix, dessenZusammenstellung detailliert in Kapitel 9 beschrieben wurde, geht esnicht nur um die optimale Nutzung der vorhandenen Ressourcen, alsoPersonaleinsparungen, sondern auch darum, wiederholbare und konsis-tente Testläufe zu gewährleisten. Automatisierte Testverfahren ermögli-chen:

Möglichkeiten automatisierter Testverfahren

� die Simulation von hunderten oder tausenden von Benutzern durcheinige wenige Mitarbeiter

� die Simulation von hunderten oder tausenden von PCs und Laptopsdurch eine kleine Zahl von Servern zur Lastgenerierung

� die Automatisierung der Ausführung komplexer Geschäftsprozesse

� die Ermittlung einiger weniger Input-Datensätze, anhand derer hun-derte gültige Datenkombinationen generiert werden können

� die Wiederverwendung der Skripte für Last-Tests, z.B. für Funktions-oder Regressions-Tests

Automatisierung von Last-Tests216

Last-Tests mitSAP NetWeaver

SAP-Last-Tests neuerer Generation müssen jedoch mehr als nur durchBenutzer generierte Transaktionen umfassen. Neben Transaktionen, diedurch ALE (Application Link Enabling) oder EDI (Electronic Data Inter-change) von anderen Systemen generiert werden, tritt mit SAP NetWea-ver die SAP Exchange Infrastructure als »Vermittler«.

Die Automatisierung der Systemlast muss daher auch dafür eingesetztwerden können, sicherzustellen, dass auch verknüpfte und unterneh-menskritische Systeme miteinander arbeiten. Glücklicherweise müssenSie hierfür kein Experte für Internetprotokolle sein. Es genügt festzule-gen, welche Geschäftsprozesse getestet werden sollen, und dieGeschäftsprozesse mit Daten im richtigen Format zu versorgen.

ManuelleAusführung von

Transaktionen

Die Alternative zur Automatisierung von Testläufen ist die manuelle Aus-führung von Transaktionen; für funktionale und Regressionstests ist diessogar die normale Methode. Für Last-Tests ist die manuelle Eingabe vonTransaktionen dagegen keine realistische Option. Abgesehen von derUnmöglichkeit, hunderte oder tausende von Mitarbeitern dafür einsetzenzu können, bestünde eine weitere Herausforderung darin, dass dieBenutzer »auf Kommando« die verschiedenen Geschäftsprozesse repro-duzierbar ausführen müssten.

Eine weitere Methode, die hier nur der Vollständigkeit halber erwähntwerden soll, ist die Simulation von Usern – auf ihren PCs außerhalb dernormalen Arbeitszeit – mithilfe von Tools, die nicht über eine SAP APIverfügen.

Praxisbeispiel So haben wir z.B. einmal auf Wunsch eines Kunden für einen Last-Testauf R/3-Systemen auf 300 PCs Transaktionen mit Windows Visual Test4.0 ausführen lassen. Dieser Ansatz hatte folgende Nachteile:

� Auf jedem dieser PCs musste ein SAP GUI installiert werden, wozujeder PC die GUI-Standards erfüllen musste, um das erfolgreicheAusführen der Skripte zu gewährleisten.

� Die Skriptsprache selbst führte bei der Ausführung zu Fehlern –Desktops wurden unerwartet gesperrt, Skriptfenster wurden unter-brochen usw.

� Auch das Starten der Tests stellte eine große Herausforderung dar,da meist ein Neustart des Rechners notwendig war, und zwar zumLeeren des Cache, Herstellen von SAP-Client-Verbindungen undAktivieren abgestürzter/blockierter Desktops.

217Praxistaugliche Ansätze

IDES und SAP-Benchmark-Kits

Eine weitere Methode beinhaltet die Verwendung eines SAP-Benchmark-Kits zur Simulation der Anwendungslast (siehe Abschnitt 10.2.1). Aller-dings können mit einem Standardtest eben auch nur Standardlasten aufStandardsystemen erzeugt werden; schon das individuelle Customizingeines Systems kann zu erheblichen Problemen führen. Zudem habendiese Benchmark-Kits eine nicht zu unterschätzende Lernkurve, z.B.inklusive handgestrickter Perl-Codes und AutoIT-Skripts. Standard-Benchmark-Kits können daher in der betrieblichen Realität nur dafürgenutzt werden, die vom Hersteller versprochene Leistung eines neuenSystems vor Beginn des Customizings in einem Abnahmetest nachzuwei-sen (siehe Abschnitt 4.2.2).

Für die Nutzung eines Internet Demonstration and Evaluation Systems(IDES) für Testzwecke gilt prinzipiell das Gleiche. Für den Test von kun-denindividuellen Geschäftsprozessen und Systemen sind diese Ansätzeungeeignet.

10.2 Praxistaugliche Ansätze

Die folgenden Ansätze für die Automatisierung von Last-Tests haben sichin der Praxis bewährt. Für diese Verfahren werden die wesentlichen SAP-Geschäftsprozesse berücksichtigt.

10.2.1 SAP-Benchmark-Kits als Vorlagen

Ganzheitlicher Geschäftsprozess

Auch wenn sich die SAP-Benchmark-Kits nicht für kundenindividuelleLast-Tests eignen, so können sie doch als Vorlage zum Erstellen eigenerSkripte verwendet werden. Der Vorteil der Benchmark-Kits liegt darin,dass sie bereits die Verknüpfung einer Reihe wichtiger komponentenspe-zifischer Transaktionen enthalten, sodass ein ganzheitlicher Geschäftspro-zess abgebildet wird. Abbildung 10.1 zeigt das Beispiel der Transaktions-abfolge eines typischen Geschäftsprozesses, wie er im Benchmark-Kit desmySAP CRM Customer Interaction Centers simuliert wird.

� Auch die Auswertung der Daten war äußerst schwierig – letztend-lich musste eine Batch-Datei erstellt werden, um die Inhalte allerProtokolldateien auf den lokalen Festplatten der einzelnen Desk-tops in einer einzigen Datei zu speichern.


Dabei müssen jedoch einige Punkte berücksichtigt werden:

� Weder die Skripte noch die Daten des SAP-Benchmark-Kits könnendirekt verwendet werden. Beide müssen an Ihr individuelles SAP-Sys-tem angepasst werden.

� Benchmark-Kits sind nur für eine relativ beschränkte Anzahl vonLösungen und Transaktionen verfügbar.

� Bei diesem Ansatz wird immer nur eine SAP-Lösung getestet. Füranwendungsübergreifende Geschäftsprozesse stehen keine SAP-Benchmark-Kits zur Verfügung.

10.2.2 Top-10-Ansatz

Am häufigstenausgeführte

Transaktionen

Wie in Abschnitt 9.1.2 beschrieben, können mit Transaktion ST03 imCCMS auf einfache Weise die häufigsten Online-, Batch- und RFC-Trans-aktionen ermittelt werden. Auf dieser Basis können dann Skripte zurSimulation der zehn wichtigsten Geschäftsvorgänge erstellt werden. Bei-ßen Sie sich dabei nicht an der Zahl zehn fest, dieser Wert dient hierlediglich als Richtlinie, vielleicht wird der Großteil Ihrer Systemlast auchvon 15 Transaktionen oder nur acht oder neun verursacht. Erfahrungsge-mäß umfassen die wichtigsten Transaktionen 70 bis 80 % an Online-Transaktionen und 20 bis 30 % an Batch-Jobs.

Es ist klar, dass dieser Ansatz nicht für die Simulation des komplettenGeschäftsprozesses und Lastspektrums geeignet ist, da ja lediglich die amhäufigsten ausgeführten Transaktionen berücksichtigt werden (sieheAbbildung 10.2). So wird zum Beispiel die Verarbeitung eines Kundenauf-trags mit Kommissionierung, Versand, Fakturierung und Zahlungseingang

Abbildung 10.1 Mögliche Transaktionsabfolge im mySAP CRM Interaction Center

Performance-Testing-Ausgabe(Reaktionszeiten, Durchsatz,

Bestätigungen, Probleme usw.)

CIC-Bildschirmladen

Material usw.bestätigen

mySAP CRM Interaction Center Benchmark 4.0

Aufruf beantworten

Geschäftsprozess bestätigen

Histor. Geschäfts-prozess-Daten

abrufen

219Praxistaugliche Ansätze

nicht vollständig simuliert. Trotzdem ist in der Praxis die Simulation derTransaktionen mit dem größten Aktivitätsvolumen (bei Sortierung nachDialogschritten) oder der größten Systemlast (bei Sortierung nach Daten-bank- oder CPU-Zeit) eine einfache und effektive Methode, um eineerforderliche realistische Verarbeitungslast zu generieren.

10.2.3 Nutzung des SAP Batch Schedulers

Eines nach dem anderen

Eine Möglichkeit, mit SAP-Bordmitteln realitätsnahe Lastprofile zu gene-rieren, bietet der SAP Batch Scheduler. Dabei dienen die TransaktionenSM36 und SM37 zum Definieren und Freigeben von Batch-Jobs, Transak-tion SM64 zum Definieren von Triggern und SE38 zum Ausführen mehre-rer Reports. Zum Steuern der Ausführung der Testläufe kann das Pro-gramm sapevt wie ein normaler ABAP-Report genutzt werden. DieAusführung externer Befehle ist mit sapxpg möglich. Auf diese Weise lässtsich ein komplexer Last-Test mithilfe weniger Skripte steuern, wobei jederabgearbeitete Job bzw. jedes Skript den nächsten auslöst. Mit dieserMethode können relativ einfach realitätsnahe komplexe Lastszenarienreproduzierbar generiert werden, bei denen Batch-Jobs bei bestimmtenexternen Ereignissen ausgelöst werden.

Mit geeigneten Skripten kann der Statuscode überprüft und damit zumBeispiel festgelegt werden, dass ein Batch-Job so lange gestartet wird, bisein vollständiger Satz Testskripte ausgeführt wurde. Für das Scripting istlediglich Transaktion SM37 erforderlich.

Abbildung 10.2 CCMS-Anzeige der Last auf einem SAP-Datenbankserver


10.2.4 Skripte für das Grundrauschen

Anzeige vonInformationen

Auch die Verwendung von Noise-Skripten (siehe Abschnitt 9.1.3) ist einehervorragende Testmethode. Am besten eignen sich hierfür Transaktio-nen, bei denen keine Eingabe von Daten notwendig ist, sondern lediglichdie Anzeige von Informationen vom System angefordert wird, wie zumBeispiel Transaktion VA03 (Anzeige von Aufträgen), Transaktion MM03(Anzeige von Materialien), Transaktion PA03 (Anzeige von Mitarbeiterin-formationen), Transaktion MB03 (Anzeige von Material belegen), Trans-aktion ME53 (Anzeige von Bestellanforderungen), Transaktion ME23(Anzeige von Bestellungen) und Transaktion XD03 (Anzeige von Kunden-informationen).

Eine weitere Methode ist zum Beispiel die wiederholte Ausführung vonTransaktion VA01 (Auftragserstellung). Dabei müssen nur beim erstenDurchgang Daten (per Skript) eingegeben werden. Bei erneuter Ausfüh-rung der Transaktion mit dem Parameter »/n« wird die Systemlast inregelmäßigen Schritten reproduzierbar erhöht.

10.2.5 Mandantenkopien

Systemressourcenbeanspruchen

Das Erstellen von Mandantenkopien via Transaktion SCCL oder Mandan-tenexporten über Transaktion SCC8 hat zwar nichts mit dem Ausführeneines Geschäftsprozesses zu tun, kann aber ebenfalls zur Erzeugung einerTestlast »missbraucht« werden, da dabei die Systemressourcen – vorallem des Plattensubsystems – massiv beansprucht werden.

Leistung derNetzwerk-

infrastruktur

Da der Speicherbedarf eines SAP-Mandanten in der Regel die Größe desSchreib-Caches des Plattensubsystems überschreitet, führt die Ausfüh-rung einer Mandantenkopie zu ressourcenintensiven Lese- und Schreib-vorgängen. Damit sind eine Mandantenkopie zum Messen der Leistungeines Plattensubsystems und ein Mandantenexport zum Messen der Leis-tung der Netzwerkinfrastruktur hervorragend geeignet.

Auch die Erstellung eines leeren Mandanten kann eine hohe Last miteiner geringen Menge Eingabedaten generieren. Mandantenkopien sinddementsprechend eine gute Möglichkeit, ein System unter eine reprodu-zierbare Last zu setzen. Allerdings hat diese Last nur wenig mit der tat-sächlichen Nutzung eines SAP-Systems zu tun.

10.3 Vorbereitung von Skripten

Keine leichteSache

Wie das Programmieren umfasst auch das Erstellen von Skripten zurAutomatisierung von Last-Tests eine Reihe von Schritten, zu denen z.B.

221Vorbereitung von Skripten

auch das Beheben von Codierungsfehlern oder die Erstellung von Routi-nen für die Fehlerbehandlung gehört. Die Erstellung von Skripten istkeine triviale Aufgabe. Auch wenn die Geschäftsaktivität, für die dasSkript erstellt werden soll, einfach strukturiert ist, kommt es häufig zuProblemen mit gültigen Datensätzen für die Eingabe. Vor allem Datenfel-der, die nur in einigen Fällen erforderlich sind, oder Eingaben, die Fehler-meldungen, Warnungen oder unerwartete Folgebildschirme auslösen,müssen durch geeignete Routinen abgefangen werden können.

Auch das Aufzeichnen eines Geschäftsprozesses ist nicht immer frei vonFehlern: Das benutzte Scripting-Werkzeug zeichnet unter Umständenbestimmte Bedingungen oder Feldwerte nicht auf. Ebenso kann ein Dop-pelklick an einer bestimmten Position des Cursors während der Aufzeich-nung eines Skripts für einen Geschäftsprozess ein Problem verursachen.Daher ist die erste Fassung eines Skripts meist noch nicht direkt für einenLast-Test einsetzbar. Es müssen z.B. »mitgeschnittene« Eingabewerte wieetwa Vertriebswege, Buchungskreise oder Kundennummern in Variablenumgewandelt werden, die wiederum vom Skript mit gültigen, aberpseudo-zufälligen Werten gefüllt werden müssen. Für diese Variablenmuss zum Beispiel ein gültiger Wertebereich bestimmt werden, der fest-legt, ob es sich um numerische Daten oder Textdaten usw. handelt.

Reaktion des SAP-Systems mitplanen

Das Aufzeichnen des Skripts ist also nur die halbe Miete – das Erfassender einzelnen SAP-Transaktionen, die Tastatureingaben, Mausklicks usw.über das jeweilige Frontend dienen lediglich dem Erstellen einer besserenTextdatei. Das tatsächliche Skript für den Geschäftsprozess wird erstdurch das Hinzufügen der Variablen und der Anweisungen für die Reak-tion auf die diversen möglichen Antworten des SAP-Systems auf dieseEingabedaten komplettiert.

Bevor aber mit dem Schreiben von Code oder dem Aufzeichnen vonGeschäftsprozessen begonnen werden kann, müssen Sie entscheiden, obdie Interaktion mit realen Benutzern berücksichtigt werden muss und wiedie Skripte selbst getestet werden sollen.

10.3.1 Tests mit realen Benutzern

Auch wenn für die Erstellung der erforderlichen Skripte ein gewisser Auf-wand notwendig ist, hat die vollautomatische, »mannlose« Generationder Systembelastung eine ganze Reihe von Vorteilen. Das Scripting machtdie Abarbeitung von Geschäftsprozessen kontrollier- und wiederholbar,da diese stets mit identischen Variablen ausgeführt werden. Fehler wer-den vermieden und die Skripte bilden die einfachste Form der Dokumen-


tation. Aus diesen Gründen spricht praktisch alles für automatisierteTests.

Trotzdem gibt es auch Fälle, in denen eine manuelle Lasterzeugung sinn-voll sein kann. Beispiele sind sehr selten auszuführende Geschäftspro-zesse und das Starten lang laufender Batches, etwa eines MRP-Laufes(Material and Ressource Planning). Hier ist der zeitliche Aufwand für dieErstellung eines Skripts in der Regel höher als die direkte manuelle Aus-führung der Transaktion.

Vorteile realerBenutzer

Weitere Vorteile bestehen darin, dass auch reale Benutzer für einen Testmehrere virtuelle Benutzer simulieren können, da in einem Test ja keine»Bedenkzeit« berücksichtigt werden muss wie im realen Betrieb, bei demdie Benutzer zwischen den Eingaben ja auch einmal darüber nachdenkenmüssen, was sie da eigentlich tun. In der Praxis funktioniert eine solcheMehrfachnutzung der Benutzer nur sehr bedingt, wenn die Eingaben vonTransaktion zu Transaktion realitätsnah variieren sollen.

Reale Benutzer kennen darüber hinaus ihre Geschäftsprozesse in- undauswendig. Dadurch entfällt der Zeitaufwand für das Einarbeiten in dasScripting. Bei unerwarteten Reaktionen des Systems können physischeBenutzer sofort reagieren. Zu guter Letzt werden für Tests mit realenBenutzern keine Werkzeuge benötigt.

Nachteile realerBenutzer

Doch auch die Nachteile von realen Benutzern für Ihre Tests und IhrTuning sollen nicht außer Acht gelassen werden. Für die User bedeutetdie Durchführung von Tests in der Regel zusätzliche Arbeit, für die sie nurschwer zu motivieren sind – auch wenn sich die Mitarbeiter durchausbewusst sind, dass die Tests der störungsfreien, performanten und nor-malen Arbeit dienen. Egal, ob Tests in der normalen Arbeitszeit oder inÜberstunden durchgeführt werden, es entstehen immer Personalkosten.Daher ist es genauso schwer, die Abteilungsleitung – an der in der Regeldiese Kosten hängen bleiben – für einen Test zu motivieren.

Darüber hinaus müssen auch manuelle Testverfahren geplant und koordi-niert werden; es genügt nicht, »kurz in die Abteilung zu gehen« oder»eben mal anzurufen«. Außerdem sind die zur Verfügung stehenden End-benutzer keine Maschinen, machen dementsprechend Fehler und kön-nen nicht – im wahrsten Sinne des Wortes – pausenlos durcharbeiten.

10.3.2 Tests mit virtuellen Benutzern

Sobald die Belastung eines Systems durch hunderte von Benutzern undtausende von Geschäftsprozessen simuliert werden muss, ist daher das

223Vorbereitung von Skripten

Durchführen von Last-Tests mit physischen Mitarbeitern keine realistischeund effektive Methode mehr. Stattdessen muss die Systembelastungdurch virtuelle Benutzer generiert werden.

Kein UnterschiedFür das SAP-System gibt es keinen Unterschied zwischen virtuellen undrealen Benutzern; bei virtuellen SAP GUI-Sitzungen kann in der Regelauch auf das auf einem PC installierte SAP GUI verzichtet werden. DieTestwerkzeuge schreiben stattdessen die »Eingaben« der virtuellenBenutzer über ein API in die entsprechenden Felder des SAP GUI. Das-selbe gilt für die Betätigung von Dropdown-Boxen, Auswahlknöpfenusw., eine Anzeige dieser Elemente ist daher nicht erforderlich.

10.3.3 Infrastruktur für die Entwicklung von Last-Test-Skripten

Qualitätssiche-rungssystem bereitstellen

Auch für die Entwicklung – und paradoxerweise auch für das Testen – derSkripte für Last-Tests muss eine Infrastruktur bereitgestellt werden.Neben dem eigentlichen Entwicklungssystem, für das in der Regel ein gutausgestatteter PC oder eine UNIX-Workstation ausreicht, sollten Sieschon in dieser Phase zumindest ein abgespecktes Qualitätssicherungs-system für Mini-Last-Tests zum Debuggen der einzelnen Skripte zur Ver-fügung stellen (siehe Abbildung 10.3).

Abbildung 10.3 Einfache Infrastruktur für die Entwicklung von Testskripten

Pakete

AutomatischeSkripts

SAP APO

SAP R/3

mySAP CRM

QA-Systeme

Client/Desktop

Lastgenerator

Testtool-Konsole(z.B. AutoController)

Testtool: Virtueller Client

Physisches SAP GUI

Virtuelles SAP GUI

Virtue

lles S

AP GUI


Im einfachsten Fall lässt sich eine solche Umgebung für kleinere Last-Testsaus einigen PCs und kleinen Servern zusammenstellen. Mit einem einzi-gen Vier-Wege-Server können ohne großen Aufwand hunderte virtuelleBenutzer simuliert werden. In Testumgebungen, in denen die Anzeige desSAP GUI erforderlich ist – z.B. zum visuellen Testen der Ausführbarkeitvon Geschäftsprozessen, bevor diese im virtuellen Modus ohne Frontendausgeführt werden, oder zum Ausführen von Geschäftsprozessen aufmySAP-Komponenten, auf denen das SAP GUI nicht ausgeblendet wer-den kann –, können mit VMware oder Citrix mehrere Clients auf einemRechner emuliert werden.

10.4 Praxistipps für die Skripterstellung

Templates helfen Wie bei jeder Programmentwicklung empfiehlt sich auch bei der Erstel-lung der Last-Test-Skripte die Verwendung von Vorlagen (Templates).Dabei sollten Sie die folgenden Punkte berücksichtigen:

� Nutzen Sie die Möglichkeit, Nachrichten mit Informationen zumAblauf des Skripts anzeigen zu lassen (z.B. aktuell verarbeitete Daten,berechnete Ergebnisse, Fehlermeldungen). Diese Meldungen sindwährend der Skriptentwicklung von enormem Nutzen. Vor dem Aus-führen der Skripte im Rahmen des Last-Tests können Sie diese Meldun-gen dann einfach auskommentieren. Auf diese Weise wird für denAblauf der Skripte Transparenz gewährleistet und Sie behalten denÜberblick über den Verarbeitungsprozess, eventuelle Fehler usw.

� Implementieren Sie Routinen für die Fehlerbehandlung. Dabei sindzwei Fälle zu berücksichtigen: Zur Behandlung kleinerer Fehler sollteein Skript implementiert werden, das ein Wiederaufsetzen der Skript-ausführung von einem bestimmten Checkpoint aus ermöglicht. Fürschwere Fehler wird ein Skript benötigt, das die Verbindung mit demvirtuellen SAP GUI trennt und ein Fehlerprotokoll erstellt.

� Nutzen Sie ein Standardverfahren für die Eingabe von Daten. Dazuwerden einfache Textfiles oder Tabellen Zeile für Zeile eingelesen. EineAlternative ist die Erstellung einer Routine, die über einen entspre-chenden Algorithmus Zufallszahlen aus einem zulässigen Wertebereichgeneriert. Im strengen Sinne sollten auch pseudo-zufällig erzeugte Ein-gabedaten gespeichert werden, um den Testlauf wiederholbar zumachen.

� Umgekehrt wird natürlich auch eine Standardmethode zum Erfassender Leistungsparameter benötigt, genauso wie eine Routine, die dieAntwort des Systems auf die Benutzereingaben in einem Ausgabepro-

225Praxistipps für die Skripterstellung

tokoll für den Lauf erfasst. Nutzen Sie die üblichen Verfahren wie If-Then-Bedingungen und Schleifen, um auf Ereignisse zu reagieren(siehe Abbildung 10.4).

� Damit das Skript einen Geschäftsvorgang exakt wiedergibt, müssen Siemit seinem Workflow vertraut sein. Die ideale Quelle für diese Infor-mationen ist der Entwickler, der diesen Prozess codiert und aufgesetzthat. Wenn er nicht verfügbar und keine ausreichende Dokumentationvorhanden ist, sollten Sie Power-User, Abteilungsleiter usw. befragen.

10.4.1 Skripte testen und bearbeiten

Erst testen, …Nach dem Erstellen, aber auch bei der Wiederverwendung eines Skripts,muss dieses getestet werden, um sicherzustellen, dass es überhaupt mitden aktuellen Eingabedaten ausgeführt werden kann. Nicht selten stelltschon dies eine Herausforderung dar. Ein Skript, das früher einmal pro-

Abbildung 10.4 Verknüpfung von Unterprogrammen innerhalb eines Skripts

Ausgabe-daten

Eingabe-daten

Anmeldung am SAP-System

Definition von Variablen

und Zählern

J/N

Ausführung desHauptskripts

(VA01)

Ermittlung von Statistiken und

Performance-Daten

J/N

Erhöhung derVariablen- und

Zählerwerte

Bedingungenprotokollieren,

Dateien schließenund vom

SAP-Systemabmelden

Hauptteildes

Skripts

Protokoll


blemlos mit den bereitgestellten Daten ausgeführt wurde, kann nachKonfigurationsänderungen oder der Installation von Support-Packagesnicht mehr laufen. Das Gleiche gilt auch für die Daten.

… dannbearbeiten

Wenn Skripte durch das Aufzeichnen von Benutzeraktionen erzeugt wer-den, müssen diese in der Regel für den Einsatz nachbearbeitet werden.Denn selbst mit den besseren Werkzeugen für das Aufzeichnen werdenmeist nicht sämtliche Eingaben über Tastatur und Maus durch die ent-sprechenden SAP-Befehle ersetzt, die das spätere Ausführen des jeweili-gen Skripts im virtuellen Modus ermöglichen.

Mit dem AT1-Tool wird das Ausführen der Skripte im virtuellen Modusz.B. über den Befehl SapSetDirectMode On eingestellt. Anschließendmüssen Befehle wie Type durch SAP-spezifische Befehle wie SapInput-FieldValue oder SAPSendKey ersetzt werden. Um die Antwort desSAP-Systems, z.B. das Anzeigen der erfolgreichen Verarbeitung eines Auf-trags, von Fehlermeldungen oder Warnungen, aufzuzeichnen, müssenBefehle wie SapRetrieveEntireMessage (zum Aufzeichnen der ge-samten Nachricht als Protokoll für die Ausgabedatei) und SapRetrieve-MessageSegment '1' (zum Aufzeichnen des ersten Teils einer Nachrichtwie z.B. der Bestellnummer) hinzugefügt werden.

Korrekte Daten-beschaffung

Der nächste Schritt umfasst die Datenbeschaffung. Dafür sind Kenntnisseder den Transaktionen zugrunde liegenden Geschäftsabläufe unabding-bar. Das Wissen, dass beispielsweise bestimmte Teile nur von bestimmtenKunden bestellt werden können oder bestimmte Materialien nurbestimmten Fabriken, Werken oder Lagern zugeordnet sind, ist Grund-voraussetzung für die Ermittlung gültiger Datenkombinationen. Auch hiersollten die Entwickler und Power-User Ihre ersten Quellen für Informati-onen über die gültigen Wertebereiche sein.

10.4.2 Skript für die Erfassung der Daten und Statistiken

Transaktion FB03 Um die essenziellen Daten zu erfassen, können neben den verschiedenenin den vorangegangenen Kapiteln beschriebenen Tools und Manage-ment-Applikationen auch Bordmittel eines Skriptes genutzt werden. Dasfolgende Beispiel zeigt ein solches Ausgabeskript zum Erfassen und Pro-tokollieren der Ausgabedaten der einfachen Transaktion FB03:

Assign RESULTS.SCREEN = "FB03-Display Document "Assign RESULTS.OUTPUT = FI.FB03INPUTDOCAssign FI.OUTPUT = $MACHINEAssign FI.OUTPUT = FI.OUTPUT + ", "


Assign FI.OUTPUT = FI.OUTPUT + $TESTCASEIDAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + LOGIN.SAPSERVERAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + RESULTS.SCREENAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + $RUNNAMEAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + $DATEAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + LOGIN.STRTTIMEAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + LOGIN.STOPTIMEAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + FI.RESPONSEAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + RESULTS.OUTPUTAssign FI.OUTPUT = FI.OUTPUT + ", "Assign FI.OUTPUT = FI.OUTPUT + RESULTS.ERRORLog "s:\ATWCS\outputFI.txt" FI.OUTPUT

Listing 10.1 Ausgabeskript zur Erfassung der Ausgabedaten für Transaktion FB03

Zusätzliche Sicherung

Mit diesem Skript werden alle Ausgabedaten in einem einzigen Reposi-tory gespeichert. Für die Erfassung zusätzlicher Daten muss am Ende derListe ein weiterer alphanumerischer String hinzugefügt werden. DasSkript kann auch als Sicherung zusätzlich zu anderen Monitoring-Toolsdienen.

Auch die verschiedenen CCMS-Transaktionen können in Skripten ver-wendet werden. Vor allem die schon erwähnten Transaktionen ST07 undAL08 zur Erstellung von Statistiken sind dabei recht nützlich. Die CCMS-Transaktion ST03 eignet sich vor allem in Verbindung mit SM51 zumErfassen von Reaktionszeiten und Durchsatz einzelner Anwendungsser-ver. Über Transaktion SM51 wird ein bestimmter Anwendungsserver aus-gewählt (z.B. der Server an erster Stelle in der Liste). Anschließend wirdTransaktion ST03 ausgeführt, um die durchschnittliche Reaktions-, Wait-,Load-, Enqueue-, Roll- und Datenbankabfragezeit zu erfassen. Danachwird SM51 zur Auswahl des nächsten Anwendungsservers in der Listeausgeführt.


10.4.3 Skript für das SAPLOGIN

Eine naturgemäß recht häufig benutzte Routine ist ein Skript für das SAP-LOGIN der virtuellen Benutzer. Wenn Sie das Skript an die unterschiedli-chen Anmeldeanforderungen anpassen wollen, kann es recht umfang-reich werden, um Unterstützung für alle Funktionen zu bieten.

Anmeldung amSAP-System

Dabei werden sämtliche server- und anmeldegruppenspezifischen Datenals Variablen in SAPLOGIN definiert. Damit kann dann gesteuert werden,wie sich ein virtueller Benutzer an einem SAP-System anmeldet. DieHauptfunktion dieses Skripts entspricht dem Ausführen des Befehls

SapEstablishSession "server_name" "instance" "front",

wobei "server_name" der Variablenname des Anwendungsservers oderder Zentralinstanz ist, "instance" die Instanz-ID-Variable (z.B. »00«),und "front" das Skript anweist, das SAP GUI-Bild anzuzeigen (und nichtauszublenden). Wenn zum Beispiel eine virtuelle Verbindung zu einerSAP-Anmeldegruppe namens »MARKETING« hergestellt werden soll,wird an SAPLOGIN

SapLoadEstablishSession "TST" "message_server_ name""/H/" "MARKETING" front groupconnect

übergeben. In diesem Fall führt "front" dazu, dass das SAP GUI im Vor-dergrund ausgeführt wird, sodass der SAP GUI-Bildschirm bei Ausführungeines Skripts angezeigt wird. In neueren Versionen des SAP GUI API desSAP Web Application Servers ist diese Funktion erforderlich, da die Aus-führung im virtuellen Modus im Hintergrund nicht möglich ist.

WeitererAnmeldeprozess

Eine weitere wichtige Codezeile im SAPLOGIN gibt Auskunft über Client,Benutzer-ID, Kennwort und Sprache für die Anmeldung am richtigenSAP-Anwendungsserver oder der richtigen Anmeldegruppe. Nach demErstellen einer Sitzung auf dem zu testenden SAP-System kann der wei-tere Anmeldeprozess über einen Skriptbefehl wie z.B.

SapLogin "020" "anderson" "pass" "E"

automatisiert werden. Dabei beschreibt "020" den Client, "anderson"ist die für diesen Client festgelegte Benutzer-ID und "E" legt Englisch alsSprache fest. Ihr Kennwort kann entweder verschlüsselt oder als Klartextgespeichert werden; in oben stehendem Beispiel lautet das Kennwort imKlartext schlicht "pass".

Screen-Scraping Das Skript zum Start einer SAP-Sitzung bietet nicht nur Unterstützung fürvirtuelle Benutzer, sondern ermöglicht darüber hinaus auch das Screen-


Scraping: Fehlermeldungen, Werte für Auswahlknöpfe, Feldinhalte,Namen für bestimmte Bilder usw. können über das SAP GUI abgerufenwerden, weil eine Sitzung mit einem virtuellen Benutzer erstellt wurde.Wenn während der Ausführung einer Transaktion eine bestimmte Warn-meldung angezeigt wird oder eine unvorhergesehene Bedingung dieAnzeige eines unerwarteten SAP GUI-Bildes auslöst, kann das Skript z.B.eine Fehlerroutine aufrufen, das Schreiben von Daten in eine Protokollda-tei veranlassen, ein bestimmtes Unterprogramm oder das Skript beenden,die SAP GUI-Verbindung trennen usw.

10.4.4 Zeitversetzte Anmeldung am SAP GUI

Auch virtuelle User sollten sich nicht aufhängen

Das automatische Anmelden vieler hunderter virtueller Benutzer istebenfalls keine triviale Aufgabe. Wenn das Skript alle Benutzer praktischzur selben Zeit am System anmeldet, besteht das Risiko, dass aufgrunddes massiven Ressourcenbedarfs das System streikt. Um eine erfolgreicheAnmeldung sämtlicher Benutzer sicherzustellen, müssen die Anmelde-vorgänge daher zeitversetzt ausgeführt werden. Bei den SAP-Benchmark-Kits wird zum Beispiel jede Sekunde ein neuer Benutzer angemeldet.

AnmeldestatusVor dem Aufbau einer Verbindung ist es zudem empfehlenswert, denAnmeldestatus des virtuellen SAP-Benutzers zu überprüfen. Der Anmel-destatus wird über den Wert von $SAP_SESSION ermittelt. Der Wert »0«bedeutet, dass noch keine Verbindung erstellt wurde. In diesem Fall wirddas Skript zur Anmeldung ausgeführt.

Als Nächstes muss der Wert der Systemvariable $MACHINE auf den Wert»Machine« überprüft werden. Wenn diese Variable einen anderen Wertals »Machine« aufweist, wird ein Skript z.B. über AutoController ausge-führt. Wenn der Wert dieser Variable auf »Machine« gesetzt ist, heißt das,dass gerade kein Last-Test ausgeführt wird und demzufolge auch keineAnmeldung erforderlich ist. Wird jedoch ein anderer Wert als »Machine«ausgegeben, kann dieser für das SAPLOGIN genutzt werden.

So könnten z.B. mit dem Befehl $MACHINE 17 2 LOGIN.COUNTERTXTdie letzten beiden Zeichen im Namen des virtuellen Clients extrahiertund in einer Variable gespeichert werden. Wenn Sie AutoController mit»HPS« als Name des virtuellen Clients installiert haben, würde der voll-ständige Name des virtuellen Clients 321 wie folgt lauten:»HPS.VIRT.USER.0321«. Durch den Parameter »17 2« werden die beidenletzten Zeichen (»21«) extrahiert. »16 3« extrahiert die letzten drei Zei-chen (»321«). Dabei werden die Zeichen von links nach rechts extrahiert.Die erste Zahl des Befehls gibt die Anfangsposition an, ab welcher die


durch die zweite Zahl benannten Zeichen extrahiert werden. Da es sichum alphanumerische Zeichen handelt, wird dem Wert eine Textvariablewie LOGIN.COUNTERTXT zugewiesen.

Durchführung vonBerechnungen

Nach der Zuweisung der Textvariablendatei können die Daten beliebiggeändert werden, auch das Konvertieren in einen numerischen Wert istmöglich. Damit können dann Berechnungen durchgeführt werden, wiedas folgende Codebeispiel zeigt:

Assign LOGIN.COUNTER = LOGIN.COUNTERTXTMessage LOGIN.DELAY wait 1Delay LOGIN.COUNTER

Listing 10.2 Konvertierung in numerische Werte

Bei der Variable LOGIN.COUNTER handelt es sich um einen numerischenWert, der zu Vergleichsoperationen, als Anfangswert für einen Count-down oder wie in oben stehendem Beispiel als einfacher Delay-Befehlverwendet werden kann. Der Message-Befehl ist optional und dientlediglich dazu, während dem Erstellen und Testen des Skripts zu überprü-fen, ob das SAPLOGIN-Unterprogramm für die Anmeldung auch erwar-tungsgemäß funktioniert. In der finalen Version des Skripts für den Last-Test wird diese Zeile aus zwei Gründen auskommentiert: Zum einen, weildie Funktion nicht benötigt wird, und zum anderen, da sie eine relativhohe Last auf dem Client verursacht.

Beachten Sie, dass bei einer zeitversetzten Benutzeranmeldung für bei-spielsweise 600 virtuelle Benutzer in einem Abstand von jeweils einerSekunde mindestens zehn Minuten vergehen, bis alle Benutzer ihrer vir-tuellen Tätigkeit nachgehen.

10.4.5 Weitere Tipps und Tricks

Auf exakteZeichen achten

Zum Trennen der verschiedenen Datenpunkte ist es bei der Ablage ineiner Tabelle empfehlenswert, Tabulator- oder andere Zeichen anstellevon Kommas zu verwenden, damit beim Import keine Verwechslungenmit echten Kommas in Zahlenwerten entstehen. Sie können das Ausga-beprotokoll aber auch direkt in ein Excelsheet exportieren.

Wenn das verwendete Scripting-Werkzeug nicht über ein SAP API ver-fügt, sollten – wenn möglich – Tastaturbefehle anstelle von Mausklicks imSkript verwendet werden. Bei simulierten Eingaben über die Tastaturerhalten Sie meist ein zuverlässigeres Skript als beim Mauseingaben. Lei-der wird die Tastenkombination Strg-S zum Speichern der Transaktions-


ergebnisse im virtuellen Modus von AT1 unter neueren Versionen desR/3-Systems nicht unterstützt; der alte Kurzbefehl F11 funktioniertjedoch noch immer.

Keine Elemente erstellen oder verändern

Wenn in einem Last-Test nicht die Belastung der Datenbank und des Plat-tensubsystems im Vordergrund steht, wie zum Beispiel bei Tests zumErmitteln der Netzwerklast, ist es sinnvoll, keine Transaktionen auszufüh-ren, mit denen Elemente erstellt oder verändert werden. Dadurch wirddie Datenbank nicht modifiziert und muss auch nicht vor jedem Testlaufauf denselben definierten Zustand zurückgesetzt werden. Bei Testläufen,für die dieser Ansatz nicht geeignet ist, wird ein schnelles Verfahren zumZurücksetzten der Datenbank zwischen den Testläufen benötigt. Andern-falls liefern die Testläufe keine zuverlässigen Vergleiche. Bei modernenPlattensubsystemen stellt der Einsatz von Klonen oder Business Continu-ity-Funktionen eine geeignete Möglichkeit dar, um eine Kopie der Daten-bank zu erstellen und diese immer wieder auf einen definierten Zustandzurückzusetzen.

Pseudo-zufällige Eingabewerte

Neben den Programmen zur Generierung zufälliger Eingabedaten, die imLieferumfang verschiedener Werkzeuge für Last-Tests enthalten sind,empfiehlt es sich, über einen eigenen Prozess für pseudo-zufällige Einga-bewerte zu verfügen. Einige dieser Werkzeuge generieren wirklich echteZufallszahlen, bei anderen wiederholen sich die Zahlenfolgen nach einergewissen Zeit. Eine Möglichkeit ist hier die beliebte Methode, Eingabe-werte aus Seriennummern und anderen sich ständig verändernden Wer-ten zu berechnen. Beispiele für solche Werte sind neben der Nummerdes virtuellen Clients die Werte für Datum und Uhrzeit.

Uhrzeit nutzenFür einen weiteren nützlichen Trick wird die Sekundenzahl der aktuellenUhrzeit (00–59) genutzt, um das Ausführen einer Reihe verschiedenerTransaktionen auszulösen. Wenn beispielsweise in 10 % aller Fälle Trans-aktion FD32 und in 30 % Transaktion VA03 ausgeführt werden soll, wür-den die Befehle

if time = 00 through 05, then execute transaction FD32

(entspricht 6 von 60 Möglichkeiten und somit 10 %) und

if time = 06 through 23, then execute transaction VA03

(entspricht 18 von 60 Möglichkeiten und somit 30 %) genügen, um dasSkript entsprechend zu steuern.

Um zu gewährleisten, dass eine bestimmte Anzahl eines Skripts innerhalbeines bestimmten Zeitraums ausgeführt wird, können Sie eine weitere


Methode verwenden, die auf der Uhrzeit basiert. Wenn z.B. TransaktionMB1C für die Eingabe von Wareneingängen und den Transport einer Lie-ferung von einem Ort an einen anderen 1.200-mal pro Stunde ausgeführtund anschließend ein Transportauftrag (Transaktion LT06) erstellt werdensoll, dann entspricht dies 20 MB1C/LT06-Geschäftsprozessen proMinute. Gehen wir davon aus, dass MC1C und LT06 auch bei Spitzenlastinnerhalb von 60 Sekunden ausgeführt werden können – die typischeZeit liegt bei etwa zehn Sekunden –, so werden folglich 20 virtuelleBenutzer benötigt, die jeweils einmal pro Minute die TransaktionenMB1C und LT06 ausführen, um das Kriterium von 1.200 Ausführungenpro Stunde zu erfüllen.

Wenn vor dem Ausführen der Transaktionen durch einen virtuellenBenutzer die Minuten- und Sekundenzähler (Systemvariablen) erfasstwerden, können diese Werte dazu genutzt werden, um exakt zu steuern,wann die Transaktionen MB1C und LT06 erneut ausgeführt werden.Wenn beispielsweise die Transaktion MB1C um 10:33:21 Uhr zum erstenMal gestartet wurde, ermittelt eine Schleife, wann der Wert 21 (oder einhöherer Wert, für den Fall, dass der Zeitpunkt verpasst wurde) dasnächste Mal im Sekundenzähler angezeigt wird. Das Skript wartetdadurch so lange, bis der Wert 21 erneut erreicht wird, und führt dannMB1C und anschließend LT06 erneut aus.

Wenn die Steuerung granularer erfolgen soll, können sowohl der Minu-ten- als auch der Sekundenzähler genutzt werden, um alle 2, 4 oder nSekunden einen neuen Geschäftsprozess zu starten. Die Startzeit derSkripte für die einzelnen virtuellen Benutzer sollte zeitversetzt mit einemAbstand von einer Minute gewählt werden.

10.4.6 Regelmäßige Kommunikation

Status desScriptings

Eine regelmäßige und gut funktionierende Kommunikation zwischen denTeammitgliedern ist für jedes Projekt von Vorteil, das Scripting von SAP-Geschäftsvorgängen stellt hier keine Ausnahme dar. Insbesondere beieiner neuen SAP-Implementierung oder im Rahmen einer geplantenAktualisierung ändert sich häufig eine Reihe von Faktoren innerhalbweniger Tage, die das Scripting beeinflussen. Daher sollte zweimal proWoche in kurzen Meetings der Status des Scriptings im SAP-Team erörtertwerden. Wichtig sind dabei folgende Punkte:

� Überprüfen der Geschäftsvorgänge oder -prozesse

� Status der Skripte für die Geschäftsprozesse

233Standard-Subroutinen für Last-Tests

� Status der Eingabedatensätze

� Status von Fehlerroutinen

� Ausgabemethode

Da es sich um die zu testenden Geschäftsprozesse handelt, sollten auchdie Verantwortlichen für die Geschäftsprozesse selbst an diesen Meetingsteilnehmen. Bei Projekten mit einer Dauer von mehr als einem Monatsollte auch der Projektsponsor ungefähr alle zwei Wochen an diesenMeetings teilnehmen. Auch bereits beim »Vortesten« der Skripte ent-deckte Auswirkungen von Änderungen – wenn zum Beispiel kritischeStamm- oder Konfigurationsdaten auf einem Client gelöscht wurden –sollten während solcher Meetings thematisiert werden.

10.4.7 Utility-Skripte

ServiceUm Ihnen die Arbeit bei der Erstellung der Skripte zu erleichtern, findenSie in Anhang A dieses Buches eine Reihe häufig benötigter Funktionensowie kleine Hilfsroutinen. Diese Utility-Skripte sind für AutoController inAT1 geschrieben, sie sind aber auch eine ausgezeichnete Vorlage für dasErstellen von Skripten für andere Scripting-Werkzeuge oder Last-Test-Pro-gramme und lassen sich einfach an andere Last-Generatoren anpassen.

Diese Musterskripte können Sie auch von der Website zu diesem Buchunter http://www.sap-press.de herunterladen.

10.5 Standard-Subroutinen für Last-Tests

Wie bereits weiter oben diskutiert, ist es sinnvoll, für in Testszenarienimmer wieder benötigte Routineprozesse auch entsprechende Skript-routinen zu erstellen. Beispiele dafür sind z.B. Skripte für das Starteneiner SAP GUI-Sitzung oder zum Öffnen von Eingabedateien. Hinzu kom-men noch spezielle Skripte, die zum Beispiel spezifische Datums- undKalenderkombinationen berücksichtigen (siehe Abbildung 10.5).

10.5.1 Variablen und Eingabedaten

Skripte müssen in der Regel nicht nur nachbearbeitet werden, um dieEingaben über Tastatur und Maus durch die entsprechenden SAP-Befehlezu ersetzen, sondern auch, um diese Variablen mit den jeweiligen Wertenzu versorgen. Da das Umwandeln von Skriptzeilen von fest programmier-ten Eingabedaten in Variablen sehr aufwändig sein kann, ist es ratsam,hierfür ein Standardskript zu erstellen.

357Index

Index

AActive Directory 178Adaptive Computing 52, 53AGate 192ALE � Application Link EnablingAllocation Unit 56Anmeldelast 71Anmelden, automatisches 229Anmeldestatus 229Antwortzeit 91, 285

am Anwendungsserver 210end-to-end 210

Anwendersicht 92Application Link Enabling 46, 216Application Service Providers 53Application Stress Test 101Arbeitslast 196, 245, 285, 299, 327

repräsentative 196Arbeitslast-Baselining 201Arbeitsvolumen 103Arbitrated Loop 187ARIS 330Assemble-to-Order 146Ausfallsicherheit 93Ausfallzeiten 319Ausführungsfenster 69Automatisierung 215Available to Promise 68

BBandsicherung 140, 257BAPI 145Baseline 51, 56, 97, 103, 118, 122, 166,

174, 200, 253, 255, 297, 302, 330Arbeitslast 201Definition 103einfrieren 190erfassen 187für Testkombinationen 200Gründe für die Erstellung 103Konfiguration 103Typen 103

Basis Components 68Batch-Jobs 273Batch-Prozesse 69, 210

Batch-Transaktionen 218Batch-Verarbeitung 40, 69Belastungstest 49Benchmark 55, 141

Definition 55Eigenschaften 55Three-Tier 100Two-Tier 100

Benchmark Driver 102Benchmark-Kits 98, 217

SAP 217Benchmark-Tests 50, 129Benutzer 71

gleichzeitige 71implementieren 240parallele 71reale 222virtuelle 102, 260

Benutzerzahl, Steuerung 198Berechnungen, durchführen 230Bericht 73Beta-Server 308Betriebssystem 151, 269, 309

Releasewechsel 121Testkombinationen 204

Betriebssystemmonitor 283, 284Betriebssystemstatistiken 272Betriebssystem-Tools 174BIOS 308Blockaden 95BroadVision 130Buffer-Gets 302Business Continuity 321Business Continuity Volumes 258Business-Sandbox-System 87

CCache 202Call 280Campus Cluster 322Capacity on Demand 52, 186CATT 152CCMon � Cluster Consistency

Monitor

Index358

CCMS 69, 152, 158, 209, 219, 248, 260, 328

Central Monitoring System (CEN) 160, 161Merkmale 161

Change-Management 112, 113, 119, 207, 271, 295strategisches 120taktisches 119Team 119

CIF-Queue 48Client-Emulation

Installation 242Konfiguration 243

Clients 298Client-Umgebung 240Cluster Consistency Monitor 173, 321Cluster-Konsitenz 174Codierungsfehler, beheben 221COD-Modelle 52, 53Cold Fusion 130Collaborative PLM 79Competence Center 309, 329Composite Application Framework

83, 329Composite Applications 83, 118, 213Computer Aided Test Tool 152Computer Telephony Integration 77Computing Center Management

System � CCMSConsultans, externe 115Content Management 71Continental Cluster 322Controlling 68CORBA 133CPU 272, 284, 308

Leistung 318Nutzung 209Status 171

Customizing 91

DDatei- und Druckserver 187Daten

aufbereiten 287, 289Datenanalyse 271Datenbank 192, 257, 269, 323

Konfiguration 205

Performance 275Releasewechsel 120Testkombination 205Tuning 302zurücksetzen 190, 256

Datenbank-Commits 286Datenbankleistung 276Datenbankmonitor 275Datenbankreplikation 323Datenbanksystem 273Datenbeschaffung 209, 226Datenerforschung 73Datengrundlage 209Datenhydrant 322Deltatest 97Desaster Recovery 321

Konzepte 313System 88

Desktop Management Interface 170Development System 84Diagramme 293Disk Queue Length 204Distributed Common Object Model

149DNS-Server 187Dokumentation 253

Daten-Repository 189Dokumentationswerkzeuge 163Domain Name Service 131, 178Downtime 314DSAG 117, 127Durchsatz 91Dynamic Linked Library 143

EEasyScripts 150eCATT 112, 152eCATT Argument Container 148ECC-Memory 316Einfrieren, Testplattform 245Eingabeblockaden 237Eingabedatei, Ende 237Eingabedaten 233, 254Eingabewerte, pseudo-zufällige 236Einschränkungen 42Electronic Data Interchange (EDI) 216Endlosschleife 267

359Index

Engpässe 54Enterprise Java Beans 151Enterprise Management Applications

180Enterprise Services Architecture 118,

329, 332Enterprise-Management 180Entmilitarisierte Zone 63Entwicklungssystem 86Erfolgskriterien 103Execution Thread Count 140Execution-Threads 204Executive User 73Extensible Markup Language 46

FFailover 319Failover-Cluster 173, 318, 320Failover-Test 318, 322Fat Tree 301Feedback-Netzwerk 123Fehlerbehandlung 221, 224Fehlerquellen, ausschließen 42File Replication Service 178Finanzen 68Five-Nines-Availability 27Footprint 149Frontend-Client 274Funktionstests 43

GGesamtbetriebskosten 38Geschäftsanforderungen 37Geschäftsprozesse 155, 218, 299, 329

relevante 93testen 147verbundene 199

Grundkomponenten 68Grundrauschen 199, 220, 335

HHardwarekomponenten, Test

einzelner 97Hardwareressourcen 185Hauptspeicher 318Heap-Speicher 265Highend-Benchmark 100

HintergrundaktivitätenBest Practices 199erzeugen 199

Hochverfügbarkeitslösungen 314Host Bus Adapter 298Hyperthreading-Technologie 308

IIDE 308IDES 217Independent Computing Architecture

151InfoCubes 72, 74, 212Information Consumer 73Infrastruktur, hochverfügbare 314Input-Daten 195, 201

Anzahl der Datensätze 202Quantität 202

Instandhaltung 68Instanzenkonsolidierung 70Instanzprofile 306Integrationssystem 85Internet InterORB Protocol 149Internet Transaction Server (ITS) 83Internetanbindung 110IP-Adressen 201ITIL 118, 142, 188, 200, 312IT-Lebenszyklus 43ITSM 118, 142, 188, 200, 312IT-Ziele 90

Merkmale 90iViews 70

JJBuilder 151

KKey Performance Indicators 76Key Solution Characteristics 90Klon 201Knowledge Management 70Konfiguration 298Konsolidierung 38, 70, 310Konsolidierungsprojekte 121

Merger 122technische 122

Konsolidierungsszenarien 121Konvertierung, notwendige 201

Index360

Korrekturen 239Kosteneinsparungen 38, 58Kurz-Dumps 182

LLab-Utilities 176Lagerverwaltung 68LAN 187, 210, 316Lastaufkommen 311Lasterzeugung, automatisieren 215Lastgenerator 187, 245, 298Lastkurve 209Last-Mix 215

zusammenstellen 209Lastpakete 197Last-Test 28, 38, 142, 255, 260, 313, 328,

331Alternativen 50Analyse 271Argumente für 44Aufwand für 45Definition 45Einsatzszenarien 37iterative 295Methoden 97mit realen Benutzern 221mit virtuellen Benutzern 222Phasen 256reproduzierbare 313Überwachung 246, 261Vergleichbarkeit 50Vorbehalte 21, 22Wiederholbarkeit 253

Lastverteilung 63Laufwerkscontroller 308Leistungsüberwachung, CCMS 159Lerneffekte 115Lernerfolge, Best Practices 116Lernkurve 114, 116Lesevorgänge 265liveCache-Server 79, 212loadwc 156Logfiles 137Logical Units 108, 273Logshipping 323Lösungsmerkmale 41, 42, 91Lösungsvisionen 39, 89LUN 300

MManagement-Tools 175Mandantenkopien 220Materialwirtschaft 68MaxDB 305Memory Bus 204Metered Services 52Methodenwechsel 297Microsoft Active Directory 317Microsoft ASP 130Microsoft Excel 271, 287, 291, 337Microsoft Powerpoint 271, 293Microsoft SQL Server 175Middleware 273Mitarbeiterzahl 67Mittagsspitze 208MM-Skripte 243Monitoring-Tools 157, 260, 261

Funktion 157MRP-Lauf 222Multi-Channel Interface-Server 212Multipathing 140Multi-Threaded 244mySAP Business Suite 91mySAP CRM 77, 212

Benchmark-Kit 213Benutzertypen 77Frontend-Clients 78

mySAP CRM Customer Interaction Center 91, 155, 217

mySAP Customer Relationship Mana-gement 314

mySAP PLM 78, 213Geschäftsprozesse 78

mySAP SCM 79, 313Geschäftsprozesse 79

mySAP SRM 80, 155, 213mySAP-Komponenten 330

NNachschubplanung 94Network Attached Storage (NAS) 310Netzwerk, lokales 317Netzwerkinfrastruktur 109, 220

Änderungen 121Netzwerklast 231Neustart 259

361Index

Noise-Skripte 199, 200, 210, 220Notrechenzentrum 321

OODS-Objekt 72OLAP 108OLAP-Analyse 73OLAP-Systeme 47, 136OLTP 108OLTP-Systeme 46, 136One-Stop-Anbieter 35Online-Transaktionen 218Open Database Connectivity 149Operational Data Store 191Operationen 203Oracle 175Oracle 9iRAC 138Order-to-Cash 146Outsourcing 20Overhead 149

PPage-in 205Paging 272Paging Daemon Scan Rate 171Parallel active 68Parallel logged on 68PA-RISC 326partitionierbare Systeme 53Pay-per-use 52Performance-Log 274Performance-Management 170Performance-Optimierung 40Performance-Tests, Arten von 49Performance-Tuning 28, 51, 142, 295,

313, 331allgemeine Ziele 39Vorbehalte 21

periphere Geräte 176Persistent Staging Area 191Personal Information Manager 156Pilotieren 126Pilotierung 349

Grundsätze 128Plant Maintenance 68Plattensubsystem 109, 134, 202, 272,

276, 300Infrastruktur 191

Leistung 108Messkriterien 108Testkombinationen 204Tools 170

Postrun-Analyse 296Power User 73Pre-Tuning 98, 191Proaktives Testen 329Produktionsplanung 68Produktionssystem 88Profilparameter 283, 305Programmpuffer 279Projektplanvorlage 95, 97Projektsystem 68Projektziele 111Proof-of-concept-Test 101Pufferanforderungen 265

QQualitätssicherungssystem 86, 186Quality Assurance System (QA) 84Query-Typen 73Queue-Depth 136

RRAID-1 204RAID-1-Konfiguration 257RAID-5 204RAID-Controller 308RAID-Konfiguration 301RAID-Technologie 316Rapid Deployment 53Read-Only-Kopie 257Reaktionszeiten 29, 106, 237Reale Benutzer

Nachteile 222Vorteile 222

Recovery-Profile 324Referenzkunden 117Releasewechsel 121, 122, 311Remote Function Call 46Replenishment 94Reports 68Request 280Requisite BugsEye 80Requisite eMerge 80Return on Information 58Return on Investment (ROI) 57

Index362

RFC-Request 263RFC-Transaktionen 218RFC-Verbindungen 250RSRCATTTRACE 154RSRTRACE 154Run Queue 171

SSales & Distribution 68SAN 187, 300, 310, 316SAN Management Appliances 171Sandbox-System 185, 330

technisches 87SAN-Fabric-Konfiguration 301SAN-Laufwerkscontroller 301SAP APO 212SAP Application Benchmark Perfor-

mance Standard (SAPS) 92, 99SAP Batch Scheduler 219SAP Bidding Engine 213SAP BW 35, 47, 72, 153

Benutzertypen 73Testszenarien 74

SAP CCMS 153, 274, 288SAP CCMS Alert Monitor 263SAP CCMS Monitors for Optional

Components 160SAP Competence Center 116SAP DB 305SAP Development Workbench 62SAP eCATT 148SAP Enterprise Buyer Professional 213SAP Enterprise Portal 35, 47, 70, 155,

213SAP ERP Central Component 46, 67,

162SAP Exchange Infrastructure 35, 64,

81, 214, 216, 273SAP GUI 143, 146, 153, 210, 216, 223,

274, 289, 306, 334Installation 242zeitversetzte Anmeldung 229

SAP GUI Scripting 152SAP IPC 77SAP ITS 83, 214SAP ITS AGate 192SAP ITS WGate 193SAP Master Data Management 35, 64

SAP Mobile Infrastructure 35SAP NetWeaver 35, 64, 65, 91, 216, 273SAP R/3 67, 212SAP SEM 76, 153, 212

Szenarien 76SAP Solution Manager 161SAP Supplier Self-Services 213SAP Transport Management System 62SAP Web Application Server 62, 84,

228, 288Architektur 64

SAP XI Integration Server 82SAP-Anwendungsebene 192, 273SAP-Anwendungsserver 205SAP-Basis 62SAP-Benchmark-Kits 155SAP-Instanz 269SAPLOGIN 228SAPMSG.ini 242Saposcol-Daemon 158SAPS 327SAP-System 299

Besonderheiten 20Upgrade 311

SAP-Systemlandschaft 70, 85, 125SAP-Technologie 272SAP-Upgrade 27Scale-out-Skalierbarkeit 326Scale-up-Skalierbarkeit 325Schattendatenbank 323Schleifenzähler 267Schnittstellen 273Schulungsmaßnahmen 111Screen-Scraping 228Screenshots 188Scripting-Tools

generische 141, 146SCSI 308, 316SD-Skripte 243Server 305Serverhardware 272

Testkombinationen 203Serverkonsolidierung 305Serverleistung 203Service Level Agreement 28, 29, 45,

61, 107, 111, 113Short Dumps 191Sid-ID 201

363Index

Simple Network Management Protocol 170

Simulationvon Benutzern 215von Kundenaufträgen 236

Single Points of Failure 315Single-Threaded 244Single-Unit-Test 49Single-User-Test 49Sizing-Prozess 327Skalierbarkeit 93, 324

horizontale 326Skinny Tree 300Skript

BASISNOISE 335COMPARE_ROUTINE 338für das SAPLOGIN 228für Geschäftsprozesse 221OUTPUT 347RANDOM_NUMBER_GENE-

RATOR 338READ_EXCEL_INPUT 337REAT_TEXT_INPUT 336SAPGUI_SCREEN_SCRAPE 342SAPLOGIN_STAGGER 333SAPLOGOFF 334ST03 342UNIQUE_NUMBER_GENERATOR

337Skripte

testen 225vorbereiten 220

Skripterstellung, Praxistipps 224Skriptsprachen 142Smoke-Test 48, 250, 328Snap-Ins 170Snapshots 163, 164, 258SolMan � SAP Solution ManagerSolution Manager for Operations 162Speichernutzung 279Speichersubsystem, SAN-basiert 317Speicherverwaltung 279Sperreinträge 276Spitzenlasten 299

saisonal bedingte 208testen 208

Split-Mirror-Technologien 50SPOF � Single Points of Failure

Spurbitdichte 300SQL Server 137SQL-Anweisungen 273, 303SSM Implementation 162SSM Operations 162Staging-System 87Standard Operation Procedure 188Standard-Benchmarks 132Standard-Benchmark-Tests 98Standardisierung 38Standard-Mauszeiger 156Standard-Subroutinen 233Standardverfahren 224Standardwerte 235Statistiken, erfassen 237Steuerungsdateien 191Stoppuhr-Test 104, 106Storage Area Network 110, 300, 309Storage-Arrays 310Storage-Subsysteme 258Stoßzeiten 197Strawman Project Plan 95Stripeset 310Striping 300Stufe-1-Test 97Stufe-2-Test 98Stufe-3-Test 101Subroutinen 233, 236, 243Such- und Klassifizierungs-Engine 70Swap File Page-in Count 171Switches 301System Global Area 303Systemadministration 328Systemänderungen 38Systemdurchsatz 29

messen 107Systemlandschaft 85Systemlasten 245, 254

automatisieren 216testen 207typische 198

Systemleistung, messen 107System-Management-Systeme 329Systemoptimierung 20Systemprüfung 259Systemsicht 91

Index364

TTabelle DD12L 281Tabelle MARA 276Tabelle MSEG 276Tabellen 292Tabellenpuffer 280Teambildung 111Technical Operation Procedure 188Technologieschicht 35Technologie-Update 27Templates 224Temporary-Capacitity-Modell 186Terminal-ID 265Terminate and Stay Resident 156Test- und Tuning-Team 111, 118

langfristig gebildete 114taktische Erkenntnisse 113Zusammensetzung 112

Testdaten, Quantität 94Testeinheit 96Testen

der durchschnittlichen Belastung 49proaktiv 329

Testkombinationen, für technische Komponenten 203

TestmixDefinition 195repräsentativer 195

Testpakete 119, 208testen 244

Testpläne 42überprüfen 239

Testplattform, einfrieren 245Testskripte, entwickeln 223Testsystem 201

Voraussetzungen 241vorbereiten 191

Testszenario 24Testtools

Administrator's Pak 179AppManager 183AssetDB 169AutoController 147, 229, 240, 244,

333AutoIT 143AutoShutdown 180AutoTester ONE Special Edition for

SAP 147, 353

Benchmark Factory 132bstat 175CCMon 321Chariot 133CheckIt 128, 165, 203chkdsk 175Citrix 224Cluster Administrator 175Cluster Consistency Monitor 173Configuration Auditor 166DSview 171e-Load 130estat 175eTimer 180, 266EventComb 178GetConfig 168, 308HPReadData 140Insight for Oracle 176Insight for SAP R/3 176IOgen 138Iometer 139, 204iostat 175IOzone 204Jmeter 131Kriterien zur Auswahl 170LoadRunner 150MeasureWare 173Microsoft Management Console 175Microsoft SQL Profiler 205MonitorIT 165Nbench 139, 203NetBench 131Norton AntiVirus LoadSim 134NTiogen 138OpenLoad 131OpenPath 176OpenSTA 133OpenView Operations 182, 248Patch Manager 166Patrol for SAP Solutions Suite 181PenguinoMeter 139Performance Assessment Tool 140,

350Performance Diagnostic Tool 173Performance Toolbox 173PerfStress 130Perfview 173PrimalScript 144

365Index

Printkey 179PsTools 177QALoad 149QCheck 133QuickTest Professional 150sapevt 219sapxpg 219sar 175Scriptomatic 169SecurePath 176ServerWatch 165Smart Plug-Ins 182Snagit 179SQL Profiler 140, 175SQLIO 135, 204SQLIOStress 136Statspack 175StressTool 131Survey 167, 308SysStress 130Systems Insight Manager 164TablePro 179TestPartner 148, 211Thrasher 129Tivoli Monitoring for Applications

183TxShuttle 145, 179Unicenter Application Management

182UNIX-Betriebssysteme 171Virtual Terminal Display 171vmstat 171VMware 224VMware GSX 24WebBench 131WebLOAD 131Windows Management Instrumen-

tation 169Windows Media Player 134Windows Performance Monitor 174Windows Visual Test 216WinMSD 164WinRunner for R/3 150

Testumgebung 245Testverfahren, automatisierte 215Testversionen 127Testwerkzeuge 125

Auswahl 126

beschaffen 127Kategorien 125Kriterien 126Matrix 349testen 126, 127

Testwoche 251Textkonvertierungs-Assistent 291Three-Tier-Benchmark 49, 100Top-10-Ansatz 218Top-Transaktionen 47, 197Total Cost of Ownership (TCO) 38, 117TPC-C-Benchmark 101tpm-C-Werte 101Tracing 140Tracking 214Trainingssystem 87Transaktion AL08 158, 206, 247, 248,

262, 265, 274Transaktion CICO 155Transaktion DB02 158, 248, 265, 275,

302Transaktion DB05 282, 304Transaktion FB03 226Transaktion FD32 202, 205Transaktion LT06 232Transaktion MB03 220Transaktion MB1C 232Transaktion ME23 220Transaktion ME53 220Transaktion MM03 205, 220Transaktion PA03 220Transaktion RSRT 154Transaktion RZ10 305Transaktion RZ20 161, 260, 263Transaktion SAINT 162Transaktion SCC8 220Transaktion SCCL 220Transaktion SE13 281Transaktion SE38 153, 219Transaktion SM04 158, 247, 265, 274Transaktion SM12 248, 276Transaktion SM13 276Transaktion SM31 248Transaktion SM36 219Transaktion SM37 219Transaktion SM50 248, 266Transaktion SM51 259Transaktion SM59 259

Index366

Transaktion SM64 219Transaktion SM66 247, 248, 262, 266,

274Transaktion ST02 248, 265, 279, 303Transaktion ST03 158, 160, 197, 218,

227, 249, 265, 280, 285, 288, 302, 306, 342

Transaktion ST03G 163, 286Transaktion ST03N 249, 250, 265, 285Transaktion ST04 158, 248, 265, 276,

302, 303Transaktion ST05 305Transaktion ST06 158, 248, 262, 265,

283Transaktion ST07 158, 206, 247, 248,

262, 274, 303Transaktion ST10 281, 304Transaktion ST22 248Transaktion ST30 158Transaktion STAD 264, 280, 289Transaktion STATTRACE 163Transaktion SU53 249Transaktion VA01 146, 155, 220Transaktion VA03 205, 220Transaktion VL01 155Transaktion XD03 220Transaktionen

aufzeichnen 145Ermittlung der häufig ausgeführten

197manuell ausführen 216

Transaktionslast, tägliche 207Transaktionslasten 67Transaktionsmix 45Transaktionssysteme 67TREX 70, 212Two-Tier-Benchmark 100, 101

UÜberwachungswerkzeuge 157

Funktion 157Uhrzeit 231Unicode 63, 83Unification Server 70UNIX, Varianten 172Upgrades, technische 120Utility Computing 53

VVerbuchungsaufträge 277Verfügbarkeit 93, 313, 314, 315Vertrieb 68Verzeichnisdienst-Infrastruktur 187Virenschutz 134Virtuelle Benutzer 102Vision 39Vorlagen 224

WWAN 210WAN-Verbindung, emulieren 211Web Dynpro 84, 210Web GUI 133, 153, 193, 210Web-based Enterprise Management

169, 170WebLogic 130WebSphere 130Weitverkehrsnetzwerke 210Werkzeugkoffer 32WGate 193Wiederholbarkeit, von Last-Tests 253Windows Scripting Host 145Workprozesse 265, 285, 309Write Ahead Logging 137

XxApps 83

ZZeitraum 103Zeitraumanalysen 69Zeitsteuerung 245Zieldefinitionen 39Zielgruppen 292Z-Transaktionen 198Zufallsgenerator 338

Documents

Last-Testing und Performance-Tuning · George W. Anderson, Michael Mißbach Projekthandbuch Last-Testing und Performance-Tuning