Addison Wesley - SAP R3 Systeme Effizient Testen+

Sandini Bib
SAP® R/3®-Systeme effizient testen

Sandini Bib
Edition SAP®
Liane Will, Christiane Hienger, Frank Straßenburg, Rocco Himmer
Administration des SAP-Systems R/3
2. Auflage zum Release 3.x, 1997, ISBN 3-8273-1136-5
Erich Dräger
Projektmanagement mit SAP R/3
1. Auflage, 1998, ISBN 3-8273-1334-1
Mario Pérez, Alexander Hildenbrand, Bernd Matzke, Peter Zencke

Geschäftsprozesse im Internet mit SAP R/3
1. Auflage, 1998, ISBN 3-8273-1358-9
Rüdiger Buck-Emden
Die Technologie des SAP-Systems R/3
4. Auflage zum Release 4.0/4.5, 1998, ISBN 3-8273-1379-1
Thomas Teufel, Jürgen Röhricht, Peter Willems
SAP R/3-Prozeßanalyse mit Knowledge-Maps
1. Auflage, 1999, ISBN 3-8273-1388-0
Bernd Matzke
ABAP/4
3., erweiterte Auflage, 1999, ISBN 3-8273-1553-0
Thomas Teufel, Jürgen Röhricht, Peter Willems

SAP Prozessbibliothek:
SAP Prozesse mit Knowledge Maps analysieren und verstehen
1. Auflage, 2000, ISBN 3-8273-1603-0
SAP Prozesse: Vertrieb und Customer Service
1. Auflage, 2000, ISBN 3-8273-1602-2
SAP Prozesse: Planung, Beschaffung und Produktion
1. Auflage, 2000, ISBN 3-8273-1601-4
SAP Prozesse: Finanzwesen und Controlling
1. Auflage, 2000, ISBN 3-8273-1600-6
Gerhard Oberniedermaier
Vertriebslogistik mit SAP R/3
1. Auflage, 2000, ISBN 3-8273-1610-3
Andreas Berthold, Ulrich Mende, Herbert Schuster

SAP Business Workflow
2., aktualisierte Auflage, 2000, ISBN 3-8273-1687-1
Michael Ullrich
SAP R/3 Der schnelle Einstieg
1. Auflage, 2000, ISBN 3-8273-1646-4
®
Sandini Bib
Marcus Geiß
SAP R/3 -Systeme

® ®
effizient testen
Automatisiertes Testen von

Geschäftsprozessen in R/3®
mit CATT und Mercury
ADDISON-WESLEY
An imprint of Pearson Education
München • Boston • San Francisco • Harlow, England
Don Mills, Ontario • Sydney • Mexico City
Madrid • Amsterdam
Sandini Bib
Die Deutsche Bibliothek – CIP-Einheitsaufnahme
Ein Titeldatensatz für diese Publikation ist bei

Der Deutschen Bibliothek erhältlich
Sämtliche in diesem Buch abgedruckten Abbildungen und Bildschirmabzüge unterliegen dem Urheber-
recht © der SAP AG, Neurottstraße 16, D-69190 Walldorf.
SAP®, R/2®, R/3®, RIVA®, ABAP®, SAPaccess®, SAPmail®, SAPoffice®, SAP-EDI®, SAP Business Workflow®,
SAP EarlyWatch®, SAP ArchiveLink®, R/3 Retail®, ALE/WEB®, SAPTRONIC® sind eingetragene Warenzei-
chen der SAP AG.
Andere Produktnamen werden nur zur Identifikation der Produkte verwendet und können eingetragene
Marken der entsprechenden Hersteller sein.
Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröf-
fentlicht.
Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.
Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen.
Trotzdem können Fehler nicht vollständig ausgeschlossen werden.
Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristi-
sche Verantwortung noch irgendeine Haftung übernehmen.
Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar.
Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektroni-
schen Medien.
Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig.
Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig
auch eingetragene Warenzeichen oder sollten als solche betrachtet werden.
Umwelthinweis:
Dieses Produkt wurde auf chlorfrei gebleichtem Papier gedruckt.
Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus umweltverträglichem und recyclingfähi-
gem PE-Material.
10 9 8 7 6 5 4 3 2 1
02 01 00
ISBN 3-8273-1561-1
© 2000 by Addison Wesley Verlag

ein Imprint der Pearson Education Deutschland GmbH
Martin-Kollar-Straße 10–12, D-81829 München/Germany
Alle Rechte vorbehalten
Einbandgestaltung: Barbara Thoben, Köln

Lektorat: Christian Schneider, cschneider@pearson.de
Korrektorat: Johannes Gerritsen, Emmerich-Elten
Herstellung: Anja Zygalakis, azygalakis@pearson.de
Satz: mediaService, Siegen. Gesetzt aus der Palatino mit FrameMaker
Druck: Bercker Graphischer Betrieb, Kevelaer
Printed in Germany
Sandini Bib
Inhaltsverzeichnis
Geleitwort 9
Vorwort zur zweiten Auflage 13
Vorwort zur ersten Auflage 15
Einleitung 19
Kapitel 1
Einführung in das Testen von Software 27
1.1 Grundlagen der Softwareentwicklung 29
1.2 Vorgehensmodelle der Softwareentwicklung 32
1.3 Qualitätssicherung durch Tests im Rahmen des
Software-Life-Cycle 39
1.4 Debugging 45
1.5 CASE-Werkzeuge 46
1.6 Standardsoftware 52
Kapitel 2
Testumgebung in SAP R/3-Systemen 57
2.1 ABAP/4 Development Workbench 57
Kapitel 3
Das Testwerkzeug CATT – Computer Aided Test Tool 67
3.1 CATT-Historie 67
3.2 Genereller Überblick 68
Kapitel 4
CATT als integrales Element der R/3-Einführung 73
4.1 Das traditionelle SAP-Vorgehensmodell 75
4.2 Der ASAP-Ansatz 97
4.3 Das DSDM-basierte Vorgehensmodell 103
4.4 Fazit 125
5
Sandini Bib
Inhaltsverzeichnis
Kapitel 5
Allgemeine Funktionen von CATT 127
5.1 Einbindung von CATT in die Infrastruktur der R/3-Umgebung 127
5.2 Remote Start 128
5.3 Berechtigungsprüfung 129
5.4 Aufzeichnungsfunktionalität 131
5.5 Expertenmodus 131
5.6 Neuheiten in R/3-Release 4.0 132
5.7 Neuheiten in R/3-Releases 4.5 A bis einschließlich 4.6 B 132
5.8 Zusammenfassung der Ziele von CATT 136
Kapitel 6
Aufbau des CATT-Tools 139
6.1 Testbaustein (optional) 139
6.2 Protokoll 141
6.3 Varianten 145
Kapitel 7
Funktionen des CATT-Tools 157
7.1 Allgemeine Funktionen 158
7.2 Spezielle Funktionen von CATT 159
7.3 Parameter 172
7.4 Variablen 174
7.5 Startbild (Einzelstart) 179
7.6 Varianten 181
7.7 CATT im Repository-Informationssystem 182
Kapitel 8
Einführung in die Bedienung von CATT 183
8.1 Voraussetzungen 183
8.2 Beispiel 183
8.3 Einfacher CATT 184
8.4 Komplexer CATT-Ablauf 209
8.5 Pflege von Customizing–Tabellen über Dynpros
bzw. Transaktionen 231
8.6 Sonstige Funktionen 240
8.7 Remote Start 243
8.8 Problembehandlungen 245
8.9 Protokoll anzeigen 247
Kapitel 9
CATT-Management 249
9.1 Massenstart 249
9.2 Einzelstart 250
9.3 Selektion 250
9.4 CATT-Statistik 254
9.5 CATT-Rangfolge-Pflege 261
9.6 CATT-Transportvorbereitung 263
9.7 Übersicht 264
6
Sandini Bib
Kapitel 10
Verwaltung von CATT-Testfällen 269
10.1 Testkatalog 270
10.2 Testplan 275
10.3 Testpaket 277
10.4 Testdurchführung 277
10.5 Statusanalysen durchführen 278
10.6 Testpaket zuordnen 280
10.7 Neuerung in R/3 Release 4.5 281
Kapitel 11
Fallstudie zum praxisnahen Einsatz von CATT 283
11.1 Testplanung 283
Kapitel 12
Testabläufe zu Geschäftsprozessen des Referenzmodells 319
12.1 Absatzplanung 319
12.2 Kosten-/Erlösartenbearbeitung 321
12.3 Kreditorenstammbearbeitung 322
12.4 Debitorenstammbearbeitung 323
12.5 Bestellanforderungsbearbeitung 324
12.6 Materialstammbearbeitung 325
12.7 Kundenkontraktbearbeitung 326
12.8 Fakturabearbeitung 327
12.9 Materialstücklistenbearbeitung 328
12.10 Arbeitsplatzbearbeitung 329
Kapitel 13
Mercury Testtools 331
13.1 Mercury Interactive Inc. – Das Unternehmen 331
13.2 Testlösungen von Mercury – Executive Summary 332
Anhang A 359
A.1 R/3-Einführung: Traditionelles Vorgehensmodell 359
Anhang B 367
B.1 Aufgabenbeschreibung der ASAP-Phasen 367
Anhang C 385
C.1 Kernprozesse im IDES-Schulungssystem 385
Anhang D 387
Inhaltsverzeichnis
D.1 Übersicht der standardmäßig verfügbaren Testabläufe 387

Glossar 411
Literaturverzeichnis 419
Stichwortverzeichnis 425
7
Sandini Bib
Sandini Bib
Geleitwort
Das Testen stellt im Rahmen von SAP R/3-Einführungsprojekten eine ebenso

schwierige wie wichtige Aufgabe dar. Und obwohl gerade ein guter Test über
die Qualität des R/3-Systems entscheidet, wird diese Aufgabe immer wieder
stark vernachlässigt. Gründe hierfür sind einerseits der hohe Zeitdruck, unter
dem R/3-Systeme eingeführt werden, andererseits aber auch die Scheu vor dem
enorm hohen Personalbedarf und den damit verbundenen Kosten, die traditio-
nelles, d.h. manuelles Testen mit sich bringt.
Das in diesem Buch vorgestellte Computer Aided Test Tool hilft dabei diesen
Problemen zu begegnen. Mithilfe dieses Tools kann das Testen der Geschäfts-
prozesse automatisiert werden, wodurch der Zeit- und Kostenaufwand über
den gesamten Lebenszyklus einer R/3-Installation minimiert wird.
Der Einsatz von Werkzeugen und Tools zum Nutzen der Kunden entspricht in
hohem Maße dem Selbstverständnis des ganzheitlichen Beratungs und Service-
konzeptes der ICM. Unsere Kunden erhalten Lösungen, die schnell und kosten-
sparend eingeführt werden und durch neueste Technologien für die Anforde-
rungen von morgen optimal vorbereitet sind. Dies wird besonders deutlich,
wenn man beispielsweise die Notwendigkeit eines Release-Wechsels und den
damit verbundenen erneuten Testaufwand in Betracht zieht.
Durch Kooperationen mit Partnern verfügen wir über ein Set von nützlichen
Tools, die sowohl bei der Implementierung einer neuen Lösung als auch im
Continuous Business Improvement eingesetzt werden.
Die ICM-Vorgehensweise zur effizienten Einführung von SAP R/3 basiert auf
der ASAP-Einführungsmethode der SAP-AG und nutzt zusätzlich die LIVE-
Tools der IBIS Prof. Thome GmbH./SBS. Weitere Tools, die aufgrund unserer
langjährigen Erfahrung in der Beratungspraxis entwickelt worden sind, kom-
plettieren dieses Angebot.
9
Sandini Bib
Geleitwort
Die Nutzenaspekte der Vorgehensweise von ICM sind die folgenden:

◗ Konsequente Ausrichtung auf zeit- und kosteneffektive Einführung von
SAP R/3
◗ Ausgereifte Werkzeuge; Powered by ASAP
◗ Schwerpunkt liegt auf dem methodischen Ansatz
◗ Unterstützung von durchgängigem Projektmanagement
Die LIVE-Tools zeichnen sich dadurch aus, dass sie eine zuverlässige Bestim-
mung des Projektumfangs und des Customizingaufwandes durch Beantwor-
tung von Fragen, die Generierung von Auswertungen (z.B. Workshop-Protokoll,
Management Summary, ...), die Sicht auf Prozesse, Berichte, Arbeitsplätze und
eigene Business Cases bieten. Man hat eine kurze, qualitativ hochwertige Analy-
sephase mit komfortabler Frage-/Antwort-Technik, die zudem intranetfähig ist.
Daraus resultiert die verständliche Darstellung betriebswirtschaftlicher Zusam-
menhänge in R/3 und die regelbasierte Reduktion auf den benötigten R/3-Um-
fang. Das Resultat ist eine automatische Generierung eines reduzierten Einfüh-
rungsleitfadens (IMG) und eine schnelle Erstellung unternehmensspezifischer
Anwenderdokumentationen und Schulungsunterlagen.
Die ICM International Consulting Group Munich ist ein Beratungs- und Dienst-
leistungsunternehmen. Wir verstehen uns als Lösungsanbieter im Umfeld der
SAP-Software.
Als Logo-, Entwicklungs- und Migrationspartner sowie als ein Systemhaus der
SAP AG verfügen wir über umfassendes Know-how im Bereich integrierter Un-
ternehmenslösungen. Darüber hinaus pflegen wir weitere strategische Partner-
schaften mit technologisch führenden Unternehmen. Mit insgesamt 18 Standor-
ten im In- und Ausland verfügen wir über internationale Erfahrung und können
einen flächendeckenden Service offerieren.
Bei uns bekommen Sie Lösungen mit großem Mehrwert auf höchstem Qualitäts-
niveau – und das für verschiedene Branchen und Unternehmen unterschied-
lichster Größen: vom mittelständischen Betrieb bis zum internationalen Groß-
konzern. Wir bündeln betriebswirtschaftliche und informationstechnologische
Kompetenz und sind Ihnen so in allen Phasen eines Projekts ein kompetenter
Partner: vom ersten Beratungsgespräch über die Implementierung der Software
bis hin zur Betreuung nach der Installation. Sie profitieren vom Full-Service aus
einer Hand: rollenbasiertes Anwendertraining, branchenspezifische Erweite-
rungen des SAP R/3® Standards, Nutzung neuester Internettechnologie wie die
WAP-Handy-Anbindung an ERP-Systeme und der Betrieb Ihrer Anwendung
im Outsourcing-Verfahren.
Besonders in den Branchen Chemie, Pharma, Konsumgüter (Food und Non
Food), Seetransport und in der Bauindustrie konnten wir unsere Stärken unter
Beweis stellen.
10
Sandini Bib
Dieses Branchen-Know-how wird permanent im Rahmen von Projekten erwei-

tert. Unsere Erfahrungen nutzen wir für eine vertikale Branchendurchdringung
und bieten einsatzfertige Lösungen für Großunternehmen und für mittelständi-
sche Unternehmen an. Diese enthalten die Individualität einer Subbranche auf
der Basis des Industriestandards SAP R/3 und der neuesten Informationstech-
no-logie. Selbstverständlich stellen wir auch hier das gesamte Serviceangebot
der ICM Group zur Verfügung.
Die Sicherstellung der Qualität der einzuführenden xERP-Software bei gleich-
zeitiger Minimierung der Aufwände und Kosten sind demnach keine konkur-
rierenden Ziele mehr und bei ICM State-of-the-Art.
Rainer Linnhoff
ICM Group GmbH
International Consulting Group Munich
Geleitwort
11
Sandini Bib
Sandini Bib
Vorwort zur
zweiten Auflage
Qualitätssicherung und Softwaretest – für viele DV-Leute bedeuteten diese Auf-

gaben in der Vergangenheit eher eine lästige Pflicht. Seit der ISO-9001-Zertifi-
zierung und natürlich auch mit dem in letzter Zeit viel diskutierten Jahr-2000-
Problem hat sich diese Sichtweise von Grund auf gewandelt. Nun ist der Soft-
waretest als wichtiger Bestandteil sowohl eines Software-Entwicklungsprojekts
als auch eines Software-Einführungsprojekts allgemein anerkannt. In beiden
Projekten spielt die Testphase eine nicht unerhebliche Rolle bei der Projektpla-
nung. Bei einer so umfangreichen Software wie R/3 darf die Qualitätssicherung
selbstverständlich erst recht nicht vernachlässigt werden. Heutzutage ist es na-
hezu selbstverständlich, dass die Unternehmen der verschiedensten Branchen
nach einer einheitlichen Qualitätsnorm wie der DIN ISO 9001 zertifiziert werden.
Ein Unternehmen, das nach dieser Norm zertifiziert werden will, muss aus-
drücklich nachweisen, dass die SAP R/3-Einführung und auch der anschließen-
de Produktivbetrieb des Systems den hohen Ansprüchen dieser Qualitätsnorm
genügt. Diesen Ansprüchen kann u.a. nur durch intensives Testen des R/3-Sys-
tems im Rahmen der Einfühung und der anschließenden Weiterentwicklung
bzw. Optimierung des Systems Rechnung getragen werden. Das angestrebte
Ziel ist es immer, mit möglichst wenig Zeit- und Personalaufwand möglichst
alle Eventualitäten in den Bereichen Funktionalität, Stabilität und Performance
auszutesten. Um dieses Ziel effizient zu erreichen, benutzt man spezielle Test-
werkzeuge, mit denen eine Automatisierung der Abläufe möglich wird. Das in
diesem Buch vorgestellte Computer Aided Test Tool der SAP AG hilft, diesen
Anforderungen in optimaler Weise gerecht zu werden. Dies gilt im selbem
Maße auch für die Testwerkzeuge der Mercury Interactive GmbH.
Dieses nun in der 2. Auflage vorliegende Buch verfolgt das Ziel, eine solide Ba-
sis für ein effizientes Testen und Weiterentwickeln des betriebswirtschaftlichen
Anwendungssystems SAP R/3 zu legen. Bei der Konzeption und beim Schrei-
ben des vorliegenden Buches haben wir besonderen Wert darauf gelegt, dass es
bei der Generierung von Lösungen, die sowohl in Time und Budget eingeführt
13
Sandini Bib
Vorwort zur zweiten Auflage
werden als auch in Zukunft dazu prädestiniert sind, Kosten und Zeit zu sparen,
größtmögliche Unterstützung bietet.
Bei der Realisierung dieser Neuauflage haben wir viel Unterstützung erfahren.
Dafür möchten wir uns sehr herzlich bedanken. Unser besonderer Dank gilt
Herrn Manfred Eierle, Geschäfsführer der Mercury Interactive GmbH, für sei-
nen wertvollen Beitrag. Für die vielen Hinweise, Meinungen und Ratschläge
danken wir unseren Lesern. Über die große Resonanz haben wir uns sehr ge-
freut. Dem Addison-Wesley Verlag sei für die kooperative Zusammenarbeit
ebenfalls gedankt.
August 2000
Gerhard Oberniedermaier und Marcus Geiß
14
Sandini Bib
Vorwort zur
ersten Auflage
Vorliegendes Buch spiegelt im wesentlichen meine Erfahrungen aus der Pla-

nung und Durchführung mehrerer erfolgreicher CATT-Projekte bei verschiede-
nen R/3-Einführungsprojekten und –Kunden wider, die ich im Rahmen meiner
Tätigkeit als Unternehmensberater bei der ICM Unternehmensberatung Grup-
pe, Stammhaus München/Ismaning, begleitet habe.
ICM ist die Abkürzung für International Consulting Group Munich. Die ICM ist
ein international tätiger, renommierter und erfahrener Beratungs-, Entwick-
lungs- und Logopartner der SAP AG, Walldorf. Core-Business der ICM sind
SAP-Implementierungen aller Größenordnungen sowie Managementberatung
und Business Reengineering. Die ICM Unternehmensberatungs-Gruppe posi-
tioniert sich dabei als »Unique Selling Proposition-Company« (Mehrwert-Un-
ternehmen). In diesem Kontext ist ICM auch auf folgende Dienstleistungen spe-
zialisiert: Entwicklung von Add-ons für SAP, Complementary Software,
Lösungen für Internet/Intranet und Groupware, End-User-Training, Conti-
nuous Business Engineering sowie Integration der Betriebsdatenebene.
Zusammen mit dem Bereich »Business Engineering« der SAP AG entwickelt
ICM darüber hinaus die R/3-Branchenmodelle für die Bereiche Chemische In-
dustrie, prozessorientierte Markenartikelindustrie und Pharmaindustrie. Die
Remote-Anwendungsbetreuung von SAP R/2- und R/3-Systemen durch das
ICM Support Center runden das umfangreiche Angebot des Unternehmens ab.
Durch diese Konzentration auf Branchenschwerpunkte verfügt die ICM über
hohes Erfahrungspotential in der Prozessindustrie. Aufgrund dieser Speziali-
sierung konnten fast alle Bigplayer der europäischen Chemischen und Pharma-
zeutischen Industrie sowie der Markenartikelindustrie als langfristige Kunden
gewonnen werden.
Dem interessierten Leser sollen anhand dieses Buches Lösungsansätze geboten
werden, welche im wesentlichen die Sicherung und Steigerung der Qualität des
R/3-Systems sowie dessen Weiterentwicklung zum Inhalt haben.
15
Sandini Bib
Vorwort zur ersten Auflage
Selbstverständlich bin ich allen Lesern jederzeit für Hinweise und Vorschläge
bezüglich des Inhalts und der Struktur dieses Buches dankbar. Der Leser sei
hiermit ausdrücklich ermutigt, sowohl konstruktive Kritik als auch Verbesse-
rungsvorschläge zur vorliegenden ersten Auflage dieses Buches an mich zu sen-
den. Als federführender Autor werde ich mich intensiv darum bemühen, diesen
Vorschlägen Rechnung zu tragen.
Als Kontaktadresse dient hierzu folgende E-Mail-Adresse:
Gerhard.Oberniedermaier@t-online.de
Anfragen für die Realisierung von entsprechenden R/3-Projekten können auf
diesem Wege natürlich auch gerne an mich herangetragen werden.
Allen, die zum erfolgreichen Abschluss dieses Buchprojektes beigetragen ha-
ben, möchte ich an dieser Stelle herzlichen Dank aussprechen.
Großer Dank gebührt in diesem Zusammenhang der Geschäftsführung der
ICM, Herrn Rainer Linnhoff und Herrn Matthias Mauser, für die hervorragende
Unterstützung bei der Realisierung dieses Buchprojektes. Dem Buchprojekt
wurde seitens meines Arbeitgebers großes Interesse und große Aufgeschlossen-
heit entgegengebracht.
Ich möchte mich vor allem auch bei meinem Mitautor Herrn Marcus Geiß für
die sehr gute und produktive Zusammenarbeit bedanken. Er unterstützte mich
konstruktiv bei der Erstellung der Kapitel 1, 4 und 12 dieses Buches.
Dem Team von Addison Wesley Longman, welches das Buchprojekt von der er-
sten bis zur letzten Seite konstruktiv begleitet hat, danke ich an dieser Stelle
ebenfalls ganz herzlich. Insbesondere möchte ich hier dem Lektor, Herrn Tomas
Wehren, für die sehr gute und erfreuliche Zusammenarbeit meinen großen
Dank aussprechen.
Mein ganz besonderer Dank allerdings gilt meiner Familie, insbesondere mei-
ner Mutter, die mich jederzeit in guten und wie schwierigen Situationen in toller
Art und Weise unterstützte.
Für ihre ganz besonders liebenswerte Art, mich trotz aller zeitlichen Entbehrun-
gen, die mein Beruf und auch die Erarbeitung dieses Buches mit sich brachten,
immer wieder neu zu inspirieren und auch zu motivieren sei abschließend vor
allem aber Kathrin, meiner großen Liebe, sehr herzlich gedankt. Sie schuf den
Ruhepol, der mich immer wieder neue Kraft und neuen Elan tanken ließ.
Mühldorf a. Inn, im April 1999

16
Sandini Bib
Ich möchte mich insbesondere bei Herrn Gerhard Oberniedermaier bedanken,

einerseits für die sehr gute und produktive Zusammenarbeit und andererseits
dafür, daß er mir die Möglichkeit geboten hat, an diesem überaus interessanten
Buchprojekt teilzuhaben. Und dann möchte ich die Gelegenheit wahrnehmen,
mich bei Ginevra für all die vergangenen Jahre zu bedanken, die wir gemeinsam
verbracht und gemeinsam erlebt haben.
Köln, im April 1999

Marcus Geiß
Vorwort zur ersten Auflage
17
Sandini Bib
Sandini Bib
Einleitung
Um heutzutage auf den sich permanent wandelnden Märkten bestehen bzw.

dauerhaft wettbewerbsfähig sein zu können, müssen sich in den Unternehmen
die meist traditionell gewachsenen und daher oft auch veralteten Strukturen än-
dern.
Eine wachsende Herausforderung an die Unternehmen stellen dabei die sich
ständig ändernden Kundenanforderungen dar. Auf diese gilt es, will man keine
Marktanteile verlieren, effizient zu reagieren. Die herkömmlichen unternehme-
rischen Reaktionen führen jedoch meist zu keiner wesentlichen Verbesserung:
Kostensenkung, Markenartikelwerbung, finanzielle Umstrukturierung und dgl.
stellen im Wesentlichen keine strategische Umorientierung dar und erbringen
so im besten Fall nur kurzfristig Gewinne.
Die heutigen Erfordernisse des Marktes zwingen die Unternehmen daher, die
Qualität und den Leistungsumfang ihrer Produkte permanent zu verbessern.
Die effizienteste Methode hierzu besteht, den Erfahrungen der Praxis zufolge,
darin, Strukturen und Abläufe gänzlich neu zu überdenken und zu optimieren.
Das Schlagwort vom Business Reengineering ist in aller Munde.
Jedes Unternehmen ist darum bemüht, die eigene Organisationsform, die Pro-
duktionsabläufe und natürlich auch die Produkte entsprechend diesen Markt-
erfordernissen zu gestalten. Das erfolgreiche Unternehmen der Zukunft wird
sich daher vom heutigen Unternehmen in vielem stark unterscheiden. Diese
Unterschiede werden sich in gravierender Weise natürlich auch auf den gesam-
ten Bereich der Informationstechnologie auswirken.
Denn Fakt ist: Das Einzige, was in einem Unternehmen nicht dem Prozess der
Veränderung unterworfen wird, ist die Tatsache, dass sich ständig alles ändert.
Das daraus resultierende Fazit kann folglich also nur lauten: Ein Unternehmen
muss eine sehr hohe Reaktionsfähigkeit hinsichtlich der Anforderungen des
Marktes zeigen und sich kontinuierlich den jeweiligen Erfordernissen anpassen
19
Sandini Bib
Einleitung
können. Dabei werden vom Unternehmen auch und vor allem an die Informa-
tionstechnologie sehr hohe Ansprüche gestellt.
John J. Donovan, Professor des MIT (USA), Business Reengineering with Infor-
mation Technology, vertritt in diesem Zusammenhang folgende Auffassung:
Um auf dem Markt einen strategischen Vorteil gegenüber den zahlreichen Wett-
bewerbern zu erlangen und außergewöhnliche Ergebnisse zu erzielen, muss ein
Unternehmen über eine solide Softwarearchitektur für alle betriebswirtschaftli-
chen Anwendungen verfügen. Diese Architektur ist eine dreistufige, auf Stan-
dards basierende Client/Server-Lösung.
Das bedeutet im Klartext Folgendes: Zum einen müssen wichtige Informatio-
nen bei Bedarf sofort zentral und anwendungsübergreifend verfügbar sein; das
heißt, zu jeder Zeit, von jeder Stelle aus muss der Zugriff auf diese Daten in
Echtzeit möglich sein. Es nutzt nichts, wenn die Daten nicht den jetzigen Stand,
sondern den der letzten Woche widerspiegeln.
Prozesse, die bislang zeitlich aufeinanderfolgten, müssen nun parallel ablaufen.
Um maximale Produktivität zu erreichen, ist es erforderlich, dass die entspre-
chenden Daten automatisch in den verschiedensten Anwendungsbereichen ver-
fügbar, also anwendungsübergreifend auf einer zentralen Datenbank hinterlegt
sind. Datenredundanz wird damit ausgeschlossen, und eventuelle Fehlerquel-
len werden dadurch vermieden. Die Anforderungen an ein zukunftstaugliches
ERP-System (Enterprise Ressource Planning-System) verlangen darüber hin-
aus, dass sämtliche Geschäftsvorgänge in einem Unternehmen prozessorientiert
dargestellt und strukturiert werden können.
Diese zwingend erforderlichen Funktionalitäten eines Softwaresystems erhö-
hen die Anforderungen an die heutige Softewareentwicklung enorm. Die mo-
derne Softwareentwicklung verlangt aufgrund der hohen Anforderungen an
Funktionalität, Integration und Verteilung die Durchführung großer Entwick-
lungsprojekte. Die Anforderungen des Marktes hinsichtlich der Produktqualität
wachsen dabei ständig. Immer mehr Unternehmen sind darum bemüht, nach
bestimmten Qualitätsnormen wie z.B. der DIN ISO 9000 zertifiziert zu sein, und
hoffen so, sich gegenüber der übrigen Konkurrenz am Markt hervorheben zu
können. In Bezug auf die Qualität in der Softwareentwicklung ist in Europa die
Qualitätsnorm DIN ISO 9000-3 besonders bedeutend. Qualität im Rahmen der
Entwicklung von Software wird heutzutage also zunehmend zu einem entschei-
denden Faktor.
Software hoher Qualität mit niedrigen Kosten zu entwickeln ist somit sowohl
für den Entwickler als auch für den Anwender eine herausfordernde Tätigkeit,
die letztlich durch das systematische Vorgehen geprägt wird. Zur Unterstüt-
zung der Entwicklung, der Implementierung und auch der anschließenden
Wartung und – im Idealfall – permanenten Optimierung der Software gibt es
computergestützte Werkzeuge. Für sie gilt: »Der Fortschritt des Menschen do-
kumentiert sich wesentlich in der Entwicklung und Anwendung seiner Werk-
zeuge. Je ausgereifter, komplexer und auch handhabbarer seine Werkzeuge
20
Sandini Bib
sind, desto produktiver und hochwertiger werden die Ergebnisse seiner Arbeit
und desto höher wird letztlich damit auch die Qualität seiner Softwareprodukte
sein.« [/Frick95/ 320]
Dieses elementare Statement muss insbesondere auch für die Entwicklung, An-
passung und Wartung einer betriebswirtschaftlichen Standardanwendungs-
software gelten, da hier ebenfalls höchste Anforderungen an Produktivität,
Qualität und Funktionalität der Software gestellt werden. Deshalb sollten unter
anderem im Rahmen eines betriebswirtschaftlichen Standardanwendungssoft-
warepaketes auch entsprechende Werkzeuge zur Verfügung gestellt werden –
sowohl für die Softwareentwicklung beim Hersteller als auch für die schnelle
und effiziente Einführung, Anpassung, Modifizierung und Wartung beim spä-
teren Endkunden.
Das Softwarehaus SAP AG mit Sitz in Walldorf bietet mit der betriebswirt-
schaftlichen Standardsoftware R/3 ein weltweit eingesetztes betriebswirtschaft-
liches Standardsoftwaresystem an, welches alle bisher beschriebenen Anforde-
rungen in hervorragender Art und Weise erfüllt.
Bei der R/3-Software handelt es sich um ein mehrstufiges Client-Server-System
mit umfassender betriebswirtschaftlicher Funktionalität, das sich durch unter-
nehmensweite Integration auszeichnet, wodurch ein einheitlicher Datenzugriff,
Flexibilität und Produktivität auf höchsten Niveau gewährleistet sind.
Mithilfe dieses Softwarepaketes können sich sowohl Unternehmen der verschie-
densten Branchen als auch öffentliche Verwaltungen, Behörden, Krankenhäuser
usw. kontinuierlich den sich permanent ändernden betriebswirtschaftlichen An-
forderungen des Marktes anpassen und somit ihre Wettbewerbsposition verstär-
ken oder sogar ausbauen. Heute ist das R/3-System zu einem De-facto-Standard-
system sowohl für große, multinational operierende Unternehmen als auch für
kleinere, national engagierte Betriebe geworden.
Das R/3-System ist heute weltweit mittlerweile ca. 21.000mal installiert. Diese
Zahl wird in Zukunft noch sehr stark ansteigen. Denn der Weltmarkt für be-
triebliche Standardsoftware wächst nach Meinung vieler Marktexperten weiter
mit bis zu 35 % pro Jahr. Außerdem erklärte Dietmar Hopp, Mitbegründer und
ehemaliger Vorstandsvorsitzender der SAP AG, in einem Interview: »R/3 wird
sehr langfristig auf dem Markt sein. Die SAP AG entwickelt es ständig weiter.
Ein R/4 ist nicht in Sicht.« [/Börse Online97/ 40]
Das kräftige Wachstum ist auf die weltweit ungebrochen hohe Nachfrage nach
standardisierter Anwendungssoftware zur Unterstützung betrieblicher Abläufe
zurückzuführen. Die Einführung des EURO sowie die Jahrtausendwende sor-
gen darüber hinaus für erhebliche Investitionen der Unternehmen im Hard-
Einleitung
und Softwarebereich, von denen die SAP AG auch in Zukunft noch in erhebli-
cherem Maße profitieren wird. Auf die EURO-Einführung sowie den Jahrtau-
sendwechsel sind die SAP-Systeme bestens vorbereitet. Auch die strikte Aus-
richtung der Produkte an die Kundenanforderungen sowie die Fähigkeit der
21
Sandini Bib
Einleitung
SAP AG, permanent Innovationen zu liefern, führen zu einem stetig zunehmen-

den Interesse an den SAP-Produkten und machen sie zu einem Verkaufserfolg
bei Unternehmen aller Größenordnungen.
Weltkonzerne wie Coca-Cola, General Motors, Ford, Hitachi, Shell, Daimler-
Chrysler, Hoechst oder Singapur Airlines haben durch den Einsatz der SAP-
Software ihre innerbetrieblichen Abläufe optimiert und so erheblich an Wettbe-
werbskraft gewonnen.
Zum Wachstum der SAP AG trägt darüber hinaus der zunehmende Erfolg im
Mittelstandsgeschäft bei. Denn der Mittelstand ist auch in zunehmender Weise
daran interessiert, die Vorteile des SAP-Systems R/3 zu nutzen. 1997 kamen be-
reits 37 % aller Neuaufträge aus dem mittelständischen Bereich. Weiteres
Wachstum ist auch hier im Rahmen der 1997 von der SAP AG initiierten »Mit-
telstandsoffensive« zu erwarten. Ein Ende des Höhenfluges der SAP AG ist ins-
gesamt also nicht abzusehen.
Die zahlreichen Erfahrungen aus der Praxis zeigen, dass die Zeitspanne zur Im-
plementierung des komplexen betriebswirtschaftlichen Standardsoftwarepake-
tes sehr stark variiert; jedoch in wesentlicher Abhängigkeit von der Unterneh-
mensgröße. Je größer das Unternehmen, desto länger dauert in der Regel der
Einführungsprozess, beginnend mit der Vorstudie bis hin zur Produktivset-
zung des Systems.
Bei der Einführung einer Standardanwendungssoftware ist, wie die Erfahrun-
gen aus der Praxis zeigen, in der Regel ein sehr langer, arbeitsintensiver und
schwieriger Weg zu absolvieren, bis die vielfältigen Möglichkeiten der Software
und die verschiedensten Bedürfnisse des Unternehmens in optimaler Weise
aufeinander abgestimmt sind. Erst dann kann das System in den Produktivbe-
trieb übergehen. Unternehmen, die neu mit der Einführung von Softwaresyste-
men konfrontiert sind, benötigen daher ein spezielles Projektmanagement für
die Einführung der Software.
Das R/3-System kann stufenweise mit eingeschränkter Funktionalität einge-
führt werden und ist demnach schneller produktiv. Die Abbildung der komple-
xeren Funktionalitäten und die entsprechende Konfiguration kann dann später
nach Bedarf erfolgen.
Die SAP AG hat mit dem R/3-Vorgehensmodell eine Einführungsmethodik für
SAP-Produkte entwickelt. Das Vorgehensmodell umfasst die jeweils neuesten
Erkenntnisse der SAP AG aus erfolgreichen R/3-Einführungen in Form von
Empfehlungen. Es bietet komfortablerweise dort, wo es notwendig ist, Zugriff
auf die entsprechenden Werkzeuge wie z.B. das R/3-Referenzmodell oder den
IMG (Implementation Guide, auch »Einführungsleitfaden« genannt). Somit er-
möglicht das Vorgehensmodell eine ideale Terminierung des Einführungspro-
jektes. Es bietet auch die Grundlage für die Einschätzung der im Laufe der Im-
plementierung benötigten Zeit und Ressourcen. Vom Vorgehensmodell aus
kann darüber hinaus direkt auf die Dokumentation des Projektes zugegriffen
22
Sandini Bib
werden. Das Modell gliedert das EDV-Projekt in mehrere Projektphasen und

Arbeitsschritte. Im Wesentlichen lassen sich die Einführungsphasen »Organisa-
tion und Konzeption«, »Detaillierung und Realisierung«, »Produktionsvorbe-
reitung« sowie »Produktivbetrieb« differenzieren. Alle Arbeitspakete in den
einzelnen Phasen enthalten Empfehlungen und eine Projektverwaltungsunter-
stützung.
Die Unternehmen wollen die Implementierungszeiten für neue Systeme und
neue Prozesse verständlicherweise so kurz als möglich halten. Gleichwohl soll
sich die Qualität und Produktivität des neuen Systems auf höchstem Niveau be-
finden. Auf diese anspruchsvolle Herausforderung hat die SAP AG frühzeitig
reagiert, indem sie unter anderem geeignete Methoden und Tools zur Verfü-
gung stellt, welche dem Kunden dabei helfen sollen, die Einführungszeiten we-
sentlich zu reduzieren.
Die SAP AG bietet in diesem Kontext u.a. mit dem unternehmenseigenen Tool
CATT Computer Aided Test Tool ein universell einsetzbares Werkzeug an, das
sich in hervorragender Weise dazu eignet, die Entwicklung bzw. Modifikation
des R/3-Systems, den Einführungsprozess und auch die sich daran anschlie-
ßende Pflege und Weiterentwicklung des R/3-Systems auf vielfältige Weise ef-
fizient und umfassend zu unterstützen und zu beschleunigen. Das Tool ist bei-
spielsweise in der Lage, modular aufgebaute betriebswirtschaftliche Prozesse
aller Art zu automatisieren und beliebig oft zu wiederholen. CATT enthält dar-
über hinaus alle erforderlichen Funktionen, um Testbausteine für einzelne
Transaktionen sowie Testabläufe für dynamische betriebswirtschaftliche oder
administrative Prozesse darzustellen, zu starten, zu testen, zu verwalten und zu
protokollieren. Dieses Werkzeug wird im weiteren Verlauf dieses Buches detail-
liert beschrieben.
Um der Forderung der SAP-Kunden nach kürzeren Einführungszeiten noch
besser zu entsprechen, entwickelte die SAP AG in Zusammenarbeit mit erfahre-
nen Unternehmensberatern darüber hinaus die Einführungsmethode ASAP.
Unter Zuhilfenahme dieses Tools können die Einführungszeiten erheblich ver-
kürzt werden. Im Idealfall sollten nach Meinung der SAP AG Implementie-
rungszeiten von sechs bzw. neun Monaten zu realisieren sein. Zur Umsetzung
der beschleunigten R/3-Einführung mittels ASAP kann auch CATT einen ent-
scheidenden Beitrag leisten. Das dynamische, DSDM-basierte Vorgehensmodell
für SAP R/3-Projekte darf an dieser Stelle nicht unerwähnt bleiben.
Das Ziel dieses Buches ist es, ein detailliertes und umfassendes Konzept für die
Anwendung von CATT bei der Einführung der von SAP R/3 nach dem klassi-
schen SAP-Vorgehensmodell darzustellen. Darüber hinaus wird gezeigt, wie
CATT in die ASAP-Vorgehensweise optimal integriert werden kann. Dadurch
Einleitung
soll sowohl R/3-Beratern als auch Anwendern ein praxisorientierter Leitfaden

zur Verfügung gestellt werden, welcher die Verwendungsmöglichkeiten von
CATT im Detail erläutert. Dabei stehen die Beschreibung der Funktionalitäten,
23
Sandini Bib
Einleitung
die Einsatzmöglichkeiten bezogen auf Projektphasen, die Vorteile von CATT so-
wie die Umsetzung von CATT im R/3-Einführungsprojekt im Mittelpunkt.
Das vorliegende Buch ist wie folgt aufgebaut:
In Kapitel 1 dieses Buches werden kurz beschrieben:
◗ Die Grundlagen der Softwareentwicklung
◗ Die Phasen des Softwareentwicklungsprozesses
◗ Das Testen von Software und die dabei verwendeten CASE-Werkzeuge
Dies soll den Lesern, welche noch über keine genaueren Kenntnisse in diesen
Themengebieten verfügen, einen umfassenden Überblick gewähren. Dieses Ka-
pitel zeigt überdies, wie das SAP-eigene CASE-Werkzeug CATT in die einzel-
nen Phasen des Softwareentwicklungs- und Testprozesses eingebunden wer-
den kann.
Kapitel 2 bietet einen Überblick über:
◗ Die Historie des CATT-Tools
◗ Die Definition
◗ Die CATT-Funktionen
◗ Die Einschränkungen der Funktionen
In Kapitel 3 wird der Aufbau der im R/3-System, Modul Basis, enthaltenen Ent-
wicklungsumgebung ABAP/4 Development Workbench erläutert.
Kapitel 4 veranschaulicht, wie das Testwerkzeug CATT bei der Einführung von
R/3 in den einzelnen Phasen
◗ des traditionellen Vorgehensmodells,
◗ der ASAP-Einführungsmethode und
◗ des neuentwickelten DSDM-basierten Vorgehensmodells
◗ effektiv genutzt werden kann. Die einzelnen mit CATT automatisierbaren
Arbeitspakete werden dabei detailliert beschrieben. Auch auf phasenüber-
greifende Einsatzmöglichkeiten wird im Detail eingegangen.
Im Anschluß daran werden in Kapitel 5 die allgemeinen Funktionalitäten des in
der ABAP/4 Development Workbench integrierten Computer Aided Test Tools
aufgezeigt.
In Kapitel 6 wird unter anderem auch die Zusammensetzung des Tools, dessen
modulares Konzept und die Verwendung von Variablen und Parametern dar-
gestellt.
24
Sandini Bib
Kapitel 7 beschreibt die verschiedenen Programmierfunktionen von CATT:

◗ Bearbeitungsfunktionen
◗ Prüffunktionen
◗ Steuerungsfunktionen
◗ Operatoren
◗ Parameter
◗ Variablen
◗ Varianten
In Kapitel 8 werden die wesentlichen Funktionalitäten des Computer Aided
Test Tools mit Hilfe ausführlicher Screen-Shot-Unterstützung erläutert. Die de-
taillierte »Step-by-step«-Auflistung der durchgespielten Screen-Shots nimmt
zwar viel Platz in Anspruch, doch wegen der Übersichtlichkeit und Nachvoll-
ziehbarkeit der behandelten Schritte soll nicht darauf verzichtet werden. Die
Verwendung von Screen-Shots soll überdies die Nachvollziehbarkeit der An-
wendungen am System erleichtern.
In Kapitel 9 werden die besonderen Funktionalitäten des CATT-Managements
erläutert.
Ergänzend und der Vollständigkeit halber wird in Kapitel 10 ein weiteres Tool
mit dem Namen Testworkbench vorgestellt, das zur Verwaltung und Organisati-
on der CATT-Abläufe eingesetzt werden kann.
Kapitel 11 zeigt die Verwendung des CATT-Tools bei einem R/3-Einführungs-
Kunden. Dabei werden die Vorgehensweise bei der Planung sowie die Abbil-
dung eines komplexen betriebswirtschaftlichen Testszenarios innerhalb des R/
3-Einführungsprojektes bei der Fa. XYZ GmbH realisiert. Aus Gründen der
Übersichtlichkeit ist diesem Kapitel das detaillierte Ablaufprotokoll zu dem
dort abgebildeten Testszenario beigefügt.
Für ausgewählte Geschäftsprozesse aus dem SAP-Referenzmodell wird in Ka-
pitel 12 exemplarisch dargestellt, wie die (diesen Geschäftsprozessen zuzuord-
nenden) Testabläufe bei einer Abbildung durch CATT aussehen können. Au-
ßerdem soll zu diesen Prozessen gegebenenfalls auf die Testbausteine bzw.
Testabläufe verwiesen werden, die standardmäßig mit dem R/3-System ausge-
liefert werden. Dies erfolgt vor allem unter dem Aspekt, dem CATT-Anwender
die Möglichkeit zu geben, auf bereits vorhandene Bausteine und Abläufe zu-
rückgreifen zu können, um den Erstellungs- und Bearbeitungsaufwand so nied-
rig wie möglich zu halten. Auf Anhang D sei an dieser Stelle verwiesen.
Einleitung
In Kapitel 13 werden die Testlösungen von Mercury Interactive, einem führen-

den Anbieter und Hersteller von automatisierten Tests und Performance-Mana-
gement-Lösungen, näher vorgestellt. Die Werkzeuge und Softwaretechnologien
von Mercury Interactive ermöglichen es, Funktionstests sowie Last- und Perfor-
25
Sandini Bib
Einleitung
mancetests an unterschiedlichen Applikationen innerhalb des Unternehmens

einzusetzen. Neben dem Applikationsbereich SAP R/3 werden auch die ERP-
Lösungen anderer führender Hersteller wie beispielsweise PeopleSoft, Baan
und Oracle unterstützt. Die Lösungen von Mercury Interactive ergänzen und er-
weitern die bislang vorgestellten Betrachtungen zum Thema Funktions-test an
SAP R/3-Umgebungen. Neben dem effizienten Test aus Benutzersicht für R/3-
Systeme können darüber hinaus komplette horizontale Geschäftsprozesse –
etwa über mehrere Applikationen hinweg – automatisiert abgebildet werden.
Anhang A beschreibt das traditionelle Vorgehensmodell zur R/3-Einführung.
Dabei wird jedes Arbeitspaket, welches mit CATT organisiert, abgearbeitet, be-
schleunigt und automatisiert werden kann, explizit gekennzeichnet. Dies gilt in
analoger Weise auch für Anhang B, welcher sämtliche Arbeitspakete der ASAP-
Einführungsmethode aufzeigt.
Unter den so genannten »Kernprozessen« im IDES-Schulungssystem sind die
Beispiele aufgeführt, die eine hohe Integration der Geschäftsabläufe im R/3-Sy-
stem abbilden und wichtige Geschäftsprozesse in IDES darstellen. Die meisten
dieser Kernprozesse arbeiten auch intensiv mit dem Computer Aided Test Tool.
Alle diese Kernprozesse sind in Anhang C aufgeführt.
Die in Anhang D dargestellte Tabelle gibt eine Übersicht über die Testabläufe,
die standardmäßig mit dem SAP R/3-System ausgeliefert werden.
Es sei darauf hingewiesen, dass vorliegendes Buch die Thematik CATT derge-
stalt behandelt, dass sowohl die R/3-Releaseversion 3.1. G und höher als auch
die R/3-Releaseversion 4.0 bis einschließlich 4.6B abgedeckt sind.
26
Sandini Bib
Einführung in das Testen

von Software
1
Vorliegendes Buch soll nach Meinung der Autoren im Wesentlichen folgende
Zielgruppen ansprechen:
◗ SAP-Programmierer
◗ SAP-Applikationsberater und -experten
Jede dieser Zielgruppen verfügt über fachspezifisches R/3-Know-how. So sind
dem SAP-Programmierer u.a. die Thematik der Softwareentwicklung und des
Testens von Software sehr vertraut. Das R/3-spezifische Modulwissen ist je-
doch meist weniger stark ausgeprägt.
Die Applikationsexperten hingegen kennen sich bestens mit der SAP R/3-Soft-
ware aus und verfügen beispielsweise über spezielles Wissen darüber, welche
Geschäftsprozesse und Funktionen mit dem SAP R/3-System abgebildet wer-
den können bzw. wann Modifikationen notwendig sind. In der Regel verfügen
die Applikationsexperten aber selten über ein detailliertes Wissen hinsichtlich
der Softwareentwicklung oder der verschiedenen Testmethoden.
Die Basis für die Benutzung der SAP-eigenen Werkzeuge zum Testen der SAP
R/3-Software, d.h. zum Testen der im R/3-System (einschließlich Erweiterun-
gen und Modifikationen) abgebildeten Geschäftsprozesse und -funktionen,
muss aber eine grundlegende Ausbildung in allen der folgenden Bereiche sein:
Bereich 1: Grundlagen der Softwareentwicklung sowie ausgeprägtes Wissen be-
züglich des Testens von Softwaresystemen. Die grundlegenden Begriffe zu die-
sen Themenbereichen werden in Kapitel 1 dieses Buches erläutert.
Bereich 2: Grundlegendes Wissen bezüglich der Eigenschaften und Besonderhei-
ten des SAP R/3-Systems, was sowohl die Geschäftsprozesse und -funktionen
angeht als auch Wissen bezüglich des Einführungsprozesses des SAP R/3-Sys-
tems, d.h. Know-how im Bereich der verschiedenen Vorgehensmodelle zur
Durchführung von R/3-Projekten. Diese Thematik wird, einschließlich der Fra-
27
Sandini Bib
Einführung
gestellung, wie die verschiedenen Testmethoden in den Einführungsprozess in-

tegriert werden können, in den Kapitel 1, 2 und 4 dieses Buches behandelt.
Bereich 3: Verständnis des Softwareentwicklungs- und Testkonzepts der SAP
AG sowie der dabei verwendeten Werkzeuge. Dieses Konzept wird in Kapitel 4
dieses Buches näher geschildert. In diesem Zusammenhang ist es wichtig, über
einen Überblick über die verschiedenen Funktionalitäten sowie die Bedienung
von CATT zu verfügen. Die Funktionalitäten von CATT werden in dieser Publi-
kation in den Kapiteln 3, 5 und folgende detailliert aufgezeigt.
Abgesehen von den SAP-Programmierern und den Applikationsexperten rich-
tet sich dieses Buch aber auch an die Mitarbeiter der Fachabteilungen, die als
Teammitglieder am SAP R/3-Projekt beteiligt sind. Diesen Teammitgliedern
soll das vorliegende Buch die Möglichkeit bieten, sich einen Überblick darüber
zu verschaffen, wie beispielsweise die Testworkbench oder die einfachen Auf-
nahmefunktionen des CATTs funktionieren, um so z. B. Geschäftsprozesse, die
sich auf lediglich eine Transaktion beschränken, eigenständig aufzeichnen und
mittels der Testworkbench zuordnen zu können. Darüber hinaus sollen die
internen Mitarbeiter in die Lage versetzt werden, die Testworkbench so einzu-
setzen, dass Gruppen von Testabläufen gestartet werden können, sobald Modi-
fikationen an den im SAP R/3-System abgebildeten Geschäftsprozessen durch-
geführt wurden.
Bei dem Testwerkzeug CATT Computer Aided Test Tool handelt es sich um ein
computergestütztes Testwerkzeug, das den sogenannten CASE-Tools (Computer
Aided Software Engineering Tools) zuzuordnen ist. CATT ist integriert in die
ABAP/4 Development Workbench, welche eine CASE-Umgebung darstellt. Das
Werkzeug CATT unterstützt somit optimal das Testen der R/3-Software – sowohl
bei der Erstellung der Software durch die SAP AG im Rahmen der klassischen
Softwareentwicklung als auch bei der Einführung des R/3-Systems beim Kunden.
Zur Thematik der Softwareentwicklung und zur zugehörigen Testmethodik
gibt es in der Fachliteratur mittlerweile unzählige Veröffentlichungen. Dem Le-
ser, der nicht gerade ein Informatikstudium absolviert hat, mögen viele der in
diesem Buch verwendeten Begriffe fremd sein. Deshalb werden auf den folgen-
den Seiten dieses ersten Kapitels kurz und prägnant die wichtigsten Begriffe er-
läutert. Dies ist nach Meinung der Autoren unverzichtbar für das Verständnis
der in den folgenden Kapiteln dieses Buches beschriebenen Sachverhalte. Die
folgenden Abschnitte behandeln in kompakter Form:
◗ die grundlegenden Begriffe der Softwareentwicklung
◗ die Phasen des Softwareentwicklungsprozesses
◗ die Thematik des Testens von Software
◗ die dazu verwendeten CASE-Werkzeuge
◗ das Debugging
◗ den Begriff der Standardsoftware
28
Sandini Bib
Zum R/3-System existieren bereits ebenfalls viele Publikationen, so dass sich

die Beschreibung hinsichtlich seiner Funktionalität in diesem Buch lediglich auf
zwei Seiten beschränkt.
1.1 Grundlagen der Softwareentwicklung

Die heutige Systementwicklung in der Daten- und Informationsverarbeitung
befasst sich mit der Entwicklung von sogenannten Anwendungssystemen. Die
Entwicklung von Systemsoftware und systemnaher Software gehört zwar auch
zur Systementwicklung, soll aber in diesem Buch nicht näher behandelt werden.
Wenn in diesem Buch von Systementwicklung gesprochen wird, ist die Ent-
wicklung von Anwendungssystemen gemeint.
Bei einem Anwendungssystem handelt es sich heute im engeren Sinne um die
Gesamtheit aller Programme, die als sogenannte Anwendungssoftware für
ein konkretes betriebliches Anwendungsgebiet entwickelt, eingeführt und
eingesetzt werden sowie um die zugehörigen Daten, die in unterschiedlichen
Organisationsformen (Dateien, Datenbank, verteilte Datenbank) bereitgestellt
werden.
Im weiteren Sinne versteht man unter einem Anwendungssystem die Hard-
warekomponenten und Kommunikationseinrichtungen, die für die Nutzung
der Anwendungssoftware notwendig sind. Anwendungssoftware wird in die-
sem Kontext auch als »application software« bezeichnet. [/Balzert96/23] Wenn
im folgenden von Anwendungssystemen die Rede ist, sind Anwendungs-
systeme im engeren Sinne gemeint.
Kapitel 1 – Einführung in das Testen von Software

Wie eingangs bereits erwähnt, erfordert die heutige moderne Softwareentwick-
lung aufgrund der hohen Anforderungen an Funktionalität, Integration und
Verteilung die Durchführung von Softwareentwicklungs- und Softwareeinfüh-
rungsprojekten. [/Keller97/182]
Innerhalb dieser Softwareentwicklungsprojekte unter der Restriktion niedriger
Kosten Software hoher Qualität zu entwickeln bzw. das R/3-System mit hoher
Qualität einzustellen und zu modifizieren ist eine besonders ressourcenintensi-
ve herausfordernde Tätigkeit, die letztlich und besonders durch das systemati-
sche Vorgehen geprägt wird. [/Xu95/22 ff. ] Um dieser Tatsache Rechnung zu
tragen, hat man versucht, ingenieurmäßiges, strukturiertes Vorgehen in den
Softwareentwicklungsprozess einzubringen, und diesen hierzu in sogenannte
Phasenkonzepte gegliedert. Phasenkonzepte wurden dabei in zahlreichen Va-
riationen entwickelt. Sie beschreiben in ihrem Grundprinzip folgende Phasen
des Softwareentwicklungsprozesses:
◗ Analyse
◗ Definition
◗ Entwurf
29
Sandini Bib
1.1 Grundlagen der Softwareentwicklung
◗ Implementierung
◗ Systemtest, Abnahme und Wartung
◗ Software-Life-Cycle
1.1.1 Analyse
Die Phase »Analyse« beschäftigt sich mit der Fragestellung »Was soll das An-
wendungssystem leisten?«. Im ersten Schritt befasst sich die Analysephase mit
einer Aufnahme des Ist-Zustandes des Anwendungsgebietes, welches von dem
zu entwickelnden Anwendungssystem abgedeckt werden soll. Insbesondere
werden hier die Schwachstellen analysiert und bewertet. Im zweiten Schritt
wird ein Sollkonzept entwickelt, in dem die Anforderungen der Anwender an
das künftige System festgehalten werden. Basierend darauf sowie auf der
Schwachstellenanalyse erstellt man nun den Fachentwurf, welcher den Leis-
tungsumfang des neuen Anwendungssystems detailliert beschreibt. Hinsicht-
lich der technischen Realisierung wird zunächst ein grobes Systemkonzept an-
gefertigt. Am Ende dieser Phase wird dann entschieden, ob das geplante System
überhaupt realisiert werden soll. Diesem Zweck dienend werden Kosten- bzw.
Nutzen-Analysen anhand von Wirtschaftlichkeitsvergleichen durchgeführt.
1.1.2 Definition
Die wesentlichen Aufgaben der Definitionsphase liegen in der Erstellung der
Produktdefinition, der Festlegung der Leistungsmerkmale und der Benutzer-
interaktion, der Hierarchisierung der Komponenten, der Definition von Daten,
Funktionen und Algorithmen sowie der verbindlichen Beschreibung von Qua-
litätsmerkmalen und ihren Ausprägungen. Kennzeichen dieser Phase ist also
die Umsetzung des Anwendungsgebietes in die Leistungscharakteristik eines
Softwaresystems. Sie ist von starker Methodenanwendung und dem Einsatz
von CASE-Tools geprägt. CASE-Tools sind computergestützte Hilfswerkzeuge
bei der ingenieurmäßigen Softwareentwicklung; auch das Computer Aided
Test Tool (CATT) lässt sich den CASE-Tools zuordnen.
Das Ergebnis dieser Phase ist ein konsistentes, vollständiges und eindeutiges
Anforderungsprofil sowie das Vorhandensein von Dokumenten, in denen die
relevanten Prozesse sowie die Kontroll- und Datenstrukturen beschrieben sind.
[/Frick95/38]
30
Sandini Bib
1.1.3 Entwurf
Diese Phase trägt die Überschrift: »Wie ist es zu tun?«. Hier werden wichtige
Entscheidungen getroffen. Aus dem Sollkonzept der Analysephase muss der ei-
gentliche Systementwurf in detaillierter datenverarbeitungstechnischer Sicht
abgeleitet werden. In diesem Entwurf sind vor allem die Datenstrukturen und
die Arbeitsabläufe festzulegen. Anschließend werden die Vorgaben für die Pro-
grammentwicklung, also die Programmspezifikationen, definiert. Basierend auf
dieser Programmspezifikationen wird letztlich ein Programmentwurf formu-
liert. [/Stahlknecht95/238]
1.1.4 Implementierung
In dieser Phase erfolgt die Umsetzung des in der Entwurfsphase dargestellten
abstrakten Programmentwurfs in ein Computerprogramm durch Codierung in
einer Programmiersprache. [/Beims95/13] Kritische Teile des Programms soll-
ten zuvor einem sogenannten symbolischen Test unterzogen werden. Nach Ab-
schluss der Programmierung prüfen Übersetzungsprogramme wie z.B. Assem-
bler oder Compiler das Programm auf syntaktische, d.h. formale Fehler und
teilweise auch auf semantische, d.h. logische Fehler. In engem Zusammenhang
mit der Programmierung stehen der Modultest und der Integrationstest, mit de-
nen nacheinander semantische Fehler im Programm oder in den vorangegange-
nen Entwurfsschritten eliminiert werden sollen. Die Begriffe symbolischer Test,
Modultest und Integrationstest werden nachfolgend explizit behandelt. Auch
bei diesen Tests werden die sogenannten CASE-Tools als Testwerkzeuge einge-
setzt. Ergebnis der Implementierungsphase sind zunächst die einzelnen fertig-

gestellten Softwaremodule, die am Phasenende zu einem Softwaresystem zu-
sammengefügt werden. Weiteres Resultat sind Testpläne und Testergebnisse
aus den beschriebenen Tests [/Frick95/42]. Sämtliche genannten Tests werden
mit Testwerkzeugen durchgeführt.
1.1.5 Systemtest, Abnahme und Wartung

Zunächst wird in dieser Phase der Systemtest mit dem Ziel durchgeführt, die
Wechselwirkungen der Systemkomponenten unter realen Bedingungen zu prü-
fen. Eine genauere Definition des Systemtests erfolgt im weiteren Verlauf dieses
Kapitels. »Bei dieser finalen Prüfung ist oft der Auftraggeber zugegen, der – im
besten Fall – selbst mit einem Prüfkatalog jede einzelne Systemfunktion über-
prüft.« [/Frick95/42]. Falls das System nicht von einer externen Softwarefirma er-
stellt, sondern unternehmensintern produziert wurde, ist es empfehlenswert, die-
se Prüfung durch ein Team durchführen zu lassen, das nicht an der Entwicklung
beteiligt war. [/Frick95/42] Nach Abschluss des Systemtests und damit auch der
Testphase wird das System zur Benutzung freigegeben [/Pomberger96/20]. Der
Systembetrieb ist zwar nicht mehr Bestandteil des eigentlichen Softwareentwick-
31
Sandini Bib
1.2 Vorgehensmodelle der Softwareentwicklung
lungsprozesses. Er bildet aber ein wesentliches Element des nachstehend be-

schriebenen Software-Life-Cycles. Nachdem das Softwaresystem ab- und in Be-
trieb genommen wurde, beginnt mit der Wartung und Pflege des neuen Systems
die längste, und in den meisten Fällen, auch die teuerste Phase. 67% bis 80% der
Gesamtkosten der Softwareentwicklung fallen nach Balzert allein auf Wartungs-
arbeiten an [/Balzert96/976].
1.1.6 Software-Life-Cycle
Man kann also abschließend sagen, dass in den ersten drei Entwicklungsphasen
das künftige Softwareprodukt auf verschiedenen Abstraktionsniveaus beschrie-
ben wird. In der vierten Phase entsteht dann das System als solches und in der
fünften kann es in Betrieb genommen werden. Dieses Konzept geht davon aus,
dass für jede Phase das Ergebnis, welches nach Abschluss der jeweiligen Phase
vorliegen soll, bereits im Vorfeld klar definiert ist. Eine Phase kann nur dann be-
gonnen werden, wenn die vorhergehende vollständig abgeschlossen ist. Die
Vorgehensweise ist also streng sequentiell. Man spricht hier vom klassischen
Software-Life-Cycle-Modell. »Untersuchungen von Boehm haben gezeigt, dass
diese sequentielle life-cycle-orientierte Vorgehensweise die am weitesten ver-
breitete Softwareentwicklungsmethode ist« [/Pomberger96/22].
Mit dem Begriff Software-Life-Cycle-Modell verbindet man die Vorstellung von
einer Zeitspanne, in der ein Softwareprodukt entwickelt und eingesetzt wird,
bis zum Ende seiner Benutzung.

Aus den vorgenannten Phasen bildeten sich mit der Zeit verschiedenste Varian-
ten des vorbezeichneten Phasenmodells zur Softwareentwicklung heraus. Man
spricht in diesem Kontext auch von sogenannten Vorgehensmodellen [/Beims95
/8]. Elementares Kennzeichen all dieser Modelle ist, dass sie eine noch weiter-
gehende Unterteilung der einzelnen Phasen durchführen und darüber hinaus
den Wechselwirkungen zwischen den einzelnen Phasen Aufmerksamkeit
schenken. Nachfolgend werden kurz und prägnant die wichtigsten Modelle er-
läutert. Die bekanntesten dürften das sogenannte Wasserfallmodell, das Proto-
typing und neuerdings das DSDM-basierte Vorgehensmodell sein.
1.2.1 Wasserfallmodell
Der Begriff Wasserfallmodell charakterisiert die Phasen des Softwarelebenszyklus
(Software-Life-Cycle), indem er eine bildliche Vorstellung von der schrittwei-
sen, nicht umkehrbaren Vorgehensweise beim Entwurf, der Entwicklung und
Implementierung von Software vermittelt [/Thome96/170]. Hier werden Rück-
kopplungen zwischen den einzelnen Entwicklungsschritten mit der Restriktion,
32
Sandini Bib
dass solche Rückkopplungen nur zwischen zwei aufeinanderfolgenden Phasen

erfolgen sollen, eingeführt. Das erklärte Ziel des Wasserfallmodells ist es, durch
die beschriebene Vorgehensweise eine kostspielige Nachbearbeitung infolge
von Iterationen über mehrere Phasen hinweg zu minimieren. Die Validierung
der Phasenergebnisse kann somit in den Entwicklungsprozess integriert wer-
den [/Keller97/185].
Das SAP-Vorgehensmodell zur Einführung der betriebswirtschaftlichen Stan-
dardsoftware SAP R/3 basiert auf dem eben beschriebenen Wasserfallmodell.
In Kapitel 4 dieses Buches wird auf das SAP-Vorgehensmodell noch näher ein-
gegangen.
1.2.2 Prototyping
Das Prototyping ist, kurz gesagt, eine Vorgehensweise der Softwareentwick-
lung, bei der zunächst eine Vorabversion, also ein Prototyp, des geplanten An-
wendungssystems erstellt wird. Man verwendet diesen Prototyp entweder nur
als »Wegwerfprototyp« zur Sammlung von Erfahrungen (rapid prototyping),
oder er wird schrittweise bis zum endgültigen System verbessert (evolutionary
prototyping) [/Schneider97/675]. Bezogen auf das vorstehend beschriebene
Phasenschema der Softwareentwicklung unterscheidet man darüber hinaus
noch zwischen dem explorativen und dem experimentellen Prototyping. Das ex-
plorative Prototyping konzentriert sich auf den Fachentwurf, d.h. auf die Funktio-
nalität des jeweiligen Anwendungssystems. Mit Alternativen der technischen
Realisierung z.B. Schnittstellen zwischen Programmen befasst sich das experi-
mentelle Prototyping.

Prototyping ist sowohl getrennt in den einzelnen Phasen der Softwareentwick-
lung als auch phasenübergreifend einsetzbar. Durch den Prototypen wird die
Kommunikation aller an der Entwicklung Beteiligten wesentlich verbessert,
denn einerseits können die künftigen Anwender ihre Anforderungen an das
System exakter formulieren, und andererseits haben die Entwickler die Chance,
mehr über das Anwendungsgebiet zu erfahren [/Frick95/46]. Bei richtiger
Handhabung kann man mit Prototyping die Entwicklungszeit verkürzen.
Zweckmäßig ist dabei der Einsatz von computergestützten Werkzeugen, die
das Prototyping effektiv unterstützen.
1.2.3 Das DSDM-Vorgehensmodell

Beim DSDM-Vorgehensmodell in der hier beschriebenen Form handelt es sich
um ein neu entwickeltes Vorgehensmodell für die Einführung der betriebswirt-
schaftlichen Standardsoftware SAP R/3. Aus diesem Grunde wird der Erläute-
rung dieses Vorgehensmodells hier etwas mehr Platz eingeräumt.
33
Sandini Bib
DSDM steht für Dynamic Systems Development Method und beschreibt ein nicht
geschütztes dynamisches Vorgehensmodell, welches ein Gerüst zur Verfügung
stellt, mit dem Softwaresysteme entwickelt und gewartet werden können, die
strengen Zeitvorgaben unterworfen sind.
Dieses Modell wurde vom gleichnamigen DSDM-Konsortium entwickelt und
beruht auf den Erfahrungen der verschiedener Mitglieder des Konsortiums.
Dem DSDM-Konsortium gehören mittlerweile über 1000 Mitglieder an, wie bei-
spielsweise IBM, Hewlett Packard, Siemens plc, Cap Gemini, Coopers Ley-
brand, Ernst&Young. Dem interessierten Leser, der mehr über DSDM erfahren
möchte, seien sowohl das DSDM-Handbuch [/DSDM97/] als auch das Buch
»DSDM – The Method in Practice« von Jennifer Stapleton [/Stapleton97/] emp-
fohlen.
Der Hauptanwendungszweck der Dynamic Systems Development Method ist
ein strukturiertes und kontrolliertes Vorgehen bei Softwareentwicklungsprojek-
ten. Insbesondere sollen mit DSDM sogenannte RAD-Projekte (Rapid Applica-
tion Development-Projekte) durchgeführt werden. Der Begriff des RAD geht
auf James Martin zurück und findet Verwendung in dessen gleichnamigen
Buch [/Martin91/]. Das wesentliche Charakteristikum von RAD-Projekten ist
die Beachtung streng vorgegebener Zeitfenster bzw. die hohe Entwicklungsge-
schwindigkeit, so dass RAD-Projekte häufig mit dem Ruf zu kämpfen haben, sie
seien »quick and dirty« oder RAD-Projekte seien »the licence to hack«. Dieses
negative RAD-Image resultiert aus einem scheinbar unstrukturierten und plan-
losem Vorgehen in RAD-Projekten. Die Dynamic Systems Development Me-
thod stellt nun ein Vorgehensmodell zur Verfügung, das geeignet ist, RAD-Pro-
jekte zu strukturieren und zu planen, und kann so dem negativen RAD-Image
entgegenwirken.
Die Dynamic Systems Development Method unterteilt sich in fünf Phasen. Wie
die einzelnen Phasen aussehen bzw. wie durch das Modell navigiert werden
kann, wird in der folgenden Abbildung 1.1 dargestellt.
34
Sandini Bib
Machbarkeit
Geschäftsstudie
Funktionale
Modell Implementierung
Iteration
Design &
Build Iteration
Abbildung 1.1
Das DSDM-Modell
Die Aktivitäten der einzelnen Phasen können folgendermaßen zusammenge-

fasst werden:
A 1. Phase: Die Machbarkeitsstudie
Diese erste Phase zielt darauf ab, Fragen zu beantworten wie: »Ist die Sys-
tementwicklung geeignet, die Unternehmensziele zu unterstützen, bzw. geht
sie mit diesen konform?«, »Ist eine technische Realisierung möglich, und wie
könnte diese in groben Zügen aussehen?«, »Wie hoch ist der zu erwartende
Zeit- bzw. Kostenaufwand?«. Die Ergebnisse dieser Phase müssen erstens
ein Machbarkeitsbericht sein, der sich z.B. mit dem Betätigungsfeld, den Pro-
blemdefinitionen und den Zielen auseinandersetzt, und zweitens eine Grob-
planung, die eine erste Projektplanung darstellt.
Außerdem muss in dieser Phase geklärt werden, ob das Projekt überhaupt
mit DSDM durchführbar ist. Um diese Frage beantworten zu können, stellt
das DSDM-Konsortium einen Leitfaden zur Verfügung, der dazu dient, Soft-
wareprojekte hinsichtlich ihrer DSDM-Tauglichkeit zu bewerten. Beispiels-
weise sollten weder Realtime- oder Prozesssteuerungsapplikationen noch
Softwareprodukte mit DSDM entwickelt werden, deren Anforderungen be-
reits vor Projektstart vollständig und unveränderlich zur Verfügung stehen
35
Sandini Bib
müssen. Ist das Projekt nicht mit dem DSDM-basierten Vorgehensmodell

durchführbar, so muss zu einem anderen Vorgehensmodell gewechselt wer-
den.
B 2. Phase: Die Geschäftsstudie
In dieser Phase werden die funktionalen Anforderungen sowie die Hauptan-
forderungen nicht-funktionaler Art, wie zum Beispiel Sicherheit oder Perfor-
manz, grob definiert. Von besonderer Wichtigkeit ist die Tatsache, dass die
Anforderungen in dieser Phase zunächst nur grob definiert werden und dass
die eigentliche detaillierte Geschäftsprozessanalyse erst in der nächsten Pha-
se stattfindet, d.h., es muss geklärt werden, in welchem Umfang die Ge-
schäftsfunktionen von dem neuen System unterstützt werden sollen.
Außerdem muss in dieser Phase je Geschäftsprozess und je Benutzergruppe
ein repräsentativer Benutzer für die Prototyping-Aktivitäten bestimmt wer-
den. Desweiteren müssen die Anforderungen im Hinblick auf ihre Wichtig-
keit für den Geschäftsnutzen priorisiert werden.
Die Ergebnisse dieser Phase müssen neben der Geschäftsfelddefinition (Be-
nutzer, Hauptgeschäftsprozesse, notwendige Informationen) eine Aufstel-
lung der priorisierten Funktionen, die Definition der Systemarchitektur so-
wie eine Verfeinerung der zeitlichen Grobplanung aus der ersten Phase sein,
wobei diese Verfeinerung dann einen groben Prototyping-Plan für die näch-
sten Phasen darstellt.
Häufig können die Machbarkeits- und die Geschäftsstudie kombiniert
werden.
C 3. Phase: Funktionenmodell-Iteration
Der Fokus dieser Phase liegt auf dem iterativen Prototyping, welches dazu
dient, die Anforderungen der Benutzer zu ermitteln bzw. das Wissen über
die Anforderungen zu verfeinern. Diese Phase kann und wird auch in der
Regel mehrmals wiederholt und hat die Demonstration der Funktionalitäten
zum Ziel, darüber hinaus aber auch die Erfassung der nicht-funktionalen
Anforderungen.
Diese Phase soll folgende Ergebnisse haben:
◗ Implementierungsstrategie (mit detaillierterem Plan und Kosten-Nutzen-
Analyse)
◗ Funktionenmodell
◗ detaillierte Anforderungsbeschreibung sowie die zugehörigen Proto-
typen
◗ Revisionsdokumente der funktionalen Prototyps
◗ Risikoanalyse zukünftiger Entwicklungen (optional)
36
Sandini Bib
D 4. Phase: System-Design- und System-Build-Iteration

Es ist möglich, diese Phase bereits zu beginnen, obwohl die vorhergehende
Phase noch nicht abgeschlossen wurde. Die Trennung zwischen dritter und
vierter Phase kann fließend verlaufen bzw. ganz verschwinden.
Ziel dieser Phase ist die Verbesserung und Verfeinerung des funktionalen
Prototyps und eine Berücksichtigung der nicht-funktionalen Anforderun-
gen. Als Ergebnisse soll diese Phase sowohl ein getestetes System liefern, das
alle funktionalen und nicht funktionalen Anforderungen erfüllt, als auch ei-
nen Design-Prototyp sowie Revisionsdokumente zum Design-Prototyp.
E 5. Phase: Die Implementierung
In dieser Phase wird das System den Endbenutzern übergeben. Es werden
sowohl der Projekterfolg als auch die Komponenten bestimmt, die zu einem
späteren Zeitpunkt noch fertiggestellt werden müssen. In Abhängigkeit vom
Ergebnis der Projektrevision wird in eine der vorhergehenden Phasen zu-
rückgesprungen oder das Teilprojekt beendet.
In dieser Phase wird das getestete System in die Arbeitsumgebung des Be-
nutzers eingebettet, und zukünftige Entwicklungsanforderungen werden
bestimmt. Die Benutzer werden geschult, und ein Benutzerhandbuch wird
erstellt. Diese Phase schließt mit einer dokumentierten Projektrevision ab.
Im Sinne von DSDM wird die Wartung in der Regel als kontinuierlicher Ent-
wicklungsprozess verstanden, so dass Wartung einer neuen DSDM-Entwick-
lungsiteration gleichkommt.
Die schwarzen Pfeile (siehe Abbildung 1.1) beschreiben den Weg durch den Le-

benszyklus, wobei von der Machbarkeitsstudie aus gegen den Uhrzeigersinn
von einer Phase in die nächste übergegangen wird. Die schwarzen Pfeile reprä-
sentieren den »Soll-Weg« durch das Modell. Die grauen Pfeile deuten hingegen
an, an welchen Stellen des Zyklus leicht in eine vorherige Phase zurückgesprun-
gen werden kann. Wie durch die einzelnen Phasen navigiert wird, kann sich so-
mit von Projekt zu Projekt unterschiedlich gestalten, so dass das DSDM-basierte
Vorgehensmodell kein strikt einzuhaltendes Vorgehen beschreibt, sondern ge-
rade umgekehrt impliziert, dass es dem jeweiligen Projekt angepasst wird.
Über diese Phasen hinaus beschreibt DSDM eine Vielzahl an phasenübergrei-
fenden Aktivitäten, die für eine erfolgreiche Projektabwicklung unabdingbar
sind. Im einzelnen sind dies:
◗ Projektmanagement
◗ Prototypingmanagement
◗ Konfigurationsmanagement
◗ Timeboxing
◗ Priorisierung
37
Sandini Bib
◗ Testen
◗ Risikoanalyse
◗ Qualitätssicherung
Diese phasenübergreifenden Aktivitäten sind für DSDM von besonderer Bedeu-
tung, so dass die Darstellung des vollständigen dynamischen Vorgehensmodells
darauf abzielt, diese Aktivitäten als Fundament mit in die Abbildung einzubezie-
hen. Das vollständige DSDM-Vorgehensmodell ist in Abbildung 1.2 zu sehen.
Machbarkeit
Geschäftsstudie
Funktionale
Iteration
Design &
Build Iteration
Projektmanagement
Teamstrukturen
Benutzerbeteiligung
Prototyping-Management
Fähigkeiten und Verantwortung
Schätzen
Risikoanalyse
Änderungskontrolle
Konfigurationsmangement
Entwicklungsumgebung
Methoden
Testen
Qualitätsmanagement
regelmäßige Auslieferung
Abbildung 1.2
DSDM inkl. der fundamentalen phasenübergreifenden Aktivitäten
38
Sandini Bib
Eine weitere wichtige Fragestellung ist, ob bzw. wie DSDM angewendet werden
kann, um Qualitätsnormen zu erfüllen. Ein sehr hilfreiches Werk bei der Beant-
wortung dieser Frage ist die Ausarbeitung vom British Standards Institution
(BSI) »The Dynamic Systems Development Method & TickIT«.
Das BSI beschreibt in dieser Ausarbeitung einen detaillierten Leitfaden, der dar-
stellt, wie DSDM-Softwareentwicklungsprojekte durchzuführen sind, damit die
Anforderungen der ISO 9001 erfüllt werden [/BSI97/]. Das Ergebnis dieser
Ausführungen ist also, dass DSDM die Anforderungen der ISO 9000 erfüllt.
DSDM basiert einerseits auf der Idee, die Anforderungsanalyse und -realisie-
rung unmittelbar nacheinander durchzuführen (also anders als in wasserfall-
basierten Modellen), und andererseits auf dem Ansatz des iterativen Prototy-
pings, welches durch ein Prototypen-Management gesteuert wird. Hierbei stel-
len die Prototypen im Sinne von DSDM keine »Wegwerf-Prototypen« dar, son-
dern werden als Teil des zu entwickelnden Produktes realisiert. Dieses
Vorgehen zielt darauf ab, dass der spätere Endbenutzer schon sehr früh in das
Projekt einbezogen wird, also die Entwicklung des Softwareproduktes mitver-
folgt. Als Vorteile, die sich aus diesem Vorgehen ergeben, nennt das DSDM-
Konsortium die folgenden Punkte [/DSDM97/15]:
◗ Der Endbenutzer identifiziert sich mit dem System.
◗ Die Kooperation aller Beteiligten mindert mögliche Widerstände bei der Im-
plementierung.
◗ Die Gefahr, die Bedürfnisse des Endbenutzers zu verfehlen, wird reduziert.
◗ Der Endbenutzer erlangt ein besseres Verständnis des Systems. Er weiß, was,
warum und wie gemacht wurde.

◗ Das entwickelte System ist geeigneter, die Anforderungen zu erfüllen.
◗ Prototyping vermeidet sprachliche Mißverständnisse.
◗ Der Benutzer lernt das System schon während des Prototypings kennen, so
dass der Schulungsaufwand reduziert wird.
◗ Team- und Kommunikationsfähigkeit werden trainiert.
1.3 Qualitätssicherung durch Tests im Rahmen

des Software-Life-Cycle
In R/3-Projekten muss besonders großer Wert auf eine umfangreiche Qualitäts-
sicherung gelegt werden. Heutzutage ist es nahezu selbstverständlich, dass die
Unternehmen der verschiedensten Branchen nach einer einheitlichen Qualitäts-
norm wie der DIN ISO 9001 zertifiziert werden. Ein Unternehmen, das nach die-
ser Norm zertifiziert werden will, muss ausdrücklich nachweisen, dass die SAP
R/3-Einführung den hohen Ansprüchen dieser Qualitätsnorm genügt.
39
Sandini Bib
1.3 Qualitätssicherung durch Tests im Rahmen des Software-Life-Cycle
Der Qualitätssicherungsplan ist dabei eines der wichtigsten Instrumente für

eine effektive Qualitätssicherung eines R/3-Einführungsprojektes. Die DIN ISO
9000-3 ist in Europa die wichtigste Norm für die Qualitätssicherung in der Ent-
wicklung von Software. In drei Teilen beschreibt diese Norm das Qualitätsma-
nagement für die Entwicklung, Lieferung und Wartung von Software. Diese
drei Teile heißen:
◗ Rahmen
◗ Lebenszyklustätigkeiten
◗ phasenunabhängige Tätigkeiten
Der Rahmen beschreibt sinngemäß, dass die Verantwortung für die Qualität der
Software bei der obersten Leitung des Auftraggebers und des Lieferanten liegt.
Die einzelnen Aspekte der Qualitätssicherung werden bei den Lebenszyklustätig-
keiten beschrieben. Dazu gehören:
◗ Festlegung der Anforderungen
◗ Planung der Entwicklung
◗ Planung der einzelnen Phasen
◗ Testen der Software
Zum Abschnitt der phasenunabhängigen Tätigkeiten gehören Aspekte, die in jeder
Phase des Projektes von Bedeutung sein können, z.B. die Lenkung der Doku-
mente, Regeln, Werkzeuge und die Schulung.
Wie eingangs bereits erwähnt, werden innerhalb des Software-Life-Cycles in
einzelnen Phasen verschiedene Tests durchgeführt. Um den Anforderungen der
führenden Qualitätsnorm für die Softwareentwicklung, DIN ISO 9000-3, auch
bei der Einführung der R/3-Software in optimaler Weise gerecht werden zu
können, ist das Testen, wie bei den Lebenszyklustätigkeiten der DIN ISO 9000-
3 beschrieben, eine sehr wichtige, unverzichtbare Projekttätigkeit, die von der
SAP durch das SAP-eigene Testwerkzeug Computer Aided Test Tool (CATT)
und die Testworkbench unterstützt wird.
Aus den vorgenannten Gründen soll nun zunächst der Begriff des Testens näher
erläutert werden. Anschließend wird auf die wichtigsten Testarten näher einge-
gangen. Die Tests, welche mit Hilfe von CATT abgearbeitet werden können,
sind entsprechend kommentiert.
1.3.1 Definition Testen

Unter Testen im klassischen und im engeren Sinn versteht man in der heutigen
Datenverarbeitung die Prüfung von kodierten Programmen sowohl auf korrek-
te Formulierung als auch auf richtige Ausführung hin. Demzufolge ist Testen
ein analytisches Verfahren, welches bereits nach der Programmierung beginnt.
40
Sandini Bib
Neueste Ansätze versuchen heute, Fehler bereits vor und auch während der
Entwicklung der Programme so weit wie möglich zu vermeiden.
Ziel des Testens ist es, alle im Testobjekt vorhandenen Fehler zu erkennen und
zu lokalisieren. Testen verfolgt also die Zielsetzung, möglichst viele Fehler zu
entdecken, um der Restfehlerzahl Null so nahe wie möglich zukommen. Natür-
lich sind die Ziele des Testens auch vom Nutzer der Testergebnisse abhängig,
der Entwickler, Anwender, Qualitätssicherungsbeauftragter oder auch Mana-
ger sein kann.
Als Fehler bezeichnet man jede Abweichung des Verhaltens von dem in der An-
forderungsdefinition des Programmes festgelegten Verhalten. Testen ist also
eine das Softwareentwicklungsprojekt begleitende Maßnahme zur Software-
qualitätssicherung nach Qualitätsnormen wie z.B. DIN ISO 9000-3.
An die Qualität des Testens sind entsprechend obiger Norm die Anforderungen
zu stellen, dass
◗ Tests wiederholbar, nachvollziehbar und vollständig sind,
◗ sie klare Ziele erfüllen,
◗ sie wie Softwareprodukte vollständig und lesbar dokumentiert sind,
◗ sie geplant, vorbereitet und der Qualitätssicherung unterworfen sind.
Diese Anforderungen werden durch die SAP-Testwerkzeuge CATT und Test-
workbench in idealer Weise erfüllt:
◗ CATT ermöglicht es dem Anwender, Tests wiederholbar zu gestalten. Sie
werden mit Hilfe des CATT-eigenen Testprotokolls vollständig dokumen-
tiert und sind somit für jeden Benutzer Schritt für Schritt nachvollziehbar.

Diese Protokolle stehen dem Anwender permanent zur Verfügung.
◗ Die Planung, die Vorbereitung und der Qualitätssicherungsplan zum Testen
mit CATT kann mittels der Testworkbench in äußerst komfortabler Art und
Weise vorgenommen werden.
Testobjekte im Sinne des Testens von Software sind Computerprogramme, wel-
che in unterschiedlichen Sprachen erstellt sein können.
Tests geschehen z.B. durch frühzeitiges Überprüfen der Systemanforderungen
und der Programmspezifikationen im Hinblick auf Vollständigkeit und Wider-
spruchsfreiheit sowie durch die strenge Kontrolle der Einhaltung verbindlich
festgelegter Methoden und Verfahren des System- und Programmentwurfs.
Über alle Phasen der Softwareentwicklung hinweg finden Testaktivitäten statt.
Der »Testausführende« kann hierzu auch die Hilfe eines Computers, falls dieser
mit den entsprechenden Softwaretools ausgestattet ist, in Anspruch nehmen.
All die hier beschriebenen Anforderungen an das Testen können bei Einführung
der betriebswirtschaftlichen Standardsoftware SAP R/3 mit Hilfe der SAP-Tools
Computer Aided Test Tool (CATT) und Testworkbench optimal erfüllt werden.
41
Sandini Bib
1.3.2 Testarten
Symbolischer Test
Der symbolische Test kann als Vorstufe des Testens angesehen werden. Hier
wird zunächst rein formal geprüft, ob der Code des Programms den Vorgaben
entspricht. Das Programm als solches wird hier noch nicht gestartet. Die einzel-
nen Teile des Programms bzw. das vollständige Programm werden manuell mit
wenigen Testdaten durchgespielt. Leider wird der symbolische Test häufig ver-
nachlässigt. Dies hat zur Folge, dass mit dem eigentlichen computergestützten
Testen meist zu früh, d.h. bevor ein ausgereiftes Programm besteht, begonnen
wird [/Stahlknecht95/304].
Modultest
Der Modultest stellt die erste, unterste Stufe des computergestützten Testens bei
der Softwareentwicklung dar. Zuerst werden hierbei alle elementaren Bausteine
als Fundament eines Programmsystems getestet und dann erst ihre Integration.
Es werden also alle Funktionen, die selbst keine anderen Programmbausteine
benötigen, getestet, dann erst ihre Integration zu einem Modul. Die Minimalfor-
derung für den Test eines Softwaremoduls muss dabei sein, dass mindestens
alle Programmzweige einmal durchlaufen werden und das Modul gemäß seiner
Spezifikation reagiert [/Frick95/41]. Man bezeichnet den Modultest auch als
Einzeltest.
Der Modultest testet, ob das einzelne SAP R/3-Modul richtig arbeitet. So wer-
den die einzelnen Transaktionen eines Moduls einem Test unterzogen. Alle bei
einem R/3-Einführungsprojekt durchzuführenden Modultests können mit dem
Computer Aided Test Tool automatisiert und wiederholt durchgeführt werden.
Jeder dieser CATT-gestützten Modultests wird anhand eines Testprotokolls,
welches im R/3-System archiviert wird, genau dokumentiert. Der Modultest
kann unter Zuhilfenahme der Testworkbench geplant und strukturiert werden.
Integrationstest
Nach dem Modultest folgt in der nächsthöheren Stufe der Integrationstest, auch
Komponententest genannt, welcher die Integration mehrerer, bereits getesteter
Module zu einem Subsystem einem Test unterzieht (man bezeichnet dies auch
als »inkrementelle Integration« [/Stahlknecht95/305]), bis letztlich die Integra-
tion der Subsysteme, d.h. das Gesamtsystem, getestet werden kann.
Beim Integrationstest im Zuge eines R/3-Einführungsprojektes wird z.B. über-
prüft, ob die verschiedenen Geschäftsprozesse über die Modulgrenzen hinweg
mit SAP R/3 fehlerfrei abgebildet werden können. In diesem Kontext kann z.B.
ermittelt werden, ob die Schnittstellen zwischen den einzelnen Modulen richtig
arbeiten und die Daten fehlerfrei von einem Modul zum anderen weitergegeben
42
Sandini Bib
werden. Dies ist für die Funktionsüberprüfung des Produktivsystems äußerst

wichtig. Es ist die Simulation eines realen Betriebs.
Der Integrationstest beinhaltet die Überprüfung aller Abhängigkeiten der Ge-
schäftsprozesse in der Wertschöpfungskette sowie Schnittstellen, Ausgabe- und
Druckfunktionen und Systemerweiterungen. Entfernte Standorte sind im Test
enthalten. Idealerweise wird der Integrationstest im Qualitätssicherungssystem
ausgeführt.
Auch beim SAP R/3-Integrationstest gilt: Jeder durchzuführende Integrations-
tests kann mit CATT automatisiert und wiederholt durchgeführt werden. Jeder
dieser CATT-gestützten Integrationstests wird anhand eines Testprotokolls,
welches im R/3-System archiviert wird, genau dokumentiert. Der Integrations-
test kann unter Zuhilfenahme der Testworkbench geplant und strukturiert wer-
den.
Programmtest
Modul- und Integrationstest bilden zusammen den sogenannten Programmtest.
Dieser ist ausschließlich Aufgabe der Entwickler. Nach Durchführung des Pro-
grammtests wird die Fachabteilung in das Testgeschehen involviert. Nun be-
ginnt das Testen im weiteren Sinne, da sich die Tests jetzt nicht mehr nur auf
einzelne Programme beziehen, sondern auf das vollständige Anwendungs-
system [/Stahlknecht95/305].
Systemtest
In dieser Testphase wird das Zusammenspiel zwischen den Subsystemen getes-

tet. Die Tests beziehen sich auf Aufgabenerfüllung und Systemeigenschaften
wie Leistung, Robustheit und Zuverlässigkeit. Diese unterschiedlichen Tests
sollen zeigen, inwieweit das Gesamtsystem die in den Spezifikationen festgeleg-
ten Anforderungen erfüllt. Damit wird das Gesamtsystem verifiziert.
Der Systemtest führt eine Überprüfung durch, ob das zukünftige SAP R/3-
System in der Zielumgebung problemlos ablauffähig ist. CATT kann in diesem
Zusammenhang im Konsolidierungssystem eingesetzt werden.
Bei Einführung des R/3-Systems nach der ASAP-Einführungsmethode sind im
optimalen Fall folgende Systemtests durchzuführen:
◗ System- und Durchsatztest:
Der Zweck dieses Tests ist es, die Konfiguration und die Verfahren für die
technische Produktivumgebung zu prüfen. Jede Aufgabe muss getestet und
auch gegengetestet werden, um die Datensicherheit des Produktivsystems
zu gewährleisten.
43
Sandini Bib
◗ Stresstest:
Durch diese Aktivität soll sichergestellt werden, dass die konfigurierte Pro-
duktivumgebung für den Produktivbetrieb aller notwendigen Geschäftspro-
zesse realisierbar ist und dem Anwender die Möglichkeit bietet, vor Anlauf
der Produktion potentielle Verbesserungsmöglichkeiten der Systemperfor-
mance zu erkennen. Der abschließende Testplan legt die zu verarbeitenden
Transaktionen, die Datenmengen und die geforderten Performance-Levels
fest.
◗ Systemadministrationstest:
Zweck dieser Aufgabe ist es, die für die Produktivumgebung definierten Sys-
temadministrationsprozeduren mehrmals zu testen, bis die gewünschten Er-
gebnisse erzielt werden. Hier testet man die im SAP-Systemhandbuch
angegebenen Aktivitäten eines Systemverwalters, wie die Verwaltung der
Jobplanung, Korrektur- und Transportverwaltung, Reaktion auf R/3-Sy-
stem-Alerts und -Protokolle.
◗ Disaster-Recovery-Test:
Ziel dieser Testaktivität ist es, den Disaster-Recovery-Plan und die Prozedu-
ren für die Produktivumgebung mehrmals zu testen. Wurden diese Services
einem anderen Unternehmen in Auftrag gegeben, sollte man bei dieser Ge-
legenheit deren Service und Effektivität testen. Sicherzustellen ist, dass die
gesamte technische Infrastruktur reproduzierbar ist. Auch Netzwerk, Sys-
temhardware, Leistung, Druckergebnis, Benutzerkonfiguration usw. müs-
sen hier getestet werden.
◗ Backup- und Restore-Verfahren:
Zweck dieser Aufgabe ist es, die Verfahren für Backup und Restore in der
Produktivumgebung mehrmals zu testen, bis die gewünschten Ergebnisse
erzielt werden; dazu gehören verschiedene Tests von Datenzerstörungssze-
narien (beispielsweise Hardwarefehler wie Festplattenfehler oder CPU-Feh-
ler) sowie von Anwenderfehlern wie versehentliches Löschen von Daten.
Abnahmetest
Den Abschluss des Testverfahrens bei der Softwareentwicklung bildet der Ab-
nahmetest. Er wird häufig auch als Einsatztest bezeichnet. Dieser Test hat die
Aufgabe, nachzuweisen, dass die im Pflichtenheft aufgeführten Anforderungen
erfüllt sind. Die dort festgelegten Testfälle werden dabei dem Abnahmetest zu-
grunde gelegt. Am Abnahmetest sind nicht nur die Fachabteilung, sondern
auch alle vor- und nachgeschalteten Stellen beteiligt. Im Rahmen der Abnahme-
tests ist der Beweis für die Korrektheit des Anwendungssystems zu erbringen.
Damit wird das Anwendungssystem validiert.
44
Sandini Bib
Regressionstest
Der Regressionstest überprüft, ob nach einem Releasewechsel dieselbe Funktio-
nalität zur Verfügung steht wie zuvor. Hier kann CATT ebenfalls effektiv einge-
setzt werden.
1.4 Debugging
In enger Verbindung zum Testen steht das Debugging. Deshalb sei es an dieser
Stelle der Vollständigkeit halber noch erwähnt.
Während das Testen hilft, Fehler aufzudecken, ist das Debugging eine Tätigkeit
zum Auffinden und zur Behebung von Fehlerursachen [/Stahlknecht95/305].
Testen und Debugging sind also unterschiedliche, aber sich ergänzende Aktivi-
täten. Man unterscheidet drei Methoden des Debugging:
◗ Induktion
◗ Deduktion
◗ Rückverfolgung
1.4.1 Induktion
Hier werden Informationen über die Fehlersymptome gesammelt, und zwar so
viel wie möglich, und anschließend einer Auswertung unterzogen. Im nächsten
Schritt werden eine oder mehrere Hypothesen über die Fehlerursache aufge-
stellt. Diese Hypothesen vergleicht man mit den beobachteten Informationen.

Wenn hier nun Übereinstimmung vorliegt, werden die Fehler behoben und dies
durch Folgetests bestätigt.
1.4.2 Deduktion
Hier werden sämtliche hypothetisch möglichen Ursachen der aufgedeckten
Fehler sukzessive auf ihre Richtigkeit hin überprüft, wobei diese Hypothesen
Schritt für Schritt bis auf eine letzte verworfen werden. Die Fehlerkorrektur
wird anschließend anhand der Übereinstimmung von hypothetischer Ursache
und Fehlersymptom vorgenommen.
1.4.3 Rückverfolgung
Bei der Rückverfolgung wird der Quellcode des Programms, ausgehend von
der Fehlerstelle, in rückwärtiger Richtung untersucht, bis die Fehlerquelle iden-
tifiziert werden kann [/Trauboth93/197].
45
Sandini Bib
1.5 CASE-Werkzeuge
Das computergestützte Testen ist umso effizienter, je mehr Testhilfen (Debug-

ger) zur Verfügung stehen. Dazu zählt man u.a. Programme zur Ablaufüber-
wachung (tracing), Ablaufrückverfolgung (backtracing) und Ablaufprotokollie-
rung (logging). Testhilfen sind der systemnahen Software zuzuordnen und
werden oft als Bestandteil von Softwareentwicklungswerkzeugen angeboten.
Als Softwareentwicklungswerkzeug, kurz Werkzeug (Tool), definiert man ge-
nerell ein Programm, welches die Systementwicklung vereinfacht und/oder be-
schleunigt und dabei die Softwarequalität gleichzeitig verbessert [/Stahl-
knecht95/307ff.].
1.5 CASE-Werkzeuge
1.5.1 Definition: CATT – das CASE-Tool

Unter dem Begriff CASE lassen sich alle Werkzeuge der computergestützten
Softwareentwicklung zusammenfassen. [/Jamin94/73] CASE steht als Abkür-
zung für den Fachterminus Computer Aided Software Engineering [/Beims95/5]
»und drückt aus, dass eine professionelle Softwareerstellung ohne Computer-
unterstützung nicht mehr möglich ist« [/Balzert98/592]. Für das Wort »aided«
wird oft auch der Begriff »assisted« verwendet [/Frick95/320].
»Der CASE-Begriff wurde bereits 1981 von John Manley (Carnegie Mellon Uni-
versity) geprägt. Bedeutung erlangte er aber erst Mitte der 80er Jahre. Es exis-
tiert noch keine allgemeingültige Definition, und demzufolge ist die Spannweite
der Interpretation weit.« [/Schneider97/790] Im heutigen Sprachgebrauch ist
man sich jedoch größtenteils einig, dass es sich bei CASE um ein Bündel von
leistungsstarken Methoden und Werkzeugen handelt, mit deren Hilfe man den
wachsenden Aufwand bei der Softwareerstellung durch Automatisierung und
Standardisierung in den Griff bekommen kann. [/Beims95/790] »Prinzipiell fal-
len hierunter alle computergestützten Hilfsmittel, die in irgendeiner Art und
Weise die Entwicklung von Software unterstützen – somit auch ein besserer
Editor oder ein Debugger.« [/Frick95/320]
Zur Erläuterung des CASE-Begriffes seien der einschlägigen Literatur beispiel-
haft zwei Definitionen entnommen. Bieberstein z.B. definiert CASE wie folgt:
»1. SE = Software Engineering, heißt:
– ingenieurmäßiges Planen und Entwickeln
– durch Methoden gestütztes Vorgehen
– Nutzung abstrahierender Darstellungstechniken
– Beachtung des Prinzips der schrittweisen Verfeinerung
– Wiederverwendung von Bauteilen
– Einsatz von Prototypen
– Vorgaben zur automatisierten Herstellung
46
Sandini Bib
2. CA = Computer Aided, heißt:

– vielfältige Nutzung von graphischen Editoren
– ausführliches Data Dictionary bzw. Repository
– automatische Konsistenzprüfungen der Analyse- und
Entwurfsdokumente
– automatische Erzeugung von Testfällen
– Animation und Simulation des Entwurfs durch Interpretation der
erfaßten Daten
– Systeme zum umfassenden Prototyping einschließlich Debugging
der formalen Spezifikationen
– Verknüpfung der Analyse- und Entwurfsaufgaben mit Prozess-
planungswerkzeugen
– Erfassung von Meßwerten zum Qualitätsnachweis
– automatische Dokumentationserstellung und -verwaltung
– (halb-)automatische Generierung von ablauffähigen Systemen«.
[/Bieberstein93/3]
Die Definition von Jamin lautet:
»CASE ist die Bezeichnung für eine Familie von Software-Produkten, deren An-
wendungsziel es ist, eine ingenieurmäßig ausgerichtete Software-Entwicklung
mit computergestützten Werkzeugen (Tools) zu unterstützen. CASE-Tools stel-
len dabei ideal-typisch eine Software-Entwicklungsumgebung zur Verfügung,
bei der alle Schritte (Phasen) der Software-Entwicklung [...] unterstützt und
auch zumindest teilweise automatisiert werden.« [/Jamin94/73]
CASE ist, wie man nun anhand der ausführlichen Definitionen von Bieberstein
und Jamin abschätzen kann, ein sehr umfangreicher und vielschichtiger The-

menkomplex. Nachfolgend sollen folgende Themen herausgegriffen und be-
sprochen werden: CASE-Plattform, CASE-Umgebung, CASE-Werkzeugkatego-
rien, Ziele und Vorteile von CASE sowie eine abschließende Kritik an diesen
Tools.
Die computergestützten Hilfsmittel lassen sich neben den beschriebenen CASE-
Tools noch in CASE-Plattformen gliedern. Beide zusammen ergeben die CASE-
Umgebung.
1.5.2 CASE-Plattform
Die CASE-Plattform, wie z.B. die SAP-ABAP/4 Development Workbench, bil-
det dabei den einheitlichen Integrationsrahmen, in den einzelne CASE-Werk-
zeuge nach Bedarf eingefügt werden können. [/Frick95/321] Weil die CASE-
Plattform Basisdienstleistungen zur Verfügung stellt, werden die einzelnen
CASE-Werkzeuge von diesen Dienstleistungen entlastet, d.h., diese Dienstleis-
tungen müssen selbst nicht noch einmal angeboten werden.
47
Sandini Bib
1.5 CASE-Werkzeuge
Mit den CASE-Plattformen realisiert man das Ziel, den Entwicklern eine einheit-
liche Benutzerschnittstelle für unterschiedliche Werkzeuge zur Verfügung zu
stellen. Darüber hinaus wird durch eine gemeinsame Verwaltung der Daten
echte Datenintegrität erreicht. Dann ist es nämlich möglich, dass verschiedene
Werkzeuge mit einem gemeinsamen Datenbestand arbeiten. Man bezeichnet
diese gemeinsame Datenbank als Repository oder Objekt-Management-System.
Somit wird es ermöglicht, dass Tool A nach Beendigung seiner Aufgabe Ergeb-
nisse zur Verfügung stellt, welche dem Tool B als Entwicklungsbasis dienen.
Die Endergebnisse des Tools B werden dann von Tool C weiterverarbeitet usw.
Schließlich ist zu den CASE-Plattformen noch zu sagen, dass es keinen allge-
meingültigen Standard für diese Plattformen gibt. Man kann also nicht davon
ausgehen, dass die CASE-Tools unterschiedlicher Hersteller auf einer CASE-
Plattform lauffähig sind.
1.5.3 CASE-Umgebung
»Eine CASE-Umgebung, auch Software-Entwicklungsumgebung genannt, be-
steht, zumindest konzeptionell, aus einer CASE-Plattform und mehreren darin
integrierten CASE-Werkzeugen. Sie ist eine organisatorische und computer-
unterstützte Arbeitsumgebung, die möglichst viele Tätigkeiten der Softwareer-
stellung (Entwicklung, Qualitätssicherung, Management) integriert unter-
stützt.« [/Balzert98/592]
Seit Anfang der 80er Jahre werden von Hard- und Softwareherstellern unter
dem Kürzel CASE eine Vielzahl von Programmen zur Unterstützung des Soft-
wareentwicklungsprozesses angeboten, so z.B. CATT.
CASE-Werkzeuge können in verschiedenen Werkzeugkategorien zusammen-
gefasst werden, je nachdem welche Schwerpunkte die Werkzeuge oder Werk-
zeugkombinationen bieten. Dabei lassen sich folgende Werkzeugkategorien un-
terscheiden:
◗ Upper CASE
◗ Lower CASE und
◗ I-CASE.
1.5.4 CASE-Werkzeugkategorien
Upper CASE
Dies ist die Bezeichnung für Werkzeuge, die eine »höhere« konzeptionelle Ana-
lyse- und Design-, aber auch Planungsmethode unterstützen. [/Himmler94/9]
Upper-CASE-Tools sind also Werkzeuge, welche in den ersten Phasen einer
Softwareentwicklung hilfreich sind. [/Balzert98/594]
48
Sandini Bib
Nach Bieberstein dienen diese Tools der Automatisierung von Analyse und Ent-
wurf. [/Bieberstein93/23] Diese Werkzeuge bieten grafische Unterstützung für
Organigramme, Datenflußpläne, Entscheidungstabellen sowie für die verschie-
denen Darstellungsmethoden im Rahmen dieser frühen Softwareentwicklungs-
phasen. [/Stahlknecht95/309] Die Upper-CASE-Tools sollen in den immer
komplexer werdenden Softwaresystemen die teuersten Fehler, also die Fehler in
der Analyse und Entwurfsphase, vermeiden helfen.
Upper-CASE-Werkzeuge werden heute im Allgemeinen mit dem Begriff CASE
in Verbindung gebracht und bilden den Kern für integrierte Entwicklungsum-
gebungen. Man nennt sie auch Frontend-CASE-Tools.
Lower CASE
Hier handelt es sich um eine niedrigere, maschinennahe werkzeugunterstützte
Implementierungsmethode. Entwicklungswerkzeuge, die in den späten Phasen
der Softwareentwicklung (Implementierung, Test, Einführung, Wartung und
Pflege) zum Einsatz kommen, werden in Anlehnung an einen von oben nach
unten dargestellten sequentiellen Phasenplan als niedere CASE-Werkzeuge be-
zeichnet. [/Schneider97/178] Diese Tools unterstützen das Editieren, Kompilie-
ren, Laden/Binden und Testen. Man spricht hier auch von Lower-CASE-Tools
oder Backend-CASE-Tools. [/Himmler94/138]
I-CASE
Auf dem Softwaremarkt sind bislang kaum Werkzeuge vorhanden, die den
gesamten Prozess der Softwareentwicklung vollständig abdecken. Deshalb

werden meist mehrere Werkzeuge zu einer Softwareproduktionsumgebung
(= »Werkzeugkasten«) zusammengefaßt. Hierbei handelt es sich dann um eine
integrierte Sammlung von Tools, welche die Programmentwicklung sowohl in
den frühen als auch in den späten Phasen, also über den gesamten Softwareent-
wicklungsprozess hinweg, unterstützt. [/Balzert98/595] Dementsprechend
nennt man diese »Werkzeugkästen« auch I-CASE, was als Abkürzung für »In-
tegrated-CASE« steht. [/Stahlknecht95/308] I-CASE-Tools werden auch zur
Projektleitung, Qualitätssicherung und zum Management innerhalb der Soft-
wareentwicklung eingesetzt. [/Schneider97/138] Frick verwendet als Oberbe-
griff für solche I-CASE-Systeme auch die bereits erläuterte Bezeichnung CASE-
Umgebung. [/Frick95/321]
1.5.5 Ziele von CASE

Mit CASE und damit auch mit dem Computer Aided Test Tool der SAP AG wer-
den technische, wirtschaftliche, organisatorische und psychologische Ziele ver-
folgt. Diese Ziele lassen sich wie folgt beschreiben:
49
Sandini Bib
1.5 CASE-Werkzeuge
Technische Ziele
Mithilfe der CASE-Werkzeuge sollen die Fehlermöglichkeiten bei der Software-
entwicklung verringert sowie eine ausreichende Portabilität gewährleistet wer-
den. Man setzt Generatoren ein, um Arbeitsschritte zu eliminieren. Konsistenz-
und Redundanzüberprüfungen werden durch eingesetzte Methoden ermög-
licht. Darüber hinaus soll die Qualität der Dokumentation verbessert und die
Wiederverwendbarkeit erleichtert werden.
Wirtschaftliche Ziele
Die CASE-Tools sollen helfen, die Produktivität der Softwareentwicklung zu er-
höhen, den Wartungsaufwand zu senken, die Personenabhängigkeit zu verrin-
gern und auch die Flexibilität zu erhöhen. Dies soll Änderungen auch kurz vor
der Markteinführung noch ermöglichen.
Organisatorische Ziele
Mit dem Einsatz von CASE-Tools soll bei der Durchführung eines Softwareent-
wicklungsprojektes die Projektkoordination verbessert und die Flexibilität des
Personaleinsatzes erhöht werden.
Psychologische Ziele
Die Reduzierung von Routinetätigkeiten und die Förderung von kreativem Ar-
beiten lassen sich als psychologische Ziele des CASE-Einsatzes klassifizieren.
Fazit
Generelles Ziel von CASE und damit auch von CATT muss es sein, den Ent-
wickler nicht mit zusätzlichen Tätigkeiten zu belasten, sondern ihm die Routi-
netätigkeiten so weit wie möglich abzunehmen. Der Softwareentwickler soll
sich auf die kreativen Aspekte seiner Tätigkeit konzentrieren. Besonders zu be-
tonen ist, dass CASE nicht dazu führen darf, dass Softwareerstellung in »Soft-
ware-Bürokratie« ausartet. Der Verwaltungsaufwand muss wesentlich geringer
sein, als wenn man Software ohne CASE erstellt. [/Balzert98/597]
Daraus kann man also folgendes ableiten: »Unterm Strich soll mit CASE bzw.
mit CASE-Tools die Softwareentwicklung wirtschaftlicher und flexibler ge-
macht werden. Dabei soll der gesamte Entwicklungsprozess durchgängig abge-
wickelt und automatisiert werden – von der Planung bis zur Implementierung.«
[/Himmler94/9] CASE-Werkzeuge sollen also helfen. die gewünschten Ergeb-
nisse kostengünstiger und mit höherer Qualität zu erhalten.
50
Sandini Bib
1.5.6 Vorteile der CASE-Systeme

In der übersichtlichen Dokumentation des Entwicklungsprozesses und in den
dadurch bedingten änderungsfreundlich gehaltenen Analyse-Ergebnissen lie-
gen die großen Vorteile der CASE-Systeme. Dadurch kann bei der Software-
Wartung, also wenn die entwickelte Software bereits eingesetzt wird, auf die
entsprechenden Ergebnisse der einzelnen Phasen der ursprünglichen Software-
entwicklung zurückgegriffen werden. Dies hat den positiven Effekt, dass da-
durch die Software-Wartung nicht unwesentlich rationalisiert werden kann.
Nach Frick nehmen sowohl der Umfang als auch die Komplexität der Anforde-
rungen an die Systementwicklung permanent zu. Aus diesem Grunde wird es
wohl zukünftig nicht mehr möglich sein, Systeme ohne Unterstützung von in-
genieurmäßigen Methoden und Verfahren in hoher Qualität zu erstellen. Insbe-
sondere der Upper-CASE-Bereich wird für die Aufgaben der Zukunft nicht
mehr zu umgehen sein.
1.5.7 Kritik
Man sollte aber bedenken: CASE ist kein Allheilmittel, sondern eine notwendi-
ge, aber nicht hinreichende Voraussetzung für erfolgreiche Softwareentwick-
lung. Denn »CASE löst nicht die Probleme einer Softwareerstellung. Ein guter
Softwareingenieur wird mit CASE schneller bessere Software erstellen. Ein
schlechter Softwareingenieur wird mit CASE in kürzerer Zeit noch mehr
schlechte Software erstellen.« [/Balzert98/597] Computergestützte Werkzeuge
allein reichen nicht aus, um dann »automatisch« Software hoher Qualität zu

produzieren. Die Rechnerunterstützung ist stets nur ein Baustein eines umfas-
senden Qualitätssicherungssystems bei der Softwareentwicklung. [/VDI92/1]
Wie bereits geschildert, wird die Entwicklung von Anwendungssystemen
durch die vorbeschriebenen CASE-Tools wie z.B. CATT bei SAP R/3 unter-
stützt. Wenn für ein Anwendungssystem die Software im Rahmen einer profes-
sionellen Systementwicklung entweder durch firmeneigene Entwickler und
Programmierer oder durch eine unternehmensexterne Software-Firma unmit-
telbar und speziell für eine konkrete Anwendung entwickelt wird, spricht man
von Individualsoftware. Anwendungssoftware wird heute jedoch in den meisten
Fällen nicht mehr als Individualsoftware entwickelt, sondern in Form von Stan-
dardsoftware gekauft.
Im folgenden wird deshalb nun zunächst der Fachterminus »Standardsoftware«
näher erläutert und anschließend kurz die R/3-Software charakterisiert.
51
Sandini Bib
1.6 Standardsoftware
1.6.1 Definition
Der Einsatz von Standardsoftware nimmt in den heutigen Unternehmen aller
Branchen und Größenordnungen kontinuierlich zu. Es handelt sich bei Stan-
dardsoftware um fertige Programmpakete, die aus einer Vielzahl von Program-
men bestehen und zusammen ein abgeschlossenes betriebliches Anwendungs-
gebiet abdecken. Diese Programmpakete wurden so entwickelt, dass sie einer
größeren Zahl von Anwendern für deren Aufgabenstellung genügen. Daraus
ergeben sich erhebliche Kostenvorteile und eine höhere Qualitätssicherheit.
1.6.2 Eigenschaften
Nach Stahlknecht weisen diese Programmpakete folgende Eigenschaften auf:
»Das Programmpaket übernimmt ein eindeutig definiertes betriebliches An-
wendungsgebiet, beispielsweise Fakturierung, Anlagenrechnung oder Perso-
nalabrechnung. Das Programmpaket bzw. die einzelnen Programme haben ei-
nen Festpreis für die Grundversion. Die Anpassung an die individuellen
betrieblichen Anforderungen wird nach Aufwand berechnet.«
Standardsoftware ist definitionsgemäß weitgehend branchenunabhängig. Auch
anwendungsorientierte Programme können in Form von Standardsoftware auf-
treten, werden dann jedoch meist als Standardanwendungssoftware bezeichnet.
Anwendungssoftware, welche auf die Anforderungen bestimmter Branchen zu-
geschnitten ist, wird als Branchensoftware bezeichnet. Man kann in diesem Kon-
text auch von sogenannten Branchenmodellen sprechen (auch »preconfigured
systems« genannt). Da bei den Merkmalen und im Auswahlprozess zwischen
Branchen- und Standardsoftware keine grundsätzlichen Unterschiede bestehen,
wird allgemein nur von Standardsoftware gesprochen. Standardsoftware für
branchenneutrale Anwendungen wird meist in Form modular aufgebauter, in-
tegrierter Pakete angeboten, wobei die einzelnen Module den betriebswirt-
schaftlichen Arbeitsgebieten Rechnungswesen, Logistik und Personalwirtschaft
entsprechen. [/Stahlknecht95/240]
1.6.3 Customizing
Die Standardsoftwareprogramme müssen in der Regel noch an die speziellen
Anforderungen des Unternehmens angepaßt werden. Für die Anpassung von
Standardsoftware an die betrieblichen Anforderungen, auch Customizing (engl.
»auf Maß anfertigen; Anpassung einer Standardsoftware auf die speziellen An-
forderungen des Kunden« [/Thome96/166]) genannt, gibt es im Wesentlichen
drei Möglichkeiten:
52
Sandini Bib
◗ Parametrisierung
◗ Konfigurierung
◗ Individualprogrammierung
Parametrisierung
Hier werden die gewünschten Funktionen des Programms durch das Setzen
von Parametern initialisiert. Als Voraussetzung wird hierfür benötigt, dass alle
erdenklichen Programmfunktionen in der Standardsoftware vorhanden sind.
Konfigurierung
Lediglich die gewünschten Programmbausteine werden bei der Konfigurierung
(wird auch als Modularisierung bezeichnet) in das Software-Paket aufgenom-
men. Die Generierung erfolgt per Computer durch Auswahl aus den vorhande-
nen Bausteinen.
Individualprogrammierung
Dies bedeutet, dass für die erforderlichen Anpassungen Software individuell er-
stellt wird. Die so modifizierte Standardsoftware wird den Kundenanforderun-
gen am besten gerecht, ist allerdings auch am teuersten.
Eine Alternative zur Adaption der Standardsoftware ist die Anpassung der Ab-
lauforganisation, z.B. durch eine Reorganisation der Geschäftsprozesse, die
auch eine Veränderung der Aufbauorganisation bewirken kann. In gleichzeiti-
gen Anpassungen sowohl der Standardsoftware als auch der betrieblichen Or-

ganisation besteht häufig die zweckmäßigste Lösung.
Mit Hilfe des Testwerkzeugs CATT können die Auswirkungen von Customi-
zing-Einstellungen überprüft und im Bedarfsfall wieder zurückgesetzt werden.
1.6.4 Ziele des Einsatzes von Standardsoftware

Wesentliches Ziel der Nutzung von betrieblicher Standardsoftware ist es, Perso-
nal-, Softwareentwicklungs-, Schulungs- und Wartungskosten erheblich zu re-
duzieren. Weitere positive Effekte, die von der Nutzung integrierter Standard-
software erwartet werden, sind auch:
◗ die Wahrung der Integrität der Unternehmensdaten
◗ die sofortige Verfügbarkeit aller Unternehmensdaten für jeden Mitarbeiter
◗ die bereichsübergreifende Betrachtung der im Betrieb zu bearbeitenden Ge-
schäftsvorfälle und Objekte wie Auftrag, Bestellung, Rechnung etc.
53
Sandini Bib
◗ eine flexible Änderung von betriebswirtschaftlichen Abläufen innerhalb des

vom Softwareanbieter angebotenen Lösungsspektrums [/Keller97/58]
Auf dem weltweiten Standardsoftwaremarkt sind viele Programmpakete diver-
ser Softwarefirmen erhältlich. »R/3« ist z.B. die Bezeichnung für die weltweit
eingesetzte betriebswirtschaftliche Standardanwendungssoftware der SAP AG,
Walldorf.
1.6.5 SAP-System R/3

R/3 ist mit seiner offenen Konzeption auf den Einsatz in Client/Server-Archi-
tekturen ausgerichtet, wobei die Anwendungen auf mehrere Rechnerebenen
verteilt werden können. Das R/3-System erlaubt den Firmen einen wesentlich
flexibleren Umgang mit Unternehmensdaten. Außerdem ist die R/3-Software
für den Einsatz auf Betriebssystemen verschiedener Hersteller konzipiert. R/3
löste damit eine technologische Revolution aus. Seitdem steht die SAP AG nicht
nur an erster Stelle der deutschen Softwarehäuser, sondern gehört auch interna-
tional zur Spitzengruppe. R/3 ist heute weltweit der Standard für betriebliche
Anwendungssoftware. Das R/3-System verfügt über folgende Spezifika:
◗ Integration
◗ Internationalität
◗ Branchenneutralität und Anpassungsfähigkeit
◗ Datenkonsistenz
◗ Benutzeroberfläche
◗ Modularer Aufbau
Integration
Das R/3-System weist eine umfassende Funktionalität auf. Das Finanzwesen
beispielsweise profitiert von den Funktionen anderer Anwendungsbereiche wie
Einkauf, Vertrieb oder Personalwesen, von denen es seine Buchungsdaten be-
zieht. Die Integration der Anwendungen gewährleistet die Durchgängigkeit al-
ler Funktionen im System und damit auch im Unternehmen.
Internationalität
Mit dem R/3-System können Unternehmen, sowohl international tätige als
auch multinationale Konzerne, auf einem gemeinsamen Rechner die betriebli-
chen Abläufe unterschiedlicher Landesgesellschaften durchführen und länder-
übergreifende Vorgänge in einem System abwickeln.
54
Sandini Bib
Branchenneutralität und Anpassungsfähigkeit

Durch das sogenannte Customizing erfolgt die Anpassung des R/3-Systems an
branchenspezifische Besonderheiten. Die Branchenneutralität der R/3-Software
zeigt sich am besten, wenn man die Liste der SAP-Kunden, die aus den verschie-
densten Bereichen stammen, betrachtet. Das R/3-System kann sowohl bei gro-
ßen Konzernen als auch bei mittelständischen Unternehmen eingesetzt werden.
Datenkonsistenz von R/3

Daten werden im R/3-System konsequent nur einmal gespeichert. Somit kön-
nen diese für jede Auswertung in jedem Unternehmensbereich konsistent abge-
rufen werden. Das Risiko unabgestimmter und nicht aktueller Datenbestände
sowie darauf aufbauender fehlerhafter Auswertungen wird damit vermieden.
Benutzeroberfläche
Die Benutzeroberfläche des R/3-Systems entspricht größtenteils der von MS-
Windows. Dies führt, verglichen mit dem R/2-System, welches noch nicht über
eine derartige Oberfläche verfügte, zu erheblich größerem Benutzerkomfort.
Modularer Aufbau
Das R/3-System ist in einzelne Module unterteilt. Jedes dieser Module besteht
seinerseits wieder aus einzelnen Komponenten und Subkomponenten. Die ver-
schiedenen R/3-Module können einzeln erworben werden; allerdings ist hier-
bei darauf zu achten, dass bestimmte Komponenten alleine nicht lauffähig sind.

Die verschiedensten Aktivitäten in den einzelnen Phasen bei der Einführung
der Standardanwendungssoftware SAP R/3 können unter Zuhilfenahme des
Computer Aided Test Tools durchgeführt werden. Dieses Tool wird von der SAP
AG als integrierter Bestandteil der ABAP/4 Development Workbench ausgelie-
fert.
Zunächst soll deshalb im folgenden kurz die R/3-eigene Entwicklungsumge-
bung ABAP/4 Development Workbench mit ihren einzelnen Werkzeugen darge-
stellt und erläutert werden. Anschließend wird ausführlicher auf das CATT-
Tool sowie seine Verwendung bei der R/3-Einführung eingegangen.
55
Sandini Bib
Sandini Bib
Testumgebung in
SAP R/3-Systemen
2
2.1 ABAP/4 Development Workbench
2.1.1 Allgemeine Definition

Eine rationelle Softwareentwicklung mit der Möglichkeit des Prototypings ist
eine der wichtigsten Anforderungen an die heutigen Softwareentwicklungs-
werkzeuge. Die SAP AG bietet zu diesem Zweck mit der so genannten ABAP/4
Development Workbench eine leistungsstarke Umgebung, welche die Planung
und Realisierung neuer Programme unterstützt.
Mit diesem portablen und systemunabhängigen Entwicklungswerkzeug stellt
die SAP AG ein einheitliches Instrumentarium für Modifikationen und Eigen-
entwicklungen zur Verfügung. Die ABAP/4 Development Workbench ist die
grafische Programmier- und Entwicklungsumgebung des R/3-Systems.
Entwickler können mit der Workbench folgendes tun:
◗ ABAP-Coding schreiben
◗ Dialoge mit einem grafischen Editor gestalten
◗ Menüs mit einem Menü-Editor anlegen
◗ Anwendungen auf Fehler untersuchen
◗ eine Anwendung auf ihre Effizienz testen
◗ vordefinierte Funktionen verwenden
◗ Zugriff auf Objekte steuern, die sich in der Entwicklung befinden
◗ neue Datenbankinformationen anlegen und vordefinierte Informationen an-
sprechen
57
Sandini Bib
Die ABAP/4 Development Workbench besteht aus denselben Werkzeugen, mit

denen auch das R/3-System von der SAP AG entwickelt wird.
Man findet die ABAP/4 Development Workbench innerhalb des SAP-Basismo-
duls BC. Sie umfasst ein Paket aufeinander abgestimmter Werkzeuge für die pro-
fessionelle Client-Server-Anwendungsentwicklung. Damit unterstützt die
ABAP/4 Development Workbench den gesamten Software-Entwicklungszy-
klus. Die einzelnen Werkzeuge der Workbench fügen sich zu einem integrierten
System zusammen. Wenn man beispielsweise im Editor mit Programmobjekten
arbeitet, kennt dieser Editor auch Objekte, die mit anderen Werkzeugen der
ABAP/4 Development Workbench angelegt wurden. Durch Auswahl eines Ob-
jektes mit Doppelklick wird automatisch das Werkzeug von der Workbench ge-
startet, in dem das Objekt erstellt wurde, und man kann dieses Objekt bearbeiten.
Um die Entwicklungsprozesse in dieser integrierten Umgebung zu organisieren,
bietet die SAP den Repository Browser an. Der Repository Browser liefert den
notwendigen Zusammenhang, um die Beziehungen innerhalb eines Programms
zu erfassen. Anstatt mit Werkzeugen und Entwicklungsklassen zu arbeiten, ar-
beitet man mit Objekten, und die Workbench ruft für jedes Objekt das entspre-
chende Werkzeug auf.
Man kann die ABAP/4 Development Workbench auch als CASE-Umgebung
bzw. als I-CASE-Tool (Integrated CASE Tool) bezeichnen. Die CASE-Plattform
bildet dabei den einheitlichen Integrationsrahmen, in den einzelne CASE-Werk-
zeuge nach Bedarf eingefügt werden können. Da die CASE-Plattform Basis-
dienstleistungen zur Verfügung stellt, werden die einzelnen CASE-Werkzeuge
von diesen Dienstleistungen entlastet, d.h., sie müssen diese Dienstleistungen
nicht selbst noch einmal anbieten. Anhand der CASE-Plattformen realisiert man
das Ziel, den Entwicklern eine einheitliche Benutzerschnittstelle für unter-
schiedliche Werkzeuge zur Verfügung zu stellen.
Darüber hinaus wird durch eine gemeinsame Verwaltung der Daten echte Da-
tenintegrität erreicht. Damit ist es möglich, dass verschiedene Werkzeuge mit
einem gemeinsamen Datenbestand arbeiten. Schließlich bleibt noch zu sagen,
dass es keinen allgemeingültigen Standard für CASE-Plattformen gibt. Man
kann also nicht davon ausgehen, dass die CASE-Tools unterschiedlicher Her-
steller auf einer CASE-Plattform lauffähig sind.
2.1.2 Bestandteile der ABAP/4 Development Workbench

Zum breiten Spektrum von Werkzeugen, Komponenten und Verfahren der
ABAP/4 Development Workbench gehören:
ABAP
Die ABAP/4 Development Workbench basiert auf der Programmiersprache
ABAP. ABAP steht für Advanced Business Application Programming.
58
Sandini Bib
Hierbei handelt es sich um eine anwendungsorientierte Programmiersprache

der vierten Generation (4 GL), die von der SAP AG entwickelt wurde. Sie ist für
die Entwicklung betriebswirtschaftlicher Anwendungen im Client-Server-Um-
feld besonders geeignet. Die Vorteile einer Programmiersprache der vierten Ge-
neration liegen in der leichten Erlernbarkeit, der relativ einfachen Verarbeitung
großer Datenmengen sowie in kurzen Programmierzeiten. ABAP/4 unterstützt
in der Programmentwicklung eine strukturierte Programmierung.
ABAP/4-Repository
Im R/3-Repository werden alle Entwicklungsobjekte wie z.B. ABAP-Module,
Screens, ABAP-Dictionary-Objekte, Datenmodelle und Berechtigungen zentral
abgelegt. Über das Informationssystem des Repositorys erhält der Entwickler
umfassende Auswertungsmöglichkeiten z.B. über die Verwendung von Daten.
Eine offene Repository-Schnittstelle stellt die Verarbeitung aller Repository-Ob-
jekte auch mit SAP-fremden Tools sicher.
ABAP/4-Dictionary
Das in die ABAP/4 Development Workbench integrierte ABAP/4-Dictionary
ist für den Entwickler die zentrale Informationsablage für Anwendungs- und
Sys-temdaten. Es ist ein so genanntes »aktives« Dictionary und ist als solches
vollständig mit den übrigen Entwicklungswerkzeugen in die Umgebung inte-
griert. D.h., es verwaltet zentral und aktiv alle anwendungsbezogenen be-
schreibenden Metadaten wie u.a. Tabellendefinitionen, interne Strukturen,
Felder und Bildschirmdaten. Informationen, die im ABAP/4-Dictionary ein-
gegeben werden, sind sofort im ganzen System verfügbar. Entsprechend den
im ABAP/4-Dictionary vorgenommenen Änderungen werden Daten im ge-
Kapitel 2 – Testumgebung in SAP R/3-Systemen

samten System automatisch aktualisiert.
Die wichtigsten Objekttypen im ABAP Dictionary sind Tabellen, Views, Typen,
Domänen, Suchhilfen und Sperrobjekte. Tabellen werden im ABAP Dictionary
datenbankunabhängig definiert. Aus dieser Tabellendefinition wird dann eine
Tabelle mit gleicher Struktur in der unterliegenden Datenbank angelegt. Views
sind logische Sichten auf mehrere Tabellen. Die Struktur des Views wird im
ABAP Dictionary definiert. Aus dieser Struktur kann dann ein View auf der Da-
tenbank erzeugt werden. Typen werden in ABAP-Programmen verwendet. Die
Struktur eines Typs kann global im ABAP Dictionary definiert werden. Ände-
rungen an einem Typ werden automatisch in allen Programmen wirksam, die
den Typ verwenden. Sperrobjekte dienen zur Synchronisation des Zugriffs
mehrerer Benutzer auf denselben Datenbestand. Aus der Definition eines Sperr-
objekts im ABAP Dictionary werden Funktionsbausteine generiert, die in An-
wendungsprogrammen verwendet werden können.
59
Sandini Bib
Über Domänen können verschiedene technisch gleichartige Felder zusammen-

gefasst werden. Eine Domäne beschreibt den Wertebereich der Eingabewerte
für alle Felder, die sich auf diese Domäne beziehen.
Auch die Dokumentation (F1-Hilfe) und die Eingabehilfe (F4-Hilfe) zu einem
Feld auf einer Eingabemaske stammen aus dem ABAP Dictionary. Die bei der
Eingabehilfe erscheinende Liste der möglichen Eingabewerte wird durch einen
Fremdschlüssel oder eine Suchhilfe erzeugt.
Das folgende ABAP Programm listet die in der Tabelle SCARR enthaltenen
Fluggesellschaften und deren Kürzel (Carrier-Ids) auf.
TABLES: SCARR.
SELECT * FROM SCARR.
WRITE: / SCARR-CARRID, SCARR-CARRNAME.
ENDSELECT.
Im Programm wird nur die Tabelle SCARR (mit der Anweisung TABLES:
SCARR.) deklariert. Alle Informationen zu dieser Tabelle wie z.B. Feldnamen,
Datentypen und Feldlängen sind im ABAP Dictionary definiert und werden
von dort aus beim Generieren des Programms abgerufen.
Damit muss bei einer Änderung der Tabelle, zum Beispiel bei der Veränderung
der Länge eines Tabellenfeldes, der Quelltext des Programms nicht angepasst
werden. Beim nächsten Aufruf des Programms wird in diesem Fall automatisch
festgestellt, dass sich die Struktur der Tabelle SCARR verändert hat. Das Pro-
gramm wird dann einfach neu generiert und ruft damit die aktuellen Informa-
tionen zur Tabelle SCARR aus dem ABAP Dictionarys ab. Während der Arbeit
an Entwicklungsprojekten können Objekte des ABAP Dictionary mehrfach ver-
ändert werden, bevor sie aktiviert und damit den operativen Komponenten des
Systems zur Verfügung gestellt werden. Objekte können also zum gleichen Zeit-
punkt in einer aktiven und in einer inaktiven (überarbeiteten) Version im ABAP
Dictionary vorhanden sein. Die inaktiven ABAP Dictionary-Objekte beeinflus-
sen das Laufzeitsystem (ABAP Prozessor, Datenbankschnittstelle) nicht. Damit
können größere Änderungen an mehreren Objekten durchgeführt werden,
ohne die Lauffähigkeit des Systems zu beeinträchtigen. Wenn alle Objekte geän-
dert sind, können sie dann gemeinsam aktiviert werden. Bei der Aktivierung ei-
nes ABAP Dictionary Objekts wird die Konsistenz dieses Objekts zu den bereits
aktiven Objekten geprüft. Ist keine Konsistenz gegeben, wird die Aktivierung
nicht durchgeführt.
Screenpainter und Menupainter

Mit den Tools Screenpainter und Menupainter werden die Bildschirmbilder, Me-
nüs und Dialoge für die grafische Benutzerschnittstelle angelegt, modifiziert,
angezeigt und gelöscht. Die Pflege der Bildschirmelemente erfolgt mit einem
grafischen Editor. Darüber hinaus hilft der Screenpainter dabei, allgemeine An-
gaben über Dynpros zu erfassen. Als Beispiele seien hier genannt: die Sprache,
60
Sandini Bib
in der das Dynpros abgefasst ist, oder die Form der Darstellung, ob es sich also
um ein Dialogfenster, ein Selektionsbild oder einen Eingabebildschirm handelt.
Die Dynpros des R/3-Systems sind dreistufig aufgebaut. Dieser Konstruktion
entsprechend unterstützt der Screenpainter folgende drei Aufgabenbereiche:
◗ Erfassen der Ablauflogik des Dynpros
◗ Festlegen der Feldeigenschaften des Dynpros
◗ Anordnen von Feldbezeichnungen
Durch die Verwendung des Menüpainters können die vom Programm erzeug-
ten Funktionen bestimmten Drucktasten oder Funktionstasten zugeordnet wer-
den. Sie können unter Zuhilfenahme dieses Werkzeugs auch definierten Menüs
zugewiesen werden.
ABAP/4-Workbench-Organizer
Der Workbench-Organizer unterstützt die systematische, schrittweise Vorge-
hensweise im Anwendungsentwicklungsprojekt. Der Stand der Anwendungs-
entwicklung wird hier sorgfältig koordiniert und dokumentiert. Die Entwick-
lungsobjekte werden von einem Versionsmanager verwaltet, ebenso die damit
verbundenen Korrekturen und Änderungen. Mithilfe des Transportwesens
können Entwicklungsobjekte aus der Testumgebung in die Produktivumge-
bung transportiert werden.
ABAP/4-Editor
Der Editor ist das Werkzeug, mit dem ABAP/4-Programme erstellt und getestet
werden. Zusätzlich können damit Funktionsbausteine, Dynproablauflogiken

und auch logische Datenbanken entwickelt werden. Der ABAP/4-Editor enthält
neben den üblichen Editierfunktionen wie z.B. Kopieren, Ausschneiden usw.,
auch einen Pretty Printer zur Strukturierung von Quell-Codes. Mithilfe der
Funktion Pretty Printer kann man das Layout eines Programmes erheblich ver-
bessern. Der Einsatz dieses Werkzeuges bei der Programmierung stellt sicher,
dass das Programm mit den im ABAP/4-Benutzerhandbuch aufgeführten Be-
dingungen konform geht. Besonders hervorzuheben ist an dieser Stelle noch die
systemweite Navigationshilfe für den Programmierer, die sich aus der Verwen-
dung dieses Werkzeugs ergibt.
ABAP/4-Navigation und -Browser

Der Browser listet alle Entwicklungsobjekte in Übereinstimmung mit einem
komfortablen Projektmanagementmodell auf. Der Navigator ruft Entwick-
lungsobjekte auf und aktiviert das zugehörige Tool. Navigator und Browser un-
terstützen den Entwicklungsprozess und erleichtern den Entwicklern die Orga-
nisation ihrer Arbeit.
61
Sandini Bib
ABAP/4-Data-Modeller
Der Data-Modeller ist ein Tool, mit dem Datenmodelle erstellt werden können.
Dieses Werkzeug unterstützt den Programmierer sowohl beim Design von Da-
tenbanktabellen für eigene Anwendungen als auch beim Verständnis der kom-
plexen Strukturen der R/3-Anwendungen.
ABAP/4-Query
Die ABAP/4-Query erlaubt es, ABAP/4-Reports zu erstellen, die im Standard
der R/3-Funktionalität noch nicht enthalten sind. Mithilfe der Queries können
im Speziellen auch Anwender, die weder Kenntnisse der ABAP/4-Program-
miersprache haben noch die Namen von Feldern und Tabellen kennen, eigene
einfache Auswertungen definieren. Dabei muss der Anwender lediglich die Be-
dingungen formulieren, die er an die jeweils erwünschte Auswertung stellt. Auf
der Basis dieser Angaben wird der Report, der z.B. eine entsprechende Liste lie-
fert, dann vom System automatisch generiert. Darüber hinaus besteht mittels
der Queries die Möglichkeit, Module anzupassen, Erweiterungen zu beschrei-
ben oder so genannte »Dynpros« (dynamische Programme) zu entwickeln.
Die Funktionalität eines Queries kann insbesondere im Bereich der Erstellung
von Ranglisten, Grundlisten und Statistiken genutzt werden. An den Funktions-
umfang eines klassischen ABAP/4-Reports reicht ein Query jedoch nicht heran.
Funktionsbibliothek
Mithilfe der Funktionsbibliothek können verschiedenste Funktionsbausteine er-
stellt und verwaltet werden. Funktionsbausteine sind universell einsetzbare,
wiederverwendbare Programmeinheiten. Diese Bausteine werden in der Funk-
tionsbibliothek verwaltet, die mit einer komfortablen Suchfunktion ausgestattet
ist. Die dort verwalteten und dokumentierten betriebswirtschaftlichen Funkti-
onsbausteine und Programmierhilfen lassen sich einfach in neue Entwicklungs-
objekte integrieren. Zusammen mit den R/3-Entwicklungs-werkzeugen wer-
den von der SAP AG bereits eine Vielzahl vorgedachter betriebswirtschaftlicher
Funktionen in fertigen Funktionsbausteinen ausgeliefert, welche leicht in indi-
viduell erstellte Programme übernommen werden können. Der größte Teil der
Funktionsbausteine bildet viele Anwendungsfunktionen ab, die systemweit
nutzbar sind. Die Verwendung dieser leistungsfähigen Bibliothek kann dem-
nach dazu beitragen, die Programmierzeit erheblich zu verkürzen.
Im Wesentlichen haben Funktionsbausteine folgende Eigenschaften:
◗ Funktionbausteine besitzen eine klar abgegrenzte Datenschnittstelle.
◗ Funktionsbausteine können über Remote Function Calls (RFC) systemüber-
greifend aufgerufen werden.
◗ Funktionsbausteine werden, wie bereits erwähnt, in einer Funktionsbiblio-
thek verwaltet.
62
Sandini Bib
Diese Funktionsbausteine können jederzeit in CATT-Testaktivitäten eingebunden

werden. Sie stellen einen wichtigen Bestandteil der CATT-Funktionalität dar.
Report Builder
Der Report Builder besteht aus einem interaktiven Werkzeug für die Bearbei-
tung von Listen und zur Berichtserstellung. Berichte können in einer Baum-
struktur hierarchisch abgelegt werden.
Werkzeuge für Test, Tuning und Debugging

Die Fehlersuche in ABAP/4-Programmen wird innerhalb der ABAP/4 De-
velopment Workbench durch folgende Werkzeuge unterstützt:
◗ Debugger
◗ Laufzeitanalyse
◗ Systemprotokolle
◗ SQL-Trace
◗ Computer Aided Test Tool
Debugger
Der Debugger des R/3-Systems ist ein komfortables Hilfswerkzeug für den Pro-
grammierer, das es ihm erlaubt, den Programmcode eines Programms schrittwei-
se zu verfolgen und sich Dateninhalte von Feldern anzeigen zu lassen. Mit dem
Debugger kann nach Fehlern sowohl in ABAP/4-Programmen als auch in Dyn-
pros gesucht werden. Der Debugger bietet sogar die Möglichkeit des so genannten

»Remote Debuggings«. Dadurch ist bei RFCs (Remote Function Calls) sogar eine
Fehlersuche über Systemgrenzen hinweg möglich. Dem Entwickler erleichert der
Debugger die Suche nach Fehlern sowie deren Korrektur. Dies gilt sowohl für Feh-
ler in der Anwendungslogik als auch für Fehler in der Datenbearbeitung.
Der Debugger kann angewiesen werden, den Ablauf des Programmes wahlwei-
se nach jeder Anweisung oder auch nur an bestimmten Stellen des Programms
zu unterbrechen. Anschließend informiert der Debugger über den gegenwärti-
gen Status der Verarbeitung. So können z.B. Informationen über Feldinhalte
oder interne Tabellen abgerufen werden. Zudem besteht die Option, nach Lauf-
zeitfehlern direkt in den Debugger einzusteigen.
Das Laufzeitverhalten der unterschiedlichen Anwendungen und Module wird
durch den Debugger verdeutlicht. Dies trägt zur erheblich verbesserten Trans-
parenz des oftmals weitreichenden Einsatzes von Programmteilen, Variablen
und dergleichen bei.
Beim Debugging von Dialogprogrammen kann der Anwender in beliebiger
Weise zwischen Dynpro und Modulpool-Ebene wechseln.
63
Sandini Bib
Im Einzelnen lassen sich die Funktionen des Debuggers wie folgt zusammenfas-
sen:
◗ Auswahl unterschiedlicher Debugger-Einstellungen
◗ Auswahl unterschiedlicher Ausführungsarten im Debugger
◗ Anzeige des Quelltext-Ausschnitts
◗ Setzen und Löschen von dynamischen Breakpoints
◗ Setzen und Löschen von Watchpoints
◗ Anhalten eines Programms bei einer bestimmten Anweisung, einem Ereig-
nis, Unterprogramm oder einem Funktionsbaustein.
◗ Anzeigen und Ändern von Feldinhalten zur Laufzeit
◗ Anzeige für ABAP-Objekte
◗ Verzweigen zum ABAP Editor oder zum Repository Browser, um Änderun-
gen am Quelltext vorzunehmen
Laufzeitanalyse
Die Laufzeitanalyse dient zur Optimierung des Laufzeitverhaltens eines Pro-
gramms. Mit der Funktion »Laufzeitanalyse« kann man die Performance aller
Transaktionen oder Programme analysieren, die in der ABAP/4 Development
Workbench angelegt wurden. Die Laufzeitanalyse erzeugt Listen, die laufzeit-
intensive Anweisungen aufdecken, Tabellenzugriffe zusammenfassen und die
Hierarchie des Programmablaufs zeigen. Anhand dieser Informationen ist es
möglich, Probleme zu entdecken und anschließend zu analysieren, die folgende
Ursachen haben:
◗ zu häufige Verwendung oder unnötiger Aufruf von Modularisierungseinhei-
ten (z.B. Unterprogramme oder Funktionsbausteine) und ABAP-Anweisungen
◗ CPU-intensive Programmfunktionen
◗ benutzereigene Funktionen, die durch ABAP-Anweisungen ersetzt werden
können
◗ ineffiziente und überflüssige Datenbankzugriffe
Die Laufzeitanalyse ist besonders für das Tuning einzelner Transaktionen und
Programme bestimmt. Ist man nur an den Datenbankzugriffen eines Pro-
gramms interessiert oder sind umfangreichere Tuning-Maßnahmen auf Daten-
bankebene durchzuführen, sollte man die Funktion »SQL Trace« benutzen, wel-
che nachstehend beschrieben wird.
Systemprotokolle
Der Server des SAP-Systems zeichnet alle Ereignisse und Probleme, die sich aus
dem laufenden Systembetrieb ergeben, in so genannten »Systemprotokollen«
64
Sandini Bib
auf. Man unterscheidet dabei zwei Arten der Protokollierung: zum einen die lo-
kale und zum anderen die zentrale Protokollierung. Jeder SAP-Anwendungs-
server verfügt über ein lokales Protokoll, welches die jeweiligen von diesem Ser-
ver ausgegebenen Meldungen enthält. Diese Anwendungsserver können auch
mit zentraler Protokollierung arbeiten. Dabei werden alle lokalen Protokolle ei-
nes jeden Anwendungsservers in ein zentrales Protokoll kopiert.
Anhand der Systemprotokolle kann das Input-/Outputverhalten von Program-
men detailliert überprüft werden. Man kann z.B. nachvollziehen, mit welchen
Werten Import- und Exportparameter versorgt worden sind.
SQL-Trace
Die SQL-Trace-Funktion ermöglicht es dem Benutzer, für einen Anwender oder
für das Gesamtsystem die Datenbankaufrufe von Reports und Transaktionen zu
protokollieren und zu analysieren. Der SQL-Trace zeigt dazu z.B., welche SQL-
Anweisungen eine CATT-Anwendung ausführt oder welche Werte das System
für bestimmte Datenbankzugriffe und -änderungen benutzt. Der SQL-Trace
protokolliert darüber hinaus alle R/3-Programme und Transaktionen auf der
Datenbankebene. Zwischen der Aktivierung und Deaktivierung der Trace-
Funktion werden alle Vorgänge auf der Datenbank aufgezeichnet, die für einen
bestimmten Benutzer oder ein komplettes System stattfinden. In diesem Kon-
text kann die SQL-Trace-Funktion dazu benutzt werden, Erklärungen zu be-
stimmten Oracle- oder auch zu bestimmten Informix-Datenbankanweisungen
anzuzeigen. Nimmt man weitere Funktionen zu Hilfe, so erhält man zu be-
stimmten Datenbankanweisungen detaillierte Informationen.
Computer Aided Test Tool – CATT
Das Computer Aided Test Tool, auch abgekürzt CATT genannt, ist ein in die

ABAP/4 Development Workbench integriertes Werkzeug, mit dem die Qualität
von Software umfassend getestet werden kann.
Class Builder – neu in Release 4.5
Der Class Builder ist als zentrales Werkzeug in die ABAP Workbench inte-
griert. Mithilfe des Class Browsers können vorhandene globale Objekttypen aus
der R/3-Klassenbibliothek zur Anzeige gebracht werden, und es kann in die
Pflege verzweigt werden.
Über den Menüpfad ENTWICKLUNG p CLASS BUILDER oder mit dem Transakti-
onscode SE24 wird das Einstiegsbild des Class Builders errreicht. Von hier aus
ist es möglich, entweder den Bestand der R/3-Klassenbibliothek zu sichten oder
direkt zur Pflege der Grunddaten der Objekttypen und zum Class Editor zu ver-
zweigen, in dem eine Definition der Objekttypen und ihrer Komponenten vor-
genommen werden kann. Der Definition der Objekttypen kann sich die Metho-
denimplementierung im ABAP Editor direkt anschließen. Des Weiteren ist es
65
Sandini Bib
möglich, vom Einstiegsbild oder vom Class Editor aus auf die Testumgebung
zuzugreifen.
Den Class Builder ruft man auf, um
◗ sich mithilfe des Class Browsers einen Überblick über vorhandene globale
Objekttypen und deren Beziehungen untereinander zu verschaffen.
◗ zur Pflege der vorhandenen globalen Klassen oder Interfaces zu verzweigen.
◗ neue Klassen oder Interfaces anzulegen.
◗ Attribute, Methoden und Ereignisse zu Klassen oder Interfaces anzulegen
und zu spezifizieren.
◗ klasseninterne Typen zu definieren.
◗ Methoden zu implementieren.
◗ lokale Hilfsklassen zu pflegen.
◗ Klassen oder Interfaces in einer simulierten Laufzeitumgebung zu testen.
Das Werkzeug Class Builder ermöglicht die Pflege von globalen ABAP-Klassen
und -Interfaces. Diese beiden Objekttypen werden ähnlich wie globale Datenty-
pen im ABAP Dictionary definiert und bilden so eine zentrale R/3-Klassenbi-
bliothek. Sie sind demnach im gesamten System sichtbar. Eine Navigation über
bereits vorhandene Klassen und Interfaces aus dieser Bibliothek wird mit dem
Class Browser vorgenommen
Das Werkzeug Class Browser dient zur Navigation in der R/3-Klassenbibliothek,
in der globale ABAP-Klassen und -Interfaces oder Business-Objekttypen abge-
legt sind.
Man öfffnet den Class Browser,
◗ um sich einen Überblick über den Bestand vorhandener Klassen und Inter-
faces oder Business-Objekttypen zu veschaffen.
◗ um die Beziehungen der Objekttypen untereinander zu analysieren.
◗ um aus dieser Übersicht heraus zur Pflege einzelner Objekttypen zu gelangen.
Der Class Browser ist im Class Builder intergriert und wird dort über die Funkti-
on Class Browser oder mit der Transaktion CLABAP aufgerufen.
Für die Anzeige der Klassen und Interfaces können zusätzlich zu bereits vor-
konfigurierten Sichten unterschiedliche Filter berücksichtigt werden:
◗ AlleKlassen
Sicht auf alle Klassen und Interfaces der R/3-Klassenbibliothek, bezogen auf
die Komponentenhierarchie
◗ Business-Objekte
Anzeige von betriebswirtschaftlichen Objekttypen der R/3-Klassenbibliothek.
66
Sandini Bib
Das Testwerkzeug CATT –

Computer Aided Test
Tool
3
3.1 CATT-Historie
Die Entwicklung von Software, welche höchsten Qualitätsansprüchen wie z.B.
der in Europa führenden Qualitätsnorm bei der Softwareentwicklung, ISO 9000-
3, genügt, muss von ausführlichen und intensiven Tests begleitet werden. Um
dieser wichtigen Anforderung Rechnung zu tragen, hat die SAP AG das Test-
werkzeug Computer Aided Test Tool, kurz CATT, entwickelt.
Ein Prototyp dieses CATT-Tools sorgte bereits im Jahre 1992 auf dem SAP-Ba-
sis-Kongress in Karlsruhe für erhebliches Aufsehen.
Ursprünglich entwickelte die SAP AG CATT als Qualitätssicherungswerkzeug
zum unternehmensinternen Testen der Prozessflüsse im R/3-System im Rah-
men des SAP-Softwareengineerings.
Basierend auf den sehr guten Erfahrungen, welche die SAP AG beim Einsatz
dieses Testwerkzeugs machte, und vor allem auch aufgrund der äußerst positi-
ven Kundenresonanz, überarbeitete die SAP AG CATT nochmals und gab es
dann Ende 1995 zur Auslieferung an die Kunden frei. Mit dem R/3-Release 3.0
lieferte man CATT erstmals als integrierten Bestandteil der ABAP/4-Develop-
ment-Workbench an die Kunden aus. Seither wurde das CATT-Tool ständig
weiterentwickelt und optimiert. Das Werkzeug ist heute als integraler Bestand-
teil eines jeden neuen R/3-Releases bereits an dessen Funktionen angepasst.
CATT bildet nun das zentrale Testwerkzeug zum Testen aller Prozesse inner-
halb von R/2- und R/3-Systemen. Dies gilt sowohl für SAP-eigene Systeme als
auch für die verschiedenen Kundensysteme.
67
Sandini Bib
3.2 Genereller Überblick

Das Werkzeug CATT ist ein computergestützes Testwerkzeug und lässt sich
demnach den in Kapitel 1 beschriebenen CASE-Tools zuordnen. Im Folgenden
soll nun ein kurzer Funktionsüberblick über das CASE-Tool CATT gegeben
werden.
3.2.1 Funktionsüberblick
CATT enthält alle erforderlichen Funktionen, um Testbausteine für einzelne
Transaktionen sowie Testabläufe für dynamische betriebswirtschaftliche oder
administrative Prozesse innerhalb des R/3-Systems darzustellen, zu starten, zu
testen, zu verwalten und zu protokollieren.
Diese betriebswirtschaftlichen Prozesse können einerseits auf einzelne Transak-
tionen bzw. auf ein R/3-Modul beschränkt sein (Funktionalorientierung); es
können andererseits aber natürlich auch betriebswirtschaftliche Prozesse aufge-
zeichnet werden, welche sich über mehrere R/3-Applikationen hinweg erstrek-
ken (Prozessorientierung).
Der Einsatz des Computer Aided Test Tools reduziert durch diese Automatisie-
rung der Testabläufe die Anzahl der aufwendigen manuellen Tests maßgeblich
und zwingt darüber hinaus zur Systematisierung der verschiedenen Tests
durch einen exakt definierten Input mit einem planbaren Testergebnis. Dadurch
können detaillierte Rückschlüsse auf die Qualität des Systems gezogen werden.
Außerdem können durch den Einsatz von CATT manuelle Testaktivitäten wäh-
rend des eigentlichen Testzeitraumes erheblich eingeschränkt werden. Mit der
allgemeinen Verfügbarkeit einer R/3-Version lassen sich die Tests über CATT-
Funktionen innerhalb von wenigen Tage durchführen.
CATT bietet dem Anwender dabei folgende Einsatzmöglichkeiten:
◗ Prüfen von Transaktionen
◗ Aufbau von Stammdaten
◗ Aufbau von Schulungsdaten
◗ Testen von betriebswirtschaftlichen Prozessketten
◗ Prüfen von Systemmeldungen
◗ Prüfen von Wertermittlung und Datenbankfortschreibung
◗ Einstellen von Customizing-Tabellen. Diese Möglichkeit ist vor allem dann
von Vorteil, wenn spezielle Testfälle nur ein temporäres Customizing erfor-
dern.
◗ Prüfen von Reaktionen auf Änderungen der Customizing-Einstellungen
◗ Verbindung von SAP Business Workflow und CATT
68
Sandini Bib
Im weiteren Verlauf dieses Buches wird auf jede dieser Verwendungsmöglich-

keit detailliert entweder anhand praktischer Anwendungsbeispiele oder an-
hand einer Fallstudie eingegangen. Dabei wurde streng darauf geachtet, dass
diese Beispiele der täglichen R/3-Praxis entsprechen.
Der einmalige Aufwand bei der Erstellung der diversen CATT-Abläufe macht
sich durch die beliebige Wiederholbarkeit der einzelnen Tests mehr als bezahlt.
Nach Beendigung eines jedes einzelnen Testablaufs mit CATT wird vom R/3-
System ein entsprechendes Ablaufprotokoll erstellt, das automatisch im R/3-
System archiviert wird und dann dem Anwender jederzeit für spätere Abrufe
zur Verfügung steht. Es dient als Basis für die Dokumentation der verschiede-
nen Testszenarien, der Ergebnisse der Tests und damit auch für statistische Aus-
wertungen.
Das CATT-Tool verfügt über eine große Flexibilität, die dadurch erreicht wird,
dass es die Tests auf Feldebene und nicht auf Interfaceebene durchführt, wobei
die einzelnen Feldwerte durch verschiedene vordefinierte Variablen und Para-
meter weitergereicht werden können. CATT prüft also die Qualität individuell
erstellter Software in variabler Systemumgebung.
CATT-Abläufe sind mandantenübergreifend und können grundsätzlich in je-
dem SAP-Mandanten erstellt werden. Folglich sind die Abläufe auch in jedem
Mandanten für den Start vorhanden. Es ist zwar möglich, Testabläufe und -bau-
steine in jedem beliebigen Mandanten mandantenübergreifend zu erstellen, ge-
Kapitel 3 – Das Testwerkzeug CATT – Computer Aided Test Tool

startet werden können sie jedoch nur für einen einzelnen Mandanten. Bei die-
sem konkreten Mandanten darf es sich nur um einen Testmandanten handeln.
Denn beim Produktivmandanten werden Customizing-Einstellungen verän-
dert und Test-Stammdaten erzeugt, die im Produktivsystem zu Fehlern führen
können. Um das Starten von Abläufen in einem Mandanten zu ermöglichen,
muss in der Detailpflege des betreffenden Mandanten in der Mandantentabelle
T000 im Bereich »Einschränkungen« das Kennzeichen »Starten von CATT-Ab-
läufen erlaubt« eingestellt sein.
3.2.2 Einschränkungen der Funktionen von CATT

Weniger geeignet ist das Tool für:
◗ Listen
◗ Anzeigeergebnisse
◗ Menüführung
◗ Online-Hilfen ((F1), (F4))
◗ Editorfunktionen
69
Sandini Bib
In CATT wird der Begriff »Batch-Input-Fähigkeit« verwendet, da hier die glei-

che interne Aufrufschnittstelle benutzt wird wie bei einem Batch-Input. Derzeit
sind die nachfolgend aufgeführten Problempunkte bekannt, die bei der Pro-
grammierung bzw. Veränderung von Anwendungstransaktionen zu berück-
sichtigen sind, um die Batch-Input-Fähigkeit zu gewährleisten. Für folgende
Transaktionstypen kann CATT nicht genutzt werden:
Transaktionen, die nicht batch-input-fähig sind

CATT ist bei der Aufzeichnung der Transaktionen auf die Eingabe von Daten
angewiesen, da CATT die Batch-Input-Schnittstelle verwendet, um die Transak-
tionen zu starten. Wenn nun keine Daten eingegeben werden können, weil die
Transaktion nicht batch-input-fähig ist, kann CATT folglich auch nichts auf-
zeichnen. Nicht batch-input-fähig sind Transaktionen, die sich im Hintergrund
anders verhalten als im Online-Betrieb, da die Mappen beim Abspielen im Hin-
tergrund zahlreiche Fehler mit sich bringen können. Zudem sind Transaktio-
nen, die folgende Eigenschaften haben, nur bedingt batch-input-fähig:
◗ interaktive Listverarbeitung (Mappen können nicht im Hintergrund abge-
spielt werden)
◗ Anstarten einer neuen Transaktion innerhalb des Batch-Inputs
◗ Löschen eines Modus mit /i
Transaktionen, die nach einem COMMIT WORK nicht beendet

sind
Dieser Befehl gehört zum OPEN-SQL-Befehlssatz. Der ABAP/4-Befehl COM-
MIT WORK schließt bei einem Batch-Input die Verarbeitung erfolgreich ab.
Dies bewirkt, dass ein Datenbank-Commit ausgeführt und damit eine logische
Verarbeitungseinheit abgeschlossen wird. Sind in der Transaktion danach noch
wesentliche Funktionen vorgesehen, so werden diese in CATT nicht mehr bear-
beitet. Es kann bereits ein Problem sein, wenn die Ausgabe einer Erfolgsmel-
dung direkt nach dem COMMIT WORK erfolgt. Diese Meldung wird in CATT
nicht mehr ausgegeben.
Eine logische Verarbeitungseinheit im R/3-System stellt zum Beispiel die Trans-
aktionsverarbeitung dar. Das heißt, mit dem Befehl COMMIT WORK wird die
Transaktionsverarbeitung an der Stelle im Programmquellcode abgeschlossen,
an welcher der Befehl steht. Das hat zur Folge, dass an dieser Stelle alle Daten-
bankveränderungen unwiderruflich festgeschrieben und alle Datenbanksperren
freigegeben werden. Darüber hinaus bewirkt ein COMMIT WORK den Aufruf
verschiedener registrierter Unterprogramme und die asynchrone Ausführung
der innerhalb dieser Unterprogramme oder der bereits zuvor im Rahmen der
Transaktionsverarbeitung abgesetzten Verbuchungsaufträge. Der Befehl COM-
MIT WORK löst auch die Abarbeitung der diversen im Programmhintergrund
70
Sandini Bib
erfassten Funktionsbausteine aus. Unterprogramme und Funktionsbausteine im

Hintergrund einer Transaktion können von CATT aber nicht erfasst werden. Die
im Quellcode des Programms nach dem COMMIT WORK enthaltenen Funktio-
nen und Programmbausteine können von CATT daher nicht mehr aufgezeich-
net werden, da, wie bereits erwähnt, die Transaktionsverarbeitung mit dem
COMMIT WORK beendet wird.
Bei Massentransaktionen kommt es vor, dass Tabellenupdates durch COMMIT
WORK unterbrochen werden. Auch in diesen Fällen wird die Transaktion nur
bis zum ersten COMMIT WORK ausgeführt.
Wird also das Transaktionsende nicht erreicht, so wird die Transaktion wegen
fehlender Dynprodaten automatisch abgebrochen.
Neuerung in Release 4.0
Für CATT war bisher eine Transaktion beendet, wenn ein COMMIT WORK in-
nerhalb der Transaktion ausgeführt wurde. Dies führt dazu, dass Transaktio-
nen, die COMMIT WORK mehrmals aufrufen, einer Sonderbehandlung für den
Fall einer Ausführung durch CATT unterworfen werden mussten. Daher wurde
seitens der SAP im R/3-Release 4.0 ein neuer CATT-Modus implementiert, bei
dem ein COMMIT WORK nicht mehr zum Ende des CATTs führt.
Im Klartext bedeutet dies, dass in CATT Transaktionen zukünftig nicht mehr im
Kapitel 3 – Das Testwerkzeug CATT – Computer Aided Test Tool

Batch-Input-Modus gestartet werden müssen. Daher kann man nun auch Trans-
aktionen testen, die nach einem COMMIT WORK noch sinnvolle Bearbeitungen
durchführen oder mehrfach Verbuchungsaufrufe absetzen.
Dieser neue Modus kann genutzt werden, wenn bei der Definition eines Trans-
aktionsaufrufes mittels der CATT-Funktion TCD eine entsprechende Einstel-
lung getätigt wird.
Transaktionen, die den Befehl LEAVE TO TRANSACTION

enthalten
Nachdem beim Ablauf der Transaktion im ABAP/4-Quellcode der Befehl LEA-
VE TO TRANSACTION erreicht wurde, beendet das System die Transaktion,
um zu einer anderen Transaktion zu wechseln, obwohl die eigentlich aufzu-
zeichnende Transaktion noch nicht beendet ist. Die neue Transaktion wird dann
gestartet. Dabei sorgt ein bestimmter ABAP/4-Mechanismus dafür, dass das er-
ste Dynpro der neu gerufenen Transaktion nicht über den Bildschirm prozes-
siert wird, wenn alle notwendigen Eingabefelder dieses Dynpros der neuen
Transaktion über geeignete Mechanismen mit entsprechend gültigen Werten
gefüllt werden können. Innerhalb der Aufzeichnung einer Transaktion mittels
CATT ist ein Wechsel der Transaktion aber nicht möglich.
71
Sandini Bib
Transaktionen, die eine Batch-Input-Mappe erzeugen

Bei Transaktionen, die nicht batch-input-fähig sind, kann durch Programmie-
rung diese Fähigkeit jedoch hergestellt werden. Dazu müssen mehrere Voraus-
setzungen erfüllt sein:
◗ Ein COMMIT WORK bedeutet für den Batch-Input und damit auch für
CATT das Ende einer Transaktion. Ist vor dem logischen Transaktionsende
noch ein weiterer COMMIT WORK notwendig, so kann dafür der Funktions-
baustein DB_COMMIT verwendet werden. Allerdings gilt diese Regelung
nicht für einen COMMIT WORK, der unmittelbar am Transaktionsende
steht.
◗ LEAVE TO TRANSACTION vor dem COMMIT WORK muss explizit ver-
mieden werden. Häufig wird mit dem Befehl LEAVE TO TRANSACTION
die gerade beendete Transaktion nochmals aufgerufen, um so auf einfache
Weise wieder zum Einstiegsbild zu verzweigen und damit sicherzustellen,
dass alle Arbeitsfelder leer sind. Wenn für CATT die Transaktion als solche
beendet sein soll, ist es völlig ausreichend, direkt vor dem Befehl LEAVE TO
TRANSACTION den Befehl COMMIT WORK zu setzen.
◗ Ein logisches Transaktionsende muss vorhanden sein.
◗ Die (¢)-Taste darf mit dem Funktionscode nicht fest verbunden sein. In vie-
len Fällen ist die (¢)-Taste mit einem Funktionscode belegt, wie z.B. mit
»Weiter«. Wird nun in der Verarbeitung eines solchen Popups vom System
eine Warnung ausgegeben, so gerät die Transaktion in einen Loop, aus dem
sie bei dunkler Verarbeitung nicht mehr herauskommt. Ab dem zweiten Dyn-
produrchlauf wird der Funktionscode der (¢)-Taste abgesetzt, was dazu
führt, dass das Modul mit der Ausgabe der Warnung erneut prozessiert
wird.
◗ Die (F15)-Funktion muss auf Listbildern vorhanden sein.
Achtung: Das CATT-Tool speist über die Benutzerschnittstelle Daten in das Sys-
tem ein. Diese Testdaten führen zu realen Datenbankfortschreibungen. Deshalb
sollte man CATT-Abläufe auch nur in Testsystemen verwenden, da unter Um-
ständen unerwünschte Datenbankveränderungen durchgeführt werden kön-
nen.
Man kann sich diesen Umstand aber auch zu Nutze machen, um gezielt Daten
zum manuellen Testen oder für Schulungen bzw. Demozwecke anzulegen.
72
Sandini Bib
CATT als integrales

Element der
R/3-Einführung
4
Das Computer Aided Test Tool wird, wie bereits erwähnt, bei der SAP AG in-
nerhalb der Softwareentwicklung eingesetzt. Darüber hinaus kann bzw. soll es
natürlich auch bei den SAP R/3-Endkunden Verwendung finden.
Nachfolgend soll zunächst geschildert werden, wie dieser Einsatz von CATT bei
der SAP AG aussieht, bevor anschließend ausführlich beschrieben wird, wie das
CATT beim SAP R/3-Endkunden als integrales Element des SAP R/3-Projektes
eingesetzt, bzw. wie das CATT in die verschiedenen Vorgehensmodelle zur
Durchführung von SAP R/3-Projekten eingebettet werden kann.
Die SAP AG selbst verwendet CATT neben dem Debugger intern während des
gesamten Zyklus der Softwareerstellung und Wartung. Bei den neuen Releases
arbeiten die CATTs in den Entwicklungs-, Konsolidierungs-, Test-, Endmonta-
ge- und Kundenauslieferungssystemen; bei neuen Upgrade Levels in den Kor-
rektur- und Testsystemen sowie den Kundenauslieferungssystemen. Die klassi-
sche Softwareentwicklung bei der Entwicklung von SAP R/3-Anwendungen
mithilfe der ABAP/4 Development Workbench wird durch die bereits beschrie-
benen Programmiertools unterstützt. Von der Vorstudie bis hin zur implemen-
tierten Anwendung werden alle an einem Softwareentwicklungsprojekt betei-
ligten Mitarbeiter und Objekte konzeptionell erfasst. Dadurch ist eine
strukturierte und ökonomische Softwareentwicklung gewährleistet. Die Festle-
gung der einzelnen Phasen soll keine feste Vorgabe für das Gesamtprojekt sein,
sondern in sich abgeschlossene Teilprojekte gliedern.
In der konzeptionellen Phase werden die Ergebnisse der Vorstudien und Analy-
sen in das Unternehmensdatenmodell (UDM) der SAP AG eingefügt. Anschlie-
ßend findet dann die Umsetzung der Daten aus dem UDM in Felder, Tabellen
usw. statt. Die Entwicklung der einzelnen Programmkomponenten wie Bild-
schirmoberfläche, ABAP/4 usw. erfolgt in beliebiger zeitlicher Reihenfolge. Sie
müssen erst zum Ende der Anwendungsentwicklung zusammengefügt werden.
Da diese Modularisierung der Programmentwicklung unabhängige Einzeltests
73
Sandini Bib
CATT als integrales Element der R/3-Einführung
erlaubt, wird ein iteratives Prototyping unterstützt, das die Effizienz und Quali-
tät der Softwareentwicklung durch die frühe Einbeziehung der Endanwender in
den Entwicklungszyklus erhöht. Man spricht hier auch vom so genannten »Ear-
ly-Prototyping«. Abschließende Programmtests und die sich anschließende
Überführung in das Produktivsystem runden den Entwicklungszyklus ab und
schaffen zugleich die Basis für künftige Erweiterungen.
Bei der Einführung einer Standardanwendungssoftware ist, wie die Erfahrun-
gen aus der Praxis zeigen, in der Regel ein sehr langer, arbeitsintensiver und
schwieriger Weg zu absolvieren, bis die vielfältigen Möglichkeiten der Software
und die verschiedensten Bedürfnisse des Unternehmens in optimaler und zu-
friedenstellender Weise aufeinander abgestimmt sind. Erst dann kann das Sys-
tem in den Produktivbetrieb übergehen. Unternehmen, die neu mit der Einfüh-
rung von Softwaresystemen konfrontiert sind, benötigen daher ein spezielles
Projektmanagement für die Einführung der Software.
Als Basis für diese Einführungsprojekte diente bisher entweder das traditionelle
SAP-Vorgehensmodell oder die seit einiger Zeit angewandte, neuere ASAP
(Accelerated-SAP)-Einführungsmethodik. Diese Ansätze wurden von der SAP
entwickelt und haben daher den Vorteil, dass alles, was in einem SAP R/3-Pro-
jekt an Aufgaben zu bewältigen ist, vollständig und präzise dargestellt wird. Als
alternativer Ansatz steht darüber hinaus mit dem DSDM-basierten Vorgehens-
modell ein dynamisches Vorgehensmodell zur Durchführung von SAP R/3-
Projekten zur Verfügung.
In den vorangegangen Kapiteln wurde bereits ausführlich auf die Wichtigkeit
des Testens und folglich auch auf die besonderen Möglichkeiten des Computer
Aided Test Tools eingegangen. Im Mittelpunkt des folgenden Kapitels wird da-
her nun die Fragestellung stehen, ob bzw. wie das CATT in die verschiedenen
Vorgehensmodelle, auf denen eine SAP R/3-Einführung basieren kann, inte-
griert werden kann.
Hierzu sollen die verschiedenen Vorgehensmodelle in der Reihenfolge ihrer
Entstehung betrachtet werden. Zunächst wird kurz auf das traditionelle SAP-
Vorgehensmodell und auf ASAP eingegangen, bevor das dynamische, DSDM-
basierte Vorgehensmodell ausführlicher behandelt und die besondere Stellung
des CATTs für dieses Vorgehensmodell erläutert wird. Bei dieser Gelegenheit
soll auch kurz auf das Iterative Prozess-Prototyping (IPP) eingegangen werden,
das zwar kein Vorgehensmodell beschreibt, wohl aber eine Methode zur Ge-
schäftsprozessanalyse ist, in deren Mittelpunkt die Integration verschiedener
SAP-eigener Werkzeuge steht und demnach sehr gut um CATT erweitert wer-
den könnte.
Zunächst soll aber unser Interesse den am weitesten verbreiteten und in zahlrei-
chen SAP-Projekten eingesetzten Vorgehensmodellen gelten.
74
Sandini Bib
4.1 Das traditionelle SAP-Vorgehensmodell

Die Firma SAP AG hat mit dem R/3-Vorgehensmodell eine Einführungsmetho-
de für SAP-Produkte entwickelt. Das Vorgehensmodell umfasst die jeweils
neuesten Erkenntnisse der SAP AG aus erfolgreichen R/3-Einführungen in
Form von Empfehlungen. Es bietet komfortablerweise dort, wo es notwendig
ist, Zugriff auf die entsprechenden Werkzeuge wie z.B. das R/3-Referenzmo-
dell oder den IMG (Implementation Guide; auch »Einführungsleitfaden« ge-
nannt). Daher ermöglicht das Vorgehensmodell eine ideale Terminierung des
Einführungsprojektes. Es bildet des Weiteren auch die Grundlage zur Einschät-
zung der im Laufe der Implementierung benötigten Zeit und Ressourcen. Vom
Vorgehensmodell aus kann darüber hinaus direkt auf die Dokumentation des
Projektes zugegriffen werden.
Dieses traditionelle SAP-Vorgehensmodell beschreibt ein wasserfall-basiertes
Vorgehensmodell zur SAP R/3-Einführung, d.h., es werden mehrere Phasen
beschrieben, die in einer streng vorgegebenen Reihenfolge hintereinander aus-
geführt werden müssen. Am Ende einer jeden Phase steht eine Meilensteinsit-
zung, in der die Mitglieder des Lenkungsausschusses darüber informiert wer-
den, welche Ergebnisse in der vorangangenen Phase erzielt wurden. Dieser
Lenkungsausschuss ist es dann, der darüber entscheiden muss, ob die nächste
Phase begonnen, die aktuelle Phase wiederholt oder das Projekt abgebrochen
werden soll.
Das traditionelle SAP-Vorgehensmodell besteht aus vier Phasen, die sich wie
Kapitel 4 – CATT als integrales Element der R/3-Einführung

folgt untergliedern:
A Organisation und Konzeption
B Detaillierung und Realisierung
C Produktionsvorbereitung
D Produktivbetrieb
Darüber hinaus werden die folgenden phasenübergreifenden Aktivitäten be-
schrieben:
A Projektadministration und Projektcontrolling
B Systemwartung und Release-Wechsel
In der Abbildung 4.1 wird das traditionelle SAP-Vorgehensmodell grafisch dar-
gestellt, wobei diese Darstellungsform die wasserfall-basierten Eigenschaften
des Modells sehr gut widerspiegelt. So werden bereits zu Beginn des Einfüh-
rungsprojektes die Anforderungen analysiert und die Phasen hintereinander
ausgeführt, an deren Ende jeweils ein Meilenstein in Form einer Qualitätsprü-
fung steht.
75
Sandini Bib
Abbildung 4.1
Das traditionelle SAP-Vorgehensmodell
In der ersten Phase, also der Organisations- und Konzeptionsphase, werden all-
gemeine Vorarbeiten durchgeführt, und es wird ein praktikables Einführungs-
konzept erarbeitet wie z.B.:
◗ Projekt initialisieren
◗ Unternehmensziele des R/3-Einsatzes definieren
◗ Anforderungsanalyse
◗ Bestandsaufnahme der im R/3-System abzubildenden Prozesse und Funk-
tionen
◗ Projektplanung und -organisation
◗ Durchführung des Kick-Off-Meetings
◗ Grobdesign
◗ Systeminstallation
◗ Entwurf von Schnittstellen und Systemerweiterungen
◗ Schulungen der Projektmitglieder
◗ Prozesse und Funktionen festlegen
76
Sandini Bib
◗ Schnittstellen und Systemerweiterungen entwerfen

◗ Qualitätsprüfung des Sollkonzeptes
Basierend auf der R/3-Funktionalität und den unternehmensspezifischen An-
forderungen wird ein Fach- und Datenverarbeitungskonzept festgelegt. Das Er-
gebnis dieser ersten Phase beschreibt also, welche Komponenten und Prozesse
des R/3-Systems eingeführt werden und wer für die Durchführung der Teilpro-
jekte verantwortlich ist.
In der zweiten Phase, der Detaillierung und Realisierung, werden die einzelnen
Anwendungsmodule (z.B. Materialwirtschaft, Vertrieb, Rechnungswesen) ent-
sprechend dem vorher erarbeiteten Konzept zu einem Prototypen ausgeprägt.
Dabei werden folgende Arbeitspakete abgearbeitet:
◗ globale Einstellungen vornehmen
◗ Unternehmensstruktur abbilden
◗ Grund- und Stammdaten abbilden
◗ Abbildung von Funktionen und Prozessen
◗ Realisierung von Schnittstellen und Erweiterungen
◗ Festlegung des Berichtswesens
◗ Archivverwaltung abbilden

◗ Gestaltung des Berechtigungskonzeptes
◗ Durchführung des Abschlusstests
◗ Qualitätsprüfung Anwendungssystem
Während in der Organisations- und Konzeptionsphase kaum firmenspezifische
Anpassungen im R/3-System durchgeführt werden, liegt in der zweiten Phase
der Schwerpunkt auf dem Customizing im engeren Sinne. Es werden verschie-
dene Arbeitspakete durchgeführt. Jedes dieser Arbeitspakete kann für sich, also
modulbezogen, getestet werden. Letztlich wird der so genannte »Abschlus-
stest« durchgeführt. Bei diesem ist auf die Beteiligung aller Komponenten zu
achten, um die Integrationsfähigkeit prüfen zu können und einen ordnungsge-
mäßen Ablauf der Geschäftsvorfälle zu gewährleisten. Mann kann hier auch
von einem Integrationstest sprechen. Nach Abschluss dieser Phase ist die Detail-
lierung des Softwarekonzeptes und deren Realisierung durch Customizing-Ein-
stellungen im System vollzogen. Innerhalb des formalen Abschlusses dieser
Phase findet die Qualitätsprüfung statt. Hier werden insbesondere die Projekt-
ziele und Testergebnisse einer Prüfung unterzogen.
In der sich anschließenden Produktivvorbereitung werden folgende, für den
Produktivstart notwendige Maßnahmen getroffen:
77
Sandini Bib
◗ Produktivsetzung vorbereiten
◗ Anwenderdokumentation entwickeln
◗ Produktivumgebung einrichten
◗ Anwender schulen
◗ Systemorganisation organisieren
◗ Datenübernahme ins Produktivsystem
◗ Durchführung Systemtest
◗ Qualitätsprüfung Produktivsystem
Das Endergebnis dieser Phase ist ein eingerichtetes Produktivsystem. In der Re-
gel existiert bei einem Einführungsprojekt eine so genannte »Doppelinstallati-
on«. Dies bedeutet, dass sowohl ein Testsystem als auch ein Produktivsystem
vorhanden sind. Dabei ist das R/3-System, in dem die Echtdaten von den Fach-
abteilungen bearbeitet und gespeichert werden, das Produktivsystem. Im Test-
system werden dagegen neue Einstellungen, eigenentwickelte bzw. abgeänder-
te Transaktionen, Auswirkungen von Customizing-Änderungen, neue Puts
und eigene Zusatzprogramme (Add ons) getestet. Bei der Verwendung eines
Testsystems sowie eines Produktivsystems werden u.a. Berechtigungen, Be-
rechtigungsprofile, Berichte und Altdaten in das Produktivsystem überspielt.
Das Ergebnis der Produktvorbereitung ist ein geprüftes, produktives System.
Nun tritt die Phase Produktivbetrieb ein. Nach der Altdatenübernahme können
die entsprechenden Aktivierungsprogramme gestartet werden. Der Echtlauf
wird nach erfolgreichem Produktionsstart noch für eine gewisse Zeit vom Pro-
jektteam begleitet. Dabei wird das R/3-System optimiert. Hierbei sind folgen-
den Aktivitäten auszuführen:
◗ Betreuung der Anwender
◗ permanente Help-Desk-Betreuung sicherstellen
◗ Systemnutzung optimieren
◗ Feinplanung
◗ Projektstatus ermitteln
◗ Veranlassung von Korrekturmaßnahmen
◗ Durchführung von Projektbesprechungen
In der phasenübergreifenden Aktivität »Systemwartung und Release-Wechsel«
sind folgende Arbeitspakete durchzuführen:
◗ System-Upgrade bzw.- Release-Wechsel durchführen
◗ Release-Customizing durchführen
78
Sandini Bib
Wie man an der Vielzahl der abzuarbeitenden Arbeitspakete im Rahmen des

vorbeschriebenen klassischen Vorgehensmodells durchaus erkennen kann, ist
eine R/3-Einführung mit folgenden Problemen behaftet:
◗ hoher Zeitaufwand zur Implementierung
◗ dadurch hoher finanzieller Aufwand
◗ Nichterfüllung vieler Anforderungen
◗ häufig ungenaue Abbildung der Geschäftsprozessanforderungen aufgrund
fehlender oder unzureichend durchgeführter Tests
◗ Vernachlässigung der phasenübergreifenden Aktivitäten
Diesen Problemen kann nun mit CATT effektiv begegnet werden. CATT kann
also im Rahmen der R/3-Einführung in jeder einzelnen Phase des klassischen
SAP-Vorgehensmodells und natürlich auch phasenübergreifend eingesetzt
werden für:
◗ das Testen von Transaktionen
◗ den automatisierten Aufbau von Stammdaten
◗ die automatisierte Übernahme von Stammdaten aus Altsystemen
◗ das automatisierte Einlesen von Daten aus Tabellenkalkulationssystemen
◗ das Testen von Customizing-Einstellungen

◗ die Durchführung von Modul- und Integrationstests
◗ die Unterstützung und Durchführung von Anwenderschulungen
◗ den Aufbau von Schulungsdaten
◗ die Anwenderschulung mittels IDES
◗ den Systemtest
◗ die Überprüfung der Fehlermeldungen des Systems
◗ das Prüfen von Wertermittlung und Datenbankfortschreibung
◗ die Erzeugung von Testdaten
◗ den Einsatz bei FCS-Version / Releasetests
◗ das Testen und Prüfen von Schnittstellenprogrammen
◗ die Verbindung von SAP Business Workflow und CATT
Eine umfassende, ausführliche Anleitung zu jedem einzelnen dieser vorbe-
zeichneten Arbeitspakete im Rahmen der Einführung der Standardsoftware
SAP R/3 gibt es in der SAP-Hilfedatei. Im Anhang zu diesem Buch sind zu jeder
dieser Phasen die entsprechenden Arbeitspakete aufgelistet. Jedes Arbeitspaket,
welches mit Hilfe des CATT bearbeitet werden kann, ist dort entsprechend ge-
kennzeichnet.
79
Sandini Bib
Durch die Verwendung des Computer Aided Test Tools bei der Einführung der
R/3-Software können durch die Automatisierung und Wiederholbarkeit der
verschiedenen Bausteine und Abläufe sowohl beim klassischen Vorgehensmo-
dell als auch bei der anschließend geschilderten ASAP-Einführungsmethodik
Zeit- und Kostenressourcen in erheblichem Umfang geschont werden.
Die besondere Stärke dieses Vorgehensmodells ist die sehr detaillierte Beschrei-
bung all dessen, was in einem SAP R/3-Einführungsprojekt an Aufgaben zu be-
wältigen ist. Es wird jedoch nicht beschrieben, welche Werkzeuge zur Bearbei-
tung dieser Aufgaben genutzt werden können, obwohl die SAP mit dem R/3-
System sehr viele darin integrierte Werkzeuge ausliefert.
Eine Zuordnung der einzelnen Werkzeuge zu bestimmten Tätigkeiten soll je-
doch im Folgenden nicht Thema unseres Buches sein, vielmehr sollen die Pha-
senaktivitäten des Testens mit Blick auf die Möglichkeit der Werkzeugunter-
stützung bzw. auf ihr Automatisierungspotential hin durchleuchtet werden.
Dass CATT sehr sinnvoll zum Testen von Geschäftsprozessen im R/3-System
angewendet werden kann, wurde bereits in aller Ausführlichkeit gezeigt. Um
zu überprüfen, ob bzw. wie CATT mit dem traditionellen SAP-Vorgehensmo-
dell bzw. mit ASAP in Einklang zu bringen ist, soll nun untersucht werden, wel-
che Phasenaktivitäten sich innerhalb dieses Modells überhaupt mit dem Testen
auseinandersetzen bzw. in welchen Phasen und Arbeitspaketen CATT einge-
setzt werden kann.
Überprüft man das traditionelle SAP-Vorgehensmodell daraufhin, welche Test-
aktivitäten beschrieben werden, so fällt insbesondere die Phasenaktivität »Ab-
schlusstest durchführen« innerhalb der Phase »Detaillierung und Realisierung«
auf, in der die umfangreichsten Testaktivitäten beschrieben werden. Die Ar-
beitspakete dieser Phasenaktivität lauten:
◗ Testkonzept erstellen
◗ Testplan erstellen
◗ Testaktivitäten durchführen
◗ Bericht zum Abschlusstest durchführen
◗ Abschlussreview mit den Fachabteilungen durchführen
Innerhalb dieser Arbeitspakete erfolgt eine sehr detaillierte Beschreibung all
dessen, was zu tun ist. Eine Empfehlung jedoch, wie die Tests durchzuführen
sind, erfolgt nur bezüglich der Testdokumentation, nicht aber bezüglich des ei-
gentlichen Tests. Als Dokumentationsunterstützung werden die Werkzeuge
»ARIS-Toolset« und »Visio Business-Modeler« empfohlen. Die eigentlichen
Testwerkzeuge »CATT« und die »Testworkbench« werden nicht genannt, und
folglich werden auch keine Hinweise zur Durchführung gegeben.
80
Sandini Bib
Wie das Testen im Allgemeinen vor sich gehen sollte, wird sehr ausführlich be-
schrieben. Als Beispiele sollen hier zwei Arbeitspakete betrachtet werden [vgl.
/SAP Online-Hilfe/], die prädestiniert für den Einsatz der Testworkbench (Pha-
senaktivität »Testplan erstellen«) und den Einsatz des CATTs (Phasenaktivität
»Testaktivitäten durchführen«) sind.
Testplan erstellen:
1. Erstellen Sie auf der Basis des Testkonzepts einen Testplan.
Dieser Testplan sollte für alle Beteiligten transparent aufzeigen, wann und in welchem
Umfang jeder einzelne am Test beteiligt ist. Ebenfalls sind auch die Abstimm-Meetings
und die Review-Meetings mit den Fachabteilungen in die Planung mit einzubeziehen
(siehe Projektaktivität »Abschlussreview mit den Fachabteilungen durchführen«).
Besonders zu beachten bei der Planung, sind Abhängigkeiten der einzelnen Prozesse/
Funktionen.
Dokumentieren Sie diese Planung in entsprechenden Arbeitsblättern und legen Sie diese
in der Mappe »Allgemein« unter »Sonstiges« ab.
2. Informieren Sie alle Testbeteiligten über die Vorgehensweise und den Testplan.
Diese Information sollte frühzeitig in einer gemeinsamen Veranstaltung mit allen Test-
beteiligten erfolgen, so dass rechtzeitig alle Personen über die Vorgehensweise und den
Testplan informiert sind.
3. Organisieren Sie die für den Test erforderlichen Ressourcen (Räume, PCs, Arbeits-

materialien ...).
Grundlage hierfür ist der abgestimmte Testplan.
Testaktivitäten durchführen:
1. Führen Sie je Testbereich die geplanten Testaktivitäten durch, und dokumentieren Sie
die Testergebnisse.
Testen Sie insbesonders auch folgende Aspekte:
• Prozesse/Funktionen, die gegenüber der Standardfunktionalität modifiziert bzw. er-
weitert worden sind
• Verbindungen zu anderen Anwendungssystemen
• organisatorischen Besonderheiten
• Berichte und Auswertungen
• Nachrichtensteuerung und Formulare
Anpassungen des Fachkonzeptes sind nur in Abstimmung mit dem Geschäftspro-
zessverantwortlichen vorzunehmen.
81
Sandini Bib
Änderungen bei Systemeinstellungen sind nur von den Anwendungskomponentenver-

antwortlichen entsprechend den dafür vorgesehenen Standards im Mandanten 001 vor-
zunehmen.
Bei allen Änderungen ist zu überprüfen, inwieweit Testaktivitäten wiederholt werden
müssen. Vermerken Sie diesen Sachverhalt in den Testbeschreibungen.
2. Führen Sie die geplanten Testbesprechungen durch.
Bei den Testbesprechungen sollten insbesondere die Fehler besprochen werden, die Aus-
wirkungen auf den zeitlichen Ablauf des Tests haben könnten. Außerdem sind alle Än-
derungen am Fachkonzept von dem jeweiligen Geschäftsprozessverantwortlichen vor-
zustellen.
3. Leiten Sie Maßnahmen zur Behandlung der Fehler/Probleme ein.
Beginnen Sie dabei mit den Problemen, die die größten Auswirkungen auf nachfolgende
Testaktivitäten haben.
4. Wiederholen Sie die Testaktivitäten für Prozesse/Funktionen mit negativen Tester-
gebnissen.
Wie nun aber CATT und die Testworkbench bei den verschieden Aktivitäten im
Einzelnen eingesetzt werden können bzw. sollen, bleibt offen. Aus diesem
Grund wird nun im Folgenden untersucht, welche Phasenaktivitäten von CATT
bzw. der Testworkbench unterstützt werden können.
Bei einer R/3-Einführung kann der Kunde die Möglichkeiten von CATT in den
einzelnen Implementierungsphasen vielfältig nutzen.
4.1.1 Phase Detaillierung und Realisierung

In der Phase Detaillierung und Realisierung ist CATT wie folgt einsetzbar:
◗ Testen von Transaktionen
◗ Aufbau von Stammdaten im Rahmen der Altdatenübernahme sowie Anle-
gen neuer Stammdaten
◗ Einstellung von Customizing-Tabellen und Testen der Auswirkungen dieser
Customizing-Einstellungen
◗ Abschlusstest durchführen
◗ Durchführung von Modul- sowie Integrationstests anhand der Abbildung
betriebswirtschaftlicher Prozessketten mittels CATT
Testen von Transaktionen

Die verschiedenen Prozesse im R/3-System bestehen u.a. aus sehr vielen einzel-
nen Transaktionen. Eine Transaktion ist ein logisch abgeschlossener Vorgang
im R/3-System. Aus Sicht des Benutzers stellt eine Transaktion eine Einheit
82
Sandini Bib
(z. B. das Erzeugen einer Liste bestimmter Kunden, das Ändern der Anschrift ei-
nes Kunden etc.) dar. Aus Sicht der Dialogprogrammierung ist sie ein komple-
xes Objekt, das aus einem Modulpool und verschiedenen Dynpros besteht und
mit einem Transaktionscode aufgerufen wird. Nach der Anmeldung im R/3-Sys-
tem werden drei Ebenen voneinander unterschieden: die SAP-Ebene, die Ar-
beitsgebietsebene und die Anwendungsebene. Eine Transaktion ist eine An-
wendung auf Anwendungsebene. Um auf das Einstiegsbild einer Anwendung
zu gelangen, kann man durch die Menühierarchie navigieren oder einen vier-
stelligen Transaktionscode im Befehlsfeld eingeben. Die Verwendung des
Transaktionscodes erspart das Navigieren durch die verschiedenen Menüs und
bringt den Benutzer direkt zum Einstiegsbild.
Transaktionen werden einerseits von der SAP AG selbst programmiert (vor der
Auslieferung des R/3-Systems an den Kunden) oder andererseits vom Kunden
selbst erstellt bzw. nach seinen Anforderungen verändert. Standardtransaktio-
nen sowie kundenspezifisch veränderte Transaktionen können durch CATT
während ihrer Entwicklung getestet werden. Wenn an einem R/3-System ein
Upgrade durchgeführt, d.h., eine neue, höhere Releaseversion eingespielt wur-
de, können diese Transaktionen erneut getestet werden. Wenn nun das R/3-Sys-
tem z.B. vom Entwicklungsmandanten in den Testmandanten überführt wird,
ist es notwendig, festzustellen, ob die Transaktionen auf dem neuen System
überhaupt lauffähig sind. Aus diesem Grund werden die einzelnen Transaktio-
nen erneut getestet. Anstatt alle Transaktionen manuell durchzuspielen, also
Dynpro für Dynpro mit »Enter« zu bestätigen, ist es sinnvoll, dies anhand von

Testläufen (im folgenden »CATTs« genannt) zu automatisieren, da sich dadurch
der Testaufwand für den Anwender erheblich reduzieren lässt. Zeigt das Sys-
tem bei der manuellen Prüfung oder der des CATTs einen Fehler, kann dies
zwei Ursachen haben:
A Das R/3-System ist fehlerhaft installiert.
B Die Transaktion ist nicht in Ordnung.
Wenn eine fehlerhafte Installation ausgeschlossen werden kann, dann muss der
jeweilige Programmierer der Transaktion benachrichtigt werden. Er erhält den
Auftrag, die fehlerhafte Transaktion neu zu überarbeiten.
Aufbau von Stammdaten im Rahmen der Altdatenübernahme

sowie Anlegen neuer Stammdaten
Wenn in einem Unternehmen verschiedene alte Anwendungssysteme durch
das R/3-System abgelöst werden, müssen sämtliche bestehenden wichtigen Alt-
daten des Unternehmens wie z.B. Materialien, Kreditoren oder Debitoren usw.
natürlich auch in das neue R/3-System übernommen werden, damit der Betrieb
des Unternehmens aufrechterhalten werden kann.
Es wäre ein sehr mühseliger Weg, jeden Datensatz manuell in das R/3-System
einzupflegen. Mit CATT bietet sich dem Anwender nun die Möglichkeit, aus ex-
83
Sandini Bib
ternen Dateien, wie z.B. Excel-Tabellen Datensätze per CATT automatisiert ins
R/3-System einzulesen und zu verarbeiten. Dies senkt den Arbeitsaufwand bei
der Altdatenübernahme in erheblichem Maße, wie die Erfahrungen beim prak-
tischen Einsatz des Tools gezeigt haben. Voraussetzung hierfür ist allerdings,
dass die zu übernehmenden Altdaten bereits detailliert und zuverlässig mittels
eines Tabellenkalkulationsprogrammes aufbereitet wurden und in einer von
CATT lesbaren Form vorliegen.
In diesem Zusammenhang wird auf Kapitel 8 verwiesen. Dort wird die Vorge-
hensweise zur Einbindung von Daten aus externen Excel-Dateien in CATT-Ab-
läufe detailliert beschrieben.
Mittels entsprechender CATT-Abläufe können natürlich auch Stammdaten je-
der Art im R/3-System neu generiert werden. Falls für einen Integrationstest
100 Materialien benötigt werden, muss lediglich der CATT-Ablauf »Material
anlegen« einhundertmal durchlaufen werden. Bezogen auf den Aufwand, der
sich beim manuellen Anlegen dieser 100 Materialien ergeben würde, bedeutet
diese Automatisierung durch CATT eine erhebliche Erleichterung.
Zudem bietet diese Art der Datenübernahme ein hohes Maß an Datensicherheit.
»Datensicherheit« bedeutet in diesem Zusammenhang, dass bei der Datenüber-
nahme die manuelle Eingabe simuliert wird, also wie bei einem Batch Input alle
Eingabemasken durchlaufen und alle Integritätsprüfungen durchgeführt wer-
den.
Einstellung von Customizing-Tabellen und Testen der

Auswirkungen dieser Customizing-Einstellungen
In der Einführungsphase Detaillierung und Realisierung werden, wie bereits er-
wähnt, die firmenspezifischen Anpassungen durch das bereits beschriebene
Customizing am R/3-System durchgeführt. Mit CATT können Änderungen in
Customizing-Tabellen durchgeführt werden. Bei einer Änderung werden die
ursprünglichen Werte in einer internen Tabelle gesichert und können später von
CATT wiederhergestellt werden. So kann man die Auswirkungen der Änderun-
gen von Customizing-Tabellen problemlos überprüfen, ohne sich um die ur-
sprünglichen Eintragungen Sorge machen zu müssen. Die Auswirkungen die-
ser Customizing-Änderungen können durch die Verwendung von CATT-
Abläufen getestet und bei Bedarf natürlich auch wieder in ihren Ursprungszu-
stand zurückversetzt werden. Zur Veranschaulichung dieser Funktionalität
sind in den Kapiteln 4 und 5 entsprechende Beispiele angeführt.
Abschlusstest durchführen
Die Phasenaktivität Abschlusstest durchführen ist eine Aktivität des traditionellen
SAP-Vorgehensmodells, die eine der umfangreichsten Aufgaben im Bereich des
Testens darstellt. Wie bereits oben gezeigt wurde, wird für diese wichtige Akti-
84
Sandini Bib
vität jedoch nur ganz allgemein beschrieben, was an Aufgaben zu bewältigen

ist, nicht jedoch, wie dies geschehen soll.
Anhand der fünf Arbeitspakete wird im Folgenden nun kurz darauf eingegan-
gen, welche der SAP-eigenen Testtools wie eingesetzt werden können.
A Testkonzept erstellen
Mit der Test-Workbench des SAP R/3-Systems kann das Testkonzept über
die Testworkbench abgebildet werden. Nachdem die Testszenarien be-
stimmt wurden, können mit der Testworkbench Testkataloge angelegt wer-
den. Hierbei sollte jedes Szenario einem Testkatalog entsprechen.
B Testplan erstellen
Mit der Testworkbench können des Weiteren Testpläne erstellt werden, die
einzelne Testfälle nach ihrem Testzweck bzw. zeitraumbezogen unterteilen.
Außerdem können diese Testpläne wiederum in Testpakete gegliedert wer-
den, die es ermöglichen, den Testfällen einen Tester zuzuordnen. Basis für
den Testplan ist das Testkonzept. Die einzelnen Testfälle, die den Testplänen
und den Testpaketen zugeordnet werden, entsprechen den mit dem Compu-
ter Aided Test Tool aufgezeichneten Testabläufen.
C Testaktivitäten durchführen
Die Testaktivitäten können entweder direkt aus dem CATT heraus durch das
Starten einzelner CATTs oder aber aus der Testworkbench heraus durch das
Starten von einzelnen Testabläufen, Gruppen von Testabläufen oder auch

von allen Testabläufen ausgeführt werden. Wie viele CATTs gestartet wer-
den, ist abhängig davon, von welchem Knoten der Testworkbench aus der
Test angestoßen wird. Der Testumfang ist also frei variierbar. Außerdem
kann entschieden werden, ob die CATTs »live« am Bildschirm, also mit Bild-
schirmunterstützung (»Helles Abspielen«) oder ohne Bildschirmunterstüt-
zung (»Dunkles Abspielen«) durchlaufen werden.
Eine weitere Aufgabe dieser Aktivität ist die Dokumentation der Tests. Auch
diese Tätigkeit wird vom CATT dadurch unterstützt, dass es zu jedem ein-
zelnen Test automatisch ein Protokoll erzeugt. Bei diesem Protokoll kann
zwischen einer Lang- und einer Kurzform gewählt oder aber es kann ganz
auf eine Protokollerstellung verzichtet werden.
D Bericht zu Abschlusstest erstellen
Der Abschlussbericht dient als Basis für die Abschlussreviews. Hier können
als Unterstützung sowohl die Testworkbench als auch die Testprotokolle
verwendet werden.
E Abschlussreview mit den Fachabteilungen durchführen
In den Abschlussreviews dienen die aufgezeichneten CATTs als Instrument,
um die Präsentation der einzelnen Geschäftsprozesse durchzuführen. Hier-
bei kann dann je nach Bedarf darüber entschieden werden, in welchem Um-
85
Sandini Bib
fang die einzelnen Geschäftsprozesse vorgeführt werden. Auch hier kann

wiederum zwischen »hellem Abspielen (mit Bildschirmunterstützung)« und
»dunklem Abspielen (ohne Bildschirmunterstützung)« gewählt werden.
Darüber hinaus kann auch die Anzahl der zu betrachtenden Testfälle pro Te-
stablauf je nach Bedarf festgelegt werden.
Sämtliche Aktivitäten des Abschlusstests können also durchgängig, angefangen
beim Testkonzept über die Testdurchführung bis hin zur Testdokumentation,
unter Anwendung der Testworkbench des SAP R/3-Systems durchgeführt wer-
den.
Durchführung von Modul- sowie Integrationstests anhand der

Abbildung betriebswirtschaftlicher Prozessketten mittels CATT
Wie bereits in Kapitel 1 angesprochen, ist das R/3-System in diverse, einzelne
Module unterteilt. Dies heißt mit anderen Worten, dass im Grunde jedes R/3-
System beim R/3-Endkunden eine integrative Verkettung mehrerer Module
darstellt. Das R/3-System weist demnach eine umfassende Funktionalität auf.
Die Integration der Anwendungen ist lediglich Voraussetzung für die Durch-
gängigkeit aller Funktionen im System und damit auch im Unternehmen. Eine
solche Durchgängigkeit wird erst gewährleistet, wenn die einzelnen Module an
die Anforderungen des Unternehmens angepasst und schließlich auch modul-
bezogen getestet werden. Der Modultest ist die erste, unterste Stufe des compu-
tergestützten Testens bei der Softwareentwicklung. Zuerst werden hierbei alle
elementaren Bausteine als Fundament eines Programmsystems getestet und
dann erst ihre Integration. Die Minimalforderung für den Test eines Software-
moduls muss dabei sein, dass mindestens alle Programmzweige einmal durch-
laufen werden und das Modul gemäß seiner Spezifikation reagiert. Man
bezeichnet den Modultest auch als Einzeltest. Auf die entsprechenden Ausfüh-
rungen in Kapitel 1 dieses Buches sei an dieser Stelle verwiesen.
Bei der Durchführung dieser Modultests kann sich der Anwender von CATT
unterstützen lassen. Man nehme hierfür beispielhaft das Vertriebsmodul SD
(Sales and Distribution). Im Vertrieb werden Produkte an verschiedenste Ge-
schäftspartner verkauft, und/oder es werden diverse Dienstleistungen für sie
erbracht. Angefangen beim Verkauf über Versand, Fakturierung, Konditionie-
rung, Transport bis hin zum Außenhandel usw. werden sämtliche Vertriebsauf-
gaben erfüllt. Die Daten zu den Produkten und Dienstleistungen sowie zu den
Geschäftspartnern sind Grundlage der Vertriebsabwicklung mittels der R/3-
Applikation SD. Um im Modul SD einen Kundenauftrag anlegen zu können, ist
zunächst eine Kundenanfrage erforderlich, der ein Angebot an den Kunden
folgt. Für jeden dieser Belege (Anfrage, Angebot, Auftrag) wird vom System
eine eigene Belegnummer generiert. Um ein Angebot im R/3-System anlegen zu
können, wird die Belegnummer der Anfrage bei der Angebotserstellung als
zwingende Eingabe vorausgesetzt, da alle Daten aus der Anfrage auf diesem
Wege automatisch ins Angebot übernommen werden können. Die Auftragsein-
86
Sandini Bib
gabe erfordert wiederum die Belegnummer des Angebots usw. Mit den Mög-
lichkeiten von CATT könnte man jetzt beim Modultest z.B. den funktionalen be-
triebswirtschaftlichen Prozess »Anfrage anlegen, Angebot anlegen, Auftrag
anlegen, Lieferung und Transport anlegen« abbilden und auf seine hoffentlich
einwandfreie Durchgängigkeit im System testen. Der Modultest in diesem Bei-
spiel ist erst dann erfolgreich abgeschlossen, wenn letztendlich alle vom Kun-
den beispielhaft im Testszenario bestellten Waren in der richtigen Menge zum
richtigen Zeitpunkt am richtigen Ort eingetroffen sind; der Prozess also erfolg-
reich durchlaufen wurde. Der fehlerfreie Datentransfer zwischen den einzelnen
Transaktionen ist dabei unabdingbare Voraussetzung. Bei einem rein funktional
auf SD bezogenen Modultest ist es natürlich notwendig, dass entsprechende
Stammdaten für Materialien, Kunden etc. bereits im System vorhanden sind.
Falls dies nicht der Fall sein sollte, kann CATT, wie bereits beschrieben, natür-
lich auch dazu verwendet werden, die benötigten Stammdaten als grundlegen-
de Basis für die Modultests zu erzeugen.
Integrationstest
Der Integrationstest als solcher wurde bereits in Kapitel 1 dieses Buches näher
definiert. Auf diese Ausführungen sei an dieser Stelle verwiesen.
Bei der R/3-Einführung ist die detaillierte Überprüfung daraufhin, ob die ein-
zelnen Abhängigkeiten von Geschäftsprozessen mit der Wertschöpfungskette
übereinstimmen, Teil des Integrationstests. Der Integrationstest schließt auch

Schnittstellen, Ausgabe- und Druckfunktionen sowie Systemerweiterungen mit
ein. Darüber hinaus umfasst er abteilungsübergreifende Bereiche und stützt
sich in diesem Kontext auf Ergebnisse vorangegangener Aufgaben. Der Test
wird im Qualitätssicherungssystem durchgeführt.
Ablauf des Integrationstests bei der R/3-Einführung:
A Ziele des Integrationstests aufstellen
Zunächst sind die Ziele des Integrationstests festzulegen. Dabei ist darauf zu
achten, dass dieser Arbeitsschritt oberste Priorität genießt, kurz ist und im-
mer messbare Ziele verfolgt. Die allgemeinen Richtlinien bezüglich der Ziele
umfassen folgende Punkte. Wenn eine bestimmte Produktlinie 85 % des Ge-
schäfts ausmacht, müssen in diesem Bereich die Mehrzahl der Tests durch-
geführt werden. Die Gewichtung der jeweiligen Hauptproduktlinien nimmt
man vor, indem man sie auf einer Liste zusammenfasst und jeweils mit ei-
nem Testlevel versieht. Sollte ein Bereich dabei sein, dem erhöhte Aufmerk-
samkeit gewidmet werden muss, so gilt es, für diesen spezielle Testziele zu
formulieren.
B Bestimmung der Teststrategie
Hier definiert man die für diesen Abschnitt ausschlaggebenden Testkriteri-
en. Eine Teststrategie besagt z.B., dass die Integrationstests bis zum 1. De-
87
Sandini Bib
zember abgeschlossen sein müssen, damit der Produktionscutover am 1. Ja-

nuar stattfinden kann. Dies ist ein Testziel, das Einfluss auf den Umfang der
Tests hat.
C Umfang des Integrationstests festlegen
Der Umfang des Integrationstests bestimmt dessen Inhalt.. Sie bestimmen
die Grenzen des Integrationstests. Zu diesem Umfang gehören Anwen-
dungskomponenten, betroffene Unternehmen (Länder, Werke), Testumfel-
der (Produktlinien) und das technische Umfeld. Ziel dieses Abschnitts ist es,
die Grenzen für den Testinhalt und das Testende zu bestimmen.
D Abschlusskriterien festlegen
Die Integrationstests sind beendet, wenn keine Fragen mehr offen sind. Weil
dies aber eher selten der Fall sein wird, gilt es, allgemeinverbindliche Krite-
rien aufzustellen, bei deren Eintreffen der Test als abgeschlossen gilt, wäre
doch sonst eine Verwirrung bei den Beteiligten bezüglich des Testendes die
logische Folge. Der Integrationstest wird dann so lange fortgeführt, bis ein
Kompromiss erreicht wird.
E Umfang des Integrationstests und Abschlusskriterien abnehmen
In diesem Arbeitsschritt muss zunächst sichergestellt werden, dass zwischen
den Teamleitern Einigkeit über die Ziele, den Umfang und die Abschlusskri-
terien des Integrationstests besteht. Dazu wird ein Team zusammengestellt,
das prüft, ob alle Bereiche und Funktionen richtig repräsentiert werden.
Dazu soll der Testumfang dokumentiert und mit dem Team durchgegangen
werden.
Es gibt sehr viele Fälle, in denen Unternehmen ohne ausreichende Tests mit der
Produktion begonnen haben. Diese Unternehmen sehen sich nach der Einfüh-
rung mit Problemen konfrontiert. Abschlusskriterien und ein gutes Integrati-
onstestprogramm führen zu einer guten Lösung. Deshalb ist es sehr zu empfeh-
len, den Integrationstest des R/3-Systems in dieser Phase sehr detailliert zu
planen und durchzuführen.
4.1.2 Phase Produktivvorbereitung

In der Produktivvorbereitung werden für den Produktivstart notwendige Maß-
nahmen wie Dokumentationen, Systemtest und Anwenderschulungen durch-
geführt. Das Endergebnis dieser Phase ist ein eingerichtetes Produktivsystem.
In dieser Phase kann CATT für folgende Zwecke verwendet werden:
◗ Unterstützung und Durchführung von Anwenderschulungen
◗ Anwenderschulung mittels IDES
◗ Systemtest
88
Sandini Bib
Aufbau von Schulungsdaten

Man kann mit CATT eine Anwenderschulung vorbereiten. Wenn zum Beispiel
bei einer solchen Schulungsveranstaltung Material verbucht werden soll, be-
steht die Möglichkeit, per CATT für die Teilnehmer im Vorhinein automatisiert
Materialien mit fortlaufenden Materialnummern anzulegen. Darüber hinaus
kann man den Schulungsteilnehmern auch vollständig aufgezeichnete, komplexe
betriebswirtschaftliche Prozesse, die sich über mehrere R/3-Module erstrecken,
vorführen und erläutern. Dies spart erheblich Zeit ein, da die Prozesse nur ein-
mal aufgezeichnet werden müssen, dann aber für beliebig viele Anwendungen
zur Verfügung stehen. CATT bietet die Option, Testläufe »step by step« ablau-
fen zu lassen, wobei auf dem Monitor Bildschirmbild für Bildschirmbild in ihrer
logischen Reihenfolge gezeigt werden. Dadurch können dem späteren Anwen-
der die Herkunft und Weiterverwendung seiner Daten im Rahmen der in Kapi-
tel 1 beschriebenen R/3-Integration aufgezeigt und verständlich gemacht wer-
den. Darüber hinaus können mit diesen vorbereitenden Abläufen auch
komplette Customizing-Einstellungen vorgenommen werden.
Unterstützung und Durchführung von Anwenderschulungen

nach ASAP
A Schulungsunterlagen für Benutzer zusammenstellen
Zweck dieser Aufgabe ist es, per CATT-Unterstützung die Schulungsunter-

lagen für Benutzer vorzubereiten. Diese können auch Folien, Grafiken, Texte,
Policen, Bildschirmabbildungen, unternehmensspezifische Übungen usw.
enthalten. Dieses Material kann für Einführungsschulungen der Benutzer
und für die Schulung neuer Mitarbeiter verwendet werden.
B Vorgehensweise
Die mit den Experten der einzelnen Bereiche zusammenarbeitenden Schu-
lungsentwickler sollten bei sämtlichen Kursen im voraus festlegen, welche
Kurse beschreiben sollen, wie man das R/3-System verwendet, um die Ge-
schäfte des Unternehmens zu führen. Diese könnten mit einem Kurs begin-
nen, der eine Übersicht über das R/3-System gibt.
C Ablauf
Der SAP-Einführungskurs sollte Voraussetzung für alle anderen Kurse sein.
Dabei sollte man bedenken, dass diese Kurse für verschiedene Zielgruppen
auf verschiedenen Ebenen der Systembenutzung zugeschnitten sein sollten,
und zwar einschließlich sporadischer Benutzer, Sachbearbeiter und Power
User. Dieser Kurs sollte folgendes beinhalten:
◗ Die Geschäftsziele des Unternehmens für die Einführung von SAP R/3
und die Vorteile gegenüber dem gegenwärtigen System des Unterneh-
mens.
89
Sandini Bib
◗ In welcher Weise wird das Unternehmen das R/3-System verwenden.

Dabei werden die Geschäftsprozesse für das gesamte Unternehmen her-
vorgehoben, und es wird gezeigt, dass es sehr einheitlich gestaltet ist.
◗ Die grundlegenden Navigationsmerkmale des R/3-Systems sollten ver-
mittelt werden.
◗ Eine Einführung in die R/3-Online-Hilfe, Matchcodes und andere hilfrei-
che R/3-Werkzeuge sollte gegeben werden.
D Betriebswirtschaftliche Benutzerkurse
Diese Kurse sollten sowohl die neue Rolle des Benutzers beschreiben, der das
R/3-System verwendet, als auch zeigen, wie man das R/3-System nutzt, um
die eigene Arbeit zu erledigen. Die Kurse sollten detaillierte Verfahren be-
reithalten, um die mit jedem Geschäftsprozess verbundenen Aufgaben
durchzuführen, und sollte praktische Übungen mit dem System enthalten.
Es ist außerdem ratsam, dass jeder Kurs Folgendes umfasst:
◗ Kurs-Titelseite
◗ Vorwort
◗ Kursvoraussetzungen
◗ Zielgruppe
◗ Einleitung, einschließlich Kurs- und Lernziele und ein Geschäftsszenario,
das den Teilnehmer in die bei der Verwendung des R/3-Systems anzu-
nehmende Rolle versetzt.
◗ Andere Einheiten (oder Kapitel) beschreiben den Geschäftsprozess und
die Art seiner Durchführung. Jedes Kapitel sollte eine Inhaltsangabe,
Lernziele, Präsentationen des Geschäftskonzepts, Übungen, Lösungen
und Testfragen enthalten.
◗ Daten für alle Benutzer, um Übungen durchzuführen. Es empfiehlt sich,
die Daten immer für jeweils zwei Teilnehmer, die Sie unterrichten, vorzu-
bereiten. Für SAP-Projektteamschulungen bietet die SAP AG 20 Daten-
gruppen an, die von CATT erzeugt werden können.
◗ Anhang für Referenzen. Wenn man Listen der Konten, Kostenstellen,
Transaktionscodes, Verfahren, Menüpfade usw. hat, verwendet man am
besten den Anhang für diese Informationen. Im Verlauf des Kurses sollte
man desöfteren auf den Anhang verweisen.
E Tipp
Die Kursentwicklung kann mit BPML beschleunigt werden. Rollenbasierte
Schulungen sollen dem Einzelnen in erster Linie die für die Erfüllung seiner
Jobfunktionen notwendigen Fähigkeiten vermitteln. Diese Schulung enthält
eine Übersicht über das R/3-System und Hintergrundinformation. Sie setzt
90
Sandini Bib
sich aus Einzelbereichen zusammen und basiert auf Benutzerrollen. Diese

Kurse beginnen auf hohem Niveau und bewegen sich dann zu einer detail-
lierten Erörterung der in den Geschäftsprozessen durchgeführten Transak-
tionen.
Den rollenbasierten Lehrplan erhält man über die Informationsdatenbank
bzw. wenn man für die Info DB lizensiert ist, kann man dort Kursentwick-
lung noch weiter beschleunigen, indem man auf die Vorlage der Business
Process Masterlist zurückgreift, die rollenbasierte Schulungskurse und für
die Prozessebene relevante Einheiten festlegt.
Anwenderschulung mittels IDES

Die SAP AG setzt das Computer Aided Test Tool darüber hinaus bei IDES (Inter-
national Demonstration and Education System), dem vollständig ins R/3-System
integrierten und vorkonfigurierten Schulungssystem der SAP AG, ein. Dabei wird
CATT zum Aufbau der Stammdaten, zum Testen von Prozessketten, zum Erzeu-
gen von Bewegungsdaten und zum Aufbau von Schulungsdaten verwendet.
Zum besseren Verständnis soll IDES kurz erläutert werden. IDES stellt eine Mu-
sterfirma dar und eignet sich in ihrer Ausprägung als internationaler Konzern
mit Tochtergesellschaften in verschiedenen Ländern hervorragend als ein sehr
ausführlicher Demoleitfaden für den Anwender, der zum Selbststudium der
umfangreichen Systemfunktionalitäten des R/3-Systems genutzt werden kann.
IDES enthält beispielhafte Anwendungsdaten für unterschiedliche Geschäfts-

prozesse im System R/3. In IDES sind diese Prozesse genau wie in einem rich-
tigen Unternehmen abgebildet, da sie mit vielen realistischen Merkmalen ver-
sehen sind. Auf diese Weise macht IDES die anspruchsvolle Funktionalität des
R/3-Systems an leicht nachvollziehbaren Beispielen deutlich. Der Schwerpunkt
von IDES liegt jedoch nicht auf der Darstellung einzelner Funktionen, sondern
auf den durchgängigen Geschäftsprozessen und deren Integration. Mit IDES
lernt der Anwender zu verstehen, wie das R/3-System betriebswirtschaftliche
Prozesse und Abläufe unterstützt.
Anhand von IDES können alle Beispiele und Übungen aus den SAP-Schulungs-
programmen nachvollzogen und sogar vertieft werden. Im IDES sind sehr viele
sogenannte Kernprozesse abgebildet, die eine hohe Integration aufweisen und
wichtige Geschäftsprozesse darstellen.
Im Bereich Einzelfertigung der Logistik ist zum Beispiel der Prozess »Kundenein-
zelfertigung mit konfigurierbarem Produkt« zu finden. Hier handelt es sich um
eine Motorradfertigung, welche folgende Prozessschritte im R/3-System umfaßt:
Erfassung eines Kundenauftrages im R/3-Modul SD (Sales and Distribution).
Übertragung des Bedarfes, Erzeugung eines Fertigungsauftrages und Produktion
des Fertigungsauftrages jeweils im R/3-Modul PP (Production Planning). Der
Versand sowie die Fakturierung des Auftrags wird über SD abgewickelt, die Kon-
trolle der Kosten und Erlöse im CO (Controlling) vorgenommen.
91
Sandini Bib
Um diesen Prozess am IDES-System überhaupt durchspielen zu können, ist es

notwendig, dass die dazu erforderlichen Materialien im System vorhanden
sind. Falls keine Materialien vorhanden sind bzw. der Materialbestand nicht die
erforderliche Höhe aufweist, müssen neue Materialien angelegt werden. Mithil-
fe eines CATT-Ablaufes können die Voraussetzungen (»Material anlegen«) für
diesen Prozess erzeugt werden. Durch den automatisierten CATT-Ablauf wer-
den die Bestände der einzelnen Materialien auf die für den Prozessablauf not-
wendige Höhe aktualisiert. Jedesmal, wenn der Materialbestand die Untergren-
ze schließlich wieder unterschreitet, lässt man in der IDES-Schulung wieder den
CATT »Material anlegen« ablaufen, um neues Material zu generieren. CATTs
reduzieren also den Aufwand beim Anlegen der verschiedensten Stammdaten
für IDES-Schulungen erheblich. Das Computer Aided Test Tool kann natürlich
auch dazu genutzt werden, komplette IDES-Prozesse zu testen und zu automa-
tisieren.
Der IDES-Anwender kann CATT zusammenfassend also wie folgt nutzen:
◗ Aufbau von Stammdaten
◗ Erzeugen von Bewegungsdaten
◗ Aufzeichnung und Automatisierung komplexer betriebswirtschaftlicher
Prozesse zu Testzwecken.
Im Anhang dieses Buches ist eine Aufstellung darüber enthalten, wo in IDES
CATT jeweils eingesetzt wird.
IDES steht bei jedem Korrekturrelease zur Verfügung. Das Upgrade auf ein neu-
es Release ist mit IDES allerdings nicht möglich. Die Hotpackages zu den ent-
sprechenden Korrekturreleases können eingespielt werden. Mit einem neuen
IDES-Release ist also eine Neuinstallation verbunden. Nur so ist es gewährlei-
stet, neue Stamm- und Bewegungsdaten, eines neues Customizing und eine
neue Dokumentation ausgetestet und in entsprechender Qualität auszuliefern.
An dieser Stelle sei hinsichtlich ausführlicherer Darstellungen bezüglich dieser
Thematik auf die Schulungsunterlagen der SAP AG zu IDES sowie die Online-
Dokumentation im R/3-System verwiesen.
Systemtest
Bei einem R/3-Einführungsprojekt ist regelmäßig eine sogenannte Doppelin-
stallation vorhanden. Dies bedeutet, dass im Unternehmen sowohl ein Testsys-
tem als auch ein Produktivsystem existieren
Bei der Verwendung eines Testsystems sowie eines Produktivsystems werden
u.a. bei der Produktivsetzung verschiedenste Berechtigungen, Berechtigungs-
profile, Berichte und Altdaten aus dem Testsystem in das Produktivsystem
überspielt. In das Produktivsystem können natürlich auch die bereits im Testsys-
92
Sandini Bib
tem verwendeten CATT-Testbausteine und -abläufe übernommen werden.

Nach der Übernahme der notwendigen Daten, wird das Produktivsystem mit-
tels CATT und den übernommenen Testeinstellungen erneut getestet. Wenn die
Einstellungen im Testsystem richtig vorgenommen und diese dann samt den er-
forderlichen Stammdaten vollständig und fehlerfrei ins Produktivsystem über-
nommen wurden, müssen die CATT-Tests auch im Produktivsystem erfolg-
reich laufen. Falls dies nicht der Fall sein sollte, ist es unbedingt erforderlich, die
Einstellungen des Systems zu überprüfen und ggf. zu berichtigen. Der System-
test wurde im einleitenden Kapitel dieses Buches bereits erläutert. Das Ender-
gebnis der Produktvorbereitung sollte ein geprüftes, fehlerfreies produktives
System sein.
Die an SAP-Kunden ausgelieferten R/3-Systeme beinhalten mittlerweile bereits
eine große Zahl von voreingestellten CATT-Abläufen, welche von der SAP AG
programmiert wurden und vom Kunden sofort für verschiedenste Zwecke ge-
nutzt werden können. Dadurch wird das Computer Aided Test Tool sinnvoll er-
gänzt und dem SAP-Kunden der Einstieg in die CATT-Materie erleichtert. Die
SAP AG entwickelt in Zusammenarbeit mit ihren Entwicklungspartnern für die
verschiedensten Bereiche sogenannte Branchenmodelle bei denen ebenfalls
CATT-Abläufe zur Qualitätsverbesserung verwendet werden. Auch hier ist es
beabsichtigt, voreingestellte CATT-Abläufe an die Kunden auszuliefern.
4.1.3 Phasenübergreifender Einsatz von CATT

Phasenübergreifend können folgende CATT-Funktionalitäten bei der R/3-Einfüh-
rung genutzt werden:
◗ Prüfen von System- bzw. Fehlermeldungen
◗ Prüfen von Wertermittlung und Datenbankfortschreibungen
◗ Erzeugen von Testdaten
◗ Einsatz bei FCS-Version / Release- und Regressionstests
◗ Schnittstellenprogramme testen und prüfen
◗ Verbindung von SAP Business Workflow und CATT
Prüfen von System- bzw. Fehlermeldungen

Transaktionen verändern Daten und benutzen System- und Fehlermeldungen
für die Rückmeldung über ihren erfolgreichen bzw. nicht erfolgreichen Ablauf.
Bei der Eingabe von Werten überprüfen Transaktionen diese auf ihre Richtigkeit
hin. Dies kann z.B. die Eingabe des Datums in einem bestimmten vorgegebenen
Format sein. Werden diese Eingaben nicht oder nicht korrekt getätigt, erscheint
eine System- bzw. eine Fehlermeldung. Ferner kann man mittels CATT feststel-
93
Sandini Bib
len, ob die jeweiligen Fehler- oder Systemmeldungen bei der Transaktion hin-
terlegt sind und eine korrekte Reaktion erfolgt.
Darüber hinaus werden Systemmeldungen innerhalb von CATT-Abläufen
dazu genutzt, um bestimmte Aktionen zu veranlassen. Erscheint z. B die Fehler-
meldung beim Anlegen eines Terminauftrages »Debitor nicht vorhanden«,
dann wird der entsprechende CATT-Ablauf diesen Debitor anlegen.
Prüfung von Wertermittlung und Datenbankfortschreibungen

Mit CATT können Werte aus Datenbankfeldern gelesen und damit Datenbank-
fortschreibungen nach der Ausführung von Transaktionen überprüft werden.
Des Weiteren kann eine Tabelle auf das Vorhandensein eines bestimmten Ein-
trags hin untersucht werden. Wird z.B. ein Kreditor per CATT angelegt, so kann
man überprüfen, ob dieser Kreditor auch wirklich in der dazugehörigen Tabelle
enthalten ist.
Erzeugen von Testdaten

Wenn Transaktionen getestet werden, sollte dies nicht in einem Produktiv-
system, sondern in einem Testsystem geschehen. Um nun in diesem Testsystem
arbeiten zu können, müssen Daten vorhanden sein. Diese Testdaten z.B. Mate-
rialien, Debitoren, Kreditoren usw. können mit CATT angelegt werden. Ent-
sprechende Testdaten sollten so aufgebaut sein, dass alle eventuell auftretenden
Möglichkeiten zum Testen einer Transaktion berücksichtigt werden (z.B. char-
genpflichtiges Material, Sprachabhängigkeit, usw.). Man bezeichnet diese
CATTs auch als vorbereitende Abläufe. Mit ihnen können darüber hinaus auch
komplette Customizing-Einstellungen vorgenommen werden.
Einsatz bei FCS-Version / Release- und Regressionstests

Zu dem Zeitpunkt, an dem ein R/3-Release beim Kunden in der so genannten
»FCS-(First Customer Shipment«)-Version vorliegt, kann die Arbeit mit CATT
begonnen werden. In dem Zeitraum, der bis zur allgemeinen Marktverfügbar-
keit des Systems vergeht, können beliebige Testaktivitäten vorbereitet und rea-
lisiert werden, die sich in detaillierter Weise zum einen mit den (zahlreichen)
neuen Funktionen eines neuen Releases auseinandersetzen. Zum anderen kann
mit Hilfe dieser Tests ein so genanntes »Regressionstestpaket« dynamisch ent-
wickelt werden, das sich wesentlich an die für den jeweiligen Kunden entschei-
denden Geschäftsprozesse anlehnt. Ein solches Regressionstestpaket sorgt für
die Sicherung der Funktionsfähigkeit von bereits getesteten Geschäftsprozessen
und -vorfällen aus früheren Releaseversionen auch für die aktuelle Version des
R/3-Systems. Folglich können durch den Einsatz des CATT-Tools auch hier ma-
nuelle Testaktivitäten während des eigentlichen Testzeitraums in erheblichem
Umfang eingeschränkt werden.
94
Sandini Bib
Die Erfahrungen aus der Praxis zeigen, dass alle neuen R/3-Releaseversionen
mit ihrer allgemeinen Verfügbarkeit möglichst umgehend installiert und aus-
führlichen Tests unterzogen werden sollten. Als unabdingbare Voraussetzung
für dieses Testvorhaben gilt es, zunächt ein flexibles Systemumfeld zu schaffen.
Denn die Überprüfung neuer Releases sollte eigentlich simultan auf mehreren
Testsystemen mit nahezu identischem Testumfang durchgeführt werden. Das
CATT-Werkzeug ist bei dieser Aufgabe sehr komfortabel einsetzbar. Es erlaubt
die höchst flexible Verteilung der verschiedenen Testaktivitäten von einem zen-
tralen Test-Repository aus, mit dem die verschiedenen Testsysteme angespro-
chen werden können, je nach dem, welches gerade aktiv ist.
Durch diese Funktionalität von CATT können z.B. die R/3-Einführungsprojek-
te bei multinational agierenden Unternehmen, die verschiedene R/3-Releases
einsetzen, bei den Roll-outs in erheblichem Maße unterstützt werden.
Schnittstellenprogramme testen und prüfen

Der erklärte und beabsichtigte Zweck dieser Aufgabe ist es, im Detail zu über-
prüfen, ob die erforderlichen Funktionen aller notwendigen Schnittstellenpro-
gramme entsprechend den definierten Anforderungen erfüllt wurden. Ferner
werden im Rahmen dieser Tests sowohl die Datenkonsistenz als auch die An-
forderungen an den Systemdurchsatz mit Hilfe der vorher definierten Testver-
fahren geprüft.
Zur Durchführung dieses Testvorhabens empfiehlt sich folgende Vorgehens-

weise:
A Definition der Testdaten: Die Qualität der einzelnen Tests ist sehr stark von
der Wahl der geeigneten Testdaten abhängig. Die Testdaten sollten aus eben
diesem Grunde weitgehend identisch mit echten Produktivdaten des Sy-
stems sein, damit alle möglichen denkbaren Datenfälle und damit auch die
vollständigen Funktionen der diversen Schnittstellenprogramme getestet
werden können. Es empfiehlt sich in diesem Zusammenhang, einen Durch-
satztest durchzuführen, um exakte Laufzeitschätzungen für die Produktiv-
umgebung vornehmen zu können.
B Durchführung eines Datenübernahmetests: Vor Durchführung der Tests
sollte man sicherstellen, dass die an den Tests beteiligten Qualitätssiche-
rungssysteme entsprechend vorbereitet sind und über die richtigen Konfigu-
rationseinstellungen (extern zum R/3-System) und Customizing-Voreinstel-
lungen (innerhalb des R/3-Systems) verfügen. Während der Tests sollten
darüber hinaus auch die Werkzeuge zur Fehlerbehandlung und Überwa-
chung sowie die implementierten und die im R/3-System enthaltenen Proze-
duren überprüft werden. Wenn möglich, empfiehlt es sich, auch Mitarbeiter
mit einzubeziehen, die in der Produktivumgebung für diese Aufgaben ver-
antwortlich sind.
95
Sandini Bib
C Überprüfung der Datenkonsistenz innerhalb des R/3-Systems und des exter-

nen Systems: Wurden während der Testläufe keine Fehler entdeckt, muss die
Datenkonsistenz innerhalb des R/3-Systems überprüft werden. Dabei sollte
man auch die externen Systeme in diese Tests mit einbeziehen, da diese auch
Teil der verteilten Geschäftsvorgänge sind. Es ist sehr wichtig, dass die Basis
der globalen Daten an der Schnittstelle konsistent bleibt.
D Überprüfung der Laufzeit: Hier sind die Laufzeiten im Rahmen von Durch-
satztests zu ermitteln. Dadurch erhält man eine Schätzung für die Laufzeit
der Produktivumgebung. Da die entwickelten Schnittstellen zusammen mit
anderen in der Produktivumgebung laufenden Anwendungssystemen auf
gemeinsame Ressourcen zurückgreifen, sollte man auch andere Faktoren be-
achten, die diese Tests beeinflussen können. In diesem Zusammenhang ist
auch sinnvoll, die Engpässe in der IT-Umgebung, die bei der Übernahme von
großen Datenmengen durch die Schnittstelle zu fatalen Folgen führen kön-
nen, zu identifizieren.
E Überprüfung der Schnittstellenprogramme: In manchen Fehlerfällen ist es
notwendig, die Schnittstellen zu reparieren. Nach einer solchen Reparatur
müssen die Testläufe mit denselben Daten und demselben Umfang wieder-
holt werden. Wenn die berechnete Zeit der Schnittstelle für große, produktiv-
ähnliche Daten zu lang ist, erfordert es die Situation, Überlegungen zu einer
Optimierung der Laufzeit anzustellen. Dabei untersucht man, ob die Bu-
chung, die Bereitstellung oder die einfache Datenübertragung zu viel Zeit in
Anspruch nimmt. Jeder Bestandteil der Schnittstelle ist bei der Untersuchung
zu berücksichtigen. Es empfiehlt sich, vor einer Laufzeitoptimierung der Pro-
gramme eine Überprüfung der optimalen Parametereinstellung des R/3-Sys-
tems und mögliche Optimierungen in der IT-Infrastruktur vorzunehmen.
F Verwendung von Testwerkzeugen, falls möglich. Der R/3-interne Teil der
Schnittstellen kann mithilfe des CATTs (Computer Aided Test Tool) aus
R/3 getestet werden (Transaktion SCAT). Mithilfe von CATT kann dabei der
Teil der Verarbeitung innerhalb des R/3-Systems überprüft werden (z.B. die
bei einer RFC-Verbindung verwendeten Funktionsmodule), jedoch nicht die
gesamte Schnittstelle selbst.
G Ergebnis: Testergebnisse, überprüfte Schnittstellenprogramme und Laufzeit-
schätzungen für die Produktivumgebung.
Verbindung von SAP Business Workflow und CATT

In Verbindung mit dem SAP Business Workflow ist es möglich, die aufgenom-
menen Testbausteine (z.B. Fakturabuchung, Kundenstammsatzbearbeitung,
Auftragserfassung, Lieferungsbearbeitung usw.) ereignisgesteuert ablaufen zu
lassen. Dies ist insbesondere für Prozesse interessant, in denen häufig Transak-
tionsabläufe in der gleichen Art und Weise zu bearbeiten sind. Über CATT kön-
nen dann die einzupflegenden Inhalte eingespielt werden.
96
Sandini Bib
4.2 Der ASAP-Ansatz

ASAP wurde 1996 von der SAP Amerika in Zusammenarbeit mit einer Vielzahl
von erfahrenen R/3-Beratern entwickelt. Hintergrund dieser Entwicklung war
der vielfach geäußerte Wunsch der US-Kunden von SAP nach wesentlich kür-
zeren Einführungszeiten. Diesem Wunsch wird nun mittels ASAP (Accelerated
SAP ) Rechnung getragen – seit 1997 auch in Europa. Mit dieser Einführungsme-
thodik sollen vor allem kleinere und mittlere Unternehmen die R/3-Software
innerhalb eines halben Jahres bzw. innerhalb von neun Monaten einführen kön-
nen.
Nach unserer Meinung ist ASAP aus dem heutigen klassischen R/3-Vorgehens-
modell entstanden und integriert neueste Erkenntnisse der R/3-Einführung.
ASAP ist demnach keine gänzlich neue Vorgehensweise, sondern stellt gesam-
meltes Know-how von SAP-Kunden und -Partnern zur Verfügung.
Bei der Realisierung der ASAP-Einführungmethode kann das Werkzeug CATT
sehr gut verwendet werden. Im Folgenden wird nun zunächst die ASAP-Me-
thode als solche kurz beschrieben. Anschließend wird nach bereits verwende-
tem Muster die CATT-Einbindung in jede ASAP-Phase gezeigt.
Grafisch dargestellt sind die ASAP-Roadmap wie folgt aus:
Abbildung 4.2 © SAP AG

Die ASAP-Roadmap
Wie die abgebildete ASAP-Roadmap zeigt, gründet die ASAP-Methode auf fünf
Phasen:
◗ Projektvorbereitung
◗ Business Blueprint
97
Sandini Bib
4.2 Der ASAP-Ansatz
◗ Realisierung
◗ Produktionsvorbereitung
◗ Go-Live und Support
Jeder dieser Phasen sind verschiedene Arbeitspakete zugeordnet, die im Ver-
lauf der Phase der Reihe nach abzuarbeiten sind. Dabei bieten sie den Anwen-
dern konkrete Hilfsmittel wie Beispieldokumente oder -präsentationen sowie
konkrete, zur Nachahmung empfohlene Vorgehensweisen an. Im Anhang sind
die Arbeitspakete mit all ihren einzelnen Aktivitäten aufgelistet.
Die ASAP-Einführungsmethode unterscheidet sich von anderen vor allem
durch den »Timebox-Ansatz«. Das zentrale Element eines ASAP-Projektes ist
seine Laufzeit, der Projektumfang muss sich an diese Zeitvorgabe anpassen. Das
gilt für das Gesamtvorhaben wie auch für jeden einzelnen Projektschritt. Des-
halb erfordert ASAP immer wieder schnelle und teilweise harte Entscheidun-
gen.
Im Folgenden sollen nun die fünf Phasen der ASAP-Roadmap kurz beschrieben
werden.
4.2.1 Phase 1: Projektvorbereitung

Diese Phase der ASAP-Einführungsmethode dient der Planung und Vorberei-
tung des R/3-Projektes. Folgende Punkte sind hier zu berücksichtigen:
◗ Ziele und Zielsetzungen des Projektes definieren
◗ Umfang der Einführung klären
◗ Einführungsstrategie festlegen
◗ Zeitplan für das Gesamtprojekt festlegen
◗ Organisation und Gremien des Projektes einrichten
◗ Ressourcen zuteilen
In dieser Phase müssen folgende Arbeitspakete abgearbeitet werden:
◗ Grobplanung des Projektes
◗ Projektprozeduren
◗ Kickoff des Projektes
◗ Planung der technischen Anforderungen
◗ Qualitätsprüfung und Projektvorbereitungsphase
98
Sandini Bib
4.2.2 Phase 2: Business Blueprint

Sinn und Zweck dieser Phase ist es, ein Dokument zu erstellen, welches eine de-
taillierte Dokumentation der in den Anforderungsworkshops der ersten Phase
erzielten Ergebnisse enthält. Dieses Dokument wird als Business Blueprint be-
zeichnet. Der Business Blueprint dokumentiert also die Anforderungen des Un-
ternehmens an die Geschäftsprozesse. Anhand dieser Dokumentation erhält
man einen genauen Überblick, wie das Unternehmen seine Geschäftsprozesse
künftig im R/3-System abbilden möchte.
Folgende Arbeitspakete müssen dabei erledigt werden:
◗ Schulung des Projektteams für die zweite Phase
◗ Systemumgebung definieren
◗ Organisationsstruktur festlegen
◗ Geschäftsprozessdefinition festlegen
◗ Qualitätsprüfung durchführen
4.2.3 Phase 3: Realisierung

Das primäre Ziel dieser Phase ist ein vollständig konfiguriertes, getestetes und

abgenommenes R/3-System. In dieser Phase werden die Anforderungen des
Kunden, die im Business Blueprint detailliert dokumentiert sind, implemen-
tiert. Mit bestimmten Werkzeugen werden alle wichtigen Informationen, die
zur Realisierung erforderlich sind, konsolidiert. Zur vollständigen Realisierung
müssen des Weiteren Programme zur Datenübernahme, für Schnittstellen und
für das Berichtswesen erstellt werden. In dieser Phase wird hierzu ein abschlie-
ßender Integrationstest durchgeführt, der voraussetzt, dass alle relevanten
Schnittstellen und Systemerweiterungen geplant, realisiert und getestet wer-
den. Die Konfiguration wird innerhalb des R/3-Systems über den Business En-
gineer vorgenommen, dokumentiert und transportiert.
Die Arbeitspakete dieser Phase sind:
◗ Schulung des Projektteams für die dritte Phase
◗ Basiskonfiguration (Baseline) erstellen und testen
◗ Systemverwaltung
◗ Detailkonfiguration erstellen und testen
◗ Erweiterungen, Reports und Formulare entwickeln
◗ Berechtigungskonzept erarbeiten
99
Sandini Bib
4.2 Der ASAP-Ansatz
◗ Archivierung einrichten
◗ Integrationstest durchführen
◗ Benutzerschulung planen und realisieren
◗ Qualitätsprüfung
4.2.4 Phase 4: Produktionsvorbereitung

In der vierten Phase sollen die Voraussetzungen für den Produktivbetrieb ge-
schaffen werden. Mit dem Abschluss dieser Phase sollen alle festgelegten Ge-
schäftsabläufe im R/3-System gemäß den Anforderungen bearbeitet werden
können.
Diese Phase beinhaltet folgende Arbeitspakete:
◗ Benutzerschulung
◗ Systemmanagement
◗ Planung Cutover and Support
◗ Cutover
◗ Help-Desk-Aufbau
◗ Qualitätsprüfung
In dieser letzten Vorbereitungsphase vor den Produktivbetrieb werden alle
noch offenen Punkte und Fragen geklärt. Nach dem erfolgreichen Abschluss
dieser Phase könne die Geschäftsprozesse mit dem R/3-Produktivsystem
durchgeführt werden.
4.2.5 Phase 5: Go-Live and Support

Ziel der fünften Phase ist es, den produktiven R/3-Betrieb zu unterstützen und
den Systemdurchsatz zu optimieren. Hier wird von der vorproduktiven Umge-
bung zum produktiven Produktionsprozess gewechselt. In dieser Phase haben
die Anwender erfahrungsgemäß sehr viele Fragen. Deshalb ist es notwendig,
eine solide Support-Einrichtung für die R/3-Benutzer zu schaffen. Diese sollte
aber nicht nur während der ersten kritischen Tage des Produktivbetriebs, son-
dern dauerhaft zur Verfügung stehen.
Diese Phase befasst sich mit folgenden Arbeitspaketen:
◗ Produktionssupport
◗ Aktivitäten nach dem Produktivstart
100
Sandini Bib
Mit dieser Phase wird das R/3-Einführungsprojekt abgeschlossen. Idealerweise

sollte nun eine permanente Optimierung und Weiterentwicklung des R/3-Sys-
tems erfolgen.
Aber auch die ASAP-Einführungsmethode hat mit denselben Problemen zu
kämpfen wie das klassische Vorgehensmodell zur R/3-Einführung (siehe die
entsprechenden Ausführungen unter Ziffer 4.1 dieses Kapitels). Auch den Pro-
blemen im Rahmen der ASAP-Vorgehensweise kann nun mit CATT effektiv be-
gegnet werden. CATT kann wiederum in jeder einzelnen Phase des ASAP-An-
satzes und natürlich auch phasenübergreifend eingesetzt werden für:
◗ das Testen von Transaktionen
◗ den automatisierten Aufbau von Stammdaten
◗ die automatisierte Übernahme von Stammdaten aus Altsystemen
◗ das automatisierte Einlesen von Daten aus Tabellenkalkulationssystemen
◗ das Testen von Customizing-Einstellungen
◗ die Durchführung von Modul- und Integrationstests
◗ die Unterstützung und Durchführung von Anwenderschulungen
◗ den Aufbau von Schulungsdaten
◗ die Anwenderschulung mittels IDES
◗ den Systemtest

◗ die Überprüfung von Fehlermeldungen des Systems
◗ das Prüfen von Wertermittlung und Datenbankfortschreibung
◗ die Erzeugung von Testdaten
◗ den Einsatz bei FCS-Version/Releasetests
◗ das Testen und Prüfen von Schnittstellenprogrammen
Da der ASAP-Ansatz aus dem traditionellen SAP-Vorgehensmodell hervorge-
gangen ist, stimmen viele Arbeitspakete der beiden Einführungsmethoden mit-
einander überein. Dies hat zur Folge, dass CATT bei Anwendung von ASAP ei-
nerseits in den mit dem traditionellen Vorgehensmodell vergleichbaren
Arbeitspaketen eingesetzt werden kann. Andererseits kann CATT nun aber
auch in vielen zusätzlichen Arbeitspaketen der verschiedenen ASAP-Phasen ef-
fektiv eingesetzt werden. Als Beispiel sei an dieser Stelle folgendes Arbeitspaket
genannt:
Arbeitspaket Vordefinierte Einstellungen einbeziehen
Zweck dieser Aufgabe ist es, vordefinierte Konfigurationspakete zur Beschleu-
nigung des Konfigurationsprozesses zu verwenden. Dabei ist es erforderlich,
die vordefinierten Konfigurationseinstellungen zu testen und sie gegebenen-
falls zu ändern.
101
Sandini Bib
4.2 Der ASAP-Ansatz
Als vordefinierte Einstellungen gibt es in ASAP den vordefinierten Mandanten

z.B. für den US-Markt. Dieser vordefinierte Mandant (PCC) liefert eine geprüf-
te, US-orientierte Umgebung. Er ist:
◗ der Ausgangspunkt für die Konfiguration.
◗ ein Basismandant mit einfachen Strukturen. Man kann auf dieser Grundlage
Konfigurationsszenarien erstellen und prüfen.
Es können z.B. Geschäftsszenarien für den Einkauf mithilfe der Prozesse des
CATTs, die mit dem PCC geliefert werden, durchgespielt werden. Dadurch
wird das Erlernen des R/3-Systems erleichtert und beschleunigt. Unnötige An-
passungseinträge werden gelöscht, um die Komplexität zu verringern.
Wenn ein Unternehmen bei der Einführung des R/3-Systems einen vorkonfigu-
rierten Mandanten verwendet, installiert man diesen vor Beginn der Konfigura-
tion der Grundeinstellungen und der Unternehmensstruktur.
Dabei ist folgender Ablauf empfehlenswert:
A Zusammenarbeit mit dem technischen Geschäftsprozessteam.
Hier wird die Zeit und das Datum für das Laden des vorkonfigurierten Man-
danten festgelegt.
B Zusammenarbeit mit dem Geschäftsprozessteam.
Überprüfung bei den Projektteams, ob die vordefinierten Einstellungen für
die Systemeinführung nützlich sind. Weitere Informationen über den vor-
konfigurierten Mandanten findet man in diesem Kontext im Knowledge Cor-
ner des ASAP-Tools. Die Erfahrungen vieler R/3-Kunden zeigt, dass durch
den Einsatz des vorkonfigurierten ASAP-Mandanten 4 bis 6 Wochen Einfüh-
rungszeit eingespart werden.
Die Installationsdauer für den vorkonfigurierten ASAP-Mandanten beträgt
ungefähr drei Stunden. Dies sollte bedacht werden, bevor man sich entschei-
det den vorkonfigurierten ASAP-Mandanten zu verwenden oder nicht.
C Installation des vordefinierten ASAP-Mandanten
Siehe Vorkonfigurierte Mandanten im Knowledge Corner, um den vorkonfi-
gurierten Mandanten zu installieren und diesbezügliche Informationen zu
erhalten.
D Werkzeuge
◗ Vordefinierter ASAP-Mandant
E Rollen
◗ Geschäftsprozessteamleitung
◗ Technischer Teamleiter
102
Sandini Bib
Da aber auch der ASAP-Ansatz, wie bereits erwähnt, auf dem wasserfall-basier-
ten Ansatz beruht und folglich mit den typischen Problemen dieser Methode zu
kämpfen hat, wird im Folgenden ein alternatives, dynamisches Vorgehensmo-
dell vorgestellt, bei dem CATT als ein unverzichtbares Werkzeug für Durchfüh-
rung von SAP R/3-Projekten verstanden wird.
4.3 Das DSDM-basierte Vorgehensmodell

Das DSDM-basierte Vorgehensmodell [Geiß98] ist ein dynamisches Vorgehens-
modell zur Durchführung von SAP R/3-Projekten. Dieses Vorgehensmodell ist
zur Zeit das Einzige, welches CATT als integralen Bestandteil seiner selbst ver-
steht, was uns Anlass genug gibt, dieses Modell im Folgenden genauer zu be-
trachten, wobei zunächst kurz auf die Herkunft bzw. die Entstehung des
DSDM-basierten Vorgehensmodells eingegangen wird, bevor nachfolgend die
einzelnen Aktivitäten sowie die Einbettung des CATTs in das Modell beschrie-
ben und abschließend noch einmal die Möglichkeiten und Vorteile zusammen-
gefasst werden, die sich aus dem CATT-Einsatz ergeben.
DSDM steht für »Dynamic Systems Development Method« und beschreibt ur-
sprünglich ein Vorgehensmodell für die Softwareentwicklung, welches insbe-
sondere für RAD(Rapid Application Development)-Projekte eingesetzt wird,
also für Projekte, die sehr engen Zeitvorgaben unterworfen sind. Diese Methode
wurde 1995 vom gleichnamigen DSDM-Konsortium entwickelt und beruht auf

den Erfahrungen der einzelnen, mittlerweile über 1000 Mitglieder eben dieses
Konsortiums. Aufgrund dieser großen Mitgliederzahl kann durchaus gesagt
werden, dass DSDM zum de facto Standard für Großbritannien geworden ist.
DSDM wird aber nicht nur in Großbritannien angewendet. Diese Methode fin-
det international eine immer größere Verbreitung und ist mittlerweile in Län-
dern wie z.B. USA, Frankreich, Benelux, Indien und anderen anzutreffen.
Von zentraler Bedeutung für den Erfolg der Methode ist einerseits die Tatsache,
dass DSDM die Dynamik der Anforderungen berücksichtigt, die Entwicklungs-
zeit verkürzt bzw. einen schnelleren Produktivstart gewährleistet und anderer-
seits die besondere Berücksichtigung, d.h., die Partizipation der Endbenutzer,
die Verwendung von Prototyping sowie die Beschreibung eines iterativen und
schrittweise erweiternden Ansatzes. Außerdem wird eine Vielzahl von phasen-
übergreifenden Aktivitäten beschrieben (siehe Abbildung 4.3).
103
Sandini Bib
Machbarkeit
Geschäftsstudie
Funktionale
Iteration
Design &
Build Iteration
Projektmanagement
Teamstrukturen
Benutzerbeteiligung
Fähigkeiten und Verantwortung
Schätzen
Risikoanalyse
Änderungskontrolle
Konfigurationsmangement
Entwicklungsumgebung
Methoden
Testen
regelmäßige Auslieferung
Abbildung 4.3
Das DSDM-Vorgehensmodell zur Softwareentwicklung
Außerdem basiert DSDM auf den folgenden Annahmen:

◗ Kein System wird direkt beim ersten Versuch perfekt entwickelt.
◗ 80% der perfekten Lösung können in 20% der Zeit erreicht werden, die zur
perfekten Lösung benötigt worden wäre.
104
Sandini Bib
◗ Endbenutzer sind nicht in der Lage, ihre weit in der Zukunft liegenden An-
forderungen bereits zum Zeitpunkt der Anforderungserhebung vorherzuse-
hen (erste Phase im Sinne traditioneller Modelle). In diesem Zusammenhang
wird ohnehin davon ausgegangen, dass die meisten Anforderungen dem Be-
nutzer erst bei der Nutzung des zu entwickelnden Systems klar werden.
DSDM geht des Weiteren davon aus, dass die aktuelle Phase nicht wie im tradi-
tionellen Wasserfallmodell vollständig abgeschlossen sein muss, sondern nur
soweit fortgeschritten sein sollte, dass gerade die nächste Phase begonnen wer-
den kann, in welcher dann die vorhergehende beendet wird.
Dabei stellt DSDM neun Prinzipien in den Mittelpunkt:
◗ Partizipation der Endbenutzer ist ein Muss.
◗ DSDM-Teams müssen bevollmächtigt werden, im Rahmen der System-
entwicklung Entscheidungen zu treffen.
◗ Das auszuliefernde Produkt steht im Mittelpunkt, nicht die Aktivitäten zur
Entwicklung des Produktes.
◗ »Fitness for business purpose« ist das wesentliche Akzeptanzkriterium, d.h.,
der Geschäftsnutzen steht im Mittelpunkt.
◗ Iterative und inkrementierende Entwicklung ist notwendig.
◗ Alle Änderungen während der Entwicklung sind reversibel.
◗ Anforderungen werden nur grob beschrieben.

◗ Testen ist keine eigene Phase, sondern findet während des gesamten Lebens-
zyklus statt.
◗ Kollaboration und Kooperation aller Beteiligten sind unverzichtbar.
Der Schritt von einer Methode der Softwareentwicklung hin zu einem Vorge-
hensmodell zur Durchführung von SAP R/3-Projekten wurde 1997 vollzogen,
als Marcus Geiß und Dr. Roland Soltysiak DSDM im Rahmen eines SAP R/3-
Projektes bei der Henkel KGaA in Düsseldorf an die Besonderheiten von R/3-
Projekten anpassten. Bei der Realisierung dieses DSDM-Projektes bei der Hen-
kel KgaA lieferte Gerhard Oberniedermaier, Berater der ICM-Unternehmensbe-
ratung GmbH, umfassend das erforderliche, bis dahin bei der Henkel KGaA
dort noch nicht vorhandene Know-how zur Verwendung von CATT, zum Te-
sten von Geschäftsprozessen verschiedenster Art und zur Planung und Durch-
führung von Tests mittels CATT und der Testworkbench.
Es soll bereits an dieser Stelle ausdrücklich darauf hingewiesen werden, daß das
DSDM-basierte Vorgehensmodell nicht im Widerspruch zum traditionellen
SAP-Vorgehensmodell oder zu ASAP steht, sondern vielmehr dazu rät, die sehr
ausführlichen Aktivitätenbeschreibungen, Dokumentvorlagen und Werkzeuge
dieser Modelle, wann immer es als sinnvoll erscheint, ausgiebig zu nutzen, da
DSDM nicht darauf abzielt, diese Phasenaktivitäten erneut zu erfinden, sondern
105
Sandini Bib
die Ansatzpunkte für Verbesserungen am Vorgehensmodell selbst sucht, und

nicht an den einzelnen Phasenaktivitäten oder den Beschleunigern und Werk-
zeugen von ASAP.
Anlaß zur Entwicklung eines neuen Vorgehensmodells zur R/3-Einführung
war die Forderung nach einem zeitgemäßeren Ansatz, welcher nicht nur die
einzelnen Phasenaktivitäten beschreibt, sondern darüber hinaus auf die Aufga-
ben- und Problemstellungen eingeht, mit denen SAP R/3-Projekte immer wie-
der zu kämpfen haben. Diese Kritikpunkte können im Wesentlichen wie folgt
zusammengefasst werden:
◗ Die Dynamik der Anforderungen wird nicht berücksichtigt.
◗ Die Produktivsetzung erfolgt zu spät.
◗ Prototyping und iteratives Vorgehen werden vernachlässigt.
◗ Es wird nicht darauf eingegangen, wie Teams parallel zusammen arbeiten
können.
◗ Es wird nicht darauf eingegangen, wie getestet werden soll.
◗ Die phasenübergreifenden Aktivitäten werden vernachlässigt.
◗ Der Know-how Transfer wird nicht unterstützt.
Die Dynamik der Anforderungen wird nicht berücksichtigt

Das Problem, dass die Dynamik der Anforderungen nicht berücksichtigt wird,
resultiert zum größten Teil aus der Tatsache, dass das traditionelle SAP-Vorge-
hensmodell und ASAP wasserfallbasierte Ansätze sind. Wasserfallbasiert be-
deutet dabei, dass die einzelnen Phasen des Einführungsprojektes in einer
streng vorgegebenen Reihenfolge hintereinander ausgeführt werden. Die erste
Phase dient in diesem Zusammenhang in aller Regel der Analyse der Anforde-
rungen, welche dann erst zum Ende des Projektes realisiert werden. Wenn man
des Weiteren berücksichtigt, dass Einführungsprojekte bis zu einem Jahr, oder
je nach Größe des Projektes sogar noch länger dauern, so wird deutlich, dass die
vor langer Zeit formulierten Anforderungen aufgrund ihrer Dynamik (Ände-
rungen in den Geschäftsprozessen, Gesetzesänderungen, Methodenwandel
oder gar eine Währungsumstellung usw.) nicht mehr viel mit den heutigen An-
forderungen gemein haben. So kann sogar ein System, dass sehr schnell nach
den niedergeschriebenen Anforderungen implementiert wurde, nicht mehr den
Bedürfnissen zum Zeitpunkt der Implementierung genügen. Diese Problematik
wird besonders deutlich, wenn man den Ansatz eines sogenannten Big-Bangs
wählt, bei dem in aller Regel zunächst alle Geschäftsprozesse bis ins kleinste De-
tail beschrieben werden (in Negativbeispielen wird allein auf diese Aktivität ein
Jahr und mehr verwendet!), bevor das eigentliche Einführungsprojekt gestartet
wird. Es galt also, diese Problematik im DSDM-basierten Vorgehensmodell zu
berücksichtigen, d.h., den wasserfall-basierten Ansatz zu überwinden und ei-
106
Sandini Bib
nen dynamischen Ansatz zu wählen, der sich verändernde Anforderungen

während des Projektes berücksichtigt.
Die Produktivsetzung erfolgt zu spät

Die zu späte Produktivsetzung, die zu berechtigter Kritik Anlass gibt, begrün-
det sich einerseits darin, dass die Projekte selbst schon sehr viel Zeit in An-
spruch nehmen und sie andererseits zumeist so geplant werden, dass alle Ge-
schäftsprozesse innerhalb eines einzigen Projektes eingeführt werden. Dieses
Vorgehen ist auch gleichzeitig das Einzige, das vom traditionellen SAP-Vorge-
hensmodell und von ASAP unterstützt wird, die beide nicht davon ausgehen,
dass das Modell mehrere Mal durchlaufen werden sollte. Hier verfolgt DSDM
einen völlig anderen Ansatz, der besagt, dass im ersten Projekt gerade nicht alle
Geschäftsprozesse, sondern nur die wichtigsten (gemessen an der Wichtigkeit für
den Geschäftsnutzen) eingeführt werden sollten. Der erste Durchlauf durch das
Modell zielt darauf ab, eine ca. 80%-Lösung produktiv zu setzen, bevor später in
einem zweiten Durchlauf die speziellen Funktionen, also die restlichen 20%,
eingeführt werden. Diese Funktionen werden entweder sehr wenig bis gar nicht
genutzt oder sind für den Geschäftsnutzen relativ unbedeutend. Das DSDM-ba-
sierte Vorgehensmodell soll also dazu beitragen, dass das SAP R/3-System
schneller produktiv gesetzt werden kann und folglich schneller zum Unterneh-
menserfolg beiträgt.
Prototyping und iteratives Vorgehen werden vernachlässigt

Prototyping und iteratives Vorgehen sind zwei Charakteristika, die in wohl je-
dem SAP R/3-Projekt anzutreffen sind und die in aller Regel auch gewünscht
werden. Auch hier sieht man sich beim traditionellen SAP-Vorgehensmodell
bzw. ASAP wieder mit dem Problem konfrontiert, dass diese Methoden zwar
von jedermann angewendet werden, doch von diesen traditionellen Modellen
nicht berücksichtigt werden. Dies wiegt umso schwerer, wenn man bedenkt,
dass das Prototyping mit seiner Benutzerbeteiligung in der Fachliteratur sehr
umstritten ist und bei einem unbedarften Vorgehen zu Recht als sehr fehleran-
fällig angesehen wird.
Ziel des DSDM-basierten Vorgehensmodells muss es also sein, ein Prototyping-
Management zu etablieren, welches dafür Sorge zu tragen hat, dass das Proto-
typing in einer geplanten und kontrollierbaren Art und Weise durchgeführt
wird. Gleiches gilt für das iterative Vorgehen, welches auch in allen Projekten
unerlässlich ist, da nicht davon ausgegangen werden kann, dass alle Geschäfts-
prozesse direkt im ersten Versuch gemäß den Anforderungen implementiert
werden. Vom Vorgehensmodell muss also überdies verlangt werden, dass auch
die Iterationen kontrolliert durchgeführt werden können.
107
Sandini Bib
Es wird nicht darauf eingegangen, wie Teams parallel zusammen

arbeiten können
Typisch für SAP R/3-Projekte ist es auch, dass zumeist mehrere Teams parallel
an der Projektarbeit beteiligt sind. Hieraus ergibt sich zunächst die Schwierig-
keit, dass in der Regel mehrere Teams beispielsweise mit den gleichen Customi-
zing-Einstellungen arbeiten müssen, wobei diesem Problem noch relativ einfach
begegnet werden kann. Schwieriger gestaltet sich hingegen die Aufgabe, die Er-
gebnisse der einzelnen Teams zusammenzuführen und zu überprüfen, ob all
das, was in jedem einzelnen Team unabhängig funktioniert, auch gemeinsam,
d.h. integriert, so abläuft, wie dies erwartet wird. Auch die Problematik der par-
allel arbeitenden Teams spielt weder beim traditionellen SAP-Vorgehensmodell
noch bei ASAP eine Rolle. Ziel für das DSDM-basierte Vorgehensmodell muss
also eine Beschreibung sein, wie die Ergebnisse der verschiedenen Teams zu-
sammengeführt werden können und wie der Testaufwand, der sich ggf. bei An-
passungen dieser Ergebnisse ergibt, auf ein Minimum reduziert werden kann.
Es wird nicht darauf eingegangen, »wie« getestet werden soll

Zwar werden sowohl im traditionellen Vorgehensmodell als auch bei ASAP
ausführliche Anleitungen gegeben, was getestet werden sollte und mit welcher
Tool-Unterstützung die Dokumentation dieser Tests durchgeführt werden soll-
te, doch fehlt jeglicher Hinweis darauf, welcher Tool-Unterstützung man sich
bedienen kann. Hieraus folgt, dass natürlich auch nicht darauf eingegangen
werden kann, wie dieses Tool einzusetzen ist und welche Möglichkeiten es bie-
tet. Des Weiteren bleibt unerwähnt, wie die Tests organisiert werden können. So
ist es für das neue Vorgehensmodell von besonderer Bedeutung, zu zeigen, wie
das CATT und die Testworkbench innerhalb des Einführungsprojektes einge-
setzt werden können.
Die phasenübergreifenden Aktivitäten werden vernachlässigt

Ein weiterer Nachteil, der immer wieder an den SAP-Vorgehensmodellen bemän-
gelt wird, ist die Vernachlässigung bzw. das Fehlen von phasenübergreifenden
Aktivitäten. Während im traditionellen SAP-Vorgehensmodell als phasenüber-
greifende Aktivitäten lediglich die Projektadministration und das Projektcon-
trolling sowie die Systemwartung und der Release-Wechsel beschrieben werden,
wird in der Roadmap, dem ASAP-Vorgehensmodell, ganz auf die Beschreibung
solcher Aktivitäten verzichtet. Aber gerade das Projektmanagement, das Prototy-
pingmanagement, das Qualitätsmanagement, das Testmanagement oder das
Konfigurationsmanagement spielen gerade in SAP-Projekten eine wichtige Rolle,
so dass eine Beschreibung dieser phasenübergreifenden Aktivitäten zunächst
wünschenswert wäre. Das DSDM-basierte Vorgehensmodell soll sich also auch
mit diesen Themen auseinandersetzen, wobei im Kontext dieses Buches der
Schwerpunkt selbstverständlich auf das Testmanagement gelegt werden soll.
108
Sandini Bib
Der Know-how Transfer wird nicht unterstützt

Bei SAP-Projekten handelt es sich in der Regel um sehr große und sehr komple-
xe Projekte, die darüber hinaus sehr viel Zeit in Anspruch nehmen (siehe oben).
Ausserdem bedarf es eines enormen SAP Know-hows, welches jedoch im Allge-
meinen nicht in ausreichendem Maße beim einführenden Unternehmen vor-
handen ist, so dass die Notwendigkeit besteht, externe Berater hinzuzuziehen.
Woran es dann aber häufig mangelt, sind geeignete Konzepte, wie das Berater-
wissen während der Projektarbeit an die internen Mitarbeiter weitergegeben
werden kann. Für gewöhnlich sieht der Know-how-Transfer nämlich lediglich
so aus, dass die Unternehmensberatung am Ende bis Detail weiß, wie das ein-
führende Unternehmen arbeitet und wie die einzelnen Geschäftsprozesse funk-
tionieren, dass einführende Unternehmen jedoch zu wenig über SAP gelernt
hat, um nachfolgende Projekte oder ggf. auch nur einzelne, kleine Veränderun-
gen oder Anpassungen selbständig durchführen zu können. Es begibt sich also
in eine Abhängigkeit von der beauftragten Unternehmensberatung, von der es
sich nur sehr schwer freimachen kann, weil jedes neu beauftragte Beratungs-
haus zunächst wieder alles über das Unternehmen lernen müsste, was sehr zeit-
und somit auch sehr kostenaufwendig ist. Es sollte also bereits im Laufe des Pro-
jektes darauf geachtet werden, dass die internen Mitarbeiter befähigt werden,
Probleme eigenständig zu lösen. Es gilt also, Möglichkeiten zu finden, wie der
Know-how-Transfer unterstützt werden kann, und zwar der von der Unterneh-
mensberatung hin zum einführenden Unternehmen.

4.3.1 Der Aufbau des DSDM-basierten Vorgehensmodells
In diesem Kapitel wird nun das DSDM-basierte Vorgehensmodell zur Durch-
führung von SAP R/3-Projekten in seinen Grundzügen vorgestellt. Alle folgen-
den Ausführungen beziehen sich auf das Buch »SAP R/3 dynamisch einführen
– Das DSDM-basierte Vorgehensmodell zur Durchführung von SAP R/3-Pro-
jekten« von Marcus Geiß und Roland Soltysiak [Geiß98]. Dem begierigen Leser,
der sich für weiterführende Informationen zum DSDM-basierten Vorgehens-
modell interessiert, sei eben dieses Buch empfohlen, in dem die einzelnen Pha-
senaktivitäten und phasenübergreifenden Aktivitäten detailliert beschrieben
und in einer Fallstudie verdeutlicht werden.
Das DSDM-basierte Vorgehensmodell beschreibt einen neuen Weg der SAP R/3-
Einführung, indem ein dynamischer, iterativer und schrittweise erweiternder
Ansatz gewählt wird, bei dem die Geschäftsprozesse gemäß ihrer Wichtigkeit
von parallel arbeitenden Teams unter Zuhilfenahme von Prototyping und Ein-
satz des CATT eingeführt werden.
109
Sandini Bib
Machbarkeitsstudie
(Vorstudie)
Einführung/
Geschäftsstudie
Produktivbetrieb
Geschäfts-
prozeßanalyse MM System-Design
Funktionen- und System-Build
modell- SD Iteration
Iteration Integrations-, Versions-,
Release- und Performanz-
Customizing CO Abgleich
CATTs
= iterative Phase
= Soll-Richtung
= Kann-Richtung
Abbildung 4.4
Das DSDM-basierte Vorgehensmodell zur Durchführung von SAP R/3-Projekten
Von besonderer Wichtigkeit für diesen Ansatz ist die Tatsache, dass das DSDM-
basierte Vorgehensmodell die typischen SAP-Phasenaktivitäten wie beispiels-
weise »Systemlandschaft einrichten« oder »Globale Einstellungen vornehmen«
selbstverständlich nicht neu erfindet, sondern auf die vollständigen und sehr de-
taillierten Aktivitätenbeschreibungen aus dem traditionellen SAP-Vorgehens-
modell bzw. aus ASAP zurückgreift. Auch der Einsatz der ASAP-Werkzeuge
und der ASAP-Beschleuniger wie beispielsweise Checklisten oder Dokument-
vorlagen wird, wann immer es sinnvoll erscheint, ausdrücklich gewünscht. Was
das Vorgehen selbst angeht, so soll alles was über die Aktivitätenbeschreibungen
hinausgeht auf DSDM-Basis durchgeführt werden. Die effektivste Projektdurch-
110
Sandini Bib
führung ist also genau dann möglich, wenn das Projekt auf der Grundlage des
DSDM-basierten Vorgehensmodells »powered by« ASAP organisiert wird.
Das DSDM-basierte Vorgehensmodell selbst besteht aus 5 Phasen und ist in
Abbildung 4.4 dargestellt.
Alle diese Phasen haben ihre DSDM-Besonderheiten, auf die im Folgenden kurz
eingegangen werden soll.
Phase 1: Die Machbarkeitsstudie/Vorstudie

Im Unterschied zu den bekannten SAP-Vorgehensmodellen stellt die Machbar-
keitsstudie/Vorstudie eine Phase dar, die dem eigentlichen Projekt vorange-
stellt wird. Diese Phase dient zunächst der Überprüfung, ob das SAP R/3-Sys-
tem überhaupt geeignet ist, die unternehmensindividuellen Anforderungen zu
erfüllen. Wurde die Entscheidung getroffen, das SAP R/3-System einzuführen,
so steht als nächstes die Auswahl der Module an, die im ersten DSDM-Durch-
lauf, also dem ersten Teilprojekt, eingeführt werden sollen. Außerdem wird
eine Einführungsstrategie festgelegt, und es werden Unternehmensziele defi-
niert. Abgeschlossen wird diese Phase mit einem Machbarkeitsbericht, in dem
die Ergebnisse dieser Phase festgehalten werden.
Die Phase der Machbarkeitsstudie/Vorstudie wird nur einmal, d.h., vor dem
ersten DSDM-Durchlauf durchgeführt (siehe Abbildung 4.4). Vor jedem weite-
ren Durchlauf wird auf sie verzichtet, da die generelle Entscheidung für das

SAP R/3-System ja bereits getroffen wurde und die Planung der nächsten
DSDM-Durchläufe jeweils als Aktivität am Ende der fünften Phase eingeplant
ist.
Phase 2: Die Geschäftsstudie

(Die traditionellen Aktivitäten, die zur Durchführung von SAP R/3-Projekten benötigt
werden, werden gemäß dem traditionellen SAP-Vorgehensmodell bzw. gemäß ASAP
durchgeführt!)
In der Geschäftsstudie werden im Gegensatz zu den traditionellen Vorgehens-
modellen drei DSDM-charakteristische Aktivitäten durchgeführt:
A Die abzubildenden Geschäftsprozesse werden grob identifiziert.
B Die Geschäftsprozesse werden priorisiert, und eine grobe Zeitplanung wird
aufgestellt.
C Es wird ein Abstimmungsworkshop durchgeführt.
Zu 1: Der wichtigste Begriff in dieser Aktivitätenbezeichnung ist der Begriff
»grob«. Im Gegensatz zum traditionellen Vorgehen werden die einzelnen Ge-
schäftsprozesse zu diesem Zeitpunkt, also zu Beginn des eigentlichen Einfüh-
rungsprojektes, noch nicht detailliert analysiert und beschrieben, sondern ledig-
lich grob erfasst, d.h., es werden die einzuführenden Geschäftsprozesse grob
111
Sandini Bib
identifiziert. Diese grobe Geschäftsprozessidentifikation kommt hierbei einer

Auffindung von Geschäftsprozessüberschriften gleich, die einerseits dazu
dient, abschätzen zu können, wie groß der Zeitaufwand ungefähr ausfallen
wird, und andererseits, um eine Grundlage zu schaffen, auf der im folgenden
die Priorisierung der Geschäftsprozesse aufbauen soll. Abschließend werden
den einzelnen Geschäftsprozessen verantwortliche Personen bzw. verantwort-
liche Teams zugeordnet.
Zu 2: Die Priorisierung stellt für die Projektdurchführung gemäß dem DSDM-
basierten Vorgehensmodell ein ganz wesentliches Element dar. Sie trägt dafür
Sorge, dass die einzelnen Teams die Geschäftsprozesse nicht ihren persönlichen
Vorlieben gemäß oder einfach »irgendwie« durchführen, sondern in einer Rei-
henfolge, die sich an der Bedeutung der einzelnen Geschäftsprozesse gemessen
an ihrer Wichtigkeit für den Geschäftsnutzen orientiert. Die Priorisierung wird
in Workshops durchgeführt, an denen das jeweils verantwortliche Team und
ein interner Mitarbeiter teilnehmen, der im Idealfall einen Überblick über alle
im Workshop zu behandelnden Geschäftsprozesse hat. Im Workshop selbst
werden den Beteiligten dann die Geschäftsprozesse (d.h. die Überschriften)
vorgelegt und in gemeinsamer Abstimmung gemäß einer Priorisierungsregel in
eine Reihenfolge gebracht. Wie diese Priorisierung funktioniert, wird weiter un-
ten bei den phasenübergreifenden Aktivitäten beschrieben. Die so entstandene
priorisierte Geschäftsprozessliste ist verbindlich und bestimmt über die Reihen-
folge der späteren Bearbeitung. Die Liste kann nur verändert werden, wenn sich
im Laufe des Projektes veränderte Anforderungen ergeben oder sich im Rah-
men des Abstimmungsworkshops die Notwendigkeit ergibt, die Prioritätenliste
zu verändern.
Die Veränderung der Anforderung innerhalb des Projektes kann drei verschie-
dene Ursachen haben:
◗ Es entstehen neue Anforderungen.
◗ Bekannte Anforderungen verändern sich.
◗ Die Wichtigkeit bestehender Anforderungen verändert sich.
Tritt einer dieser Fälle ein, so muss sowohl in Abstimmung mit dem gesamten
Team als auch teamübergreifend eine Neueinordnung in die Prioritätenliste er-
folgen.
Die Prioritätenliste ist auch ausschlaggebend für die Zeitplanung des weiteren
Projektes, da im DSDM-basierten Vorgehensmodell darauf abgezielt wird, im
ersten DSDM-Durchlauf eine ca. 80 Prozent-Lösung einzuführen. Die Zeitpla-
nung erfolgt also auf der Basis der wichtigsten 80 Prozent der einzuführenden
Geschäftsprozesse.
Zu 3: Der Abstimmungsworkshop ist eine sehr wichtige Aktivität, die bereits
sehr frühzeitig durchzuführen ist, also unmittelbar nachdem bekannt ist, wel-
che Geschäftsprozesse einzuführen sind. In diesem Abstimmungsworkshop
112
Sandini Bib
sollen alle die Fragen geklärt werden, die in Zusammenhang mit der teamüber-
greifenden Arbeit stehen. Beispielhaft sollen hier die folgenden Fragen genannt
werden:
◗ Ist die Zeitplanung der einzelnen Teams in Einklang zu bringen?
◗ Welche Customizing-Einstellungen werden von mehreren Teams angefasst?
◗ Sind alle Teams mit der Priorisierung innerhalb der anderen Teams einver-
standen?
◗ Werden die Verantwortlichkeiten für die einzelnen Geschäftsprozesse von
allen Teams akzeptiert?
Von besonderer Bedeutung für diese Aktivität ist hier die Erfahrung der Berater,
die in der Lage sind, sowohl geeignete Schätzungen für die Zeitplanung abzu-
geben als auch darüber zu informieren, an welchen Stellen, die verschiedenen
Teams auf die gleichen Customizing-Einstellungen zugreifen müssen. Eine
Kenntnis dieser Gegebenheiten kann im weiteren Verlauf des Projektes sehr
hilfreich sein und unangenehme Überraschungen vermeiden helfen
Weitere Aktivitäten, die in dieser Phase durchzuführen sind, sind einerseits die
SAP-Schulung, in der den internen Teammitglieder die R/3-Grundlagen und,
falls vorhanden, den internen Customizing-Beauftragten das nötige Customi-
zing Know-how vermittelt wird, und andererseits die DSDM-Schulungen.
Phase 3: Die Funktionenmodell-Iteration

(Die traditionellen Aktivitäten, die zur Durchführung von SAP R/3-Projekten
benötigt werden, werden gemäß dem traditionellen SAP-Vorgehensmodell
bzw. gemäß ASAP durchgeführt!)
Diese Phase stellt in Verbindung mit der vierten Phase das Kernstück des
DSDM-basierten Vorgehensmodells dar. Die Hauptaufgaben dieser Phase sind
die detaillierte Geschäftsprozessanalyse, die Geschäftsprozessbeschreibung,
das Customizing und die Erstellung des jeweiligen CATTs, wobei die Bearbei-
tung der einzelnen Geschäftsprozesse gemäß der in Phase zwei ermittelten Prio-
ritätenliste erfolgt. Im Gegensatz zu traditionellen Vorgehensmodellen erfolgt
die Analyse und das Customizing der einzelnen Geschäftsprozesse unmittelbar
nacheinander und gelten erst dann als abgeschlossen, wenn der zugehörige
Testlauf aufgezeichnet und die nötigen Testdaten ermittelt wurden. Diese Er-
weiterung ist sehr wichtig, da die Testfallaufzeichnung dafür sorgt, dass im Fol-
genden eine Menge an Doppelarbeit vermieden und somit das Projekt nicht nur
beschleunigt wird, sondern auch sehr einfach darüber Sicherheit gewonnen
werden kann, dass bei Änderungen am System die Geschäftsprozesse weiterhin
wie gewünscht funktionieren.
Am Anfang der dritten Phase steht jedoch die Timeboxplanung, in der festge-
legt wird, wie viele Geschäftsprozesse aus der Prioritätenliste von den einzelnen
113
Sandini Bib
Teams in der nächsten Timebox bearbeitet werden sollen. Eine Timebox stellt in
der Regel ein Zeitfenster von 10 Arbeitstagen, also zwei Kalenderwochen dar.
Am Ende einer jeden Timebox steht innerhalb der Teams ein kleiner Meilenstein
an, an dem überprüft wird, ob die gesetzten Ziele erreicht wurden bzw. ob die
Aufgabenplanung für die Timebox realistisch war. Wie eine solche Timeboxpla-
nung aussehen kann wird beispielhaft in Abbildung 4.5 dargestellt.
3 Wo. 11 Wo.
Phase 2 Timbox Phase 3 Phase 4
Projekt-
verlauf
TB1 TB2 TB3 TB4
Zeit
2 Wo. 2 Wo. 2 Wo. 2 Wo.

TB = Timebox
Abbildung 4.5
Timebox-Planung für die dritte Phase
Innerhalb dieser Timeboxes findet also die Bearbeitung der einzelnen Ge-
schäftsprozesse statt, wobei hier als Werkzeug auf jeden Fall zum Prototyping
geraten wird. Um dieses Prototyping durchzuführen, bieten sich mit dem Itera-
tiven Prozess-Prototyping (IPP) von Keller und Teufel [/Keller97/] und dem
DSDM-Prototyping-Management zwei Methoden an.
Das IPP nutzt hierbei die verschieden integrierten SAP-eigenen Werkzeuge, um
die Geschäftsprozesse in Workshops gemäß der Benutzeranforderungen einzu-
stellen. Die verschiedenen Hilfsmittel, die hierbei genutzt werden, sind:
◗ das R/3-Customizing
◗ das R/3-Prototyping
◗ das R/3-Data Dictionary
◗ das R/3-Referenzprozessmodell
◗ das R/3-Daten-/Objektmodell
◗ das R/3-Organisationsmodell
114
Sandini Bib
Wie das Netzwerk zwischen den einzelnen Komponenten des IPPs und die ver-
schieden möglichen Navigationswege aussehen, wird in Abbildung 4.6 darge-
stellt.
Bertriebnswirtschaftliche
R/3-
Organi-
sations-
R/3- modell R/3-
Referenz- Daten-/
prozeß- Objekt-
Ebene
modell Modell
IPP
R/3-
Systemtechnische
R/3-Data
Proto-
Dictionary
typing
R/3-
Custo-
mizing
Ebene

Abbildung 4.6
Navigationswege im IPP [s. /Keller97/ 198]
Das IPP schlägt also offensichtlich nicht die Nutzung von CATT vor. Wenn das
Projekt jedoch auf der Basis des DSDM-basierten Vorgehensmodells durchge-
führt werden soll, ist die Erstellung der CATTs unumgänglich, so dass auch bei
Nutzung des IPPs an die Bearbeitung eines jeden Geschäftsprozesses die Auf-
zeichnung des zugehörigen CATTs angehängt werden muss, was dem Gedan-
ken des IPPs, die SAP-eigenen Werkzeuge zu nutzen, sicherlich nicht entgegen-
steht.
115
Sandini Bib
Abbildung 4.7
Fragen im iterativen (DSDM-) Prototyping
Die zweite Möglichkeit, Prototyping einzusetzen, ist das iterative (DSDM-) Pro-
totyping, welches zwar nicht die Nutzung der SAP-eigenen Werkzeuge vor-
schreibt, jedoch vergleichbare Fragestellungen zu den einzelnen Prototypen
aufwirft, wie es im IPP der Fall ist. Darüber hinaus ist dieses iterative (DSDM-)
Prototyping in ein Prototypen-Management eingebettet, welches dafür Sorge
tragen soll, dass das Prototyping nicht zu einem ziel- und endlosen Prototyping
wird, sondern in steuerbarer Weise vor sich geht.
Wird das iterative (DSDM-)Prototyping angewendet, so werden in den einzel-
nen Teams R/3-Prototypen zu den einzelnen Geschäftsprozessen erarbeitet, für
welche dann in jeder Iteration die in Abbildung 4.7 dargestellten Fragestellun-
gen behandelt werden sollen. Der Fragenkatalog enthält folgende Fragen:
◗ Ist der Bildschirmaufbau übersichtlich?
◗ Sind alle nötigen Eingabefelder vorhanden?
◗ Ist die Eingabelogik eingängig?
◗ Sind die gewünschten Vorschlagswerte eingestellt?
◗ Sind die Reaktionszeiten OK?
◗ Sind die geäußerten Änderungswünsche durchführbar?
Wurde der Prototyp schließlich als funktionierendes Teil des Systems abgenom-
men, so muss selbstverständlich auch hier der entsprechende CATT-Ablauf auf-
116
Sandini Bib
gezeichnet werden. Im Sinne des Know-how-Transfers wird im Idealfall darauf

geachtet, dass sämtliche Customizing-Einstellungen von einem internen Team-
mitglied (unter Aufsicht des Beraters) vorgenommen werden, so dass die inter-
nen Mitarbeiter mit der Zeit in die Lage versetzt werden, zunächst kleine Auf-
gaben selbst zu übernehmen und später Änderungswünsche eigenständig im
Customizing einzustellen. Gleiches gilt für die CATT-Aktivitäten. Auch hier
sollen die internen Mitarbeiter darauf vorbereitet werden, dass sich nicht bis in
alle Ewigkeit externe Berater im Unternehmen aufhalten.
Das CATT wird im DSDM-basierten Vorgehensmodell aber auch über die ei-
gentlichen Testaufgaben hinaus genutzt. Beispielsweise kann das CATT auch
genutzt werden, um Altdaten zu übernehmen, um Stammdaten einzuspielen,
um Schulungsunterlagen oder auch die Anwenderdokumentation zu erstellen.
Am Ende einer jeden Timebox findet dann innerhalb der Teams eine Meilen-
steinsitzung statt, in der geklärt wird, ob und wie die Anforderungen der ver-
gangenen Timebox erfüllt werden konnten und wie die nächste Timebox ausse-
hen soll.
Phase 4: Die System-Design- und System-Build-Iteration

durchgeführt!)

Die vierte Phase kann bereits begonnen werden, ohne dass die dritte Phase voll-
ständig abgeschlossen wurde. Die wesentlichen Begriffe für diese Phase sind In-
tegrations-, Performanz- und Versionsabgleich, d.h., hier werden die Ergebnis-
se der dritten Phase überprüft. Aus dieser Phase wird dann so lange wieder in
die dritte Phase zurückgesprungen, bis das SAP R/3-System den Benutzeran-
forderungen entspricht. Dieses »Hin und Her-Springen« zwischen der dritten
und vierten Phase macht wiederum deutlich, welche Vorteile die aufgezeichne-
ten CATTs mit sich bringen. Sie ermöglichen es nämlich, nach jeder Änderung
am System wieder einen vollständigen Test aller Geschäftsprozesse durchzu-
führen und das bei minimalem Aufwand und der Gewissheit, dass das System
wie gewünscht funktioniert.
Diese vierte Phase wird des Weiteren bei einem Release-Wechsel genutzt, mit
dem früher oder später jedes System konfrontiert werden wird. Auch hier wer-
den bei den Regressionstests die aufgezeichneten CATTs verwendet, so dass es
zu enormen Zeit- und somit auch Kosteneinsparungen kommen kann.
Des Weiteren werden in dieser vierten Phase alle diejenigen Aktivitäten durch-
geführt, die im traditionellen SAP-Vorgehensmodell unter »Produktivsetzung
vorbereiten« und in ASAP unter »Produktionsvorbereitung« fallen.
117
Sandini Bib
Phase 5: Einführung/Produktivsetzung
durchgeführt!)
In dieser Phase wird der aktuelle DSDM-Durchlauf abgeschlossen und der Pro-
duktivbetrieb unterstützt.
Aus dem Produktivbetrieb werden sich ändernde bzw. neue Anforderungen
abgeleitet, und der nächste DSDM-Durchlauf wird geplant. Dies kann entweder
ein neues Teilprojekt darstellen oder, je nach Aufgabenstellung, auch einen
Rücksprung in eine vorherige Phase bedeuten. Kommt es beispielsweise zu Pro-
blemen funktionaler Art, so muss in die dritte Phase zurückgesprungen werden.
Treten hingegen Probleme nicht-funktionaler Art auf, wird die vierte Phase er-
neut durchlaufen.
Am Ende des ersten DSDM-Durchlaufs sollte idealerweise eine ca. 80 Prozent-
Lösung (Basissystem) stehen. Im zweiten Durchlauf (zweites Teilprojekt) wird
dann dieses Basissystem erweitert. Diese Erweiterung kann die verschiedensten
Gründe haben wie z.B.:
◗ neue Anforderungen
◗ veränderte Anforderungen
◗ Fehlerbeseitigung
Zu einem dritten Durchlauf käme es beispielweise bei einem Releasewechsel.
[s. /Geiß98/ 265ff.]
4.3.2 Die phasenübergreifenden Aktivitäten

Im DSDM-basierten Vorgehensmodell werden auch mehrere phasenübergrei-
fenden Aktivitäten beschrieben. Diese Aktivitäten stellen das Fundament für
die einzelnen Phasenaktivitäten dar und sind für eine erfolgreiche Projekt-
durchführung unverzichtbar.
Projektmanagement
Das Projektmanagement in DSDM-basierten Projekten sieht sich im Gegensatz
zu wasserfall-basierten Projekten sowohl mit neuen Aufgabenstellungen als
auch mit neuen Zielsetzungen konfrontiert. Gründe für diese Veränderungen
sind insbesondere das Timeboxing und das Prototyping.
Während der Projektmanager in traditionellen Projekten damit beschäftigt war,
die vorgegebenen Anforderungen unter Einhaltung der Zeitvorgaben zu erfül-
len, muss er heute dafür Sorge tragen, dass die Timebox mit möglichst vollstän-
diger Realisierung der Anforderungen eingehalten wird. Konnte man in tradi-
118
Sandini Bib
tionellen Projekten noch die Anforderungen als Konstante und die Zeit als
Variable verstehen, so müssen heute in einer fest vorgegebenen Timebox even-
tuell die Anforderungen gemäß der Prioritätenliste reduziert, also als Variablen
verstanden werden, die auf eine 80 Prozent-Lösung abzielen. Der Projektmana-
ger im DSDM-basierten Vorgehensmodell muss also insbesondere darum be-
müht sein, dass die Teams die Anforderungen entsprechend ihrer Wichtigkeit
bearbeiten, dass die einzelnen Teammitglieder effektiv zusammenarbeiten und
dass die Timeboxes realistisch geplant werden.
In DSDM-basierten Projekten stellt das iterative Prototyping eine der wesentli-
chen Aufgaben dar. Da dieses Prototyping nicht zuletzt aufgrund seiner Itera-
tionen mitunter sehr problematisch sein kann, bedarf es eines wirksamen Proto-
typing-Managements, welches dafür verantwortlich ist, dass sowohl das
Prototyping selbst als auch die Iterationen in einer kontrollierten und steuerba-
ren Weise funktionieren.
Das Prototyping hat in den unterschiedlichen Kontexten unterschiedliche Be-
deutungen. Prototyping in der Softwareentwicklung bedeutet z.B., dass es dem
Auftraggeber ermöglicht wird, seine Vorstellungen anhand eines ersten Abbil-
des des zu entwickelnden Systems zu präzisieren und eventuell zu korrigieren,
wobei dieses erste Abbild in der Regel verworfen, also nicht weiterentwickelt
wird.

Während Prototyping in SAP-Projekten ursprünglich lediglich dazu dient es
dem Anwender zu ermöglichen, sich die einzelnen Geschäftsprozesse im R/3-
System anzuschauen, wird Prototyping im DSDM-basierten Vorgehensmodell
als eine Technik verstanden, Anforderungen zu ermitteln bzw. zu verfeinern,
wobei die Entwicklung eines Teils des einzuführenden Systems darstellt, der
nicht weggeworfen wird, sondern iterativ weiterentwickelt wird.
Als Vorteile des iterativen Prototypings verspricht man sich u.a.:
◗ besser fundierte Anforderungen
◗ Vermeidung von Entwurfsfehlern durch frühzeitige Erprobung
◗ erhöhte Benutzerakzeptanz
◗ frühzeitige Benutzerausbildung
Um diese Vorteile realisieren zu können, muss jedoch ein wirksames Prototy-
ping-Management etabliert werden, dass dafür sorgt, dass nicht endlos hin
und her »geprototyped« wird, sondern dass die Iterationen begrenzt werden.
Wie das Prototyping-Management aussehen kann wird in Abbildung 4.8 dar-
gestellt. Für weitere Informationen zum Prototyping-Management wird auf
[/DSDM97/] verwiesen.
119
Sandini Bib
Anfänglicher Prototyp
Verfeinerter Prototyp
Konsolidierter Prototyp
Abbildung 4.8
Risikoanalyse
Die Risikoanalyse hat das Erkennen möglicher Projektrisiken zum Ziel und
muss während der gesamten Projektdauer immer wieder durchlaufen werden.
Der Fragenkatalog der Risikoanalyse muss also über alle Phasen hinweg immer
wieder beantwortet werden, und zwar sowohl in »kleinen« Meilensteinen in-
nerhalb der einzelnen Teams als auch in »großen« Meilensteinen an den jewei-
ligen Phasenenden. Es wird vorgeschlagen die folgenden Risiken zu überprü-
fen:
◗ Wurden den einzelnen Geschäftsprozessen eindeutig jeweils ein verantwort-
licher Mitarbeiter zugeordnet?
◗ Gefährdet die Zeitdauer, die für Entscheidungen benötigt wird, den Projekt-
plan?
◗ Werden die Benutzer ausreichend in das Projekt miteinbezogen?
◗ Entspricht der Detaillierungsgrad der Anforderungsanalyse der aktuellen
Phase?
120
Sandini Bib
◗ Werden die Geschäftsprozesse gemäß der Prioritätenliste bearbeitet?

◗ Bringen die realisierten Geschäftsprozesse den erwarteten Nutzen?
◗ Ist das Abnahmeverfahren eindeutig definiert?
◗ Sind die Iterationen unter Kontrolle?
◗ Konzentrieren sich die Teammitglieder mehr auf die einzelnen Aktivitäten
als auf das zu erreichende Ziel?
◗ Kann problemlos zu einem bekannten Entwicklungsstand zurückgekehrt
werden?
◗ Wird das Testen als integraler Bestandteil des Vorgehensmodells verstan-
den?
◗ Arbeiten alle Beteiligten kooperativ zusammen?
◗ Kennen alle Beteiligten die DSDM-Grundätze?
◗ Kennen die Entwickler das SAP R/3-System ausreichend?
◗ Ist die Veränderung der Organisation des Unternehmens, die die Einführung
des SAP R/3-Systems mit sich bringt, unter Kontrolle?
◗ Ist das Projektziel noch erreichbar?
Timeboxing und Priorisierung

Das Timeboxing dient der besseren Kontrolle des Projektmanagements, indem
kleine, überschaubare Zeitfenster mit klar definierten Anforderungen beschrie-
ben werden. Innerhalb der Timeboxes müssen die Teams die zu bearbeitenden
Aufgaben gemäß der Prioritätenliste bearbeiten.
Die Prioritätenliste erhält man, indem man die abzubildenden Geschäftsprozes-
se und -funktionen beispielweise mittels der MoSCoW-Rules in eine Reihenfol-
ge gemessen an ihrer Wichtigkeit für den Geschäftsnutzen bringt. Wie die MoS-
CoW-Rules funktionieren, wird in Abbildung 4.9 dargestellt.
121
Sandini Bib
Abbildung 4.9
Priorisierung mittels der MoSCoW-Rules
Die Einordnung in diese »Muss-«, »Soll-«, »Kann-« und »Wäre Schön-«Gruppen

erfolgt innerhalb der für den Geschäftsprozess verantwortlichen Teams. Diese
Priorisierung stellt dann auch die Grundlage für die Timeboxplanung dar.
Konfigurationsmanagement
Das Konfigurationsmanagement ist dafür verantwortlich, dass das DSDM-ba-
sierte Einführungsprojekt trotz aller Dynamik unter Kontrolle bleibt. Von be-
sonderer Bedeutung ist hierbei die Verwaltung der einzelnen Softwareelemente
hinsichtlich ihrer Veränderung bzw. der Aufzeichnung der verschiedenen Ver-
sionen, die diese Elemente durchlaufen. Softwareelemente im SAP R/3-System
können beispielsweise sein:
◗ Geschäftsprozessdokumentation
◗ Customizing-Einstellungen
◗ CATTs
◗ Schulungsunterlagen usw.
Um nun diese Softwareelemente mit einem geeigneten Konfigurationsmanage-
ment zu verwalten, bietet das SAP R/3-System mit
◗ dem Change und Transport Organizer,
◗ dem SAPoffice und
◗ dem Dokumentenverwaltungssystem
122
Sandini Bib
verschiedene integrierte Werkzeuge an, deren Nutzung es möglich macht, je-

derzeit zu einem bekannten Entwicklungszustand zurückzukehren.
Testen
Wie das Testen im DSDM-basierten Vorgehensmodell durchzuführen ist, wur-
de bereits ausführlich innerhalb der CATT-Einsatzmöglichkeiten beschrieben
und soll deshalb hier nicht weiter behandelt werden.
Um zu gewährleisten, dass ein DSDM-basiertes Projekt einen gängigen Quali-
tätsstandard erfüllt, soll an dieser Stelle auf die Ausführungen der British Stan-
dards Institution verwiesen werden, die in ihrer Veröffentlichung »The Dyna-
mic Systems Development Method & TickIT« ausführlich beschreibt, wie
DSDM-Projekte durchzuführen sind, um die Anforderungen der ISO 9000-3 zu
erfüllen.
Kommunikation
Die Kommunikation spielt gerade in DSDM-basierten Projekten eine sehr wich-
tige Rolle, da hier einer engen Zusammenarbeit von Endbenutzern und Beratern
für den Projekterfolg eine entscheidende Rolle zukommt.
Im DSDM-basierten Vorgehensmodel für SAP R/3-Projekte wird aus diesem

Grund nicht nur auf die Wichtigkeit dieser Kommunikation hingewiesen, son-
dern es werden zwei Kommunikationsmodelle vorgestellt, welche die Benut-
zer/Berater-Zusammenarbeit verbessern sollen:
◗ Contextual Inquiry
◗ Themenzentrierte Interaktion
Contextual Inquiry
Das Contextual Inquiry [Beyer98] beschreibt eine Art der Kundenbefragung, die
hauptsächlich bei der Geschäftsprozessanalyse eingesetzt wird. Im Mittelpunkt
dieser Methode steht die Annahme, dass der Kunde seine tägliche Arbeit we-
sentlich besser beschreiben kann, wenn er im Kontext seines gewöhnlichen Ar-
beitsumfelds befragt wird, also nicht wie bei traditionellen Befragungstechni-
ken in einem neutralen Besprechungsraum.
Grundlage für diese Befragung ist das so genannte »Meister/Lehrling-Modell«,
in welchem der Kunde der Meister ist, der seinem Lehrling, im vorliegendem
Fall dem SAP-Spezialisten, seine tägliche Arbeit so erklären soll, dass dieser in
die Lage versetzt wird, des Kunden Arbeit eigenständig durchzuführen, also
auch zu verstehen. Um dieses Ziel zu erreichen, werden vier Prinzipien formu-
123
Sandini Bib
liert (Kontext, Partnerschaft, Interpretation, Fokus), die sowohl ein zielgerichte-

tes Arbeiten als auch ein gemeinsames Verständnis ermöglichen.
Themenzentrierte Interaktion
Die Themenzentrierte Interaktion beschreibt eine Methode, die den Grundstein
für produktive Teamarbeit legt. Wichtig für diese Methode sind einerseits die
drei Faktoren
◗ Individuum,
◗ Team und
◗ Thema,
in welche die Teamarbeit eingebettet ist, und andererseits Postulate und Verhal-
tensregeln, die eine effiziente Kommunikation ermöglichen.
4.3.3 Zusammenfassung der CATT-Aktivitäten im

DSDM-basierten Vorgehensmodell
In der folgenden Übersicht soll nun noch einmal zusammenfassend dargestellt
werden, wie das CATT im DSDM-basierten Vorgehensmodell verwendet wer-
den kann, wobei zwischen den Aktivitäten unterschieden wird, für die das
CATT eigentlich entwickelt wurde (also Testaktivitäten), und Aktivitäten, bei
denen das CATT über seine eigentliche Funktionsweise hinaus angewendet
wird (sonstige Aktivitäten).
CATT-Testaktivtäten:
◗ Funktionstest
◗ Modultest
◗ Integrationstest
◗ Massentest
◗ Regressionstest
Sonstige CATT-Aktivitäten:
◗ Altdatenübernahme
◗ Einspielung von Stammdaten
◗ Erstellung von Schulungsunterlagen
◗ Erstellung von Anwenderdokumentation
124
Sandini Bib
4.3.4 Die Vorteile des DSDM-basierten

Vorgehensmodells
Aus dem beschriebenen Vorgehen ergibt sich eine Vielzahl von Vorteilen, die
wie folgt zusammengefasst werden können:
◗ Die Anforderungen werden erfüllt.
◗ Das Prototyping wird unterstützt.
◗ Der Forderung nach einem iterativen und inkrementellem Vorgehen wird
Rechnung getragen.
◗ CATT ist integrales Element des Vorgehensmodells.
◗ Release-Wechsel werden durch die Übernahme der CATTs vereinfacht.
◗ Das SAP R/3-System trägt schneller zum Unternehmenserfolg bei.
◗ Die Wartungsaktivitäten fallen geringer aus.
◗ Kosten- und Zeitvorgaben werden eingehalten.
◗ Beratungsunternehmen werden kontrollierbarer.
◗ Der Know-how-Transfer wird unterstützt.
◗ Der Schulungsaufwand verringert sich.

4.4 Fazit
Obwohl die SAP AG das Computer Aided Test Tool zum Testen ihrer eigenen
Software einsetzt, wird aber auf Kundenseite weder im traditionellen SAP-Vor-
gehensmodell noch in ASAP der Einsatz dieses Test-Werkzeuges empfohlen.
Eine Integration des CATTs in jedes der im gegenwärtigen Kapitel beschriebe-
nen Vorgehensmodelle bringt jedoch mehrere Vorteile mit sich, die in diesem
Kapitel ausführlich diskutiert wurden.
Um nun CATT innerhalb eines SAP R/3-Projektes einzusetzen, bieten sich zwei
Möglichkeiten an: Entweder werden die verschiedenen Phasenaktivitäten so-
wohl des traditionellen Vorgehensmodells als auch der ASAP-Einführungsme-
thodik in Anlehnung an die oben gemachten Ausführungen durchgeführt, oder
es wird auf das DSDM-basierte Vorgehensmodell in Kombination mit ASAP zu-
rückgegriffen.
Wie dabei im Einzelnen vorgegangen und in welchem Umfang CATT eingesetzt
wird, wird sicherlich von Projekt zu Projekt variieren. Festzuhalten bleibt je-
doch, dass das automatisierte Testen von Geschäftsprozessen ein in sehr hohem
Maße effizientes Testen von SAP R/3-Systemen ermöglicht.
125
Sandini Bib
Sandini Bib
Allgemeine Funktionen
von CATT
5
5.1 Einbindung von CATT in die Infrastruktur der
R/3-Umgebung
Die Infrastruktur der bereits kurz beschriebenen ABAP/4 Development Work-
bench ermöglicht es dem Benutzer von CATT, auf die verschiedenen Funktio-
nen wie Korrektur- und Transportwesen, Repository-Infosystem und Mehr-
sprachigkeit etc. zuzugreifen. Damit kann das CASE-Tool CATT sämtliche
Vorteile seiner Integration in die CASE-Umgebung ABAP/4 Development Work-
bench hervorragend nutzen. Darüber hinaus wird der korrekte Testablauf durch
synchrones Verbuchen mit gezieltem Tabellenpuffer-Refresh garantiert. Wich-
tig ist dies insbesondere bei komplexen Transaktionsketten bestehend aus
Transaktionen, die auf den Ergebnissen der vorher ausgeführten Transaktionen
aufbauen. Durch die Integration von CATT in die ABAP/4 Development Work-
bench ist auch das so genannte »Mastersprachenhandling« im R/3-System ein-
heitlich gestaltet. Wie andere ABAP/4-Development-Workbench-Objekte ha-
ben auch Testabläufe und Testbausteine in CATT eine Originalsprache. Legt
man in CATT ein Objekt an, so erhält es die jeweilige Anmeldesprache unter der
sich der Anwender im System angemeldet hat, im System SY-LANGU genannt,
die dann die Originalsprache ist. Sämtliche Texte zu einem Objekt sind immer
in dieser Originalsprache im System vorhanden. Beim Kopieren wird die Origi-
nalsprache des Objekts auch für das neue Objekt übernommen, da die Bearbei-
tung normalerweise in der Originalsprache des Objekts erfolgt. Unterscheidet
sich die Originalsprache des bearbeiteten Objekts jedoch von der Anmeldespra-
che, so kann man entweder die Bearbeitung in der Originalsprache durchführen
oder die Originalsprache ändern. Falls die Originalsprache geändert werden
soll, ist darauf achten, dass die Texte bereits in die neue Originalsprache über-
setzt vorliegen. Ist dies nicht für alle Texte der Fall, dann kann man die nicht
vorhandenen Texte zunächst in die neue Sprache übersetzen. Dies sollte
schnellstmöglich geschehen. Sämtliche Attribute und Objekte der angelegten
127
Sandini Bib
5.2 Remote Start
Testabläufe und Testbausteine werden im Repository-Infosystem verwaltet.

Dies ermöglicht eine gezielte Suche nach Bausteinen oder Abläufen, die be-
stimmte Kriterien erfüllen.
5.2 Remote Start

Mit CATT kann man verschiedenste Testszenarien aus einem zentralen R/3-Sy-
stem in einem anderen R/3- oder sogar auch R/2-Satellitensystem über einen
RFC ( Abkürzung für »Remote-Function-Call«) zu testen. Die RFC-Schnittstelle
ist ein Standardwerkzeug der ABAP/4-Development-Workbench. Diese
Schnittstelle ermöglicht es dem Anwender, Programme innerhalb eines Netz-
werkes aufzurufen, auf welchem Rechner sich das Programm auch immer be-
finden mag. Die R/3-Funktionsbibliothek stellt darüber hinaus einen RFC-Ge-
nerator zur Verfügung, mit dem man externe Programme erzeugen und auf das
jeweilige Frontend-System herunterladen kann. Für die Kommunikation mit ex-
ternen Programmen (C, C++ und Visual Basic) sind RFC-Entwicklungsbiblio-
theken für alle heutige gängigen Betriebssysteme (MS-WINDOWS, MS-WIN-
DOWS NT) und auch für alle vom R/3-System unterstützen UNIX-Plattformen
verfügbar. Man unterscheidet zwischen dem RFC-Client und einem RFC-Ser-
ver. Der RFC-Client ist eine Instanz, die eine Funktion remote aufruft. Der RFC-
Server stellt diese Funktion bereit und führt sie aus. Um sicherzustellen, dass die
einzelnen RFC-Funktionen im RFC-Server sicher und unabhängig von der Ver-
fügbarkeit des Servers ausgeführt werden, können die Aufrufe transaktional
durchgeführt werden. Hierbei werden die via RFC zu übertragenden Daten in
der Datenbank des R/3-Systems zwischengespeichert und als eine Einheit über-
tragen. Bei der Ausführung eines RFC-Aufrufs wird eine Reihe von Aufgaben
automatisch durchgeführt:
◗ Datenkonvertierung
◗ Anmeldung beim SAP-Partnersystem
◗ Umsetzung aller RFC-Datentypen
◗ Steuerung des Kommunikationsflusses
Für das R/2-System ist RFC als so genannte »Add-on-Komponente« verfügbar.
Hier wird der Testablauf in dem zentralen R/3-System gestartet und die Trans-
aktionen werden über die RFC-Schnittstelle in den Satellitensystemen gesteuert.
CATT-Abläufe können also entweder lokal in dem System ablaufen, das die
CATT-Daten selbst verwaltet, oder remote in einem zweiten System. So kann in
einer größeren Systemumgebung ein dezidiertes R/3-Testsystem für den Test
von Abläufen in allen R/2- und R/3-Umgebungen des Kunden eingesetzt wer-
den. Der Zugang zu einem Remote-System erfolgt immer über die SAP-Schnitt-
stelle RFC. Ein Remote-System wird durch die so genannte »RFC-Destination«
beschrieben. Diese enthält den Systemnamen, den Mandanten und den Benut-
zernamen, mit dem man in diesem System arbeitet. RFC-Destinationen kann
128
Sandini Bib
man im SAP-System mit der Transaktion »SM59« bearbeiten. Das Remote-Sys-

tem muss aber nicht unbedingt ein anderes System sein. Man kann auch einfach
nur mit einem anderen Mandanten im gleichen System arbeiten. Der SPA/
GPA-Parameter Id RFC entscheidet darüber, ob CATT lokal oder in einem Re-
mote-System gestartet wird. Ist dieser Parameter leer, wird CATT lokal gestar-
tet; enthält er eine gültige RFC-Destination, wird remote gestartet. Setzt man
diesen Parameter global, dann wird ihm bei jeder Anmeldung ein Wert zuge-
wiesen. Es besteht die Möglichkeit, den Parameter auch individuell beim Start
zu setzen; dann erhält er einen Wert, der ab dem Zeitpunkt für diese Anmel-
dung gültig ist. Beim direkten Start von CATT-Abläufen über den Funktions-
baustein CAT_START kann die RFC-Destination für den aktuellen Startvorgang
im Parameter RFCD übergeben werden.
Auswirkungen im Remote-Ablauf: Im Verwaltungssystem (System 1) erfolgt inner-
halb von Testabläufen oder Testbausteinen die Definition von CATT-Funktio-
nen. Im Ausführungssystem (System 2) werden Funktionsbausteine remote auf-
gerufen, die dort die lokale Ausführung der CATT-Funktionen veranlassen. Für
die in diesen CATT-Funktionen verwendeten Systemvariablen werden die Wer-
te aus dem Remote-System übernommen. Beispiele hierfür sind:
SY-MANDT = &MND
SY-LANGU = &SPR
SY-UNAME = &NAM
Außerdem erfolgt die Bearbeitung von Parametern mit CATT-Funktionen im
Remote-System, d.h., jeder Parameterwert wird aktuell aus dem Remote-Sys-
tem gelesen. Beim Setzen wird jeder Wert im Memory des Remote-Systems ab-
gelegt. Hinsichtlich dieser Ausführungen sei auf Kapitel 8 verwiesen. Dort wird
die Einrichtung sowohl der R/3 - R/2 - Verbindung als auch der R/3 - R/3 - Ver-
Kapitel 5 – Allgemeine Funktionen von CATT

bindung sowie das Anlegen von RFC-Destinationen detailliert veranschaulicht.
5.3 Berechtigungsprüfung
Berechtigungen im R/3-System sind sehr wichtig, um die Programme und Da-
ten unberechtigten Zugriffen von Dritten zu entziehen. Deshalb sollten sie in
den CATT-Entwicklungen unbedingt genutzt werden. Bei der Definition von
Berechtigungen bedient man sich des Berechtigungsobjekts. Eine Berechtigung
ist eine Ausprägung eines Berechtigungsobjektes. Diese Berechtigung enthält ei-
nen eigenen Namen und alle Felder des zugrundeliegenden Berechtigungsob-
jektes. Diesen Feldern können entsprechende Werte zugewiesen werden. Die
Berechtigungsprüfung erfolgt dann später gegen diese Werte.
Durch die geschilderte Integration des Computer Aided Test Tools in die
ABAP/4 Development Workbench wird bei der Ausführung von Testbaustei-
nen und Testabläufen stets automatisch überprüft, ob der Anwender im Rah-
129
Sandini Bib
5.3 Berechtigungsprüfung
men seines Berechtigungsprofils überhaupt über eine Berechtigung zur Ver-

wendung des CATTs verfügt.
CATT beinhaltet ein Autorisationskonzept, welches die Möglichkeit bietet, ge-
nau zu definieren, welcher spezifische Benutzer berechtigt sein soll, Testbaustei-
ne und Testabläufe zu erstellen, zu ändern, anzuzeigen, zu starten und zu ver-
walten. Darüber hinaus werden alle Berechtigungsprüfungen der zu testenden
Transaktion durchgeführt. Im CATT wird die Berechtigung mit einem Objekt,
hier ABAP/4-Development-Workbench (S_DEVE-LOP), betrachtet. Dieses Be-
rechtigungsobjekt besteht aus fünf Feldern.
Innerhalb des Berechtigungskonzeptes von CATT werden folgende drei Felder
auf ihren Inhalt hin geprüft:
A die ID eines Entwicklungsobjekts (OBJTYPE): Der Wert ‚SCAT‘ wird geprüft.
B der Knotenname (OBJNAME): Die Testablaufnummer wird geprüft. Daher
können Berechtigungen für einzelne Testabläufe oder Testablaufgruppen
vergeben werden.
C die Aktivität (ACTVT): Folgende Werte für das Feld ACTVT werden hierbei
einer Prüfung unterzogen:
◗ ‚02‘ bei Anlegen, Ändern und Löschen von Testbausteinen und Testabläu-
fen
◗ ‚03‘ bei Anzeigen von Testbausteinen und Testabläufen
◗ ‚06‘ bei Starten von Testbausteinen und Testabläufen
◗ ‚07‘ bei Verwalten von Testabläufen
Zur Vergabe von Prüfkennzeichen ist es erforderlich, dass in den Benutzerfest-
werten für CATT das Kennzeichen Prüfkennzeichen markiert ist.
Die Entwicklungsklasse für das Transportwesen (DEVCLASS) wird innerhalb
der Berechtigungsprüfung von CATT nicht berücksichtigt, ebensowenig die Be-
rechtigungsgruppe ABAP/4-Programm (P_GROUP).
Beim Remotestart wird innerhalb der Berechtigungsprüfungen zunächst sicher-
gestellt, dass der Zielmandant des Remote-Systems zum Starten von CATT zu-
gelassen ist. Dieses Kennzeichen ist also bei der Einrichtung des Mandanten ent-
sprechend zu setzen, da man im Zielmandanten des Remote-Systems die zum
Starten von Testabläufen übliche Berechtigung für das Berechtigungsobjekt
‚S_DEVELOP‘ benötigt. Diese Berechtigung darf allerdings nicht auf bestimmte
Testabläufe beschränkt werden. Der Anwender muss zum Starten aller Testab-
läufe berechtigt sein. Im Ablauf von Transaktionen und Funktionsaufrufen wer-
den die darin vorgesehenen Berechtigungen auch im Remote-System einer Prü-
fung unterzogen.
130
Sandini Bib
5.4 Aufzeichnungsfunktionalität
CATT stellt eine anwenderfreundliche, komfortable und einfach zu bedienende
Aufzeichnungsfunktionalität bereit. Mit dieser Funktionalität wird dem An-
wender von CATT ein Werkzeug an die Hand gegeben, das es ihm erlaubt, so-
wohl einzelne Transaktionen als auch ganze Transaktionsketten aufzuzeichnen
und später jederzeit wieder abzuspielen. Um eine Transaktion aufzeichnen zu
können, sind der Transaktionscode sowie die für die Durchführung der Trans-
aktion erforderlichen Daten notwendig. Zu jedem Dynpro (dynamisches Pro-
gramm) ist im R/3-System unter dem Systemstatus der entsprechende zugehö-
rige Transaktionscode zu finden. Die Daten zur Aufzeichnung werden am
besten mit den entsprechenden Applikationsexperten festgelegt, da diese mit
den Daten gut vertraut sind. Die bei der Aufzeichnung der einzelnen Transak-
tionen verwendeten Festwerte, auch Defaultwerte genannt, werden bei jedem
Start eines Test durchgespielt. Sie können aber auch gezielt durch Parameter er-
setzt werden, wodurch die Flexibilität des CATT-Tools erheblich gesteigert wer-
den kann. Der Anwender hat natürlich in CATT auch die Möglichkeit, bestehen-
de, von der SAP AG programmierte Transaktionen seinen Vorstellungen und
Bedürfnissen gemäß anzupassen bzw. eigene Transaktionen zu entwickeln. Al-
lerdings muss er in diesen Fällen auf die komfortable Aufzeichnungsfunktiona-
lität verzichten und manuell arbeiten.
5.5 Expertenmodus
Das Computer Aided Test Tool verfügt über einen Expertenmodus, in dem auch
komplexe betriebswirtschaftliche Testszenarien sowohl aus funktionaler als
auch aus prozessorientierter Sicht erstellt werden können. Die bei der Aufzeich-
nung eines Testbausteins bzw. Testablaufs verwendeten Festwerte können bei

der Nachbearbeitung im Expertenmodus gezielt durch Import- bzw. Exportpa-
rameter substituiert werden, wodurch die Flexibilität des Testwerkzeugs CATT
erst in seinem vollem Umfang genutzt werden kann. Die Festwerte werden
dann zu so genannten »Vorschlagswerten« umfunktioniert, die bei jedem Start
eines Tests für die einzelnen Parameter vom R/3-System angeboten werden.
Falls die Parameter mit anderen Werten belegt werden sollen, können diese
Vorschlagswerte einfach überschrieben werden. Häufig benötigte Parameter-
einstellungen können durch das Anlegen von externen und internen Varianten
gespeichert werden. Auf diese Varianten kann sowohl extern als auch intern
beim Ausführen des Testablaufs in beliebiger Weise zurückgegriffen werden.
Die Parametrisierung als solche sowie die externen und internen Varianten wer-
den im weiteren Verlauf noch ausführlich beschrieben.
131
Sandini Bib
5.6 Neuheiten in R/3-Release 4.0
5.6 Neuheiten in R/3-Release 4.0
5.6.1 Releaseübergreifende Tests

Ab Release 4.0 eröffnet sich den Kunden der SAP AG die Möglichkeit, verschie-
dene Anwendungen unter verschiedenen Releaseständen einzusetzen. Diese
entkoppelten Systeme kommunizieren über ALE (Application Link Enabling)
miteinander. Wollte man mit ALE verschiedene Releasestände koppeln, so er-
hielt man bisher nur im Remote-System verlässliche Dynprofolgen und sonstige
Informationen. Um diese Probleme zu lösen, wurde die Funktion des Remote-
Aufrufs von CATT-Bausteinen entworfen. Das Protokoll zu einem remote auf-
gerufenen Testbaustein besteht aus der Dokumentation der Import- und Ex-
portschnittstelle sowie der verwendeten RFC-Destination.
5.6.2 Erweiterung der Namensräume

Die bisherigen achtstelligen Namen von CATT-Objekten reichten unter dem
Gesichtspunkt der Vergabe von Partner- und Kundennamensräumen nicht
mehr aus. Die Namen wurden daher von 8 auf 16 Stellen verlängert. Die maschi-
nelle Nummernvergabe wurde auf externe Namensvergabe umgestellt. Daher
muss der Benutzer nun beim Anlegen, Aufzeichnen und Kopieren von CATT-
Objekten einen neuen Namen angeben. Die bisher zweistellige numerische Ken-
nung von Varianten wurde auf drei Stellen verlängert und auf alphanumerische
Namen umgestellt. Bei Repository-Objekten, auf die in CATT- Objekten Bezug
genommen wird, wurden die Eingabefelder erweitert. CATT-Objekte, die in ei-
nem 4.0-System angelegt wurden, können dann nicht mehr in ein 3.X-System
transportiert werden, sofern ihr Name mehr als acht Zeichen lang ist. Auch dür-
fen referenzierte Objekte (Testbausteine, Transaktionen, Tabellen und Program-
me) keine längeren Namen haben als in Release 3.X zugelassen werden.
5.7 Neuheiten in R/3-Releases 4.5 A bis

einschließlich 4.6 B
5.7.1 Testen von Funktionsbausteinen

In CATT bis einschließlich Release 3.1 hatte der Aufruf von Funktionsbaustei-
nen mit der Funktion FUN den Zweck, die im Funktionsbaustein programmier-
te Funktionalität zu nutzen. Ein Aufruf zum Zweck des Testens eines Funkti-
onsbausteins war bisher nicht vorgesehen. Mit der neuen Testfunktionalität ist
geplant, beliebige Funktionsbausteine mit beliebigen Schnittstellen zu testen.
Die Funktionsbausteine können dabei auch Dialoge enthalten.
132
Sandini Bib
Änderungen in der Vorgehensweise: Vom Einstiegsbild der CATT-Transaktion

aus, können Sie die Funktionalität Funktionsbaustein aufzeichnen nutzen, um ein
CATT-Objekt anzulegen, das einen Funktionsbausteintest durchführen soll. Sie
geben dann den Funktionsbaustein an, der getestet werden soll. Auf dem Folge-
bild müssen Sie dann die Import-, Changing- und Tabellenschnittstelle spezifi-
zieren. Danach wird der Funktionsbaustein ausgeführt. Sofern der Funktions-
baustein Dialoge beinhaltet, werden die einzelnen Bildschirmbilder mit den von
Ihnen gemachten Eingaben aufgezeichnet. Bei der späteren Nachbearbeitung
des Testfalls können Sie diese Eingaben parametrisieren. Dies erfolgt analog zu
einem Transaktionstest mit CATT. Nach Beendigung des Funktionsbausteins
wird das Ergebnis der Ausführung des Funktionsbausteins angezeigt und auf-
gezeichnet. Bei einem späteren Funktionsbausteintest, wird das aktuelle Ergeb-
nis mit dem aufgezeichneten Ergebnis verglichen.
5.7.2 Unterdrückung des Kontierungsblocks im CATT

Vor Release 4.5A wich die Dynprofolge bei Testabläufen mit dem Computer Ai-
ded Test Tool (CATT) von der Dynprofolge bei Warenbewegungen im Dialog
ab. Beim CATT wurde grundsätzlich der Kontierungsblock als eigenes Dialog-
fenster aufgerufen.
Ab Release 4.5A ermittelt das System, ob das CATT aktiv ist. Wenn dies der Fall
ist, so wird der Kontierungsblock unterdrückt. Somit verhält sich der Testablauf
so wie der Dialog. Beim Batch-Input wird der Kontierungsblock weiterhin in ei-
nem eigenen Dialog aufgerufen.
5.7.3 CATT: Integration externer Test Tools

Ab Release 4.5a existiert eine neue Schnittstelle im CATT des SAP-Systems, um
Testabläufe im Format externer Test Tools vom SAP-System aus zu nutzen. Sie
können die Testabläufe externer Test Tools als externe CATT-Testbausteine im
SAP-System speichern und von dort auch ablaufen lassen. Die Pflege der Testab-
läufe geschieht, indem das externe Test Tool vom SAP-System aus im Pflegdia-
log gestartet wird. Um das externe Test Tool vom SAP System aus zu nutzen,
sind ab Release 4.5a Customizing-Einstellungen unter der Anwendungskompo-
nente CA-CAT-TOL nötig.
5.7.4 Wizards zur Unterstützung bei der

Workflow-Definition
Wizards bieten eine Dialog-geführte Hilfestellung, wenn innerhalb einerWork-
flow-Definition genau umrissene Teilaktivitäten zu modellieren sind. Basierend
auf einigen wenigen Benutzereingaben übernimmt der Wizard die erforderli-
chen Definitionen von Einzelschrittaufgaben und Workflow-Schritten. Im Ein-
133
Sandini Bib
5.7 Neuheiten in R/3-Releases 4.5 A bis einschließlich 4.6 B
zelnen werden Sie von Wizards u.a. bei folgenden Modellierungsaufgaben un-
terstützt:
◗ Definieren und Einfügen einer Einzelschrittaufgabe, mit der ein Test-Ablauf
(CATT) ausgeführt wird
◗ Modellieren einer Terminüberwachung, bei der die Terminüberschreitung
den ursprünglichen Schritt beendet und Folgeschritte definiert werden kön-
nen
◗ Erzeugen einer Objektreferenz aus gegebenen Schlüsselfeldern
◗ Definieren und Erzeugen einer Formularaufgabe
◗ Versenden von Mails aus einem Workflow
◗ Definieren und Einfügen einer Einzelschrittaufgabe, mit der ein Report aus-
geführt wird
◗ Versenden von Mails
Wizards werden über das Menü "Wizards" im grafischen oder alphanumeri-
schen Workflow-Editor aufgerufen.
5.7.5 Erweiterung der Funktionalität in der

Test Workbench
Zu Release 4.6A werden vor allem ergonomische Gesichtspunkte bei der Wei-
terentwicklung der Test Workbench berücksichtigt. Dies schlägt sich vor allem
in der neuen Benutzeroberfläche des CATTs nieder.
5.7.6 Test Organizer
Status-Infosystem
Mithilfe des Status-Infosystems ist es möglich, testplanübergreifende Statusana-
lysen durchzuführen. Über ein Selektionsbild können Sie dabei die relevanten
Testpläne spezifizieren. Um diese Selektion zu erleichtern, wurde dem Testplan
ein neues Attribut Stichwort hinzugefügt. Über dieses Stichwort kann dann im
Status-Infosystem selektiert werden. Das Ergebnis des Status-Infosystems ist
eine Liste aller Testpläne, die den Selektionskriterien entsprechen. In der Liste
wird das Ergebnis der jeweils zuletzt ausgeführten Statusanalyse über den je-
weiligen Testplan angezeigt. Zu Präsentationszwecken kann das Ergebnis des
Status-Infosystem in eine Desktop-Applikation geladen und dort bearbeitet
werden.
134
Sandini Bib
5.7.7 CATT: Neuer Pflegemodus

Der neue CATT Pflegemodus stellt eine Weiterentwicklung des bereits mit Re-
lease 4.5 ausgelieferten Easy Modes dar. Intention dieses Pflegemodus ist die
Bereitstellung der CATT-Funktionalität in einem Umfeld, das keinen oder nur
einen geringen Schulungsaufwand erfordert. Der Benutzer ist in der Lage, Test-
fälle zu erfassen, indem er die zu testenden Transaktionen aufzeichnet. Wurde
in einem Testfall eine Transaktionskette aufgezeichnet, kann der Benutzer die
Transaktionen miteinander verketten. Das bedeutet, dass das Ergebnis einer
Transaktion an die nachfolgenden Transaktionen übergeben werden kann. Des
Weiteren ist das Anlegen von Startvarianten möglich. Unter einer Variante ver-
steht man dabei einen Wertesatz, der die Eingaben in die Eingabefelder der
Transaktionen während des Ausführens enthält.
Auch die Prüfung von Feldinhalten und Fehlermeldungen wird realisiert. Dabei
ist eine Prüfung gegen Festwerte, aber auch gegen Parameter möglich. Beim Er-
stellen eines Testfalls könnte folgende Vorgehensweise gewählt werden:
◗ Festlegen eines neuen Testfallnamens
◗ Aufzeichnen einer oder mehrerer Transaktionen
◗ Verketten der Transaktionen
(sofern mehrere Transaktionen aufgezeichnet wurden)
◗ Definition von Prüfungen
◗ Anlegen von Varianten
◗ Wartezeit zwischen Bildschirmbildern. War es ab Release 4.5B möglich, zwi-
schen einzelnen CATT-Funktionen eine Wartezeit einzuplanen, wird mit
Release 4.6 auch die Definition einer Wartezeit zwischen einzelnen Bild-

schirmbildern möglich sein. Die Wartezeit wird mithilfe einer Wertzuwei-
sung an den Parameter &LWD festgelegt und wirkt hierbei bei allen dunkel
abgespielten Transaktionen.
◗ Angleich von Varianten: Bisher wurde im CATT zwischen internen und ex-
ternen Varianten unterschieden. Die Unterscheidung schlug sich sowohl in
der Pflege (im R/3 bzw. lokal am PC) als auch bei der Ausführung der Vari-
anten nieder. Diese Unterschied gilt ab Release 4.6 nicht mehr. Ab dieser Ver-
sion können die Varianten im R/3-System und über einen Download /
Upload auch lokal bearbeitet werden.
◗ Definition von Prüfungen zu einem Transaktionsablauf
◗ Lesen und Prüfen von Feldinhalten auf Dynpros: Die Einzelbildverarbeitung
bildet die Grundlage für diese neue Funktionalität. Innerhalb des Testfalls
können nun bei der Detailpflege einer TCD-Funktion bzw. eines Funktions-
bausteintests mit Dialogen Felder, die von dem zu testenden Dialog versorgt
werden ausgelesen oder geprüft werden.
135
Sandini Bib
5.8 Zusammenfassung der Ziele von CATT
◗ Lesen von Feldinhalten: Bei der Pflege des Testfalls wird in der Detailpflege
zu dem relevanten Dynpro auf dem Feld, das ausgelesen werden soll, ein Pa-
rameter definiert. Dazu steht dem Benutzer die Funktion Feldwert lesen zur
Verfügung. Durch diese Funktion wird ein Exportparameter angelegt, in den
der Feldwert gestellt wird.
◗ Prüfen von Feldinhalten: Bei der Prüffunktion wird nach Abschluss der
Transaktion überprüft, ob der zur Laufzeit gültige Wert eines Feldes mit ei-
nem erwarteten Wert übereinstimmt. Die Prüfung kann sowohl gegen einen
Festwert als auch gegen einen Parameter erfolgen. Erfolgt die Prüfung gegen
einen Parameter, muss der Testfallersteller darauf achten, dass zur Laufzeit
der Parameter mit dem richtigen Prüfwert versorgt wird. Wird ein noch nicht
vorhandener Parametername angegeben, legt das System automatisch einen
Importparameter an. Zur Definition einer Prüfung steht dem Benutzer auf
der Detailpflege des relevanten Dynpros die Funktion Feld prüfen zur Verfü-
gung.
◗ Simulation von Custom Controls: Der Einbau von Custom Controls in die
Applikation erfordert eine Erweiterung der Funktionalität des CATTs, um
die Applikationen weiterhin mit CATT testen zu können. Bei der Aufzeich-
nung von Testfällen werden zusätzlich zu den bisher aufgezeichneten Einga-
ben in Dynprofelder jetzt auch die Datenströme von und zu den Custom
Controls aufgezeichnet, die bei Data Providers und der Automation Queue
anfallen. Beim Abspielen des Testfalls werden die Custom Controls ausge-
schaltet und die Benutzeraktionen durch Einspielen der aufgezeichneten Da-
tenströme simuliert.
5.8 Zusammenfassung der Ziele von CATT

Durch den Einsatz von CATT lassen sich also zusammenfassend folgende Ziele
im Unternehmen realisieren:
◗ Steigerung der Softwarequalität
◗ Vereinheitlichung und Systematisierung von Tests
◗ beliebige Wiederholbarkeit der Testabläufe
◗ Automatisierung des Testvorganges
◗ Erzeugung von Schulungsdaten
◗ Transparenz der Tests durch Modularisierung
◗ erhebliche Reduktion der Testkosten: Die Tests können durch CATT automa-
tisiert in einem Bruchteil der Zeit, die z.B. für einen manuellen Integrations-
test vorgesehen ist, durchgeführt werden. Dadurch werden einerseits die
personellen Ressourcen des R/3-einführenden Unternehmens geschont und
andererseits kostenintensive Beratertage in erheblichem Umfang eingespart.
136
Sandini Bib
◗ Dokumentation der Tests für die Qualitätssicherung anhand der Protokolle

und der Testunterlagen. Dadurch ist es leicht möglich, u.a. auch durch den
Einsatz von CATT und der im weiteren Verlauf dieses Buches näher be-
schriebenen Testworkbench die Anforderungen der in Europa führenden
Qualitätsnorm für die Softwareentwicklung namens ISO 9000-3 zu erfüllen.
Dies ist insbesondere für Unternehmen, die nach der genannten Norm zerti-
fiziert werden wollen, von erheblicher Bedeutung.
◗ Bei einem Releasewechsel können alle Tests erneut automatisch durchge-
führt werden.
◗ Konsistenz von Dokumentation, Hilfe und Schulungsmaterial bei gleichzei-
tig einfacher Handhabung wird durch den CATT-Einsatz sichergestellt, da
die mit CATT entwickelten und durchgeführten Tests auch für Schulungen,
Handbücher und Hilfefunktionen verwendet werden können. Da sich ein
CATT-Test an definierten Geschäftsprozessen orientiert, beschreibt jeder
Testablauf den dadurch abgebildeten Geschäftsprozess aus der Sicht des Be-
nutzers und gibt alle Geschäftsabläufe beispielhaft wieder. Dies hat den
Vorteil, dass in einer Benutzerschulung diese bereits in CATT eingestellten
und dort verfügbaren und damit wiederholbaren Abläufe von Anwendern
zunächst »hell« mit den Vorschlagswerten und anschließend mit anderen
Testdaten manuell Dynpro für Dynpro wiederholt werden können. Die Vor-
gabe entsprechender Stammdaten und auch die Konfigurierung und Initiali-
sierung des Schulungssystems kann ebenfalls über die erstellten CATT-
Abläufe sichergestellt werden. Prozessorientierte Hilfefunktionen können
auf die einzelnen Testbeschreibungen zugreifen.
137
Sandini Bib
Sandini Bib
Aufbau des CATT-Tools
6
Der Testablauf bildet einen vollständigen betriebswirtschaftlichen oder admini-
strativen Prozess mit allen Voraussetzungen ab, die für eine bestimmte Prüfung
notwendig sind. »Terminauftrag anlegen« erfordert z.B. als Voraussetzungen
»Debitor anlegen«, »Material anlegen« sowie »Konditionen festlegen«.
Ein Testablauf kann beliebige Testbausteine zu einer gesamten Anwendung
oder einer bestimmten Funktionalität einer Anwendung aufnehmen (referie-
ren). Es ist jedoch auch möglich, einen Testablauf ohne Testbausteine aufzubau-
en. Der Testablauf kann bei entsprechender Einstellung mit einem Prüfkennzei-
chen versehen werden.
Zu einem Testablauf gehören folgenden Komponenten:
◗ Testbaustein
◗ Protokoll
◗ Varianten
6.1 Testbaustein (optional)

Hier ist zwischen Testbaustein und Testablauf als solchem zu unterscheiden.
Diese Unterscheidung wird anhand des so genannten »modularen Konzeptes«
vorgenommen, welches im Folgenden näher erläutert wird.
6.1.1 Modulares Konzept

Mit CATT können sowohl Testbausteine als auch Testabläufe innerhalb des SAP-
Systems erstellt werden.
139
Sandini Bib
6.1 Testbaustein (optional)
Testbaustein
Ein Testbaustein entspricht der kleinsten prüfbaren Einheit, in der Regel einer
Transaktion z.B. »Kreditor anlegen« (Transaktionscode: FK01). Der Testbaustein
kann entweder direkt zum Testen verwendet oder in einem Testablauf referen-
ziert werden. Man kann einen Testbaustein auch als Testablauf für eine Trans-
aktion bezeichnen. Das Anlegen von Testbausteinen erfolgt über die komforta-
ble Aufzeichnungsfunktionalität von CATT, welche unter Ziffer 5.4 bereits
ausführlich beschrieben wurde. Dabei werden die Bildschirmbildabfolge und
die Eingaben auf den einzelnen Bildschirmbildern der ausgewählten Transakti-
on aufgezeichnet. Zu Erhöhung der Flexibilität der einzelnen Testbausteine
existieren je eine definierte Import- und Exportschnittstelle. Diese Schnittstellen
werden mit speziellen Export- und Importparametern realisiert. Hinsichtlich
näherer Erläuterungen zur Parametrisierung der Testbausteine und Testabläufe
wird auf das sich anschließende Kapitel 7 verwiesen.
Testablauf
Ein Testablauf wird bei CATT modular aus einzelnen Testbausteinen aufgebaut,
d.h., er besteht aus einer Aneinanderreihung von verschiedenen Testbaustei-
nen. Ein Testablauf kann einen betriebswirtschaftlichen Prozess sowohl aus
funktionaler als auch aus prozessorientierter Sicht abbilden. Testabläufe wer-
den mit der gleichen Pflegetransaktion wie Testbausteine angelegt und gepflegt.
Der einzige Unterschied besteht darin, dass man die komfortable Funktionalität
zum Aufzeichnen von Transaktionen für das Anlegen von Testabläufen nicht
benutzen kann. Die einzelnen Testbausteine bilden die Module, aus denen die
Testabläufe in beliebiger Weise zusammengestellt werden können.
Durch das modulare Konzept kann ein Testbaustein in verschiedenen Testab-
läufen genutzt werden. Dadurch werden Redundanzen vermieden. Die Pflege
eines Testbausteins hat sofort Auswirkungen auf alle Testabläufe, die den ge-
pflegten Testbaustein referenzieren. Dies reduziert den Änderungsaufwand so-
mit erheblich, da der Testbaustein nur einmal geändert werden muss, aber dann
in vielen Testabläufen gleichzeitig im geänderten Zustand zur Verfügung steht.
Um z.B. den betriebswirtschaftlichen Prozess »Terminauftrag anlegen« als Test-
ablauf anlegen zu können, muss zuvor als Voraussetzung die Aufzeichnung der
Transaktionen »Debitor anlegen«, »Material anlegen« sowie »Konditionen festlegen«
jeweils als Testbaustein erfolgen. Diese Transaktionen werden nach ihrer Auf-
zeichnung per CATT im Testablauf »Terminauftrag anlegen« eingebunden. Falls
nun später der betriebswirtschaftliche Prozess »Anfrage anlegen« durch einen Test-
ablauf abgebildet werden soll, sind dazu folgende Transaktionen notwendig:
»Debitor anlegen«, »Material anlegen« und »Anfrage anlegen«. Doch hier muss le-
diglich die Transaktion »Anfrage anlegen« noch als Testbaustein erstellt werden.
Denn die beiden übrigen benötigten Transaktionen wurden bereits zur Abbil-
dung des Testablaufs »Terminauftrag anlegen« als Testbausteine aufgezeichnet.
140
Sandini Bib
Bei der Abbildung des Prozesses »Anfrage anlegen« kann demnach auf die bei-
den bereits bestehenden Testbausteine zurückgegriffen werden. Dies verdeut-
licht, dass ein Testbaustein, wenn er einmal erstellt ist, in beliebig vielen Testab-
läufen referenziert werden kann. Dem einmaligen Aufwand zur Erstellung des
Testbausteins steht also durch die Option, ihn in beliebig viele Abläufe integrie-
ren zu können, ein erheblich höherer Nutzen gegenüber. Voraussetzung hierfür
ist allerdings, dass die Schnittstellen der einzelnen Testbausteine entsprechend
flexibel parametrisiert sind, um eine derart universelle Verwendbarkeit zu errei-
chen. Hier ist es erfahrungsgemäß sehr vorteilhaft, einen Standard, auch »Kon-
vention« genannt, für die Benutzung der Übergabeparameter der Testbausteine
festzulegen und auch konsequent einzuhalten. Testabläufe haben zu diesem
Zweck eine definierte Import- und Exportschnittstelle, durch die Testparameter
gezielt eingegeben werden können. Durch die Importparameter kann ein Test-
ablauf mit Werten von außen versorgt werden. Dadurch wird eine hohe Flexi-
bilität bei den Testabläufen erreicht. Testbausteine verfügen ebenfalls über eine
definierte Import- und Exportschnittstelle. Dadurch sind sie durch den Testab-
lauf parametrisierbar und können Ergebnisse an den Testablauf zurückgeben.
Die Exportschnittstelle eines Testablaufes ist im Vergleich zur Exportschnittstel-
le des Testbausteins allerdings nur sehr beschränkt einsetzbar. Die Thematik
»Parametrisierung von Testbausteinen und -abläufen« wird im weiteren Ver-
lauf dieses Buches gesondert und detailliert behandelt. Der Testablauf bzw.
Testbaustein erhält beim Anlegen vom System eine eindeutige Identifikation,
d.h., ihm wird vom System automatisch eine Nummer zugeordnet.
6.2 Protokoll
CATT erstellt beim Abspielen von Testbausteinen und Testabläufen in CATT
ausführliche Protokolle, die zentral auf der Datenbank des ausführenden R/3-
Systems abgelegt werden und alle relevanten Informationen über Ablauf und
Ergebnis des Testverlaufes enthalten. Die verschiedenen Protokolle können dort
jederzeit abgerufen werden.
Ein CATT-Protokoll ist hierarchisch aufgebaut und wird als Struktur mit Kno- Kapitel 6 – Aufbau des CATT-Tools
tenpunkten abgebildet. In dieser Struktur kann der Anwender so wie im Einfüh-
rungsleitfaden navigieren. Alle Eingaben und Meldungen sind im Protokoll
aufgelistet. Auf der ersten Ebene des jeweiligen Vorgangsprotokolls wird der
verwendete Testablauf (bei Verwendung der Funktion »Massenstart« mehrere)
bzw. der Testbaustein angezeigt. In der darunterliegenden Ebene sind die in
den Testablauf integrierten Funktionen, die Parameter und Variablen angeord-
net. Aus dem Protokoll kann man an dieser Stelle ablesen, mit welchen Werten
die einzelnen Parameter und Variablen versorgt wurden. Eine weitere Ebene
tiefer sind die einzelnen im Testablauf referenzierten Testbausteine aufgeführt.
Jeder dieser Testbausteine kann seinerseits wiederum eine Ebene tiefer »aufge-
rissen« werden. Das Testprotokoll zeigt dann die Bestandteile des betreffenden
Testbausteins, also der dort aufgezeichneten Transaktion. Man kann in dieser
141
Sandini Bib
6.2 Protokoll
Ebene ersehen, welches Feld in der aufgezeichneten Transaktion mit welchem

Wert versehen bzw. welches Feld in welcher Weise parametrisiert wurde. Des
Weiteren besteht die Möglichkeit, Attribute zu einem Ablauf bzw. einem Test-
baustein auszuwählen.
Jeder Schritt, der innerhalb eines Testablaufes bzw. Testbausteins per CATT
durchgespielt wurde, ist somit Schritt für Schritt nachvollziehbar. Der Anwen-
der kann genauso durch das Testprotokoll navigieren, wie er es vom Implemen-
tation Guide (IMG) im Rahmen des Customizings gewohnt ist.
Wenn der Testbaustein bzw. der Testablauf erfolgreich abgeschlossen wurde,
wird dies an den entsprechenden Stellen im Protokoll mit einer Erfolgsnachricht
kommentiert. Wurde z.B. die Transaktion »Material anlegen« mit Erfolg durch-
gespielt, das gewünschte Material also generiert, findet man im Protokoll die Er-
folgsmeldung »Material Nr. 0000002345 wurde angelegt«. Daran erkennt man,
dass dieser Testbaustein erfolgreich und fehlerfrei läuft. Natürlich kommt es
auch vor, dass im Rahmen dieser Tests diverse Fehler in einzelnen Testbaustei-
nen auftreten können. Auch dies ist aus dem Testprotokoll leicht ersichtlich. Bei
entsprechenden Transaktionsfehlern ist eine Anzeige des Kurzdumps möglich.
Bei auftretenden Kurzdumps kann man in die Dumpanzeige verzweigen. Wäh-
rend des Testvorgangs aufgetretene Fehler sind im Protokoll an der Stelle, an
welcher der Fehler auftrat, farblich gekennzeichnet und werden durch eine ent-
sprechende Fehlermeldung kommentiert. Durch Doppelklick auf die Fehler-
meldung erhält der Anwender detaillierte Informationen zum aufgetretenen
Problem. Überdies kann man anhand des vorliegenden Testprotokolls nun das
erwartete und dem tatsächlich erzielten Testergebnis vergleichen. Fehler und
Probleme innerhalb des Testszenarios sind folglich schnell und einfach zu eru-
ieren. Die einzelnen Testbausteine und -abläufe können zu diesem Zweck belie-
big oft gestartet werden. Damit hat man die Möglichkeit, einen eventuell aufge-
tretenen fehlerhaften Prozessschritt leicht sukzessive einzugrenzen und
abschließend zu verbessern. Auch damit erfüllt CATT die Anforderungen, wel-
che beim Testen von Software gestellt werden. Die Qualitätskriterien wurden
bereits eingangs in Kapitel 1 kurz dargelegt. Darüber hinaus werden die Lauf-
zeiten der Tests im Protokoll angezeigt. Bei der Anzeige mehrerer CATT-Proto-
kolle wird eine Liste erzeugt, welche die wichtigsten Daten enthält. Das Proto-
koll kann in zwei verschiedenen Formen erstellt werden:
◗ Langform
◗ Kurzform
6.2.1 Langform
Hierbei werden alle CATT-Funktionsdaten protokolliert. Im Fehlerfall wird au-
tomatisch ein Langprotokoll erzeugt, das bei dem fehlerhaften Baustein mit der
Protokollierung beginnt, auch dann, wenn auf dem Startbildschirm die Option
»kein Protokoll« markiert wurde.
142
Sandini Bib
6.2.2 Kurzform
Sofern keine Fehler auftreten, erhält der Anwender hier nur Informationen über
die im Testablauf aufgerufenen Testbausteine und Parameterinhalte. Welche
Form des Protokolls für einen Lauf erzeugt werden soll, entscheidet der Anwen-
der beim Starten im Startbildschirm von CATT. Das Protokoll wird schließlich
systemintern sowohl mit einem Erstelldatum als auch mit einem Verfallsdatum
versehen. Das Verfallsdatum wird standardmäßig auf 14 Tage nach Erstellda-
tum gesetzt. Es kann jedoch manuell verändert werden.
CATT verfügt hinsichtlich der Protokolle über eine Downloadfunktion, durch
welche die einzelnen Protokolle auf die Arbeitsstation heruntergeladen werden
können. Die heruntergeladenen Protokolle können dann z.B. mit Differenz-
Viewern von MS-Word auf Unterschiede hin untersucht werden.
Kapitel 6 – Aufbau des CATT-Tools

Selektionsbildschirm für CATT-Protokolle
6.2.3 Neuheit ab Release 4.0: Start aus dem CATT-Protokoll

Ab R/3-Release 4.0 ist es möglich, alle Teile der einzelnen Testbausteine und
Testabläufe aus dem jeweiligen CATT-Protokoll heraus mit denselben Daten zu
testen. Die Analyse eines CATT-Protokolls zeigt oftmals verschiedenste Fehler
in den einzelnen getesteten Transaktionen. Der einfachste Weg, diese Fehler zu
143
Sandini Bib
6.2 Protokoll
untersuchen ist der, diese Transaktion sofort mit den gleichen Daten erneut zu
starten. Bisher war ein Neustart der Transaktion aber nur über einen Alternativ-
modus mit Übernahme der entsprechenden, bereits im ersten Testlauf verwen-
deten Parameterwerte möglich.
Ab dem R/3-Release 4.0A können nun die einzelnen Testbausteine und Testab-
läufe direkt aus dem jeweiligen CATT-Protokoll heraus neu gestartet und damit
auch neu getestet werden. Durch die CATT-Funktion RESTART wird die Feh-
leranalyse erheblich vereinfacht. Damit kann je nach Cursorposition entweder
der gesamte Vorgang, ein Ablauf oder ein Testbaustein, der im Protokoll aufge-
zeichnet ist, ausgeführt werden.
6.2.4 Archivierung von Protokollen

Falls Daten, die nicht mehr benötigt werden, trotzdem aber noch in einem aus-
wertbaren Zustand erhalten bleiben sollen, dann kann man diese Daten mit dem
CATT-eigenen Archivierungsprogramm archivieren. Die Daten werden zu die-
sem Zweck vom R/3-System in Archivdateien geschrieben und danach aus dem
System entfernt, also gelöscht.
Um die Archivierung anzustoßen muss in den Benutzerwerten unter CATT die
Option Prüfkennzeichen aktiviert werden.
Es werden hier nur Vorgänge archiviert, die dieses Kennzeichen haben und de-
ren Verfallsdaten kleiner oder gleich dem aktuellen Systemdatum sind. Das Sys-
tem fügt dann beim Ausführen dem jeweiligen Vorgang die entsprechenden
Kennzeichen hinzu.
Es ist zu empfehlen, den eigentlichen Archivierungslauf als Hintergrundjob ein-
zuplanen, da dies die Systemressourcen erheblich schont. Dazu kann die Trans-
aktion SARA verwendet werden. Anhand des Archivierungslaufs werden dann
die Protokolle in einer Archivdatei angelegt und die Protokolldaten aus der Da-
tenbank gelöscht. Zusätzlich wird vom R/3-System der Report RSCATDEL ge-
startet. Dadurch werden alle Daten gelöscht, die nicht mehr benötigt werden
bzw. deren Verfallsdatum überschritten ist.
6.2.5 Auswertung von Protokollen

Im Protokoll werden evtl. aufgetretene Fehler mit Fehlermeldungen dokumen-
tiert. Im Folgenden sind besonders häufig auftretende Fehler und ihre Ursachen
aufgelistet:
◗ Leave to transaction
Dieser Befehl führt zum Abbruch der Transaktion.
144
Sandini Bib
◗ Batch-Input-Daten für Dynpro XXX nicht vorhanden

Folgende Ursachen sind hierbei denkbar: Im Testablauf bzw. Testbaustein
wurde eine falsche Bildfolge gepflegt. Im Testablauf bzw. Testbaustein fehlt
ein Bildschirmbild. Während des Testlaufs trat ein unerwartetes Bildschirm-
bild Dialogfenster auf (Unterschied Online- bzw. Hintergrund-Betrieb!).
◗ Feld <tabelle-feldname>
Dies erlaubt keine Eingabe.
Ein Ausgabefeld wurde im Testablauf bzw. Testbaustein mit Werten verse-
hen.
◗ Bitte alle Mussfelder ausfüllen
Ein Mussfeld wurde nicht mit Werten versorgt.
6.3 Varianten
Man unterscheidet bei den Varianten von CATT zwischen externen und inter-
nen Varianten.
6.3.1 Externe Varianten

CATT bietet die Möglichkeit, zu komplexen Testabläufen externe Varianten an-
zulegen, mit denen der Anwender, Varianten für die Importparameter von Te-
stabläufen in einem Tabellenkalkulationsprogramm wie z.B. Microsoft EXCEL
erstellen kann. Es können bis zu 99.999 externe Datensätze erzeugt und dann
auch mittels CATT in das R/3-System zu verschiedensten Zwecken eingespielt
werden.
Man kann den Testablauf mit dem Kennzeichen Externe Variante in der Attribu-
tepflege versehen. Dadurch erreicht man, dass der Testablauf beim Start immer
auf externe Varianten zurückgreift. Sollten diese nicht vorhanden sein, wird
vom R/3-System eine Fehlermeldung ausgegeben. Falls der Testablauf nicht
mit dem Kennzeichen Externe Variante versehen wird, prüft das System beim
Ausführen des Tests trotzdem, ob eine externe Variante existiert. Diese wird, so- Kapitel 6 – Aufbau des CATT-Tools
weit vorhanden, beim Ablauf auch benutzt. Sollte lokal auf dem startenden
Rechner im Standardverzeichnis eine Textdatei mit dem Namen des Testablaufs
gefolgt von dem Suffix TXT vorhanden sein (Beispiel: KBC00271.TXT), dann
wird diese vom CATT-Ablauf als Datei mit externen Varianten geladen. Die Da-
tendateien der externen Varianten sind Textdateien. Die einzelnen Elemente der
Datei sind durch Tabulatoren voneinander getrennt. Dabei stehen in der ersten
Zeile der Datei die Parameternamen ohne vorangestelltes &. Die zweite Zeile
der Datei enthält die Kurztexte zu den Parametern. In der dritten Zeile stehen
die Vorschlagswerte der Parameter, die während der Aufzeichnung der Trans-
aktion eingegeben wurden. Ab der vierten Zeile können eigene Werte eingetra-
gen werden. D.h., erst ab der vierten Zeile dieser Textdatei beginnen die Daten
der externen Varianten.
145
Sandini Bib
6.3 Varianten
CATT bietet die Möglichkeit, erstellte externe Varianten aus dem externen File
in das R/3-System automatisch zu importieren. Dadurch sind diese für alle Be-
nutzer ausführbar. Außerdem können damit die externen Varianten auch in an-
dere R/3-Systeme transportiert werden. Wurde eine externe Variante mittels
CATT ins R/3-System importiert, dann wird diese ausgeführt, sofern auf dem
lokalen Rechner keine Datei existiert, die den Namen des Testablaufs gefolgt
von dem Suffix TXT führt.
6.3.2 Interne Varianten

Werden für einen Testablauf im Computer Aided Test Tool Importparameter
verwendet, so können für diesen Testablauf bis zu 99 interne Varianten im R/3-
System abgelegt werden. Der Inhalt dieser Varianten wird den einzelnen Im-
portparametern zugewiesen. Diese Werte können gegebenenfalls im Testablauf
auch manipuliert werden. Es können darüber hinaus einzelne von den angeleg-
ten Varianten ausgewählt werden, die anschließend von CATT im Testablauf
durchgespielt werden, was das Tool noch flexibler macht.
Im Hinblick auf die Verwendung von externen und internen Varianten sei an
dieser Stelle auf Kapitel 8 verwiesen. Dort wird sowohl die Generierung einer
externen Excel-Datei mit anschließendem Einpflegen von Daten in diese Datei
als auch das Importieren von externen Varianten ins R/3-System sowie das An-
legen von internen Varianten ausführlich beschrieben.
6.3.3 Externe Anwendungen

In einen CATT-Testbaustein können externe Anwendungen eingebunden und
in Testabläufen aufgerufen werden. Dies ermöglicht z.B. das Starten externer
Testwerkzeuge oder das Anzeigen von Dokumentationen zu manuellen Testfäl-
len mit externen Programmen wie z.B. MS-Word Voraussetzung dafür ist, dass
die entsprechenden Anwendungsprogramme lokal auf dem von CATT-Anwen-
der benutzten Rechner verfügbar und lauffähig sind.
Folgende Anforderungen werden dabei an das Frontend gestellt:
◗ Installation von Windows NT, Windows 95, Windows 3.x oder OS/2
◗ Installation des entsprechenden Anwendungsprogramms
◗ Verknüpfung der Extension des Dateinnamens mit dem entsprechenden An-
wendungsprogramm
Zur Kommunikation mit einer externen Anwendung können in jedem CATT-
Baustein entsprechende Parameter definiert werden. Import-Parameter werden
in eine Textdatei heruntergeladen und können von der externen Anwendung
gelesen werden. Diese Textdatei hat folgende Struktur:
146
Sandini Bib
Für jeden Parameter ist eine dreiteilige Textzeile vorgesehen:

1. Teil: Parametertyp 1-stellig, »I« = Import-, »E« = Export-Parameter
2. Teil: Parametername max. 12-stellig, ohne vorangestelltes »&«
3. Teil: Parameterwert max. 132-stellig.
Der erste Teil ist durch ein Leerzeichen vom zweiten Teil getrennt. Der zweite
Teil wird zwölfstellig ausgegeben. Ist der Parametername kürzer, werden Leer-
zeichen eingefügt. Schließlich wird der zweite Teil vom dritten Teil durch » = «
(Leerzeichen Gleichheitszeichen Leerzeichen) getrennt.
I IMPORT1 = Test
E EXPORT = Test Ende
E EXPORT1 = Test erfolgreich
Bei der Rückgabe der Exportparameter können die Leerzeichen zwischen den
drei Teilen weggelassen werden. Die gesamte Textzeile für einen Parameter
kann maximal 148 Zeichen enthalten.
Die Textdatei wird als erste Datei von den Dateien für die externe Anwendung
heruntergeladen. Die externe Anwendung kann selbst Exportparameter in diese
Textdatei stellen, die nach dem Ablauf der externen Anwendung vom CATT-
Baustein hochgeladen werden. Diese Parameter können danach in CATT wei-
terverarbeitet werden. Die Namen der von CATT vorgesehenen Exportparame-
ter werden zusammen mit den Importparametern heruntergeladen. Standard-
mäßig wird für die Textdatei zur Parameterübergabe der Name CAT-
START.TXT verwendet. Wird ein anderer Filename gewünscht, so definiert
man im entsprechenden CATT-Baustein einen Importparameter mit dem Na-
men &PARAM-FILE. Diesem Parameter kann als Wert der gewünschte Datei-
name mitgegeben werden. Sofern in einen Testablauf ein Testbaustein integriert
wird, der eine externe Anwendung aufruft, wird dieser Testbaustein in jedem
Fall hell, also mit Bildschirmanzeige abgespielt. Beim Starten des Testbausteins
erscheint ein Dialogfenster, in dem weitere Informationen zur Vorgehensweise
enthalten sind. Wurde für den Testbaustein der externen Anwendung ein Lang- Kapitel 6 – Aufbau des CATT-Tools
text mit Testanweisungen für die geplanten Bearbeitungsschritte eingepflegt, so
kann dieser Langtext mit der Funktion LANGTEXT aus dem Dialogfenster her-
aus zur Anzeige gebracht werden.
6.3.4 Attribute
Hierbei handelt es sich um verschiedene Kennzeichen und Verwaltungsinfor-
mationen zu den einzelnen Testbausteinen bzw. Testabläufen, die als Suchkrite-
rium im Repository-Informationssystem dienen können. Ein wichtiges Attribut
z.B. kennzeichnet, ob es sich um einen Testablauf oder einen Testbaustein han-
delt.
147
Sandini Bib
6.3 Varianten
Nachfolgende Abbildung zeigt den Attributspflegebildschirm des Computer

Aided Test Tools.

Attributspflegebildschirm von CATT
Auf dem Attributspflegebildschirm wird, wie man sieht, zwischen Kopfdaten,

allgemeinen Daten, Verwaltungsdaten, Abhängigkeiten, Nutzbarkeit und
Kennzeichen differenziert. Jedes dieser Attributsfelder soll im Folgenden kurz
erläutert werden.
Kopfdaten
Als Kopfdaten werden folgende Attribute bezeichnet:
Testbaustein/Testablauf
Beim Sichern des Testbausteins bzw. des Testablaufs wird vom R/3-System au-
tomatisch eine eindeutige Nummer vergeben, über welche der Baustein bzw.
der Ablauf zu identifizieren ist. Diese Baustein- bzw. Ablaufnummer sollte man
sich am besten sofort notieren, um den Testbaustein bzw. -ablauf später ohne
großen Aufwand wieder auffinden zu können.
148
Sandini Bib
Status
Der Status wird vom R/3-System automatisch beim Sichern der Testbausteine
bzw. -abläufe gesetzt. Aus dem Status lässt sich ablesen, ob ein Testbaustein
bzw. -ablauf bereits gesichert ist oder noch überarbeitet wird.
Typ
Beim Aufruf wird vom System initial C = »CATT« eingestellt. Der Typ eines
CATT-Ablaufs gibt an, in welcher Weise der Ablauf ausgeführt werden kann.
Es stehen hier folgende Typen zur Verfügung:
◗ C CATT: maschineller Einzel- oder Massenstart im R/3
◗ M Manuell: Es werden nur Attribute und Langtext genutzt.
◗ V Veri: Start von Verifikationsreports SAP-intern
◗ R Remote R/2: maschineller Start über RFC in R/2-Systeme
◗ S Systeminst: Installationsablauf für Schulungssysteme
◗ X Externe Anw.: Start externer Anwendung nach Download
Originalsprache
Wird der Testbaustein bzw. der -ablauf gespeichert, trägt das System hier die
Sprache ein, mit der sich der Benutzer bei im R/3-System angemeldet hat.
Kurztext
Bei diesem Feld handelt es sich um ein Mussfeld. Kurze Erläuterungen zum
Testbaustein bzw. Testablauf sind hier einzutragen. Am besten gibt man bei
Testbausteinen als Erstes den Transaktionscode der zu testenden Transaktion
an. Dies erhöht die Übersichtlichkeit beim Referieren von Testbausteinen in
Testabläufen.
Stichwort 1 Kapitel 6 – Aufbau des CATT-Tools
Auch hierbei handelt es sich um ein Mussfeld. Das Stichwort 1 dient als Such-
kriterium im Repository-Informationssystem. Falls man für einen Testbaustein
bzw. Testablauf mehr als ein Stichwort hinterlegen will, besteht die Option,
über die Drucktaste Stichworte in ein Dialogfenster zum Pflegen der insgesamt
fünf möglichen Stichworte zu gelangen.
Entwicklungsklasse
Beim Sichern wird die Entwicklungsklasse in einem eigenen Dialogfenster er-

fragt. Die Entwicklungsklasse kann nachträglich geändert werden.
149
Sandini Bib
6.3 Varianten
Allgemeine Daten
Applikation
Hier trägt man die Bezeichnung der Applikation, also die des Moduls, entspre-
chend der SAP-Funktionsliste ein, z.B. FI für die Applikation Finanzwesen, oder
man wählt sie mit der (F4)-Eingabehilfe aus.

Anzeige der SAP-Anwendungskomponenten
Subapplikation
Der Teilbereich der Applikation ist hier anzugeben (gemäß der SAP-Funktions-
liste, z.B. GL für Hauptbuchhaltung), oder Auswahl mit der (F4)-Eingabehilfe.
Komponente
Hier wird die Bezeichnung für die Komponente innerhalb der Subapplikation
eingetragen (gemäß der SAP-Funktionsliste, z.B. CU für Währungsbuchhal-
tung) oder aber mit der (F4)-Eingabehilfe ausgewählt.
150
Sandini Bib
Applikation, Subapplikation und Komponente bilden zusammen einen so ge-

nannten »Anwendungsbereich« des SAP-Funktionsbaums. Zum Beispiel: FI-GL-
CU für Applikation Finanzwesen, Subapplikation Kreditorenbuchhaltung und
Komponente Grundfunktionen.
Priorität
Hier wird die Wichtigkeit der Testabläufe festgelegt. Dabei können folgende
Prioritätsstufen eingestellt werden:
A sehr hoch
B hoch
C mittel
D niedrig
Appl. übergreifend
Kennzeichnet einen applikationsübergreifenden Testablauf. Diese Art von Ab-

läufen werden in Integrationstests benötigt und erstrecken sich über mehrere
Applikationen.
Verwaltungsdaten
Falls in den Benutzerfestwerten für CATT das Kennzeichen Prüfkennzeichen
markiert ist, werden nach jedem Testablauf Verwaltungsdaten zum Testablauf
hinterlegt, denen Bearbeitungs- und Prüfdaten entnommen werden können.
Erfasser
Liefert Informationen über den Erfasser des Testablaufs. Nach dem Doppelklick
auf das Namensfeld erscheint das Dialogfenster Benutzer: Detailinformation.
Geändert von
Der Urheber von Änderungen wird hier festgehalten.
Verantwortl.
In dieses Feld wird beim Sichern automatisch der Erfasser des Testablaufs ein-
gestellt. Ist der Erfasser jedoch nicht der Ansprechpartner für diesen Testbau-
stein/Testablauf, sollte der Eintrag geändert werden.
151
Sandini Bib
6.3 Varianten
Gepflegt für Release und bis
Beide Felder sind voreingestellt. Über diese Felder wird das letzte gesicherte Re-
lease bekanntgegeben, in dem der Testablauf bzw. Testbaustein lauffähig war.
Es findet kein Abgleich mit dem aktuellen Release statt. Gegebenenfalls ist das
Feld Gepflegt für Release zu ändern.
In CATT gibt es drei Release-Angaben:
◗ gepflegt für Release (vom Benutzer änderbar)
◗ gepflegt bis Release (beim Anlegen oder Pflegen aktuell gesetzt)
◗ gültig bis Release (optional vom Benutzer eingebbar)
Durch diese Angaben definiert sich immer ein entsprechendes Intervall. Dieses
Intervall beinhaltet die angegebenen Grenzen und alle Releases dazwischen.
Folglich ist das Gültigkeitsintervall für jeden CATT-Ablauf eindeutig festgelegt.
Im Repository-Informationssystem und in der Test Workbench kann man nun
nach der Gültigkeit eines Ablaufs selektieren. Zu diesem Zweck stehen dort
zwei Selektionsfelder zur Verfügung:
◗ von Release
◗ bis Release
Aus den Selektionsangaben und dem Gültigkeitsintervall eines Ablaufs be-
stimmt sich eindeutig, ob der Ablauf zur Selektion passt oder nicht.
Gültig bis Release
Das Feld zeigt an, bis zu welchem Release der Testablauf bzw. Testbaustein lauf-
fähig ist. Das Feld Gültig bis Release muss nicht unbedingt ausgefüllt werden,
wenn wenn es jedoch gefüllt wird, müssen die ersten beiden Zeichen Ziffern sein.
Abhängigkeiten
Frontend
Kennzeichnet einen Testablauf bzw. Testbaustein als frontendabhängig. Das

heißt, dass dieser Testablauf bzw. Testbaustein nur von bestimmten Frontends
(z.B. WINDOWS, UNIX ...) gestartet bzw. geändert werden kann.
Beispiele: Zielpfad und Dateiname beim Download
Plattform
Kennzeichnet, ob ein Testablauf bzw. Testbaustein plattformabhängig (Be-

triebssystem des Servers) ist. Diese so gekennzeichneten Testabläufe bzw. Test-
bausteine sind nur auf bestimmten Systemplattformen lauffähig.
152
Sandini Bib
Sprache
Kennzeichen für einen sprachabhängigen Testbaustein oder Testablauf. Hier ist

in diesem Fall in dem dazugehörigen Feld die Sprache anzugeben, für die der
Testablauf bzw. Testbaustein gültig sein soll. Man kann die Sprache auch über
die (F4)-Eingabehilfe auswählen.
Beispiel: Vergleich von Texten in einer IF-Anweisung
Land
Kennzeichen für Testabläufe bzw. Testbausteine, die länderabhängig sind. In

diesem Fall trägt man in dem dazugehörigen Feld das Land ein, für das der Test-
ablauf bzw. Testbaustein gültig sein soll, oder man wählt es mit der (F4)-Einga-
behilfe aus.
Beispiel: Währungen oder Maßeinheiten können zu einer Abhängigkeit führen
Kontext
Die kontextabhängige Definition von Testabläufen hat Bedeutung für den Mas-
sentest. Wenn man beim Starten mehrerer Testabläufe eine Reihenfolge festle-
gen möchte, markiert man dieses Kennzeichen. In diesem Fall gibt man in dem
dazugehörigen Feld die Position ein (»1« bis »4« für Vorspannläufe oder »6« bis
»9« für Nachspannläufe).
Nutzbarkeit
Hier wird festgelegt, wie der Testablauf bzw. Testbaustein eingesetzt werden kann:
Anwendungstest
Der Testablauf bzw. Testbaustein ist zum Test einer Anwendung vorgesehen.
Individualtest
Der Testablauf bzw. Testbaustein ist noch in der Erstellungs- und Testphase und
soll noch nicht produktiv eingesetzt werden. Das Feld sollte demnach immer dann
markiert werden, wenn der Testablauf/-baustein nur vom Ersteller und noch nicht
allgemein genutzt werden soll. Man bezeichnet dies auch als so genannten »Alpha-
Test«.
Plattformtest (nur für Testabläufe)
Der Testablauf soll auf heterogenen Systemplattformen eingesetzt werden. So-

lange ein Testbaustein bzw. Testablauf noch bearbeitet und getestet wird, sollte
er mit dem Kennzeichen Individualtest versehen sein. Erst dann, wenn eine ein-
wandfreie Qualität gewährleistet ist, ist es zweckmäßig das Kennzeichen auf
Anwendungstest oder Plattformtest zu setzen.
153
Sandini Bib
6.3 Varianten
Kennzeichen
Testbaustein
Wenn das anzulegende Objekt ein Testbaustein sein soll, dann ist dieses Kenn-
zeichen zu markieren. Falls hier keine Markierung erfolgt, geht das System au-
tomatisch davon aus, dass es sich bei vorliegendem Objekt um einen Testablauf
handelt. Dies kann bei der Referenzierung des Testbausteins zu Schwierigkeiten
führen.
Externe TCD-Daten
In einem so gekennzeichneten Testablauf oder -baustein wird die zuerst ablau-

fende Transaktion mit Daten versorgt, die nicht aus der CATT-Ablage kommen,
sondern aus externen Textdateien. Die aufgezeichnete Transaktion wird von
CATT im Allgemeinen durch die externe Ansteuerung mehrfach durchgespielt,
maximal 999-mal. Die einzelnen Datensätze für einen Transaktionsdurchlauf
werden hier als Varianten bezeichnet. Dabei ist zu beachten: Die Dynprofolge in
den externen Daten muss absolut identisch sein mit der in CATT vorhandenen
Musterdynprofolge. Die Werte für BDC_OKCODE und BDC_CURSOR werden
immer aus den CATT-Daten geholt. Die Werte für sonstige Eingabefelder in den
Dynpros werden im Allgemeinen aus den externen Datein gelesen. Durch eine
entsprechende Steuerung kann veranlasst werden, dass für einzelne Dynpros
die CATT-Feldinhalte verwendet werden.
Abbruch-Kennz.
Falls CATT den Testablauf bzw. Testbaustein nach dem ersten aufgetretenen
Fehler abbrechen soll, ist dieses Kennzeichen zu setzen. Wenn nun ein Fehler im
Ablauf auftritt, bricht das System den Test an der Fehlerstelle ab und zeigt am
Monitor das fehlerhafte Dynpro der Transaktion an. Man hat nun die Möglich-
keit, den Fehler zu beheben. Wird anschließend mit (¢) bestätigt, setzt das Sys-
tem den Test wieder fort. Ohne Markierung des Abbruchkennzeichens läuft der
Test trotz eines unter Umständen aufgetretenen Fehlers bis zum Ende durch.
Das Abbruchkennzeichen wirkt jedoch nur in Testabläufen bzw. Testbaustei-
nen, die direkt gestartet werden. Bei referierten Testbausteinen wird der Wert
vom aufrufenden Testablauf überlagert. Dies bedeutet, dass der Testablauf im
Falle des Auftretens eines Fehlers nur dann vom System abgebrochen wird,
wenn in der Attributepflege des Testablaufs das Abbruchkennzeichen gesetzt
ist. In diesem Fall nutzt es nichts, wenn in der Attributpflege der Testbausteine
Abbruchkennzeichen gesetzt sind.
154
Sandini Bib
Inaktiv
Wenn ein Testablauf bzw. Testbaustein für die Nutzung gesperrt sein soll, ist
dieses Kennzeichen zu markieren. Ein Ausführen dieses Testbausteins bzw.
-ablaufs ist dann nicht mehr möglich. Allerdings ist hier Folgendes unbedingt
zu beachten: Setzt man einen Testbaustein, der in einem oder mehreren Testab-
läufen referenziert wird, inaktiv, kann dies unter Umständen bedeuten, dass der
Testablauf dadurch fehlerhaft wird oder im schlimmsten Fall überhaupt nicht
mehr lauffähig ist, da ja ein wesentliches Element des Ablaufs nicht mehr funk-
tionsfähig ist.
Externe Varianten (nur für Testablauf)
Wenn dieses Kennzeichen markiert wurde, erwartet der Testablauf Datensätze

aus externen Varianten. Siehe hierzu die Ausführungen in Kapitel 8.
Freigegeben (nur für Testbausteine)
Wenn Testbausteine für die Verwendung in Abläufen aller Applikationen ange-

boten werden sollen, setzt man dieses Kennzeichen. Mit diesem Kennzeichen
wird eine einwandfreie Qualität und ständige Pflege der Testbausteine garan-
tiert.
155
Sandini Bib
Sandini Bib
Funktionen des
CATT-Tools
7
Die hier näher beschriebenen Funktionen des Computer Aided Test Tools
entsprechen einzelnen Testaktionen, die in einem Testbaustein oder Testablauf
aufgenommen und während des Abspielens eines Tests ausgeführt werden
können.
Um Bausteine mithilfe von CATT schnell und effektiv erstellen zu können, sollte
man mit den Funktionen der CATT-Pflegetransaktion vertraut sein. Besonders
wichtig ist dabei der Umgang mit dem Funktionseditor. Für die Programmie-
rung der Funktionen für CATT-Abläufe wurde von der SAP AG ein einfach zu
bedienender Editor entwickelt, dessen Funktionalitäten im Folgenden kurz be-
schrieben werden. Damit CATT-Objekte schnell und effizient erstellt und ge-
pflegt werden können, ist es erforderlich, die Grundfunktionen dieses Editors
zu beherrschen.
Sobald man die Pflegetransaktion für CATT-Objekte verlässt, verzweigt das Sys-
tem in das Einstiegsbild für die Pflege von CATT-Objekten. Hier gibt man die
Nummer des in der letzten Übung erstellten Testbausteins an. Durch Auswahl
der Funktion Ändern verzweigt man direkt in den Funktionseditor für die Pflege
der CATT-Funktionen. Falls sich der Anwender noch in der Pflegetransaktion
für CATT-Objekte befindet, muss er die Funktion Funktionen ausführen. Wie bei
allen SAP-Editoren gibt es auch beim Funktionseditor den Anzeige- und den Än-
dern-Modus.
157
Sandini Bib
7.1 Allgemeine Funktionen
7.1 Allgemeine Funktionen

7.1.1 Funktionseditor
Die erste Spalte »K« des Funktionsbildschirms dient der Eingabe von Editor-
kommandos. In der folgenden Tabelle werden die möglichen Editorbefehle des
Funktionseditors vorgestellt:
Kommando Auswirkung
r(epeat) Wiederholen: Hiermit schreibt man den Inhalt der betreffenden Zeile in
die darauf folgende Zeile
i(nsert) Einfügen: Hiermit fügt man nach der betreffenden Zeile eine Leerzeile
ein.
d(elete) Löschen: Hiermit ist die betreffende Zeile zu löschen.
c(opy) Kopieren: Anhand dieses Editierkommandos kann man die entspre-

chend gekennzeichnete Zeile im Funktionsbildschirm kopieren.
m(ove) Verschieben: Hiermit kopiert bzw. verschiebt man die betreffende Zeile.
Für diese Editorbefehle benötigt man immer eine Zielangabe, d.h., es
muss zusätzlich die Zielzeile »a« gekennzeichnet werden.
> Referenz auflösen: Hiermit kopiert man den Inhalt eines referenzierten
Testbausteins.
* Positionieren: Hiermit stellen man die betreffende Zeile in die erste Aus-
gabezeile der Seite.
Tabelle 7.1
Editorbefehle des Funktionseditors
7.1.2 Blockmodus
Die Zeilen im Funktionseditor können vom Anwender blockweise im so ge-
nannten »Blockmodus« bearbeitet werden. Mit der Funktion Markieren gelangt
er in den Blockmodus, in welchem er ganze Blöcke im Funktionsbildschirm lö-
schen, verschieben, kopieren und ablegen kann. Beim Einstieg ist die ausge-
wählte Zeile der komplette Block, der mit Ende Markieren erweitert werden
kann.
Mit den Funktionen Ablegen und Einlesen kann man Blöcke zwischen Abläufen
austauschen. Der benutzte Puffer bleibt auch über einen Neustart von CATT
oder ein Abmelden hinweg erhalten, gilt aber nur im aktuellen System (dort je-
doch mandantenübergreifend).
158
Sandini Bib
7.2 Spezielle Funktionen von CATT

Folgende Funktionen stehen im Funktionsbildschirm zur Erstellung eines Test-
bausteins bzw. eines Testablaufs zur Verfügung. Dabei handelt es sich um Test-
aktionen, die in einem Testbaustein oder Testablauf integriert und während des
Tests mit ausgeführt werden. Diese Funktionen unterteilt man, je nach Art der
Aufgabenstellung, in drei Gruppen:
◗ Bearbeitungsfunktionen
◗ Steuerungsfunktionen
◗ Prüffunktionen
Bearbeitungsfunktionen
Funktionsname Bedeutung
TCD Transaktion ausführen
REF Testbaustein aufrufen und ausführen
FUN Funktionsbaustein aufrufen und ausführen
TXT Kommentartext eingeben
Tabelle 7.2
Bearbeitungsfunktion von CATT
Steuerungsfunktionen
Kapitel 7 – Funktionen des CATT-Tools

SETVAR Variable mit Werten versorgen
SETVAR Table Variable mit Werten aus Tabellen versorgen
SETTAB Customizing-Tabellen einstellen
RESTAB Customizing-Tabellen zurücksetzen
DO Schleife
ENDDO Beendigung einer Schleife
EXIT Bedingter Abbruch einer Schleife
IF...ENDIF Abhängigkeiten definieren
Tabelle 7.3
Steuerungsfunktionen von CATT
159
Sandini Bib
Prüffunktionen
CHEERR Fehlermeldung aus Transaktion prüfen
CHETAB Datenbankinhalt prüfen
CHEVAR Variableninhalt prüfen
Tabelle 7.4
Prüffunktionen von CATT
7.2.1 Bearbeitungsfunktionen
Transaktion ausführen – TCD

Mit der Funktion TCD gibt man den Transaktionscode der Transaktionen ein,
die im Testbaustein bzw. Testablauf ausgeführt werden sollen. In einem Detail-
Pflegebildschirm werden die benötigten Eingabewerte für jedes einzelne Einga-
befeld aller Bildschirmfelder der zu testenden Transaktion eingegeben.
Testbaustein aufrufen und ausführen – REF

Um einen Testbaustein in einen Testablauf einzubinden, verwendet man die
Funktion REF. Dadurch kann derselbe Testbaustein jederzeit in verschiedenen
Testabläufen referenziert werden. Die Weitergabe der Werte aus den Testbau-
steinen im Testablauf erfolgt über so genannte »Import-« und »Exportparame-
ter«, die im Testbaustein definiert sind und im Testablauf mit Werten bzw. Va-
riablen belegt werden. Die entsprechenden Parameter der Testbausteine werden
auf dem Detailbild der betreffenden Referenz gepflegt. Dort können sowohl fixe
Werte, Variablen als auch Importparameter des Ablaufs als Werte eingegeben
werden. Die Defaultwerte aus dem Testbaustein werden als Übergabewerte vor-
geschlagen und können im Testablauf überschrieben werden.
Funktionsbaustein aufrufen und ausführen – FUN

Mithilfe dieser Funktion wird es dem Anwender auf einfache Weise ermöglicht,
Funktionsbausteine auszuführen, die Werte aus den verschiedenen Bereichen
der Applikationen zur Weiterverarbeitung im Testablauf ermitteln.
Funktionsbausteine stellen dem CATT-Benutzer sowohl allgemeine als auch an-
wendungsübergreifende Funktionalitäten zur Verfügung. Sie unterliegen hin-
sichtlich ihrer inneren Funktionalität keinerlei Einschränkungen. So kann ein
Funktionsbaustein beispielsweise zur Überprüfung von Datenbankeinträgen, zur
Erstellung von Tabellen oder auch zum Löschen von Daten eingesetzt werden.
160
Sandini Bib
Der Aufruf des in den Testablauf bzw. Testbaustein eingebundenen Funktions-

bausteins wird beim Starten jedesmal vom System dynamisch generiert.
Zu beachten ist Folgendes: Werden an einem in Testabläufen eingebundenen
Funktionsbausteinen Änderungen durchgeführt und sollen dementsprechend
die Parameter im Testablauf neu versorgt werden, ist es unbedingt erforderlich,
die CATT-Funktion FUN im betroffenen Testablauf entsprechend zu überarbei-
ten. Eventuelle weitere Änderungen werden durch die dynamisch stattfindende
Generierung der CATT-Schnittstellen automatisch vom System nachgezogen.
Um an eine Übersicht über alle in CATT vorkommenden Funktionsbausteine zu
bekommen, muss das Programm RSCATINI gestartet werden. Nach dem Ab-
lauf dieses Programms erstellt das System ein Protokoll, welches die erfolgten
Generierungen der CALL-Schnittstelle für die vorhandenen Funktionsbaustei-
ne erstellt.
Funktionsbausteine existieren im R/3-System nicht losgelöst von ihrem System-
umfeld. Sie sind ebenso wie auch andere Elemente der verschiedensten SAP-
Anwendungen in eine Hierarchie eingebunden. So sind z.B. mehrere Funkti-
onsbausteine, die logisch zusammen gehören, in einen so genannten »Funkti-
onspool« integriert. Dieser Funktionspool entspricht in etwa dem Modulpool ei-
ner Transaktion. So können die Funktionsbausteine im Großen und Ganzen mit
den einzelnen Modulen verglichen werden.
Eine Auflistung aller im System verfügbaren Funktionsbausteine findet man in
der ABAP/4-Development-Workbench unter »Funktionsbibliothek«. Die Do-
kumentation zur Schnittstelle der Funktionsbausteine findet man beim jeweili-
gen Funktionsbaustein (Transaktion SE37).
Texte eingeben – TXT

Mit der Funktion TXT können Kommentarzeilen eingegeben werden, um Ab-
laufschritte in Stichworten zu kommentieren. Dies ist besonders sinnvoll bei der

Verwendung von Variablen und Parametern, um einen allgemein nutzbaren
Testbaustein bzw. Testablauf für jedermann verständlich zu halten.
7.2.2 Steuerungsfunktionen
Variable versorgen – SETVAR

Variablen werden innerhalb eines Testablaufs oder Testbausteins durch die
Funktion SETVAR mit Werten versorgt. Diese Werte bleiben über den gesamten
Testablauf hinweg erhalten, solange keine erneute Wertzuweisung durchge-
führt wird.
161
Sandini Bib
Variablen mit Werten aus Tabellen versorgen – SETVAR Table

Diese Funktion ermöglicht es, Variablen mit Werten aus Tabellen zu versorgen
oder zu ändern.
Customizing-Tabellen mit CATT einstellen – SETTAB

Customizing-Standardeinstellungen dürfen im R/3-System nur dann verändert
werden, wenn sie innerhalb desselben Ablaufs wieder zurückgenommen wer-
den. Für Änderungen von Customizing-Tabellen sind die CATT-Funktionen
SETTAB und RESTAB zu verwenden. Dabei muss beachtet werden, dass Ände-
rungen in Datenbanktabellen nicht möglich sind. Die ursprünglichen Werte des
geänderten Eintrags werden hierzu in einer internen Sicherungstabelle abgelegt
und können mit RESTAB wiederhergestellt werden. So kann man die Auswir-
kungen der Änderungen von Customizing-Tabellen problemlos überprüfen,
ohne sich um die ursprünglichen Eintragungen sorgen zu müssen. Folgende
Aktionen können mit dieser Funktion ausgeführt werden:
◗ vorhandene Sätze der Tabelle ändern
◗ nicht vorhandene Sätze hinzufügen
Die Funktion SETTAB führt beim Ausführen eines Testablaufs zwar zu einer
Änderung des Tabelleninhalts, sperrt die Tabelle jedoch nicht.
Auf die Funktion SETTAB muss spätestens am Ende des Testablaufs die im fol-
genden beschriebene Funktion RESTAB folgen, damit die verschiedenen Tabel-
len wieder in den korrekten Ausgangszustand rückgeführt werden, weil ansons-
ten die Customizing-Einstellungen dauerhaft verändert blieben.
Die Funktion SETTAB sollte nur dann zum Einsatz kommen, wenn abweichen-
de Einstellungen von Tabellen einer Prüfung unterzogen werden sollen oder
Fehler, die auf bestimmten Einstellungen beruhen, näher untersucht werden
sollen.
Die empfohlene Vorgehensweise lautet:
A In das Feld Funkt. muss zunächst SETTAB und in das Feld Objekt der Tabel-
lenname eingegeben werden.
B Auf der Zeile, in die man SETTAB eingegeben hat, führt man einen Doppel-
klick aus. Dadurch navigiert das System in die Detailpflege. Alle Schlüssel-
felder der Tabelle sind hier aufgelistet.
C In der Detailpflege gibt man den Schlüssel (Argument) in das Felder ARG
der Tabelle vollständig ein.
D Das Tabellenfeld für den Mandanten wird immer mit dem Wert des aktuel-
len Mandanten gefüllt.
E Funktion ALLE FELDER ANZEIGEN ausführen.
162
Sandini Bib
F Um gezielt Felder zu ändern, fügt man am besten nur im Funktionsteil dieser

Felder (FKT) den gewünschten neuen Wert ein.
Zurücksetzen von Customizing-Tabellen mittels CATT – RESTAB

Alle während eines Testablaufs mit SETTAB ausgeführten Änderungen werden
zwischengespeichert. Am Ende des Testablaufs können Tabellenänderungen
mit der Funktion RESTAB zurückgenommen werden. Falls in einem CATT-Ab-
lauf eine CATT-Funktion zum Abbruch des Ablaufs führt, wird danach automa-
tisch die Funktion RESTAB* durchgeführt, die alle in einem Testbaustein oder
Testablauf durchgeführten Tabellenänderungen zurücknimmt. Im Fehlerfall,
d.h., wenn der Testablauf vor Erreichen der Funktion RESTAB abbricht, wird
diese Funktion automatisch angestoßen. Soll allerdings erreicht werden, dass
die SETTAB-Einstellungen nicht zurücksetzt werden sollen, so erreicht man
dies durch Eingabe von RESTAB%.
Die RESTAB-Funktion kann in folgenden Fällen nicht mehr durchgeführt wer-
den:
◗ Eingabe im OK-Code /N durch den Benutzer beim hellen Abspielen einer
Transaktion
◗ Transaktion durchläuft den Befehl LEAVE TO TRANSACTION
◗ Laufzeitfehler in einem aufgerufenen Funktionsbaustein
Schleifenfunktion – DO
Um CATT-Funktionen wiederholt zu starten, können sie in eine Schleife gestellt
werden. Dazu gibt man die Funktion DO in das Feld »Funkt.« und die ge-
wünschte Zahl der Schleifendurchläufe in das Feld »Objekt« auf dem Funktions-
pflegebildschirm ein. Man kann Schleifen setzen, die Wiederholungen zwischen
1 und 999 durchführen. Danach sind die CATT-Funktionen einzutragen, die

wiederholt abgespielt werden sollen.
Beenden einer Schleife – ENDDO

Dieser Befehl beendet eine Schleife in einem CATT-Programm.
Beispiel:
DO 10
REF K12536001
ENDDO
Der referierte Testbaustein K12536001 wird zehnmal ausgeführt. Man kann in

CATT die DO...ENDDO-Schleife und IF...ENDIF-Blöcke beliebig ineinander
verschachteln.
163
Sandini Bib
Abbruch einer Schleife – EXIT

Soll eine Schleife einmal bedingt abgebrochen werden, ist dies mit der Funktion
EXIT zu bewerkstelligen. Dabei wird die Funktion EXIT zwischen DO und
ENDDO angegeben. Bei jedem Durchlauf der Schleife wird die dort genannte
Bedingung überprüft. Falls diese erfüllt ist, wird die Schleife sofort beendet, und
es wird die Anweisung nach dem ENDDO ausgeführt. Dadurch werden sehr
flexible Schleifenkonstruktionen möglich.
Abhängigkeiten definieren – IF...ENDIF

Wenn man z.B. die Ausführung von Funktionen vom Inhalt einer Variablen ab-
hängig machen will, kann man eine Bedingung für deren Ausführung stellen.
Dazu gibt man IF in die Spalte »Funkt.« und die Bedingung in die Spalte »Text«
ein. Die Spalte »Objekt« bleibt frei. Die zwischen IF und ENDIF angegebenen
Funktionen werden nur dann ausgeführt, wenn die Bedingung erfüllt ist.
7.2.3 Prüffunktionen
Fehlermeldung aus Transaktion prüfen – CHEERR

CHEERR bedeutet ausgeschrieben Check Error. Man kann hier überprüfen, ob
eine Transaktion eine erwartete Fehlermeldung ausgibt. Dazu ist die Funktion
CHEERR direkt vor der Funktion TCD einzugeben, welche den Fehler erzeugen
soll. Nach Auftreten des erwarteten Fehlers wird die Transaktion sofort verlas-
sen. Wenn der aufgetretene Fehler mit dem erwarteten Ergebnis identisch ist, so
wird die Transaktion trotz des Fehlers im Protokoll als mit positivem Ergebnis
abgespielt vermerkt. Tritt der erwartete Fehler nicht auf, erscheint im Protokoll
eine Fehlermeldung. Ist das Abbruchkennzeichen im Attributefeld gesetzt,
führt das Ausbleiben eines erwarteten Fehlers zum Abbruch.
Beispiel:
Man erwartet die Fehlermeldung 286 in der Transaktion FB01. Diese Fehlermel-
dung lautet:
»Periode ist für Kontoart& und Hauptbuch& nicht geöffnet.«
Funkt. Objekt
CHEERR 286
TCD FB01
Es gibt in CATT auch eine Anweisung, die alle Fehlernummern zur Fehlermel-
dungsprüfung zulässt. Diese Funktion lautet:
Funkt. Objekt
CHEERR *
164
Sandini Bib
Datenbankinhalt prüfen – CHETAB

CHETAB ist die Abkürzung für Check Tabelle. Diese Funktion bietet dem An-
wender die Möglichkeit, Werte aus Datenbankfeldern zu lesen und damit Daten-
bankfortschreibungen nach der Ausführung von Transaktionen zu überprüfen.
Darüber hinaus kann untersucht werden, ob ein bestimmter Tabelleneintrag vor-
handen ist. Customizing-Tabellen können mittels dieser Funktion auf ihre Kor-
rektheit hin überprüft werden. Falls die Funktion in Einzelfällen unter den ange-
gebenen Werten keinen Eintrag in der entsprechenden Tabelle findet, erfolgt ein
Abbruch des Testablaufs, da CATT von einer Fehlersituation ausgeht. Vorausset-
zung für den Einsatz dieser Funktion ist allerdings, dass CHETAB für die Zugrif-
fe die vollständige Schlüsselangabe benötigt. Ist die Schlüsselangabe nicht kor-
rekt bzw. unvollständig, so werden die nicht gepflegten Schlüsselfelder vom
System automatisch mit den typgerechten Initialwerten gefüllt.
In der Praxis kann durchaus der Fall eintreten, dass eine Selektion nicht nach
den Schlüsselfeldern der Tabelle erforderlich ist, sondern nach anderen Kriterien.
Hier besteht für den Programmierer die Möglichkeit, die Selektion über selbst-
erstellte Funktionsbausteine in den entsprechenden CATT-Testabläufen bzw.
Testbausteinen durchzuführen.
Variableninhalte überprüfen – CHEVAR

Mit dieser Funktion kann der Wert einer Variablen geprüft werden. Ist die an-
gegebene Bedingung nicht erfüllt, wird im Protokoll eine Fehlermeldung einge-
tragen und bei gesetztem Abbruchkennzeichen der Ablauf abgebrochen.
7.2.4 Beispiele mit allen in CATT verwendbaren

Funktionen
Beispiel Nr. 1:

Dieser Testbaustein führt das Customizing der Kreditkontrollbereiche durch.
Dabei wird zunächst ein entsprechender Finanzbeleg gebucht und ein Testbau-
stein K1101032 referenziert, der die Anfrage hierzu angelegt. Nach der Einbin-
dung eines Standardfunktionsbausteins, der zur Ermittlung des Periodenda-
tums dient, werden die Kreditkontrollbereiche per Customizing eingestellt.
Anschließend werden aus der Tabelle BSEG (Belegsegment Buchhaltung) die
Werte zu den Kreditkontrollbereichen abgelesen.
165
Sandini Bib
Funktion Objekt Text
TCD FBO1 Beleg buchen
REF K1101032 Anfrage anlegen
FUN DATE_TO_PERIOD_CONVERT
TXT Dies ist ein Kommentartext
SETTAB T014 Kreditkontrollbereiche
RESTAB T014 Kreditkontrollbereiche
SETVAR &D01 = ´2411&JHR´
SETVAR &V01 + ´1´
SETVAR BSEG Belegsegment Buchhaltung
IF &V01 = ´1´
ENDIF
DO 003
EXIT &V01 = ´2´
ENDDO
CHEERR 286
CHETAB BSEG Belegsegment Buchhaltung
CHEVAR &V01 = ´3´
Beispiel Nr. 2:
In folgendem Beispiel handelt es sich um einen exemplarisch ausgewählten
Standard CATT-Baustein, der von SAP AG mitausgeliefert wird. Dabei wird
zunächst der Fakturabeleg über einen Eingabeparameter in den CATT-Bau-
stein eingelesen. In der Tabelle VBRK werden anschließend die Nettobeträge
einer Prüfung unterzogen. Für den Fakturabeleg, der durch die vorher einge-
lesene Belegnummer identifiziert wird, wird über den Funktionsbaustein
AC_DOCUMENT_RECORD der zugehörige Buchhaltungsbeleg gelesen. An-
hand der Belegnummer im FI wird die entsprechende Tabelle BSEG (Buchhal-
tungssegment) gelesen und die Mahnstufe geprüft. Der CATT-Baustein, der
diese Bedingungen erfüllt, sieht dann wie folgt aus:
166
Sandini Bib
TXT ***** lesen VBRK für die Beträge
CHETAB VBRK Faktura: Kopfdaten
TXT lesen Buchhaltungsbeleg über Faktura-

nummer
FUN AC_DOCUMENT_
RECORD
TXT Ablauf nur, wenn Buchhaltungsbeleg vor-

handen ist
SETVAR VBRK Faktura: Kopfdaten
IF &V02 GT '0000000000'
TXT Prüfungen Buchhaltung für die entspre-

chende Faktura
TXT F2 und LR, da keine weiteren Felder zur

Prüfung anstehen
CHETAB BKPF Belegkopf für Buchhaltung
TXT über Buchhaltungsbelegnr. aus BKPF wird

BSEG gelesen
TXT Hier werden die Mahnsperre, Zahlungsfri-

stenbasisdatum, die Vorbelegnummer und
WRBTR geprüft.

ENDIF
TXT Wenn eine Rechnungsliste erstellt wurde,

so sind die Dateninhalte der VBRL zu prü-
fen.
TXT Geprüft wird der Nettobetrag und die Steu-

er der Fakturen (F2) und
TXT der Delkrederebetrag und die Steuer der

Rechnungsliste (RL)
IF &V01 EQ 'LR'
SETVAR &V18 = '00001'
167
Sandini Bib
CHETAB VBRL Vertriebsbeleg: Rechnungsliste
SETVAR &V18 = '00002'
SETVAR &V18 = '00003'
ENDIF
TXT wird Delkredere bezahlt, wird FI-Beleg vor-

handen geprüft
IF &I21 NE ' '
CHEVAR &V02 NE '
ENDIF.
Beispiel Nr. 3:
Dieser Testbaustein zeigt, wie man per CATT das Customizing für SD-Trans-
porte automatisiert gestalten kann.
TXT Customizing für Transport
TXT ************************************
TXT Transportart 1 festlegen:
IF &I01 <> ''
SETTAB TVTK Transportarten
ENDIF
IF &I09 <> ''
ENDIF
168
Sandini Bib
IF &I09 <> ''
ENDIF
TXT
TXT Transportrelevanz Lieferart 1
IF &I25 <> ''
SETTAB TVLK Lieferungen: Arten
ENDIF
TXT Transportrelevanz Lieferart 2
IF &I26 <> ''
SETTAB TVLK Lieferungen: Arten
ENDIF
TXT
TXT Transportrelevanz Route 1
IF &I27 <> ''
SETTAB TVRO Routen
ENDIF

TXT Transportrelevanz Route 2
IF &I28 <> ''
SETTAB TVRO Routen
ENDIF
TXT alternative Route (in der Lieferung)
TXT zur Route im Auftrag (=00001)
SETTAB TROAL Routen: erlaubte Ist-Routen zur Lieferung
TXT alternative Route (in der Lieferung)
TXT zur Route im Auftrag (=00001)
169
Sandini Bib
SETTAB TROAL Routen: erlaubte Ist-Routen zur Lieferung
Beispiel Nr. 4:
Testbaustein P3005022 SD-Transport: Customizing zurücksetzen
TXT CATT: SD-Transport
TXT Customizing zurücknehmen
TXT Leerzeile
TXT Customzing für Lieferungserzeugung
RESTAB T184 Verkaufsbelege: Positionstypenfindung
TXT Leerzeile
TXT Customizing für Versandelemente
REF P3000681 SD-Transport: Customizing zurücksetzen
TXT Leerzeile
TXT Customizing für Transport
TXT Leerzeile
TXT Transportarten-Tabelle zurücksetzen
RESTAB TVTK Transportarten
TXT Leerzeile
TXT Lieferarten-Tabelle zurücksetzen
RESTAB TVLK Lieferungen: Arten
TXT Leerzeile
TXT Route zurücksetzen
RESTAB TVRO Routen
RESTAB TROAL Routen: erlaubte Ist-Routen zur Lieferung
TXT Leerzeile
170
Sandini Bib
TXT Leerzeile
Beispiel Nr. 5:
Dieser Testbaustein verprobt die Tabelle BSEG (Belegsegment Buchhaltung).
Funkt. Objekt Text
Nach Doppelklick auf BSEG erscheint Folgendes:
Bez. Feldbeschreibung Feldname Typ Lg. Feldinhalt
ARG Mandant MANDT CLNT 003 SY-MANDT
Buchungskreis BUKRS CHAR 004 0001
Belegnummer eines Buch- BELNR CHAR 010 &I01

haltungsbelegs
Geschäftsjahr GJAHR NUMC 004 &JHR

Nummer der Buchungszeile BUZEI NUMC 003 001
FKT Betrag in Belegwährung WRBTR CURR 014 1771.00
Kontonummer des Liefer- LIFNR CHAR 010 &I02

anten
171
Sandini Bib
7.3 Parameter
7.3 Parameter
Die innerhalb des Computer Aided Test Tools zur Verfügung stehenden Para-
meter sind für die Wertübergabe an Testbausteine bzw. Testabläufe verantwort-
lich. In allen betriebswirtschaftlichen Prozessen, welche in Testabläufen bzw.
-bausteinen abgebildet werden, sind in Eingabefeldern verschiedenste Daten
einzugeben. Diese Daten lösen dann im System Berechnungen aus. Die errech-
neten Ergebnisse bilden wiederum die Grundlage für nachfolgende Berechnun-
gen. Deshalb ist es empfehlenswert, Daten in CATT nicht nur als fest vorgege-
bene Werte, sondern mittels definierter Variablen bzw. Parameter zwischen den
einzelnen Bausteinen auszutauschen. Dies erhöht die Flexibilität der Testbau-
steine und -abläufe, wie bereits erwähnt, erheblich. Fast alle CATT-Funktionen
benötigen Eingabewerte und liefern davon abhängig bestimmte Ergebnisse.
Man unterscheidet in CATT folgende Parameter:
7.3.1 Importparameter
Die Werte für die Importparameter werden beim Aufruf eines Testbausteins
oder Testablaufs übergeben und stehen innerhalb eines Testablaufs oder Test-
bausteins lokal zur Verfügung. Die Importparameter werden bei ihrer Definiti-
on bestimmten Feldern als Platzhalter zugeordnet und später im jeweiligen
Testablauf mit Werten versehen. Dem Anwender bietet sich hier die Option, im
Testbaustein für jeden Importparameter dieses Bausteins einen Vorschlagswert
festzulegen, der in jedem Testablauf, der diesen Testbaustein referenziert, als
Voreinstellung vorgeschlagen wird. Bei der Übergabe von Werten während des
Testablaufs werden die Vorschlagswerte überschrieben. Das Vergeben von Vor-
schlagswerten im Testbaustein ist sehr zu empfehlen, weil dadurch der Pflege-
aufwand im referenzierenden Testablauf reduziert wird.
Vorschlagswert Importparameter-Inhalt
'abc' abc
Space nicht definiert auf Bildschirmbild
'' (2 Hochkommata) space
&JHR (Standardvariablen) &JHR-Inhalt
SY-xxxx (Systemvariablen) SY-xxxx Inhalt
172
Sandini Bib
Übergabewert Importparameter-Inhalt
&Vnn, &Dnn (Variablen) &Vnn-Inhalt, &Dnn-Inhalt
' (1 Hochkomma) nicht definiert auf Bildschirmbild, bzw. initial auf Ta-
bellen
(Parameter) &Inn-Inhalt, &Enn-Inhalt (aus rufendem Ablauf bzw.

Testbaustein
%xxx %xxx Inhalt
SY-xxxxx (Systemvariablen) SY-xxxxx Inhalt
Tabelle 7.5
Beispiele, wie ein Vorschlagswert oder Übergabewert im Importparameter
aufgelöst wird
Default Importparameter-Inhalte
(interne Variablen) Wird nicht aufgelöst
(Parameter) Wird nicht aufgelöst
' (1 Hochkomma) Fehler
%xxx (SET/GET-Parameter) Wird nicht aufgelöst
Tabelle 7.6
Obige Variablenverwendungen in Vorschlagswerten können zu Fehlern führen
7.3.2 Exportparameter
Den Exportparametern können die Ergebniswerte eines Testbausteins zugewie-

sen werden. Exportparameter stellen die Exportschnittstelle zu anderen CATT-
Objekten dar. Dadurch können Exportparameter ihre beliebigen Daten nach
Rückkehr aus einem Testbaustein im referenzierenden Testablauf einer Varia-
blen übergeben. Auf Testbausteinebene können beliebig viele Exportparameter
vergeben werden. Auf Testablaufebene steht die Exportschnittstelle von CATT
nicht bzw. nur sehr eingeschränkt zur Verfügung.
7.3.3 Allgemeine Hinweise zu den Import- und

Exportparametern
Hinsichtlich der Namensgebung der Import- und Exportparameter können
zum einen die vom System vorgeschlagenen Parameternamen übernommen
werden. Zum anderen besteht die Option, den Parametern jederzeit andere Na-
men zu geben. Die Einhaltung von Namenskonventionen ist in diesem Kontext
173
Sandini Bib
7.4 Variablen
sehr empfehlenswert, da dies die Übersichtlichkeit und Einheitlichkeit fördert.

Das erste Zeichen des Namens muss immer ein »&« sein. Danach können bis zu
12 weitere Zeichen verwendet werden. Die Anzahl der Import- und Exportpa-
rameter ist unbegrenzt. Sie haben Bezug zum Datenelement und können Daten
mit einer Länge bis zu 132 Bytes aufnehmen.
Die Wertzuweisungen an Variablen oder Parameter können entweder direkt im
Testbaustein bzw. Testablauf definiert werden oder sie erfolgen während des
Ablaufs an Schnittstellen für die Export- bzw. Importparameter. Festwerte wer-
den immer in Großbuchstaben umgesetzt, es sei denn, sie sind in Hochkommata
eingeschlossen. Die Hochkommata werden zum Ausführungszeitpunkt ent-
fernt.
7.3.4 SET/GET-Parameter
Neben dem Lesen aus Tabellen können auf die Datenbankinhalte auch über die
so genannten SET/GET-Parameter zugegriffen werden. Diese beziehen sich auf
die Parameter-ID, welche für manche Datenbankfelder im R/3-System vorhan-
den ist. SET/GET-Parameter beginnen immer mit »%« gefolgt von Großbuch-
staben und sind meist dreistellig. Jedoch können nicht alle Parameter-IDs im
CATT weiterverwendet werden. Die SET/GET-Parameter sollten möglichst
sparsam eingesetzt werden, da die Kapazität des SET/GET-Memorys begrenzt
ist.
7.4 Variablen
Variablen dienen der Wertübergabe innerhalb eines Testbausteins bzw. Testab-
laufs. In CATT können verschiedene Variablentypen in Testbausteinen und Test-
abläufen verwendet werden. Dies können sowohl intern vereinbarte Variablen
als auch Bezugnahmen auf im System verfügbare Variablen sein. Folgende Va-
riablentypen können dabei vom Anwender genutzt werden:
◗ Message-Variablen
◗ lokale Variablen
◗ Textvariablen
◗ SET/GET-Parameter/Parameter-IDs
◗ Systemvariablen
◗ Sondervariablen
◗ Datumsvariablen
174
Sandini Bib
7.4.1 Message-Variablen
Transaktionen geben nach erfolgreicher Bearbeitung eine Dialogmeldung an
den Benutzer, die mit Hilfe der Message-Variablen abgefragt werden können.
Diese Dialogmeldungen sind systemintern in der Tabelle T100 zu finden. Da
diese Systemmeldungen maximal vier variable Anteile beinhalten können, ste-
hen in CATT-Objekten demnach auch vier Message-Variablen zur Verfügung.
Anhand dieser Message-Variablen können folglich die zur Laufzeit variablen
Werte übergeben werden wie z.B. Beleg- bzw. Stammsatznummern. Message-
Variablen beginnen immer mit &M gefolgt von einer zweistelligen Nummer
(01-04). Dabei bezieht sich die Variable &M01 auf den ersten variablen Anteil ei-
ner Systemmeldung, die Variable &M02 auf den zweiten usw. Wenn man die In-
halte dieser Messagevariablen weiterverwenden möchte, sind diese an interne
Variablen oder Exportparameter zu übergeben.
7.4.2 Lokale Variablen

Lokale Variablen werden in CATT-Abläufen eingesetzt, um Berechnungen
durchzuführen oder Werte von Exportparametern aus referenzierten Testbau-
steinen oder aufgerufenen Funktionsbausteinen zu übernehmen. Diese lokalen
Variablen werden während des Ablaufs eines Tests durch die verschiedenen
CATT-Funktionen mit Werten versorgt. Die maximale Länge einer solchen Va-
riablen beträgt zwanzig Zeichen. Lokale Variablen sind das Transportmedium
zwischen dem Exportparameter des Testbausteins, welcher Daten zur Weiter-
gabe berechnet, und dem Importparameter des Testbausteins, welcher diese Da-
ten für seine eigenen Berechnungen als Basis benötigt.
7.4.3 Textvariablen
Mithilfe dieser Variablen können sprachabhängige Felder in CATT gestaltet

werden. Pro CATT-Objekt stehen 99 Textvariablen mit einer Länge von 50 Zei-
chen zur Verfügung. Dabei können die Inhalte der Variablen an Bildschirmbil-
der, Funktionsbausteine oder Tabellen übergeben werden. Sollte das Zielfeld
kürzer als 50 Zeichen sein, werden die darüber hinausgehenden Zeichen abge-
schnitten. Die Textvariablen werden von dem Übersetzungswerkzeug erkannt
und können in die benötigten Sprachen übersetzt werden.
7.4.4 SET/GET-Paramter/Parameter-Ids
Innerhalb des Testablaufs besteht die Möglichkeit, auf die im benutzerspezifi-
schen Bereich abgelegten SET/GET-Parameter in der Länge von 50 Zeichen zu-
zugreifen. Auf Werte von definierten SET/GET-Parametern kann über deren
Parameter-Ids (%<set/get>) zugegriffen werden.
175
Sandini Bib
7.4 Variablen
7.4.5 Systemvariablen
Die Systemfelder werden vom R/3-System zur Laufzeit mit verschiedenen ak-
tuellen Werten gefüllt. Einige sind von erheblicher Bedeutung, da sie Auskunft
über den jeweiligen Systemstatus liefern. Andere dienen nur der Kommunika-
tion diverser Basisprogramme untereinander. Systemvariablen liefern Informa-
tionen, die vom System zur Verfügung gestellt werden. Im CATT kann man da-
für alle SY-Felder des Systems nutzen. Die Namen der vorhandenen SY-Felder
erhält man über die Datenbanktabelle SYST.
SETVAR &V01 = SY-LANGU
Hier wird der Systemvariablen &V01 die jeweilige Anmeldesprache des An-
wenders zugewiesen.
Beispiele für in CATT nutzbare Systemfelder sind:
◗ SY-LANGU (Anmeldesprache):
Dieses Feld wird bei Anmeldung eines Anwenders mit dem Kürzel für die
jeweils, aktuelle Sprache gesetzt. Anhand dieses Feldes ermitteln viele sys-
teminterne Hilfsmittel die korrekten sprachabhängigen Texte und Nachrich-
ten.
◗ SY-UZEIT (aktuelle Uhrzeit):
Dieses Feld wird vom System mit der aktuellen Uhrzeit versorgt.
◗ SY-DATUM (aktuelles Datum):
Dieses Feld wird bei der Anwendung mit dem aktuellen Tagesdatum gefüllt.
◗ SY-UNAME (Benutzername):
In dieses Feld wird bei der Anmeldung am System der Anmeldename des
Anwenders eingetragen. Dieser Name wird beispielsweise von der Berechti-
gungsprüfung genutzt.
◗ SY-SUBRC (korrekte Programmausführung):
Es handelt sich hierbei um das am häufigsten benutzte Systemfeld. Es beinhal-
tet nach der Ausführung vieler Anwendungen einen konkreten Wert, der de-
taillierte Auskunft über die richtige Abarbeitung dieses Kommandos gibt.
7.4.6 Sondervariablen
Außer den allgemeinen Systemvariablen können auch CATT-eigene Sonderva-
riablen genutzt werden, um Daten des R/3-Systems abzurufen. Sondervaria-
blen können dabei direkt in ein Literal (Zeichenkette) eingebunden werden.
Nicht möglich ist hier jedoch die Angabe von Offset und Länge der jeweiligen
Variablen, z.B. &M01-02(08).
176
Sandini Bib
Folgende Sondervariablen können voneinander unterschieden werden:

◗ Mandant &MND
In allen Tabellenfunktionen in CATT mit mandantenabhängigen Tabellen
trägt man im Mandantenfeld &MND ein und erhält so beim Start des Testab-
laufs den aktuellen Mandanten. Es handelt sich um den gleichen Inhalt wie
bei der Systemvariablen SY-MANDT.
◗ Systemdatum &DAT
Das Datum wird in &DAT (siehe Datumsvariablen) im externen Format ohne
Aufbereitungszeichen zur Verfügung gestellt. Welches externe Format wirk-
sam ist, definiert man als Festwert im Benutzerstammsatz. Im Gegensatz zu
&DAT enthält SY-DATUM immer das interne Format: JJJJMMTT.
◗ Benutzername &NAM
Diese Sondervariable hat den gleichen Inhalt wie die Systemvariable SY-UNAME.
◗ Jahresangaben
Folgende Variablen stehen hier zu Verfügung:
◗ &JHV vorhergehendes Jahr
◗ &JHR aktuelles Jahr
◗ &JHN nachfolgendes Jahr
◗ Aktueller Loopdurchlauf (Loopcounter) &LPC:
Innerhalb von DO/ENDDO -Schleifen wird der jeweils aktuelle Wert der
innersten Loop-Schleife in der Variablen &LPC zur Verfügung gestellt.
Die Eingaben der jeweiligen Sondervariablen müssen in Großbuchstaben erfolgen.
7.4.7 Datumsvariablen
Mit Datumsvariablen können z.B. verschiedene Termine berechnet werden. Das
Addieren und Subtrahieren von Tagen ist mit den Datumsvariablen automa-

tisch datumsgerecht möglich, d.h., es erfolgt jeweils der Übergang zum darauf-
folgenden Monat bzw. Jahr.
Folgende Datumsformate können verwendet werden:
Internes Format: JJJJMMTT
Externe Formate mit und ohne Aufbereitungszeichen:
TT.MM.JJJJ TTMMJJJJ
MM/TT/JJJJ MMTTJJJJ
MM-TT-JJJJ MMTTJJJJ
JJJJ.MM.TT JJJJMMTT
JJJJ/MM/TT JJJJMMTT
Im Benutzerstammsatz (Festwerte) wird definiert, welches externe Format für
den Anwender wirksam sein soll.
177
Sandini Bib
7.4 Variablen
Setzen von Datumsvariablen

Auf folgende Weise können Datumsvariablen gesetzt werden:
◗ über einen Direktwert mit Datum in beliebigem Format
(das Datum wird dabei auf Gültigkeit hin geprüft)
◗ aus einem SY-DATUM Feld. Beim Feld SY-DATUM wird das Feld bei der
Anwendung automatisch mit dem jeweiligen Tagesdatum gefüllt.
◗ aus der CATT-Sondervariablen &DAT
◗ aus anderen Datumsvariablen &Dnn
◗ aus beliebigen sonstigen CATT-Variablen mit Datum in beliebigem Format
◗ aus Exportparametern eines Testbausteins
Übergeben von Datumsvariablen

Das Ergebnis einer Zuweisung an eine Nicht-Datumsvariable erscheint immer
im externen Format. Für Importparameter, die Datumseinträge verwenden,
empfiehlt es sich, diese intern auf Datumsvariablen zu übertragen und auf Dyn-
pros zu plazieren, da die Testabläufe sonst je nach benutzerspezifischer Da-
tumsdarstellung auf einen Fehler laufen könnten.
Arithmetische Operationen mit Datumsvariablen

Folgende arithmetische Operationen können mit Datumsvariablen durchge-
führt werden:
A Datumsrechnung:
Ist der erste Operand vom Typ DATE (&Dnn, &DAT, SY-DATUM), der zweite
Operand von anderem Typ (&Vnn, &Inn, Direktwert n, etc.) mit numerischem
Inhalt, so wird eine Datumsrechnung durchgeführt, d.h., das Datum im ersten
Operanden wird um die im zweiten Operanden angegebene Zahl von Tagen
hochgezählt.
SETVAR &D01 = SY-DATUM + ‚30‘
&D01 = 19931215 + 30
&D01 = 19940114
SETVAR &V01 = ‚5‘

&V01 = 5
SETVAR &D02 = &D01 - &V01

&D02 = 19940114 - 5
&D02 = 19940109
178
Sandini Bib
B Tagesdifferenzen:
Sind beide Operanden vom Typ DATE (&Dnn, &DAT, SY-DATUM) und ist das
Ergebnis keine Datumsvariable (z.B. &V01, &I01, usw.), so werden bei der Sub-
traktion positive und negative Tagesdifferenzen ermittelt.
Prüfen und Vergleichen von Datumsvariablen

Beim Prüfen und Vergleichen von Datumsvariablen müssen die Bedingungen
für das Ausführen nachfolgender CATT-Funktionen (IF...ENDIF), für das vor-
zeitige Beenden (EXIT) einer DO/ENDDO-Schleife und die Prüfbedingungen
für Inhalte von Variablen (CHEVAR) in der üblichen Form (<Variable1> <Ope-
rand> <Variable2>) angeben werden. Ist mindestens eine der beiden Variablen
eine Datumsvariable, so findet ein Datumsvergleich statt. Dabei wird zunächst
die zweite Nicht-Datumsvariable oder ein Direktwert automatisch in das Da-
tumsformat konvertiert.
SETVAR &D01 = ‚31011994‘
&D01 = 19940131
CHEVAR &D01 < SY-DATUM

19940131 < 19940117
Bedingung (&D01 < SY-DATUM) nicht erfüllt
7.4.8 Verwendungsnachweis von Parametern und

lokalen Variablen
Auf dem Parameterpflegebild der CATT-Pflegetransaktion kann für die benutzten
Parameter und Variablen ein Verwendungsnachweis durchgeführt werden. Als
Resultat erhält man hier einen Überblick über das CATT-Objekt. Dabei sind die

Stellen, an denen der Parameter oder die lokale Variable benutzt werden, farblich
hervorgehoben. Diese Übersichtsdarstellung kann natürlich auch ausgedruckt
werden. Auf der Druckerausgabe sind die Verwendungsstellen fett gedruckt.
7.5 Startbild (Einzelstart)

Um per CATT Testbausteine und Testabläufe zu starten, hat man mehrere
Möglichkeiten:
◗ Einzelstart
◗ Massenstart
◗ Remote Start
179
Sandini Bib
7.5 Startbild (Einzelstart)
7.5.1 Einzelstart
Der Testablauf bzw. Testbaustein wird direkt aus der Pflegetransaktion über ein
Startbild gestartet, in dem man Angaben zum Ablauf eingeben kann.
7.5.2 Massenstart
Hiermit können mehrere Testabläufe und Testbausteine hintereinander gestar-
tet werden. Details hierzu werden in den Erläuterungen zum CATT-Manage-
ment geschildert.
7.5.3 Remote Start

Testabläufe können über die Angabe einer RFC-Destination remote in einem an-
deren R/3- oder R/2-System gestartet werden.
Der Startbildschirm enthält die Laufbedingungen (Protokollart, Abspielmodus,
Varianten) und führt einen Testablauf bzw. Testbaustein aus.

CATT-Startbildschirm
180
Sandini Bib
7.5.4 Abspielmodus
Ein Testablauf bzw. Testbaustein kann einzeln gestartet werden. Falls für einen
Testablauf Varianten vorliegen, hat man die Option, im Startbild auszuwählen,
ob und gegebenenfalls welche Variante(n) gestartet werden soll(en). Der Ab-
spielmodus wirkt sich nur auf das Abspielen von Transaktionen in der CATT-
Funktion TCD aus.
Helles Abspielen
Der Ablauf wird vollständig im Dialog ausgeführt. Es besteht die Möglichkeit,
Feldeingaben zu korrigieren oder durch Eingabe von OK-Codes den Ablauf zu
beeinflussen. Mit (¢) gelangt man auf das Folgebild.
Dunkles Abspielen
Die Transaktionen laufen ohne jeden Dialog im Hintergrund ab. Der Anwender
kann den Ablauf der Transaktion am Bildschirm nicht verfolgen.
Nur Fehler anzeigen

Die Transaktionen laufen in diesem Modus nur bis zum ersten Auftreten eines
Fehlers oder Abbruchs ohne Dialog. Danach wird auf Dialog umgeschaltet. Nun
kann man bei Bedarf eine fehlerhafte Eingabe ändern. Nach Bestätigung der
Eingabe läuft die Transaktion wieder ohne Dialog weiter bis zum nächsten auf-
tretenden Fehler. Jeweils am Ende des Testlaufs wird das gewünschte Protokoll
erstellt, sofern im Startbild nicht das Kennzeichen »ohne Protokoll« gesetzt wur-
de. Das System springt direkt in eine Anzeige, die ein Kurzprotokoll liefert,
wenn im Testablauf keine Fehler entdeckt wurden. Bei einem Fehler erhält man
ein Langprotokoll ab dem Baustein, in dem der Fehler auftrat.

Protokollart
Hier kann der CATT-Anwender durch eine entsprechende Markierung ent-
scheiden, ob nach Beendigung des Testbausteins bzw. -ablaufs vom System ein
kurzes oder ein langes Protokoll erstellt werden soll. Er kann darüber hinaus auf
die Generierung eines Protokolls ganz verzichten.
7.6 Varianten
Durch entsprechende Markierungen in diesem Teil des Startbildschirms kann
der Anwender in den Start des Testbausteins bzw. -ablaufs Varianten einbin-
den. Dabei kann vom R/3-System auf alle oder auch nur auf spezielle, ausge-
wählte Varianten zugegriffen werden.
181
Sandini Bib
7.7 CATT im Repository-Informationssystem
7.7 CATT im Repository-Informationssystem

Sämtliche Attribute und verwendeten Objekte der angelegten Testabläufe und
Testbausteine werden im Repository-Informationssystem verwaltet. Dies er-
möglicht eine gezielte Suche nach Bausteinen oder Abläufen, die bestimmte,
vom Benutzer vorgegebene Kriterien erfüllen.

CATT-Repository-Informationssystem
182
Sandini Bib
Einführung in die
Bedienung von CATT
8
8.1 Voraussetzungen
Die hier angegebenen Beispielszenarien sind so nur im entsprechend gepflegten
SAP-System »KBC, Mandant 099« ablauffähig. Sollen diese Szenarien in einem
anderen R/3-System bzw. Mandanten ausgeführt werden, gilt es die hier ange-
gebenen Stammdaten durch die entsprechenden Stammdaten des ausführen-
den Systems bzw. Mandanten zu ersetzen. Das verwendete R/3-System muss
dabei den Releasestand 3.1g oder höher besitzen. Des Weiteren müssen für den
entsprechenden Benutzer die Berechtigungen zum Pflegen und Ausführen von
CATT-Objekten eingerichtet sein. Bei diesbezüglichen Problemen ist der Sys-
temverwalter zu konsultieren.
Anhand des nachfolgenden Beispiels werden nun die grundsätzlichen Funktio-
nen des Computer Aided Test Tools erläutert.
8.2 Beispiel
Zunächst sollen Bewegungsdaten über die Transaktion Anlegen Kreditor (Trans-
aktionscode »FK01«) aus dem R/3-Modul FI eingegeben und anschließend über
die Transaktion Kreditor ändern (FK02) korrigiert werden. Am Beispiel der
Transaktion Anlegen Kreditor wird zunächst veranschaulicht, wie ein Testbau-
stein anzulegen ist. Später wird dieser Testbaustein zusammen mit einem wei-
teren Testbaustein dazu verwendet, um einen komplexen Testablauf zu erstel-
len. Über Varianten und die dazugehörigen Importparameter können konkrete
Werte zugeordnet werden, so dass der Testablauf mehrere Kreditoren gleichzei-
tig anlegt und auch wieder ändert. In Abschnitt 8.4.4. wird erläutert, wie die
konkreten Eingabewerte aus einem externen Tabellenkalkulationsprogramm
gelesen werden. CATT kann auch zur Pflege von Customizing-Tabellen ver-
wendet werden. An diversen Beispielen soll dies in Abschnitt 8.5 demonstriert
183
Sandini Bib
8.3 Einfacher CATT
werden. In Abschnitt 8.6 werden die sonstigen Funktionen des Computer Aided
Test Tools beschrieben wie z.B. Suchen, Übersetzen und Transportieren von
CATTs. Der Remote Start von CATT-Abläufen, diverse Problembehandlungen
und das Arbeiten mit dem CATT-Protokoll-Archiv werden darüber hinaus the-
matisiert.
8.3 Einfacher CATT

Das Anlegen von Testbausteinen erfolgt über die bereits beschriebene komfor-
table Aufzeichnungsfunktionalität von CATT. Dabei werden die Bildschirm-
abfolge (auch »Dynproabfolge« genannt) der jeweiligen Transaktion und die
Eingaben des Benutzers auf den einzelnen Bildschirmbildern (Dynpros) aufge-
zeichnet.
A Nach erfolgter Anmeldung im R/3-System (mindestens Releasestand 3.1 G)
ist zum Einstieg folgender Menüpfad zu wählen: WERKZEUGE p ABAP/4
WORKBENCH. Dadurch gelangt man in die ABAP/4 Development Work-
bench. Die ABAP/4 Development Workbench ist die grafische Program-
mier- und Entwicklungsumgebung im Rahmen des R/3-Systems, wie in
Kapitel 3 bereits beschrieben wurde. Sie beinhaltet die verschiedenen Pro-
grammierwerkzeuge, die einem Entwickler innerhalb des R/3-Systems zur
Verfügung stehen.
B Es erscheint nun ein Dynpro, welches den Einstiegsbildschirm der ABAP/4
Development Workbench zeigt. Hier kann man die verschiedenen Werkzeu-
ge der ABAP/4 Development Workbench aufrufen wie z.B. den Object
Browser, das Dictionary, den ABAP/4-Editor, die Funktionsbibliothek usw.
C Um aus obigem Dynpro in das Computer Aided Test Tool zu gelangen, ist
jetzt folgender Menüpfad zu wählen: TESTp TEST WORKBENCHp CATT-AB-
LÄUFE.
D Daraufhin verzweigt das R/3-System das Einstiegsbild von CATT (siehe Ab-
bildung 8.1). Hier legt der Anwender fest, ob er einen neuen CATT-Testab-
lauf bzw. -baustein anlegen oder einen bereits angelegten CATT anzeigen,
starten oder ändern möchte.
184
Sandini Bib

Einstiegsbildschirm von CATT
8.3.1 Textbaustein anlegen

A Zum Aktivieren der Aufzeichnungsfunktionalität von CATT muss der But-
Kapitel 8 – Einführung in die Bedienung von CATT

ton Aufzeichnen angeklickt werden.
B Daraufhin erscheint ein Dialogfeld, in das nun der Transaktionscode der je-
weiligen Transaktion, welche als Testbaustein aufgezeichnet und angelegt
werden soll, einzutragen ist. Folgender Transaktionscode ist nun einzuge-
ben: FK01 Kreditor anlegen. Zur Ermittlung des entsprechenden Transaktions-
codes der abzubildenden Transaktion verzweigt man zunächst in die An-
wendungsebene der Transktion im R/3-System. Über den Menüpfad
SYSTEMpSTATUS kann dann der zugehörige Transaktionscode abgelesen wer-
den. Abbildung 8.2. zeigt den Transaktionscode FK01 zur Transaktion Kredi-
tor anlegen.
C Mit der (¢)-Taste oder durch Anklicken des grünen Hakens navigiert man
in das folgende Bildschirmbild (Abbildung 8.3). Dort füllt man nun folgende
Felder aus:
◗ Buchungskreis: 1401
◗ Kontengruppe: KRED
185
Sandini Bib
8.3 Einfacher CATT

Statusbildschirm des R/3-Systems

Transaktionsbildschirm – Einstieg Buchhaltung
186
Sandini Bib
D Die Kontengruppe KRED steht dabei für die interne Nummernvergabe beim
Anlegen eines Kreditors im R/3-System. Daher muss das Feld Kreditor nicht
gefüllt werden. Nach Abschluss der Transaktion erzeugt das R/3-System
selbständig eine entsprechende Kreditorennummer. Die Felder Vorlage – Kre-
ditor und Vorlage – Buchungskreis müssen hier nicht gefüllt werden, da hier
keine Kreditor mit Bezug auf einen anderen angelegt werden soll.
E Die Eingaben sind nun mit (¢) oder durch Anklicken des grünen Hakens
auf dem Dynpro oben links zu bestätigen.
F Daraufhin verzweigt das System zum Eingabebildschirm »Kreditor anlegen:
Anschrift« (siehe Abbildung 8.4).

Transaktionsbildschirm – Anschrift des Kreditors
Folgende Daten werden hier eingetragen:

◗ Anrede: Firma
◗ Name: Test AG
◗ Suchbegriff: Test AG
◗ Straße: Carl-Zeiss-Ring 4
◗ Ort: Ismaning
◗ Postleitzahl: 85737
187
Sandini Bib
8.3 Einfacher CATT
◗ Land: DE
◗ Sprache: D
Diese Eingaben müssen erneut bestätigt werden.
Es erscheint das Dynpro »Kreditor anlegen: Steuerung« (Abbildung 8.5).
Hier ist die Umsatzsteuer-Identifikationsnummer (UST-ID.Nr) des Kreditors
einzugeben:
UST-ID.-Nr. DE123456789

Transaktionsbildschirm – Steuerung
G Die Eingaben sind wiederum mit (¢) oder durch Anklicken des grünen Ha-
kens auf dem Dynpro oben links zu bestätigen. Auf dem folgenden Dynpro
»Kreditor anlegen: Zahlungsverkehr« werden keine Eintragungen vorge-
nommen.
H Bitte nochmals mit (¢) oder durch Anklicken des grünen Hakens auf dem
Dynpro oben links bestätigen.
188
Sandini Bib
I Auf dem Folgebildschirm »Kreditor anlegen: Kontoführung Buchhaltung«

(siehe Abbildung 8.6) werden folgende Daten zum Abstimmkonto eingetra-
gen:
◗ Abstimmkonto: 160000

Transaktionsbildschirm – Kontoführung
J Die Eingaben müssen nun erneut bestätigt werden. Das Dynpro »Kreditor
anlegen: Zahlungsverkehr Buchhaltung« erscheint nun (vgl. Abbildung 8.7).
Hier ist folgende Zahlungsbedingung einzugeben:
◗ Zahlungsbedingung: ZB01
K Um in das Folgedynpro »Kreditor anlegen: Korrespondenz Buchhaltung«
(Abbildung 8.8) zu gelangen, ist es erforderlich, die eingegebenen Daten hier
zu bestätigen. Hier werden folgende Daten zum Mahnverfahren ergänzt:
◗ Mahnverfahren: 0001
189
Sandini Bib
8.3 Einfacher CATT

Transaktionsbildschirm – Zahlungsverkehr

Transaktionsbildschirm – Korrespondenz
190
Sandini Bib
L Bitte mit (¢) oder durch Anklicken des grünen Hakens auf dem Dynpro
oben links bestätigen. Die Daten müssen nun gesichert werden.
Nachdem diese Transaktion abgeschlossen wurde, verzweigt das System au-
tomatisch auf den in Kapitel 6 bereits näher beschriebenen Attributspflege-
bildschirm der CATT-Pflegetransaktion (siehe Abbildung 8.9). Hier hat man
die Möglichkeit, die durch die Aufzeichnung generierten Attribute zu über-
prüfen und, falls notwendig, entsprechend abzuändern. Während der Auf-
zeichnung des Testbausteins wurden bereits alle notwendigen Attribute au-
tomatisch vom R/3-System gepflegt.

CATT-Attributspflegebildschirm
Wenn nun die Aufzeichnung des Testbausteins sowie die Attributspflege be-
endet sind, kann man fortfahren.
M Anschließend wählt man den Menüpfad TESTABLAUF p PRÜFEN, um den an-
gelegten Testbaustein einer Syntaxprüfung zu unterziehen. Nach erfolgrei-
cher Syntaxprüfung erfolgt in der blauen Statuszeile des Attributspflegebild-
schirms eine entsprechende Meldung des Systems: Syntaxprüfung wurde
erfolgreich abgeschlossen.
N Nun ist der Testbaustein über den Menüpfad TESTABLAUFpSICHERN zu spei-
chern und das darauffolgend erscheinende Dialogfeld wie folgt zu ergänzen:
◗ Entwicklungsklasse BCAT
191
Sandini Bib
8.3 Einfacher CATT
Eine komplexe Anwendung in der ABAP/4 Development Workbench be-

steht aus vielen verschiedenen Entwicklungsobjekten. Für alle Elemente ei-
ner Anwendung verwendet man als gemeinsamen Oberbegriff den Begriff
der Entwicklungsklasse. Durch die Entwicklungsklasse wird das Zielsystem
für einen eventuellen Export bestimmt; ebenso bestimmt die Entwicklungs-
klasse die Transporteigenschaften der in ihr enthaltenen Objekte. Alle Ent-
wicklungsobjekte in der ABAP/4 Development Workbench können anhand
des Object-Browsers angezeigt werden. Eine Entwicklungsklasse sollte vor
Beginn einer Entwicklung angelegt werden. Dafür müssen den Benutzern
aber die entsprechenden Berechtigungen zugewiesen werden.
O Nun ist Lokales Objekt anzuklicken. Dadurch wird der Testbaustein als loka-
les Objekt im R/3-System angelegt. Derartige Objekte werden außerhalb des
SAP-Korrektur- und Transportwesens bearbeitet. Das heißt, lokale Objekte
können nicht mit den Instrumenten des Korrekturwesens gegen die Bearbei-
tung und Veränderung durch Dritte geschützt werden. Sie können auch
nicht transportiert werden. Der einzige Schutz eines lokales Objekts besteht
in der Sperre des Objekts während der direkten Bearbeitung mit dem CATT-
Werkzeug.
Hinweis: Hier ist es aus Vereinfachungsgründen empfehlenswert, sich gleich an
dieser Stelle die Nummer des vorstehend erstellten Testbausteins zu notieren.
Dies erleichtert es, ihn später wiederzufinden. Es besteht aber auch jederzeit die
Möglichkeit, den Testbaustein über das Repository-Informationssystem anhand
bestimmter Suchkritieren zu ermitteln. Dieser Aufwand kann allerdings durch
den Vermerk der Testbausteinnummer sofort nach dessen Erstellung vermie-
den werden.
Im Folgenden wird der Testbaustein unter der Bezeichnung »KBC02106« refe-
renziert. Die Testbausteinnummer wird als Erfolgsmeldung in der Statuszeile
nach dem Sichern angegeben.
Nach Beendigung der Aufzeichnung der Transaktion Kreditor anlegen, ver-
zweigt das R/3-System am Ende der letzten Übung automatisch auf den Pflege-
bildschirm Computer Aided Test Tool: Einstieg (siehe Abbildung 8.10). Durch die
Eingabe der Nummer eines Testbausteins bzw. eines Testablaufs kann man sich
hier den entsprechenden Testbaustein bzw. -ablauf anzeigen lassen bzw. in den
Änderungsmodus wechseln. Dabei besteht die Option, eine der drei Teilsichten
Funktionen, Parameter und Attribute der Pflegetransaktion nach Bedarf auszu-
wählen und vom System sich anzeigen zu lassen. Durch Markierung der ent-
sprechenden Zeile sowie durch anschließendes Betätigen des Buttons ANZEIGEN
bzw. ÄNDERN kann zu den einzelnen Teilsichten navigiert werden.
192
Sandini Bib
8.3.2 Testbaustein anzeigen

A Nun soll der erstellte Testbaustein KBC02106 angezeigt werden. Um in den
Testbaustein zu verzweigen, ist nun der bereits bekannte Menüpfad W ERK-
ZEUGEpABAP/4 WORKBENCH zu wählen.
B Im zweiten Schritt navigiert man über pTESTp TEST WORKBENCHp CATT-AB-

LÄUFE in den Einstiegsbildschirm von CATT.
C In diesem bereits erwähnten Einstiegsbildschirm von CATT ist die Nummer

des vorstehend angelegten Testbausteins Kreditor anlegen einzutragen:
◗ Testablauf: KBC02106
Falls die Nummer des Testbausteins nicht bekannt ist, kann man, sich über
die Suche im so genannten Repository-Informationssystem sämtliche Testbau-
steine und auch -abläufe, abhängig von zuvor eingegebenen Kriterien, anzei-
gen lassen. Als Suchkriterium kann z.B. der Verantwortliche XY eingetragen
werden. Das System sucht nun, nachdem man den Befehl Ausführen gegeben
hat, nach allen Testbausteinen und -abläufen, welche vom Verantwortlichen
XY im Laufe der Zeit angelegt wurden. Selbstverständlich kann die Suche
nach einem Testbaustein bzw. -ablauf auch anhand anderer einzelner oder
mehrerer kombinierter Kriterien gestaltet werden.
In den Eingabebildschirm des Repository-Informationssystems navigiert
man über die Match-Code-Suche des Eingabefeldes Testablauf. Dort drückt
man auf den nach unten gerichteten Pfeil. Damit gelangt man in ein Eingabe-
dynpro des Respository-Informationssystems, in welchem nun die jeweili-
gen Suchkriterien eingegeben werden können. Nach erfolgreich verlaufener

Suche erscheint ein Dynpro, das alle im System verfügbaren Testbausteine
und Testabläufe des Verantwortlichen XY auflistet.
Nun markiert man den gewünschten Testbaustein bzw. -ablauf, den man
sich ansehen bzw. ändern möchte, mit dem Cursor und klickt anschließend
den grünen Haken am unteren linken Rand des Dynpros an. Daraufhin er-
scheint wieder der CATT-Einstiegsbildschirm, der nun die Nummer des ge-
wählten Testbausteins bzw. -ablaufs enthält.
D Wenn man jetzt auf dem Startbildschirm die Auswahl Funktionen markiert
und dann das Button ANZEIGEN anklickt, erscheint der Funktionsbildschirm
von CATT (siehe Abbildung 8.11).
Um Testbausteine und -abläufe effektiv erstellen zu können, ist es wichtig, mit
sämtlichen Funktionen, die dieser Funktionsbildschirm bietet, vertraut zu sein.
Der Funktionseditor und auch die einzelnen Funktionen wurden bereits näher
beschrieben. Auf diese Ausführungen sei hier verwiesen. Falls man auf diesem
Bildschirm das Button PARAMETER anklickt, verzweigt man in die Anzeige von
Import- und Exportparametern sowie Variablen zum Testbaustein KBC02106.
Im Rahmen dieses Testbausteins sind allerdings noch keine Parameter und Va-
193
Sandini Bib
8.3 Einfacher CATT
riablen angelegt. Auf entsprechende spätere Ausführungen (siehe Kap. 8.3.3)

sei an dieser Stelle verwiesen. Über den Button ATTRIBUTE navigiert man von
hier aus in den Attributspflegebildschirm dieses Testbausteins.
Dieser Funktionsbildschirm enthält in der ersten Zeile die Funktion TCD so-
wie als Objekt den Transaktionscode FK01. Durch diese Zeile wird in CATT
die Funktion Transaktion FK01 ausführen und aufzeichnen aktiviert. Wenn man
nun im Feld Objekt einen Doppelklick ausführt, erreicht man das Dynpro An-
zeigen Details Funktionen TCD Testbaustein KBC00268 (Abbildung 8.12), das
alle Bildschirmbilder der Reihe nach auflistet, die während der Aufzeich-
nung der Transaktion FK01 vom System durchlaufen wurden.

Einstiegsbildschirm von CATT
194
Sandini Bib

Funktionsbildschirm von CATT

Detailbildschirm von CATT
195
Sandini Bib
8.3 Einfacher CATT
Durch Positionierung des Cursors auf eine dieser Zeilen und anschließen-
dem Doppelklicken oder nach Aktivierung der Funktionstaste AUSWÄHLEN
(= Symbol Lupe), erhält man Gelegenheit, die Pflege der bei der Transakti-
onsaufzeichnung eingegebenen Festwerte über eine Liste aller Felder direkt
auf dem betreffenden Dynpro vorzunehmen.
Mithilfe der Buttons VORIGE SEITE und NÄCHSTE SEITE ist es möglich, auf die-
sem Bildschirm die einzelnen Seiten zu durchblättern.
Durch Anklicken der Taste FELDLISTE navigiert man zum Dynpro Anzeigen
Eingabewerte SAPMF02K 0105 (vgl. Abbildung 8.13). Die Ziffernfolge »0105«
ist die systeminterne Nummer des Dynpros. Dieses Dynpro listet sämtliche
auf dem Dynpro befindlichen Eingabewerte auf. Diese Eingabewerte, auch
Festwerte genannt, wurden bei der Aufzeichnung der Transaktion aufge-
zeichnet. Sie werden auf den einzelnen Dynpros als Vorschlagswerte gezeigt.
Da es sich bei den aufgezeichneten Werten, wie bereits gesagt, nur um Vor-
schlagswerte handelt, können sie je nach Bedarf geändert werden.

Feldwertebildschirm von CATT
Man sieht hier, dass im ersten Dynpro die Feldinhalte von Buchungskreis
und Kontengruppe genau jenen entsprechen, welche auch bei der Aufzeich-
nung eingegeben wurden.
196
Sandini Bib
Mithilfe der rotmarkierten Tasten VORIGES DYNPRO bzw. NÄCHSTES DYNPRO

kann man nun zwischen den einzelnen, im Detailbild Funktionen aufgeliste-
ten Dynpros hin- und herblättern.
Falls ein Dynpro mehrere Seiten von Eingabewerten aufweist, kann man
auch zwischen diesen Seiten blättern, indem man die Tasten V ORIGE SEITE
bzw. NÄCHSTE SEITE betätigt. Als weitere Ausgangssitutaion wird nun das
Dynpro Anzeigen: Details Funktionen verwendet (Abbildung 8.12).
E Ein Doppelklick nun im Detailbild Funktionen auf »SAPMF02K DynproNr.
0110« bringt die Sicht zur Pflege der Festwerte Anschrift auf dem Dynpro Nr.
0110 zum Vorschein (siehe Abbildung 8.14).

Eingabewerte
Hinweis: Aus Gründen der Übersicht ist es für den Anwender sehr empfehlens-
wert, sich auch die anderen Dynpros ebenfalls per Doppelklick anzusehen, um
einen Überblick über die in diesem Testablauf zu pflegenden Felder zu erlangen.
F Nach Betrachtung dieser Dynpros bestätigt man mithilfe des Buttons ZU-
RÜCK. Es erscheint wieder der Funktionsbildschirm Anzeigen Funktionen (Ab-
bildung 8.11).
197
Sandini Bib
8.3 Einfacher CATT
G Durch Auswahl des Buttons ATTRIBUTE gelangt man in den bereits bekann-
ten Bildschirm zur Pflege der Attribute.
H Nach Betrachtung des Attributspflegebildschirms kann man zurück auf das
Dynpro Anzeigen Funktionen navigieren. Durch Klicken auf PARAMETER erzeugt
das System eine Übersicht über die für diesen Testbaustein eventuell definier-
ten Import- und Exportparameter sowie über eventuell vereinbarte Variablen.
Hinweis: Zum jetzigen Zeitpunkt sind noch keine Parameter gepflegt; sie
werden noch ausführlich behandelt. Deshalb findet sich auf dem Dynpro An-
zeigen Importparameter auch noch keine entsprechende Auflistung. Dasselbe
gilt natürlich für die Exportparameter und die Variablen. Aus diesem Grund
wird auf die Abbildung der betreffenden Dynpros an dieser Stelle verzichtet.
I Mit Zurück (F3) gelangt man wieder in das Funktionsbild Anzeigen Funktio-
nen.
8.3.3 Pflege der Eingabewerte/Parameter/Variablen

In der letzten Übung wurde erläutert, wie ein Testbaustein mithilfe der Auf-
zeichnungsfunktionalität anzulegen ist. Bei der Aufzeichnung wurden die in
der Transaktion Kreditor anlegen vorgenommenen Eingaben als Festwerte in den
Testablauf übernommen. Wenn diese Eingaben nun variabel gestaltet werden
sollen, da ja nicht immer der gleiche Kreditor angelegt wird, muss man zunächst
Importschnittstellen definieren. Dadurch ist es möglich, den Testbaustein beim
Aufruf mit beliebigen Werten zu versorgen und folglich sehr flexibel zu gestal-
ten. Den Importparametern können dabei jeweils Namen zugewiesen werden.
A Man markiert im Funktionsbildschirm (Abbildung 8.11) die Zeile »TCD
FK01« und führt dort einen Doppelklick aus. Daraufhin erscheint der in Ab-
bildung 8.15 gezeigte Detailbildschirm. Wie bereits näher ausgeführt, zeigt
diese Sicht alle Dynpros, die während der Aufzeichnung des Testbausteins
durchlaufen wurden.
B Nun markiert man auf dem Dynpro Details Funktionen TCD Testbaustein
KBC00268 die erste Zeile. Durch Betätigen des Buttons AUSWÄHLEN oder durch
einen Doppelklick auf die markierte Zeile wird das Dynpro aus Abbildung 8.16
angesteuert. Die weißen Eingabefelder zeigen die Daten, die während der Auf-
zeichnung des Testbausteins vom Anwender eingegeben wurden.
198
Sandini Bib

Detailbildschirm von CATT

Eingabewerte – Transaktion Kreditor anlegen
199
Sandini Bib
8.3 Einfacher CATT
C Hier können alle Eingabewerte gepflegt werden. Für Feldinhalte, welche va-
riabel gehalten werden sollen, sind Importparameter zu vergeben. Diese Pa-
rameter werden bestimmten Feldern als Platzhalter zugeordnet und später
in einem eventuell diesen Testbaustein KBC02106 referenzierenden Testab-
lauf mit Werten versehen. Auf obigem Dynpro werden zunächst jedoch die
bei der Aufzeichnung eingegebenen Werte übernommen, da hier angenom-
men wird, dass der Buchungskreis 1401 und auch die Kontengruppe KRED
im Rahmen der weiteren Verwendung dieses Testbausteins immer gleich
bleiben werden. Es handelt sich hier also um Festwerte. Man gelangt nun
durch Anklicken des Buttons ZURÜCK in den Detailbildschirm Funktionen.
Dort ist die zweite Zeile zu markieren. Durch Doppelklick oder Auswählen
navigiert das System zum Dynpro aus Abbildung 8.17.

Eingabewerte Adresse – Transaktion Kreditor anlegen
Die Werte für Anrede, Land und Straße werden als Festwerte vereinbart. Die
Feldinhalte für Name, Suchbegriff, Straße, Ort, Postleitzahl und UST.-ID.Nr sol-
len jedoch variabel gehalten werden, da jeder Kreditor hier andere Daten
aufweist. Für diese Felder gilt es nun, jeweils Importparameter zu definieren.
Diese Parameter werden den Feldern als Platzhalter zugeordnet und später
im jeweiligen Testlauf mit Werten versehen. Die im obigen Dynpro bereits
eingetragenen Daten der Firma Test AG werden als mögliche Werte beim
Testablauf vorgeschlagen (Vorschlagswerte). Die Parameter (und auch die
Variablen) sind in ihrer Anzahl unbegrenzt, haben Bezug zum Datenelement
200
Sandini Bib
und können Daten mit einer Länge bis zu 132 Bytes aufnehmen. Man steuert,
wie bereits gezeigt, durch einen Doppelklick auf das jeweilige Eingabefeld in
die Parameterpflege.
D Ein Doppelklick auf das Eingabefeld Name lässt das Dynpro Pflegen Importpa-
rameter aus Abbildung 8.18 erscheinen. Auf dem Dynpro wird zunächst der
vom System vorgeschlagene Parametername (hier: &NAME_1GP) mit dem
entsprechenden Vorschlagswert und seinem Feldbezug gezeigt. Der Anwen-
der hat natürlich jederzeit die Möglichkeit, den Parametern eigene Namen
zuzuweisen. Allerdings sollte hier auf Namenskonventionen geachtet wer-
den. Jeder Parametername beginnt mit dem Zeichen »&« , dem anschließend
noch zwölf weitere Zeichen folgen können. Sobald ein neuer Parameter oder
eine neue interne Variable in ein CATT-Objekt eingefügt werden soll, er-
scheint das folgende, in Abbildung 8.18 dargestellte Dialogfenster, auf dem
der neue Parameter bzw. die neue Variable deklariert wird.

Parameterpflegebildschirm
Man kann hier den Parameter bzw. die Variable mit Bezug auf ein Feld aus
dem ABAP/4-Dictionary deklarieren. Dazu steht das Eingabefeld Datenele-
ment zur Verfügung. Durch diese Verknüpfung werden die Kurztexte des
Datenelements übernommen. Der bei der Aufzeichnung des Testbausteins
eingegebene Festwert gilt als Vorschlagswert. Rechts unten auf diesem Dyn-
pro kann man auswählen, ob nun ein Import-, einen Exportparameter oder
201
Sandini Bib
8.3 Einfacher CATT
eine lokale Variable definiert werden soll. Im vorliegenden Fall soll ein Im-
portparameter vergeben werden. Durch Anklicken des Buttons IMPORTPARA-
METER und durch Bestätigung mittels des grünen Pfeils definiert man für das
Feld Name einen Importparameter. Nun sind alle Parameter auf dem Dynpro
Nr. 0110 zu pflegen. Nach erfolgreicher Pflege aller zu definierenden Import-
parameter (Name, Suchbegriff, Straße, Ort, Postleitzahl) wechselt man in das
nächste Dynpro.
E Durch Doppelklick auf den Button NÄCHSTES DYNPRO erscheint das Dynpro
Nr. 0120 (Abbildung 8.19). Das Feld UST.-ID.-Nr enthält den Festwert
DE123456789. Da die Umsatzsteuer-Identifikationsnummer für jedes Unter-
nehmen anders lautet, ist es sinnvoll, dieses Feld flexibel zu gestalten. Des-
halb ist auch dieses Eingabefeld zu parametrisieren.
F Durch Doppelklick auf das Feld UST.-ID.-Nr erscheint das bereits erläuterte
Dynpro Pflegen Importparameter.
Auch dieser Importparameter ist nach der geschilderten Vorgehensweise an-
zulegen. Anschließend kehrt das System automatisch wieder in das Dynpro
Nr. 0120 zurück.

Eingabewerte Steuerung – Transaktion Kreditor anlegen
202
Sandini Bib
G Durch Anklicken des Buttons NÄCHSTES DYNPRO navigiert das System in das
Dynpro Nr. 0210. Auf diesem Bildschirmbild ist keine Parametrisierung vor-
zunehmen. Das Abstimmkonto 160000 wird als Festwert übernommen, da es
für alle Kreditoren gleich ist.
H Um wiederum ein Dynpro weiter zu gelangen, klickt man erneut auf N ÄCH-
STES DYNPRO. Es erscheint das Dynpro Nr. 0215. Hier ist zu sehen, dass die
Zahlungsbedingung ZB01 als Festwert eingetragen ist. Da diese Zahlungsbe-
dingung für alle Kreditoren Gültigkeit besitzt, kann hier ebenfalls auf eine
Parametrisierung verzichtet werden.
I Durch Anklicken des Buttons NÄCHSTES DYNPRO steuert man in das letzte
Dynpro Nr. 220. Hier wird das Mahnverfahren 0001 ebenfalls als Festwert
für alle Kreditoren behandelt.
J Die benötigten Importparameter für den Testbaustein KBC02106 sind nun
definiert. Nun navigiert man zum Funktionsbildschirm zurück (Abbildung
8.20). Hier sind folgende Daten einzugeben:
◗ TCDFK01
SETVAR&LIFNR = &M01

CATT-Funktionsbildschirm
203
Sandini Bib
8.3 Einfacher CATT
K Nachdem die für diesen Testbaustein benötigten Importparameter definiert

worden sind, stellt sich nun die wichtige Frage, welche Exportparameter zu
vergeben sind. Transaktionen im R/3-System geben nach erfolgreicher Bear-
beitung eine Dialogmeldung an den Benutzer aus. Das Resultat einer erfolg-
reich durchgespielten Transaktion »Kreditor anlegen« ist die Ausgabe der Dia-
logmeldung »Kreditor 0000001234 für Buchungskreis 0001 wurde angelegt« in der
Statuszeile. Diese Meldung kann bis zur vier Platzhalter enthalten, die zur
Laufzeit vom System mit Werten wie z.B. Kreditoren-, Beleg- oder Stammsatz-
nummern etc. versorgt werden. Auf diese Platzhalter kann man im Rahmen
von CATT mit den sogenannten Messagevariablen &M01 bis &M04 zugreifen.
Dabei bezieht sich &M01 auf den ersten Platzhalter in einer Dialogmeldung,
die Variable &M02 auf den zweiten usw. Das heißt, die Variable &M01 hat Be-
zug auf den Wert »0000001234« und die Variable &M02 auf den Wert »0001«.
Mit dem Befehl SETVAR &LIFNR = &M01 wird die vom System intern ver-
gebene Kreditorennummer an den noch zu definierenden Exportparameter
&LIFNR übergeben. Im vorliegenden Beispiel enthält demnach nach Beendi-
gung des Testbausteins KBC00268 der Exportparameter &LIFNR die Num-
mer des durch den Ablauf der Transaktion FK01 neu erzeugten Kreditors.
Falls in einem eventuell späteren Testablauf der Testbaustein Kreditor anlegen
referenziert wird, kann es sein, dass einer der anderen im Testablauf referen-
zierten Testbausteine innerhalb des Ablaufs auf die nun vergebene Kredito-
rennummer zugreifen muss. Zum Beispiel benötigt die Transaktion FK02 eine
Kreditorennummer. Entsprechend den Ausführungen zum modularen Kon-
zept in Kapitel 6 ist es daher nötig, einen Exportparameter, der in diesem Falle,
wie bereits erwähnt, den Namen &LIFNR trägt, im Testbaustein Kreditor anle-
gen zu definieren. Dieser Exportparameter &LIFNR kann dann, wenn ge-
wünscht, den Wert Kreditorennummer anderen Testbausteinen zur Verfügung
stellen. Exportparameter stellen die Exportschnittstelle zu anderen CATT-Ob-
jekten dar. Durch sie können beliebige Informationen aus dem Testbaustein
an das referenzierende CATT-Objekt weitergegeben werden. Exportnamen
unterliegen dabei den gleichen Namenskonventionen wie Importparameter.
Um die Kreditorennummer aus dem Testbaustein KBC02106 exportieren zu
können, wird zunächst auf dem vorherigen Dynpro Pflegen Funktionen Test-
baustein der Inhalt der Messagevariablen &M01 mit der Funktion SETVAR
(Setzen Variable) dem Exportparameter &LIFNR zugewiesen. Sofern man
den Exportparameter noch nicht definiert hat, erscheint automatisch das
Popup zur Parameterpflege. Hier ist der Parametertyp auf Exportparameter
zu setzen und &LIFNR entsprechend zu parametrisieren. Damit ist die Para-
metrisierung dieses Testbausteins KBC02106 abgeschlossen. Falls nun eine
Übersicht über alle im Testbaustein Kreditor anlegen verwendeten Parameter
und Variablen angezeigt werden soll, klickt man im Funktionsbildschirm auf
den Button PARAMETER und anschließend auf den Button IMPORT. Dann er-
scheint das in Abbildung 8.21 gezeigte Bildschirmbild, welches sämtliche im
Baustein KBC02106 verwendeten Importparameter samt ihrer Kurzbeschrei-
bung und den zugehörigen Vorschlagswerten auflistet:
204
Sandini Bib

Übersicht Importparameter

Übersicht Exportparameter
205
Sandini Bib
8.3 Einfacher CATT
L Durch Anklicken das Buttons EXPORT gelangen man zu einer Übersicht aller
in diesem Baustein definierten Exportparameter (Abbildung 8.22).
Auf die Abbildung des Dynpros zur Übersicht über die im Testbaustein ver-
wendeten Variablen wurde hier verzichtet, da bisher noch keine Variablen defi-
niert worden sind. Zu Übungszwecken kann man aber bereits durchaus einmal
dorthin navigieren.
In dieser Übung wurden für die Eingabewerte der verschiedenen Dynpros Im-
portparameter definiert. Diese wurden automatisch mit Vorschlagswerten be-
setzt. Dadurch werden diese Vorschlagswerte bei der Ausführung dieses
CATT-Testbausteins, sofern keine anderen Werte an die Importparameter über-
geben werden, verwendet. Für den Fall, dass man die Vorschlagswerte nicht
verwenden möchte, können diese beim Start des Testbausteins einfach über-
schrieben werden.
Darüber hinaus wurde ein Exportparameter vergeben. Dies erleichtert die Ver-
wendung von Testbausteinen in Testabläufen.
8.3.4 Testbaustein abspielen

Um einen Testbaustein bzw. einen Testablauf abspielen zu können, ist es erfor-
derlich, in den Startbildschirm von CATT zu verzweigen. Über folgenden Me-
nüpfad gelangt man dorthin:
A WERKZEUGEpABAP/4 WORKBENCHpTESTpTESTWORKBENCHpCATT-ABLÄU-
FE. Nun erscheint der bekannte Einstiegsbildschirm von CATT. Dieses Dyn-
pro wurde bereits in den vorherigen Kapiteln gezeigt (vgl. Abbildung 8.10).
Auf seine Abbildung wird deshalb hier verzichtet.
B Eingabe folgender Daten auf dem Einstiegsbildschirm:
◗ Testablauf KBC00268
C Durch Anklicken des Buttons AUSFÜHREN verzweigt das R/3-System in den
Startbildschirm von CATT.
Auf diesem Dynpro kann man, wie ersichtlich, verschiedene Optionen für
den Start des Testbausteins bzw. -ablaufs auswählen. Man kann die lange
bzw. die kurze Protokollart aktivieren oder ganz auf die Erstellung eines Pro-
tokolls verzichten. Des Weiteren stehen mehrere Abspielmodi zur Verfü-
gung. Darüber hinaus können auf diesem Startbildschirm sowohl interne als
auch externe Varianten gestartet werden.
206
Sandini Bib

CATT-Startbildschirm
D Im CATT-Startbildschirm werden nun folgende Felder markiert:

◗ Protokollart: Lang

◗ Abspielmodus: Hell
◗ Varianten: Ohne
E Klicken Sie anschließend auf das Button AUSFÜHREN.
Hinweis: Bitte pro aufgerufenem Dynprobild jeweils die (¢)-Taste drücken
und beobachten, wie der Testbaustein die einzelnen Felder automatisch füllt.
F Nachdem der Test beendet ist, erscheint das Dynpro CATT-Testplanprotokoll
aus Abbildung 8.24. Es ist vorerst nur zu ersehen, dass der Testbaustein
KBC02106 getestet wurde.
Um weitere Einzelheiten zu diesem Test sehen zu können, klickt man auf Be-
arbeiten und dann Knoten expandieren.
G Es erscheint nun das in Abbildung 8.25 gezeigte Ablaufprotokoll:
207
Sandini Bib
8.3 Einfacher CATT

CATT-Ablaufprotokoll

Ablaufprotokoll detailliert
208
Sandini Bib
Hinweis: Auch hier ist es zweckmäßig, sich die Nummer des neu angelegten
Kreditors zu notieren; sie wird im weiteren Verlauf der Arbeit benötigt.
8.4 Komplexer CATT-Ablauf

8.4.1 Anlegen eines weiteren Testbausteins
Bei folgendem Testbaustein, welcher letztendlich die aufgezeichnete Transakti-
on FK02 (Kreditor ändern) zum Inhalt hat, werden lediglich noch die Dynpros ex-
plizit aufgeführt, die für die Änderung der Kreditorendaten verantwortlich
sind. Die einleitende Dynprofolge zum Aufzeichnen eines Testbausteins ist vor-
stehend bereits detailliert beschrieben worden. Deshalb wird auf deren erneute
ausführliche Darstellung an dieser Stelle verzichtet und auf die vorherigen Aus-
führungen verwiesen.
A WERKZEUGEpABAP/4 WORKBENCH
B TESTpTEST WORKBENCHpCATT-ABLÄUFE
C Baustein aufzeichnen aktivieren.
D Es folgt ein Dialogfeld. Hier ist der Transaktionscode FK02 einzugeben.
E Mit (¢) bestätigen.
F Es erscheint das Dynpro Kreditor ändern: Einstieg Buchhaltung aus Abbildung
8.26.

Einstiegsbildschirm – Transaktion Kreditor ändern
209
Sandini Bib
Innerhalb der Transaktion Kreditor ändern besteht auf diesem Dynpro die Op-
tion, festzulegen, welche Kreditorendaten durch diese Transaktion geändert
werden sollen. Hier sind nun folgende Daten einzugeben:
◗ Kreditor 100134 (= Fa. Test AG)
◗ Allgemeine Daten: Anschrift anklicken
Im Rahmen der Transaktion FK02 (Kreditor ändern) soll also die Anschrift
des Kreditors »Firma Test AG« geändert werden. Deshalb klickt man An-
schrift in der Auswahl Allgemeine Daten an.
G Die Eingaben sind mit der (¢)-Taste oder durch Anklicken des grünen Ha-
kens auf dem Dynpro links oben zu bestätigen.
Es erscheint nun ein Dynpro, das uns aus der Transaktion Kreditor anlegen be-
reits bekannt ist. Es beinhaltet die bereits eingebenen Daten aus der Auf-
zeichnung des Testbausteins.
H Nun ändert man auf diesem Dynpro die Adresse der »Firma Test AG« wie folgt:
◗ Straße: Bonner Straße 111
◗ Ort: Düsseldorf
◗ Postleitzahl: 10000

Eingabewerte Adresse – Kreditor ändern
210
Sandini Bib
I Die Eingaben sind mit der (¢)-Taste oder durch Anklicken des grünen Ha-
kens auf dem Dynpro links oben zu bestätigen.
J Sichern der Änderungen durch Betätigung des gelben Icons links neben dem
grünen Pfeil.
K Nun verzweigt man zum nächsten Dynpro. Nachdem im nächsten Schritt
der neu angelegte Testbaustein einer Syntaxprüfung unterzogen und er als
lokales Objekt entsprechend den vorherigen Ausführungen angelegt wurde,
notiert man sich die Nummer des neu angelegten Testbausteins. Die Num-
mer lautet: KBC02107.
Dann verzweigen Sie bitte in den bereits bekannten Attributspflegebild-
schirm zu diesem neu angelegten Testbaustein. Dort kontrolliert man die At-
tribute des Testbausteins. Auch hier sei auf die entsprechenden Ausführun-
gen verwiesen.
L Nach der erfolgter Kontrolle der Attribute navigieren Sie bitte in den Funk-
tionsbildschirm des Testbausteins KBC02107.
M Durch einen Doppelklick auf Objekt FK02 verzweigt das System in den Bild-
schirm Details Funktion TCD Testbaustein KBC00269. Hier können, wie in den
vorherigen Ausführungen bereits erläutert, die einzelnen Dynpros, die wäh-
rend der Aufzeichnung durchlaufen wurden, aufgerufen, ihr Inhalte näher
betrachtet und, falls notwendig, entsprechend abgeändert werden. Zu
Übungszwecken ist es empfehlenswert, nochmals durch die einzelnen Dyn-
pros zu navigieren.
N Hier stellt sich nun primär die Frage, welche Parameter für diesen Testbau-
stein definiert werden müssen, um ihn möglichst flexibel zu gestalten. Wir

setzen voraus, dass sich die Kreditoren alle in demselben Buchungskreis be-
finden. Dies wird in der Realität zwar nicht oft der Fall sein, sei der Einfach-
heit halber hier jedoch angenommen. Damit ein Kreditor aber geändert wer-
den kann, muss der Testbaustein Kreditor ändern wissen, welcher Kreditor
denn zu ändern ist. Dazu muss im Testbaustein Kreditor ändern im Einstiegs-
bildschirm Kreditor ändern: Einstieg Buchhaltung die entsprechende Nummer
(Kreditorennummer) des zu ändernden Kreditors eingegeben werden, wird
doch jeder Kreditor durch seine individuelle Kreditorennummer im System
identifiziert. Unter der eingegebenen Kreditorennummer, hier 100134, sind
sämtliche Daten des Kreditors »Firma Test AG« im System hinterlegt. Das
heißt, der Testbaustein Kreditor ändern füllt seine Felder zunächst mit den Da-
ten des Kreditors 100134.
211
Sandini Bib

Detailbildschirm – Transaktion Kreditor ändern

Eingabewerte – Transaktion Kreditor ändern
212
Sandini Bib
O Aus den vorherigen Ausführungen ergibt sich, dass es sinnvoll ist, die Kre-
ditorennummer in diesem Testbaustein als Importparameter zu definieren,
um den Testbaustein Kreditor ändern um einiges flexibler zu gestalten. Da-
durch wird auch die eventuelle Einbindung des Bausteins in mögliche Test-
abläufe erleichtert. Falls im Rahmen des Testbausteins auch die Adresse des
jeweiligen Kreditors überprüft und eventuell geändert werden soll, sind
auch hier die bisher eingetragenen Festwerte für die Straße, den Ort und die
Postleitzahl des Kreditors durch entsprechende Importparameter zu erset-
zen. Auf die bisherigen Ausführungen sei hier verwiesen. Hier ist aber zu-
nächst nur der besprochene Importparameter für das Feld Kreditorennummer
zu definieren. Wie man dabei vorgeht, wurde bereits besprochen.
P Auf dem folgenden Dynpro Pflegen Eingabewerte SAPMF02K 0110 Testbau-
stein KBC02107 wird auf eine Parametrisierung zunächst verzichtet (siehe
Abbildung 8.29).
Q In der Übersicht Importparameter finden sich dann die in Abbildung 8.30 ge-
zeigten Eintragungen. Wie man dort hin gelangt, wurde bereits gezeigt.

Übersicht Importparameter – Transaktion Kreditor ändern
R Exportparameter wurden im Testbaustein KBC02107, wie diese Übersicht

zeigt, nicht vereinbart.
S Nun verzweigt man in den Attributspflegebildschirm und überprüft dort die
generierten Attribute (Abbildung 8.31).
213
Sandini Bib

Attributspflegebildschirm – Transaktion Kreditor ändern
T Die Aktivierung der Syntaxprüfung erfolgt über den Menüpfad TESTAB-

LAUFpPRÜFEN. Nach erfolgreicher Syntaxprüfung erscheint in der Statuszeile
eine entsprechende Meldung des Systems.
Wenn auch diese Übung ohne Schwierigkeiten absolviert wurde, ist der An-
wender mit den Grundtechniken der Erstellung von Testbausteinen vertraut.
Sollten allerdings Schwierigkeiten aufgetreten sein, ist es sehr empfehlenswert,
die entsprechenden Übungen nochmals zu wiederholen.
Hinweis: Auch hier sollte die Nummer des Testbausteins zwecks späterer Ver-
wendung notiert werden. Im Folgenden wird der Testbaustein unter der Be-
zeichnung KBC02107 referenziert.
8.4.2 Testablauf erstellen

Ein Testablauf setzt sich im Allgemeinen modular aus mehreren verschiedenen
Testbausteinen zusammen. Dieser Tatbestand wurde bei der Schilderung des mo-
dularen Konzeptes von CATT bereits in Kapitel 6 näher beschrieben. Falls es hier
evtl. Verständnisprobleme geben sollte, empfiehlt es sich, diese Lektion nochmals
durchzuarbeiten und zu wiederholen. Im Testablauf wird ein Testbaustein durch
Aufruf der Funktion REF und Angabe der Nummer des Testbausteins referen-
ziert. Auf die entsprechenden Ausführungen zu den CATT-Funktionen in Kapitel
214
Sandini Bib
7 sei in diesem Kontext ebenfalls verwiesen. Durch diese Referenzierung des Test-
bausteins im Testablauf ist es möglich, im Testablauf alle Importparameter des
Testbausteins mit Werten zu versorgen. Man kann dazu Importparameter des Te-
stablaufs verwenden oder Festwerte eingeben. Sofern keine Angaben gemacht
werden sollen, werden die Vorschlagswerte des Testbausteins benutzt. Des Wei-
teren kann man die Exportparameter des Testbausteins verwenden, um Informa-
tionen aus dem Testbaustein an lokale Variablen des Testablaufs zu übergeben.
A Menüpfad: WERKZEUGEpABAP/4-WORKBENCH
B TESTpTEST WORKBENCHpCATT-ABLÄUFE
C Anlegen
Dadurch erscheint zunächst der Attributspflegebildschirm. Bei der Erstel-
lung eines Testablaufs werden die Attribute im Gegensatz zur Aufzeichnung
von Transaktionen nicht automatisch vom R/3-System gepflegt, sondern
müssen vom Anwender manuell eingepflegt werden. Hier ist besonders zu
beachten, dass im Falle des Anlegens eines Testablaufs unter dem Attibut
Kennzeichen das Kästchen Testbaustein nicht markiert ist. Andernfalls geht
das R/3-System davon aus, dass es sich bei dem vorliegenden CATT-Objekt
um einen Testablauf handelt. Es empfiehlt sich daher, die Inhalte des Attri-
butspflegebildschirm genauestens im Auge zu behalten.

Attributspflegebildschirm – Testablauf KBC02108
215
Sandini Bib
D Anschließend navigiert man, wie beschrieben, in den Funktionsbildschirm.

Dort referenziert man die beiden bereits erstellten Testbausteine KBC02106
und KBC02107. Dies sieht dann wie Abbildung 8.33 aus.

Funktionsbildschirm – Testablauf KBC02108
E Nun ist im Funktionsbildschirm das Objekt KBC02106 zu markieren.

F Durch Doppelklick auf das Objekt steuert das System im Testablauf
KBC02108 in die Transaktionsebene des Testbausteins KBC02106.
G Dort werden für den Testablauf KBC02108 nach dem bereits bekannten Ver-
fahren Importparameter für Name, Suchbegriff, Postleitzahl, Ort, Umsatzsteuer-
ID.Nr. und Adresse definiert.
Die Übersicht über die neu definierten Importparameter des vorliegenden
Testablaufs KBC02108 können Sie Abbildung 8.34 entnehmen.
216
Sandini Bib

Importparameter – Testablauf KBC02108
Der Testbaustein KBC02106 liefert als Resultat eine durch die Transaktion
FK01 generierte Kreditorennummer. Diese Kreditorennummer wird dem
Exportparameter &LIFNR als Wert zugewiesen. Damit dieser Exportpara-

meter seinen Wert anderen Testbausteinen, also in diesem Fall dem Testbau-
stein KBC02107 innerhalb des Testablaufs KBC02108 zur Verfügung stellen
kann, muss eine lokale Variable auf Testablaufebene definiert werden. Diese
lokale Variable soll der Einfachheit halber ebenfalls &LIFNR genannt wer-
den. Mit dem doppelt vergebenen Namen &LIFNR gibt es keine Probleme,
da der Exportparameter &LIFNR auf Testbausteinebene (KBC02106) und die
lokale Variable &LIFNR auf Testablaufebene (KBC02108) definiert wurde,
und sie damit jederzeit einfach zu differenzieren sind.
H Die lokale Variable &LIFNR muss nun angelegt werden. Hierzu navigiert
man in das Dynpro Pflegen Exportparameter Testbaustein KBC02106 (Abbil-
dung 8.35). Dort wird im Feld Parameterwert der Name &LIFNR der zu defi-
nierenden lokalen Variable eingetragen.
Wenn diese Eingaben nun mit der (¢)-Taste bestätigt werden, erscheint das
bereits bekannte Dynpro zur Parameterpflege. Dort werden lokale Variablen
analog zu den Ausführungen bzgl. der Importparameter angelegt.
217
Sandini Bib

Pflegebildschirm Exportparameter – Testbaustein KBC02106

Pflegebildschirm Importparameter – Testbaustein KBC02107
218
Sandini Bib
I Anschließend markiert man nun im Funktionsbildschirm das Objekt

KBC02107. Durch Doppelklick auf das Objekt gelangt man im Testablauf
KBC02108 in die Transaktionsebene des Testbausteins KBC02107. Dort
wechselt man dann in den Pflegebildschirm für die Importparameter des
Testbausteins KBC02107 (Abbildung 8.36).
J Um nun innerhalb des Testablaufs KBC02107 die Verbindung zwischen dem
Exportparameter &LIFNR des im Testablauf referenzierten Testbausteins
KBC02106 und dem Importparameter &LIF16 des Testbausteins KBC02107
herzustellen, wird in obigem Dynpro als Parameterwert die lokale Variable
&LIFNR eingetragen. Somit fungiert die lokale Variable &LIFNR als Trans-
portmedium zwischen Export- und Importparameter.
K Exportparameter sind im Testbaustein KBC02107 nicht zu pflegen.
L Die Eingaben sind an dieser Stelle zu sichern, und die Syntaxprüfung ist
durchzuführen.
M Nun navigiert man zum Startbildschirm von CATT, um den Testablauf
KBC02108 zu starten. Der Startbildschirm sieht dann wie in Abbildung 8.37
gezeigt aus:

Startbildschirm – Testablauf KBC02108
219
Sandini Bib
Wie bereits beschrieben, können hier die Startoptionen (Protokollart, Ab-

spielmodus und Varianten) festgelegt werden. Falls im Feld Parameterwert
keine Eintragungen vorgenommen werden, werden die Importparameter
des Testablaufs KBC02108 mit den bei der Aufzeichnung eingetragenen Vor-
schlagswerten versorgt. Wenn diese Vorschlagswerte nicht verwendet wer-
den sollen, müssen im Feld Parameterwert die gewünschten Daten eingetra-
gen werden.
N Nach erfolgreicher Beendigung des Testablaufs KBC02108 wird vom R/3-
System ein ausführliches Protokoll erzeugt. Auf die entsprechenden Erläute-
rungen zum CATT-Protokoll sei an dieser Stelle hingewiesen. Das Protokoll
zum Testablauf KBC02108 sieht aus, wie in Abbildung 8.38 gezeigt:

Ablaufprotokoll – Testablauf KBC02108
Vorliegendes Protokoll kann an den einzelnen Knoten noch weiter aufgeris-

sen werden.
In der letzten Übung wurde erläutert, wie ein Testablauf erstellt wird, der die in
den erstellten Testbausteine KBC02106 und KBC02107 referenziert. Es wurde
gezeigt, wie Importparameter und Exportparameter der Testbausteine in Test-
abläufen genutzt werden können und wie auf Testablaufebene Importparame-
ter definiert werden. Jetzt heißt es, den erstellten Testablauf abzuspielen.
220
Sandini Bib
8.4.3 Testablauf abspielen

Beim Abspielen eines Testablaufs geht man analog zu den Schritten beim Ab-
spielen eines Testbausteins vor. Es sei hier auf Abschnitt 8.2.4 verwiesen.
Im Folgenden wird erläutert, wie man den Testablauf KBC02108 abspielt. Jedes
aufgerufene Dynprobild muss jeweils mit Drücken der (¢)-Taste bestätigt wer-
den. Dabei kann beobachtet werden, wie das Computer Aided Test Tool im vor-
liegenden Testablauf die einzelnen Felder automatisch mit Daten versorgt.
B Menüpfad: TEST WORKBENCHpCATT-ABLÄUFE
C Folgende Felder sind zu füllen:
Felder Daten
Testablauf KBC00271
D Ausführen (F8)
E Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Protokollart Lang Markieren
Abspielmodus Hell Markieren

Varianten Ohne
F Ausführen (F8)
G Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
KBC02108 Markieren
H Menüpfad: BEARBEITENpKNOTEN EXPANDIEREN

I Zurück (F3)
8.4.4 Varianten anlegen

In den vorherigen Abschnitten wurde erläutert, wie man mittels CATT einen
automatisierten Testablauf erstellt. Der Testablauf legt jedoch nur einen Kredi-
221
Sandini Bib
tor an und ändert ihn anschließend. Will man aber über den Testablauf mehrere
Kreditoren gleichzeitig anlegen, so müssen hierzu Varianten verwendet wer-
den. Man unterscheidet dabei zwischen internen und externen Varianten.
Interne Varianten
Zunächst bilden die internen Varianten die Basis folgender Überlegungen. Bei
der Aufzeichnung der Transaktion FK01 (Kreditor anlegen) wurden die in der
Transaktion vorgenommenen Dateneingaben in den Testablauf als Festwerte
übernommen. Wenn man diese Eingaben variabel gestalten möchte, müssen im
Testbaustein die bereits besprochenen Importschnittstellen definiert werden,
die mit den notwendigen Initialwerten versorgt werden können. Beim Starten
von Testabläufen besteht aber auch die Möglichkeit, die Importparameter direkt
mit Werten zu versehen. Zusätzlich können Varianten angelegt werden, in de-
nen dann spezielle Werte für die Importparameter im System abgespeichert
werden. Diese werden beim Start des Testablaufs mit aktivierten Varianten an
die entsprechenden Importparameter übergeben. Es können maximal 99 interne
Varianten zu einem Testablauf angelegt werden.
Interne Varianten anlegen

Für den Testablauf KBC2108 sollen nun interne Varianten angelegt werden, die
den Testablauf mit verschiedenen Werten versorgen. Anschließend kann der
Testablauf mit Varianten gestartet werden.
B Menüpfad: TESTpTEST-WORKBENCHpCATT-ABLÄUFE
C Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Testablauf KBC02108
D Ändern
E Menüpfad: SPRINGENpVARIANTEN. Das System verzweigt dadurch in die Pfle-
getransaktion für Varianten namens Pflegen Varianten zu Testablauf KBC02108.
In der Statuszeile dieses Dynpros erscheint der Hinweis, dass zum vorliegen-
den Testablauf KBC02108 noch keine (internen) Varianten existieren.
F Duch Aufruf der Funktion Anlegen gelangt man in das Dynpro namens An-
legen Variante zu Testablauf KBC02108 (vgl. Abbildung 8.39). Hier wird eine
Auflistung sämtlicher Importparameter des Testablaufs erzeugt. In der Sta-
tuszeile erscheint der Hinweis, dass Variante 01 noch nicht belegt ist. Die Im-
portparameter können nun im Rahmen der Festlegung der Variante 01 mit
Werten versehen werden.
222
Sandini Bib
G Es folgt die Eingabe folgender Daten in die entsprechenden Felder:
Variante 01
Felder Daten
Name Oberniedermaier KG
Suchbegriff ONM KG
Straße Münchener Str. 138
Ort Mühldorf
Postleitzahl 84453
UmsatzsteuerID.Nr. DE987654321
Das Dynpro sieht dann wie folgt aus:

Übersicht Varianten – Testablauf KBC02108
H Betätigen der Funktion Anlegen.
223
Sandini Bib
I Es schließt sich die Eingabe einer Kurzbeschreibung für die Variante und die
Pflege der Parameter mit den Werten aus der Musterliste an, sofern sie vom
Vorschlagswert abweichen. Um weitere zwei Varianten 02 und 03 zu verein-
baren, sind folgende Werte einzugeben:
Variante 02
Felder Daten
Name Kernbichl ohG
Suchbegriff Kerni
Straße Dorfstraße 9
Ort Karlsfeld
Postleitzahl ohne Eintrag
UST-ID.Nr. ohne Eintrag
Variante 03
Felder Daten
Name Schmidt
Suchbegriff Schmidt
Straße ohne Eintrag
Ort ohne Eintrag
Postleitzahl ohne Eintrag
UST-ID.Nr. ohne Eintrag
Hier ist jeweils die Funktion Anlegen zu betätigen. Außerdem ist es empfeh-
lenswert, auch hier eine Kurzbeschreibung für die Varianten einzugeben
und die Parameter mit den Werten aus der Musterliste zu pflegen, sofern sie
vom Vorschlagswert abweichen. Sowohl bei Variante 02 als auch bei Varian-
te 03 wurden einige Felder bewusst nicht mit Werten belegt. Hier übernimmt
das R/3-System bei Abspielen der Varianten automatisch die Vorschlags-
werte der Importparameter aus dem Testablauf KBC02108. In diesem Zu-
sammenhang ist das folgende Testprotokoll zum Testablauf KBC02108 samt
Varianten genauer zu betrachten. Auf die Darstellung der Dynpros hinsicht-
lich des Anlegens der Varianten 02 und 03 wurde hier verzichtet, da sie den
vorhergehenden entsprechen.
J Die Varianten werden hier gesichert.
224
Sandini Bib
Interne Varianten abspielen

B Menüpfad TESTpTEST WORKBENCHpCATT-ABLÄUFE
Felder Daten
Testablauf KBC02108
D Ausführen
E Auf dem Startbildschirm kann nun bei der Festlegung der Startoptionen in
der Gruppe Varianten gewählt werden, ob der Testablauf ohne, mit allen
oder mit einer speziellen Variante gestartet werden soll. In vorliegendem Fall
wählt man den Auswahlknopf Alle.

Startbildschirm mit aktivierten Varianten – Testablauf KBC02108
225
Sandini Bib
F Das System führt den Testablauf wie gewohnt aus. Nach Beendigung des
Testablaufs wird von System ein Protokoll erzeugt. In diesem Protokoll wer-
den vier Abläufe aufgelistet. Der erste Ablauf entspricht dem Ablauf mit den
Startwerten, der zweite, dritte und vierte Ablauf entspricht jeweils einer der
Varianten Nr. 01, Nr. 02 und Nr. 03. Dabei wird der Name der Variante hinter
dem jeweiligen Ablauf im Protokoll ausgegeben. Es empfiehlt sich, das Test-
protokoll (Abbildung 8.41 und 8.42) näher zu betrachten.
G Überprüfung der Arbeit.
Bisher wurde illustriert, wie interne Varianten angelegt und wie Testabläufe mit
internen Varianten gestartet werden können. Mithilfe der internen Varianten ist
es möglich, verschiedene Testversionen zu erzeugen, die dann bei einem Testab-
lauf verwendet werden können. Dadurch können die Reaktionen des zu testen-
den Ablaufs auf verschiedene Eingabemodifikationen hin untersucht werden.

Ablaufprotokoll zu Testablauf KBC02108 mit Varianten – Teil 1
226
Sandini Bib

Ablaufprotokoll zu Testablauf KBC02108 mit Varianten – Teil 2
Externe Varianten
Externe Varianten eröffnen die Möglichkeit, Varianten für die Importparameter

von Testabläufen in einem Tabellenkalkulationsprogramm wie Microsoft
EXCEL zu erstellen. Dabei können bis zu 99.999 externe Datensätze erzeugt und
anschließend mittels CATT abgespielt werden. Der Testablauf wird zu diesem
Zweck mit dem Kennzeichen Externe Varianten auf dem Attributspflegebild-
schirm versehen. Dadurch wird erreicht, dass der Testablauf beim Start immer
versucht, auf externe Varianten zurückzugreifen. Sollten diese nicht vorhanden
sein, wird vom System eine Fehlermeldung ausgegeben. Die Datendatei mit den
externen Varianten ist eine so genannte »Textdatei«. Die einzelnen Elemente der
Datei sind durch Tabulatoren voneinander getrennt. In der ersten Zeile der Da-
tei stehen die Parameternamen ohne vorangestelltes »&«. Die zweite Zeile ent-
hält die Kurztexte. In der dritten Zeile stehen die Vorschlagswerte der Parame-
ter. Ab der vierten Zeile können dann eigene Werte, also die externen Varianten
eingetragen werden.
Externe Varianten anlegen

B Menüpfad: TESTpTEST WORKBENCHpCATT-ABLÄUFE
227
Sandini Bib
Felder Daten
Testablauf KBC02108
D Ändern anklicken
E Menüpfad: SPRINGENpEXTERNE VARIANTENpVORSCHL. EXPORTIEREN
F Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Name der Dateien C:\temp\KBC02108.TXT
G Übertragen anklicken
Hinweis: Nun ist es erforderlich, nach MS-EXCEL zu wechseln. Dort öffnet
man die Datei C:\temp\KBC02108.TXT. Nun ist im Fenster Dateityp die Opti-
on Textdateien (*.prn, *.txt, *.csv) zu wählen. MS-EXCEL wird nun versuchen,
die Datei im EXCEL-Format einzulesen. Dazu drückt man einfach zweimal die
Drucktaste WEITER und im Schritt 3 des Assistenten die Drucktaste ENTER.
Durch Doppelklick auf das File KBC02108.TXT navigiert EXCEL in folgende
EXCEL-Tabelle:
Abbildung 8.43
EXCEL-Tabelle zum Testablauf KBC02108
228
Sandini Bib
Hinweis: Obige EXCEL-Datei besteht aus sechs Spalten und drei Zeilen. In
der ersten Zeile sind die Namen der Importparameter eingetragen, in der
zweiten Zeile die Bezeichnungen bzw. Beschreibungen der Importparame-
ter. In der dritten und letzten Zeile befinden sich die von Ihnen bei der Auf-
zeichnung gewählten Vorschlagswerte. In den folgenden Zeilen können pro
Importparameter unterschiedliche Eingabewerte angegeben werden. Wer-
den einzelne Zellen in einer Zeile freigelassen, so übernimmt das System die
Vorschlagswerte für diese Zeile. Die Tabelle ist wie folgt aufzubauen:

Abbildung 8.44
Um externe Varianten erweiterte EXCEL-Tabelle zum Testablauf KBC02108
H Beim Speichern des Dokuments müssen die Daten wiederum im Textformat

(getrennt durch Tabulatoren) abgespeichert werden.
Externe Varianten abspielen

229
Sandini Bib
Felder Daten
Testablauf KBC02108
D Ausführen
E Menüpfad: SPRINGENpEXTERNE VARIANTENpEINBINDEN
Felder Daten
der Datei C:\temp\KBC02108.TXT
G Übertragen anklicken. Daraufhin erscheint der Startbildschirm von CATT. In

der Statuszeile des Startbildschirms von CATT wird die Meldung »283 Bytes
übertragen« ausgegeben.
H Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Varianten Ohne
Parameterwerte Alle freilassen
I Ausführen
Hinweis: Hier muss man jedes aufgerufene Dynprobild jeweils mit der (¢)-
Taste bestätigen. Dabei kann beobachtet werden, wie der Batch-Input die
einzelnen Felder automatisch füllt. Das Szenario wird dreimal durchlaufen
und zwar mit den Werten aus den Zeilen 4 und 5 der EXCEL-Datei. Die Vor-
schlagswerte aus der dritten Zeile werden nicht ausgeführt!
J Folgendes Protokoll wird am Ablaufende ausgegeben:
230
Sandini Bib

Protokoll zum Testablauf KBC02108 mit externen Varianten
8.5 Pflege von Customizing–Tabellen über

Dynpros bzw. Transaktionen

8.5.1 Testbaustein anlegen für neue Tabelleneinträge
C Aufzeichnen
D Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Transaktionscode 0VA8 (= Automatische Kreditlimitprüfung)
E Neue Einträge
231
Sandini Bib
8.5 Pflege von Customizing–Tabellen über Dynpros bzw. Transaktionen
Felder Daten
KKBR 0001
RKI 001
KG 01
Saisonfaktor 50
G Sichern
H Abbrechen
I Möchten Sie wirklich abbrechen?: Ja.
J Zurück
K Aufzeichnung beendet
L (¢)
M Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Kurztext Customizingprofil Kreditlimitprüfung

automatisch
Stichwort A020020435
Applikation SD
Subapplikation BF
Komponente CM
N Menüpfad: TESTABLAUF pPRÜFEN

O Sichern ohne Prüfen
Hinweis: Es ist empfehlenswert, sich die Nummer des Testbausteins zu notieren.
Im Folgenden wird der Testbaustein unter der Bezeichnung KBC00249 referen-
ziert.
232
Sandini Bib
8.5.2 Testbaustein anlegen für existierende

Tabelleneinträge
A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE
C Aufzeichnen
Felder Daten
Transaktionscode 0VA8 (= Automatische Kreditlimitprüfung)
E Positionieren
Felder Daten
KKBR 0001
RKI 001
KG 01
G Weiter mit (¢)

H Detail
I Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Saisonfaktor 60
J Sichern
K Zurück
L Zurück
M Aufzeichnung beendet mit (¢)
233
Sandini Bib
N Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten

automatisch
Applikation SD
Subapplikation BF
Komponente CM
O Menüpfad: TESTABLAUF pPRÜFEN

P Sichern ohne Prüfen (F11)
Hinweis: Es ist empfehlenswert, sich die Nummer dieses Testbausteins zu notie-
ren. Im Folgenden wird der Testbaustein unter der Bezeichnung KBC00250 re-
ferenziert.
8.5.3 Testablauf aus beiden Testbausteinen festlegen

C Kopieren
Felder Daten
Testablauf KBC00036
E Kopieren anklicken
Felder Daten

automatisch
Applikation SD
234
Sandini Bib
Felder Daten
Subapplikation BF
Komponente CM
G Funktionen anklicken
Hinweis: Definition der Schlüsselfelder als Importparameter.
H Eingabe folgender Daten in die entsprechenden Felder und Bestätigung mit
(¢):
Felder Daten
Funktion CHETAB
Objekt T691F
Kreditkontrollbereich &
I Eingabe folgender Daten in die entsprechenden Felder und danach »Weiter«:
Felder Daten
Parametername &KKBER
Vorschlagswert 0001

J Eingabe folgender Daten in die entsprechenden Felder und Bestätigung mit
(¢).
Felder Daten
Kreditmanagement: &
Risikoklasse
K Eingabe folgender Daten in die entsprechenden Felder und danach »Weiter«:
Felder Daten
Parametername &CTLPC_CM
Vorschlagswert 001
235
Sandini Bib
L Eingabe folgender Daten in die entsprechenden Felder und Bestätigung mit

(¢).
Felder Daten
Kreditgruppe Vorgang &
M Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Parametername &CRMGR_CM
Vorschlagswert 01
N Zurück
O Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Referenz 1 KBC00249
P Menüpfad: BEARBEITEN pAUFLÖSEN REFERENZ

Q Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Referenz 2 KBC00250
R Menüpfad: BEARBEITEN pAUFLÖSEN REFERENZ

S Doppelklick auf die TCD-Zeile und dann alle Schlüsselparameter durch ein
»&« ersetzen.
T Sichern
8.5.4 Testbaustein anlegen

C Anlegen
236
Sandini Bib
D Im Attributspflegebildschirm sind nun folgende Felder zu füllen:
Felder Daten

automatisch
Applikation SD
Subapplikation BF
Komponente CM
Nun ist es erforderlich, zum Funktionsbildschirm zu navigieren. Dort sind

die Schlüsselfelder der Tabelle als Importparameter zu definieren.
E Eingabe folgender Daten in die entsprechenden Felder und Bestätigung mit
der (¢)-Taste.
Felder Daten
Funktion SETTAB
Objekt T691F
F Doppelklick auf dem Objekt T691F

G Eingabe folgender Daten in die entsprechenden Felder und Bestätigung mit
(¢).
Felder Daten
Kreditkontrollbereich &
H Eingabe folgender Daten in die entsprechenden Felder, danach »Weiter«.
Felder Daten
Parametername &KKBER
Vorschlagswert 0001
237
Sandini Bib
I Eingabe folgender Daten in die entsprechenden Felder und Bestätigung mit

(¢).
Felder Daten
Kreditmanagement: &
Risikoklasse
J Eingabe folgender Daten in die entsprechenden Felder, danach »Weiter«.
Felder Daten
Parametername &CTLPC_CM
Vorschlagswert 001
K Eingabe folgender Daten in die entsprechenden Felder und Bestätigung mit

(¢).
Felder Daten
Kreditgruppe Vorgang &
L Eingabe folgender Daten in die entsprechenden Felder, danach »Weiter«.
Felder Daten
Parametername &CRMGR_CM
Vorschlagswert 01
M Alle Felder anzeigen.

Hinweis: Alle angezeigten Felder können hier mit beliebigen, von Ihnen ge-
wählten Werte gefüllt werden. Ist die Customizing-Tabelle bereits mit einem
Wert vorbelegt, so wird der betreffende Wert überschrieben. Bleibt das Feld
Feldinhalt leer, so wird der Eintrag in der Customizing-Tabelle nicht modifi-
ziert.
N Eingabe folgender Daten in die entsprechenden Felder, danach »Zurück«:
Felder Daten
Saisonfaktor in % 50
238
Sandini Bib
Hinweis: Damit die SETTAB-Einstellungen nicht zurückgesetzt werden, ist

anschließend die Funktion RESTAB% einzugeben. Damit sind alle Rücksetz-
daten für die davorliegenden SETTAB-Einstellungen gelöscht.
O Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
Funktion RESTAB
Objekt %
P Menüpfad: TESTABLAUF pPRÜFEN

Q Sichern ohne Prüfen
R Lokales Objekt
S Zurück
Hinweis: Im Folgenden wird der Testbaustein unter der Bezeichnung KBC00251
referenziert.
8.5.5 Testbaustein abspielen


Felder Daten
Testablauf KBC00251
D Ausführen
Felder Daten
Varianten Ohne
Kreditgruppe Vorgang 02
239
Sandini Bib
8.6 Sonstige Funktionen
Felder Daten
Kreditmanagement: ohne Eintrag

Risikoklasse
Kreditkontrollbereich ohne Eintrag
Hinweis: Werden bei den Importparametern Felder freigelassen, so werden

die Vorschlagswerte gezogen. Im Beispiel wird die Customizing-Tabelle für
den Kreditgruppenvorgang 02, Risikoklasse 001 (= Vorschlagswert) und
Kreditkontrollbereich 0001 (= Vorschlagswert) gepflegt.
F Ausführen
G Eingabe folgender Daten in die entsprechenden Felder:
Felder Daten
KBC00251 Markieren
H Menüpfad: BEARBEITENpKNOTEN EXPANDIEREN

I Zurück
Hinweis: Der Testbaustein wird überprüft, indem man die Transaktion 0VA8
(= Sicht für die Pflege der automatischen Kreditlimitkontrolle) aufruft. Für die
Kreditgruppe 02 sollte dort ein Saisonfaktor von 50% gepflegt sein.
8.6.1 CATT über Komponenten suchen

Felder Daten
Testablauf Taste (F4) drücken
240
Sandini Bib
Felder Daten
Applikation SD
Subapplikation BF
Komponente CM
Hinweis: Zum Belegen der Felder Applikation, Subapplikation und Komponente

existieren jeweils (F4)-Hilfen.
E Ausführen
Felder Daten
CATT-Ablauf Markieren
G Auswählen ((¢))
8.6.2 CATT über Funktion/Funktionsvariante suchen


Felder Daten
Testablauf F4
Felder Daten
E Ausführen
241
Sandini Bib
Felder Daten
CATT-Ablauf Markieren
G Auswählen ((¢))
8.6.3 CATT übersetzen

C Menüpfad: ÜBERSETZUNG pKURZTEXTE pWEITERE TEXTE pCATT-ABLÄUFE
Felder Daten
Einzelobjekt bearbeiten Markieren
E (¢)
Felder Daten
CATT-Ablauf-Nr. KBC00251
Quellsprache D
Zielsprache E
G Übersetzen und Überarbeiten

H Sichern
I Zurück
8.6.4 CATT transportieren

242
Sandini Bib
Felder Daten
Testablauf KBC00251
D Transportieren
Felder Daten
Testablauf KBC00251 Markieren
F Transportieren ((¢))
Hinweis: Es erscheint nun die Abfrage Änderungsauftrag. Nun ist es möglich, ei-
nen bereits existierenden Transportauftrag auszuwählen bzw. einen neuen
Transportauftrag anzulegen. Anschließend muss der Transportauftrag noch
freigegeben werden. Hier wendet man sich am besten an den zuständigen Sys-
temverwalter. Er erläutert, wie die physikalische Datei auf das gewünschte Ziel-
system transportiert werden kann.
8.7 Remote Start
8.7.1 Zentrales Testsystem und Remote Tests

Die einzelnen Tests sowie die CATT-Daten liegen in einem zentralen R/3-Sys-
tem. Die CATT-Abläufe können sowohl in diesem zentralen System gestartet
werden als auch per Remote Function Call in einem remoten R/3- (ab R/3-Re-
lease 3.0D) bzw. R/2-System. Die Protokolle zu den einzelnen Testvorgängen
liegen ebenfalls im zentralen System. Im Remote-System laufen sämtliche Prü-
fungen ab, die vom Anwender definiert wurden.
8.7.2 Einrichten der R/3-R/3-Verbindung

A Zunächst wird im Zielsystem der Remote-CATT-Benutzer mit den entspre-
chenden Berechtigungen angelegt.
B Im Quellsystem muss die RFC-Destination über den Menüpfad WERKZEUGE
pADMINISTRATION pVERWALTUNG pNETZWERK p RFC-DESTINATION angelegt
werden.
243
Sandini Bib
8.7 Remote Start
C Zur Parameter-ID RFC ist als Parameter eine bestimmte Destination zu defi-
nieren. Diese wird dann bei jeder Anmeldung vorgeschlagen. Der Menüweg
hierzu ist: SYSTEM pBENUTZERVORGABEN pBENUTZERPARAMETER.
8.7.3 RFC-Destination anlegen (R/3-R/3)

A Um CATTs remote starten zu können, benötigt man eine RFC-Destination.
Mit einer RFC-Destination wird die Verbindung zu einem Remote-System
definiert. Die Anmeldung im Remote-System findet unter dem angegebenen
Benutzernamen statt.
B Falls der Anwender keine Berechtigung zum Anlegen einer RFC-Destination
hat, ist es zweckmäßig, sich an den Systemverwalter zu wenden.
C Wenn der Anwender zum Anlegen einer RFC-Destination berechtigt ist, ist
der Menüpfad WERKZEUGE p ADMINISTRATION p VERWALTUNG p NETZWERK
p RFC-DESTINATION zu wählen. Dadurch wird die Pflege der RFC-Destina-
tionen aufgerufen.
D In den technischen Einstellungen muss der Verbindungstyp gewählt wer-
den, d.h. für R/3-Verbindungen Verbindungstyp 3. In einer logischen Desti-
nation (Verbindungstyp L) wird zu einer bereits bestehenden Destination ein
Bezug hergestellt, um für ein Zielsystem verschiedene Anmeldungen (unter-
schiedliche Mandanten, Benutzer, Sprachen) durchführen zu können.
E Das Zielsystem muss nun dokumentiert werden.
F Für die Anmeldung im Remote-System muss der CATT-Benutzer eingetra-
gen werden.
8.7.4 Einrichten der R/3-R/2-Verbindung

A R/2-System: Der CATT-Benutzer wird hier mit dem Benutzertyp CIPIC an-
hand der Transaktion USER angelegt.
B R/3-System: Man legt die RFC-Destination über das Menü WERKZEUGE p
ADMINISTRATION p VERWALTUNG p NETZWERK p RFC-DESTINATION an. Hier
definiert man den Gateway (= Verbindungsrechner) zur Verbindung zum
Remote-System sowie einen CATT-Benutzer zur Anmeldung im Remote Sys-
tem. Die Verbindung R/3-Gateway-R/2 muss von der Systemverwaltung
eingerichtet sein, bevor die Definition einer Gateway möglich ist.
C Zur Parameter-ID RF2 ist als Parameter eine bestimmte Destination zu defi-
nieren. Diese wird dann bei jeder Anmeldung vorgeschlagen. Der Menüweg
hierzu ist: SYSTEM pBENUTZERVORGABEN pBENUTZERPARAMETER.
244
Sandini Bib
8.7.5 RFC-Destination anlegen (R/3 – R/2)

Die Schritte 1 bis 3 erfolgen analog zu Ziffer 8.7.3.
D In den technischen Einstellungen muss der »Verbindungstyp« gewählt wer-
den, d.h. für R/2-Verbindungen Verbindungstyp 2. In einer logischen Desti-
nation (Verbindungstyp L) wird ein Bezug hergestellt zu einer bereits beste-
henden Destination, um für ein Zielsystem verschiedene Anmeldungen
(unterschiedliche Mandanten, Benutzer, Sprachen) durchführen zu können.
E Jetzt muss der Gateway, der auf Betriebssystemebene als Kommunikations-
rechner generiert ist, definiert werden.
F Das Zielsystem muss nun dokumentiert werden.
G Für die Anmeldung im Remote-System muss der CPIC-Benutzer eingetragen
werden.
8.8 Problembehandlungen
8.8.1 Tabelleninhalt prüfen (CHETAB)

Beschreibung: Nach der Ausführung von Transaktionen sollen Datenbankfort-
schreibungen überprüft werden. Dies ermöglicht die Funktion CHETAB, die
Werte aus Datenbankfeldern liest.
Vorgehen: Im Funktionseditor muss die Funktion CHETAB in der Spalte Funkt.

und der Datenbankname (Tabelle) in der Spalte Text eingetragen werden. Durch
Doppelklick auf die Zeile gelangt man auf das Detailbild zur Pflege der Feldin-
halte. Die Schlüsselfelder (ARG) müssen vollständig mit Werten gefüllt werden.
Über Alle Felder anzeigen werden die Felder des Funktionsteils aufgelistet. Hier
sind die Soll-Werte über Festwerte oder Parameter einzutragen, für die ein Soll-
Ist-Vergleich durchgeführt werden soll (Beispiel a). Ist das Ergebnis dieses Ver-
gleichs negativ, bricht der CATT-Ablauf mit einer Fehlermeldung ab. Soll ledig-
lich der Tabelleneintrag auf seine Existenz hin geprüft werden, so sind nur die
Schlüsselfelder zu füllen, aber kein Funktionsfeld (Beispiel b).
Beispiel:
a) Im ersten Schritt des Ablaufs muss überprüft werden, ob eine gegebene Plan-
kalkulation im System vorhanden ist. Die Prüfung erfolgt über die Tabelle »KE-
KO«, in welche die gegebenen Werte für die Funktionsfelder übertragen wer-
den. Nur bei Vorhandensein dieser Werte wird der CATT-Ablauf fortgesetzt.
b) Es soll überprüft werden, ob der im Baustein angelegte Kundenauftrag in die
Datenbank fortgeschrieben wurde. Über die Messagevariable &M02 wird die
Auftragsnummer in den Exportparameter &E01 gestellt. Das Vorhandensein
dieser Auftragsnummer wird in der Tabelle VBAK überprüft, weshalb der Pa-
245
Sandini Bib
8.8 Problembehandlungen
rameter &E01 in das Feld Verkaufsbeleg der Tabelle übergeben wird. Bei Vorhan-
densein der Information läuft der CATT-Test ohne Meldung weiter, bei Fehlen
der Auftragsnummer wird eine Fehlermeldung ausgegeben.
8.8.2 Verwendung von Funktionsbausteinen

Beschreibung: Funktionsbausteine sind ABAP/4-Routinen, die Grundfunktio-
nen enthalten und von jedem verwendet werden können. Innerhalb der Abläufe
bzw. Bausteine können Funktionsbausteine über die Funktion FUN aufgerufen
werden.
Vorgehen: Im Funktionseditor muss die Funktion FUN in der Spalte Funkt. und
der Name des Funktionsbausteins in der Spalte Text eingetragen werden. Durch
Doppelklick auf die Zeile gelangt man auf den Detail-Pflegebildschirm, in dem
die Schnittstellenparameter des Funktionsbausteins aufgelistet sind. Importpa-
rameter sind mit Werten zu belegen, die bereits während des Testablaufs er-
zeugt wurden. Als Exportparameter sind die Variablen anzugeben, die durch
die Verarbeitung des Funktionsbausteins mit Werten gefüllt werden sollen.
Beispiel: Der Funktionsbaustein G_CATT_CONVERT_INPUT_VALUE dient der
Konvertierung von Input-Werten und erzeugt feldnamengerecht führende Nul-
len. Im Beispiel soll die Auftragsnummer mit führenden Nullen versehen wer-
den. Importparameter ist daher die Auftragsnummer (Feldname: VBELN, Ta-
belle: VBAK) mit dem aktuellen Wert, welcher in dem Exportparameter &E01
steht. Der konvertierte Wert soll in denselben Exportparameter &E01 ausgege-
ben werden.
8.8.3 Verwendung von SET/GET-Parametern

Beschreibung: Neben dem Lesen aus Tabellen können Datenbankinhalte auch
über den SET/GET-Parameter abgegriffen werden. Dieser bezieht sich auf die
Parameter-ID, welche für manche Datenbankfelder vorhanden ist. SET/GET-
Parameter beginnen immer mit »%« und sind meist dreistellig. Jedoch können
nicht alle Parameter-IDs im CATT weiterverwendet werden.
Vorgehen: Im Funktionseditor muss die Funktion SETVAR in der Spalte Funkt.
eingetragen werden; in der Spalte Text erfolgt die Zuweisung der Parameter-ID
an eine interne Variable. Auch die umgekehrte Verwendung, nämlich dass ein
SET/GET-Parameter durch einen Importparameter neu belegt wird, ist mög-
lich. Ob für das gewünschte Dynpro-Feld eine Parameter-ID definiert ist, kann
man der Technische Info im Bereich Feld-Daten entnehmen.
Beispiel:
a) Als Absprache wird ein Lieferantenbonus angelegt. Die Nummer dieses Bo-
nus kann der Parameter-ID %VBO entnommen werden und wird im Baustein
P3004856 dem Exportparameter &E01 zugewiesen.
246
Sandini Bib
b) Für die Abrechnung eines Servicevertrages muss der korrekte Kostenrech-

nungskreis gewählt werden. Dieser ist über die Parameter-ID %CAC ansprech-
bar, der im Baustein durch den Importparameter &I06 an den richtigen Wert ge-
bunden wird.
8.8.4 Wertzuweisung aus einer Tabelle (SETVAR)

Beschreibung: Um Feldinhalte abzugreifen, können Werte aus Datenbanktabel-
len an Variablen übergeben werden. Diese Vorgehensweise ist notwendig,
wenn die gewünschten Daten nicht über Messagevariablen ausgegeben oder
Parameter-ID´s (SET/GET-Parameter) abgegriffen werden können.
Vorgehen: Im Funktionseditor muss die Funktion SETVAR in der Spalte Funkt.
und der Tabellenname in der Spalte Objekt eingetragen werden. Durch Doppel-
klick auf die Zeile gelangt man auf den Detail-Pflegebildschirm, in dem die Ta-
bellenfelder aufgelistet sind. Zunächst werden nur die Schlüsselfelder (ARG)
angezeigt. Die Anzeige der Felder des Funktionsteils (FKT) erhält man mit Alle
Felder anzeigen. In den Argumentationsteil der Tabelle ist der vollständige
Schlüssel mittels Direktwerten, Parametern oder Variablen einzutragen, d.h.,
alle Argumentfelder müssen mit Werten gefüllt werden. In die gewünschten
Felder des Funktionsteils müssen die Variablen (meist Exportparameter) einge-
tragen werden, die mit dem gelesenen Datenbankwert belegt werden sollen.
Beispiel: Zu einer Einteilung eines Kundenauftrags soll das Transportdispositi-
onsdatum gelesen werden. Dieses befindet sich in der Tabelle VBEP. Alle
Schlüsselfelder werden belegt: Der aktuelle Mandant durch die Sondervariable
&MND, der Verkaufsbeleg durch den Importparameter &I09 sowie Verkaufs-

belegposition und Einteilungsnummer über Festwerte. Das Transportdispositi-
onsdatum zu diesen Schlüsselfeldern soll in den Exportparameter &E01 einge-
lesen werden, der im Baustein definiert sein muss.
Hinweis: Die Schwierigkeit dieser Vorgehensweise liegt im Auffinden der geeig-
neten Tabelle. Es kann nur aus einer Tabelle gelesen werden, nicht jedoch aus
einer Struktur. Im günstigsten Fall kann die Tabelle über die Technische Info zu
einem Feld ermittelt werden. Führt dies nicht zum gewünschten Ergebnis, so
können Tabellen direkt im Baustein über Matchcode selektiert werden. Hierfür
muss SETVAR in die Spalte Funkt. eingetragen werden, der Cursor ist in der
Spalte Objekt zu positionieren und der Matchcode ist aufzurufen. Über Kurzbe-
schreibung kann evtl. die geeignete Tabelle ermittelt werden.
8.9 Protokoll anzeigen

Am Ende eines jeden Testlaufs wird von CATT ein Protokoll erstellt, das dem
Anwender detaillierte Informationen über das Testergebnis liefert. Wird im
Startbild angegeben, dass ein Protokoll erwünscht ist, wird es am Ende des Test-
laufs erstellt.
247
Sandini Bib
8.9 Protokoll anzeigen
Um das Protokoll zu erhalten, geht man folgendermaßen vor:

Menüpfad: HILFSMITTEL pTESTPLAN pPROTOKOLLE
In dem nun erscheinenden Selektionsbildschirm gibt man alle gewünschten Se-
lektionskritierien ein. Dann startet man den Selektionslauf. Das System erzeugt
eine Liste alle die Selektionskriterien erfüllenden Testabläufe.
Nun selektiert man einen Testablauf, indem man den Cursor auf die betreffende
Zeile positioniert und Auswählen anklickt. Daraufhin zeigt das System das zum
Testablauf gehörige Protokoll in einer hierarchisch gegliederten Struktur. Auf
dieser Ebene wird der Testablauf (bei Massenstart mehrere) bzw. der Testbau-
stein angezeigt, der in dem Testablauf ausgeführt wurde.
Wenn gewünscht, kann das Protokoll ausgedruckt werden.
8.9.1 Protokollarchiv anzeigen

Hier wird gezeigt, wie die archivierten Protokolle angezeigt werden können.
A Menüpfad: HILFSMITTEL pTESTPLAN pPROTOKOLLE
B Markieren der Option Aus Archiv lesen
C Ausführen
D Nun ist es möglich, die gewünschten Archivdateien auszuwählen.
248
Sandini Bib
CATT-Management
9
CATT bietet zur Verwaltung, Auswertung und Organisation aller erstellten, ge-
prüften und ungeprüften Testabläufe und -bausteine eine Managementfunktio-
nalität an. Mit diesem komfortablen Managementtool von CATT kann der An-
wender folgende Aktionen ausführen:
◗ Massenstart
◗ Repository-Infomationssystem
◗ Ablaufstatistik
◗ Transaktionsstatistik
◗ Rangfolgepflege
◗ Transportvorbereitung
◗ Übersichtsliste
Man gelangt über folgenden Menüpfad aus dem CATT-Einstiegsbildschirm in
das nachfolgende beschriebene CATT-Management-Tool: HILFSMITTEL pMANA-
GEMENT.
9.1 Massenstart
Diese Funktion ermöglicht es dem Anwender, automatisch mehrere Testabläufe
nach verschiedenen Selektionskriterien nacheinander zu starten. Selektiert wer-
den können dabei grundsätzlich nur CATT-Testabläufe, aber keine Testbaustei-
ne. Dem liegt die Überlegung zugrunde, dass das erfolgreiche Abspielen von
Testbausteinen im Allgemeinen auf bestimmten Customizing-Einstellungen be-
ruht, die nicht notwendigerweise vorhanden sein müssen.
249
Sandini Bib
9.2 Einzelstart
9.2 Einzelstart
Falls man Testbausteine alleine abspielen möchte, so kann man dies für einen
Testbaustein im Rahmen der CATT-Transaktion tun. Wenn das Feld »Listenver-
arbeitung erwünscht« markiert ist, kann der Benutzer aus der ausgewählten Se-
lektion einzelne CATT-Abläufe vom Massentest ausnehmen.
9.3 Selektion
9.3.1 Repository-Informationssystem
Auf dem nachfolgend abgebildeten Selektionsbildschirm (Abbildung 9.1) be-
kommt man zunächst folgende Kriterien hinsichtlich einer Auswahl von CATT-
Testabläufen angeboten:
◗ Testablaufnummer
◗ Applikation
◗ Subapplikation
◗ Komponente
◗ Verantwortlicher
◗ Erfasser oder Änderer
◗ Nutzbarkeit
Neben diesen allgemeinen Selektionskriterien, die auch bei der Suche im Repo-
sitory-Informationssystem zur Verfügung stehen wie z.B. Applikation oder Er-
fasser des Ablaufs stehen einige weitere Auswahlkriterien zur Verfügung:
◗ Laufzeitstatistik
◗ Prüfkennzeichen
◗ Varianten
◗ Rangfolgesteuerung und
◗ Durchführung
250
Sandini Bib

CATT-Repository-Informationssystem – Teil1
Kapitel 9 – CATT-Management

CATT-Repository-Informationssystem – Teil 2
251
Sandini Bib
9.3 Selektion
9.3.2 Laufzeitstatistik
Durch die Selektion über Laufzeitstatistik wird bei jedem CATT-Ablauf eine mi-
nimale, mittlere und maximale Laufzeit ausgegeben, sofern man das Feld Listen-
verarbeitung erwünscht markiert hat. Diese Daten resultieren aus vorherigen Zeit-
erfassungen, die beim Abspielen des betreffenden CATT-Ablaufs im aktuellen
System angefallen sind.
9.3.3 Laufzeitsummierung
Bei der Laufzeitsummierung werden Varianten nicht mit berücksichtigt. Das
gilt auch für Abläufe, die noch nie bzw. vor längerer Zeit im aktuellen System
gelaufen sind. Sie werden als neu eingestuft. Ist dies der Fall, liegen keine Zeit-
daten vor.
9.3.4 Listenverarbeitung
Wenn man auf dem Bildschirm das Feld Listenverarbeitung erwünscht markiert,
erscheint bei der ersten Auswahl von Ausführen eine Liste aller selektierten Te-
stabläufe. Aus dieser Liste kann man noch vor dem eigentlichen Start einzelne
Abläufe aus dem Massentest durch Markierung per Doppelklick ausschließen.
9.3.5 Abspielmodus und Protokoll

Des Weiteren ist es möglich, den Abspielmodus und die Form des Protokolls zu
bestimmen. Voreingestellt sind:
◗ ‚n‘ für dunklen Abspielmodus
◗ ‚s‘ für kurze Protokollart
Bei den Feldern Vorgang und Kurztext können Einträge vorgenommen werden,
so dass es systemseitig möglich wird, später mit der Protokollhistorie wieder
auf das erzeugte Protokoll zurückzugreifen.
Im Feld Maximale Laufzeit in Minuten legt man fest, wie viele Minuten Laufzeit
für das Abspielen der ausgewählten CATT-Abläufe zur Verfügung stehen sol-
len. Wird die vom Anwender festgelegte Grenze erreicht, so beendet das R/3-
System den aktuell abgespielten CATT-Ablauf ordnungsgemäß, und unmittel-
bar danach endet der Massentest. Alle nachfolgend geplanten CATT-Abläufe
werden nicht mehr abgespielt.
Der Vorschlagswert »0« hat keine Auswirkung auf die zur Verfügung gestellte
Laufzeit. Standardmäßig ist das Feld leer. Dies bedeutet, dass keine Laufzeitbe-
schränkung eingestellt ist.
252
Sandini Bib
Beim Protokoll ist es möglich, zwischen verschiedenen Ausgaben zu wählen:

◗ einem Langprotokoll
◗ einem Kurzprotokoll
◗ keinem Protokoll
Dem Langprotokoll entspricht der Eintrag L, dem Kurzprotokoll der Eintrag S.
Standardmäßig wird vom System der Eintrag S gesetzt. Soll kein Protokoll aus-
gegeben werden, so ist der Eintrag S ersatzlos zu entfernen.
Beim Abspielmodus kann man wählen zwischen:
◗ Hell abspielen
◗ Dunkel abspielen
◗ Dunkel abspielen bis zur ersten Fehlermeldung
Dabei entspricht Hell abspielen dem Eintrag A, Dunkel abspielen dem Eintrag N
und Dunkel abspielen bis zur ersten Fehlermeldung dem Eintrag E. Bei den Feldern
Vorgang und Kurztext kann man Einträge vornehmen, so dass man später mit
der Protokollhistorie wieder auf das erzeugte Protokoll zurückgreifen kann.
Bei allen ausgewählten CATT-Abläufen können noch andere Werte der Import-
parameter mitgegeben werden. Zu berücksichtigen ist jedoch, dass eine Verän-
derung der Parameterwerte für alle ausgewählten CATT-Abläufe greift, was
nur in Ausnahmefällen oder bei der Selektion sehr weniger, ähnlicher CATT-
Abläufe sinnvoll ist.
9.3.6 Prüfkennzeichen
Im Repository-Informationssystem besteht die Option, nur Testabläufe auszu-
wählen, die ein Prüfkennzeichen besitzen bzw. nicht besitzen. Es kann auch
nach dem Prüfzeitraum selektiert werden, in dem das selektierte Prüfkennzei-
chen vergeben wurde. Dabei kommt es unter Umständen vor, dass das Prüf-
kennzeichen zu einem Zeitpunkt vergeben wurde, der nicht in dem angegebe- Kapitel 9 – CATT-Management
nen Zeitraum liegt. Dann wird diese CATT-Prozedur nicht beim Testablauf
berücksichtigt.
Will man unabhängig vom Prüfkennzeichen CATTs selektieren, so ist es zwin-
gend erforderlich, in das Feld Prüfkennzeichen den Eintrag »*« vorzunehmen und
die beiden Prüfzeitraumfelder zu löschen. Das Prüfkennzeichen ist ein Feld in
den CATT-Attributen und dort unter dem Button VERWALTUNGSDATEN abgelegt.
Man unterscheidet beim Status zwischen:
◗ geprüft
◗ fehlerhaft
◗ ungeprüft
253
Sandini Bib
9.4 CATT-Statistik
Im Rahmen dieses Reports entspricht PASS dem Status geprüft, FAIL dem Sta-
tus fehlerhaft und KEIN EINTRAG beim Prüfkennzeichen dem Status unge-
prüft.
9.3.7 Varianten
Auch Varianten eines Testablaufs tragen ein Prüfkennzeichen. Diese Prüfergeb-
nisse der Varianten können mit einbezogen werden, indem das Kennzeichen
mit Variantenprüfkennzeichen gesetzt wird.
Das dann entstehende globale Prüfkennzeichen wird wie folgt gebildet: Ist die
Defaultparametrisierung oder eine aktive Variante im Status »ungeprüft«, so
wird der Ablauf insgesamt als »ungeprüft« bewertet. Falls der Ablauf nicht den
Status »ungeprüft« hat, so wird der Ablauf mit »Fail« bewertet, falls die Default-
parametrisierung oder mindestens eine Variante mit »Fail« bewertet worden
sind. Nur wenn die Defaultparametrisierung und alle Varianten mit »PASS« be-
wertet worden sind, liegt das globale Prüfkennzeichen »PASS« vor. Das globale
Prüfkennzeichen ist dann das Prüfdatum, das zu der Variante oder der Default-
parametrisierung gehört, die das globale Prüfkennzeichen definiert hat. Wird
das Kennzeichen mit Variantenprüfkennzeichen nicht gesetzt, so gilt das Prüf-
kennzeichen der Defaultparametrisierung mit dem zugehörigen Prüfdatum.
Wird keines der beiden Kennzeichen markiert, so wird bei allen ausgewählten
Abläufen nur die Defaultparametrisierung abgespielt. Durch Markieren des
Kennzeichens »Alle Varianten zusätzlich abspielen« werden neben der Defaultpa-
rametrisierung aller ausgewählten Abläufe auch alle aktiven Varianten mit ab-
gespielt. Wird das Kennzeichen »Nur abspielen der Variante XX« markiert, so
werden nur Abläufe selektiert, bei denen Varianten XX aktiv ist (XX steht dabei
für eine zweistellige Zahl zwischen 0 und 99). Es wird in diesem Fall die De-
faultparametrisierung nicht berücksichtigt, sondern nur die ausgewählte Vari-
ante. Das Abspielen einer ausgewählten Variante für alle selektierten Abläufe
bietet sich insbesondere dann an, wenn Klassifizierungen z.B. nach Ländern
oder Branchen sich im Parameternamen niederschlagen und alle selektierten
Abläufe diese Spezialparameter in einer einheitlichen Variantennummer abge-
legt haben.
9.4 CATT-Statistik
Hier ist zwischen
◗ Statusanalyse und
◗ an Transaktionscode und Bildschirmbildern orientierter Statistik
zu differenzieren:
254
Sandini Bib
9.4.1 Statusanalyse
In CATT kann eine Statusanalyse bezüglich aller erstellten Testbausteine und
Testabläufe durchführt werden. Dazu wird der Report RSCATSTA verwendet.
Dieser Report erstellt eine statistische Auswertung über CATT.
Über die entsprechend ausgewählte Applikation wird eine Liste mit einer Prüf-
kennzeichenauswertung ausgegeben. Sie ist abhängig vom Verantwortlichen,
dem Erfasser oder dem Änderer und der Nutzbarkeit. Ausgehend von dieser
Statusanalyseliste kann man ins Protokoll verzweigen oder die grafische Prüf-
historie aufrufen.
Abbildung 9.3 © SAP AG Kapitel 9 – CATT-Management

CATT-Statusanalyse – Selektionsbildschirm
Auf diesem Selektionsbildschirm werden CATT-Testbausteine bzw. -testabläu-

fe nach folgenden Kriterien selektiert:
◗ Applikation: SD mit inaktiven CATTs
◗ Nutzbarkeit bei Testbausteinen und Abläufen
◗ Prüfkennzeichenstatistik seit 08.01.1999
◗ Prüfsystem I40
255
Sandini Bib
9.4 CATT-Statistik
Nach Auswahl des Befehls »Ausführen« dieser Selektion erscheint das folgende
Übersichtsbild:

CATT-Statusanalyse – Auswertung Teil 1
Durch Rechtsscrollen wird die in Abbildung 9.4 zu sehende Übersicht vervoll-

ständigt:
256
Sandini Bib

CATT-Statusanalyse – Auswertung Teil 2
Nach Doppelklick auf Zeile 3 »Fakturabearbeitung« die erscheint folgende Ge-

samtübersicht der in CATT hinterlegten Testabläufe das Modul SD betreffend.
K1101131 Faktura anlegen zu Gutschrift
K1101223 VF01 : Faktura (mit Vorgabedatum)
K1101306 VF01 : Faktura (mit Vorgabedatum)
K1101309 Faktura ändern - Rechnung ausgeben
K1101318 Hinzufügen Faktura
K1101333 Faktura ändern - Rechnung ausgeben
K1101591 Faktura anlegen mit Buchhaltung K1102028 VIS

Grobtest : Statistikfortschreibung
K1102041 VIS : Stornierung Faktura
S1100231 VIS : Retouren-Gutschrift
S1100232 VIS : Stornieren Faktura
S1100262 VIS : ändern Faktura (VF02)
S1100886 VF01 : Anlegen Faktura (allgemein)
S1100887 VF11: Stornieren Faktura (allgemein)
S1106601 Belegfolge - Export-Faktura
257
Sandini Bib
9.4 CATT-Statistik
9.4.2 An Transaktionscode und Bildschirmbildern

orientierte Statistik
Anhand des Report RSCADYST kann diese Statistik erstellt werden.
Hier handelt es sich um eine Statistik, welche einen detaillierten Überblick über
die Anzahl der Transaktionen und Dynpros gibt, die bei den ausgewählten
CATT-Testabläufen bzw. Testbausteinen aufgerufen werden. Dies ist insbeson-
dere beim Massenstart von CATTs hilfreich.
Für jede Applikation kann ermittelt werden, wie viele Testabläufe sich auf die-
selbe beziehen, wie viele Transaktionen in den selektierten Testabläufen abge-
arbeitet worden sind und wie viele verschiedene Bildschirmbilder jeweils dazu-
gehören.
Das System liefert eine Liste, die noch weiter aufgeschlüsselt werden kann. So
erhält man Informationen über die historische Entwicklung der entsprechenden
Testabläufe, Transaktionen und Dynpros pro Applikation, Subapplikation und
Komponente wahlweise entweder in grafischer Form oder als Protokoll.
Auf dem Selektionsbildschirm kann die Auswahl der CATTs bestimmten Krite-
rien unterworfen werden:
◗ Applikationen, denen die einzelnen CATTs zugeordnet sind (AM, BC, CO,
FI, HR, IM, LX, MM, PM, PP, PS, QM, RC, RW, SD)
◗ ob es sich um Testbausteine, um Testabläufe oder um beides handelt
◗ nach Nutzbarkeit gemäß Anwendungs-, Plattform- oder Individual-CATTs
oder ob keine Einschränkung bezüglich der Nutzbarkeit vorgenommen wer-
den soll
◗ nach Erfasser, Änderer, Verantwortlichem der CATTs
◗ gemäß Prüfkennzeichen (PASS, FAIL oder UNGEPRÜFT) der CATTs wahl-
weise mit oder ohne Berücksichtigung der vorhandenen aktiven Varianten
Die Ausgabe der Ergebnisse dieses Reports erfolgt auf einer Liste über den Bild-
schirm, die für jede Applikationen die Anzahl der zugeordneten CATTs und der
dabei abgearbeiteten Transaktionen und Dynpros angibt. Durch Doppelklick
kann die Liste aufgeblättert werden, und man kann sich die Anzahl der Trans-
aktionen detailliert unter dem Aspekt von Subapplikation und Komponenten
aufzeigen lassen.
Mit der Drucktaste CATTS ANZEIGEN ist es möglich, sich die entsprechenden
CATTs anzeigen zu lassen. Dabei erscheint ein Dialogfenster, in dem man einen
oder auch mehrere der aufgelisteten Testabläufe in das Hauptmenü überneh-
men und dort mit der Drucktaste MASSENTEST STARTEN ablaufen lassen kann.
258
Sandini Bib
Für jede Applikation, Subapplikation oder Komponente kann man sich die ent-
sprechenden Transaktionen oder Dynpros anzeigen lassen. In einem weiteren
Dialogfenster werden diese aufgezeigt, und zwar einschließlich der Angabe,
wie oft die entsprechende Transaktion bzw. das entsprechende Dynpro insge-
samt aufgerufen wurde und wie viele CATTs diese Transaktion direkt aufrufen.
Von hier aus gelangt man mit der Auswahl CATTS ANZEIGEN wiederum auf das
Dialogfenster zur Übernahme für den Massenstart.
Bei der Auswahl der Drucktaste MASSENTEST STARTEN werden in einem Dialog-
fenster die ausgewählten CATTs angezeigt, die daraufhin weiter eingeschränkt
werden können. Bei AUSFÜHREN erscheint ein weiteres Dialogfenster, mittels
dessen man den Abspielmodus, die Protokollart und die Abspielparametrisie-
rung einstellen kann. Bei der Abspielparametrisierung kann man wählen, mit
welchem Parametern die CATT-Abläufe abgespielt werden sollen: mit den De-
faultparametern, mit allen Varianten oder mit beiden.
Ein wiederholtes Anklicken von AUSFÜHREN startet die CATT-Abläufe.

CATT-Transaktionsstatistik – Selektionsbildschirm
259
Sandini Bib
9.4 CATT-Statistik
Hier trägt man nun beispielhaft folgende Daten ein:

◗ Anwendung: SD
◗ Kennzeichen: Testbaustein + Testablauf
◗ Nutzbarkeit: Individualtest, Anwendungstest, Plattformtest
◗ Prüfkennzeichen: PASS, FAIL, Ungeprüft, mit Varianten
Nach Betätigung des Buttons AUSFÜHREN erscheint das folgende Dynpro:

CATT-Transaktionsstatistik – Auswertung
Für die Anwendung SD – Vertrieb wurden dieser Liste zufolge aus der Tabelle
CATA 169 Testabläufe bzw. Testbausteine selektiert. Diese ausgewählten
CATTs ruften direkt und auch indirekt (also durch CATTs, auf welche sie refe-
rieren) 60 verschiedene Transaktionen und 345 verschiedene Dynpros auf.
Aus obigem Dynpro heraus können folgende Daten ermittelt werden:
◗ Nummer des entsprechenden CATT-Testablaufs bzw. -testbausteins, der Er-
fasser und Verantwortliche des CATTs sowie das jeweilige Prüfkennzeichen,
welches detaillierten Aufschluss über den Testzustand des entsprechenden
Ablaufs gibt
260
Sandini Bib
◗ die Transaktionscodes der Transaktionen, die in den selektierten CATT-Test-

bausteinen bzw. -abläufen referenziert werden
◗ über die in jeder referenzierten Transaktion durchgelaufenen Dynpros
◗ Die selektierten CATTs können über die Funktionalität des Massentests aus
dem obigen Selektionsbildschirm heraus einem solchen unterzogen werden
Dazu stellt man nun den Cursor auf die entsprechende Zeile und wählt durch
Anklicken eines Buttons die jeweilige Funktion.
Nach bestimmten Einstellungen auf dem Selektions-Bildschirm für die Anwen-
dung CO – Controlling erhält der Anwender auf dem Bildschirm folgende Liste:
Abl./Ben. Transakt. Dynpros
CO Controlling 56 19 59
Für die Anwendung CO – Controlling wurden also dieser Liste zufolge aus der
Tabelle CATA 56 Abläufe bzw. Testbausteine selektiert. Die ausgewählten
CATTs rufen direkt und auch indirekt (also durch CATTs, auf welche sie refe-
rieren) 19 verschiedene Transaktionen und 59 verschiedene Dynpros auf.
Stellt man nun den Cursor auf die Zeile mit den Zahlenangaben und wählt man
die Funktion »Transaktion anzeigen«, erscheint ein Dialogfenster mit folgendem
Inhalt:
Transaktion Aufrufe Aufrufe direkt CATTs
MRO1 Eingangsrechnung 29 9 4
Bearbeiten
MBO1 Wareneingang 26 1 1
Zur Bestellung buchen
9.5 CATT-Rangfolge-Pflege Kapitel 9 – CATT-Management
Beim Massentest von CATT-Abläufen ist es teilweise erforderlich, einige CATT-

Abläufe vorher zu starten, damit entsprechende Voreinstellungen durchgeführt
werden können, und bestimmte CATT-Abläufe erst im Rahmen eines Nach-
spanns zu definieren. Diese Einstellungen können mittels des Reports RS-
CATVSP vorgenommen werden. Wird dann der CATT-Massentest-Report
RSSTARCWC ausgeführt, so werden die CATT-Abläufe in der festgelegten Rei-
henfolge abgespielt.
261
Sandini Bib
9.5 CATT-Rangfolge-Pflege

CATT-Rangfolge-Pflege – Selektionsbildschirm
Sollen mehrere CATT-Abläufe als Vor- oder Nachspann definiert werden, so ist
dies über die so genannte »Rangfolge-Pflege« möglich. Man kann hier für eine
Auswahl von Testabläufen die Rangfolge festlegen. Falls die Rangfolgesteue-
rung eingestellt wurde, werden alle CATT-Abläufe gemäß der eingestellten Se-
lektion ausgewählt. Befinden sich darunter CATT-Abläufe mit Vor- oder Nach-
spannkennzeichen, werden diese berücksichtigt und in entsprechend geordneter
Reihenfolge abgespielt.
Wird das Feld Totalvorspann/Totalnachspann markiert, so werden zusätzlich und
unabhängig von der eingestellten Selektion alle CATT-Abläufe mit hinzuge-
nommen, die ein Vorspannkennzeichen »1« oder »2« oder ein Nachspannkenn-
zeichen »8« oder »9« tragen.
Möchte man auch CATT-Abläufe mit Vorspannwert »3« oder »4« auswählen,
müssen diese der Selektion genügen. Will man viele Testabläufe gleichzeitig als
Vor- oder Nachspann definieren, kann man dies für eine bestimmte Anwen-
dung durch die Auswahl der Funktion CATT-Rangfolgepflege-Vor-/Nachspann
durchführen. Alternativ kann auch direkt ein Eintrag auf dem Attributspflege-
bildschirm des jeweiligen Testablaufs vorgenommen werden.
262
Sandini Bib
Ist der Berater mit der angebotenen Reihenfolge nicht einverstanden, so besteht
die Option, innerhalb der CATT-Attribute das Feld Kontext zu markieren und
einen Wert zwischen 1 und 4 zu vergeben. Dabei bedeutet 1 die höchste Vor-
spannstufe und 4 die niedrigste Vorspannstufe. Für den Nachspann sind Werte
zwischen 6 und 9 vergebbar.
Mittels des Reports RSCATVSP können CATT-Abläufe als Vorspann oder als
Nachspann definiert werden. Diese CATT-Abläufe werden dann vor bzw. nach
der ausgewählten Selektion gestartet. Von den angebotenen vier Rangfolge-
steuerungen ist höchstens eine auszuwählen. Andernfalls wird eine Fehlermel-
dung ausgegeben. Wird keine Rangfolgesteuerung gewählt, so werden alle
CATT-Abläufe gemäß der eingestellten Selektion mit einbezogen. Befinden sich
darunter CATT-Abläufe mit Vorspann- oder Nachspannkennzeichen, so wer-
den diese berücksichtigt und in geordneter Reihenfolge abgespielt.
9.6 CATT-Transportvorbereitung
Der Report RSCATTRA ermöglicht es, mehrere Testabläufe in einen gemeinsa-
men Auftrag zu stellen und zu transportieren. Dabei werden alle zu einem Test-
ablauf gehörenden Testbausteine in den gleichen Auftrag eingetragen, sofern
der Testablauf weiterhin den Auswahlkriterien entspricht. Aus dem Auftrag
kann man einzelne Testabläufe herausnehmen, indem man in der angezeigten
Liste einen Doppelklick auf den betreffenden Testablauf ausführt.
Alle zu einem Ablauf gehörigen Modelle werden mit in die Korrektur eingetra-
gen, sofern der Ablauf ausgewählt bleibt. Wird »Laufzeit« markiert, so besteht
für den Anwender die Möglichkeit, auch Laufzeiten der CATTs bei der Zusam-
mensetzung der Korrektur zu berücksichtigen.
Wird »Neuer Abl. Einschl. verw. Modelle« markiert, so werden nur Abläufe, die
der Selektion entsprechen, einschließlich aller verwendeten Modelle mit in die
Korrektur eingebunden.
Falls die Taste »Nur abl. Einschl. verw. Modelle« nicht markiert wird, so werden
auch neben den Abläufen (einschl. verwendeter Modelle) auch alle Modelle
(einschließlich aller verwendeten Modelle) in die Korrektur eingebunden.

Beim Prüfkennzeichen sind folgende Einträge erforderlich:
◗ PASS: nur erfolgreich gelaufene CATTs
◗ FAIL: nur fehlerhaft gelaufene CATTs
◗ LEERZEICHEN: nur ungeprüfte CATTs
◗ *: keine Berücksichtigung des CATT-Prüfergebnisses
Es wird hier eine Liste von CATT-Abläufen angeboten, aus der einzelne Abläufe
noch aus der Korrektur herausgenommen werden können.
263
Sandini Bib
9.7 Übersicht

CATT-Transportvorbereitung – Selektionsbildschirm
9.7 Übersicht
Eine Liste der Testabläufe, Testbausteine und manuellen Testfälle kann im Rah-
men des CATT-Managements separat oder gemeinsam in einer Funktionsliste
generiert werden. Die Objekte sind gemäß ihrer Zuordnung in der Funktions-
liste (Felder: Applikation, Subapplikation, Komponente) sortiert. Auf dem Selekti-
onsbildschirm können Testabläufe, Testbausteine und manuelle Testfälle ent-
weder einzeln oder gemeinsam gemäß ihrer Zuordnung in die Funktionsliste,
also entsprechend ihrer Einträge in den Feldern Applikation, Subapplikation und
Komponente selektiert werden. Zusätzlich kann noch der Erfasser angegeben
werden.
264
Sandini Bib

CATT-Übersichtsliste – Selektionsbildschirm
In der anschließend erzeugten Liste werden die nach der Applikation sortierten
und selektieren Objekte angezeigt. Diese Liste zeigt pro Eintrag den Kurztext
und den Erfasser. Falls es sich um einen manuellen Testfall handelt, wird der
Text »manuell« nach der Spalte »Erfasser« angezeigt. Der Text »freig« kenn-
zeichnet einen Testbaustein, der das Freigabekennzeichen enthält. Testbaustei-
ne ohne Freigabekennzeichen enthalten keinen Eintrag in dieser Spalte.
Die vom System angegebene Liste sehen Sie in Abbildung 9.11. Kapitel 9 – CATT-Management
Testabläufe werden mit einem grafischen Kennzeichen in dieser Spalte verse-
hen. Es enthält drei Punkte mit unterschiedlichen Farben, die das Ergebnis der
Prüfkennzeichenvergabe darstellen, wobei grün bedeutet, dass der Testablauf
erfolgreich gelaufen ist. Rot kennzeichnet eine beim Starten fehlerhaft gelaufe-
nen Testablauf und gelb zeigt einen ungeprüften Testablauf. Als weitere Funk-
tion kann über den Eintrag »Auswählen« im Menü Bearbeiten direkt in das in der
Zeile positionierte Objekt verzweigt werden. Durch einen Doppelklick auf das
Ampelsymbol verzweigt das System in den Attributspflegebildschirm des je-
weiligen Testablaufs bzw. -bausteins.
265
Sandini Bib
9.7 Übersicht

CATT-Übersichtsliste – Auswertung
a) Manueller Testfall
Der Text wird als manuell hinter der Spalte Erfasser gekennzeichnet.
b) Testbausteine
Testbausteine mit Freigabezeichen erhalten den Eintrag freig.
Testbausteine ohne Freigabezeichen erhalten keinen Eintrag.
c) Testabläufe
Den Angaben auf der gezeigten CATT-Liste zufolge ist der CATT-Testablauf
S1106601 Belegfolge – Export Faktura in SD beim Testen auf einen Fehler gelau-
fen. Hier ist eine Nachbearbeitung des Testablaufs unbedingt erforderlich.
Der Testablauf P3004192 Testablauf Damrath ist ungeprüft.
Folgende Funktionen können aus obiger CATT-Liste heraus angestoßen werden:
◗ Der Inhalt der CATT-Liste kann gedruckt werden. Der Menüpfad hierzu lau-
tet CATT pDRUCKEN.
◗ Die Daten dieser Liste können natürlich auch direkt in einer PC-Datei gesi-
chert werden. Dazu ist folgender Menüpfad zu wählen: CATTp SICHERN in
PC-Datei.
266
Sandini Bib
◗ Aus der vorliegenden Übersichtsliste heraus ist es möglich, in die einzelnen

Testbausteine bzw. Testablaufe zu verzweigen.
◗ Die angezeigten Testbausteine bzw. –abläufe können auch direkt von hier
aus gestartet und geändert werden
◗ Ein Protokoll kann aus dem Archiv geholt werden. Dazu ist Folgendes zu
tun: JEWEILIGEN CATT MARKIEREN p PROTOKOLL ANKLICKEN. Das ausgewähl-
te Protokoll wird dann angezeigt.
267
Sandini Bib
Sandini Bib
Verwaltung von
CATT-Testfällen
10
In allen Phasen eines R/3-Projekts sind intensive Testzyklen mit Funktions- und
Akzeptanztests für den Erfolg des Projekts sehr wichtig. Dies beginnt mit der
Neueinführung eines R/3-Systems und setzt sich bei der ständigen Anpassung
des Systems an die Kundenanforderungen durch Customizing, Modifikation
und Eigenentwicklung fort. Die Durchführung von Tests ist bei R/3-Einfüh-
rungsprojekten also eine sehr wichtige Aktivität, die dabei hilft, das Risiko zu
minimieren, dass Fehler den Geschäftsnutzen verringern. Ziel beim Testen von
Software ist es also, Fehler in derselben zu finden. Ein Fehler wurde gefunden,
wenn bei der Testdurchführung das erwartete Ergebnis (Sollergebnis) nicht mit
dem tatsächlichen Ergebnis (Ist) übereinstimmt. Ein Testvorhaben war erfolg-
reich, wenn es entweder vorhandene Fehler aufgedeckt hat bzw. die Fehlerfrei-
heit der Software gezeigt hat. Zur Unterstützung des Testens stellt die SAP AG
zwei Werkzeuge zur Verfügung: Das bereits beschriebene Computer Aided
Test Tool zum Erstellen, Verwalten, automatischen Ausführen und Protokollie-
ren von Testabläufen und die so genannte »Testworkbench« . Ebenso wie CATT
wird auch die Testworkbench von der SAP AG zusammen mit dem R/3-System
ausgeliefert. Diese Testworkbench wurde entwickelt, um die Fehleraufdek-
kungsrate zu erhöhen. Es handelt es sich dabei um ein Tool zum Planen, Kon-
trollieren und Dokumentieren von Testvorhaben. Automatische Tests, manuel-
le Tests und auch externe Anwendungen, die mittels CATT erstellt wurden,
können anhand der Testworkbench organisiert und verwaltet werden. Dabei
werden die Testszenarien in Testkataloge, Testpläne und Testpakete gegliedert.
Des Weiteren können Dokumentationen zu den Tests in die Testworkbench ein-
gebunden werden. Der Testadministrator plant den gesamten Testvorgang.
Dazu erstellt er die so genannten Testkataloge, von denen ausgehend bis zu den
Testpaketen, welche an die diversen Testausführenden vergeben werden, wei-
ter unterteilt wird. Dies ist natürlich nur dann sinnvoll, falls neben dem Testad-
ministrator noch weitere testende Personen eingesetzt werden.
269
Sandini Bib
10.1 Testkatalog
Die Testworkbench ermöglicht mit all diesen Funktionen eine komfortable Pfle-
ge der verschiedenen Testszenarien über die jeweils aktuelle Release-Version
hinaus. Sie soll folgende Aufgaben erfüllen:
◗ klare Spezifikation der Testvorgaben
◗ vollständige Dokumentation der Testdurchführung
◗ Erstellung einer Testauswertung
◗ Durchführung von Nachtests gewährleisten
Der Einsatz dieses Werkzeugs lohnt sich den Erfahrungen aus der Praxis zufol-
ge schon bei einer kleinen Menge von Testabläufen, weil man bereits hier alle
Testabläufe in einer klaren Form strukturieren kann. Dabei muss folgende Rei-
henfolge bei der Bearbeitung eingehalten werden:
◗ Schritt 1:
Anlegen des Testkatalogs
◗ Schritt 2:
Struktur des Testkatalogs bestimmen
◗ Schritt 3:
CATT-Testabläufe in den Testkatalog einbinden
◗ Schritt 4:
Anlegen des Testplans
◗ Schritt 5:
Anlegen des Testpaketes
◗ Schritt 6:
Zuweisung des Testpakete an den Testausführenden
◗ Schritt 7:
Ausführung der Testpakete
◗ Schritt 8:
Durchführung einer Statusanalyse nach dem Testende
Im Folgenden wird nun jeder dieser Schritte beschrieben.
10.1 Testkatalog
Der Testkatalog ist die oberste Gliederungsform innerhalb der Testworkbench.
Im Testkatalog werden vom Testkoordinator alle Testfälle zusammengefasst.
Die Testfälle werden dabei in einer Baumstruktur, wie sie bereits vom IMG her
bekannt ist, dargestellt. Der Testkatalog ist demnach die Sammlung aller objekt-
bezogenen Testfälle. Er bildet damit auch die Basis aller Testaktivitäten. Im Test-
katalog können sowohl automatisierte als auch manuelle Testfälle verwaltet
werden. Nicht automatisierbare Testvorgänge, wie z.B. technische Tests, lassen
270
Sandini Bib
sich in Form von Testfallbeschreibungen im R/3-Testkatalog aufbereiten und

archivieren. Manuell werden z.B. Testfälle abgewickelt, die eine große Anzahl
von Datenelementen benötigen und bearbeiten, wie bei diversen Listauswer-
tungen. Zusammen mit automatisch ablaufenden CATT-Abläufen werden die
zu prüfenden, umfangreichen Dateninhalte in der erforderlichen Weise aufbe-
reitet. Somit entstehen letztlich halbautomatische Testprozeduren, bei denen
nach einem automatischen Start lediglich nach deren Abschluss ein manueller
Check dieser Dateninhalte notwendig ist.
Dieser R/3-Testkatalog lässt sich jederzeit ohne aufwendiges und zeitrauben-
des Customizing verwenden. Zudem ist eine flexible Anpassung, Erweiterung
und Veränderung der darin enthaltenen manuellen und automatisierten Test-
bausteine aufgrund des äußerst übersichtlichen Katalogdesigns möglich. Die
bestehenden, in der Praxis sehr gut nutzbaren Funktionalitäten des Testkatalogs
decken alle Anforderungen im Rahmen eines konsequent betriebenen Testma-
nagements innerhalb von R/3-Projekten höchst komfortabel ab.
In Abhängigkeit davon, zu welchem konkreten Zweck der Testkatalog einge-
setzt werden soll, ist es empfehlenswert, die Gliederung des Testkatalogs in un-
terschiedlich feinen Stufen vorzunehmen.
10.1.1 Integration automatischer Tests mit CATT-Abläufen

Wenn der Testkatalog im Wesentlichen dafür genutzt werden soll, CATT-Ab-
läufe zu verwalten, ist der Testkatalog am besten nur so fein zu gliedern, dass
die CATTs in hierarchisch korrekter Weise eingegliedert werden können. Dies
hat folgenden Vorteil: Es ist möglich, CATT-Abläufe im Modus HELL als Lern-
hilfe abzuspielen.
Kapitel 10 – Verwaltung von CATT-Testfällen

10.1.2 Integration manueller Tests
Zunächst sollte der Testbaum bis zur kleinsten überschaubaren Testeinheit ver-
feinert werden. Die oberste Ebene enthält dabei die Kurzinformationen über das
gesamte Testvorhaben. Auf der nächsttieferen Stufe werden die Testfälle einge-
ordnet. Die detaillierte Beschreibung der Testfälle erfolgt dann auf den darun-
terliegenden Stufen.
Im Testkatalog können aber auch Testanweisungen sowohl für manuelle Test-
fälle als auch automatisierte CATT-Abläufe gleichzeitig in das jeweilige Test-
szenario integriert werden. Eine solche Mischung ist zum Beispiel immer dann
ganz sinnvoll, wenn die CATT-Abläufe zu Beginn des Testszenarios wichtige
Daten erzeugen, welche die Grundlage für die folgenden, manuellen Tests bil-
den.
271
Sandini Bib
10.1 Testkatalog
Bevor man nun einen Testkatalog erstellt, ist das Testszenario detailliert zu pla-
nen. Hier sind folgende Fragen zu klären:
◗ Wer ist für die Testdurchführung verantwortlich?
◗ Welche Testfälle sind im Testszenario enthalten?
◗ Wie sollen die Testfälle strukturiert werden?
◗ Ist die geplante Unterteilung der Testfälle sinnvoll?
◗ Handelt es sich um manuelle und/oder automatische Tests?
◗ Greift ein Testfall auf andere Testergebnisse zurück?
◗ Wenn ja, auf welche?
◗ Bildet der Testkatalog eine prozessorientierte oder eine funktionsorientierte
Sicht ab?
◗ Wie sollen die Testfälle dokumentiert und ausgewertet werden?
Bei der Testplanung ist zu berücksichtigen, dass viele Tests auf den Ergebnissen
von zuvor durchgeführten Tests aufbauen. Die prozessorientierte Sicht ist in
häufigen Fällen eine gute Basis für die Planung des Testkatalogs. In einigen Fäl-
len kann aber auch die funktionsorientierte Sicht eine gute Ausgangsposition
für die Planung sein. Ein Testkatalog ist eine baumartig strukturierte Menge von
Testfällen. Er besteht aus Knoten und Wurzeln. Diese Baumstruktur stellt dabei
eine sinnvolle Untergliederung von Testabläufen oder (manuellen) Testfällen
dar.
10.1.3 Erstellung eines Testkataloges

Nachdem man in der Planungsphase ein detailliertes Testszenario erstellt hat,
ist dieses in einen Testkatalog umzusetzen.
A Zunächst verzweigt man dazu von der ABAP/4 Development Workbench
aus über TEST p TESTWORKBENCH p TESTORGANISATION p TESTKATALOG VER-
WALTEN in den Einstiegsbildschirm für die Pflege von Testkatalogen.
B Hier ist nun der Name des anzulegenden Testkatalogs einzugeben.

C Im nächsten Schritt wird die Funktion Anlegen betätigt.
D In dem nun erscheinenden Dialogfenster gibt man einen Titel für den Test-
katalog ein, z.B. Testkatalog Nr. 1.
E Nun sichert man die Eingaben.
272
Sandini Bib
10.1.4 Untergeordneten bzw. gleichgeordneten Knoten

hinzufügen
Über die Funktion Testkatalog ändern können die Testkataloge durch das Einfü-
gen von Knoten gegliedert werden.
A Dazu stellt man den Cursor auf das Objekt, zu dem man einen untergeord-
neten bzw. gleichgeordneten Knoten anlegen will.
B Man wählt die Funktion Als Unterknoten bzw. Auf gleichem Niveau.
C Jetzt wird dem Knoten ein Text oder ein Objekt zugeordnet. Folgende Objek-
te können einem Knoten zugeordnet werden:
Feld Bedeutung
Kurztext Kurzbeschreibung des Knotens bzw. Testfalls
Gliederungsknoten Knoten ohne weitere Funktion wird eingefügt
Manueller Testfall Man verzweigt in die Pflegetransaktion für CATT-Objekte

und kann einen manuellen Testfall anlegen
Automatischer Testfall Man kann einen automatischen Testfall anlegen
Externe Anwendung Man kann eine externe Anwendung einbinden
Testfall Ein existierendes CATT-Objekt (Testbaustein bzw. Testab-

lauf) kann eingebunden werden.
Testkatalog Ein kompletter Testkatalog kann als Knoten in den Testka-

talog eingebunden werden.

Dokument Ein bereits existierender Dokumentationsbaustein kann
eingebaut werden.
Release Note Informationen zum Release können hinterlegt werden.
IMG-Aktivität Eine bereits existierende IMG-Aktivität kann eingebaut

werden.
Nachdem CATT-Abläufe in den Testkatalog eingebunden wurden, erscheint

ein Icon, welches zum Starten einzelner CATT-Abläufe benutzt werden kann.
Im Testkatalog wird zusätzlich auf der Ebene des übergeordneten Knotens ein
Icon zum Starten aller untergeordneten Abläufe sichtbar.
Ein Testkatalog sieht z.B. folgendermaßen aus:
273
Sandini Bib
10.1 Testkatalog

Testkatalog YTEST1
10.1.5 Tests aus dem Testkatalog heraus starten

An jedem Knoten im Testkatalog, an dem ein CATT-Ablauf hängt, erscheint ein
Startsymbol. Durch ein Doppelklick auf ein ausgewähltes Startsymbol werden
alle in der Baumstruktur unterhalb des selektierten Startsymbols angeordneten
CATT-Abläufe gestartet. Des Weiteren kann man hier ebenso wie im CATT-Ma-
nagement zwischen Einzelstart und Massenstart wählen.
Im Allgemeinen sind vorbeschriebene Testkataloge sehr groß und umfangreich,
so dass sie der Übersichtlichkeit halber auch in Testpläne und Testpakete einge-
teilt werden können. Diese Sammlung von Tests stellt jedoch nur eine Sicht auf
den jeweiligen Testplan dar. Änderungen in den Testfällen oder neue Testfälle
sind immer im Testkatalog vorzunehmen bzw. einzubinden. Testfälle können
auch in mehreren Testplänen oder Testpaketen vorkommen.
274
Sandini Bib
10.2 Testplan
Testpläne werden aus dem Testkatalog heraus generiert und stellen in der Regel
eine einmal benötigte release- und zweckbezogene Teilmenge an Testfällen dar.
Folglich bilden sie eine Teilsicht auf den gesamten Testkatalog ab. Sie werden
vom Testkoordinator eingeteilt. Mit den R/3-Testplänen kann der Status jeder
beliebigen Testaktivität während deren Durchführung bis auf die unterste Ebe-
ne, also bis auf die Ebene einzelner konkreter Testfälle, verfolgt werden. Sind in
diesem Zusammenhang OSS-Problemmeldungen (OSS = Online-Service-Sys-
tem) erforderlich, so können hierzu entsprechende Querverweise angelegt wer-
den. Reports über den Testverlauf dienen hierbei der Analyse, Steuerung und
auch Bewertung der einzelnen Testvorgänge.
Mit den drei Säulen CATT, R/3-Testkatalog und den Testplänen kann z.B. im
Rahmen von Releasetests das von Release zu Release kontinuierlich wachsende
Regressionstestpaket gepflegt werden. Alle in diesem Kontext wichtigen Test-
fälle funktionsbezogener Art können demnach in die Tests der folgenden Re-
leases in standardisierter Form mit einbezogen werden
Ein Testplan ist eine Teilmenge des Testkatalogs. In der Regel wird der Testplan
nur einmal benötigt. In ihm werden die Testfälle nach Testzwecken (zeitraum-
und zweckbezogen) organisiert. Zeitraumbezogen bedeutet dabei, dass der Test-
plan z.B. zum Testen einer bestimmten Releaseversion erstellt wird. Zweckbezo-
gen meint, dass sich der Testplan einem bestimmten Thema des Testkatalogs wid-
met, z.B. allen Transaktionen, die dem Erstellen eines Kundenauftrages folgen.
10.2.1 Erstellung eines Testplan

A Ausgehend von der ABAP/4-Development-Workbench gelangt man über

den Menüpfad TEST p TESTWORKBENCH p ORGANISATION p TESTPLAN ANLE-
GEN in die entsprechende Transaktion.
B Nun gibt man den Namen des Testkatalogs an, zu dem man einen Testplan
erstellen möchte.
Beispiel:
Testkatalog YTEST 1 Testkatalog Nr. 1
C Der Name für den zu erstellenden Testplan wird ebenfalls in das entspre-
chende Feld eingetragen.
Beispiel:
Testplan YTESTPLAN 1 Testplan Nr. 1 zum Testplan Nr. 1
D Nun wird die Funktion Anlegen ausgeführt.
275
Sandini Bib
10.2 Testplan
E Daraufhin erscheint ein Dialogfeld. Dort gibt man eine Kurzbeschreibung für
den Testplan ein. Die Angaben zum Testkatalog wurden bereits vom System
automatisch eingetragen.
Beispiel:
Testplan YTESTPLAN 1 Testplan Nr. 1 zum Testkatalog Nr. 1
F Dieses Dynpro muss nun durch Betätigen des grünen Hakens bestätigt wer-
den.
G In der Gruppe Auswahl betätigt man nun den Auswahlknopf manuelles Mar-
kieren und führt die Funktion Weiter aus. Daraufhin erscheint die Baumstruk-
tur des angegebenen Testkatalogs.
H Die Teilbereiche in der Baumstruktur, die in den Testplan integriert werden
sollen, werden nun markiert, z.B. SD – Sales and Distribution. Anschließend
wählt man die Funktion Testplan generieren. Damit wird ein Testplan erzeugt,
der nur den Vertriebsbereich betreffende Testbausteine und Testabläufe zum
Inhalt hat.
Diese generierten Testpläne können weiter verfeinert, also in Testpakete unter-
gliedert werden.

Testplan anlegen – Auswahl des Bereichs SD
276
Sandini Bib
10.3 Testpaket
Auf der Basis der vorbeschriebenen Testpläne können wiederum Testpakete er-
zeugt werden. Diese Testpakete werden letztendlich den Testern zugeordnet.
Aus dem Testplan werden die relevanten Tests für das Testpaket ausgewählt.
Testpakete können einem oder mehreren Testausführenden zugeordnet wer-
den, die dann die im Testplan spezifizierten Testfälle durchführen.
Aus den Testkatalogen, Testplänen und auch Testpaketen heraus können die
Testabläufe und -bausteine gestartet werden. Neben dem von CATT erstellten
Testprotokoll führt die Testworkbench auf der Ebene der Testpakete eine Sta-
tuspflege durch, und das nur dort. Kommt ein Testfall in mehreren Testpakten
vor, so führt das System eine voneinander unabhängige mehrfache Statuspflege
durch. Der Testadministrator erhält anhand der Statusinformationen der Test-
pakete eine Übersicht über den Gesamtstatus des Tests. Nach jedem Test besteht
die Möglichkeit, ein Protokoll über den Test anzulegen.
10.3.1 Anlegen eines Testpaketes:

Das Anlegen eines Testpaketes erfolgt analog zu den Schritten zum Anlegen ei-
nes Testplanes.
10.4 Testdurchführung
A Über den Menüpfad WERKZEUGE p ABAP/4 WORKBENCH gelangt man vom
R/3-Startbildschirm in die ABAP/4-Workbench.
B Nun verzweigt man mit TEST p TESTWORKBENCH p TESTDURCHFÜHRUNG in die

Testtransaktion. Hier wird vom System automatisch eine Übersicht über alle
Testpakete, für die man als Tester eingetragen ist, generiert.
C Die Testtransaktion muss nun ausgewählt und gestartet werden. Als Test-
transaktionen werden der Testkatalog, der Testplan und das Testpaket be-
zeichnet.
D Auswahl des Testpaketes XXXX, in dem man auf das Icon für Ausführen
klickt.
E Nun expandiert man die Struktur mit der Funktion BEARBEITEN p ALLE UN-
TERKNOTEN.
F Ausführung des Tests

G In diesem Schritt ist der Status des Tests zu setzen, in dem die Funktion Sta-
tus bearbeiten gewählt wird. Dort soll eine Statusbezeichnung sowie eine Be-
arbeiternotiz hinterlegt werden. Ist ein Nachtest einer Testaktivität erforder-
lich, markiert man die Art des Nachtests. Ein internes Problem bzw. eine
Anfrage eines Kunden kann hier gegebenenfalls erfasst werden.
277
Sandini Bib
10.5 Statusanalysen durchführen
Diese vorstehend geschilderten Schritte im Rahmen eines Tests von CATT-Test-

bausteinen bzw. Testabläufen kann für jeden Testfall analog angewandt wer-
den. Besonders komfortabel werden die Ergebnisse der Testaktivitäten natür-
lich dann, wenn zu jedem einzelnen Testfall eine ausführliche Dokumentation
hinterlegt wird. Die Statuspflege ist in diesem Kontext natürlich sehr wichtig.
Eine sorgfältige Dokumentation sowie eine entsprechende Pflege des Status er-
möglicht es dem Anwender, sich schnell einen detaillierten Überblick über den
aktuellen Stand des Testgeschehens zu verschaffen. Ein Anwender, der viel-
leicht nicht unmittelbar mit der Erstellung des Testkatalogs und der dort struk-
turierten Testfälle beteiligt war, hat bei entsprechend gepflegten Dokumentatio-
nen die Möglichkeit, sich schnell in die einzelnen Testszenarien einzuarbeiten,
da er anhand der dokumentierten Testfälle erkennen kann, was denn eigentlich
getestet wird.
Unter der Voraussetzung, dass zu jedem Testfall der entsprechende Status sorg-
fältig gepflegt wurde, bietet die Testworkbench es an, im Testkatalog eine so ge-
nannte »Statusanalyse« durchzuführen.
10.5 Statusanalysen durchführen

Der Testfortschritt einzelner Testpläne oder Testpakete kann jederzeit durch
den Testkoordinator verfolgt werden. Durch so genannte Statusanalysen erhält
man zu jeder Zeit einen detaillierten Überblick über den noch verbleibenden
Testaufwand. Das SAP R/3-System unterstützt die Statusverwaltung mit einer
Ampelschaltung, die auf einen Blick sofort erkennen lässt, welche Testfälle O.K.
(grüne Ampel), fehlerhaft (rote Ampel) oder noch ungetestet (gelbe Ampel)
sind. Die einzelnen, den Status beschreibenden Kennzeichen können dabei so-
wohl automatisch als auch manuell vergeben werden. Dadurch hat der Anwen-
der die Möglichkeit, sofort zu erkennen, welche Testabläufe noch nicht behan-
delt wurden.
Der Status im Rahmen dieser Analyse kann folgende Werte haben:
◗ ungetestet:
Der Testfall ist noch keinem Test unterzogen worden.
◗ in Bearbeitung:
Die Arbeit an diesem Testfall ist noch nicht abgeschlossen.
◗ OK:
Bei der Abarbeitung eines Testfalls wurden keinerlei Beanstandungen
festgestellt.
278
Sandini Bib
◗ OK mit Einschränkungen:
Es bestehen geringfügige Mängel z.B. ergonomische Schwachstellen.
◗ Fehlerhaft / Nachtest erforderlich:
Das Programm enthält gravierende Mängel bzw. Programmfehler.
◗ Nachtest OK:
Beim Nachtest wurde festgestellt, dass frühere Fehler behoben wurden.
Die Statusanalyse in der Testworkbench wird wie folgt durchgeführt:
A Zunächst verzweigt man in eine entsprechende Pflegetransaktion, für die
man die Statusanalyse durchführen möchte. Als Pflegetransaktionen existie-
ren der Testkatalog, der Testplan und das Testpaket.
B Nun gibt man z.B. den Testkatalog XXX und den Testplan YYY an. Für diese
Pflegetransaktionen soll nun eine Statusanalsyse durchgeführt werden. Man
kann natürlich auch die Kombination Testkatalog/Testpaket für die Status-
analyse vorsehen.
C Über HILFSMITTEL p STATUSANALYSE gelangt man in das Einstiegsbild der Sta-
tusanalyse.
D Hier kann der entsprechende Testkatalog und/oder Testplan ausgewählt
werden.
E In dem Feld Auswahlzeitraum kann durch die Angabe eines bestimmten Zeit-
raums explizit selektiert werden, welche Tests in die Statusanalyse miteinbe-
zogen und welche Tests ausgegrenzt werden sollen.
F Anhand der Funktion Ausführen startet man die Statusanalyse. Dabei infor-
miert das System über den Testfortschritt. Sowohl Informationen als auch
der Teststatus werden angezeigt.
279
Sandini Bib
10.6 Testpaket zuordnen

Testplan YTEST1
10.6 Testpaket zuordnen

Ein Testpaket wird in der Regel einem Tester zugeordnet. Der Tester findet die-
ses Testpaket dann in der Transaktion zum Testen von Testpaketen vor.
Diese Zuordnung der Testpakete ist mandantenabhängig.
Sofern einem Tester ein bestimmtes Testpakete zugeordnet werden soll, sind
folgende Schritte auszuführen:
A Zunächst verzweigt man über den Menüpfad ABAP/4 DEVELOPMENT
WORKBENCH pTEST pTESTWORKBENCH pTEST-ORGANISATION pTESTPAKET AN-
LEGEN in die entsprechende Pflegetransaktion.
B Hier sind im nächsten Schritt der Name des Testkatalogs und des Testpakets,
die einem Tester zugeordnet werden sollen, einzugeben.
C Funktion Tester zuordnen ausführen
D Eingabe des Testers auf dem Dialogfenster Zuordnung Testpaket an Benutzer.
E Die Schaltfläche Weiter muss betätigt werden.
280
Sandini Bib
Über den Menüpfad TEST p TESTWORKBENCH p TESTORGANISATION p TESTPAKET

ZUORDNEN gelangt man auf das Einstiegsbild. Dies zeigt eine Übersicht aller Te-
ster und der ihnen zugeordneten Testpakete.

Übersicht der Benutzer des Testpaketes YTESTPAKET1

10.7 Neuerung in R/3 Release 4.5
Mit Release 4.5A wurde die Ablage der Testkataloge, Testpläne und Testpakete
verändert. Testkataloge von vorhergehenden Releases können mit einem Pro-
gramm in die neue Ablage umgesetzt werden.
281
Sandini Bib
Sandini Bib
Fallstudie zum
praxisnahen Einsatz
von CATT
11
11.1 Testplanung
Der Erfolg von automatisierten Tests mit dem Computer Aided Test Tool ist we-
sentlich von der Qualität der erstellten Testbausteine und Testabläufe abhängig.
In diesem Kontext sind klar definierte, einheitliche Konventionen hinsichtlich
der Erstellung und Parametrisierung der einzelnen Testbausteine unverzicht-
bar, um eine universelle Einsetzbarkeit der Testbausteine zu gewährleisten.
Darum ist eine Planung der einzelnen Schritte vor der eigentlichen Erstellung
der Tests unbedingt notwendig.
Diese Planung stellt darüber hinaus auch die für die Testablauferstellung benö-
tigten Daten und Informationen bereit. Die folgenden Punkte wurden basierend
auf Erfahrungen aus der Praxis entwickelt und mögen als Anregung für die
Durchführung der Testvorbereitung verstanden werden. Die hier nun näher be-
schriebene Vorgehensweise zur Planung von CATT-Projekten wurde in der Pra-
xis bei der Realisierung von R/3-Einführungsprojekten bereits mehrfach erfolg-
reich angewandt.
Im Folgenden sollen nun die einzelnen Schritte der Testplanung in Verbindung
mit einem konkreten, in der Praxis bereits durchgeführten CATT-Projekt bei der
Firma XYZ GmbH näher aufgezeigt werden. Dabei werden die erforderlichen
Schritte in der empfohlenen Reihenfolge beschrieben. Jeder einzelne Schritt
wird zunächst theoretisch erläutert und anschließend mit konkreten Daten der
Firma XYZ praktisch umgesetzt. Dadurch wird dem Leser die Möglichkeit ge-
geben, die Testplanung und -durchführung mittels CATT am konkreten Bei-
spiel zu verfolgen, und er lernt, sie nach und nach zu verstehen.
Basis für die Benutzung der SAP-Werkzeuge zum Testen von Software ist, wie
in Kapitel 1 bereits angesprochen, eine Ausbildung der jeweiligen Anwender in
folgenden Bereichen:
283
Sandini Bib
11.1 Testplanung
◗ Bereich 1:
Grundlagen der Softwareentwicklung sowie ausgeprägtes Wissen bezüglich
des Testens von Softwaresystemen.
◗ Bereich 2:
Grundlegendes Wissen bezüglich der Eigenschaften und Besonderheiten des
SAP R/3-Systems, was sowohl die Geschäftsprozesse und -funktionen an-
geht als auch den Einführungsprozess des SAP R/3-Systems, d.h. Know-
how im Bereich der verschiedenen Vorgehensmodelle zur Durchführung
von R/3-Projekten.
◗ Bereich 3:
Verständnis des Softwareentwicklungs- und Testkonzepts der SAP AG so-
wie der dazu verwendeten Werkzeuge. In diesem Zusammenhang ist es
wichtig, über einen Überblick über die verschiedenen Funktionalitäten sowie
die Bedienung von CATT zu verfügen.
◗ Bereich 4:
Einweisung in die einzelnen Schritte der Testplanung. Die folgenden Aus-
führungen detaillieren eine Vorgehensweise zur Planung der Tests und auch
zur Anwendung von CATT zum Testen der SAP-Software.
Im Folgenden soll nun zunächst eine generelle Übersicht über die Testplanung
als Vorbereitung des Einsatzes des CATT-Tools dargestellt werden. Sie soll dem
Leser als Grundlage dienen, selbst die Planung und die Realisierung eines
CATT-Projektes verwirklichen zu können. Die aufgeführten Fragen zum Pro-
jekt sind allerdings nur als Vorschlag zu nehmen, da die Durchführung eines
CATT-Projektes in jedem Unternehmen teilweise von anderen Bedingungen ab-
hängt. Aus diesem Grund wurde bei der Zusammenstellung der Leitfragen ver-
sucht, möglichst vollständig die essentiellen Fragestellungen aufzuführen, wel-
che in allen CATT-Projekten auftauchen und beantwortet werden müssen.
Wer ist der Testverantwortliche?
◗ Hier ist festzulegen, wer der Leiter und Verantwortliche des CATT-Projektes
ist.
◗ Welche Mitglieder gehören dem CATT-Team an? Die Erfahrung zeigt, dass
es sinnvoll ist, das CATT-Team sowohl aus Modulspezialisten als auch aus
CATT-Fachleuten zusammenzusetzen, da die Modulspezialisten in der Re-
gel kein CATT-Know-how besitzen und die CATT-Experten meist über kein
konkretes Modulwissen verfügen.
Was soll getestet werden?
◗ Welche Prozesse bzw. Prozessketten sollen mit CATT abgebildet werden?

Hier kann es vorteilhaft sein, zunächst nur die wichtigsten Prozessketten zu
betrachten, um sich nicht gleich zu Anfang in Details zu verzetteln. Detaillie-
rungen können auch noch später realisiert werden. Die Erfahrungen aus der
284
Sandini Bib
Praxis zeigen, dass eben aus diesen Gründen die Vorgehensweise »Vom Gro-
ben ins Detail« für CATT-Projekte sehr zu empfehlen ist.
◗ Welche Anwendungsbereiche sind betroffen? Hier ist zunächst festzulegen,
welche Applikation, Subapplikation und welche Komponente des R/3-Sys-
tems mittels CATT getestet werden soll. Diese Festlegung ist in den einschlä-
gigen Workshops zur Vorbereitung des CATT-Projektes eindeutig zu treffen.
Als Ergebnis dieses Workshops kann z.B. vereinbart werden, dass alle Pro-
zesse, welche die Finanzbuchhaltung, die Materialwirtschaft und den Ver-
trieb betreffen, mittels CATT einem Test unterzogen werden sollen. Hier
kann auch festgelegt werden, welche Stammdaten per CATT aus externen
Dateien ins R/3-System eingespielt werden sollen.
◗ Was soll mit CATT getestet werden? Folgende Fragestellungen sind hier zu
klären:
◗ Transaktionen
◗ erwartete Fehlermeldungen
◗ korrekte Wertermittlung und Datenbankfortschreibung
◗ Auswirkungen von Customizing-Änderungen
◗ formale Lauffähigkeit von Anzeigetransaktionen und Onlinereports
Welche Daten sollen erzeugt werden?
Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT

◗ Testdaten
◗ Schulungsdaten
Bestehen Restriktionen irgendwelcher Art für den Einsatz des Computer

Aided Test Tools?
Zum Beispiel hinsichtlich

◗ der Verwendbarkeit im System
◗ der Sprache
◗ des Landes
◗ der Reihenfolge des Einsatzes?
Sind Schulungen in CATT notwendig?
◗ Wenn ja, in welchen Bereichen müssen die Mitarbeiter geschult werden?

Falls Schulungsbedarf besteht, ist es hier unbedingt erforderlich, einen de-
taillierten Schulungsplan für die Mitarbeiter zu erarbeiten, der sämtliche
schulungstechnisch abzubildenden Themengebiete abdeckt. Dies ist für den
Erfolg eines CATT-Projektes unabdingbar.
285
Sandini Bib
11.1 Testplanung
Wie soll der Test aufgebaut sein?
◗ Welches Testsystem wird verwendet?

◗ Welche Testbausteine werden zur Abbildung des Tests benötigt?
◗ Handelt es sich um manuelle, nicht per CATT automatisierbare Testbaustei-
ne oder sind es Testbausteine, die per CATT automatisiert werden können?
◗ Wie müssen sie parametrisiert sein, damit sie möglichst vielfältig einsetzbar
sind?
◗ Festlegung der Namenskonventionen für die Parameter.
◗ Welche Variablen werden benötigt?
◗ Werden Funktionsbausteine verwendet? Wenn ja, welche?
◗ Welche Bildschirmbilder werden aufgerufen?
◗ Welche Transaktionen müssen geändert werden?
◗ Welche Testabläufe sind zu erstellen?
◗ Sind Varianten zu den Testabläufen bzw. Testbausteinen gewünscht?
◗ Für die Pflege des Testbausteins bzw. Testablaufs ist es sinnvoll, die Trans-
aktion parallel im Dialog durchzuführen. So gewährleistet man, dass alle
notwendigen Bildschirmbilder aufgelistet und die jeweiligen Mussfelder
ausgefüllt werden.
Besonderheiten bei der Durchführung des CATT-Projektes
◗ Sind Customizing-Einstellungen zur Vorbereitung des Tests durchzufüh-

ren? Wenn ja, dann ist es erforderlich, dass diese am Ende des Testablaufs
wieder zurückgenommen werden.
◗ Sind Datenbankänderungen zu überprüfen?
◗ Sind Fehlermeldungen zu überprüfen?
◗ Sollen Ablaufvarianten definiert werden? Falls ja, handelt es sich dabei um
interne oder externe Varianten?
◗ Sind auch manuelle Tests anzulegen?
Verwaltung der Testszenarien
◗ Wie sollen die Testfälle verwaltet werden?

◗ Die Art der Dokumentation muss geklärt werden
Im Folgenden werden diese allgemeinen Leitfragen zur Testplanung auf die
entsprechenden Anforderungen der XYZ-GmbH angewendet.
286
Sandini Bib
11.1.1 Festlegung des Testziels

Im ersten Schritt der Testplanung sollte zunächst das eigentliche Ziel der Tests
mittels CATT fixiert werden. Dieses Ziel ist in Abhängigkeit des jeweiligen Ein-
führungsfortschrittes festzulegen. Die Einsetzbarkeit des CATT-Tools bezogen
auf die jeweiligen Einführungsphasen wurde bereits in Kapitel 4 detailliert be-
schrieben.
Die Definition des Testziels in der jeweiligen Einführungsphase beantwortet die
Frage, wozu CATT generell eingesetzt werden soll. Ein mögliches Testziel hier-
bei könnte sein: Es soll unter Verwendung von CATT getestet werden, ob be-
stimmte ausgewählte Geschäftsprozesse des Unternehmens mit der momentan
eingestellten, bereits per Customizing eingestellten SAP-Software-Konfigurati-
on fehlerfrei durchgeführt werden können. Dies kann zum Beispiel innerhalb ei-
nes Integrationstests bei der R/3-Einführung erfolgen.
XYZ GmbH
Beim R/3-Einführungsprojekt der XYZ GmbH wurde von den Projektleitern be-
schlossen, die bisher getroffenen Systemeinstellungen im Rahmen der Phase
Detaillierung und Realisierung einem größeren Integrationstest zu unterziehen.
Das Einführungsprojekt war also bereits sehr weit gediehen. Dabei gab es für
die Projektleitung grundsätzlich zwei Möglichkeiten der Testdurchführung. Ei-
nerseits wurde die Option diskutiert, den Test von den jeweiligen Modulverant-
wortlichen manuell durchführen zu lasen. Dabei ging man von einer zu veran-

schlagenden Dauer des Tests von etwa fünf Tagen aus. Diese Zeitspanne
erschien der Projektleitung aber aufgrund der ohnehin angespannten terminli-
chen Situation innerhalb des R/3-Einführungsprojektes viel zu lang und vor al-
lem auch zu teuer. Aufgrund dieser klaren zeitlichen Restriktion der Geschäfts-
leitung der XYZ GmbH entschied man sich für die Verwendung eines CASE-
Tools unter der Anleitung erfahrener Unternehmensberater. Als entsprechen-
des Testwerkzeug wählte die Projektleitung nach Prüfung der in Frage kom-
menden Werkzeuge hierzu das Computer Aided Test Tool der SAP AG aus.
Wesentliches Entscheidungskriterium dabei war, dass es sich beim CATT-Tool
um ein SAP-eigenes Tool handelt, welches bereits in allen Details und Funktio-
nen auf die SAP-Software zugeschnitten ist und im Rahmen der ABAP4-De-
velopment-Workbench bereits an die XYZ-GmbH ausgeliefert worden war.
Man musste also kein neues Softwareprodukt mehr kaufen. Als Testziel legte
die Projektleitung im entsprechenden Workshop die fehlerfreie Durchführung
diverser Integrationstests auf der Basis verschiedener, von den Modulteams ge-
meinsam entwickelten Testszenarien fest. Innerhalb der R/3-Entwicklungsab-
teilung der XYZ GmbH wurde ein Team von fünf Personen mit der Umsetzung
der Szenarien mit CATT betraut. Das Team setzte sich zusammen aus vier Mo-
dulexperten und einem externen Unternehmensberater der ICM Unterneh-
mensberatungs Gruppe.
287
Sandini Bib
11.1 Testplanung
11.1.2 Voraussetzungen zum CATT-Einsatz

Zunächst einmal ist zu klären, welche Prozesse mittels CATT abgebildet und ge-
testet werden sollen, und auch, welche R/3-Anwendungsbereiche davon be-
troffen sind. Der Einsatz des Computer Aided Test Tools setzt ein umfassend
gepflegtes und eingerichtetes Testsystem voraus. Das R/3-System muss also
über entsprechende, für den Einsatz des CATT-Werkzeugs notwendige Custo-
mizing-Einstellungen verfügen. Wichtig ist dabei, dass Veränderungen an Cu-
stomizing-Einstellungen nur dann realisiert werden dürfen, wenn sie innerhalb
desselben Ablaufs wieder zurückgenommen werden.
Es ist darüber hinaus notwendig, zu wissen, ob es sich bei den zu testenden Pro-
zessen um funktional orientierte oder um prozessorientierte Geschäftsabläufe
handelt. Falls es sich um die Abbildung von funktional orientierten Prozessen
handelt wie z.B. die Tankzugabwicklung aus Vertriebssicht (Modul SD) genügt
es, wenn sich die Experten des Moduls SD mit den CATT-Fachleuten zusam-
menfinden, um den Testzyklus abzubilden. Dabei liefern die SD-Fachleute mit
ihrem Modul-Know-how die entsprechenden Stammdaten sowie Informatio-
nen zu den Schnittstellen zwischen den einzelnen SD-Transaktionen, die für die
Abbildung des Testszenarios »Tankzugabwicklung« erforderlich sind. Die
CATT-Programmierer entwerfen nach diesen Angaben die entsprechenden
Testbausteine und -abläufe. Nur durch diese Kooperation zwischen den Modul-
spezialisten einerseits und den CATT-Experten andererseits ist es möglich, die
Schnittstellen zwischen den einzelnen Transaktionen im Modul SD fehlerfrei zu
gestalten, da die CATT-Experten in der Regel zur Entwicklungsabteilung gehö-
ren und oft keinerlei Modulkenntnisse besitzen.
Bei der Abbildung prozessorientierter Geschäftsabläufe ist es erforderlich, dass
die Experten aller beim abzubildenden Testszenario eingesetzten R/3-Module
gleichzeitig mit den CATT-Spezialisten zusammenarbeiten. Zunächst legen die
Modulexperten gemeinsam die entsprechenden Stammdaten fest, welche erfor-
derlich sind, um den abzubildenden Prozess im R/3-System lauffähig zu gestal-
ten. Dabei ist die Schwierigkeit der unterschiedlichen Schnittstellen der einzel-
nen Module zu überwinden. Die Informationen zu den Schnittstellen zwischen
den Modulen werden den CATT-Programmierern von den Applikationsexper-
ten zur Verfügung gestellt. Nachdem die erforderlichen Stammdaten verfügbar
und bekannt und die Schnittstellen identifiziert sind, bilden die CATT-Experten
die prozessorientierten CATT-Szenarien ab.
Um eine bessere Übersicht über die einzelnen Bestandteile der abzubildenden
funktionalen oder prozessorientierten Geschäftsabläufe zu gewährleisten, ist es
erfahrungsgemäß empfehlenswert, die verschiedenen Testszenarien auch in
grafischer Form darzustellen. Möglich ist z.B. eine Illustration der Geschäfts-
prozesse in Form von ereignisgesteuerten Prozessketten anhand entsprechen-
der Prozessmodellierungstools wie z.B. den folgenden:
◗ ARIS Toolset von IDS Prof. Scheer GmbH
288
Sandini Bib
◗ LIVE-Model von Intellicorp. INC

◗ Business Modeller von VISIO
◗ Enterprise Charter von MICROGRAFX
Eine elementare Voraussetzung für die graphische Darstellung der abzubilden-
den Geschäftsprozesse mittels dieser vorgenannten Modellierungswerkzeuge
ist allerdings, dass alle im Rahmen dieser grafischen Darstellung verwendeten
Funktionen und Prozesse auch durch entsprechende SAP-Transaktionen iden-
tifizierbar und abbildbar sind. Können zu den einzelnen Funktionen und Pro-
zessen nicht alle erforderlichen Transaktionen identifiziert werden, ist es nicht
möglich, für diese Pfade der Grafiken Tests durchzuführen.
XYZ GmbH
Innerhalb des mehrjährigen R/3-Einführungsprojektes bei der XYZ GmbH
wurden zur Vorbereitung des Integrationstests die verschiedensten Geschäfts-
prozesse grafisch unter Einsatz eines der genannten Modellierungstools abge-
bildet. Diese Geschäftsprozesse wurden anschließend durch externe Unterneh-
mensberater in Zusammenarbeit mit den Mitarbeitern der Firma XYZ in
einzelne SAP-Transaktionen zerlegt. Jede einzelne der Transaktionen wurde per
CATT aufgezeichnet. Die dadurch entstehenden Testbausteine wurden gemäß
den definierten Geschäftsprozessen in entsprechende, die gewünschte prozess-
orientierte Funktionalität abbildende Testabläufe integriert. Diese Testszenarien
wurden bei der Firma XYZ GmbH auch als Testzyklen bezeichnet.

Die Modulteams hatten das System so konfiguriert, dass die in den Testzyklen
enthaltenen Geschäftsprozesse durchgehend und integrativ durchgespielt wer-
den konnten. Die entsprechenden Stammdaten wurden durch die verantwortli-
chen Mitarbeiter eingepflegt.
Verbale Beschreibung der Testzyklen
Im Rahmen des Einführungsprojektes wurden bei der XYZ GmbH folgende
Module eingeführt:
MM Material Management Materialwirtschaft
EC External Accounting Finanzwesen
PP Production Planning Produktionsplanung
SD Sales and Distribution Vertrieb
Der Testzyklus, welcher die Integration dieser vier Module beispielhaft über-
prüfen soll, wird wie folgt beschrieben:
289
Sandini Bib
11.1 Testplanung
Modul MM (Material Management – Materialwirtschaft)

Zunächst werden im Modul MM zwei Bestellungen von Materialien generiert.
Diese Bestellungen betreffen zum einen das Material Nr. 100190 sowie zum an-
deren die dazugehörige Verpackung mit der Nummer 10090.
Die Lieferanten dieser Materialien sind für das Material 100190 die Fa. KUNDE
AG (Lieferantennummer 500141) sowie für die Verpackung die Fa. WKW
GmbH (Lieferantennummer 500406).
Diesen erzeugten Bestellungen wird vom System nach Beendigung der entspre-
chenden Transaktion automatisch jeweils eine eindeutige Belegnummer zuge-
wiesen. Unter Verwendung dieser Belegnummern im Modul MM soll nun zu je-
der dieser Bestellungen ein Wareneingang gebucht werden. Das Resultat dieser
Wareneingangsbuchungen ist wiederum je eine eindeutige Belegnummer zu je-
der Bestellung.
Modul EC (External Accounting – Finanzwesen)
Aufbauend auf dieser vorher generierten Belegnummer zum jeweiligen Waren-
eingang ist jedem dieser Wareneingänge die dazugehörige Rechnung des Liefe-
ranten hinzuzufügen. Jede dieser Fakturen ist anhand einer vom R/3-System
vergebenen Rechnungsnummer eindeutig zu identifizieren. Diese Rechnungen
werden im Modul External Accounting (Finanzwesen) verbucht.
Modul PP (Production Planning – Produktionsplanung)
Anschließend sind im Modul PP die entsprechenden Prozessaufträge zur Pro-
duktion des an den XYZ-Kunden, die Fa. ABC-AG, zu liefernden Endprodukts
mit der Materialnummer 10019010090 anzulegen. Die Firma ABC-AG ist im
System unter der Kundennummer 100263 angelegt. Basierend auf der hier vom
System vergebenen Prozessauftragsnummer sollen ebenfalls im Modul PP die
Rückmeldungen zum gesamten Prozessauftrag durchgeführt werden. Das Er-
gebnis dieser Rückmeldungs-Transaktionen sollte sein, dass die Rückmeldung
zum Prozessauftrag gesichert ist und alle bisherigen Warenbewegungen fehler-
frei durchgelaufen sind.
Modul SD (Sales and Distribution – Vertrieb)
Für den Kunden ABC-AG (Kundennummer 100263) wird nun im Modul SD für
das Endprodukt 10019010090 ein Kundenauftrag generiert. Dieser Kundenauf-
trag wird unter einer so genannten »Terminauftragsnummer« im System ge-
speichert. Darauf aufbauend wird im Modul SD eine Lieferung an die ABC-AG
mit automatischer Chargenfindung angelegt. Das Ergebnis dieser Transaktion
ist die Sicherung der vorher erzeugten Lieferung im System, welche unter einer
bestimmten Liefernummer eindeutig identifizierbar ist. Letztlich wird im Mo-
dul SD zu dieser Lieferung eine Faktura angelegt. Auch dieser Faktura wird
vom R/3-System eine eindeutige Belegnummer zugewiesen. Diese Belegnum-
290
Sandini Bib
mer soll abschließend weiteren Anwendungen zur Verfügung stehen, falls die-
ser Testablauf erweitert werden sollte.
11.1.3 Überprüfung von eventuellen Restriktionen

Nach der Festlegung des Testszenarios prüft man, ob bestimmte Restriktionen
beim CATT-Einsatz bezüglich der Verwendbarkeit der Testbausteine und Test-
abläufe im System, der Sprache, des Landes und der Reihenfolge des Einsatzes
bestehen. Eine Bedingung kann beispielsweise sein, dass die CATTs in engli-
scher Sprache erstellt sein müssen, da sie auch in den Roll-outs bei den verschie-
denen Tochtergesellschaften im Ausland eingesetzt werden sollen.
XYZ GmbH
Aufgrund der internationalen Ausrichtung der Fa. XYZ GmbH ist die Master-
sprache des R/3-Systems Englisch. Demzufolge werden auch alle CATTs in
englischer Sprache erstellt. Andere Restriktionen waren hier nicht vorhanden.
11.1.4 Erstellung der Testbausteine
Identifizierung der Transaktionen und der dazugehörigen Daten

In diesem Schritt sind nun die Testdaten und auch die Funktionscodes für jeden
Baustein des beschriebenen Testszenarios von den jeweiligen Modulexperten

detailliert darzustellen. Die zentrale Fragestellung hier ist, welche Transaktio-
nen zur Abbildung des Testszenarios notwendig und mit welchen konkreten
Werten die einzelnen Transaktionen im Test zu versorgen sind. Falls für die zu
testenden Transaktionen noch keine verwertbaren Stammdaten im System vor-
handen sind, müssen diese von den Modulexperten ins R/3-System eingepflegt
werden. Im Idealfall sollten die Modulexperten diese Daten (Transaktionscodes
sowie Stammdaten) so umfassend und verständlich aufbereiten, dass die
CATT-Fachleute anhand dieser Daten die Testbausteine und -abläufe »nur«
noch anhand der grafischen Darstellung des abzubildenden Prozessen auf-
zeichnen müssen.
XYZ GmbH
Folgende Transaktionen wurden zur Abbildung des in Abschnitt 11.2 beschrie-
benen Testzylus benötigt. Dabei wurde für jede der im Folgenden aufgeführten
Transaktionen jeweils ein Testbaustein unter Verwendung der geschilderten
Testdaten aufgezeichnet. Diese Daten wurden den CATT-Experten von den ein-
zelnen Modulteams zur Verfügung gestellt.
a) Transaktion Hinzufügen Bestellung ME21
abgebildet im CATT-Testbaustein ZDCE0099
291
Sandini Bib
11.1 Testplanung
Diese Transaktion ist dem Modul MM zuzuordnen. Sie erzeugt eine Bestellung
im R/3-System. Da sowohl für den Lieferanten 500141 als auch für den Lieferan-
ten 500406 eine Bestellung erzeugt werden soll, muss diese Transaktion im spä-
teren CATT-Ablauf zweimal abgearbeitet werden.
Die Modulexperten haben hierzu folgende Testdaten festgelegt:
Testdaten
Lieferantennummer: 500141 / 500406
Einkaufsorganisation: DE01
Einkäufergruppe: 999
Werk: DEAA
Lagerort: 0001
Bestelldatum: jeweiliges Tagesdatum
Materialnummer: 100190
Menge: 10000 / 100
Preis: 10 / 20
b) Transaktion Wareneingang zur Bestellung buchen MB01

abgebildet in den CATT-Testbausteinen ZDCE0102, ZDCE0091
Testdaten
Erforderlich ist hier vor allem die Belegnummer der mittels der vorherigen
Transaktion ME21 generierten Bestellung. Hieraus werden dann sämtliche für
diese Transaktion MB01 notwendigen Daten wie z.B. Werk und Lagerort vom
R/3-System automatisch übernommen.
c) Transaktion Rechnung hinzufügen MRHR
Testdaten
Auch hier ist vor allem die Belegnummer des mittels Transaktion MB01 gene-
rierten Wareneingangs erforderlich. Anhand dieser Nummer werden dann
sämtliche für die Transaktion MRHR notwendigen Daten wie z.B. Datum und
Buchungskreis vom R/3-System automatisch übernommen.
d) Transaktion Anlegen ProzessauftragCOR1
292
Sandini Bib
Testdaten
Werk: DEAA
Prozessauftragstyp: P101
Gesamtmenge: 5000 kg
Zieldatum: Tag des Tests + 1 Tag
e) Transaktion Rückmeldung Prozessauftrag CORK

Testdaten
Erforderlich ist hier vor allem die Prozessauftragsnummer des mittels der vor-
herigen Transaktion COR1 generierten Prozessauftrags. Hieraus werden dann
sämtliche für diese Transaktion »CORK« notwendigen Daten vom R/3-System
automatisch übernommen.
Auftragsmenge: 5000 kg
f) Transaktion Zuschlagsberechnung KG12

g) Transaktion WIP-Ermittlung Auftrag KRAX
h) Transaktion Abweichungen Fertigungsauftrag KKS2
Vorstehende Transaktionen f) bis h) beziehen ihre Testdaten aus den jeweiligen Da-
ten, die vom System durch die bisher genannten Transaktionen generiert wurden.
i) Transaktion IST-Abrechungs-Auftrag KO88
abgebildet in CATT-Testbaustein ZDCE0092
Testdaten
Die mittels der Transaktion COR1 generierte Prozessauftragsnummer ist hier
für jede dieser Transaktionen erforderlich. Hieraus werden dann sämtliche für
die Transaktionen KG12, KRAX, KKS2 und K088 notwendigen Daten vom R/3-
System automatisch übernommen.
Periode: gegenwärtiger Monat abzüglich 2
Fiskal-Jahr: 1998
293
Sandini Bib
11.1 Testplanung
j) Transaktion Kundenauftrag anlegen VA01

Testdaten
Auftragstyp: TA
Vertriebsorganisation: DE10
Vertriebsweg: 01
Sparte: 51
Kundennummer: 100263
Lieferdatum: freie Auswahl
k) Transaktion Anlegen Lieferung VL01

Testdaten
Diese Transaktion benötigt die Belegnummer des mittels der vorherigen Trans-
aktion VA01 generierten Kundenauftrags. Mithilfe dieser Nummer werden
dann sämtliche für die Transaktion VL01 notwendigen Daten vom R/3-System
automatisch aus dem Kundenauftrag übernommen.
Versandstelle: DE01
l) Transaktion Anlegen Faktura VF01

Testdaten
Erforderlich ist hier vor allem die Belegnummer der mittels der vorherigen
Transaktion VL01 generierten Lieferung. Hieraus werden dann sämtliche für
diese Transaktion VF01 notwendigen Daten vom R/3-System aus der angeleg-
ten Lieferung automatisch übernommen.
Aufzeichnung von Testbausteinen

In diesem Schritt sind nun alle vorstehend aufgeführten Transaktionen mit den
von den Modulexperten vorgegebenen Daten in CATT abzubilden. Dabei wird
für jede einzelne Transaktionen je ein Testbaustein erstellt. Hinsichtlich der
technischen Handhabung von CATT bei der Aufzeichnung von Testbausteinen
sei auf Kapitel 8 verwiesen.
294
Sandini Bib
Insgesamt ergibt sich folgende Liste von Testbausteinen:

◗ CATT-Testbaustein ZDCE0099 Hinzufügen Bestellung
◗ CATT-Testbaustein ZDCE0102 Wareneingang zur Bestellung buchen
◗ CATT-Testbaustein DCE0108 Rechnung hinzufügen
◗ CATT-Testbaustein ZDCE0057 Anlegen Prozessauftrag
◗ CATT-Testbaustein ZDCE0058 Rückmeldung Prozessauftrag
◗ CATT-Testbaustein ZDCE0085 Zuschlagsberechnung
◗ CATT-Testbaustein ZDCE0086 WIP-Ermittlung Auftrag
◗ CATT-Testbaustein ZDCE0091 Abweichungen Fertigungsauftrag
◗ CATT-Testbaustein ZDCE0092 Ist-Abrechungsauftrag
◗ CATT-Testbaustein ZDCE0050 Kundenauftrag anlegen
◗ CATT-Testbaustein ZDCE0111 Lieferung anlegen
◗ CATT-Testbaustein ZDCE0052 Faktura anlegen
Durchführung von Transaktionstests

Hierzu werden die verschiedenen Testbausteine einzeln gestartet und per
CATT einem Test unterzogen. Dabei werden durch die Tests Daten verändert
und Ergebnisse erzeugt. Falls bei diesen Modultests Fehler in den Testbaustei-

nen (d.h. an den Transaktionen) bzw. in den durch sie generierten Daten bzw.
Ergebnissen auftreten, müssen diese Fehler behoben werden. In CATT bietet
sich, wie bereits besprochen, die Möglichkeit, einen Fehler sukzessive einzu-
grenzen und ihn nach seiner Identifizierung zu beheben. Erst dann, wenn zwi-
schen dem erwarteten Ergebnis einer Transaktion und ihrem tatsächlichen Er-
gebnis keine Differenzen mehr bestehen, ist der Testbaustein als korrekt zu
betrachten. Daraufhin kann auch in seinem Attributspflegebildschirm der Test-
status auf »freigegeben« gesetzt werden.
Parametrisierung der Testbausteine

Bevor die einzelnen erstellten und geprüften Testbausteine nun zu einem Test-
ablauf zusammengefügt werden, stellt sich die Frage, wie diese Testbausteine
parametrisiert sein müssen, um erstens untereinander auf Ablaufebene die not-
wendigen Daten austauschen zu können und zweitens möglichst vielfältig ein-
setzbar und flexibel zu sein, z.B. auch in anderen Testabläufen. Es müssen auch
Überlegungen angestellt werden, ob Variablen benötigt werden, und wenn ja,
welche.
295
Sandini Bib
11.1 Testplanung
XYZ GmbH
Testbaustein »Hinzufügen Bestellung« (Transaktion ME21)
Dieser Testbaustein muss innerhalb des zu erstellenden Testablaufs zweimal re-
ferenziert werden. Im ersten Aufruf generiert dieser Baustein am Tage seines
Durchlaufs die Bestellung von 10.000 kg des Materials 100190 beim Lieferanten
500141 zum Preis von 10 DM/kg. Im zweiten Durchlauf soll dieser Baustein
vom Lieferanten 500406 eine Bestellung von 100 kg des Verpackungsmaterials
10090 zum Preis von 20 DM/kg erzeugen. Jeder Durchlauf dieses Testbausteins
bezieht sich dabei auf die Einkaufsorganisation DE01 und die Einkäufergruppe
999. Das bestellende Werk ist immer das Werk mit der Bezeichnung DEAA, das
Material wird stets am Lagerort 0001 gelagert. Nach erfolgreichem Durchlauf
gibt der Baustein in der Statuszeile die Meldung »Normalbestellung unter der
Nummer XXXXXXXXXX angelegt« aus. Diese Belegnummer muss für im Ab-
lauf später referenzierte Testbausteine zur Verfügung stehen. Aus diesen Anga-
ben ergeben sich für den Testbaustein folgende Maßnahmen:
Um den Testbaustein generell mit Werten von außen versorgen zu können,
müssen diese Importparameter generiert werden:
Bedeutung Parametername Vorschlagswert(e)
Kontonummer des Lieferanten &VENDOR 500141 / 500406
Bestelldatum &DAT jeweiliges Systemdatum
Materialnummer &MATERIAL 100190 / 10090
Bestellmenge &QUANTITY 10000
Preis &PRICE 10
Durch diese Importparameter wird der Testbaustein sehr flexibel gestaltet, so

dass er auch in jedem beliebigen anderen Testablauf referenziert werden kann.
Die Vorschlagswerte der Importparameter können dann natürlich durch entspre-
chende Daten sowohl auf Baustein- als auch auf Ablaufebene ersetzt werden.
Wie bereits beschrieben, gibt der Testbaustein am Ende seines erfolgreichen Ab-
laufs in der Statuszeile die Dialogmeldung »Normalbestellung unter der Nummer
XXXXXXXXXX angelegt« aus. Entsprechend den Ausführungen zu den Message-
variablen kann auf die Belegnummer über die Messagevariable &MS02 zugegrif-
fen werden. Diese Belegnummer muss an nachfolgende Bausteine im Testablauf
weitergegeben werden. Deshalb wird hierfür ein Exportparameter generiert.
Belegnummer der Bestellung &PURCHASE_NR Inhalt von &MS02
296
Sandini Bib
Testbaustein »Wareneingang zur Bestellung buchen« (Transaktion MB01)

Nun muss ein Testbaustein erstellt werden, welcher die Transaktion MB01 »Wa-
reneingang zur Bestellung buchen« beinhaltet. Diese Transaktion benötigt fol-
gende Daten: Werk DEAA, Lagerort 0001, Mehrwertsteuerland DE sowie die
Belegnummer der anhand des vorherigen Testbausteins ZDCE099 angelegten
Bestellung. Mittels Importparameter in diesem Testbaustein muss lediglich die
Belegnummer der Bestellung in diesen Baustein importiert werden, da die
Transaktion MBO1 anhand dieser Belegnummer die dazugehörige Bestellung
identifizieren und die entsprechenden, für diese Transaktion erforderlichen Da-
ten von dort übernehmen kann. Das Werk und der Lagerort werden also direkt
aus der Bestellung übernommen. Lediglich das Mehrwertsteuerland muss in-
nerhalb der Aufzeichnung dieses Testbausteins als Festwert aufgezeichnet wer-
den. Als Importparameter wird &PURCHASE_NR für die Übernahme der Be-
stellungsnummer definiert.
Auch dieser Baustein muss im abzubildenden Testszenario der Fa. XYZ zwei-
mal durchgespielt werden; zuerst für die Bestellung der Materials und dann für
die Bestellung der Verpackung.
Testbaustein »Rechnungen hinzufügen« (Transaktion MRHR)
Den Bestellungen müssen nun im System die entsprechenden Rechnungen hin-
zugefügt werden. Dies geschieht anhand der Transaktion MRHR. Hier sind fol-
gende Importparameter auf Bausteinebene zu vereinbaren:

Rechnungsdatum &DAT jeweiliges Systemdatum
Belegnummer der Bestellung &PURCHASE_NR jeweilige Belegnr.
Wert der Bestellung &AMOUNT Bruttowert der Bestellung
MWST &TAX MWST-Betrag
Als Festwerte werden die Währung »DEM« sowie die Belastungsart »KR« auf-
gezeichnet. Der Buchungskreis muss nicht extra eingegeben werden, da durch
die Übernahme der Bestellnummer anhand des Importparameters
&PURCHASE_NR auf die entsprechenden Daten aus der Bestellung zugegrif-
fen wird. Die entsprechenden Werte für die Importparameter &AMOUNT so-
wie &TAX werden auf Ablaufebene berechnet.
Dieser Testbaustein muss für jede der Bestellungen im Ablauf je einmal referen-
ziert werden.
297
Sandini Bib
11.1 Testplanung
Testbaustein »Anlegen Prozessauftrag« (Transaktion COR1)

Jetzt ist unter Verwendung der Transaktion COR1 ein Testbaustein zum Anle-
gen von Prozessaufträgen aufzuzeichnen. Diese Transaktion muss mit folgen-
den Werten versehen werden:
Materialnummer &PURCHASE_NR 10019010090
Werk DEAA
Prozessauftragsart pi01
Gesamte Auftragsmenge &PRO_QUANTITY 75
Datum &D01 Bestelldatum + 1 Tag
Die zu vereinbarenden Importparameter sind aufgeführt.

Diese Transaktion schließt mit der Dialogmeldung »Prozessauftrag XXXXXXXX
wurde angelegt« in der Statuszeile ab. Die Nummer des Prozessauftrags kann
anhand der Messagevariablen &MS01 dem hier noch zu definierenden Export-
parameter &ORDER_NR zugewiesen werden.
Testbaustein »Rückmeldung Prozessauftrag gesamt« (Transaktion CORK)
Dieser Testbaustein benötigt lediglich den Importparameter &ORDER_NR, der
ihm die Belegnummer des generierten Prozessauftrags liefert, sowie den Im-
portparameter &PRO_QUANTITY, der ihn mit der Angabe der Gesamtmenge
versorgt. Das Mehrwertsteuerland »DE« wird aus dem Prozessauftrag über-
nommen.
Testbaustein »Zuschlagsberechnung IST« (Transaktion KG12)
Folgende Importparameter sind hier zu vereinbaren:
Auftragsnummer &AB_AUFNR Nr. des Prozessauftrags
Periode (Monat) &CO_PERIO 3
Geschäftsjahr &GJAHR 1998
298
Sandini Bib
Testbaustein »WIP-Ermittlung Auftrag« (Transaktion KRAX)

Auftragsnummer &AB_AUFNR Nr. des Prozessauftrags
Abgrenzungsmonat &BIS_ABGR_M 3
Abgrenzungsjahr &BIS_ABGR_J 1998
Version &VERSN_ABGR 0
Testbaustein »Abweichungen Fertigungsauftrag« (Transaktion KKS2)

Auftragsnummer &AB_AUFNR Nr. des Prozessauftrag
Geschäftsjahr &YEAR 1998
Periode &PERIOD 3

Testbaustein »Ist-Abrechnung: Auftrag« (Transaktion K088)
Auftragsnummer &AB_AUFNR Nr. des Prozessauftrag
Geschäftsjahr &YEAR 1998
Periode &PERIOD 3
Testbaustein »Kundenauftrag anlegen« (Transaktion VA01)

Kundennummer &KUNAG 100263
Lieferdatum &LIEFERDATUM 19980311
Materialnummer &MATNR1 10019010090
299
Sandini Bib
11.1 Testplanung
Gesamtmenge &PRO_QUANTITY 75
Als Festwerte sind einzugeben:
Auftragsart TA
Verkaufsorganisation de10
Vertriebsweg 01
Sparte 51
Diese Transaktion schließt mit der Dialogmeldung »Terminauftrag XXXXXXXX

wurde gesichert« in der Statuszeile ab. Die Nummer des Terminauftrags kann
mithilfe der Messagevariablen &MS02 dem hier noch zu definierenden Export-
parameter &SDORDER_NR zugewiesen werden.
Testbaustein »Anlegen Lieferung mit automatischer Chargenfindung«
(Transaktion VL01)
Dieser Testbaustein benötigt zunächst den Importparameter &SDORDER_NR,
welcher ihn mit der Belegnummer des generierten Terminauftrags versorgt.
Versandstelle &VERSANDST DE01
Datum &SELEKTDAT 1998/03/11
Gesamtmenge &PRO_QUANTITY 75
Diese Transaktion schließt mit der Dialogmeldung »Lieferung XXXXXXXXXX

gesichert« in der Statuszeile ab. Die Nummer der Lieferung kann anhand der
Messagevariablen &MS02 dem noch zu definierenden Exportparameter
&LIEFER_NR zugewiesen werden.
Testbaustein VF01 »Anlegen Faktura« (Transaktion VF01)
Dieser Testbaustein benötigt lediglich den Importparameter &LIEFER_NR, der
ihn mit der Belegnummer der generierten Lieferung versorgt. Alle weiteren Da-
ten übernimmt diese Transaktion aus der entsprechenden Lieferung.
300
Sandini Bib
Diese Transaktion schließt mit der Dialogmeldung »Beleg XXXXXXXXXX gesi-

chert« in der Statuszeile ab. Die Nummer des Belegs kann mit Hilfe der Messa-
gevariablen &MS01 dem noch zu definierenden Exportparameter &F2_NR zu-
gewiesen werden, damit sie für weitere Anwendungen in anderen
Testbausteinen zur Verfügung steht.
11.1.5 Erstellung Testablauf

In diesem Schritt werden die verschiedenen Testbausteine zu einem Testablauf
zusammengefügt. Nachdem die notwendigen Testbausteine im Ablauf referen-
ziert wurden, ist es erforderlich, die für den Ablauf notwendigen Importpara-
meter zu definieren. Es wurden zwar bereits in den Testbausteinen diverse Im-
portparameter vereinbart, dies geschah aber vor allem im Hinblick auf die
Flexibilisierung der Testbausteine. Auf Ablaufebene müssen die Parameter der
Bausteinebene nicht alle zwingend verwendet werden. Falls sie nicht verwendet
werden, übernimmt das System einfach die den Importparametern bei der Auf-
zeichnung zugewiesenen Vorschlagswerte. Die nun auf Ablaufebene definier-
ten Importparameter versorgen den Testablauf mit den entsprechenden Daten.
Dabei gilt es zu beachten, dass Importparameter auf Ablaufebene die entspre-
chenden äquivalenten Importparameter auf Bausteinebene überlagern und da-
mit mit den Werten der Ablaufebene versorgen.
XYZ GmbH

Nun kann der Testablauf zur Abbildung des komplexen Testszenarios der Fa.
XYZ GmbH erstellt werden.
Referenzierung der Testbausteine

Zur Erstellung des Testablaufs müssen die verschiedenen Testbausteine refe-
renziert werden. Der Funktionsbildschirm des Testablaufs sieht dann wie folgt
aus:
301
Sandini Bib
11.1 Testplanung

Funktionsbildschirm zum vorliegenden Testszenario
Definition der Importparameter auf Ablaufebene

Durch die Definition von Importparametern auf Ablaufebene werden die Im-
portparameter der Bausteinebene überlagert. Durch dieses System ist sicherge-
stellt, dass einerseits die Testbausteine durch ihre eigenen Importparameter für
sich selbst flexibel und lauffähig sind und anderseits diese Testbausteine auch
im jeweils referenzierenden Testablauf von dessen Importparametern mit Wer-
ten versorgt werden können. Auf Testablaufebene wurden für den vorliegen-
den Testzyklus deshalb folgende Importparameter vereinbart:
Auftraggeber &CUSTOMER = 100263
Materialnummer &MAT_NR = 100190
Nettopreis im Einkaufsbeleg &MAT_PRICE = 10
Bestellmenge &MAT_QUANTITY = 10000
Kontonummer des Lieferanten &MAT_VENDOR = 500141
302
Sandini Bib
Periode &PERIOD =3
Materialnummer &PKG_NR = 10019
Nettopreis im Einkaufsbeleg &PKG_PRICE = 20
Bestellmenge &PKG_QUANTITY = 100
CATT-Parameterwert &PRO_NR = 10019010090
Gesamte Auftragsmenge &PRO_QUANTITY = 75
Versandstelle &VERSANDST = DE01
Abgrenzungsversion &VERSION =0
Geschäftsjahr &YEAR = 1998
Definition der lokalen Variablen

Lokale Variablen auf Ablaufebene sind das Transportmedium zwischen dem
Exportparameter eines Testbausteines, der die zu transportierenden Daten zur
Verfügung stellt, und dem diese Daten benötigenden Importparameter eines im
Ablauf später folgenden Testbausteins. Um einen fehlerfreien Testablauf zu ge-
währleisten, müssen nun auf Ablaufebene diese lokalen Variablen definiert

werden.
XYZ GmbH
a) Übergabe der vom Testbaustein ZDCE0099 generierten Belegnummer der
Bestellung an die Testbausteine ZDCE0102, ZDCE0103 und ZDCE0108:
Exportparameter des lokale Variable des Importparameter im jewei-

Testbausteins ZDCE0099 Testablaufs ligen Testbaustein
&PURCHASE_NR Æ &PURCHASE_NR Æ &PURCHASE_NR
b) Übergabe der im Testbaustein ZDCE0057 generierten Prozessauftragsnum-

mer an die Testbausteine ZDCE0058, ZDCE0085, ZDCE0086, ZDCE0091 und
ZDCE0092.
Exportparameter des lokale Variable des Importparameter im jewei-

Testbausteins ZDCE0057 Testablaufs ligen Testbaustein
&ORDER_NR Æ &ORDER_NR Æ &ORDER_NR
303
Sandini Bib
11.1 Testplanung
c) Übergabe der im Testbaustein ZDCE0050 erzeugten Belegnummer des Ter-

minauftrags an den Testbaustein ZDCE0111.
Exportparameter des lokale Variable des Importparameter im Testbau-

Testbausteins ZDCE0050 Testablaufs stein ZDCE0111
&SDORDERNR Æ &SDORDERNR Æ &SDORDERNR
d) Übergabe der im Testbaustein ZDCE0111 erzeugten Belegnummer der Liefe-

rung an den Testbaustein ZDCE0052.
Exportparameter des lokale Variable des Importparameter im Testbau-

Testbausteins ZDCE0111 Testablaufs stein ZDCE0052
&LIEFERNR Æ &LIEFERNR Æ &LIEFERNR
Durchführung des Testablaufs

Nun kann der erstellte Testablauf gestartet werden. Falls dieser Testablauf nach
dem Start auf Fehler trifft, sollte man den Test so lange wiederholen, bis die Feh-
ler identifiziert und behoben werden können. Wenn der Testablauf fehlerfrei
abgeschlossen werden konnte und damit das Ziel des Testvorhabens erreicht
wurde, ist der Integrationstest erfolgreich verlaufen.
Das Protokoll zu dem vorliegenden Testablauf ist im Folgenden dargestellt.
ADCE0107 00:00:44 Testablauf: Cycle CATT01
Importparameter
Auftraggeber &CUSTOMER = 100263
Materialnummer &MAT_NR = 100190
Nettopreis im Einkaufsbeleg &MAT_PRICE = = 10
Bestellmenge &MAT_QUANTITY = 10000
Kontonummer des Lieferanten &MAT_VENDOR = 500141
Periode &PERIOD =3
Materialnummer &PKG_NR = 10090
Nettopreis im Einkaufsbeleg &PKG_PRICE = 20
Bestellmenge &PKG_QUANTITY = 100
Kontonummer des Lieferanten &PKG_VENDOR = 500406
304
Sandini Bib
Importparameter
CATT-Parameterwert &PRO_NR = 10019010090
Gesamte Auftragsmenge &PRO_QUANTITY = 75
Versandstelle &VERSANDST = DE01
Abgrenzungsversion &VERSION =0
Geschäftsjahr &YEAR = 1998
REF ADCE0099 ME21 Hinzufügen Bestellung (Rohstoff)
TCD ME21 Hinzufügen Bestellung [00:32 min E]
SO6017 Normalbestellung unter der Nummer 4500000377 angelegt.
SAPMM06E 0100 Anforderungsbild Anlegen Bestellung
EKKO-LIFNR &VENDOR = 500141
EKKO-EKORG = de01
EKKO-EKGRP = 999
RMO6E-EEIND &DAT = 19980304

RMO6E-WERKS = DEAA
RMO6E_LGORT = 0001
BDC_OKCODE = /00
BDC_CURSOR = RM06E_LGORT
SAPMM06E 0121 Positionsübersicht zweizeilig Bestellung
EKPO-EMATN(1) &MATERIAL = 100190
EKPO-MENGE(1) &QUANTITY = 10000
EKPO_NETPR(1) &PRICE = 10
BDC_OKCODE =/00
BDC_CURSOR = EKPO-NETPR(01)
305
Sandini Bib
11.1 Testplanung
BDC_OKCODE = BU
BDC_CURSOR =EKPO_TXZ01(01)
SETVAR & PURCHASE_NR = &M02
PURCHASE-NR = 4500000377
REF ADCE0099 ME 21 Hinzufügen Bestellung (Rohstoff)
TCD ME21 Hinzufügen Bestellung [00:32 min E]
SO6017 Normalbestellung unter der Nummer 4500000378 angelegt
SAPMM06E 0100 Anforderungsbild Anlegen Bestellung
EKKO-LIFNR &VENDOR = 500406
EKKO-EKORG = de01
EKKO-EKGRP = 999
RMO6E-EEIND &DAT = 19980304
RMO6E-WERKS = DEAA
RMO6E_LGORT = 0001
BDC_OKCODE = /00
BDC_CURSOR = RM06E_LGORT
EKPO-EMATN(1) &MATERIAL = 100190
EKPO-MENGE(1) &QUANTITY = 10000
EKPO_NETPR(1) &PRICE = 20
BDC_OKCODE =/00
BDC_CURSOR = EKPO-NETPR(01)
BDC_OKCODE = BU
306
Sandini Bib
BDC_CURSOR =EKPO_TXZ01(01)
SETVAR & PURCHASE_NR = &M02
PURCHASE-NR = 4500000378
REF ACDE0102 MB01 Wareneingang zur Bestellung buchen
TCD MB01 Wareneingang zur Bestellung buchen [00:35 min E]
SM7060 Beleg 50000415 gebucht
SAPMM07M 0200 Anforderungsbild: Wareneingang zur Bestellung
RM07M-BWARTWE = 101
RM07M-EBELN &PURCHASE_NR = 4500000377
RM07M_WERKS = DEAA
RM07M-LGORT = 0001
BDC_OKCODE = /00
BDC_CURSOR = RM07M_LGORT

SAPMM07M 0221 Auswahlliste: Wareneingang zur Bestellung
BDC_OKCODE = SEUE
BDC_CURSOR = MSEG-ERFMG (01)
SAPLCTMS 0100 Merkmalbewertung: Klassifikation
RCTMS-MWERT (4) = de
BDC_OKCODE = /00
BDC_CURSOR = RCTMS-MWERT (04)
BDC_OKCODE = BACK
307
Sandini Bib
11.1 Testplanung
BDC_OKCODE = BU
BDC_CURSOR = MKPF-BUDAT
REF ACDE0103 MB01 Wareneingang zur Bestellung buchen
TCD MB01 Wareneingang zur Bestellung buchen [00:35 min E]
SM7060 Beleg 50000416 gebucht
SAPMM07M 0200 Anforderungsbild: Wareneingang zur Bestellung
RM07M-BWARTWE = 101
RM07M-EBELN &PURCHASE_NR = 4500000377
RM07M_WERKS = DEAA
RM07M-LGORT = 0001
BDC_OKCODE = /00
BDC_CURSOR = RM07M_LGORT
BDC_OKCODE = SEUE
BDC_CURSOR = MSEG-ERFMG (01)
BDC_OKCODE = BU
BDC_CURSOR = MKPF-BUDAT
SETVAR &AMOUNT = &MAT_QUANTITY * MAT_PRICE
&AMOUT = 10000 * 10
&AMOUT = 100000
308
Sandini Bib
SETVAR &TAX = &AMOUNT * `0,15`
&TAX = 100000 * 0,15
&TAX = 015000
SETVAR &AMOUNT = &AMOUNT * `1,15`
&AMOUNT = 100000 * 1,15
&AMOUNT = 115000
REF ACDE0108 MRHR Rechnung hinzufügen
TCD MRHR Rechnung hinzufügen [00:17 E]
SM8060 Beleg Nr. 1900000011 wurde hinzugefügt
SAPMM08R 0100 Rechungsprüfung:Einstieg
BDC_OKCODE =/00
BDC_CURSOR = BKPF-XBLNR

BKPF_BLDAT &DAT = 19980304
BKPF-BLART = KR
BKPF-BUKRS = de01
BKPF-WAERS = DEM
BKPF-XBLNR = Rechnungs-Nr.
RM08R-EBELN &PURCHASE_NR = 4500000377
SAPMM08R 0110 Rechnungsprüfung: Kreditorenposition
BCD_OKCODE = /00
BSEG-WRBTR & AMOUNT = 115000
BDC_CURSOR = RM08R-WMWST1
RM08R_WMWST1 &TAX = 015000
309
Sandini Bib
11.1 Testplanung
SAPMM08R 0150 Rechungsprüfung: Auswahl der Bestellpositionen
BCD_OKCODE = PB
BDC_CURSOR = EK08R-WRBTR (01)
SAPMM08R 0200 Rechnungsprüfung: Belegübersicht
BDC_OKCODE = BU
BDC_CURSOR = ABTAB-BUZEI (01)
SETVAR &AMOUNT = PKG_QUANTITY * PKG_PRICE
&AMOUNT = 100 * 20
&AMOUNT = 2000
SETVAR &TAX = &AMOUNT * ´0,15`
&TAX = 2000 * 0,15
&AMOUNT = 0300
SETVAR &AMOUNT = &AMOUNT * `1,15`
&AMOUNT = 2000 * 1,15
&AMOUNT = 2300
REF ACDE0108 MRHR Rechnung hinzufügen
TCD MRHR Rechnung hinzufügen [00:04 E]
SM8060 Beleg-Nr. 1900000012 wurde hinzugefügt
SAPMM08R 0100 Rechungsprüfung:Einstieg
BDC_OKCODE =/00
BDC_CURSOR = BKPF-XBLNR
BKPF_BLDAT &DAT = 19980304
310
Sandini Bib
BKPF-BLART = KR
BKPF-BUKRS = de01
BKPF-WAERS = DEM
BKPF-XBLNR = Rechnungs-Nr.
RM08R-EBELN &PURCHASE_NR = 4500000378
SAPMM08R 0110 Rechnungsprüfung: Kreditorenposition
BCD_OKCODE = /00
BSEG-WRBTR & AMOUNT = 2300
BDC_CURSOR = RM08R-WMWST1
RM08R_WMWST1 &TAX = 0300
SAPMM08R 0150 Rechungsprüfung: Auswahl der Bestellpositionen
BCD_OKCODE = PB
BDC_CURSOR = EK08R-WRBTR (01)

SAPMM08R 0200 Rechnungsprüfung: Belegübersicht
BDC_OKCODE = BU
BDC_CURSOR = ABTAB-BUZEI (01)
REF ACDE0057 COR1 Anlegen Prozessauftrag
SETVAR &D01 = &DAT + ´1´
&D01 = 19980304 + 1
&D01 = 19980305
TCD COR1 Anlegen Prozessauftrag [00:35 min E]
S40582 Prozessauftrag 100000411 wurde angelegt
SAPLCOKO 5100 Anlegen Batchauftrag mit Material
311
Sandini Bib
11.1 Testplanung
CAUFVD-MATNR = 10019010090
CAUFVD-WERKS = DEAA
AUFPAR-PI_AUFART = PI01
BDC_OKCODE =/00
BDC_CURSOR = AUFPAR-PI_AUFART
SAPLCOKO 5120 Prozessauftrag: Kopf (normal)
CAUFVD_GAMNG &PRO_QUANTITY = 75
CAUFVD-GLTRP &D01 = 19980305
BDC_OKCODE = OMLA
BDC_CURSOR = CAUFVD-GAMNG
SAPLCOMK 5120 Prozessauftrag: Materialliste zweizeilig
RC27X_FLG_SEL(1) = X
BDC_OKCODE = CHPI
BDC_CURSOR = RC27X-FLG_SEL(01)
SAPLV01F 0100 Chargenauswahl bei Chargenfindung
BDC_OKCODE = Take
BDC_CURSOR = XV01FDP-Menge_P(01)
BDC_OKCODE = Frei
BDC_CURSOR = RESBD-MENGE(01)
BDC_OKCODE = BU
BDC_CURSOR = RESBD-Menge(01)
312
Sandini Bib
SETVAR &ORDNER_NR = &M01
&ORDER_NR = 100000411
REF ADCE0058 CORK Rückmeldung Prozessauftrag gesamt
SRU110 Rückmeldung gesichert, Warenbewegungen: 3, fehlerhaft: 0
SAPFCORU 5400 Einstiegsbild Kopf - Rückmeldung zur Fertigungsauftrag
CORUF-AUFNR &ORDER_NR = 100000411
BDC_OKCODE = /00
BDC_CURSOR = CORUF-AUFNR
SAPLCORU 0410 Rahmen für Detailbilder Kopf - Rückmeldung zum Fertigungsauftrag
AFRUD-LMNGA &PRO_QUANTITY = 75
BDC_OKCODE = MB03
BDC_CURSOR = AFRUD-LMNGA

SAPLM610 0135 P1 Auf Komponenten einzeilige Übersicht
BDC_OKCODE = WEIT
BDC_CURSOR = MDPM-ERFMG (01)
RCTMS-MWERT(4) = de
BDC_OKCODE = /00
BDC_OKCODE = BACK
BDC_CURSOR = RCTMS-MWERT(04)
313
Sandini Bib
11.1 Testplanung
REF ADCE0085 KG12 Zuschlagberechnung IST
TCD KG12 Zuschlagsberechnung IST [00:01 min E]
SAPMKAZB 1000
KAZB-KOKRS = 1000
KAZB-AB_AUFNR &AB_AUFNR = 100000411
KAZB-PERIODE &CO_PERIO = 3
KAZB-GJAHR &GJAHR = 1998
KAZB-TESTLAUF = ´ ´
BDC_OKCODE = ZUBR
BDC_CURSOR = *KAZB-TESTLAUF
REF ADCE0086 KKAX WIP-Ermittlung Auftrag
TCD KKAX WIP-Ermittlung Auftrag [00:03 min E]
SKJ500 1 Objekt wurde bearbeitet, bei 0 Objekten traten Fehler auf
SAPMKKAC 0101 Einstiegsbild der WIP-Ermittlung für Auftrag
AUFK-AUFNR &AUFNR = 100000411
KKA0100-BIS_AGBR_M &BIS_ABGR_M = 3
KKA0100-VERSN &VERSN_ABGR = 0
KKA0100-TESTL = ´ ´
KKA0100-MAXAN = ´ ´
BDC_OKCODE = AUSF
BDC_CURSOR = KKA0100-MAXAN
SAPMKKAC 0101 Einstiegsbild der WIP-Ermittlung für Auftrag
BDC_OKCODE = /EBACK
BDC_CURSOR = KKA0100-BIS_ABGR_M
314
Sandini Bib
REF ADCE0091 KKS2 Abweichungen Fertigungsauftrag
TCD KKS2 Abweichungen Fertigungsauftrag [00:04 min E]
SAPMKKS0 2000 Einstiegsbild: Abweichungen
KKS00-POPER &PERIOD = 3
KKS00-GJAHR &YEAR = 1998
KKS00-TESTL = ´ ´
KKS00-LISTF = ´ ´
BDC_OKCODE = AUSF
BDC_CURSOR = KKS00-LISTF
KKS00-AUFNR &AB_AUFNR = 100000411
REF ADCE0092 K088 Ist-Abrechnung: Auftrag
TCD K088 Ist-Abrechnung: Auftrag [00:08 min E]
SAPLK074 1000 Anforderungsbild für alle Abrechnungstransaktionen
LK074-PERIO &PERIOD = 3

LK074-GJAHR &YEAR = 1998
LKO74-VAART = 1
LKO74-TESTLAUF = ´ `
BDC_OKCODE = AUSF
BDC_CURSOR = LKO74-TESTLAUF
CODIA-AUFNR &AB_AUFNR = 100000411
SETVAR &D01 = &DAT + 7
&D01 = 19980304 + 7
&D01 = 19980311
REF ADCE0050 VA01 Kundenauftrag anlegen Direct Sales
TCD VA01 Kundenauftrag anlegen [00:23 min E]
315
Sandini Bib
11.1 Testplanung
SV1311 Terminauftrag 555 wurde gesichert
SAPMV45A 0101 Verkaufsbeleg Einstieg Anlegen
VBAK-AUART = ta
VBAK-VKORG = de10
VBAK-VTWEG = 01
VBAK-SPART = 51
BDC_OKCODE = ENT2
BDC_CURSOR = VBAK-SPART
SAPMV45A 0400 Auftrag Übersicht zweizeilig
KUAGV-KUNNR &KUNAG = 100263
VBAK-BSTNK = CATT1
RV45A-KETDAT &LIEFERDATUM = 19980311
BDC_OKCODE = ENT1
BDC_CURSOR = RV45A-KETDAT
VBAP-MATNR (1) &MATNR1 = 10019010090
RV45A-KWMENG (1) &PRO-QUANTITY = 75
BDC_OKCODE = ENT1
BDC_CURSOR = RV45A-KWMENG (01)
BDC_OKCODE = SICH
BDC_CURSOR = VBAP_MATNR (02)
SETVAR &SDORDERNR = &M02
&SDORDERNR = 555
316
Sandini Bib
REF ADCE0111 VL01 Anlegen Lieferung mit automatischer Chargenfindung
TCD VL01 Anlegen Lieferung [00:10 min E]
SVL311 Lieferung 80000318 gesichert
SAPMV50A 0100 Lieferung: Einstieg VL01
LIKP-VSTEL &VERSANDST = DE01
LV50C-DATBI &SELEKTDAT = 1998/03/11
BDC_OKCODE = ENT2
BDC_CURSOR = LV50C-DATBI
SAPMV50A 0220 Kommissionierbild
BDC_OKCODE = PALL
BDC_CURSOR = LIPSD-CHMULT (01)

LIPSD-PIKMG (2) &PRO_QUANTITY = 75
BDC_OKCODE = ENT1
BDC_CURSOR = LIPSD-PIKMG (02)
BDC_OKCODE = WABU
BDC_CURSOR = LIKP-VBELN
SETVAR &LIEFERNR = &M02
&LIEFERNR = 80000318
REF ADCE0052 VF01 Anlegen Faktura
TCD VF01 Anlegen Faktura [00:08 min E]
SVF311 Beleg 9000000173 gesichert
317
Sandini Bib
11.1 Testplanung
SAPMV60A 0102
KOMFK-VBELN(1) &LIEFERNR = 80000318
BDC_OKCODE = ENT2
BDC_CURSOR = KOMFK-VBELN(01)
SAPMV60A 0104
BDC_OKCODE = SICH
BDC_CURSOR = KURGV-KUNNR
SETVAR &F2NR = &M01
&F2NR = 9000000173
Dieses Protokoll zeigt, dass der zugrundeliegende CATT-Testablauf fehlerfrei

abgelaufen ist. Die Parameter aller im Testablauf referenzierten Testbausteine
wurden mit den richtigen Daten versorgt. Dieser Integrationstest kann damit als
erfolgreich abschlossen betrachtet werden.
Um die Anforderungen der DIN ISO 9003 zu erfüllen, ist das Testprotokoll noch
zu dokumentieren und zu archivieren. Dies kann z.B. auf der Datenbank des
Systems erfolgen. Das Protokoll und die Dokumentation kann zu diesem
Zweck aber auch ausgedruckt und entsprechend abgeheftet werden. Welche
Anforderungen hierzu in den einzelnen Unternehmen gestellt werden, ist im
jeweiligen Qualitätssicherungshandbuch des Unternehmens festgelegt.
318
Sandini Bib
Testabläufe zu
Geschäftsprozessen des
Referenzmodells
12
In diesem Kapitel wird für ausgewählte Geschäftsprozesse aus dem Referenz-
modell exemplarisch dargestellt, wie die (diesen Geschäftsprozessen zuzuord-
nenden) Testabläufe aussehen können. Außerdem wird zu diesen Prozessen
gegebenenfalls auf die Testbausteine bzw. Testabläufe verwiesen, die standard-
mäßig mit dem R/3-System ausgeliefert werden.
Um dem Leser die Möglichkeit zu bieten, sich bei der Erstellung der einzelnen
CATTs an bekannten Strukturen zu orientieren, werden wir die Geschäftspro-
zesse in der gleichen Reihenfolge bearbeiten, wie dies Keller und Teufel in ih-
rem Buch »SAP R/3 prozessorientiert anwenden« [/Keller98/] getan haben.
Dem Leser, der über CATT hinausgehende Informationen zu den einzelnen Ge-
schäftsprozessen erhalten möchte, findet zudem in diesem Buch umfassende
Beschreibungen der betriebswirtschaftlichen Aspekte und SAP-spezifische Be-
sonderheiten.
Auf diese Beschreibungen wird jeweils zu Beginn der folgenden Abschnitte ei-
gens verwiesen.
12.1 Absatzplanung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 298ff.].
319
Sandini Bib
12.1 Absatzplanung
Der Testablauf
YTL_Absatzplan (Absatzplanung)
YBS_KE11 YBS_KE1G YBS_KEPP YBS_KE11 YBS_KE1E
Testbaustein - Pool
Abbildung 12.1
Testablauf zum Geschäftsprozess »Absatzplanung«
YTL_Absatzplanung

CATT zum Geschäftsprozess »Absatzplanung«
Standard-CATTs
keine
320
Sandini Bib
12.2 Kosten-/Erlösartenbearbeitung
Der Testablauf
YTL_Kostenarten (Kosten-/Erlösartenbearbeitung)
YBS_KA01 YBS_KS01 YBS_KA01 YBS_OB14 YBS_KAH1
Testbaustein - Pool
Abbildung 12.3
Testablauf zum Geschäftsprozess »Kosten-/Erlösartenbearbeitung«
YTL_Kosten-/Erlösartenbearbeitung
Kapitel 12 – Testabläufe zu Geschäftsprozessen des Referenzmodells

CATT zum Geschäftsprozess »Kosten-/Erlösartenbearbeitung«
Standard-CATTs
K1102369, K1103317, K1102547, K1103521, K1102621, P3009025, P00664, P300666
321
Sandini Bib
12.3 Kreditorenstammbearbeitung
12.3 Kreditorenstammbearbeitung
Der Testablauf
YTL_Kreditor (Kreditorenstammbearbeitung)
YBS_FK01
Testbaustein - Pool
Abbildung 12.5
Testablauf zum Geschäftsprozess »Kreditorenstammbearbeitung«
YTL_Kreditorenstammbearbeitung

CATT zum Geschäftsprozess »Kreditorenstammbearbeitung«
Standard-CATTs
K1100833, K1101716, K1102364
322
Sandini Bib
12.4 Debitorenstammbearbeitung
Der Testablauf
YTL_Debitor (Debitorenstammbearbeitung)
YBS_FD01
Testbaustein - Pool
Abbildung 12.7
Testablauf zum Geschäftsprozess »Debitorenstammbearbeitung«
YTL_Debitorenstammbearbeitung

CATT zum Geschäftsprozess »Debitorenstammbearbeitung«
Standard-CATTs
K1100477, K1101754
323
Sandini Bib
12.5 Bestellanforderungsbearbeitung
12.5 Bestellanforderungsbearbeitung
Der Testablauf
YTL_Banf (Bestellanforderungsbearbeitung)
YBS_ME51 YBS_ME52 YBS_ME51 YBS_ME54
Testbaustein - Pool
Abbildung 12.9
Testablauf zum Geschäftsprozess »Bestellanforderungsbearbeitung«
YTL_Bestellanforderungsbearbeitung

CATT zum Geschäftsprozess »Bestellanforderungsbearbeitung«
Standard-CATTs
K1102132, K1101501, S1100739, S1100740
324
Sandini Bib
12.6 Materialstammbearbeitung
Der Testablauf
YTL_Material (Materialstammbearbeitung)
YBS_MM01
Testbaustein - Pool
Abbildung 12.11
Testablauf zum Geschäftsprozess »Materialstammbearbeitung«
YTL_Materialstammbearbeitung

CATT zum Geschäftsprozess »Materialstammbearbeitung«
Standard-CATTs
S1100085, P3002913, P3002920, P3002422, P3002435
325
Sandini Bib
12.7 Kundenkontraktbearbeitung
12.7 Kundenkontraktbearbeitung
Der Testablauf
YTL_Kontrakt (Kundenkontraktbearbeitung)
YBS_VA41 YBS_VA01 YBS_VA41
Testbaustein - Pool
Abbildung 12.13
Testablauf zum Geschäftsprozess »Kundenkontraktbearbeitung«
YTL_Kundenkontraktbearbeitung

CATT zum Geschäftsprozess »Kundenkontraktbearbeitung«
Standard-CATTs
K1100336, K1101145, P3004529
326
Sandini Bib
12.8 Fakturabearbeitung
Der Testablauf
YTL_Faktura (Fakturabearbeitung)
YBS_VF01
Testbaustein - Pool
Abbildung 12.15
Testablauf zum Geschäftsprozess »Fakturabearbeitung«
YTL_Fakturabearbeitung

CATT zum Geschäftsprozess »Fakturabearbeitung«
Standard-CATTs
K1101131, K1101223, K1101306, K1101318, K1101591, K1102028, P3011957,
P3012773, S1100231, S1100886
327
Sandini Bib
12.9 Materialstücklistenbearbeitung
12.9 Materialstücklistenbearbeitung
Der Testablauf
YTL_Stückliste (Materialstücklistenbearbeitung)
YBS_CS01
Testbaustein - Pool
Abbildung 12.17
Testablauf zum Geschäftsprozess »Materialstücklistenbearbeitung«
YTL_Materialstücklistenbearbeitung

CATT zum Geschäftsprozess »Materialstücklistenbearbeitung«
Standard-CATTs
S1100068, S1100087, S1100099
328
Sandini Bib
12.10 Arbeitsplatzbearbeitung
Der Testablauf
YTL_Arbeitsplatz (Arbeitsplatzbearbeitung)
YBS_CR01
Testbaustein - Pool
Abbildung 12.19
Testablauf zum Geschäftsprozess »Arbeitsplatzbearbeitung«
YTL_Arbeitsplatzbearbeitung

CATT zum Geschäftsprozess »Arbeitsplatzbearbeitung«
Standard-CATTs
K1103535, P3021177, S1100313, S1107143
329
Sandini Bib
Sandini Bib
Mercury Testtools
13
13.1 Mercury Interactive Inc. – Das Unternehmen
Mercury Interactive wurde 1989 in den USA gegründet. Seit 1991 besteht eine
Niederlassung in Deutschland. Seinen Stammsitz hat das Unternehmen in
Sunnyvale, Kalifornien, und unterhält Niederlassungen in den USA, Europa
und Japan, unterstützt durch ein weltweites Distributorennetz. Das europäische
Headquarter von Mercury Interactive ist in Paris. In Deutschland befindet sich
der Hauptsitz in München mit Geschäftsstellen in Frankfurt, Düsseldorf, Berlin,
Hamburg und Wien.
Im Geschäftsjahr 1999 wurde weltweit ein Umsatz von 187,7 Millionen US-Dol-
lar erzielt, eine Steigerung von 55 Prozent gegenüber dem Vorjahr. Mercury In-
teractive wurde 1999 von der US-amerikanischen Analystenfirma Merrill Lynch
in die Liste der zehn besten Unternehmen in der High-Tech-Industrie aufge-
nommen. Aktien des Unternehmens werden in den USA unter dem Kürzel
MERQ (Nasdaq) gehandelt. Die Web-Site von Mercury Interactive ist unter
www.mercuryinteractive.com erreichbar.
Mercury Interactive ist der weltweit führende Anbieter von Test- und Perfor-
mance-Management-Lösungen und bietet eine umfassende Produktlinie an
automatisierten Tools zum Testen der Skalierbarkeit, Verfügbarkeit und Zu-
verlässigkeit von Internet-Anwendungen und zur Optimierung der Endbenut-
zererfahrung. Die Lösungen sind unternehmensweit einsetzbar und umfassen
Funktionalitätstests, Testmanagement sowie Last- und Performancetests zur
Unterstützung des Qualitätssicherungsprozesses und des Risikomanagements
beim Testen von Client/Server-, E-Business-, Mainframe- sowie ERP- und
CRM-Applikationen.
331
Sandini Bib
13.2 Testlösungen von Mercury – Executive Summary
13.2 Testlösungen von Mercury –

Executive Summary
In den nachfolgenden Ziffern werden die Testlösungen von Mercury Interacti-
ve, einem führenden Anbieter und Hersteller von automatisierten Tests und
Performance-Management-Lösungen, näher vorgestellt. Die Werkzeuge und
Softwaretechnologien von Mercury Interactive ermöglichen es, Funktionstests
sowie Last- und Performancetests an unterschiedlichen Applikationen inner-
halb des Unternehmens durchzuführen. Neben dem Applikationsbereich SAP
R/3 werden auch die ERP-Lösungen anderer führender Hersteller wie bei-
spielsweise PeopleSoft, Baan und Oracle unterstützt. Erst kürzlich hat der Soft-
warehersteller seine Produktpalette in Richtung CRM/SFA-Applikationen er-
weitert. Darüber hinaus werden die gleichen Lösungen auch für die Bereiche E-
Business, E-Commerce sowie Individualsoftware (z.B. Visual Basic, Delphi,
Oracle, C++,...) angeboten. Die Testunterstützung für IBM-3270/5250-basierte
Terminal-Emulationsumgebungen runden die Palette ab. Die Lösungen von
Mercury Interactive ergänzen und erweitern die bislang vorgestellten Betrach-
tungen zum Thema Funktionstest an SAP R/3-Umgebungen. Neben dem effizi-
enten Test aus Benutzersicht für R/3-Systeme können darüber hinaus komplet-
te horizontale Geschäftsprozesse – etwa über mehrere Applikationen hinweg –
automatisiert abgebildet werden. So ist es z.B. möglich, einen komplexen Ge-
schäftsprozess mit Auftragserfassung über Web-basierte Frontend-Schnittstel-
len, automatische Informationsweiterleitung in SAP R/3-Systeme mit nachge-
schalteter Verarbeitung im Rahmen eines Mainframe- oder Host-basierten
Systems ebenso automatisiert zu untersuchen. Beim Last- und Performancetest
mit LoadRunner kann zu einem sehr frühen Zeitpunkt schon eine erste Abschät-
zung über die zu erwartende Performanceausprägung im jeweiligen kunden-
spezifischen Umfeld erfolgen. Über die Ebene der reinen Benchmarkaktivität
hinaus ergibt sich somit die Möglichkeit, bereits zu einem frühen Zeitpunkt Si-
cherheit im jeweiligen Projektumfeld zu gewinnen. Der erste Test dient somit im
Wesentlichen der Validierung der Architekturentscheidungen. Auf diese Weise
können verschiedene ERP-Lösungen im konkreten IT-Umfeld des Kunden oder
aber unterschiedliche Implementierungsstrategien (z.B. 3-stufige, 4-stufige Ar-
chitektur, Webschnittstelle etc.) eines Herstellers miteinander verglichen wer-
den. Die zweite unerlässliche Einsatzphase für automatisierte Last- und Perfor-
mancelösungen ist dann der Zeitraum von etwa drei bis sechs Monaten vor dem
geplanten Produktivstart. Hier gilt es nunmehr, mit der jeweiligen kundenspe-
zifischen Implementierung die im Projekt benötigten Prozesslandschaften auto-
matisiert abzubilden und mit LoadRunner Hunderte oder Tausende von Benut-
zern bereits im Vorfeld nachzubilden. In diesem Zeitraum sind sehr detaillierte
Performanceaussagen über den späteren Leistungsumfang des Systems mög-
lich, gleichzeitig kann das Systemverhalten bei unterschiedlichen Lastprofilen
untersucht und gegebenenfalls optimiert werden. Sowohl WinRunner Quick-
Test für SAP R/3 als auch LoadRunner für SAP R/3 ergänzen hiermit sowohl
332
Sandini Bib
traditionelle R/3- Einführungskonzepte als auch beispielsweise moderne Im-

plementierungsmethoden wie ASAP oder DSDM.
13.2.1 Applikationsübergreifender Funktionstest mit

WinRunner für R/3
Funktionsprinzip WinRunner für R/3

Bei WinRunner QuickTest für R/3 handelt es sich um ein automatisiertes Test-
werkzeug, das ähnlich wie auch das von SAP entwickelte Computer Aided
Testing Tool (CATT) für automatisierte Tests von Dialogprozessen gedacht ist.
Im Vergleich zu CATT ergeben sich aber auch wesentliche Unterschiede, was
später noch genauer behandelt werden soll. In WinRunner erfolgen alle Testak-
tivitäten stets aus Benutzersicht, es ist also sehr einfach möglich, auch transakti-
onsübergreifende Geschäftsprozesse, die der Benutzer im Dialog mit dem R/3-
System durchführt, automatisiert abzubilden. Für die Testdarstellung wird da-
bei der so genannte »Recording-« oder »Mitschneidemodus« verwendet. Nach-
dem der Benutzer (Fachanwender, Berater, gegebenenfalls auch ABAP-Pro-
grammierer) den Recording-Modus aktiviert hat, werden alle nachfolgenden
Interaktionen des Benutzers mit dem R/3-System mitgeschnitten und in eine
entsprechende Baumstruktur umgesetzt. Für jeden einzelnen Dialogschritt bzw.
Fensterwechsel wird ein separater Eintrag angelegt. So wird es sehr einfach,
auch Geschäftsprozesse, die über verschiedene Transaktionen hinweg durchge-
führt werden, komplett vollautomatisch mitzuschneiden. In einem zweiten
Schritt werden die ursprünglich mitgeschnittenen Daten und Informationen
dann entsprechend angereichert und verfeinert. Auf diese Weise können ohne
große programmiertechnische Eingriffe optionale Dialogschritte ohne die Not-
wendigkeit von Exception-Handling-Mechanismen abgebildet werden. Dies ist
insbesondere wichtig, wenn es etwa geplant ist, denselben Geschäftsprozess mit
unterschiedlichen Testdaten abzuspielen. So ergeben sich z.B. bei der Auftrags-
erfassung unterschiedliche Verzweigungsstrukturen im R/3-System, je nach-
dem, ob ein Kunde nur eine Lieferadresse oder unter Umständen mehrere ver-
schiedene Lieferadressen im System hinterlegt hat. Auch die Variation der Kapitel 13 – Mercury Testtools
jeweils einzugebenden Testdaten ist sehr komfortabel über Excel-ähnliche Test-
datenstrukturen möglich. Alle im jeweiligen Dialogschritt verwendeten Testpa-
rameter können sehr einfach über die rechte Maustaste ( p Parametrisierung)
aufgerufen und dann auch abgeändert werden. Programmierungen von Ver-
zweigungen bzw. Schleifenstrukturen sind somit auch für Fachanwender mög-
lich. Technisch basiert die Schnittstelle von WinRunner für R/3 auf dem so ge-
nannten BC-ATT Interface zu R/3. Diese Schnittstelle ist derzeit offiziell
verfügbar und freigegeben für R/3-Systeme der Versionen 3.0, 3.1, 4.0, 4.5 (ein-
schließlich Version 4.5B). Über diese Schnittstelle können alle mit dem R/3-Sys-
tem durchgeführten Dialogaktionen mitgeschnitten werden und zu einem spä-
teren Zeitpunkt jederzeit reproduzierbar wieder abgespielt werden. Parallel
dazu bietet WinRunner QuickTest für R/3 Schnittstellen zum generischen Re-
333
Sandini Bib
cord-Replay-Werkzeug WinRunner. Darüber hinaus können neben reinen R/3-

Dialoginteraktionen auch die Aktionen von Benutzern mit anderen Applikatio-
nen außerhalb des R/3-Basissystems in einer Geschäftsprozesskette abgebildet
werden.
Abbildung 13.1
Testen der Enterprise application integration (EAI)
Gegenüber dem SAP-eigenen Testwerkzeug CATT ergeben sich aufgrund der

komplett unterschiedlichen technischen Architektur und Testphilosophie un-
terschiedliche Ausprägungen und Eigenschaften. Einige der Kernvorteile von
WinRunner für R/3 sind sicherlich die visuelle Oberfläche und die damit sehr
einfache Anwendung für alle Beteiligten eines R/3-Implementierungsprojektes.
Mithilfe des intuitiven Recordings und der einfachen Manipulierbarkeit der
Testdaten können auch Fachanwender jederzeit problemlos in den Testerstel-
lungszyklus mit einbezogen werden. Einer der Hauptvorteile bei automatisier-
ten Tests ist die Möglichkeit, die Testaktivitäten, die durch Fachanwender
durchgeführt werden, für spätere Regressionstestläufe zu konservieren und je-
derzeit reproduzierbar wieder in das System einzuspielen. Durch die erzielte
Personenunabhängigkeit kann sichergestellt und gewährleistet werden, dass
mit einem gleichbleibend hohen Testabdekkungs- und Qualitätsniveau an der
Projektimplementierung gearbeitet wird. Einzelne Regressionsläufe sind quasi
jederzeit bei gleichem Qualitätsniveau möglich. Hierdurch lassen sich beispiels-
weise sehr schnell und unproblematisch Quereffekte von Customizing-Einstel-
lungen über mehrere R/3-Module hinweg abfangen bzw. validieren. Ein weite-
res wesentliches Abgrenzungsmerkmal zu CATT stellt das sogenannte »EAI-
Testing« (Enterprise Application Integration) dar (siehe Abbildung 13.1). Hier
gilt es, komplexe Geschäftsprozesse über mehrere Applikationsebenen hinweg
aufzuzeichnen und abzuspielen. Nur so ist ein echter End-to-End-Funktionstest
auf Geschäftsprozessebene realisierbar. Die Architektur von WinRunner und
CATT unterscheidet sich gleichermaßen. Während CATT als fester Bestandteil
334
Sandini Bib
des R/3-Systems immer auf dem R/3-Applikationsserver läuft und quasi in den
R/3-Basiskern eingebettet ist, wird WinRunner QuickTest für R/3 oder auch
WinRunner für Tests an Web-, Java- oder anderen Applikationen immer auf der
Client-Seite, also dem Arbeitsplatz installiert und aktiviert. Dadurch ergibt sich
ein etwas anderes Testverhalten. WinRunner arbeitet mit dem R/3-System im-
mer exakt in der gleichen Weise wie der Endanwender, also über die Dialogo-
berfläche. Unter CATT ablaufende Transaktionen verändern hier teilweise ent-
sprechende Dialogschritte bzw. unterliegen auch Limitierungen hinsichtlich der
Art und Weise, wie Geschäftsprozesse aufgezeichnet werden (Mitschneiden der
Einzeltransaktionen und nachfolgendes Aneinanderreihen mehrerer Transak-
tionen zu einem Geschäftsprozess) mit separater Definition von Input- und Out-
putparametern. Abschließend bleibt festzuhalten, dass beide Werkzeuge jeweils
spezifische Vorteile und Leistungsmerkmale aufweisen. Sie sind damit nicht
primär als konkurrierende Werkzeuge einzustufen, sondern können sich inner-
halb einer komplexen Testaktivität jederzeit hervorragend ergänzen.
13.2.2 Last- und Performancetest mit LoadRunner für R/3
Funktionsprinzip von LoadRunner für R/3

Neben dem bereits angesprochenen Funktionstest stellt insbesondere der Last-
und Performancetest einen wesentlichen Sicherheitsfaktor für den späteren
Produktivstart dar. Nur durch den frühzeitigen Einsatz von Last- und Perfor-
mancewerkzeugen lassen sich bereits im Vorfeld Engpässe eindeutig identifi-
zieren, isolieren und, falls notwendig, beheben. Nahezu alle SAP Implementie-
rungsmethoden, sowohl von der SAP selbst als auch die der SAP Logopartner,
sehen vor Produktivstart, gegen Ende des Implementierungszyklus, einen spe-
zifischen Nachweis der Leistungsfähigkeit für das R/3-System vor. LoadRun-
ner für R/3 ermöglicht diesbezügliche Testaktivitäten sehr effizient und genau.
Beim Test mit LoadRunner wird die Systemarchitektur von R/3 optimal unter-
stützt und in keinster Weise verändert oder beeinflusst. Datenbank und Appli-
kationsserverumgebungen bleiben komplett identisch mit dem späteren Pro-
duktivsystem. Alle Testaktivitäten erfolgen von der Client-Seite her. Anstelle Kapitel 13 – Mercury Testtools
von Hunderten oder Tausenden echter Arbeitsplätze werden für den Last- und
Performancetest sogenannte »lastgenerierende Systeme« aufgebaut. Auf jedem
dieser lastgenerierenden Systeme werden dann einzelne Lastbausteine (virtu-
elle User) aktiviert. Jeder einzelne Lastbaustein repräsentiert einzelne Transak-
tionen bzw. Geschäftsprozesse. Die Koordination aller Lastbausteine bzw. aller
Aktivitäten im System erfolgt mit dem LoadRunner Controller zentral von ei-
nem Arbeitsplatz aus (siehe Abbildung 13.2).
335
Sandini Bib
Abbildung 13.2
Einbindung des Load Runner Controller in die Systemarchitektur
Typischerweise wird LoadRunner innerhalb eines R/3-Implementierungspro-

jektes zum Einsatz gebracht. Zum ersten Mal erfolgen Testaktivitäten bereits
frühzeitig, meist auf einem noch nicht oder nur minimal kundenspezifisch ange-
passten (customized) R/3-System. Beim Ersttest in dieser Konfiguration gilt es
noch nicht, die exakte Performance für das später individuell konfigurierte R/3-
System festzustellen, sondern es geht vielmehr um den Nachweis der grundsätz-
lichen Performance im jeweiligen kundenspezifischen Umfeld. Insbesondere zie-
len die Testergebnisse auf die kundenspezifische Hardwareumgebung und In-
frastrukturumgebung (Netzwerk etc.) ab. Dies stellt bereits einen wesentlichen
weiteren Informationsfaktor zum reinen (synthetischen) Benchmarkergebnis.
Alle Benchmarkergebnisse dienen lediglich dazu, Hardware unter synthetischen
Bedingungen vergleichbar zu machen und damit dem Kunden eine bessere und
transparentere Entscheidungsplattform über die (theoretische) Skalierbarkeit
von R/3-Hardware-Plattformen aufzuzeigen. Die Intention von Standard-
Benchmarkergebnissen kann es niemals sein, ein exaktes Abbild der Leistungs-
fähigkeit und des Antwortzeitverhaltens von kundenspezifisch veränderten
R/3-Konfigurationen zu liefern. Der zweite und dritte Einsatzzeitpunkt für Loa-
dRunner liegt gegen Ende des Implementierungszyklus, d.h. vor dem geplanten
Produktivstart. Dann gilt es: a) ganz gezielt die konkrete Leistungsfähigkeit der
336
Sandini Bib
R/3-Implementierung aufzuzeigen. Hierzu werden die kundenspezifischen Ge-

schäftsprozesse und Nutzungsprofile automatisiert abgebildet und umgesetzt.
Und: b) die Performance der jeweiligen kundenspezifischen Infrastruktur zu un-
tersuchen. Hier geht es darum, die Leistungsfähigkeit von LAN/WAN-Kompo-
nenten aufzuzeigen und falls notwendig zu optimieren.
Nutzen
Der Nutzen für R/3-Projekte besteht im Wesentlichen darin, zu jedem Zeit-
punkt einen sinnvollen und genauen Überblick über die Performance und Leis-
tungsfähigkeit des R/3-Systems zu gewinnen. Ganz gleich, ob es nur darum
geht, zu einem frühen Zeitpunkt detailliertere Informationen über die (grobe)
Antwortzeitperformance zu erhalten oder vor Produktivstart Sicherheit zu ge-
winnen über die konkrete kundenspezifische R/3-Implementierung. Zu jedem
Zeitpunkt ist es möglich, sich detaillierte Informationen über Antwortzeitver-
halten sowie über die Skalierbarkeit der R/3-Systeme zu verschaffen. Parallel
dazu erhält man auf Wunsch innerhalb weniger Stunden eine Rückmeldung,
wie sich Änderungen an Systemkonfiguration, Einstellungsparametern, Hard-
ware oder Applikation auf die Performance auswirken (Rückkopplungseffekt).
Diese Feedback-Wirkung erlaubt es, innerhalb kurzer Zeit (typischerweise drei
bis sechs Wochen) auch komplexe Last- und Performancetests zu realisieren
und die jeweiligen Systeme auch aus Sicht der Performance zu stabilisieren und
zu optimieren. Darüber hinaus ist es möglich, die Last- und Performancereak-
tionen des Systems auf unterschiedliche Lastprofile hin zu untersuchen. Das IT-
System bleibt ja schließlich nicht statisch, sondern ist mit kontinuierlich verän-
derten Benutzerprofilen konfrontiert und damit auch Performanceeinflüssen
ausgesetzt. Mit LoadRunner lassen sich auch Spezialfälle wie beispielsweise si-
multane Zugriffe (»Montag-Morgen-Effekt«) – alle zehn, fünfzehn Minuten
kommen weitere Benutzer, loggen sich ein und beginnen mit der Arbeit – oder
Spitzenlasteffekte wie beispielsweise die Zeit nach der Mittagspause oder vor
Feierabend elegant prüfen. Hier ist es möglich, über sogenannte Synchronisati-
onsmechanismen gleichzeitige Zugriffe auf R/3-Systeme nachzubilden. Ein
weiterer Pluspunkt ist darin zu sehen, dass nicht nur Performanceauswirkun-
gen von fachlich korrekter Bedienung der Applikation getestet werden können, Kapitel 13 – Mercury Testtools
sondern darüber hinaus entsprechende »Fehlbedienungen« hinsichtlich ihrer
Auswirkungen auf das Antwortzeitverhalten geprüft werden können (z.B. ar-
beiten zehn Prozent alle Benutzer anstelle von gezielten Parametern mit Match-
Code-Funktionen). Insbesondere bei gemischten Lastprofilen können somit
sehr schnell die tatsächlichen Leistungsreserven in der R/3-Konfiguration aus-
gelotet werden. Einen weiteren wesentlichen Nutzen bringt die Möglichkeit, Ak-
tivitäten im System, die normalerweise über längere Zeiträume sich erstrecken
und auflaufen, in einem quasi Zeitraffereffekt durchzuspielen. So kann bei-
spielsweise ein wachsender Daten- und Informationsbestand im R/3-System
mit seinen Auswirkungen beobachtet werden, indem LoadRunner innerhalb
weniger Stunden bzw. Tage diese Aktivitäten eines Systems durchspielt. Zeit-
337
Sandini Bib
räume von sechs, zwölf oder achtzehn Monaten können folglich innerhalb we-
niger Tage mit Blick auf die entstehenden Datenvolumina abgebildet und um-
gesetzt werden. Hieraus lassen sich dann wieder performancekritische
Informationen etwa zur Beantwortung folgender Fragen ableiten: Wie schnell
wächst die Datenbank? Ab welchem Zeitpunkt ist es notwendig, entsprechende
zusätzliche Archivierungsmechanismen einzuschalten, um über eine sinnvolle
und performancerelevante Datenbankgröße nicht hinauszuwachsen?
Leistungsüberblick LoadRunner
LoadRunner besteht im Wesentlichen aus den folgenden Produktkomponenten:
LoadRunner Controller LoadRunner Virtual User Monitore

Generator (VUGen)
Zentrale Koordinationskon- Werkzeug, um im Recor- Der Netzwerkmonitor er-

sole. Von hier aus werden ding-/Programmierungs- möglicht die detaillierte
Lastprofile erstellt, Lasttest- verfahren einzelne Lastbau- Überwachung und Auf-
zeiten gesteuert und koor- steine für das spätere schlüsselung der Perfor-
diniert. An diesem Arbeits- Lastprofil mitzuschneiden mancedaten für einzelne
platz laufen auch zentral und aufzusetzen. Der Virtu- Netzwerksegmente.
alle Performanceauswer- al User Generator ermög- Der Servermonitor ermög-
tungen und Ergebnisse zu- licht es, Testskripte aus licht den Zugriff auf alle
sammen. dem Bereich WinRunner wichtigen Performanceda-
QuickTest für R/3 nahtlos ten des jeweiligen Server-
(d. h. zu 100 Prozent) zu systems (Applikations-
übernehmen und wieder bzw. Datenbankserver).
zu verwenden. Dadurch ist Informationen über CPO,
ein erheblicher Beschleuni- Speicher, IO, etc. sind de-
gungsfaktor bei der Zusam- tailliert abruf- und auswert-
menstellung von Last- und bar.
Performanceprofilen mög-
lich.
Tabelle 13.1
Produktkomponenten des LoadRunners
In Abbildung 13.3 ist die Generierung von geschäftsprozessorientierten Last-

bausteinen zu sehen. Abbildung 13.4 zeigt die Variation der Testdaten für ver-
schiedene Durchläufe.
338
Sandini Bib
Abbildung 13.3
Generierung von geschäftsprozessorientierten Lastbausteinen
Kapitel 13 – Mercury Testtools
Abbildung 13.4
Variation der Testdaten
339
Sandini Bib
Projektablauf
Der typische Projektablauf beim Last- und Performancetest mit LoadRunner
lässt sich grob wie folgt skizzieren:
A Definition der Testziele, Performanceerwartungen und des Projektzeitrah-
mens
B Vorbereitende Maßnahmen
C Skripterstellung für Lastbausteine
D Aufbau der Lastprofile aus Lastbausteinen
E Testdurchführung
F Monitoring und Protokollierung der Ergebnisse
G Nachtest/Optimierung
Zu 1 Definition der Testziele, Performanceerwartungen und des Projekt-
zeitrahmens
Wie bei allen Test- und Qualifizierungsmaßnahmen wird der Grundstock über
die später zu erzielende Genauigkeit bereits zu einem sehr frühen Zeitpunkt
festgelegt. Hier ist es unabdingbar, sich über die zu verwendende Version des
R/3-Systems, die Anzahl der (gleichzeitigen) Benutzer, Module und Customi-
zing-Einstellungen Klarheit zu verschaffen. Gleichzeitig aber ist es wichtig, rea-
listische und sinnvolle Soll-/Referenzwerte für Antwortzeitverhalten und Ska-
lierbarkeit vorzugeben. Empfehlenswert ist es, prinzipiell Performance immer
im Hinblick auf Geschäftsprozesse zu definieren, das heißt, z.B. 90 Prozent aller
Auftragserfassungsvorgänge kleiner gleich 30 Sekunden anzunehmen anstelle
von 90 Prozent aller Transaktionen kleiner gleich eine Sekunde Antwortzeit.
Nur bei einer geschäftsprozessspezifischen Betrachtung ist hinterher auch ein
optimaler Nutzen für die Performanceoptimierung gegeben. Sollten alle Trans-
aktionen gleich gewichtet werden, ist sicherlich eine etwas schwächere Aussa-
gekraft gegeben, da dann nicht notwendigerweise eine Hundert-Prozent-Ver-
bindung zur Geschäftsprozessperformance möglich ist. Darüber hinaus ist es
wichtig, den möglichen Projektzeitrahmen sowie die Ressourcenstruktur zu ko-
ordinieren.
Zu 2 Vorbereitende Maßnahmen
Systemaufbau: Nun gilt es, die spätere Testumgebung als System aufzubauen.
Idealerweise stehen für Testaktivitäten bereits Zugriffsmöglichkeiten auf das
später zu verwendende Produktivsystem zur Verfügung (zumindest für den
Testrahmen, die Testskripte und Lastbausteine können jederzeit auch auf einem
vorgeschalteten Qualitätssicherungs- oder Integrationssystem erstellt werden).
Sollte der Zugriff auf das Produktivsystem oder eine vergleichbare Hardware-
Plattform aus projektspezifischen Gründen nicht möglich sein, kann man auch
340
Sandini Bib
auf Alternativsystemen testen. Allerdings ist dann die Übertragbarkeit der Er-
gebnisse nicht immer eins zu eins gegeben.
Identifikation der Lastquellen: Nächster Schritt bei den vorbereitenden Maß-
nahmen ist die Identifikation der Lastquellen. Auf jedes R/3-System wirken un-
terschiedliche Lastquellen ein. Als Wesentliche sind hier Dialog-last (d.h. Inter-
aktion der Benutzer mit dem R/3-System), Batchlast (permanent bzw.
zeitgesteuert laufende Hintergrundprozesse) sowie Schnittstellenlast (z.B. auto-
matische Kopplung von R/3 mit anderen Systemen bzw. AME-Kopplung un-
terschiedlicher R/3-Systeme, Edifact-Informationsaustausch). Um eine mög-
lichst genaue Performanceaussage innerhalb des Last- und Performancetests zu
erzielen, ist es wichtig, bereits zu einem frühen Zeitpunkt alle wesentlichen
Last- und Performancequellen zu identifizieren und für den späteren Last- und
Performancetest zu berücksichtigen. Die Abbildung der Dialoglast ist mit Load-
Runner für R/3 einfach und schnell möglich. Alle anderen Lastquellen müssen
projektspezifisch untersucht und gegebenenfalls mit Hilfsapplikationen (z.B.
Edifact-Nachrichtengenerator oder Idoc-Strukturgenerator) nachgebildet wer-
den. Bei der eigentlichen Testdurchführung ist es dann sinnvoll und notwendig,
im Normalfall laufende Hintergrundprozesse realitätsnah zeitgesteuert oder
automatisch aktiviert mitlaufen zu lassen. Nur bei entsprechender Berücksich-
tigung aller Lastquellen können die gemessenen Performanceergebnisse auch
mit dem späteren Realverhalten übereinstimmen.
Auswahl der Geschäftsprozesse: Für einen Last- und Performancetest können
erfahrungsgemäß nicht alle »theoretisch« vorkommenden Geschäftsprozesse
umgesetzt werden. Von einer ausreichenden Genauigkeit der Performanceaus-
sage kann man bei einer Abbildung von ca. 15 bis 30 Geschäftsprozessen ausge-
hen. Die wichtigsten Kriterien für die Auswahl sind Häufigkeit des jeweiligen
Geschäftsprozesses, Kritikalität im Sinne von Performanceeinfluss (so sind z.B.
verbuchungsintensive Geschäftsprozesse sicherlich performancekritischer als
reine Hilfefunktionen) und die Wichtigkeit der Geschäftsprozesse (z.B. wenn
Geschäftsprozess abc nicht funktioniert, dann haben wir ein Problem).
Aufbau der Stamm- und Bewegungsdaten: Nachdem nun ausgewählt und de-
finiert wurde, über welche Schnittstelle welche Informationen in welcher Kom- Kapitel 13 – Mercury Testtools
bination letztendlich eingespielt werden, müssen die entsprechenden Aus-
gangsvoraussetzungen auch auf Systemseite geschaffen werden. Dazu muss
auch innerhalb des R/3-Systems eine entsprechende Informationsmenge vor-
handen sein. Konkret gilt es, eine ausreichende Anzahl von Stamm- und Bewe-
gungsdaten herzustellen. Hier gibt es prinzipiell zwei unterschiedliche Ansätze:
a) Übernahme möglichst vieler Daten aus bereits bestehenden Produktiv- oder
Altsystemen oder b) Neuanlage und Generierung der entsprechenden Datenin-
formation. Beide Ansätze sind möglich und haben sich in der Praxis bewährt. Im
projektspezifischen Kontext wird eine Entscheidung für das jeweilige Vorgehen
gefällt. Je nachdem wie einfach oder schwierig beispielsweise der Zugriff auf be-
reits bestehende Informationssysteme ist, entscheidet man sich für den einen
341
Sandini Bib
oder anderen Weg. Neben der Informationsquelle ist auch die Anzahl der Infor-
mationen von entscheidender Bedeutung für die Genauigkeit der Ergebnisse
der späteren Tests. Sinnvoll ist es, Datenbanken so aufzubauen und vorzuberei-
ten, dass für den eigentlichen Testdurchlauf ein Informationsstand vorliegt, der
dem R/3-System etwa vier bis acht Wochen nach Produktivstart entspricht.
Schließlich nutzt ein Test auf einer nur halb so großen Datenbank wenig, um de-
finitive Performanceaussagen machen zu können. Eine spätere, möglichst ge-
naue Reproduzierbarkeit der Performanceergebnisse erfordert die Sicherung
dieses Datenbankzustands für spätere Nachfolgetests (idealerweise durch eine
Backup-Restore-Möglichkeit).
Zu 3 Skripterstellung für Lastbausteine
Für alle im Rahmen der Testvorbereitung festgelegten und definierten Lastquel-
len müssen nun geeignete Umsetzungsmaßnahmen gefunden werden. Load-
Runner unterstützt in idealer Weise die effiziente Nachbildung der Dialog-last.
Dabei werden die einzelnen Geschäftsprozesse (innerhalb eines R/3-Moduls
bzw. transaktionsübergreifend) aufgezeichnet. Jeder Fachanwender ist folglich
in der Lage, seinen Beitrag zu Last- und Performanceprofil zu liefern. Die bei der
Aufzeichnung »fest verdrahteten« Testdaten werden in einem zweiten Schritt
durch Parameter ersetzt, denen Ein- bzw. Ausgabedateien zugeordnet. Als Da-
tenquelle kann z.B. jederzeit ein externes Excel Spreadsheet verwendet werden.
Alternativ ist auch die Übernahme der Funktionsskripte von WinRunner Quick-
Test für R/3 möglich. Sofern bereits mit WinRunner als Funktionsstestwerk-
zeug Testskripte erstellt worden sind, können diese ohne jede Modifikation für
den Last- und Performancebereich verwendet werden. Neben der Parametrisie-
rung der Testskripte für Test- und Eingabedaten ist die Festlegung des Benut-
zerverhaltens wichtig. Hierbei wird exakt definiert, mit welcher Arbeitsge-
schwindigkeit der emulierte Anwender später mit dem R/3-System arbeitet.
Konkret werden neben einer generellen Arbeitsgeschwindigkeit auch entspre-
chende Pausen bzw. Denkzeiten in die Testskripte integriert. Nur so kann si-
chergestellt werden, dass die nachfolgenden Last- und Performancetests ein
realistisches Ergebnis hervorbringen. Abschließend wird jeder einzelne Last-
baustein für sich selbst auf seine Ablauffähigkeit und korrekte Funktionalität
hin überprüft. Ist dieser Vorgang erfolgreich abgeschlossen, so werden die so
genannten »Messpunkte« hinzugefügt. Hier gilt es zu entscheiden, welche De-
tailinformationen bei der späteren Testdurchführung geprüft und gemessen
werden sollen. So ist es z.B. möglich, sowohl die gesamte Durchlaufdauer eines
Benutzers als Messpunkt zu betrachten, als auch jeden durchgeführten einzel-
nen Dialogschritt. In den meisten Projekten liegt die Realität zumeist zwischen
diesen beiden Extremen. Grundsätzlich ist es zu empfehlen, die Messpunkte an
den wirklich wichtigen geschäfts- oder businesskritischen Stellen zu setzen.
342
Sandini Bib
Zu 4 Aufbau der Lastprofile aus Lastbausteinen

Sind alle Testskripte erstellt, so gilt es, die einzelnen Lastbausteine zu einem
Lastprofil zusammenzufügen. Dabei wird der entsprechende Transaktionsmix
exakt so nachgebildet, wie es auch beim späteren Produktivstart bzw. Wirkbe-
trieb erwartet wird. Durch die Mischung der unterschiedlichen Geschäftspro-
zesse und der unterschiedlichen Lastquellen (z.B. Batch und Dialog) wird ein
sehr realitätsnahes Abbild erreicht. Parallel dazu kann vom LoadRunner Con-
troller aus das Lastprofil beispielsweise geographisch über unterschiedliche
lastgenerierende Systeme verteilt werden. (vgl. Abbildung 13.5)
Abbildung 13.5 Kapitel 13 – Mercury Testtools

Lasttest über verteilte Anwendungen und verschiedene Standorte
Dadurch ist sichergestellt, dass von allen Standorten aus die Performance getes-
tet wird. Der Black-Box-Testaufbau mit LoadRunner macht es so möglich, das
System unter exakt den gleichen Konditionen zu testen, wie sie auch im späte-
ren Wirkbetrieb vorzufinden sind. Dadurch lässt sich nicht nur garantieren,
dass das System eine entsprechende Performance bietet, sondern auch wie viel
Prozent dieser Performance tatsächlich beim Endanwender ankommen. Neben
der Lastverteilung über mehrere Standorte, Netzwerksegmente oder ähnliches
hinweg ist es darüber hinaus auch ratsam, bestimmte Sonderprofile zu definie-
ren. Häufigster Anwendungsfall für Sonderprofile sind sogenannte Spitzenlast-
szenarien wie z.B. »Mittagspausen-Effekt« um 12 Uhr, wenn der Großteil der
343
Sandini Bib
Mitarbeiter in die Mittagspause geht und wenn um 13 Uhr nahezu alle zeit-
gleich zurückkommen und die Arbeit mit dem System erneut aufnehmen. An-
dere Spitzenlastprofile sind Szenarien wie der »Montag-Morgen-Effekt«: Alle
zehn bis fünfzehn Minuten kommen weitere Mitarbeiter, verbinden sich mit
dem System, melden sich an und beginnen mit der Arbeit. Je nach Projekt- bzw.
Kundenumfeld sind alternativ weitere Sonderszenarien wie z.B. gemeinsame
Aktualisierung der Forecasts jede Woche donnerstagabend oder ähnliches
denkbar. In vielen Projekten hat sich hier gezeigt, dass Anwender rein aus Ge-
wohnheitsgründen immer noch zu bestimmten Tätigkeiten Aktionen am Sys-
tem durchführen, weil dies in einem früheren IT-System nur zu diesem Zeit-
punkt möglich war. Auch falls moderne Systeme wie beispielsweise SAP R/3
jetzt hier mehr Flexibilität bieten, werden die alten Gewohnheiten beibehalten.
Technisch realisiert wird die Spitzenbelastung durch den so genannten »Syn-
chronisations-« oder »Rendezvous-Mechanismus«, d.h., in die einzelnen Last-
bausteine werden entsprechende Querverweise eingefügt, so dass die einzelnen
Lastbausteine einander synchronisieren. Dies ist gleichzusetzen mit Meetings,
wo beispielsweise auch einzelne Meetingteilnehmer aufeinander warten. Load-
Runner ermöglicht für die Synchronisation ebenso das Festlegen entsprechen-
der Vorgehensleitfäden. Wie in der Praxis kann auf diese Weise bestimmt wer-
den, wie z.B. verfahren werden soll, wenn nur 80 Prozent aller Teilnehmer eines
virtuellen Meetings tatsächlich erscheinen. So kann beispielsweise definiert
werden, ob das Meeting dann trotzdem stattfindet, d.h. die eingestellte Warte-
zeit durchgeführt wird.
Zu 5 Testdurchführung
Nachdem alle Lastbausteine erstellt worden sind und in einem zweiten Schritt
zu Lastprofilen zusammengefügt wurden, kann die eigentliche Testausführung
beginnen. Obwohl in den meisten Projektumgebungen alle Testteilnehmer dar-
auf brennen, das System unter Spitzenlast agieren zu sehen, sollte man der Ver-
suchung, sofort mit zu hoher Last auf das System zu gehen, widerstehen. An-
dernfalls besteht die Gefahr, dass beispielsweise das System sehr frühzeitig in
die Knie geht (unter Umständen sogar »zerschossen« wird) und man dadurch
wertvolle Testzeit verliert. Es ist daher ratsam, in einem ersten Schritt stufenwei-
se mit mehr und mehr Benutzern gleichzeitig auf das System zu gehen. Eine
sinnvolle Steigerung sind hier beispielsweise fünfzig oder hundert zusätzliche
gleichzeitig damit arbeitende Mitarbeiter. Dadurch erhält man bereits eine erste
aktive Rückmeldung und beugt der Gefahr eines frühzeitigen Systemproblems
vor. In vielen Projektumgebungen stellen auch bereits diese ersten Testaktivitä-
ten eine erste ernst zu nehmende Hürde dar. In einem zweiten Testschritt sollte
dann versucht werden, die zu erwartende Nennlast auf das System zu geben,
also bis zum Zielszenario hochzuskalieren. Hier ist zu beachten, dass jedes Sys-
tem dynamisch reagiert, d.h. so genannte »Einschwingzustände« aufweist. Die
Performanceuntersuchungen dürfen sich nicht nur auf diese Einschwingzeit be-
schränken, sondern zielen insbesondere ab auf den eingependelten, stabilen Zu-
stand nach einer halben Stunde bis zwei Stunden Wirkbetrieb. Nur durch eine
344
Sandini Bib
ausreichend lange Testphase ist sichergestellt, dass nicht nur die optimierten
Antwortzeiten des Systems gemessen werden, sondern das Zusammenspiel al-
ler Systemkomponenten. So ist es nicht selten, dass die Dialogantwortzeiten in
der ersten halben Stunde des Wirkbetriebs sehr gut sind (weil z.B. noch gar kei-
ne physikalischen Verbuchungsvorgänge auf die Festplatten erfolgen). In der
dritten Testphase wird dann versucht, Sonderprofile für Spitzenbelastungszei-
ten und ähnliches nachzubilden oder aber mit veränderten Lastszenarien Per-
formanceuntersuchungen durchzuführen. So kann man beispielsweise mit ei-
ner 25 oder 50 Prozent höheren Belastung als der angenommenen Nennlast
bereits erkennen, welche Sicherheitsreserven für Funktionalität und Perfor-
mance noch im System stecken.
Zu 6 Monitoring und Protokollierung der Ergebnisse
Wie bereits in dem vorherigen Kapitel mit dem Titel »Skripterstellung« kurz
angesprochen, gilt es festzulegen, welche Performancewerte hinterher gemes-
sen werden sollen. Je nach Projektumgebung können hier ganz unterschiedli-
che Parameter entscheidend sein. Für ein R/3-System etwa, das im Call-Cen-
ter-Betrieb betrieben wird, ist die Gesamtdauer des Geschäftsprozesses von
wesentlicher Bedeutung – vom ersten Einstieg in die Dialogmaske bis hin zum
Verbuchen in der Datenbank und erneutem Einstieg für den nächsten Anrufer
am Telefon. Gilt es im Wesentlichen, die Akzeptanz der Endanwender sicher-
zustellen, so ist neben der eigentlichen Geschäftsprozessdauer insbesondere
die so genannte »Dialogwechselzeit« wichtig, die aussagt, wie schnell das Sys-
tem von Maske zu Maske weiterkommt. Je nach Anforderungen werden dann
entsprechend Messpunkte in die Testskripte integriert. Für die Performancea-
nalyse der Testergebnisse wird auf die Messdaten im LoadRunner, genauer im
LoadRunner Controller zugegriffen. Zusätzlich werden Testdateninformatio-
nen aus dem Computing Center Management System (CCMS) von SAP R/3
verwendet. Durch die Kombination dieser beiden Sichtweisen (Black-Box-An-
satz und Inside-Out-Performancemessungen) ist es möglich, in kurzer Zeit ein
genaues Verständnis für die Systemperformance zu gewinnen und entspre-
chende Optimierungsmaßnahmen zu identifizieren und abzuleiten. Während
für die Testskripterstellung einzelne Sachbearbeiter involviert werden können, Kapitel 13 – Mercury Testtools
erfolgt die Zusammenstellung des Lastprofils ebenso wie die Testdurchführung
und Performanceauswertung immer durch Spezialisten. Insbesondere bei der
Performanceanalyse sollten neben R/3-Anwendungs-Know-how auch entspre-
chende Spezialisten aus dem Bereich R/3-Basis bzw. R/3-Implementierungs-
partner anwesend sein. Nur so kann aus den ermittelten Performancewerten
kurzfristig abgeleitet werden, an welchen Stellschrauben (Customizing, Konfi-
gurationseinstellungen, Hardware, Software, Datenbank,...) gedreht werden
muss. Ein Beispiel für die von LoadRunner gelieferten Performancewerte finden
Sie in den Abbildungen 13.6 und 13.7.
345
Sandini Bib
Abbildung 13.6
Darstellung der ermittelten Performancewerte in LoadRunner (1)
Neben der reinen Performancebetrachtung des Systems aus Endanwendersicht

mit den individuell frei konfigurierbaren Messpunkten ist auch eine detaillierte
Untersuchung der Performance für einzelne Netzwerksegmente sowie ein Zu-
griff auf die gesamten Performanceinformationen der Serverbetriebssysteme
möglich.
346
Sandini Bib
Abbildung 13.7
Darstellung der ermittelten Performancewerte in LoadRunner (2)
Zu 7 Nachtest/Optimierung
Sind die Problemstellen der R/3-Konfiguration identifiziert, so kann mit ent-
sprechenden Maßnahmen eine Verbesserung/Optimierung vorgenommen
werden. Durch einen schnellen Nachtest mit dem gleichen LoadRunner-Szena-
rio kann die Auswirkung einer durchgeführter Modifikation auf die Systemper-
formance analysiert werden. Bei allen Optimierungsmaßnahmen ist Folgendes
zu beachten: Was vielleicht in einem Bereich gut ist, kann sich in einem anderen Kapitel 13 – Mercury Testtools
Bereich funktional oder hinsichtlich der Performance negativ auswirken. Kurz
gesagt: Der Weg zum optimierten System ist nicht notwendigerweise eine Ein-
bahnstraße. Durch permanente Tests mit gleichen Lastprofilen bei veränderter
Systemkonfiguration bzw. veränderten Lastprofilen ist es möglich, das Perfor-
manceverhalten der Systeme aus unterschiedlichen Perspektiven zu durch-
leuchten. So kann das System optimal auf den späteren Wirkbetrieb ausgerich-
tet werden.
347
Sandini Bib
Einsatz von LoadRunner in komplexen, heterogenen

Projektumgebungen
LoadRunner als Last- und Performancewerkzeug unterstützt neben den bereits
angesprochenen Testaktivitäten für die Performance im Bereich SAP R/3 eine
Vielzahl anderer Protokollumgebungen. Dadurch kann auch das Zusammen-
spiel von SAP R/3 in komplexeren Kunden-IT-Landschaften untersucht wer-
den. Denkbar sind hier insbesondere Umgebungen wie SAP R/3-Systeme, die
für einen Teilbereich – z.B. Employee Self Service oder Kundenbuchungen –
entsprechende Schnittstellen zu Web- oder Javaumgebungen aufweisen. Pro-
jekt-szenarien reichen hier von der einfachen Darstellung der R/3-Benutzer-
schnittstelle in alternativen Umgebungen wie SAP GUI for HTML oder SAP
GUI for Java bis hin zu komplexen CRM-Systemen (Customer Relationship Ma-
nagement), die eine Querverbindung zu R/3 als ERP-System aufweisen. Eine
weitere oftmals gewählte Variante ist die, verschiedene R/3-Einzelinstallatio-
nen über ALE (Application Linking and Embedding) miteinander zu verbinden.
Auch solche Projektlandschaften können projektübergreifend mit LoadRunner
auf Performanceaspekte hin untersucht werden. Ebenso kann ein Gesamtsy-
stemtest zwischen SAP R/3 und beispielsweise quergekoppelten Mainframe-
oder AS/400-»Legacy«-Systemen getestet werden.
Erfahrungen aus konkreten Projekten - Beispiel 1: Siemens ICN

Seit einigen Jahren nimmt der globale Wettbewerb und Preisverfall im Markt für
Telekommunikationssysteme und -netze stetig zu. Um diesem Trend zu begeg-
nen, hat sich der Siemens-Bereich »Information and Communication Networks«
(ICN) entschieden, seine Geschäftsabläufe durch modernste Informations-
technik zu optimieren. Kernstück ist dabei die Einführung von SAP R/3, Version
4.0B, im Vertrieb Deutschland, der deutschen Vertriebs- und Serviceorganisation
mit 8.000 Mitarbeitern und ca. 4 Mrd. DM Umsatz. Ausgefeilte TK-Lösungen für
Kunden vom kleinen Steuerberater bis zum multinationalen Konzern sind das
Hauptgeschäft des Vertriebs Deutschland. Mit dem Abschluss des eigentlichen
Kundenauftrags und der Installation der TK-Lösung ist jedoch die Kundenbezie-
hung in den seltensten Fällen beendet. Viele TK-Lösungen werden gemietet statt
gekauft und in mehr als 400.000 Fällen wurden Serviceverträge abgeschlossen,
die eine regelmäßige Wartung und schnelle Hilfe im Störungsfall garantieren.
Dieses komplexe Geschäft gilt es, in einer prozessorientierten, durchgängigen
und integrierten Lösung mit R/3 abzubilden.
Ablösung der Kernverfahren, Euro und Jahr 2000
Im Vertrieb Deutschland wurden bislang proprietäre Verfahren eingesetzt, die
auf Großrechnern unter dem Betriebssystem BS2000 laufen. Die Altverfahrens-
landschaft im Vertrieb Deutschland (VD) umfasste eine äußerst diversifizierte
Struktur mit mehr als 100 Einzelsystemen, die über ca. 500 Schnittstellen mitein-
ander kommunizieren. Jedes Altsystem benötigt Service und Updates, die von
verschiedenen Anbietern durchgeführt werden und deshalb ein hohes Maß an
348
Sandini Bib
organisatorischem Aufwand erfordern. Aus diesen Rahmenbedingungen resul-

tierte die Frage, welche Alternativen sinnvoll erscheinen, um die Geschäftsvor-
gänge des Vertriebs Deutschland effizient abwickeln zu können.
Projekt VKD Pro 2000 – Der erste Schritt in die Zukunft
Unter dem Projektnamen VKD Pro 2000 startete im Juni 1997 ein 65-köpfiges
Projektteam, bestehend aus internen Kennern der VD-Geschäftsprozesse und
Beratern bzw. Programmierern der Unternehmen PricewaterhouseCoopers Un-
ternehmensberatung (Lead Consultant), Siemens Business Services (SBS) und
debis Systemhaus. Nach der Analyse der Ist-Geschäftsprozesse wurden diese
zum Teil in optimierter Form, in einem R/3-Prototypen abgebildet. Die haupt-
sächliche Schwierigkeit bestand darin, bestehende Geschäftsprozesse im neuen
System abzubilden. Im Gegensatz zur jahrelangen, gewachsenen unterneh-
mensinternen Optimierung werden Geschäftsprozesse in betriebswirtschaftli-
chen Standardlösungen oft anders abgebildet. Die funktionellen Anforderun-
gen des Vertriebs Deutschland wurden jedoch von Anfang an berücksichtigt
und sind in die Entwicklung der R/3-Lösung eingegangen. Dazu zählten die
Anbindung des TK-Systems unter Nutzung von CTI (Computer Telephony In-
tegration), die Integration von Sales Force Automation und Field Service Tools
sowie die Implementierung von Paging-Funktionalitäten.
Perfekter Service mit SAP R/3
Längst hat sich die Abbildung der Serviceabwicklung in R/3 als eine der we-
sentlichen Herausforderungen des Projektes VKD Pro 2000 erwiesen. Etwa
5.500 Servicetechniker kümmern sich um Montage, Inbetriebnahme und über 1
Mio. Störmeldungen pro Jahr. Eine schnelle Abwicklung ist für die Kundenzu-
friedenheit von entscheidender Bedeutung. Hierfür werden modernste Techno-
logien eingesetzt: CTI (Computer Telephony Integration), HTS (Hicom® Tele
Service, automatische Übernahme von Störmeldungen eines Hicom®-Kommu-
nikationssystems in eine R/3-Servicemeldung), Percy (Benachrichtigung dispo-
nierter Servicetechniker aus R/3 heraus über Cityruf oder Handy) und ein Field
Service Tool, mit dem die Servicetechniker vor Ort die Serviceaufträge bearbei-
ten können. Kapitel 13 – Mercury Testtools
349
Sandini Bib
Das System in Zahlen

Im Rechenzentrum werden zwei mal zwei Hauptrechner vom Typ Siemens
Nixdorf RM600 E70 mit insgesamt 40 Prozessoren (MIPS R10000) und 24 GB
Hauptspeicher sowie einem redundanten Speichersystem der Firma EMC2 mit
insgesamt 1,2 TB Kapazität eingesetzt. Als Datenbank ist Oracle 8 im Einsatz.
Die Rechner überwachen sich stets gegenseitig und können im Störungsfall ei-
nes Rechners sofort dessen Aufgaben übernehmen. Die R/3-Systemkonfigura-
tion für den Performancetest ist in Abbildung 13.8 skizziert.
Abbildung 13.8
Konfiguration des Systems R/3 für den Performancetest
Das System im Performancetest

Im Rahmen der von PricewaterhouseCoopers durchgeführten Performancetests
konnte schnell die optimale Einstellung von Anwendung und Datenbank ge-
funden werden. Die im Rahmen des Sizing-Verfahrens der Produktionsplatt-
form gemachten Aussagen wurden durch einen Test ausgewählter, perfor-
mancekritischer Funktionen überprüft. Hier kam das Performancetest-Tool
LoadRunner von Mercury Interactive zum Einsatz. Abbildung 13.9 zeigt die
Vorgehensweise beim Performancetest. In Abbildung 13.10 sind beispielhaft
Performancemesskurven in LoadRunner zu sehen.
350
Sandini Bib
Abbildung 13.9
Zusammenfassung der Vorgehensweise für den Performancetest
Abbildung 13.10
LoadRunner, beispielhafte Performancekurven
351
Sandini Bib
Nachdem die Testergebnisse bei allen R/3-Modulen positiv ausfielen, bestand

nun eine Basis, um die Ablösung der wesentlichen Altverfahren durchführen zu
können. Seitens der SAP AG wurde der Performancetest von einem Tuning-
und einem Benchmark-Experten im Remote-Modus sowie von einem Koordina-
tor vor Ort unterstützt.
Auf die richtige Karte gesetzt
Auch im direkten Kundenkontakt gab es Neues: Mit der Anbindung von mobilen
Sales-Force-Automation- und Field-Service-Tools an R/3 werden systemüber-
greifende Geschäftsprozesse implementiert, und die Kommunikation zwischen
den Vertriebsbeauftragten bzw. Servicetechnikern und dem Innendienst wird
wesentlich erleichtert. Über die Anbindung von R/3 an das Internet (Electronic
Commerce) wird ein neuer Kommunikationskanal zum Kunden hin geschaffen,
um ausgewählte Partner elektronisch an das System R/3 anzubinden. Im Con-
trolling erfordert die Dynamik der Märkte neue Auswertungsmöglichkeiten in
Planung und Berichterstattung. Mit den zentral in SAP definierten Berichten wird
die Vergleichbarkeit der Organisationseinheiten deutlich verbessert.
Erfahrungen aus konkreten Projekten - Beispiel 2: RWE Energie

In einem groß angelegten SAP Projekt hat die RWE Energie veraltete IT-Systeme
durch R/3 ersetzt. Vor dem Produktivstart am 1. Juli 1999 wurden die Kompo-
nenten des R/3-Systems einem automatisierten Stresstest unterzogen, um Auf-
schluss über Performance und Stabilität zu erhalten und bei Bedarf Optimie-
rungsmaßnahmen einzuleiten. Der RWE-Konzern zählt zu den größten
deutschen Industrieunternehmen. Als konzernleitende Holding koordiniert
und führt die RWE AG die sieben Unternehmensbereiche Energie, Bergbau und
Rohstoffe, Mineralöl und Chemie, Umweltdienstleistungen, Industriesysteme
sowie Bau. In Deutschland hält der Energiekonzern in den Kernbereichen
Strom, Öl, Gas, Wasser und Kohle einen Marktanteil von 15 Prozent. Der Unter-
nehmensbereich RWE Energie hat Mitte 1999 SAP R/3 produktiv eingeführt.
Ziel des Einsatzes der Standardsoftware war es, einen großen Teil der damali-
gen Informationsverarbeitungssysteme zum einen wegen ihres Alters und zum
anderen wegen neuer Anforderungen aufgrund von Geschäftsprozessoptimie-
rungen abzulösen.
»Big Bang« – Produktivsetzung von R/3 bei der RWE Energie
Insgesamt wurden im Zuge der SAP Einführung 46 Informationsverarbeitungs-
systeme durch R/3 komplett ersetzt. Betroffen davon waren die Anwendungs-
gebiete Finanz- und Anlagenbuchhaltung, Controlling, Materialwirtschaft, Per-
sonalwirtschaft, Instandhaltung und Projektabwicklung. Die entsprechenden
R/3-Module wurden gleichzeitig mit dem R/3 Release 4.0B produktiv gesetzt.
Warum die IT-Fachleute dabei von einem so genannten »Big Bang« sprechen,
wird bei diesem Projekt eindrucksvoll deutlich. Insgesamt wurden bei der RWE
352
Sandini Bib
Energie 19 Kraftwerke, zehn Netz- und Versorgungsbetriebe sowie mehrere Be-

teiligungsgesellschaften mit der Standardsoftware versorgt.
Ein immenses Datenvolumen muss bewältigt werden.
Das SAP Projekt beschäftigte etwa 250 Personen, wobei die Anwenderteams
nicht miteingerechnet sind. Mit mehr als 11.000 Anwendern der RWE Energie,
von denen ca. 3.000 gleichzeitig am System arbeiten, verfügt die RWE Energie
heute über eine der bedeutendsten R/3-Installationen weltweit. Die Kernan-
wendungen der SAP-Installation sind im Bereich PM und MM zu sehen. An
Stammdaten werden hier über 2,2 Millionen technische Plätze, über 1,2 Millio-
nen Ausrüstungsteile und über 250.000 Materialposten verwaltet. In der Anla-
genbuchhaltung beträgt das Stammdatenvolumen mehr als 700.000 Anlagen.
Dass an die Systemauslegung hohe Anforderungen gestellt werden, steht außer
Frage. Um nur exemplarisch den Bereich PM und MM zu nennen: Es müssen
täglich 4.000 PM-Aufträge erzeugt werden können. Ferner sind pro Tag ca.
10.000 Materialbewegungen und 4.000 Bestellungen zu bewältigen.
Hochverfügbar und extrem sicher: Die Datenbank
Die Produktionsumgebung basiert auf einer OS/390-DB2-Plattform für den Da-
tenbankrechner und auf RS/6000 unter AIX für die Applikationsserver. Der Da-
tenbankrechner ist eine IBM-9672-Y46-Maschine mit 2 + 4 GB Hauptspeicher
unter OS/390 Version 2.5 und DB2 Version 5.1. Das System ist innerhalb eines
Parallel-Sysplex-Verbunds hochverfügbar abgesichert. Das SAP-System um-
fasst 17 Applikationsserver (IBM RS/6000 SP, je 4 CPUs mit 3 GB Hauptspei-
cher).
Durchführung eines Sizing-Verfahrens für die Hardware-Planung
Wie es für Installationen dieser Größenordnung üblich ist, wurden zwei ver-
schiedene Sizing-Ansätze verfolgt und anschließend die Konsistenz beider Ver-
fahren geprüft. Es wurde zum einen ein User-basiertes Sizing und zum anderen
ein mengenbasiertes Sizing durchgeführt. Das User-basierte Sizing, welches auf
einer CPU-Belastung von 33 Prozent ausgelegt ist, ergab für 3.000 gleichzeitig
aktive User einen Leistungsbedarf der Produktionsumgebung von 10.000 bis
12.000 SAPS. Das mengenbasierte Sizing, ausgelegt auf einen CPU-Verbrauch

von 67 Prozent, lieferte einen Leistungsbedarf von 8.000 bis 10.000 SAPS. Diese
Anforderung wurde durch den Hardware-Lieferanten in Form der jetzt betrie-
benen Umgebung umgesetzt. Vor dem Produktionsstart am 1. Juli 1999 sollte
das Zusammenspiel der Komponenten des SAP R/3-Produktionssystems ge-
meinsam mit der Anwendung in der realen Produktionsumgebung getestet
werden. Durch diesen Stresstest sollte sichergestellt werden, dass die Rechner-
kapazität in ausreichender Größe vorhanden war und dass SAP R/3 aus An-
wendungssicht in dieser Größenordnung optimal betriebsfähig ist.
353
Sandini Bib
Entscheidung für ein automatisiertes Testverfahren

Man entschied sich in Anbetracht der Größenordnung der zu simulierenden
User sehr schnell für ein automatisiertes Testverfahren, zum einen, um reprodu-
zierbare Testläufe durchführen zu können, und zum anderen, um den Auf-
wand, Tausende von Anwendern zu instruieren und zu koordinieren, zu ver-
meiden. Als Werkzeug für den Stresstest entschied sich RWE für LoadRunner
von Mercury Interactive. Infolge der besonderen Architektur der R/3-Systeme
von SAP sind herkömmliche Testwerkzeuge nicht in der Lage, R/3-Scripts auf-
zuzeichnen, weil sie deren Objekte nicht erkennen. Von einem einzigen »Misch-
pult« aus kann LoadRunner das System mit Hunderten oder gar Tausenden vir-
tueller User belasten, um potentielle Engpässe noch vor der tatsächlichen
Inbetriebnahme des Systems zu erkennen – ein unabdingbare Voraussetzung
bei SAP Projekten dieser Größenordnung. Ohne ein automatisiertes Tool wären
derartige Tests nur durchführbar, bei gleichzeitigem Einsatz zahlreicher An-
wender, die zur Durchführung des Tests ihre normalen Aufgaben tagelang hin-
ten anstellen müssten. Der Verlauf des Stresstests bei der RWE Energie spielte
sich wie folgt ab:
A Auswahl der im Test abzubildenden Transaktionen und Ermittlung des ent-
sprechenden Transaktionsvolumens
B Aufzeichnung der Einzeltransaktionen mit dem Tool »WinRunner« von
Mercury Interactive und Aufbau der Stresstest-Datenbank (Daten-Eingabe-
Sätze und Anfangsdatentöpfe für die einzelnen Transaktionen)
C Aufbau des Testmandanten in der echten Produktionsumgebung
D Aufstellen der Stresstest-Server
E Ausführen der Stresstestläufe
F Auswertung und bei Bedarf Einleiten von Abhilfe-Maßnahmen
Erfreuliches Endergebnis für die RWE Energie
Das System bewies eine hohe Stabilität. In einzelnen Bereichen wurden Engpäs-
se und Probleme aufgedeckt, die jedoch kurzfristig behoben werden konnten.
So konnte das schon erfreuliche Ergebnis des Stresstests bis zum Produktions-
start noch weiter gesteigert werden. Auch fachliche Probleme wurden identifi-
ziert. So stellte sich eine Anzeigetransaktion aus dem Bereich MM als kritisch
für die Performance heraus. Dieses Problem wurde durch organisatorische
Maßnahmen beseitigt. Die RWE Energie kann nun nicht nur auf eines der größ-
ten R/3-Systeme zurückgreifen, sondern profitiert zusätzlich von einer hohen
Betriebssicherheit durch die konsequente Entscheidung für den automatisierten
Stresstest. Die Erkenntnisse aus den ermittelten Testdaten haben die Systemop-
timierung nicht nur erheblich erleichtert, sondern erst möglich gemacht und
diesem aufwendigen IT-Großprojekt zum erfolgreichen Abschluss verholfen.
354
Sandini Bib
Typische Probleme der Implementierungen

Der in den meisten in R/3-Projektumgebungen problematischste Bereich ist das
Netzwerk, genauer die Netzwerkverbindung zwischen den Endanwendern
(Einzelplätze) und den jeweiligen Applikationsservern. Insbesondere bei kom-
plexeren Abfragen oder Reports gehen hier sehr viele Daten über das Netz. Je
nach Nutzungsszenario sind die Endanwender über Local-Area- oder Wide-
Area-Netzwerkverbindungen angebunden. Im Backend-Bereich ist das Netz-
werk ebenfalls eine sehr wichtige Komponente, wenngleich sie meist einfacher
in den Griff zu bekommen ist. Insbesondere die Verbindung zwischen Applika-
tions- und Datenbankservern, gegebenenfalls aber auch zwischen verschiede-
nen R/3-Systemen gekoppelt, ist kritisch und damit entscheidend für die Per-
formance. Im Bereich der Server-Hardware sind insbesondere die Anzahl der
Applikationsserver sowie die spezifischen Konfigurationen der Datenbankser-
ver wesentlich für eine optimale Leistungsfähigkeit. LoadRunner ermöglicht es,
einfach und unkompliziert zu prüfen, ob die bessere Lösung beispielsweise in
einer Erhöhung der Anzahl der Applikationsserveranzahl oder aber in der Kon-
figuration entsprechend größerer Maschinen bei gleicher Anzahl von Applika-
tionsservern besteht. Auch die Konfigurationseinstellungen in den einzelnen
Datenbankservern können auf Performanceaspekte hin beleuchtet werden. Im
Bereich der Anwendung entstehen die Performanceengpässe überwiegend in
der Komplexität der Customizing-Einstellungen bzw. in den entsprechenden
Sperren. Sind z.B. Lockingmechanismen auf zu großer Basis implementiert, so
werden jeweils zu hohe Datenmengen für andere Benutzer gesperrt. Ist die Im-
plementierung zu feingliedrig, so ist die Anzahl der insgesamt in der Datenbank
bzw. im Applikationsserver zu verwaltenden Sperren zu hoch. Insbesondere bei
Eigenentwicklungen und ABAP-Erweiterungen sollte hierauf geachtet werden.
Weitere performancekritische Bereiche sind z.B. die Anzahl der Verbucherpro-
zesse bzw. die Konfiguration der so genannten »Collections« in den Applikati-
onsservern. Diese Bufferbereiche sind sehr empfindlich und müssen unbedingt
optimal konfiguriert werden. Als Grundlage hierfür können das kundenspezi-
fische Transaktionsprofil und -volumen herangezogen werden. Für die Perfor-
manceoptimierung kann es durchaus hilfreich sein, je nach Tagesbetrieb bei-
spielsweise dediziert die Funktionalität von Applikationsservern zwischen
Batch- und Dialogbetrieb umzuschalten.
13.2.3 Verwaltung von Funktionstest und Lasttest mit

TestDirector
TestDirector unterstützt und verwaltet die gesamten Testaktivitäten dadurch,
dass die Prozesskette für Testaktivitäten abgebildet und umgesetzt wird. Kon-
kret werden in einem gemeinsamen Informationsrepository sowohl manuelle
als auch automatisierte Testaktivitäten (Funktionstest sowie Last- und Perfor-
mancetest) erfasst und verwaltet. Durch die Aufgliederung in die drei wesentli-
355
Sandini Bib
chen Phasen Planung, Testdurchführung und Fehlerverfolgung können über-

sichtlich alle Informationen gespeichert und jederzeit abrufbar verwaltet
werden. In jedem der drei Teilbereiche ist neben der effizienten Informationsab-
lage ebenso ein umfassendes Berichts- und Auswertungssystem enthalten. So
lassen sich komplexe Fragestellungen wie ‚In welchem Modulbereich haben wir
die größten Probleme identifziert?‘ oder ‚Welche gravierenden Punkte müssen
vor Freigabe in jedem Fall behoben sein?‘ nahezu auf Knopfdruck beantworten.
TestDirector steht als Testmanagement-Plattform für alle Applikations- und
Anwendungsbereiche zur Verfügung. D.h. auch Projektumgebungen außer-
halb von SAP R/3 werden genauso gut und effizient unterstützt. Durch die be-
reitgestellte offene Architektur ist TestDirector sehr flexibel über offene Schnitt-
stellen an die jeweilige Kundenlandschaft anpassbar. Im Bereich SAP R/3 ist
hier insbesondere die Schnittstelle zu Intellicorp Live Model erwähnenswert.
Damit ist es möglich, die im Bereich Geschäftsprozess-Modellierung definierten
Geschäftsprozessabläufe per Knopfdruck in den TestDirector zu übernehmen.
Konkret bedeutet dies, dass für jeden einzelnen Geschäftsprozess automatisch
ein entsprechender Eintrag in die Testfallverwaltung vorgenommen wird, so
dass bei den späteren Testaktivitäten kein Geschäftsprozess ausgelassen oder
vergessen werden kann. Durch die Verwaltung aller Testergebnisse an einer
zentralen Stelle kann insbesondere der Bereich Ergebniskonsolidierung der
Testaktivitäten bzw. Abschätzen des gesamten Reifezustandes für das Projekt
verbessert werden. Dadurch dass alle Mitarbeiter auf den jeweils gleichen Infor-
mationspool zugreifen bzw. mit gleichen Testskripten oder Testdaten arbeiten,
kann darüber hinaus die Zeitdauer für Problemreproduktion signifikant verbes-
sert und beschleunigt werden. Weiterer Nebeneffekt der zentralen Verwaltung
ist die Möglichkeit, Testergebnisse auch sechs, acht, zwölf oder noch mehr Mo-
nate nach dem ersten Testzyklus jederzeit erneut abrufen zu können. Dadurch
kann unmittelbar geprüft werden, wer denselben Testfall zu einem früheren
Zeitpunkt bereits mit welchen Ergebnissen im System durchgeführt hat. Zielset-
zung von TestDirector ist es, den gesamten Qualitätssicherungsprozess soft-
waremäßig abzubilden und zu unterstützen und dadurch zu einer Beschleuni-
gung der Implementierungsdauer beizutragen.
13.2.4 Zusammenfassung und Fazit

In dem vorangegangenen Ziffern wurden unterschiedliche Testlösungen für
unterschiedliche Bereiche der Qualitätssicherung vorgestellt. TestDirector als
Testmanagementwerkzeug legt das Fundament für alle Testaktivitäten. Hier
werden Informationen konsolidiert und zentral verwaltet. Mit WinRunner
QuickTest für R/3 ist es möglich, Geschäftsprozesse jederzeit auf Knopfdruck
automatisierbar wieder im System abspielen zu lassen. Ziel dabei ist es, zu prü-
fen, ob sich die Applikation heute noch genauso verhält wie beim letzten Test-
durchlauf oder ob es zu unerwünschten Nebeneffekten kommt. LoadRunner
wird eingesetzt, um mit einem überschaubaren Aufwand an Hardware das Sys-
356
Sandini Bib
tem mit einer hohen Anzahl von Benutzern zu betreiben, um Systemstabilität

sowie Last- und Performanceverhalten zu untersuchen und zu optimieren. In
allen Bereichen der Testaktivitäten ist es wichtig, dass das ursprüngliche Ziel im
Auge behalten wird. Zielsetzung einer jeden IT-Implementierung und somit
auch eines jeden R/3-Projektes ist es, den Endanwendern und Benutzern einen
entsprechenden Businessnutzen zu liefern. Dies bedeutet in der Praxis, dass die
Anforderungen, was Stabilität, Funktionalität und Performance angeht, erfüllt
sein müssen. Die Grundvoraussetzungen hierfür werden sicherlich in den Be-
reichen Projektmanagement sowie Auswahl der IT-Systeme und -Architekturen
gelegt. Qualität sollte niemals in ein System »hineingetestet« werden, sondern
kontinuierlicher Bestandteil des Projektimplementierungszyklus sein. Auch
beim Aufbau der Testaktivitäten gilt es, an der einen oder anderen Stelle vertret-
bare Kompromisse zu finden, um zu einem wirtschaftlich guten Ergebnis zu
kommen. Dies gilt auf der Projektmanagementebene (Gesamtimplementie-
rungsdauer und Zeitrahmen für QS-Maßnahmen) ebenso wie auf der Detailebe-
ne Funktionstest (Testabdeckungsgrad horizontal über verschiedene Module
und Applikationen hinweg im Gegensatz zum vertikalen Testabdeckungsgrad
in die fachliche Tiefe hinein, d.h., alle Feinheiten und Variationen der Geschäfts-
prozesse zu prüfen) oder im Last- und Performancebereich (Konfiguration und
Optimierung des Systems auf Nennlastprofil gegenüber Optimierung auf Spit-
zenlastprofile hinweg). Die Testlösungen von Mercury Interactive unterstützen
die R/3-Implementierungen dadurch, dass die Bereiche Stabilität, Funktionali-
tät und Performance kontinuierlich geprüft werden können, und machen damit
ein optimales Risikomanagement der jeweiligen Projekte möglich.
13.2.5 Der Autor des Kapitels

Manfred Eierle, Dipl.-Ing., (31) ist am 1. Januar 1998 zum Geschäftsführer der
Mercury Interactive GmbH ernannt worden. Er ist seit März 1996 bei Mercury
Interactive und war zuvor als Account Manager für die Betreuung von Groß-
kunden und strategischen Partnern verantwortlich.
Vor seinem Eintritt bei Mercury Interactive GmbH war Manfred Eierle fünf Jah-
re bei NCR und AT&T Global Information Solutions tätig. Dort zeichnete er zu-
letzt als Projekt Manager für die Leitung von Entwicklungsprojekten (Personal
Computer-Plattformen und Softwarelösungen) verantwortlich. In seinen Auf-
gabenbereich fiel neben der weltweiten Koordination von Marketing, Einkauf,
Produktmanagement, Entwicklung und Fertigung auch die Produktauswahl
und Erstellung von Produktspezifikationen und Projektplänen.
Manfred Eierle, der am 9. Juni 1967 in Schwabmünchen geboren wurde, hat
nach der Fachoberschule in Augsburg ein Studium der Elektrotechnik mit dem
Schwerpunkt Nachrichtentechnik absolviert. Für seine Diplomarbeit erhielt er
eine Auszeichnung des VDI (Verband der Deutschen Industrie).
357
Sandini Bib
Sandini Bib
Anhang A
A
Das nachfolgend abgebildete traditionelle Vorgehensmodell zur Einführung
der R/3-Software wurde von der SAP entwickelt. Jede Aktivität innerhalb der
einzelnen Phasen dieses Vorgehensmodells, die mit CATT abgearbeitet werden
kann, ist mit dem Zusatz »CATT« gekennzeichnet.
Jeder Arbeitsschritt, der mithilfe der Testworkbench durchgeführt werden
kann, wird im Folgenden mit dem Zusatz »Testworkbench« versehen.
A.1 R/3-Einführung:
Traditionelles Vorgehensmodell
A.1.1 Phase 1: Organisation und Konzeption
Projekt vorbereiten
Projekt initialisieren
Unternehmensziele des R/3-Einsatzes definieren
Bestandsaufnahme durchführen
Prozesse/Funktionen des R/3-Systems kennen lernen
Geschäftsprozesse definieren
Funktionale Anforderungen mit R/3-System abgleichen
Abbildung der Unternehmensstruktur erarbeiten
Ziele und Umfang von Standardisierungsvorhaben definieren
Einführungsstrategie festlegen
359
Sandini Bib
A.1 R/3-Einführung: Traditionelles Vorgehensmodell
Hardware-Bedarf ermitteln
Projektaufbauorganisation festlegen
Projektstandards und -arbeitsweise festlegen
Systemlandschaft festlegen
Aufwands-, Termin- und Kostenplan erstellen
Ergebnisse der Projektvorbereitung verabschieden
Projektauftrag erstellen
Kick-off des Einführungsprojektes durchführen
Systemlandschaft einrichten
Systeme und Mandanten einrichten CATT
Benutzerstammsätze für Projektmitarbeiter einrichten CATT
Mandantensteuerung, Korrektur-/Transportwesen einrichten
Systemumfeld einrichten
Remote-Verbindung einrichten
Landesspezifische Voreinstellungen ändern
Unternehmens-IMG erzeugen
Customizing-Projekte anlegen
Projektteam schulen
Projektteam ausbilden CATT
R/3-Funktionalität kennenlernen CATT
Prozesse/Funktionen festlegen
Prozesse/Funktionen anhand des Referenzmodells spezifizieren
Verantwortung für Prozesse/Funktionen festlegen
Input/Output-Informationsobjekte überprüfen
Anforderungen an das Berichtswesen ermitteln
Schnittstellen und Systemerweiterungen bestimmen
Abbildung der Unternehmensstruktur festlegen
Prototyping ausgewählter Prozesse/Funktionen durchführen
DV-Konzept spezifizieren
Fach- und DV-Konzept abstimmen
360
Sandini Bib
Schnittstellen und Systemerweiterungen entwerfen

Detailbeschreibung für die Schnittstellen erstellen
Detailbeschreibung für die Systemerweiterungen erstellen
Ausarbeitung für die Datenübernahme erstellen
Qualitätsprüfung Sollkonzept
Projektaufbau- und -ablauforganisation überprüfen
Einhaltung der Projektstandards überprüfen
Systemlandschaft überprüfen
Sollkonzept überprüfen
Schnittstellen- und Systemerweiterungsbeschreibung überprüfen
Projektplanung überprüfen
Prüfungsprotokoll erstellen
Freigabe der nächsten Phase veranlassen
A.1.2 Phase 2: Detaillierung und Realisierung
Globale Einstellungen vornehmen

Globale Einstellungen kennen lernen
Globale Einstellungen anpassen
Unternehmensstruktur abbilden
R/3-Systemorganisationseinheiten prüfen und anpassen
Grund- und Stammdaten abbilden

Felder und Inhalte für Stammdaten festlegen CATT
Systemeinstellungen für Stammdaten durchführen CATT
Systemeinstellungen für Stammdaten testen CATT
Beschreibung für die Stammdatenübernahme detaillieren CATT
Anhang A
Prozesse/Funktionen abbilden
Felder und Inhalte für Prozesse/Funktionen festlegen CATT
Systemeinstellungen für Prozesse/Funktionen durchführen CATT
361
Sandini Bib
Systemeinstellungen für Prozesse/Funktionen testen CATT

Ausgewählte Prozesse/Funktionen Fachabteilungen vorstellen
Beschreibung für die Datenübernahme detaillieren CATT
Schnittstellen und Systemerweiterungen realisieren

Datenübernahmeprogramme erstellen CATT
Schnittstellen realisieren
Systemerweiterungen realisieren
Datenübernahmeprogramme testen CATT
Schnittstellen testen CATT
Systemerweiterungen testen CATT
Berichtssystem abbilden
Informationsbedarf ermitteln
Informationsbedarfsabdeckung prüfen
Lösungen für noch offene Anforderungen erstellen
Organisation des Berichtssystems festlegen
Berichtssystem testen
Archivverwaltung abbilden
Konzept für Archivverwaltung erstellen
Systemeinstellungen durchführen
Archivierungsvorgänge testen
Berechtigungsverwaltung abbilden
Berechtigungskonzept erstellen
Berechtigungskonzept realisieren
Berechtigungen testen
Abschlusstest durchführen
Testkonzept erstellen Testworkbench
Testplan erstellen Testworkbench
Testaktivitäten durchführen CATT
362
Sandini Bib
Bericht zum Abschlusstest erstellen CATT

Abschlussreview mit den Fachabteilungen durchführen
Qualitätsprüfung Anwendungssystem
Projektaufbau- und -ablauforganisation überprüfen
Einhaltung der Projektstandards überprüfen
Umsetzung Sollkonzept überprüfen
Schnittstellen-/Systemerweiterungsrealisierung überprüfen
Berichtssystem überprüfen
Archivverwaltung überprüfen
Berechtigungskonzept überprüfen
Abschlusstest überprüfen
A.1.3 Phase 3: Produktionsvorbereitung

Produktivsetzung vorbereiten
Konfiguration für das Produktivsystem konkretisieren
Beschaffung der Systemausstattung durchführen
Benutzerstammsätze anlegen CATT
Planung für die Datenübernahme erstellen
Anwenderdokumentation entwickeln
Struktur, Inhalt und Medien festlegen
Erstellung der Anwenderdokumentation vorbereiten
Änderungskonzept erstellen
Anwenderdokumentation erstellen
Produktivumgebung einrichten
Anhang A
Netzwerk installieren
Hardware und Software am Arbeitsplatz installieren
R/3-System im Produktivsystem installieren
363
Sandini Bib
Anwender schulen
Schulungsprogramm erstellen CATT
Schulungen vorbereiten CATT
Schulungen durchführen CATT
Systemadministration organisieren
Systemadministration festlegen
Systemadministratoren schulen
Daten in das Produktivsystem übernehmen

Systemeinstellungen und Objekte übernehmen
Datenübernahme durchführen CATT
Daten manuell erfassen
Datenübernahme abnehmen lassen
Qualitätsprüfung Produktivsystem
Anwenderdokumentation überprüfen
Produktivumgebung überprüfen CATT
Durchgeführte Anwenderschulung überprüfen
Organisation der Systemadministration überprüfen
Datenübernahmen überprüfen CATT-Protokoll
A.1.4 Phase 4: Produktivbetrieb
Produktivbetrieb unterstützen
Anwender in der produktiven Anfangsphase betreuen
Permanente Betreuung durch Help-Desk-Organisation festlegen
Systemnutzung optimieren
Systemeinsatz überwachen und optimieren CATT
364
Sandini Bib
Anpassungen vornehmen
Projekt offiziell abschließen
Projektadministration und Projektcontrolling

Feinplanung durchführen
Projektstatus ermitteln
Korrekturmaßnahmen veranlassen
Projektbesprechungen durchführen
Systemwartung und Release-Wechsel

System-Upgrade/Release-Wechsel durchführen CATT
Release-Customizing durchführen CATT
Anhang A
365
Sandini Bib
Sandini Bib
Anhang B
B
B.1 Aufgabenbeschreibung der ASAP-Phasen
Das nachfolgend abgebildete ASAP-Vorgehensmodell zur Einführung der R/3-
Software wurde von der SAP AG entwickelt. Jede Aktivität innerhalb der ein-
zelnen Phasen dieses Vorgehensmodells, die mit CATT abgearbeitet werden
kann, ist mit dem Zusatz »CATT« gekennzeichnet.
Jeder Arbeitsschritt, der mithilfe der Testworkbench durchgeführt werden
kann, wird im Folgenden mit dem Zusatz »Testworkbench« versehen.
B.1.1 Phase 1: Projektvorbereitung
Projektplanung erstellen
Projektauftrag erstellen
Formulierung des Projekts Mission Statements
Business-Drivers bestimmen
Betriebswirtschaftliche Erfolgskennzahlen festlegen
Projekterfolgskennzahlen bestimmen
Inhalte des Projektauftrags zusammenstellen
Genehmigung des Projektauftrags
Einführungsstrategie prüfen und detaillieren
Einführungsvorschlag prüfen
Einführungsmethode bestätigen
367
Sandini Bib
Roll-out-Strategie des Unternehmens prüfen

Arbeitsumgebung des Projektteams einrichten
Arbeitsumgebung planen
Arbeitsumgebung einrichten
Projektstruktur bestimmen
Organisation und Rollen festlegen
Mitarbeiter den Rollen zuordnen
Übergabemeeting durchführen
Projektplan erstellen
Projektplan erstellen
Projektbudgetplan erstellen
Projekteinsatzplan erstellen
Schulungsplan für das Projektteam erstellen
Vorschläge aus Vorprojektphase prüfen
Schulungsplan überarbeiten
Schulungsteam anmelden und Schulungstermine festlegen
Projektabläufe
Projektmanagementstandards und -abläufe definieren
Kommunikationsplan festlegen
Projektdokumentation definieren
Plan für Issue-Management erstellen
Plan für Projektumfang-Management erstellen
Plan für teambildende Aktivitäten festlegen
Standards für Projektplanung und -controlling definieren
Verwendung der R/3-Services festlegen
Verfahren der Qualitätssicherung bestimmen CATT
Einführungsstandards und -abläufe definieren
Standards für Systemkonfiguration entwickeln
Strategie für Benutzerschulung und Dokumentation definieren
368
Sandini Bib
Teststrategien festlegen CATT

Strategie für Service und Support nach Einführung definieren
Systemberechtigungsstandards für Projektteam definieren
Verfahren zur Problem- und Fehlerbehandlung festlegen
Genehmigungsverfahren für Systemerweiterung und Modifikationen
definieren
Systemlandschaft definieren
Erforderliche Systeme bestimmen
Mandantenstrategie festlegen
Releasestrategie definieren
Transportwesen festlegen
Projekt-Kickoff
Kickoff-Meeting
Kickoff-Meeting vorbereiten
Kickoff-Meeting durchführen
Projekt unternehmensweit vorstellen
Meeting zur Vorstellung der Projektstandards
Meeting zu Projektstandards vorbereiten
Meeting zu Projektstandards durchführen
Planung der technischen Anforderungen

Technische Anforderungen ermitteln
Technische Fragebögen ausfüllen
Anforderungen an Systeminfrastruktur festlegen
Hardware beschaffen
Bedarf der Hardware-Grundausstattung ermitteln
System-Sizing-Ergebnisse prüfen
Anhang B
Sizing-Ergebnisse abstimmen
Hardware bestellen
Remote-Netzwerkanbindung bestellen
369
Sandini Bib
Qualitätsprüfung Projektvorbereitung
Qualitätsprüfung vornehmen und Abnahme durchführen
Qualitätsprüfung durchführen
Projektvorbereitungsphase abnehmen
B.1.2 Phase 2: Business Blueprint
Projektmanagement Business Blueprint

Abstimmung des Projektstatus
Status-Meetings vorbereiten
Status-Meetings durchführen
Erledigung der zugeordneten Aufgaben verfolgen
Projektabweichung korrigieren
Projektplan anpassen
Lenkungsausschuss
Lenkungsausschuss-Meetings vorbereiten
Lenkungsausschuss-Meetings durchführen
Allgemeines Projektmanagement
Change Management
Teambildende Aktivitäten durchführen
Rollen und Zuständigkeiten der Benutzer definieren
Schulung des Projektteams Business Blueprint

Projektteamschulung durchführen CATT
Schulungsprogramm detailliert ausarbeiten CATT
Schulung vorbereiten CATT
Kenntnisse nach Schulung prüfen und bewerten
370
Sandini Bib
Systemumgebung entwickeln
Technisches Konzept entwerfen
Systeminfrastruktur und Verteilung dokumentieren
Druckerinfrastruktur definieren und dokumentieren
Netzwerktopologie dokumentieren
Schnittstellentopologie dokumentieren
Change-Request-Management definieren
Release-Management-Strategie definieren
Desktop-Management-Strategie definieren
Technisches Konzept abstimmen
Entwicklungsumgebung einrichten
Hardware-Grundausstattung installieren
Systemumgebung überprüfen
Entwicklungsmandant einrichten und konfigurieren CATT
Desktop-Komponenten für Projektteam installieren
Benutzerstammsätze für Projektteam einrichten CATT
Entwicklungssystem sichern
Druckdienste für Projektteam installieren und konfigurieren
Remote-Netzwerkanbindung konfigurieren
Remote-Anbindung zu SAP einrichten
Systemlandschaft einstellen
Entwicklungsmandanten einrichten und konfigurieren CATT
Transportsystem konfigurieren und testen CATT
Systemverwaltung
Basis- und Systemsworkshop durchführen
Systemverwaltung für Entwicklungssystem definieren
CCMS konfigurieren
Anhang B
Backup-Strategie definieren
Funktionen der Systemverwaltung überprüfen
Periodische Vorgänge der Systemverwaltung festlegen
371
Sandini Bib
Implementation Guide (IMG) initialisieren

Unternehmens-IMG erstellen
Projekt-IMG erstellen
Organisationsstruktur
Unternehmensstrukturen bestimmen
Unternehmensstruktur-Workshop planen
Empfehlungen zur Unternehmensstruktur verteilen
Unternehmensstruktur-Workshop durchführen
Unternehmensstruktur empfehlen und abstimmen
Geschäftsprozessdefinition
Geschäftsprozess-Workshops vorbereiten
Geschäftsprozess-Workshops planen
Workshop zur Vorgehensweise bei Prozessdefinition durchführen
Workshop zu globalen Anforderungen durchführen
Globale Parameter festlegen
Unternehmensspezifische Standards festlegen
Geschäftsprozess-Workshops durchführen
Anforderungen zu Geschäftsprozessen bestimmen
Bedarf an erweiterter R/3-Funktionalität bestimmen
Anforderungen zum Berichtswesen bestimmen
Erforderliche Schnittstellen bestimmen
Anforderungen zur Datenübernahme bestimmen
Erforderliche Erweiterungen bestimmen
Bereiche mit niedrigem Abdeckungsgrad klären
Beschreibungen und Modelle der Geschäftsprozesse detaillieren
Bedarf an zusätzlichen detaillierten Workshops bestimmen
Detailanforderungs-Workshops planen
372
Sandini Bib
Detailanforderungs-Workshop durchführen
Detaillierte Anforderungen bestimmen
Geschäftsprozessdefinition und -modelle optimieren
Business Blueprint vervollständigen
Projektorganisation und -rollen detaillieren
Blueprintdokumente zusammenstellen
Baseline-Umfang ermitteln
Vollständigkeit des Blueprints überprüfen
Prüfung und Freigabe Business Blueprint
Blueprint-Präsentation vorbereiten
Prüfung und Freigabe durchführen
Benutzerschulung planen
Umfang, Inhalt und Ablauf der Benutzerschulung festlegen
Benutzerschulungsplan ausarbeiten
Benutzerschulungsplan abstimmen
Qualitätsprüfung Business Blueprint

Business-Blueprint-Freigabe
B.1.3 Phase 3: Realisierung
Projektmanagement Realisierung
Abstimmung des Projektstatus
Anhang B
Projektabweichungen korrigieren
373
Sandini Bib
Lenkungsausschuss
Ausgangsplanung für Produktionssupport und Cutover
Plan für Produktionssupport festlegen
Plan für Cutover festlegen
Change Management
Teambildende Aktivitäten durchführen
Schulung des Projektteams Realisierung

Projektteamschulung durchführen
Schulungsprogramm detailliert ausarbeiten CATT
Schulung vorbereiten CATT
Kenntnisse nach Schulung prüfen und bewerten
Baseline-Konfiguration und -Abnahme

Pläne für Baseline-Konfiguration erstellen
Baseline-Umfang verfeinern
Konfigurationsplan für Baseline erstellen
Testfälle bestimmen Testworkbench
Testplan für Baseline erstellen Testworkbench
Ressourcen zuordnen
Pläne für Baseline-Konfiguration abstimmen
Projekt-IMG detaillieren
Globale Einstellungen und Unternehmensstruktur konfigurieren
Globale Einstellungen einrichten
Organisationsstruktur einrichten
Vordefinierte Einstellungen einbeziehen CATT
374
Sandini Bib
Baseline konfigurieren und prüfen

Prozesse/Funktionen konfigurieren
Objekte in QS-Umgebung transportieren
Baseline testen CATT
Unstimmigkeiten dokumentieren und beheben
Business Blueprint detaillieren
Vollständigkeit der Detailkonfiguration sicherstellen
Baseline-Abnahme vorbereiten
Baseline-Szenarios vorbereiten
Agenda für Baseline-Abnahme zusammenstellen
Sitzung zur Baseline-Abnahme vorbereiten
Baseline-Abnahme durchführen
Baseline-Szenarios durchgehen
Baseline prüfen und abnehmen CATT
Systemverwaltung
Systemtestpläne erarbeiten CATT
Testplan für Systemausfallszenarien erarbeiten
Durchsatztestplan erarbeiten
Stresstestplan erarbeiten
Testplan zur Systemadministration erarbeiten
Druck- und Faxtestplan erarbeiten
Service-Level-Abkommen definieren
Systemausfallszenarien festlegen
Disaster-Recovery-Verfahren definieren
Service-Level-Abkommen einrichten
Systemadministrationsfunktionen einrichten
Verfahren für Mandantenkopie überprüfen
Anhang B
Tägliche Prüfvorgänge überprüfen

Transportverfahren überprüfen
Backup- und Recovery-Verfahren überprüfen
375
Sandini Bib
Qualitätssicherungsumgebung einrichten
Hardware für QS-System installieren
Technische Systemumgebung überprüfen
Qualitätssicherungssystem installieren
Benutzerstammsätze für Qualitätssicherung einrichten CATT
Qualitätssicherungssystem sichern
Druckdienste einrichten
Mandantenverwaltung und Transportsystem einrichten
Produktivsystemdesign festlegen
Schätzungen für Arbeitslast und Speicherplatz überprüfen
Festplattenlayout für das Produktivsystem entwerfen
Systemmanagement für das Produktivsystem definieren
Sicherheitskonzept des Produktivsystems festlegen
Produktive Betriebsabläufe definieren
Systemadministration für das Produktivsystem definieren
Druckumgebung für das Produktivsystem definieren
Administrationsabläufe für die Produktivdatenbank definieren
R/3-System-Bedienerhandbuch erstellen
Produktivumgebung aufbauen
Hardware für Produktivsystem installieren
Technische Umgebung des Produktivsystems überprüfen
Produktivsystem installieren
Netzwerkumgebung installieren und konfigurieren
Desktop-Hardware und -Komponenten installieren
Betriebssystem und Datenbank sichern
Drucker installieren und Druckfunktionen konfigurieren
Detail-Konfiguration und -Abnahme

Planung für Detail-Konfiguration erarbeiten
Detailumfang verfeinern
Konfigurationsplan für Detailumfang erstellen
376
Sandini Bib

Testplan für Detailumfang erstellen Testworkbench
Ressourcen zuordnen
Konfigurations-Workshops einplanen
Planung zur Detailkonfiguration abstimmen
Konfigurations-Workshops durchführen (Zyklus 1-n)
Workshop durchführen (Zyklus 1-n)
Geschäftsprozessentscheidungen dokumentieren (Zyklus 1-n)
Issues dokumentieren und klären (Zyklus 1-n)
Detailumfang konfigurieren und prüfen (Zyklus n-1)
Prozesse/Funktionen konfigurieren (Zyklus 1-n)
Objekte in QS-Umgebung transportieren(Zyklus 1-n)
Detailkonfiguration testen (Zyklus 1-n) CATT
Vollständigkeit der Detailkonfiguration sicherstellen
Detailabnahme vorbereiten
Detailabnahme-Szenarien vorbereiten
Agenda für Detailabnahme zusammenstellen
Sitzung zur Detailabnahme vorbereiten
Detailabnahme durchführen
Detailabnahme-Szenarien durchgehen CATT
Detailumfang prüfen und abnehmen CATT
Datenübernahmeprogramme entwickeln
Datenübernahmeverfahren ausarbeiten
Detaillierte Definition der Datenübernahme erstellen
Datenübernahmeprogramme erstellen CATT
Manuelle Datenübernahmevorgänge durchführen
Datenübernahmeprogramme testen und transportieren
Anhang B
Testverfahren für Datenübernahme definieren CATT

Datenübernahmeprogramme testen und prüfen CATT
377
Sandini Bib
Testergebnisse der Datenübernahme CATT

Programme in QS-System transportieren
Schnittstellenprogramme für Anwendungen entwickeln

Schnittstellenprogramme erstellen
Detaillierte Definition der Schnittstellen ausarbeiten
Dialogschnittstellendiagramme entwickeln
Hintergrundschnittstellen entwickeln
Schnittstellenprogramme testen und transportieren
Testverfahren für Schnittstellen definieren
Schnittstellenprogramme testen und prüfen CATT
Ergebnisse der Schnittstellentests abstimmen CATT
Schnittstellenprogramme in QS-System transportieren
Erweiterungen entwickeln
Erweiterungsprogramme erarbeiten
Detailierte Definition der Erweiterung ausarbeiten
Genehmigung prüfen
Erweiterungen erstellen
Erweiterungsprogramme testen und transportieren
Testverfahren für Erweiterungen definieren CATT
Erweiterungsprogramme testen und prüfen CATT
Ergebnisse der Erweiterungstests abstimmen
Erweiterungen in QS-System transportieren
Reports entwickeln
Reports erarbeiten
Detaillierte Definition der Reports ausarbeiten
Genehmigung prüfen
Reports erstellen
378
Sandini Bib
Reports testen und transportieren

Testverfahren für Reports definieren
Reports testen und prüfen
Ergebnisse der Reporttests abstimmen
Reports in QS-System transportieren
Formulare entwickeln
Formulare erarbeiten
Formulare entwickeln
Genehmigung prüfen
Formulare erstellen
Formulare testen
Testverfahren für Formulare definieren
Formulare testen und nochmals prüfen
Ergebnisse der Formulartests abnehmen
Formulare in QS-System transportieren
Berechtigungskonzept erarbeiten
Detaillierte Definition des Berechtigungskonzeptes ausarbeiten
Berechtigungsstrategie des Unternehmens detaillieren
Wichtige Transaktionen für Berechtigungen dokumentieren
Autorisierungsgespräch mit Bereichsverantwortlichen durchführen
Allgemeinen Zugang zu Informationen bestimmen
Verfahren zur Berechtigungsverwaltung beschreiben
Berechtigungskonzept implementieren
Aktivitätsgruppen erstellen
Berechtigungsprofile anlegen CATT
Modelle für Benutzerstammsätze entwickeln
Anhang B
Modell für Benutzerstammsätze testen CATT

Systemberechtigungen erteilen
Profile für einzelne Benutzer bestimmen
379
Sandini Bib
Alle Benutzerstammsätze anlegen CATT

Benutzerstammsätze mit R/3-Transaktionen prüfen CATT
Berechtigungskonzept detaillieren
Berechtigungskonzept abnehmen
Archivierung einrichten
Archivierungsverfahren erarbeiten
Archivierungsstrategie festlegen
Archivierungsverfahren erstellen
Archivierungsvorgänge testen
Archivierungsverfahren prüfen und abstimmen
Abschließender Integrationstest
Planung des Integrationstests erarbeiten Testworkbench
Umfang des Integrationstests festlegen Testworkbench
Plan für Integrationstest erstellen Testworkbench
Planung des Integrationstests erarbeiten
Transport aller Objekte im Qualitätssicherungssystem (QS) sicherstellen
System sperren
Abschließenden Integrationstest durchführen CATT
Systemeinrichtung abschließen
Integrationstest prüfen und abstimmen
Dokumentation und Schulungsunterlagen für Benutzer

Entwicklungsplan für Benutzerdokumentation erarbeiten
Dokumentationsanforderungen der Benutzer bestimmen
Entwicklungsplan für Benutzerdokumentation erarbeiten
Entwicklungsplan für Benutzerdokumentation abstimmen
Benutzerdokumentation erarbeiten
Workshop zur Benutzerdokumentation und -schulung durchführen
Benutzerdokumentation erstellen
380
Sandini Bib
Schulungsunterlagen für Benutzer erarbeiten

Schulungsunterlagen für Benutzer zusammenstellen
Schulungsleitfaden für Referenten erstellen
Benutzerschulung vorbereiten
Räume, Ausrüstung und Logistik für Schulung organisieren
Teilnehmerlisten bestätigen
Qualitätsprüfung Realisierung
Realisierung abnehmen
B.1.4 Phase 4: Produktionsvorbereitung
Projektmanagement Produktionsvorbereitungsphase
Projektstatus-Meeting
Projektabweichungen korrigieren
Lenkungsausschuss
Change-Management
Teambildende Aktivität durchführen
Anhang B
381
Sandini Bib
Benutzerschulung
Benutzerschulung vorbereiten
Logistik für Schulung fertigstellen
Umgebung für Benutzerschulung einrichten CATT
Schulungsdaten in Trainingsumgebung transportieren
Benutzerschulungen durchführen
Benutzerschulung durchführen CATT
Benutzerschulung prüfen
Systemmanagement
Administration des Produktivsystems einrichten
CCMS für Produktivumgebung konfigurieren
Druck- und Spooladministration für das Produktivsystem konfigurieren
Personal für Systemadministration schulen
Systemtests durchführen CATT
Durchsatztest durchführen
Stresstest durchführen
Systemadministrationstests durchführen
Disaster-Recovery-Test durchführen
Backup- und Restore-Verfahren testen
Druck- und Faxtests durchführen
GoingLive (Check)
Detaillierte Planung Cutover und Support

Planung für Cutover detailliert ausarbeiten
Ablauf der Datenübernahme prüfen
Checkliste zur Datenübernahme erstellen
Produktionsbereitschaft feststellen
Cutover-Planung abstimmen
382
Sandini Bib
Planung für Produktionssupport detailliert ausarbeiten

Help-Desk-Vorgänge bestimmen
Help-Desk einrichten
Team für Produktionssupport benennen
Help-Desk-Personal benennen
Langfristige Support-Strategie festlegen
Cutover
Cutover in Produktivsystem durchführen
Transport in die Produktionsumgebung
Datenübernahme vornehmen CATT
Daten manuell eingeben
Endabnahme für den Produktionsanlauf
Produktivsystem abnehmen
Produktivsystem sichern
Bereitschaft der Benutzer sicherstellen
Qualitätsprüfung Produktionsvorbereitung
Qualitätsprüfung durchführen CATT
Produktionsvorbereitungsphase abnehmen
B.1.5 Phase 5: Go-Live und Support
Produktionssupport
Produktionssupport bereitstellen
Probleme und Issues kommunizieren
Issues klären und Probleme lösen
Ergebnisse der produktiven Geschäftsprozesse prüfen
Anhang B
Tägliche und wöchentliche Transaktionen überwachen

Issues klären
Live-Umgebung bestätigen
383
Sandini Bib
Systemnutzung optimieren
EarlyWatch-Sitzungen durchführen
Technische Umgebung optimieren
R/3-Transaktionen optimieren CATT
Aktivitäten nach dem Go-Live

Follow-up-Schulung
Schulung für Fortgeschrittene durchführen CATT
Neue Mitarbeiter schulen CATT
Langfristige Pläne definieren
Technischen Upgrade-Plan detaillieren
Pläne für weitere Prozessanforderungen detailliert ausarbeiten
Langfristige Supportstrategie umsetzen
Upgrade der produktiven Systemlandschaft
System-Upgrade durchführen CATT
Datenbank-Upgrade durchführen
Release-Customizing durchführen CATT
Benutzerakzeptanz prüfen
Fortlaufende Systemvorgänge durchführen
Tägliche Vorgänge des Rechenzentrums durchführen
Tägliche Vorgänge der Datenbankadministration durchführen
Systemadministration verfeinern
Projekt-Review
Offene Fragen prüfen und klären
Geschäfts- und Projektziele überprüfen
Liste der offenen Fragen abnehmen und schließen
384
Sandini Bib
Anhang C
C
C.1 Kernprozesse im IDES-Schulungssystem
Unter den so genannten »Kernprozessen« im IDES-Schulungssystem sind die
Beispiele aufgeführt, die eine hohe Integration der Geschäftsabläufe im R/3-Sy-
stem abbilden und wichtige Geschäftsprozesse in IDES darstellen. Jeder dieser
Kernprozesse, der mit CATT abgearbeitet werden kann, ist mit dem Zusatz
»CATT« gekennzeichnet.
C.1.1 Logistik
Einzelfertigung
Kundeneinzelfertigung mit konfigurierbarem Produkt CATT
Auftragserfassung im Internet für konfigurierbare Produkte CATT
Geschäftsprozesse in der Automobilindustrie CATT
Losfertigung
Kundenauftragsanonyme Vorplanung CATT
Vorplanung mit Endmontage CATT
Vorplanung auf Baugruppe CATT
Langfristplanung
385
Sandini Bib
C.1 Kernprozesse im IDES-Schulungssystem
Serienfertigung
Planungsintegration Vertrieb/Produktion
Serienfertigung Glühlampen CATT
Serienfertigung Personal Computer CATT
Auftragserfassung im Internet über einen Produktkatalog CATT
Verkauf eines serialisierten Produktes und Anlegen eines Equipment-
Stammsatzes
Serviceabwicklung und aufwandsbezogene Fakturierung ohne
Servicevertrag
Allgemein
Buchungskreisübergreifende Transportaufträge mit MM und SD
Kreditkontrolle CATT
Einzelkapazitätsplanung auf Personenebene
Rechnungswesen
Anzahlungsabwicklung/Kreditor
Auftragserstellung und Nachweis aller Belege im Rechnungswesen
Personalwirtschaft
Einstellung eines neuen Mitarbeiters
386
Sandini Bib
Anhang D
D
D.1 Übersicht der standardmäßig verfügbaren
Testabläufe
Die folgende Tabelle gibt eine Übersicht über die Testabläufe, die standardmä-
ßig mit dem SAP R/3-System ausgeliefert werden. Die Tabelle ist nach der
Kurzbeschreibung des Testablaufes sortiert. Auf eine Übersicht zu den Testbau-
steinen wurde verzichtet, da standardmäßig über 3000 Bausteine mitausgelie-
fert werden.
Kurzbeschreibung des Testablaufs Testablauf-Nr.
2 WWI-Server auf einem PC P3007614
Abgrenzungsschlüssel K1105410
Ablauf Debitorischer Wechsel Deutschland P40WECHSEL/DEBID
Ablauf Debitorischer Wechsel Frankreich P40WECHSEL/DEBIF
Ablauf kreditorischer Wechsel P40_WECHSEL/KRED
ABSCHLUSS K1102674
Abwicklung KDE-KDN MIX K1105405
Abwicklung kundenauftragsbezogene Bestellung K1105403
Abwicklung kundenauftragsbezogene Fertigung K1105402
AC510 Vorbereitung P3005591
afds B2000600
387
Sandini Bib
D.1 Die standardmäßig verfügbaren Testabläufe
AiB mit Investitionsförderung (aktiv/passiv) P3011716
AIBU Abrechnung Anlage im Bau K1102429
Allgemeine Hinweise B2000807
ALte und neue Parameter REF, FUN B2000725
Anbindung an andere Tools B2000803
Änderbare Mengeneinheiten K1105030
Ändern externer Beleg Senderseite K1103102
Anlegen einer Menüleiste B2000808
Anlegen und Ändern von Deckblattvorlagen P3007620
Anlegen und Ändern von Stoffberichtsvorlagen P3007618
Anlegen Varianten-Stüli in N-Strukturtiefen S1100567
Anlegen Varianten-Stüli mit variabler Anz. L S1100547
Anlegen von Status B2000753
Anpassungsbuchungen K1102449
Anschluss Ergebnisobjekt K1105554
Anzahlungssequenz buchen (Debitor) K1101437
Anzeigen von Deckblattvorlagen P3007619
Anzeigen von Stoffberichtsvorlagen P3007616
Anzeigen von Stoffberichtsvorlagen P3007617
Arbeitsplatz anlegen P3001729
Arbeitsplatz anlegen mit Vorlage P3001730
Arbeitsplatz anlegen mit Vorlage P3001747
Arbeitsplatz anzeigen P3001818
Arbeitsplatzart definieren P3001716
ArchiveLink Testdatengenerierung (Ablauf) B2000471
ArchiveLink Testdatengenerierung (Ablauf) B3000007
Attribute für Typ C (Testablauf) ALRSCAT_ATTR07
388
Sandini Bib
Attribute für Typ C (Testablauf) ALRSCAT_ATTR10
Attribute für Typ C (Testbaustein) ALRSCAT_ATTR08
Attribute für Typ M ALRSCAT_ATTR09
Aufruf 602 B2000607
Ausfall eines WWI-Servers (Deaktivierung) P3007627
Ausfall eines WWI-Servers (Verbindungsunterbrechung) P3007628
Ausführen von VERI-Reports B3000016
Ausgangsrechnung ändern (Debi an GuV) K1100526
Ausgangsrechnung buchen (Debi an GuV) K1100583
Ausgleichen Sachkonto mit OP K1100580
Auslieferung Customizing FI K1103083
Austausch von Stoffberichtsvorlagen zwischen P3007632
autom. Anforderung bei fehlendem Rohbericht P3007630
Basic-Set anlegen und löschen K1102785
Basic-Set anlegen unter Verwendung... K1102786
Batch-Input K1105042
Batchkalkulation ! K1105001
Bauteilauflösung K1105027
Beleg buchen (Bil an Bil) K1100555
Beleg buchen (Bil an BilOp) K1100541
Beleg buchen (Bil an GuV) Salden prüfen K1100562
Beleg buchen (Steuer und Skonto) Salden prüfen K1100558
Beleg Buchen Stammdaten anlegen KKK00227
Beleg stornieren K1103075

Anhang D
Beleg stornieren – Salden prüfen K1103077
Beleg vorerfassen K1102842
Belegfolge – Export-Faktura im SD S1106601
389
Sandini Bib
Benutzer- und Berecht.pflege prüfen BIN00013
Bericht mit Datenseteinträgen u. Formelvar. K1102756
Bericht mit Kennzahlen u. Zellen... K1102598
Bericht mit Kennzahlen und Zellen ausführen K1102596
Berichtsversand aus SD P3007621
Berichtswesen K1105002
Bezugsobjekt Auftrag / Projekte K1105033
Bezugsobjekt Bauteil K1105036
Bezugsobjekt CO-Fertigungsauftrag K1105034
Bezugsobjekt Kostenträger K1105032
Bezugsobjekt Kundenauftrag K1105031
Brazilian movement types (T156B) P40MM_05
Brazilian movement types (T156B) – Update P40MM_051
Brazilian movement types (T156S) P40MM_06
Brazilian movement types (T156W) P40MM_07
Brazilian movement types (T158B) P40MM_08
Brazilian movement types (T158B) – (SETTAB) P40MM_081
Brazilian movement types MM-IM (J_1BIM01) P40MM_04
Brazilian movement types MM-IM (T156) P40MM_00
Brazilian movement types MM-IM (T156N) P40MM_03
Brazilian movement types MM-IM (T156T) P40MM_01
Brazilian movement types MM-IM (T157H) P40MM_02
Buchen FI-CA-Belege Haben-Positionen KKK00011
Buchen FI-CA-Belege Soll-Positionen KKK00013
Buchung ändern KKK00249
Buchungskreisübergreifende Eingangsrechnung K1101645
Buchungssummen prüfen KKK00242
390
Sandini Bib
Budgetierung in Investitionsprogrammen P3005427
CAD OD55-OD65 Customizing Transakt. nur aufrufen S1100784
CATT – Archiv anzeigen ALRSCAT_PROT__07
CATT – Archiv erzeugen ALRSCAT_PROT__06
CATT – Externe Anwendungen ALRSCAT_EXA01
CATT – Kurz- und Langprotokoll ALRSCAT_PROT__02
CATT – Protokoll anzeigen ALRSCAT_PROT__01
CATT – Protokollanz. eines remote... ALRSCAT_PROT__09
CATT – Protokollanz. eines über CATT gest. ALRSCAT_PROT__10
CATT – Protokollanzeige mit Dump ALRSCAT_PROT__11
CATT – Protokollanzeige mit Dump ALRSCAT_X_PROT11
CATT – Protokollarchiv und Prüfkennzeichen ALRSCAT_PROT__05
CATT – Protokollattribute ALRSCAT_PROT__03
CATT – Protokolleinstellungen ALRSCAT_PROT__04
CATT – Restart eines Vorgangs, Ablaufs o. Bausteins ALRSCAT_PROT__08
CATT – Veri Test ALRSCAT_X_PROT10
CATT Bausteine Kopieren ALRSCAT_KOP01
CATT Datumsparameter ALRSCAT_DAT01
CATT Externe Varianten bearbeiten ALRSCAT_EXV01
CATT für die Erzeugung von Arbeitsplänen P3004783
CATT Parameterpflege bei REF ALRSCAT_PAR01
CATT TCD aus Aufzeichnung generieren ALRSCAT_REC02
CATT TCD Dynpronamen in Variablen ALRSCAT_TCD01
CATT Testbaustein aufzeichnen ALRSCAT_REC01

Anhang D
CATT Variantenpflege (interne Varianten) ALRSCAT_VNT01
CHETAB auf KUNA B2000287
CHETAB auf NON-ATAB-Tabellen B2000290
391
Sandini Bib
CJ88 – Spezialabrechnung Projekt... P3007805
CO Controlling: Statistische Kennzahlen Ist K1102593
CO-Auftrag zum Kundenauftrag (Reparatur, Montage) K1105404
Copy control: Deliv. Note to Billing – Copy P40SD_132
Copy control: Sales to Billing – Update Item P40SD_082
Copy control: Sales to Delivery Item P40SD_031
Cursor in Listen B2000130
Customizing Arbeitsplätze P3001714
Customizing der Erzeugniskalkulation K1105020
Customizing Einzelkalkulation K1105035
Customizing IS-IS/PP KI300166
Daten-Set anlegen und löschen K1102789
Debitorenbuchhaltung K1102680
Debitorenkonto löschen K1103081
Debitorenkonto zum Buchen sperren K1101121
Debitorenstammsatz ändern K1100487
Def. Inv.projekt und Hierarchie Stufe 1 anlegen P3005281
Delta 2.2 - 3.0: Demotest B2000462
Details Pflege TCD Dynpro Fullscreen ALRSCAT_TCDDYNF
Details Pflege TCD Dynpros ALRSCAT_TCD_DYN1
Dispositionsgruppen K1105409
Document pricing procedure - Assign billing P40SD_142
Druck Erhebungsbogen K1102447
Drucktastenbelegung anlegen TF_DWB_MP_ADDB
Durchbuchung von CO-Primärkosten ins GLX K1102592
DURCHBUCHUNGEN K1102678
DVS CV01 Anlegen Dokumentinfosatz S1100124
392
Sandini Bib
DVS CV01 Anlegen Dokumentinfosatz mit Langtexten S1100220
DVS CV02 Ändern Dokumentinfosatz – Sachbearbeiter S1100144
DVS CV03 Anzeigen Dokumentinfosatz S1100152
Dynamische Menütexte B2000823
EH&S: Anlegen und Ändern von Stoffberichtsvorlagen P3007612
EH&S: Anzeigen von Stoffberichtsvorlagen P3007613
Einfache Belegstornierung KKK00258
Einfache Fakturaübernahme KKK00237
Einfaches Mahnen KKK00228
Einfaches Mahnen Stammdaten anlegen KKK00231
Eingangsrechnung (Kred an GuV) K1100530
Eingangsrechnung (Kred an GuV) Salden prüfen K1100547
Eingangsrechnung (KredNetto an GuV) Salden prüfen K1100554
Eingangsrechnung ändern (Kred an GuV) K1102120
Einstellung FI für Auslieferung – Nachspann K1102800
Einstellung FI für Auslieferung – Vorspann K1102799
Erfassung externer Belege K1103101
Ermitteln und Setzen des Nummernstandes K1102898
Erweiterte Normenprüfung B2000741
Externe Anwendung 1.Versuch B2000601
F-02 Sachkontenbuchung P3006605
Fakturaart Änderungen P40SD_11
Fakturierung: Belegarten P40SD_07
Fehlerhandling K1105041
Anhang D
Fertigungsauftragskalkulation K1105013
FI Statistische Buchung erfassen/Vorgang RFBU K1102591
FI-Beleg ins GLX buchen/Vorgang RFBU K1102589
393
Sandini Bib
FI-GLX Lokalen Beleg erfassen (Benutzertabel) K1102566
FI-GLX Lokalen Beleg erfassen (Buchungsdatum) K1102559
FI-GLX Lokalen Beleg erfassen (Fehler...) K1102563
FI-GLX Lokalen Beleg erfassen (Umrechnungsdaten) K1102568
FI-GLX Lokalen Planbeleg erfassen K1102572
Finanzdokument allgemeiner Test E3000004
Fix/Variabel – Splittung K1105029
Flexible Fehlersteuerung K1104998
Formeln, Parameter und Vorgabewertschlüssel P3001842
Freigabe von Rohberichten P3007633
Freigabe von Stoffberichtsvorlagen P3007615
Fremdwährung buchen, Salden prüfen K1101090
Fremdwährungsbewertung buchen, Salden prüfen K1101429
Frontendtest ArchiveLink B2000457
Frontendtest ArchiveLink B3000009
Funktion CHEERR * (1) CHEERR falsch ALRSCAT_X_MSG03
Funktion CHEERR * (2) CHEERR * ALRSCAT_X_MSG04
Funktion FUN, Aufruf Funktionsbaustein B2000289
Funktionen anlegen TF_DWB_MP_ADDF
Funktionstastenbelegung anlegen TF_DWB_MP_ADDP
GC21 – Bilanz erfassen K1102441
GC21 – Erfassen Anlagen K1102444
GC21 – Erfassen Beteiligungen K1102446
GC21 – Erfassen Partner K1102445
GC21 – GuV erfassen K1102442
Gesamtablauf z. Anlage von Varianten v. Stammdaten KKK00043
Geschäftspartner: Straße ändern KKK00175
394
Sandini Bib
GESCHÄFTSVERKEHR K1102673
GESCHÄFTSVORFÄLLE K1102672
Geschätspartner anlegen KI300162
GLX-Ist-Umlage mit festen Prozentsätzen... K1102526
Grunddaten (1) P3001732
Grunddaten (2) P3001748
Hierarchie Inv.projekt ab Stufe 2 anlegen P3005301
Hinzufuegen Revisionsstand S1100791
ICT Einstellungen Senderseite K1103088
IM: Auftrag anlegen/bebuchen für Massentest P3005373
IM: Direct IM process 2 w/o MM P3007424
IM: Direct IM process 3 with MM P3007550
IM: Simple investment measure process 1 P3007414
In gesperrte Periode buchen K1101442
Includemenüs B2000824
Instandhaltungskalkulation K1105018
Integration mit Workflow-Def.-Editor K1105711
Integration und Schnittstellen mit Workitem- K1105708
Integrative Anzahlungssequenz buchen (FI + SD) K1103199
Interne Formelvariable anlegen und löschen K1102793
Interne Funktionen K1105709
Internet-Test B2000764
Inv.auftrag anl.p IP, Plan, Budget, Ist P3008751
Investitionsmaßn. Projekt anlegen und abrechnen P3000531

Anhang D
InvMaßn. (Auftrag) anlegen & abrechnen P3000272
InvMaßn. (Auftrag) anlegen, Anzahlung... P3008682
Invst.auftr.anl./Plan/Budget/IP/Equi/IH/Rück P3006522
395
Sandini Bib
Invst.auftr.anl./Plan/Budget/IP/Equi/IH/Rück P3008854
Invst.auftr.anlegen+Plan.u.Budget.+an IP... P3005326
Ist-Umlage mit festen Anteilen ausführen K1102527
Ist-Verteilung mit festen Beträgen ausführen K1102540
Ist-Verteilung mit festen Prozentsätzen ausführen K1102541
IW31 Instandhaltungauftrag P3006644
Kalkulation eines Serienmaterials K1105007
Kalkulation mit Isttarifen K1105009
Kalkulationsschema: Transaktion P40SD_14
Katalog als lokales Objekt anlegen ALRSTW1_TKAN01
KLA CL01 Klasse mit Merkmal anlegen K1102242
KLA CL04 Klasse mit Merkmal löschen K1102245
KLA CL24 Klasse zu Klasse Zuordnung K1102246
KLA CT01 Merkmale anlegen K1102235
KLA CT02 Merkmale löschen K1102236
Konfigurierbare Materialien... K1104997
KONS-RF410 K1102376
Kontenverwaltung P3013894
Kontenverwaltung P3013896
Kontrollsummen K1101431
Kopfdaten P3001780
Kopieren einer Wirtschaftseinheit COPY_WE
Kopieren einer Wirtschaftseinheit WE_COPY
Kopieren von Menüleisten B2000809
Kopieren von Status B2000766
Kopierst.: Fakturierung in Verkauf – Kopf... P40SD_09
Kopiersteuerung: Verkauf an Fakturierung... P40SD_08
396
Sandini Bib
Kopiersteuerung: Verkauf in Lieferung – Kopf... P40SD_03
Kopierstg.: Lieferschein pFaktur... P40SD_13
Kostenstellenzuordnung P3001764
Kreditkontrollbereich: HZ Daten zum Debitor K1101652
Kreditkontrollbereich: Prüfen Feld Forderung K1101653
Kreditkontrollbereich: Prüfen Feld Sonder... K1101654
Kreditkontrollbereich: Überschreiten Kreditlimit K1101655
Kreditkontrollbereich: Währungsumrechnungen K1101671
Kreditorenbuchhaltung K1102681
Kreditorenkonto löschen K1103082
Kreditorenkonto zum Buchen sperren K1102122
Kreditorenstammsatz ändern K1101005
Kundenauftrag mit KDE-KDN - Mix K1105412
Kundenauftrag mit mehreren KDE-Positionen... K1105411
Kundenauftrag mit Projekten (Anlagenbauer) K1105523
Kundenauftragsarten pflegen P40SD_06
Kuppelproduktion K1105010
Liste der Materialstamm-CATTs ALRMM01_LIST
Lokale FI-GLX-Planwerte erfassen K1102579
Lokale Planwerte erfassen (mit repräs. Wert) K1102580
Lokalen Standard-Rollup mit Regel anl. K1102586
Löschen Installation von FI-GLX-Tabellenverb. K1102876
Löschen von Menüleisten B2000812
Löschen von Status B2000775

Anhang D
Löschschutz für Formeloperanden K1102791
Löschschutz für verwendete Sets K1102790
Manuelle Anforderung mit Generierung sofort P3007623
397
Sandini Bib
Manuelle Anforderung mit Generierung im Hintergrund P3007624
Manuelle Buchung Ablaufrahmen KKK00197
Massentest Endberichte P3007622
Massentest Rohberichte P3007625
Materialselektion K1105332
ME21/MB01/MRHR Bestellung / Wareneingang / Rech- P3006213

nung (1)

nung (2)

nung (3)

nung (4)
Menü anlegen TF_DWB_MP_ADDM
Messagevariablen-Check ALRSCAT_X_MSG05
Messagevariablen-Check ALRSCAT_X_MSG06
Messagevariablen-Test ALRSCAT_X_MSG02
Messagevariablen-Test : B2000106 ALRSCAT_MSG02
Messagevariablen-Test: Stammdaten anlegen ALRSCAT_X_MSG01
MM02 Material ändern Fertigungsvers. ALRMM02_VERS
MM-SRV: Dienstleistungsabw. Grundablauf P3000439
Moduswechsel B2000763
Multi-Set anlegen und löschen K1102788
Navigation P3001817
Netzplankalkulation K1105017
NF-relevanter Positionstyp P40SD_02
Oberfläche anlegen TF_DWB_MP_ADDI
OC69 Kapital-Folgekonsolidierung K1102487
398
Sandini Bib
OC69 Kapitalkonsolidierung K1102486
OC89 Schuldenkonsolidierung K1102482
OC89 Umsatzeliminierung K1102483
OC94 Zwischenerfolgseliminierung alt K1102484
P-100 0 Vorbereitung P3005592
PA: Testpersonalnummern für die Archivierung P3010832
PA-E: Generate schift schedule P3002086
PA-E: Hire an spanish employee P3001787
PA-E: MOD/COP/DEL Infotype 62 (SI) P3001819
PA-E: N-Spanische Pernr anlegen P3001709
PA-E: Payroll spain: ILT+ATEP Colaboration P3003692
PA-E: Payroll Test spain P3001713
PA-E: Read Payroll Results P3001811
PA-E: Run Payroll for spain P3001810
PCA: PrCtr-Belege buchen (externe Varianten) ALRPC_ACTPA_V001
Personen P3001768
Pflege auf dem Parameterbild ALRSCAT_PARAM01
Pflege Funktion CHETAB ALRSCAT_CHETAB
Pflege Funktion DO/ENDDO ALRSCAT_DO
Pflege Funktion IF/ENDIF ALRSCAT_IF
Pflege Funktion SETVAR mit Tabelle ALRSCAT_SETVAR2
Pflege Funktion TXT ALRSCAT_TXT
Pflege SETVAR ALRSCAT_SETVAR
Phrasentexte in Originalsprache P3007652

Anhang D
Plankosten aus dem Netz P3000783
Planstellen P3001767
Plan-Umlage mit festen Anteilen ausführen K1102539
399
Sandini Bib
Plan-Umlage mit festen Prozentsätzen ausführen K1102528
Planung in Investitionsprogrammen P3005664
Plan-Verteilung mit festen Prozentsätzen ausführen K1102555
Plan-Verteilung mit variablen Anteilen ausführen K1102542
Plausibilitätsprüfungen K1102448
Positionstypen pflegen P40SD_04
Positionstypenzuordnung P40SD_05
PP: Arbeitsplatzhierarchie mit 3 Stufen anlegen P3000473
PP: CAP: Vorgabewertermittlung (new version) S1107136
PP-PI: Kapazitätsplanung - Grunddaten P3001861
PP-PI: Komplettdurchlauf P3001148
PP-SHE: Test EH&S completly... SHE00018
Proj. anl., budgetieren, Budget freigeben... P3001289
Projektabwicklung mit Netzen und Kundenaufträgen K1105522
Projektabwicklung mit zugeordneten PPS-Aufträgen K1105521
Projektabwicklung ohne Aufträge K1105519
Prozessfertigung K1105019
Prüfen Commandfiles Logistik-Grunddaten S1100841
Prüfen Funktion CHEVAR ALRSCAT_CHEVAR
Qualifikationen P3001769
R/2 Ändern Debitor-Stammsatz – Bankdaten B2000010
R/2 Ändern Debitor-Stammsatz – Bankdaten B2000363
R/2 Ändern Kreditor-Stammsatz – Anschriftsdaten B2000248
R/2 Ändern Kreditor-Stammsatz – Bankdaten B2000192
R/2 Anzahlungssequenz debitorisch B2000352
R/2 Anzahlungssequenz kreditorisch B2000195
R/2 Auftrag - Lieferschein - WA - Faktura P3005354
400
Sandini Bib
R/2 Ausz.o.Beleg (TB05): FW=0, Kleindiff.HW P3010551
R/2 Bebuchen Anlage B2000451
R/2 Belegvorerf.: E'rechnung Filiale... P3010681
R/2 Belegvorerf.: E'rechnung parken... P3008519
R/2 Belegvorerf.: Parken Eingangsrechnung P3006203
R/2 Buchen anteilige Zahlung (Debitor) B2000426
R/2 Buchen einer Ausgangsrechnung (TB01) B2000322
R/2 Buchen einer Ausgangsrechnung (TB09) B2000422
R/2 Buchen einer Eingangs-RE (Schnellbuchen) B2000307
R/2 Buchen einer Eingangs-RE B2000296
R/2 Buchen einer Eingangsrechnung (TB09) P3006516
R/2 Buchen einer Eingangsrechnung brutto B2000188
R/2 Buchen einer Eingangsrechnung brutto B2000454
R/2 Buchen einer Eingangsrechnung netto B2000267
R/2 Buchen/Zahlen Eingangsrechnung: Filiale/Zentrale P3010649
R/2 Create Purchase Order P3005489
R/2 JO10 Generierung Batchjob B2000145
R/2 Kontopflege kreditorisch B2000254
R/2 Kurzdurchlauf RM-MAT B2000300
R/2 PA31 Personendaten anzeigen B2000169
R/2 PU00 Löschen Personaldaten B2000168
R/2 PU00 und PA31 Pflegen Grunddaten Person B2000167
R/2 REPU B2000161
R/2 RFTB3200 Pflegen Wechsel-Obligo B2000399

Anhang D
R/2 RFWEIN00 Vorschlagsliste Wechsel verwenden B2000398
R/2 RFWEXT00 'WREG'-Ausgabe Wechseldaten B2000396
R/2 RFWFOF10 Druckreport Wechsel... B2000397
401
Sandini Bib
R/2 Sequenz: Wechsel aus Anforderung (Debitoren) B2000476
R/2 Storno Anzahlungsanforderung (Debitor) B2000359
R/2 Storno Anzahlungsanforderung (Kreditor) B2000360
R/2 TCD TB01, CHETAB BKPF, CHETAB BSEG B2000160
R/2 Teilzahlungssequenz (Debitor) B2000482
R/2 Test Steuerbuchen 1 B3000054
R/2 Test Steuerbuchen 2 P3005015
R/2 TM04 Übersicht der aktiven Benutzer B2000178
R/2 TM38 B2000157
R/2 TS03 und TE21 B3000037
R/2 TS05 Verändern Sachkonto B2000152
R/2 TS08 Verändern Debitor (VCODE 02) B2000364
R/2 TX10 und TS13 B3000040
R/2 TX10 und TS13 - Prüfen LIFA- und LIFB B3000032
R/2 TX10 und TS13, Prüfen LIFA- und LIFB B3000041
R/2 TX11 und TS08, Prüfen KUNA- und KUNB... B3000035
R/2 Wechselsequenz (Debitor) B2000395
R/2 Wechselsequenz (Debitor) B2000428
R/2 Wechselverwendung: Diskontierung B2000393
R/2 Wechselzahlung (Debitor) B2000392
Referenzangebot P3001781
Release: 22E bis 31G Typ: M ALRSCAT_ATTR06
Release: 31G bis 40D Typ: R ALRSCAT_ATTR05
Release: 40A bis 40B Typ: C ALRSCAT_ATTR04
Release: 40A bis 40D Typ: M ALRSCAT_ATTR02
Release: 40A bis 41D Typ: X ALRSCAT_ATTR03
Remote Start 01 ALRSCAT_REMOTE01
402
Sandini Bib
Remote Starten von CATTs ALRSCAT_X_REMO02
Remote Starten von CATTs ALRSCAT_X_REMO03
Reporting im Finanzwesen K1103215
Rohberichtsfreigabe P3007631
Rücknahme Ausgleich K1103180
Sachkontenbuchhaltung K1102679
Sachkonto anlegen und ändern K1100531
Sales document types, document pricing procedure P40SD_141
SAPconnect: Beispiel-Testablauf B3000081
SAPconnect: Empfangen von Read Notifications B3000082
Schichtprogramm definieren P3001728
SD-Beleg: UnvollständigKontr-Objektarten. P40SD_12
Selektion über Attribut 'Release von bis' ALRSCAT_ATTR01
Selektives Neubewerten K1105028
Servicemanagement: Ablauf P3004530
Single-Set anlegen und löschen K1102787
SO01 Büro pEingangskorb P3006130
Sonderbeschaffungsschlüssel K1104993
STAMMDATEN K1102671
Stammdaten K1104989
Stammdaten/Kostenträgerrechnung K1104357
Anhang D
Steuer KN E1 (manuell) Basis brutto/brutto K1102695
Steuer KN E1 (manuell) Basis netto/brutto K1102708
Steuer KN E1 (manuell) Basis netto/netto K1102763
403
Sandini Bib
Steuer KN E1 (rechnen brutto) Basis brutto/brutto K1102696
Steuer KN E1 (rechnen brutto) Basis netto/brutto K1102709
Steuer KN E1 (rechnen brutto) Basis netto/netto K1102764
Steuer KN E1 (rechnen netto) Basis brutto/brutto K1102733
Steuer KN E1 (rechnen netto) Basis netto/brutto K1102739
Steuer KN E1 (rechnen netto) Basis netto/netto K1102765
Steuer KN N1 (manuell) Basis brutto/brutto K1102693
Steuer KN N1 (manuell) Basis netto/brutto K1102706
Steuer KN N1 (manuell) Basis netto/netto K1102760
Steuer KN N1 (rechnen brutto) Basis brutto/brutto K1102694
Steuer KN N1 (rechnen brutto) Basis netto/brutto K1102707
Steuer KN N1 (rechnen brutto) Basis netto/neetto K1102761
Steuer KN N1 (rechnen netto) Basis brutto/brutto K1102732
Steuer KN N1 (rechnen netto) Basis netto/brutto K1102738
Steuer KN N1 (rechnen netto) Basis netto/netto K1102762
Steuer KN V1 (manuell) Basis brutto/brutto K1102691
Steuer KN V1 (manuell) Basis netto/brutto K1102704
Steuer KN V1 (manuell) Basis netto/netto K1102757
Steuer KN V1 (rechnen brutto) Basis brutto/brutto K1102692
Steuer KN V1 (rechnen brutto) Basis netto/brutto K1102705
Steuer KN V1 (rechnen brutto) Basis netto/netto K1102758
Steuer KN V1 (rechnen netto) Basis brutto/brutto K1102731
Steuer KN V1 (rechnen netto) Basis netto/brutto K1102737
Steuer KN V1 (rechnen netto) Basis netto/netto K1102759
Steuer KR E1 (manuell) Basis brutto/brutto K1102701
Steuer KR E1 (manuell) Basis netto/brutto K1102714
Steuer KR E1 (manuell) Basis netto/netto K1102772
404
Sandini Bib
Steuer KR E1 (rechnen brutto) Basis brutto/brutto K1102702
Steuer KR E1 (rechnen brutto) Basis netto/brutto K1102715
Steuer KR E1 (rechnen brutto) Basis netto/netto K1102773
Steuer KR E1 (rechnen netto) Basis brutto/brutto K1102736
Steuer KR E1 (rechnen netto) Basis netto/brutto K1102742
Steuer KR E1 (rechnen netto) Basis netto/netto K1102774
Steuer KR N1 (manuell) Basis brutto/brutto K1102699
Steuer KR N1 (manuell) Basis netto/brutto K1102712
Steuer KR N1 (manuell) Basis netto/netto K1102769
Steuer KR N1 (rechnen brutto) Basis brutto/brutto K1102700
Steuer KR N1 (rechnen brutto) Basis netto/brutto K1102713
Steuer KR N1 (rechnen brutto) Basis netto/netto K1102770
Steuer KR N1 (rechnen netto) Basis brutto/brutto K1102735
Steuer KR N1 (rechnen netto) Basis netto/brutto K1102741
Steuer KR N1 (rechnen netto) Basis netto/netto K1102771
Steuer KR V1 (manuell) Basis brutto/brutto K1102697
Steuer KR V1 (manuell) Basis netto/brutto K1102710
Steuer KR V1 (manuell) Basis netto/netto K1102766
Steuer KR V1 (rechnen brutto) Basis brutto/brutto K1102698
Steuer KR V1 (rechnen brutto) Basis netto/brutto K1102711
Steuer KR V1 (rechnen brutto) Basis netto/netto K1102767
Steuer KR V1 (rechnen netto) Basis brutto/brutto K1102734
Steuer KR V1 (rechnen netto) Basis netto/brutto K1102740
Steuer KR V1 (rechnen netto) Basis netto/netto K1102768

Anhang D
STEUERN K1102676
Steuer-Testpernr 2602 Dieter Einaus K1102167
Steuer-Testpernr 2610 Bruno Briefträger K1102888
405
Sandini Bib
Steuer-Testpernr 2611 Hertha Gering-Pauschal K1102191
STL CS01 1-Stufen Rekursivität S1100076
STL CS01 Anlegen N-Alternativen S1100092
STL CS01 Anlegen Stückliste – mehrere Verwendungen S1100088
STL CS01 Anlegen Stückliste Gesamtdaten S1100064
STL CS01 Anlegen Stückliste gesperrtes Material S1100085
STL CS01 Anlegen Stückliste in Vergangenheits... S1100084
STL CS01 Anlegen Stückliste mit Referenz S1100099
STL CS01 Anlegen Stückliste mit Rohmaßposition S1100087
STL CS01 Anlegen Stückliste mit ungült. Material... S1100080
STL CS01 Anlegen Stücklisten - falsche Basismengen- S1100068

einheit
STL CS01 Nicht existente Dokumentnummer prüfen S1100097
STL CS01 N-Stufen Rekursivität S1100052
STL CS01 Preis-Schablone mit 700 Mio. DM prüfen S1100100
STL CS01 Stückliste mit 1 Dokumentenpos. Anlegen S1100095
STL CS01 Stückliste mit Nichtlagpos. o. Material... S1100098
STL CS01 Unterpositionsmengen prüfen S1100094
STL CS02 Ändern Stückliste mit Änderungsnummer S1100009
STL CS02 Löschen 3. numerische Alternative S1100093
STL CS02 Löschen Stückliste S1100082
STL Customizing OS27 Modif.param. Original S1100332
STL Customizing OS28 Vorschlagswerte ändern S1100330
Stücklisten-/Arbeitsplanselektion K1104999
Substitution (Prüfen und Ersetzen) K1105552
Summenbilanz / GuV K1102451
Syntaxcheck auf FI-Funktionsbausteine K1103238
406
Sandini Bib
Syntaxcheck auf FI-Modulpools K1103187
Syntaxcheck auf FI-Reports K1103192
Syntaxcheck Customizing DVS S1100783
Syntaxcheck Customizing Klassifizierung S1100785
Syntaxcheck Customizing Stücklisten S1100782
Syntaxcheck Customizing Varianten S1100786
Syntaxcheck Wissenseditor S1100792
Tabellarische Pflege der Anordnungsbeziehung P3002020
Terminierung P3001763
Testablauf - Autom. Nota-Fiscal-Kopftexte pflegen P40SD_101
Testablauf Kopierstg: Fakt... (2) P40SD_092
Testablauf Kopierstg: Fakt... (1) P40SD_091
Testablauf Kopierstg: LiefBlg -> Faktura P40SD_131
Testablauf KopStg: VerBelg nach Faktura P40SD_081
Testablauf Schemata den Positionstypen zuordnen P40SD_123
Testablauf Schemata den VerBlgarten zuordnen P40SD_122
Testablauf Unvollständig Stg für VerBlg erweitern P40SD_121
Testablauf Damrath P3004192
Testkatalog ändern Externe Anwendung einbinden ALRSTW1_TKAE03
Testkatalog ändern Manuellen Testfall anlegen ALRSTW1_TKAE01
Testkatalog ändern Automatischen Testfall anlegen ALRSTW1_TKAE02
Testkatalog in einer Entwicklungsklasse anlegen ALRSTW1_TKAN02
Testszenario: 1 GP, 2 VK je 10 Buch... (1) KKK00460
Testszenario: 1 GP, 2 VK je 10 Buch... (2) KKK00461

Anhang D
TEXT K1104988
Titel anlegen TF_DWB_MP_ADDT
TM31 B2000362
407
Sandini Bib
TM31, SETTAB, SETVAR, RESTAB, CHETAB B2000200
Translation Memory Übernahme: Abkürzungen... B2000490
Übernahmesteuerung K1104995
Übernahmestrategien K1105040
Überprüfen der Funktion CHEERR * ALRSCAT_MSG05
Überprüfen der Message-Variablen &MS... ohne... ALRSCAT_MSG01
Übersicht P3001778
Umbenennen von Status B2000776
Umbuchung FI-Einzelposten K1105550
Validation (Regelverprobung) K1105551
Variable vom Typ Set anlegen und löschen K1102792
Variantenkonfiguration mit Mengenvariation S1100766
Verkaufsbeleg Positionstypentabelle BR P40SD_01
Verkaufsbelegart Lokalisierung Brasilien P40SD_10
Versuch, den Vertragspartner doppelt anzulegen KKK00415
Vertragskonto anlegen und wieder löschen KKK00423
Vertragspartner anlegen und wieder löschen KKK00414
Verwendungsnachweis B2000804
Verzinsung Investitionsmaßnahme P3006156
Viele, viele Lieferungen (Test) P3010443
Voraussetzungen Costumizing K1105565
Vorerfassten Beleg ändern K1102843
Vorerfassten Beleg löschen K1102844
Vorlauf PP-PI: Nummerkreiszuordnungen P3001765
Vorschlagsarbeitsplatz definieren P3001718
Vorschlagswerte P3001749
WÄHRUNGEN K1102677
408
Sandini Bib
Währungsumrechnung K1102450
Wiederaufsetzen fehlgeschlagener Generierung P3007629
WM Freigabe Sammelgang K1105563
WM Starten Sammelgang K1105562
WM: Auswertung Sammelgang K1105564
WM: Selektion Transportbedarfe K1105561
WM:Selektion Lieferungen K1105560
Workflow-Schrittprotokoll K1105710
XK02 - Kreditor ändern, Adr.vers...f P3001050
XK02 - Kreditor ändern, Adressversionen P3001049
XK02 - Kreditor ändern, Dok.-Verkn... P3001048
XK02 - Kreditor ändern, Einkaufsdaten P3001037
XK02 - Kreditor ändern, Einkaufsdaten... P3001038
XK02 - Kreditor ändern, Klassifizierung P3001052
XK02 - Kreditor ändern, Klassifizierung P3001051
XK02 - Kreditor ändern, Kontoführung P3001031
XK02 - Kreditor ändern, Korrespondenz P3001035
XK02 - Kreditor ändern, Korrespondenz... P3001036
XK02 - Kreditor ändern, Löschvormerkgung P3001044
XK02 - Kreditor ändern, Löschvormerkung P3001043
XK02 - Kreditor ändern, Partnerrollen P3001039
XK02 - Kreditor ändern, Partnerrollen... P3001040
XK02 - Kreditor ändern, Sperrdaten P3001041
XK02 - Kreditor ändern, Sperrdaten... P3001042

Anhang D
XK02 - Kreditor ändern, Steuerung P3001055
XK02 - Kreditor ändern, Steuerung P3001057
XK02 - Kreditor ändern, Steuerung... P3001056
409
Sandini Bib
XK02 - Kreditor ändern, Steuerung... P3001058
XK02 - Kreditor ändern, Zahl.verkehr P3001030
XK02 - Kreditor ändern, zentrale Texte P3001045
Zahlungsausgang buchen K1100574
zwei WWI-Server auf einem PC P3007626
410
Sandini Bib
Glossar
ABAP Advanced Business Application Programming. Programmier-

sprache der vierten Generation, die von der SAP AG ent-
wickelt wurde und zur Entwicklung von Anwendungspro-
grammen dient.
ABAP-Programm Programm, das in der ABAP-Programmiersprache ge-
schrieben ist.
ABAP-Query Werkzeug der ABAP Workbench, das Benutzern ohne
Kenntnis der ABAP-Programmiersprache und der einzel-
nen Tabellen und Feldnamen die Möglichkeit bietet, eigene
Auswertungen zu definieren und durchzuführen.
ABAP-Report ABAP-Programm, das Daten aus Datenbanktabellen liest
und auswertet, ohne dabei die Datenbank zu verändern.
Beim Ausführen eines ABAP-Reports kann die Ausgabeli-
ste (die auch Report genannt werden kann) entweder auf
dem Bildschirm angezeigt oder zu einem Drucker geschickt
werden.
ABAP Workbench Integrierte grafische Entwicklungsumgebung der SAP. Die
ABAP Workbench unterstützt die Entwicklung und das
Modifizeren von in ABAP geschriebenen Client/Server-
Anwendungen in R/3.
Abnahmetest Test des R/3-Auslieferungsystems vor der Auslieferung
auf verschiedenen Plattformen.
Arbeitspaket Eine Gruppe von Aktivitäten, die für den Abschluss eines
großen Teiles einer Roadmap-Phase erstellt wurden.
ASAP AcceleratedSAP – Einführungsmethode zur beschleunigten
R/3-Einführung.
411
Sandini Bib
Glossar
Batch-Input Schnittstelle, die die Übernahme von großen Datenmengen

in ein SAP-System ermöglicht. Sie können den Batch-Input
für das SAP-System sowohl bei alten Daten als auch bei ex-
ternen Daten verwenden.
Berechtigung Element des Berechtigungssystems. Eine Berechtigung gibt
für jedes Berechtigungsfeld in einem Berechtigungsobjekt
einen oder mehrere erlaubte Werte an. Die Werte in einer
Berechtigung werden in Berechtigungstexten verwendet,
um festzustellen, ob eine Benutzeraktion im System gestat-
tet ist.
Berechtigungs- Eine genaue Definition der Verantwortlichkeit für bestimmte
konzept stimmte Funktionen. Diese Definition bestimmt, wer über
die Sicherheitsberechtigung und den Zugriff auf bestimmte
Funktionen verfügt und ob die Berechtigung für das Erstel-
len, Ändern oder Anzeigen bestimmter Transaktionen be-
steht.
Berechtigungs- Element des Berechtigungskonzepts. Berechtigungsprofile
profil gewähren den Benutzern Zugriff auf das System. Sie enthal
ten Berechtigungen, die durch den Namen ein Berechti
gungsobjektes und den Namen einer Berechtigung identi-
fiert werden. Wird ein Profil in einem Benutzerstammsatz
eingetragen, so sind einem Benutzer damit alle in diesem
Profil enthaltenen Berechtigungen zugeordnet.
Berechtigungs- Prüfung, ob ein Benutzer zur Ausführung einer bestimm-
prüfung ten Funktion berechtigt ist. Bearbeitungsvorgänge, Funk-
tionen und Datenzugriffe im R/3-System werden nur
durchgeführt, wenn die Berechtigungen der Benutzer ge-
prüft werden. Dies erfolgt in den jeweiligen System- und
Anwendungsprogrammen.
Blueprint- Eingabeformulare des Unternehmens für die Question &
Formular Answer-Datenbank, die für die Erfassung der Unterneh-
mensanforderungen in der zweiten Roadmap-Phase ver-
wendet werden.
Branchensystem Abbildung einer kompletten Branche im R/3-System. Ein
vorkonfiguriertes Branchensystem umfasst das Branchen-
modell, branchenspezifische Systemeinstellungen und
Stammdaten sowie branchenspezifische Präsentationen
und Hinweise als Ergänzung zur SAP-Standarddokumen-
tation.
412
Sandini Bib
CATT Computer Aided Test Tool. Universell einsetzbares SAP-Test-

werkzeug. Mit dem Computer Aided Test Tool können be-
triebswirtschaftliche Vorgänge zu wiederholbaren Testab-
läufen zusammengefasst und automatisiert werden.
Customizing Methode im R/3-System, mit deren Hilfe man SAP-Funk-
tionen schnell, sicher und kostengünstig im Unternehmen
installieren und die Standardfunktionen so anpassen kann,
dass man den besonderen Geschäftsanforderungen des je-
weiligen Unternehmens gerecht wird.
Customizing- Transaktion im Customizing, mit der man Tabellen ein-
Transaktion stellt.
Datenintegrität Korrektheit und Konsistenz der Daten in einer Datenbank.
DSDM Dynamic Systems Development Method
Early Watch Ein proaktiver Online-Dienst der SAP AG für die System-
System diagnose. Der Kunde wird mithilfe einer Fernverbindung
zwischen der SAP und dem Kunden bei der Problemüber-
wachung und -beseitigung unterstützt.
Einführung Wechsel von einem vorhandenen System und Umgestal-
tung der Geschäftsabwicklungen, um mithilfe des R/3-Sys-
tems einen Teil oder das gesamte Geschäft abzuwickeln.
Einführungs- Werkzeug zur kundenspezifischen Anpassung des R/3-Sys-
leitfaden (IMG) tems. Der Einführungsleitfaden (IMG) enthält für jede An-
wendungskomponente alle Schritte für die Einführung des
R/3-Systems, alle Standardeinstellungen und alle Aktivitä-
ten zur Konfigurierung des R/3-Systems.
Siehe auch IMG.
Externe Daten Nicht-SAP-Daten. Daten, die von einem externen System
kommen.
Funktionstest Unterste Testebene, auf der das Programm oder die Trans-
aktionen auf Fehler hin getestet und ausgewertet werden.
Der Funktionstest ist normalerweise der erste Test, der ab-
geschlossen wird. Er erfolgt für gewöhnlich während der
Entwicklungsarbeit und konzentriert sich eher auf die inne-
ren Funktionen des Programms als auf die Integration.
Geschäftsvorfall Der Geschäftsvorfall stellt die detaillierten Anweisungen
für die Einrichtung, den Betrieb, die Auswertung und die
Verbesserung der R/3-Lösung und -Konfiguration entspre-
Glossar
chend den Geschäftsanforderungen dar.

Geschäftsszenario Reihe von Geschäftstransaktionen, die die Abhängigkeit
von einem Ereignis oder einem Zeitraum gemeinsam ha-
413
Sandini Bib
Glossar
ben. Ereignisgesteuerte Szenarien basieren auf einem be-

stimmten Ereignis wie z.B. der Erteilung eines Kundenauf-
trags. Zeitabhängige Szenarien basieren nicht auf einem
bestimmten Ereignis, sondern auf einem Zeitraum. Zu sol-
chen Prozessen gehören der Monatsabschluss, die Stan-
dardkostenauswertung, Prüfdurchläufe und mögliche Da-
tenreorganisationen.
IDES International Demonstration and Education System. Es be-
inhaltet mehrere Musterunternehmen, die modellhaft die
relevanten Geschäftsprozesse des Systems R/3 abbilden.
Durch einfache Benutzerleitfäden und verschiedene
Stamm- und Bewegungsdaten können umfangreiche Sze-
narien durchgespielt werden. IDES eignet sich daher als
Trainingselement bei der Ausbildung des Projektteams.
IMG Implementation Guide; siehe Einführungsleitfaden
Integrationstest Das Testen einer Reihe von Geschäftsprozessen, die zusam-
menfließen. Funktionsübergreifende Integrationstests be-
treffen auch Ausgaben, Schnittstellen, Vorgehensweisen,
Organisationsaufbau und Sicherheitsprofile und konzen-
trieren sich auf wahrscheinliche Geschäftsereignisse und
auf Ausnahmen mit großen Auswirkungen.
ISO-Norm Norm, die von der International Organization for Standardiza-
tion herausgegeben wurde. Die ISO ist eine Organisation,
die internationale Normen für den Handel, die Wissen-
schaft und die Technologie entwickelt.
ISO9000-3 International Organisation for Standardization; Richtlinie
für die Entwicklung, Lieferung und Wartung von Software.
Länderspezifische Die Einstellungen in einem Mandanten repräsentieren die
Standard- juristischen und die wirtschaftlichen Anforderungen in ei-
einstellungen nem Land. SAP bietet die deutsche Version als Standard an.
Durch die Ausführung eines Programms kann eine Länder-
version erstellt werden, um die Vorgabeeinstellungen an
das ausgewählte Land anzupassen.
Mandant Eine handelsrechtlich, organisatorisch und datentechnisch
abgeschlossene Einheit innerhalb eines R/3-Systems mit
getrennten Stammsätzen und einem eigenständigen Satz
von Tabellen.
Mandanten- Einstellungen, die nur für einen Mandanten zutreffen. Die
abhängig Einstellungen in mandantenabhängigen Tabellen beziehen
sich nur auf den Mandanten, auf welchen bei der Anmel-
dung zugegriffen wurde.
414
Sandini Bib
Mandanten- Die Einstellungen in mandantenunabhängigen Tabellen

unabhängig beziehen sich auf alle Mandanten, unabhängig vom An-
meldemandanten.
Mandant, Der vorkonfigurierte Mandant ist eine Reihe von Konfigu-
vorkonfigurierter rationen, die aus den am häufigsten verwendeten US-Cus-
tomizing-Einstellungen besteht (z.B. US-orientierte Konto-
tabellen, Maßeinheiten und Formulare). Grundprozesse in
MM, SD und FI/CO sind eingerichtet und laufen vom er-
sten Tag an, an dem der Mandant transportiert wird.
Matchcode Vergleichsschlüssel. Ein Matchode erlaubt es, den Schlüssel
eines bestimmten Datenbanksatzes (z.B. eine Kontonum-
mer) zu finden, indem man im Satz enthaltene Informatio-
nen eingibt. Das System zeigt dann eine Liste aller Sätze an,
die es aufgrund der Eingabe ermittelt hat.
Modifikation Änderung der SAP-Standardprogramme, um den besonde-
ren Anforderungen des Benutzers gerecht zu werden (im
Gegensatz zur Erweiterung).
Produktivsystem Das System, das für den Normalbetrieb verwendet wird.
Prozess Geschäftsprozess, welche die Erstellung oder Änderungen
der Geschäftsobjekte oder -bedingungen beschreibt.
Qualitätsprüfung Eine Qualitätsprüfung wird am Ende jeder Phase der
Roadmap vorgenommen. Die Prüfung wird vom Projekt-
leiter durchgeführt und dient der Überprüfung der Tatsa-
che, ob sämtliche Aktivitäten und Aufgaben ausgeführt
und vollständige und korrekte Eingabeinformationen ent-
wickelt wurden. Nach Durchführung der Qualitätsprüfung
kann die nächste Phase begonnen werden.
R/3 Realtime/3
R/3-Referenz- Darstellung der kompletten im R/3-System enthaltenen
modell Funktionalität in Gestalt grafischer Modelle. Das R/3-Refe-
renzmodell umfasst folgende Modelle: Prozessmodell, Da-
tenmodell/Objektmodell, Organisationsmodell und Ver-
teilungsmodell.
R/3-Repository Alle Entwicklungsobjekte der ABAP Workbench werden
im R/3-Repository gespeichert. Zu diesen Entwicklungs-
objekten zählen ABAP-Programme, Bildschirme, Doku-
mentationen usw.
Glossar
Roadmap Bezeichnung für das Vorgehensmodell im ASAP-Ansatz.

SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung
415
Sandini Bib
Glossar
SAP-Einführungs- Anleitung zum Einstellen des SAP R/3-Systems.

leitfaden
SAP-Vorgehens- Wasserfall-basierter Leitfaden, der die zur Einführung des
modell R/3-Systems notwendigen Aktivitäten beschreibt.
Schnittstelle Übergangsstelle zwischen verschiedenen abgegrenzten
Komponenten eines Systems.
Stammdaten Daten, die sich auf individuelle Objekte beziehen, die über
längere Zeit unverändert bleiben. Stammdaten enthalten
Informationen, die für ähnliche Objekte auf die gleiche
Weise verwendet werden.
System- Erweiterung des R/3-Systems um zusätzliche Objekte, Pro-
erweiterung gramme oder Schnittstellen, ohne dass das bestehende
R/3-Coding geändert wird.
Testablauf Sequentielle Anordnung von verschiedenen Testbaustei-
nen in CATT.
Testbaustein Reihe von automatischen Aufrufen und Prüfungen von
SAP R/3-Transaktionen.
Testdaten Satz repräsentativer und bedeutsamer Eingabedaten, die
benutzt werden, um den Testfall zu überprüfen und die
Übereinstimmung des Systems mit den definierten Kriteri-
en und den erwarteten Ergebnissen sicherzustellen.
Testfall Besonderer Geschäftsablauf mit einem entsprechenden
Satz von Eingaben, Bedingungen und Kriterien, der ver-
wendet wird, um die R/3-Geschäftsprozesse durchzuspie-
len mit dem Ziel, die Übereinstimmung des Systems mit
den Anforderungen zu prüfen.
Testkatalog Hierarchische Gliederung aller Testbauabläufe in CATT.
Testpaket Teil eines Testplans, der für einen konkreten Test benötigt
wird und der einer bestimmten Person als verantwortli-
chem Tester zugewiesen wird.
Testplan Teil eines Testkatalogs in CATT, der für eine bestimmte
Testaufgabe benötigt wird.
Testworkbench SAP R/3-Funktionalität zum Verwalten und Dokumentie-
ren von Testvorhaben.
Testvariante Testablauf mit veränderten Import-Parametern.
416
Sandini Bib
Testumfang Satz der Testfälle, der die geplante Geschäftsumgebung

wiedergibt. Wenn diese Testfälle im R/3-System durchge-
testet wurden, kann auf angemessene Weise innerhalb ei-
nes gewissen Sicherheitsrahmens festgestellt werden, wie
geeignet die Lösung für das Geschäft ist.
Testumfeld Technische Einstellungen und die Geschäftseinstellungen,
die für die Steuerung der Ausführung, die Überwachung
und die Auswertung der Tests verwendet wird. Es gibt ver-
schiedene Testumfelder, um dem Testziel zu entsprechen.
Diese reichen von Einheitentests über Integrationstests bis
hin zu Performance-Tests. Jedes dieser Testumfelder muss
vor den Tests eingerichtet werden.
Transaktionscode Folge von vier Zeichen, die eine SAP-Transaktion kenn-
zeichnen. Um eine Transaktion im R/3-System aufzurufen,
geben Sie den Transaktionscode in das Befehlsfeld ein. Bei-
spiel: FK01 (Kreditor anlegen)
Transport Übernahme von Objekten der Entwicklungsumgebung aus
einem Quellsystem in ein Zielsystem. Im Allgemeinen er-
folgt der Transport über einen Transportauftrag.
Transportauftrag Dokument zum Kopieren von Korrekturen zwischen ver-
schiedenen Systemarten. In einem Transportauftrag wer-
den freigegebene Korrekturen erfasst. Nach Freigabe eines
Transportauftrags wird der Transport durchgeführt. Sie
können z.B. Korrekturen aus einem Integrationssystem in
ein Konsolidierungssystem transportieren.
Vorgehensmodell Leitfaden, der die zur Einführung des R/3-Systems not-
wendigen Aktivitäten beschreibt.
Glossar
417
Sandini Bib
Sandini Bib
Literaturverzeichnis
Balzert92
Helmut Balzert:
Die Entwicklung von Software-Systemen: Prinzipien, Methoden, Sprachen,
Werkzeuge. Mannheim u.a. 1992
Balzert96
Helmut Balzert:
Lehrbuch der Software-Technik: Software-Entwicklung. Heidelberg, Berlin
1996
Balzert98
Helmut Balzert:
Lehrbuch der Software-Technik: Software-Management, Software-Qualitäts-
sicherung, Unternehmensmodellierung, Heidelberg, Berlin 1998
Beims95
H. D. Beims:
Praktisches Software Engineering: Vorgehen, Methoden, Werkzeuge. Mün-
chen, Wien 1995
Beyer98
Hugh Beyer, Karen Holtzblatt:
Contextual Design: Defining Customer-Centered Design. San Francisco 1998
Bieberstein93
N. Bieberstein:
CASE-Tools: Auswahl, Bewertung, Einsatz, München, Wien 1993
419
Sandini Bib
Boehm81
B. W. Boehm :
Software Engineering, Englewood Cliffs 1981
Brand 98
Hartwig Brand:
SAP R/3-Einführung mit ASAP: Technische Implementierung von SAP R/3
planen und realisieren. Bonn u.a. 1998
Cohn77
Ruth Cohn:
Von der Psychoanalyse zur Themenzentrierten Interaktion, Klett Cotta 1977
Curth89
Michael A. Curth, Martin C. Giebel:
Management der Software-Wartung. Stuttgart 1989
DSDM95
DSDM Consortium:
Dynamic Systems Development Method. Version 2, Farnham 1995
DSDM97
DSDM Consortium:
Dynamic Systems Development Method. Version 3, Farnham 1997
Frese94
Michael Frese, Jochen Prümper, Ferdinand Solzbacher:
Eine Fallstudie zu Benutzerbeteiligung und Prototyping. In: Felix C. Brod-
beck, Michael Frese (Hrsg.): Produktivität und Qualität in Software-Projek-
ten. Psychologische Analyse und Optimierung von Arbeitsprozessen in der
Software-Entwicklung. München, Wien 1994, S. 135–143
Frick95
A. Frick:
Der Softwareentwicklungsprozeß. Ganzheitliche Sicht. München 1995
Gladden82
G. R. Gladden:
Stop the Life-Cycle, I want to get off. In: Software Engineering Notes. Nr.2,
1982, S. 25–39
Geiss, Soltysiak98
M. Geiss, R. Soltysiak:
SAP R/3 dynamisch einführen. Bonn 1998
420
Sandini Bib
Haberfellner92
Haberfellner, Nagel, Becker, Büchel, von Massom:
Systems Engineering: Methodik und Praxis. 7. Auflage, Zürich 1992
Himmler94
J.F. Himmler, N. H. C. Thuy:
Marktreport 1994 – Intelligente Software-Technologien. München 1994
Jäger93
E. Jäger et al.:
Die Auswahl zwischen alternativen Implementierungen von Geschäftspro-
zessen im einem Standardsoftwarepaket am Beispiel eines KFZ-Zulieferes.
In: Wirtschaftsinformatik 35, 1993
Jalote91
Pankaj Jalote:
An Integrated Approach to Software Engineering. New York u. a. 1991
Jamin94
K.-W. Jamin:
Das Software-Lexikon. 3., akt. Auflage, Renningen-Malmsheim 1994
Keller98
G. Keller, Th. Teufel:
SAP R/3 prozeßorientiert anwenden. 2., durchges. u. korr. Auflage, Bonn
Reading, Mass. 1998
Lehner94
F. Lehner:
Softwaredokumentation. München, Wien 1994
Martin91
James Martin:
Rapid Application Development. New York 1991
Mayrhauser90
Anneliese von Mayrhauser:
Software Engineering. Methods and Management. Boston u.a. 1990
421
Sandini Bib
Mumford84
Enid Mumford, Günter Welter:
Benutzerbeteiligung bei der Entwicklung von Computersystemen. Verfah-
ren zur Steigerung der Akzeptanz und Effizienz des EDV-Einsatzes. Berlin
1984
Nomina96
Nomina Information Services
ISIS PC Report 2-1996, München 1996
Page-Jones95
M. Page-Jones:
Strukturiertes Systemdesign. London 1995
Paulk95
Mark C. Paulk, Charles V. Weber, Bill Curtis, Mary Beth Chtissis:
The Capability Maturity Model: Guidelines for Improving the Software Pro-
cess. Reading u.a. 1995
Pomberger96
G. Pomberge, G. Blaschek:
Software Engineering, 2., überarb. Auflage, München, Wien 1996
Managermagazin98
J. Rieker:
Die drei von der Baustelle. In: Managermagazin Nr.4, 1998
Börse Online97
W. Rüppel:
SAP – einfach die erfolgreichste Aktie. In: Börse Online Nr. 46, 1997
Schneider97
H.-J. Schneider:
Lexikon Informatik und Datenverarbeitung. 4., akt. u. durchges. Auflage,
München, Wien 1997
Stahlknecht95
P. Stahlknecht:
Einführung in die Wirtschaftsinformatik. 7., vollst. überarb. und erw. Aufla-
ge, Berlin 1995
Sommerville92
Ian Sommerville:
Software Engineering. 4. Auflage, Wokingham, u.a. 1992
422
Sandini Bib
Stapleton97
Jennifer Stapleton:
Dynamic Systems Development Method. The Method In Practice. Harlow
1997
Thome96
R. Thome, A. Hufgard:
Continuous System Engineering. Würzburg 1996
Trauboth93
H. Trauboth:
Software-Qualitätssicherung. München, Wien 1993
Ungermann96
C. Ungermann, F.-J. Tesch, B. Stolpe, M. Weissert:
Qualitätsmanagement bei der Softwareerstellung: Leitfaden für die Umset-
zung der DIN EN ISO 9000. Düsseldorf 1996
VDI92
VDI-Gemeinschaftsausschuß CIM:
Qualitätssicherung. Düsseldorf 1992
Wenzel96
P. Wenzel:
Betriebswirtschaftliche Anwendungen des integrierten Systems SAP R/3.
2., verbes. u. erw. Auflage, Braunschweig, Wiesbaden 1996
Xu95
Z.-Y. Xu:
Prinzipien des Entwurfs und der Realisierung eines Organisationsinformati-
onssystems. Heidelberg 1995
Zöller91
H. Zöller:
Wiederverwendbare Software-Bausteine in der Automatisierung. Düssel-
dorf 1991
423
Sandini Bib
Internetadressen:
SAP AG: Strasbourg – Summary, Walldorf 1997
http://www.sap-ag.de/products/r2/aktuell/strasbou.htm
SAP AG: CATT – A simple tool, Walldorf
http://www.sap-ag.de/products/r2/press/catte.htm
SAP AG: CATT – automated test procedures for improved quality assurance,
Walldorf 1997
http://www.sap-ag.de/products/r2/press/10rieg12.htm
SAP AG: ABAP/4-Develoment Workbench – Media Center, Walldorf 1998
http://www.sap-ag.de/germany/products/abap/media/mc_over.htm
SAP AG: Funktionen im Detail: ABAP/4 Development Workbench, Walldorf
1997
http://www.sap-ag.de/germany/products/abap/media/50007832.htm
Anforderung an moderne Softwareentwicklungswerkzeuge
http://www.sap-ag.de/germany/products/techno/media/pdf/07832_02.pdf
Anwendungsentwicklung mit der ABAP/4 Development-Workbench
Einführung des Entwicklungssystems
Glossar
http://www.sap-ag.de/germany/products/techno/media/pdf/07832_gl.pdf
SAP AG: System R/3 – ABAP Workbench, Walldorf 1997
http://www.sap-ag.de/germany/products/techno/media/pdf/50004382.pdf
424
Sandini Bib
Stichwortverzeichnis
◗◗ A Blockmodus 158
Funktionseditor 158
ABAP/4 58 Altdatenübernahme 78, 124
ABAP/4-Data-Modeller 62 Anwenderschulung 89
ABAP/4-Development-Workbench 47, 57 Anwendungssystem 29
Bestandteile 58 Anwendungstest 153
ABAP/4-Dictionary 59 Application Link Enabling 132
ABAP/4-Editor 61 application software 29
ABAP/4-Navigation/Browser 61 Archivierung von Protokollen 144
ABAP/4-Query 62 ARIS-Toolset 80
ABAP/4-Repository 59 ASAP 74, 97
ABAP/4-Workbench-Organizer 61 ASAP-Einführungsmethodik 43, 80
Abbruch einer Schleife – EXIT 164 Backup- und Restore-Verfahren 43
Abbruchkennzeichen 154 ASAP-Roadmap 97
Abgebildet in CATT-Testbaustein Attribute 147
ZDCE0091 293 Abhängigkeiten 152
Abhängigkeiten definieren – IF...ENDIF 164 Allgemeine Daten 150
Ablaufprotokoll – Testablauf 220 Kennzeichen 154
Ablaufstatistik 249 Kopfdaten 148
Abschlussreview 80 Nutzbarkeit 153
Abschlusstest durchführen 84 Verwaltungsdaten 151
Abspielmodus 181, 252–253 Attributspflegebildschirm 148, 214–215,
Dunkles Abspielen 181 295
Helles Abspielen 181 Aufbau von Stammdaten im Rahmen der
Nur Fehler anzeigen 181 Altdatenübernahme sowie Anlegen
Protokollart 181 neuer Stammdaten 83
Abspielparametrisierung 259 Aufzeichnung von Testbausteinen 294
Add Ons 78 Aufzeichnungsfunktionalität 131, 140,
Add-On-Komponente 128 185
ALE 132 Auswertung von Protokollen 144
Allgemeine Funktionen Authorisationskonzept 130
425
Sandini Bib
◗◗ B Bildschirmbildern orientierte
Statistik 258
Batch-Input 70 Statusanalyse 255
Batch-Input-Mappe 72 CATT-Testablauf 318
Bearbeitungsfunktionen 159 CATT-Testaktivitäten 124
Beenden einer Schleife – ENDDO 163 CATT-Transportvorbereitung 263
Benutzerfestwerte 151 CATT-Übersicht 264
Benutzerhandbuch 37 CHEERR 164
Benutzerschnittstelle 48 CHETAB 165
Berechtigungsobjekt 129 CHEVAR 165
Berechtigungsprüfung 129 Client/Server-Anwendungsentwicklung 58
Betriebswirtschaftliche Testszenarien 131 Client/Server-Architekturen 54
Betriebswirtschaftlicher Prozess 140 COMMIT WORK 70
Bildschirmbildabfolge 140 Computer Aided Software Engineering 46
Branchenlösung 55 Computer Aided Test Tool 40, 67, 269
Branchenmodell 52 Computergestütztes (Test-)Werkzeug 28
Business Blueprint 97 Contextual Inquiry 123
Customizing 142, 271
Customizing-Änderungen 78
◗◗ C Customizing-Einstellung 53, 117, 288
Customizing-Tabellen 231
CASE 48 mit CATT einstellen – SETTAB 162
CASE-Begriff 46
CASE-Plattform 47
CASE-Tool 46–50, 68, 287 ◗◗ D
CASE-Umgebung 28, 47–49, 127
CASE-Werkzeuge 28 Datenbankinhalt prüfen – CHETAB 165
CASE-Werkzeugkategorien 48 Datenintegrität 48
CATT 28, 50, 67, 73, 284 Datenkonsistenz 55
Funktionsüberblick 68 Datumsvariablen 177
CATT-Abläufe 128 Debugging 28
CATT-Ablaufprotokoll 208 Rückverfolgung 45
CATT-Attributspflegebildschirm 191 Defaultparameter 259
CATT-Entwicklung 129 Defaultparametrisierung 254
CATT-Historie 67 Detailbildschirm von CATT 195, 199
CATT-Management 180, 249, 264 Detaillierung und Realisierung 75
Einzelstart 250 Dialogmeldung 204
Massenstart 249 DIN ISO 9000-3 40
Selektion 250 DIN ISO 9003 318
CATT-Massentest-Report 261 DO 163
CATT-Objekt 132, 201 Downloadfunktion 143
CATT-Projekt 283 DSDM 35, 103
CATT-Protokoll 141–142, 220, 247, 304 DSDM-basiertes Vorgehensmodell 32, 36,
CATT-Protokoll-Archiv 184 103
CATT-Prozedur 253 DSDM-Besonderheiten 111
CATT-Rangfolge-Pflege 261 DSDM-Durchlauf 118
CATT-Startbildschirm 207 DSDM-Konsortium 34
CATT-Statistik 254 DSDM-Modell 35
An Transaktionscode und DSDM-Tauglichkeit 35
426
Sandini Bib
Dunkles Abspielen 181, 253 Bearbeitungsfunktionen 160

Durchführung von Modul- sowie Prüffunktionen 164
Integrationstests 82, 86 Steuerungsfunktionen 161
Durchführung von Transaktionstests 295 Funktionenmodell-Iteration 36, 113
Dynamic Systems Development Method Funktionsbaustein 246
34, 103 aufrufen und ausführen – FUN 160
Funktionsbibliothek 62
Funktionsbildschirm
◗◗ E Testablauf 216
von CATT 195
Einfacher CATT 184 Funktionstest 124
Einführung/Produktivsetzung 118
Eingabewerte 198
Einspielung von Stammdaten 124 ◗◗ G
Einstellung von Customizing-Tabellen 82,
84 Geschäftsprozess 28, 36, 137
Einstiegsbildschirm von CATT 185, 194 Geschäftsprozessanalyse 36, 74, 113
Einzelstart 180, 250 Geschäftsprozessbeschreibung 113
ENDDO 163 Geschäftsprozessdokumentation 122
Entwicklungswerkzeug 57 Geschäftsstudie 111
Erstellung von Anwenderdokumentation Go-Live and Support 100
124 Grundlagen der Softwareentwicklung 29
Erstellung von Schulungsunterlagen 124
Erweiterung der Namensräume 132
EXCEL-Tabelle zum Testablauf 228 ◗◗ H
EXIT 164
Expertenmodus 131 Helles Abspielen 181, 253
Exportparameter 131, 147, 204, 206,
217, 220, 300
Testbaustein 218 ◗◗ I
Exportschnittstelle 140
Externe Varianten 227 I-CASE 49
Identifizierung der Transaktionen 291
IDES 91
◗◗ F IDES-Prozesse 92
IF...ENDIF 164
Fehleraufdeckungsrate 269 IMG 75, 142
Fehlerfreiheit der Software 269 Implementation 142
Fehlermeldung aus Transaktion prüfen – Implementation Guide 75
CHEERR 164 Implementierungsstrategie 36
Fehlerursache 45 Import 140

Feldwertebildschirm von CATT 196 Importparameter 131, 172, 183, 198,
Festwerte 200 200, 202, 213, 220, 229, 296, 301
First Customer Shipment 94 auf Ablaufebene 302
Flexibilisierung der Testbausteine 301 Testablauf 217
FUN 160 Testbaustein 218
Funktionen 197 Importschnittstelle 140, 198
Funktionen des CATT 157 Individualprogrammierung 53
Allgemeine Funktionen 158 Individualtest 153
427
Sandini Bib
Infrastruktur der R/3-Umgebung 127 Managementfunktionalität 249

Ingenieurmäßige Methode 51 Managementtool 249
Integrales Element 73 Massenstart 180, 249
Integration Massentest 124, 261
automatischer Tests 271 Mastersprachenhandling 127
manueller Tests 271 Meilensteinsitzung 75
Integrationsrahmen 47 Message-Variable 175, 204, 296, 300
Integrationstest 87, 124, 287, 304 Modularer Aufbau 55
Integrative Verkettung 86 Modulares Konzept 139–140, 214
Integrität der Unternehmensdaten 53 Modularisierung 53, 136
Interne Varianten 222 Modultest 124, 295
ISO 9000 39 MoSCoW-Rules 121
ISO 9000-3 67, 137
ISO_9001 39
Iterative Prozess-Prototyping (IPP) 74 ◗◗ N
Nachspannläufe 153
◗◗ K Namenskonvention 201, 204
Nur Fehler anzeigen 181
Klassische Softwareentwicklung 28
Kommunikation 123
Komplexer CATT 209 ◗◗ O
Komplexität 51
Konfigurationsmanagement 37, 122 Objekt-Management-System 48
Konfigurierung 53, 137 Organisation und Konzeption 75
Kopfdaten 148
Korrektur- und Transportwesen 127
Kritik 47 ◗◗ P
Kurzprotokoll 253
Parameter 198, 200, 211
Parameter des CATT 172
◗◗ L Exportparameter 173
Importparameter 172
Langprotokoll 253 Namensgebung 173
Laufzeitstatistik 252 SET/GET-Parameter 174
Laufzeitsummierung 252 Parameterpflegebild 179
LEAVE TO TRANSACTION 71 Parameterpflegebildschirm 201
Lebenszyklustätigkeiten 40 Parametrisierung 53, 131, 283
Listauswertung 271 der Testbausteine 295
Listverarbeitung 250, 252 Pflege
Lokale Variablen 175, 303 der Eingabewerte/Parameter/Variablen
des Testablaufs 215 198
Lower CASE 49 von Customizing-Tabellen 183
Phasenkonzept 29
Phasenübergreifende Aktivitäten 108
◗◗ M Plattformtest 153
Priorisierung 37
Machbarkeitsstudie 35 Prioritätenliste 113
Machbarkeitsstudie/Vorstudie 111 Problembehandlung 245
428
Sandini Bib
Produktionsvorbereitung 75, 100 R/3-Testpläne 275

Produktivbetrieb 75 RAD 34
Produktivsetzung 107 RAD-Projekte 34
Produktivsystem 88, 92 Rangfolgepflege 249
Professionelle Softwareerstellung 46 Rapid Application Development 34
Programmpaket 52 Realisierung 99
Projektmanagement 37, 118 Redundanz 140
Projekttätigkeit 40 REF 160, 214
Projektvorbereitung 97 Referenzierung 154
Protokoll 141 des Testbausteins 215
Art 181 Regressionspaket 94
Kurzform 142 Regressionstest 117, 124
zum Testablauf KBC02108 mit Regressionstestpaket 275
externen Varianten 231 Release- und Regressionstests 94
Prototypen-Management 116 Releaseübergreifende Tests 132
Prototyping 32 Releasewechsel 137
evolutionary prototyping 33 Remote Start 128, 180, 184, 243
rapid prototyping 33 Remote-System 128
Prototyping-Aktivitäten 36 Reorganisation der Geschäftsprozesse 53
Prototyping-Management 37, 119 Report Builder 63
Prototyping-Plan 36 Repository 48
Prozessmodellierungstool 288 Repository-Informationssystem 127, 147,
Prüfen von System- bzw. Fehlermeldungen 182, 192–193, 249, 253
93 RESTAB 163
Prüffunktionen 160 RFC-Destination 244
Prüfkennzeichen 253–254 RFC-Schnittstelle 128
Prüfkennzeichenvergabe 265 Risikoanalyse 38, 120
◗◗ Q ◗◗ S
Qualitätskriterien 142 SAP R/3-System 57

Qualitätsmanagement 40, 123 SAP-Softwareengineering 67
Qualitätsnorm 39, 137 SAP-Vorgehensmodell 75
Qualitätssicherung 38–39, 137 SAP-Werkzeuge zum Testen 283
Qualitätssicherungshandbuch 318 Schleifenfunktion – DO 163
Qualitätssicherungsplan 40 Screen-/Menupainter 60
Qualitätssicherungssystem bei der Selektion 250
Softwareentwicklung 51 Laufzeitstatistik 252
Qualitätssicherungswerkzeug 67 Laufzeitsummierung 252
Protokoll 252
Prüfkennzeichen 253
◗◗ R Repository-Informationssystem 250
Varianten 254
R/3 – R/2-Verbindung 244 Selektionsbildschirm 250
R/3 – R/3-Verbindung 243 SET/GET-Parameter 174, 246
R/3-Funktionsbibliothek 128 SET/GET-Paramter/Parameter-Ids 175
R/3-Software 40 SETTAB 162
R/3-Testkatalog 271 SETVAR 161, 204
429
Sandini Bib
Software-Bürokratie 50 Systemtest 42
Softwareentwicklung 27, 284 Testaufwand 278
Softwareentwicklungs- und Testkonzept Testausführende 269
28, 284 Testauswertung 270
Softwareentwicklungsprozess 29 Testbaustein 129, 139, 183, 283, 291
Softwareentwicklungsumgebung 47 abspielen 206
Softwareentwicklungswerkzeug 46 anzeigen 193
Softwarequalität 46, 136 aufrufen und ausführen - REF 160
Software-Wartung 51 Testdaten 94
Sondervariablen 176 Testdurchführung 269, 277
Sonstige Funktionen 240 Testen 27, 38, 40, 123, 142
Start aus CATT-Protokoll 143 Testqualität 40
Startbildschirm 143 von Transaktionen 82
mit aktivierten Varianten – Testablauf Ziel 40
225 Testfallaufzeichnung 113
Testablauf 219 Testfallbeschreibung 271
Startoptionen 220, 225 Testkatalog 270–271
Statusanalyse 270, 279 Erstellung 272
Statusanalyseliste 255 Integration manueller Tests 270
Statusbildschirm des R/3-Systems 186 Knoten hinzufügen 273
Steuerungsfunktionen 159 Test aus Katalog heraus starten 274
Syntaxprüfung 191, 211, 214, 219 Testkataloge 269
System R/3 54 Testkonzept 284
Systematisierung 68 erstellen 80
System-Design- und System-Build-Iteration Testkosten 136
37, 117 Testmanagement 271
Systementwicklung 29 Testmethodik 28
Systemtest 92 Testobjekte 41
Systemvariablen 176 Testpakete 269
Testplan 269
Erstellung 80, 275
◗◗ T Testplanung 283
Testprozedur 271
Tabelleneinträge 231, 233 Testsystem 288
Tabellenkalkulationsprogramm 227 Testszenario 128, 142, 269, 288
TCD 160, 194 Testumgebung 57
Test 39, 269 Testverantwortlicher 284
Testablauf 139–140, 183, 214–215, 221, Testverlauf 141
234, 283, 301 Testvorhaben 269
abspielen 221 Testwerkzeug 67
erstellen 214 Testworkbench 28, 40, 80, 269
Testablaufebene 217, 220 Testziel 287
Testadministrator 269 Textdatei 227
Testarten Texte eingeben – TXT 161
Abnahmetest 42 Timeboxing 37
Integrationstest 42 Priorisierung 121
Modultest 42 Traditionelles SAP-Vorgehensmodell 74
Regressionstest 42 Transaktion 70, 131, 140
Symbolischer Test 42 Anlegen Faktura VF01 294
430
Sandini Bib
Anlegen Lieferung VL01 294 Systemvariablen 176

Anlegen ProzessauftragCOR1 292 Textvariablen 175
Ausführen - TCD 160 Varianten 181, 183, 221, 254
Code 131, 140 anlegen 221
Hinzufügen Bestellung ME21 291 Externe Anwendungen 146
IST-Abrechungs-Auftrag KO88 293 Interne Varianten 146
Kundenauftrag anlegen VA01 294 Variantenprüfkennzeichen 254
Rechnung hinzufügen MRHR 292 Verwaltung von CATT-Testfällen 269
Rückmeldung Prozessauftrag CORK Statusanalyse durchführen 278
293 Testdurchführung 277
Wareneingang zur Bestellung buchen Testkatalog 269
MB01 292 Testpaket 277
WIP-Ermittlung Auftrag KRAX 293 Testpakete zuordnen 280
ZuschlagsberechnungKG12 293 Testplan 275
Transaktionsdurchlauf 154 Visio Business-Modeler 80
Transaktionskette 127, 131 Vorgehensmodell 32, 284
Transaktionsstatistik 249 Vorschlagswerte 200, 229
Transaktionstest 295 Vorspannläufe 153
Transportmedium 303 Vorteile
zwischen Export- und Importparameter der CASE-Systeme 51
219 des DSDM-basierten Vorgehensmodells
Transportvorbereitung 249 125
Transportwesen 130
TXT 161
◗◗ W
◗◗ U Wasserfallmodell 32, 105

Werkzeuge für Test, Tuning und
Übergabeparameter 141 Debugging
Übersicht Varianten – Testablauf 223 Computer Aided Test Tool 63
Übersichtsliste 249 Werkzeugkategorien 48
Unternehmensziel 35 Wertermittlung und
Upper CASE 48 Datenbankfortschreibungen 94
Wertübergabe an Testbausteine bzw.
Testabläufe 172
◗◗ V Wiederholbarkeit der Testabläufe 136
Variable versorgen – SETVAR 161

Variablen 174, 198, 200 ◗◗ Z
Datumsvariablen 177
Inhalte überprüfen – CHEVAR 165 Ziele und Vorteile von CASE 47

Lokale Variablen 175 Zurücksetzen von Customizing-Tabellen
Message-Variablen 175 mittels CATT – RESTAB 163
SET/GET-Paramter/Parameter-Ids 175
431
Sandini Bib
Copyright
Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell angebotenen
eBook-Zusatzdaten sind urheberrechtlich geschützt.
Dieses eBook stellen wir lediglich als Einzelplatz-Lizenz zur Verfügung!
Jede andere Verwendung dieses eBooks oder zugehöriger Materialien und
Informationen, einschliesslich der Reproduktion, der Weitergabe, des Weitervertriebs,
der Platzierung im Internet, in Intranets, in Extranets anderen Websites, der
Veränderung, des Weiterverkaufs und der Veröffentlichung bedarf der schriftlichen
Genehmigung des Verlags.
Bei Fragen zu diesem Thema wenden Sie sich bitte an:
mailto:info@pearson.de
Zusatzdaten
Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die
Zurverfügungstellung dieser Daten auf der Website ist eine freiwillige Leistung des
Verlags. Der Rechtsweg ist ausgeschlossen.
Hinweis
Dieses und andere eBooks können Sie rund um die Uhr
und legal auf unserer Website
(http://www.informit.de)
herunterladen

Addison Wesley - SAP R3 Systeme Effizient Testen+

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Addison Wesley - SAP R3 Systeme Effizient Testen+

Diunggah oleh

Hak Cipta:

Format Tersedia

Sandini Bib

SAP® R/3®-Systeme effizient testen

Mario Pérez, Alexander Hildenbrand, Bernd Matzke, Peter Zencke

Thomas Teufel, Jürgen Röhricht, Peter Willems

Andreas Berthold, Ulrich Mende, Herbert Schuster

SAP R/3 -Systeme

Automatisiertes Testen von

Die Deutsche Bibliothek – CIP-Einheitsaufnahme

Ein Titeldatensatz für diese Publikation ist bei

© 2000 by Addison Wesley Verlag

Einbandgestaltung: Barbara Thoben, Köln

D.1 Übersicht der standardmäßig verfügbaren Testabläufe 387

Das Testen stellt im Rahmen von SAP R/3-Einführungsprojekten eine ebenso

Die Nutzenaspekte der Vorgehensweise von ICM sind die folgenden:

Dieses Branchen-Know-how wird permanent im Rahmen von Projekten erwei-

Qualitätssicherung und Softwaretest – für viele DV-Leute bedeuteten diese Auf-

Vorliegendes Buch spiegelt im wesentlichen meine Erfahrungen aus der Pla-

Mühldorf a. Inn, im April 1999

Ich möchte mich insbesondere bei Herrn Gerhard Oberniedermaier bedanken,

Köln, im April 1999

Vorwort zur ersten Auflage

Um heutzutage auf den sich permanent wandelnden Märkten bestehen bzw.

SAP AG, permanent Innovationen zu liefern, führen zu einem stetig zunehmen-

werden. Das Modell gliedert das EDV-Projekt in mehrere Projektphasen und

soll sowohl R/3-Beratern als auch Anwendern ein praxisorientierter Leitfaden

Kapitel 7 beschreibt die verschiedenen Programmierfunktionen von CATT:

In Kapitel 13 werden die Testlösungen von Mercury Interactive, einem führen-

mancetests an unterschiedlichen Applikationen innerhalb des Unternehmens

Einführung in das Testen

gestellung, wie die verschiedenen Testmethoden in den Einführungsprozess in-

Zum R/3-System existieren bereits ebenfalls viele Publikationen, so dass sich

1.1 Grundlagen der Softwareentwicklung

Kapitel 1 – Einführung in das Testen von Software

Kapitel 1 – Einführung in das Testen von Software

1.1.5 Systemtest, Abnahme und Wartung

lungsprozesses. Er bildet aber ein wesentliches Element des nachstehend be-

1.2 Vorgehensmodelle der Softwareentwicklung

dass solche Rückkopplungen nur zwischen zwei aufeinanderfolgenden Phasen

Kapitel 1 – Einführung in das Testen von Software

1.2.3 Das DSDM-Vorgehensmodell

Die Aktivitäten der einzelnen Phasen können folgendermaßen zusammenge-

Kapitel 1 – Einführung in das Testen von Software

müssen. Ist das Projekt nicht mit dem DSDM-basierten Vorgehensmodell

D 4. Phase: System-Design- und System-Build-Iteration

Kapitel 1 – Einführung in das Testen von Software

Kapitel 1 – Einführung in das Testen von Software

1.3 Qualitätssicherung durch Tests im Rahmen

Der Qualitätssicherungsplan ist dabei eines der wichtigsten Instrumente für

1.3.1 Definition Testen

Kapitel 1 – Einführung in das Testen von Software

werden. Dies ist für die Funktionsüberprüfung des Produktivsystems äußerst

Kapitel 1 – Einführung in das Testen von Software

Kapitel 1 – Einführung in das Testen von Software

Das computergestützte Testen ist umso effizienter, je mehr Testhilfen (Debug-

1.5.1 Definition: CATT – das CASE-Tool

2. CA = Computer Aided, heißt:

Kapitel 1 – Einführung in das Testen von Software

Kapitel 1 – Einführung in das Testen von Software

1.5.5 Ziele von CASE

1.5.6 Vorteile der CASE-Systeme

Kapitel 1 – Einführung in das Testen von Software

Kapitel 1 – Einführung in das Testen von Software

1.6.4 Ziele des Einsatzes von Standardsoftware