Sie sind auf Seite 1von 432

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

Gerhard Oberniedermaier
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


Gerhard Oberniedermaier

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-

Kapitel 1 – Einführung in das Testen von Software


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.

1.2 Vorgehensmodelle der Softwareentwicklung


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.

Kapitel 1 – Einführung in das Testen von Software


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
1.2 Vorgehensmodelle der Softwareentwicklung

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-

Kapitel 1 – Einführung in das Testen von Software


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
1.2 Vorgehensmodelle der Softwareentwicklung

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-

Kapitel 1 – Einführung in das Testen von Software


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
1.2 Vorgehensmodelle der Softwareentwicklung

◗ 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
Modell Implementierung
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.

Kapitel 1 – Einführung in das Testen von Software


◗ 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.

Kapitel 1 – Einführung in das Testen von Software


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 Qualitätssicherung durch Tests im Rahmen des Software-Life-Cycle

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-

Kapitel 1 – Einführung in das Testen von Software


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
1.3 Qualitätssicherung durch Tests im Rahmen des Software-Life-Cycle

◗ 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.

Kapitel 1 – Einführung in das Testen von Software


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-

Kapitel 1 – Einführung in das Testen von Software


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

Kapitel 1 – Einführung in das Testen von Software


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

Kapitel 1 – Einführung in das Testen von Software


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 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-

Kapitel 1 – Einführung in das Testen von Software


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
1.6 Standardsoftware

◗ 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.

Kapitel 1 – Einführung in das Testen von Software


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
2.1 ABAP/4 Development Workbench

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
2.1 ABAP/4 Development Workbench

Ü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

Kapitel 2 – Testumgebung in SAP R/3-Systemen


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
2.1 ABAP/4 Development Workbench

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

Kapitel 2 – Testumgebung in SAP R/3-Systemen


»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
2.1 ABAP/4 Development Workbench

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

Kapitel 2 – Testumgebung in SAP R/3-Systemen


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
2.1 ABAP/4 Development Workbench

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

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
3.2 Genereller Überblick

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
3.2 Genereller Überblick

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
4.1 Das traditionelle SAP-Vorgehensmodell

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


◗ 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
4.1 Das traditionelle SAP-Vorgehensmodell

◗ 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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


◗ 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
4.1 Das traditionelle SAP-Vorgehensmodell

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-

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

Ä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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

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:
◗ Aufbau von Schulungsdaten
◗ 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-

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

◗ 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-

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

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
◗ Aufbau von Schulungsdaten
◗ 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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

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-

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.1 Das traditionelle SAP-Vorgehensmodell

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:

Kapitel 4 – CATT als integrales Element der R/3-Einführung

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:
◗ Projektmanagement
◗ 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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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:
◗ Projektmanagement
◗ 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:
◗ Projektmanagement
◗ 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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


◗ 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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

Machbarkeit

Geschäftsstudie

Funktionale
Modell Implementierung
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 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.

Kapitel 4 – CATT als integrales Element der R/3-Einführung


◗ 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
4.3 Das DSDM-basierte Vorgehensmodell

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

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.

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


(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
4.3 Das DSDM-basierte Vorgehensmodell

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

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


(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!)

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

Phase 5: Einführung/Produktivsetzung
(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 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.

Prototyping-Management
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.

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

Anfänglicher Prototyp

Verfeinerter Prototyp

Konsolidierter Prototyp

Abbildung 4.8
Prototyping-Management

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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

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.

Qualitätsmanagement
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

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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
4.3 Das DSDM-basierte Vorgehensmodell

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.

Kapitel 4 – CATT als integrales Element der R/3-Einführung


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

Kapitel 5 – Allgemeine Funktionen von CATT


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

Kapitel 5 – Allgemeine Funktionen von CATT


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-

Kapitel 5 – Allgemeine Funktionen von CATT


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.

Kapitel 5 – Allgemeine Funktionen von CATT

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

Abbildung 6.1 © SAP AG


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.

Abbildung 6.2 © SAP AG


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.

Abbildung 6.3 © SAP AG


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
Kapitel 6 – Aufbau des CATT-Tools
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
Kapitel 6 – Aufbau des CATT-Tools
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.

Kapitel 6 – Aufbau des CATT-Tools

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

Funktionsname Bedeutung

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
7.2 Spezielle Funktionen von CATT

Prüffunktionen

Funktionsname Bedeutung

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

Kapitel 7 – Funktionen des CATT-Tools


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
7.2 Spezielle Funktionen von CATT

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

Kapitel 7 – Funktionen des CATT-Tools


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
7.2 Spezielle Funktionen von CATT

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:

Kapitel 7 – Funktionen des CATT-Tools


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
7.2 Spezielle Funktionen von CATT

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

Funktion Objekt Text

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.

CHETAB BSEG Belegsegment Buchhaltung

Kapitel 7 – Funktionen des CATT-Tools


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
7.2 Spezielle Funktionen von CATT

Funktion Objekt Text

CHETAB VBRL Vertriebsbeleg: Rechnungsliste

SETVAR &V18 = '00002'

CHETAB VBRL Vertriebsbeleg: Rechnungsliste

SETVAR &V18 = '00003'

CHETAB VBRL Vertriebsbeleg: Rechnungsliste

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.

Funktion Objekt Text

TXT Customizing für Transport

TXT ************************************

TXT Transportart 1 festlegen:

IF &I01 <> ''

SETTAB TVTK Transportarten

ENDIF

TXT Transportart 2 festlegen:

IF &I09 <> ''

SETTAB TVTK Transportarten

ENDIF

TXT Transportart 3 festlegen:

168
Sandini Bib

Funktion Objekt Text

IF &I09 <> ''

SETTAB TVTK Transportarten

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

Kapitel 7 – Funktionen des CATT-Tools


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
7.2 Spezielle Funktionen von CATT

Funktion Objekt Text

SETTAB TROAL Routen: erlaubte Ist-Routen zur Lieferung

Beispiel Nr. 4:
Testbaustein P3005022 SD-Transport: Customizing zurücksetzen

Funktion Objekt Text

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

Funktion Objekt Text

TXT Leerzeile

Beispiel Nr. 5:
Dieser Testbaustein verprobt die Tabelle BSEG (Belegsegment Buchhaltung).

Funkt. Objekt Text

CHETAB BSEG Belegsegment Buchhaltung

CHETAB BSEG Belegsegment Buchhaltung

CHETAB BSEG Belegsegment Buchhaltung

CHETAB BSEG Belegsegment Buchhaltung

CHETAB BSEG Belegsegment Buchhaltung

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

Kapitel 7 – Funktionen des CATT-Tools


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-

Kapitel 7 – Funktionen des CATT-Tools


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

Kapitel 7 – Funktionen des CATT-Tools


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-

Kapitel 7 – Funktionen des CATT-Tools


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

Kapitel 7 – Funktionen des CATT-Tools


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.

Abbildung 7.1 © SAP AG


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.

Kapitel 7 – Funktionen des CATT-Tools


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.

Abbildung 7.2 © SAP AG


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

Abbildung 8.1 © SAP AG


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

Abbildung 8.2 © SAP AG


Statusbildschirm des R/3-Systems

Abbildung 8.3 © SAP AG


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).

Kapitel 8 – Einführung in die Bedienung von CATT


Abbildung 8.4 © SAP AG
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

Abbildung 8.5 © SAP AG


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

Abbildung 8.6 © SAP AG

Kapitel 8 – Einführung in die Bedienung von CATT


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

Abbildung 8.7 © SAP AG


Transaktionsbildschirm – Zahlungsverkehr

Abbildung 8.8 © SAP AG


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.

Kapitel 8 – Einführung in die Bedienung von CATT


Abbildung 8.9 © SAP AG
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

Kapitel 8 – Einführung in die Bedienung von CATT


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.

Abbildung 8.10 © SAP AG


Einstiegsbildschirm von CATT

194
Sandini Bib

Abbildung 8.11 © SAP AG


Funktionsbildschirm von CATT

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.12 © SAP AG


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.

Abbildung 8.13 © SAP AG


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).

Kapitel 8 – Einführung in die Bedienung von CATT


Abbildung 8.14 © SAP AG
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

Abbildung 8.15 © SAP AG


Detailbildschirm von CATT

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.16 © SAP AG


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.

Abbildung 8.17 © SAP AG


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.

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.18 © SAP AG


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.

Abbildung 8.19 © SAP AG


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

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.20 © SAP AG


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

Abbildung 8.21 © SAP AG


Übersicht Importparameter

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.22 © SAP AG


Ü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

Abbildung 8.23 © SAP AG


CATT-Startbildschirm

D Im CATT-Startbildschirm werden nun folgende Felder markiert:


◗ Protokollart: Lang

Kapitel 8 – Einführung in die Bedienung von CATT


◗ 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

Abbildung 8.24 © SAP AG


CATT-Ablaufprotokoll

Abbildung 8.25 © SAP AG


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.

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.26 © SAP AG


Einstiegsbildschirm – Transaktion Kreditor ändern

209
Sandini Bib
8.4 Komplexer CATT-Ablauf

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

Abbildung 8.27 © SAP AG


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

Kapitel 8 – Einführung in die Bedienung von CATT


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
8.4 Komplexer CATT-Ablauf

Abbildung 8.28 © SAP AG


Detailbildschirm – Transaktion Kreditor ändern

Abbildung 8.29 © SAP AG


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.

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.30 © SAP AG


Ü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
8.4 Komplexer CATT-Ablauf

Abbildung 8.31 © SAP AG


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.

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.32 © SAP AG


Attributspflegebildschirm – Testablauf KBC02108

215
Sandini Bib
8.4 Komplexer CATT-Ablauf

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.

Abbildung 8.33 © SAP AG


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

Abbildung 8.34 © SAP AG


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-

Kapitel 8 – Einführung in die Bedienung von CATT


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
8.4 Komplexer CATT-Ablauf

Abbildung 8.35 © SAP AG


Pflegebildschirm Exportparameter – Testbaustein KBC02106

Abbildung 8.36 © SAP AG


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:

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.37 © SAP AG


Startbildschirm – Testablauf KBC02108

219
Sandini Bib
8.4 Komplexer CATT-Ablauf

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:

Abbildung 8.38 © SAP AG


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.
A Menüpfad: WERKZEUGEpABAP/4-WORKBENCH
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

Kapitel 8 – Einführung in die Bedienung von CATT


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
8.4 Komplexer CATT-Ablauf

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.
A Menüpfad: WERKZEUGEpABAP/4-WORKBENCH
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:

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.39 © SAP AG


Übersicht Varianten – Testablauf KBC02108

H Betätigen der Funktion Anlegen.

223
Sandini Bib
8.4 Komplexer CATT-Ablauf

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


A Menüpfad: WERKZEUGEpABAP/4-WORKBENCH
B Menüpfad TESTpTEST WORKBENCHpCATT-ABLÄUFE
C Eingabe folgender Daten in die entsprechenden Felder:

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.

Kapitel 8 – Einführung in die Bedienung von CATT

Abbildung 8.40 © SAP AG


Startbildschirm mit aktivierten Varianten – Testablauf KBC02108

225
Sandini Bib
8.4 Komplexer CATT-Ablauf

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.

Abbildung 8.41 © SAP AG


Ablaufprotokoll zu Testablauf KBC02108 mit Varianten – Teil 1

226
Sandini Bib

Abbildung 8.42 © SAP AG


Ablaufprotokoll zu Testablauf KBC02108 mit Varianten – Teil 2

Externe Varianten
Externe Varianten eröffnen die Möglichkeit, Varianten für die Importparameter

Kapitel 8 – Einführung in die Bedienung von CATT


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


A Menüpfad: WERKZEUGEpABAP/4-WORKBENCH
B Menüpfad: TESTpTEST WORKBENCHpCATT-ABLÄUFE

227
Sandini Bib
8.4 Komplexer CATT-Ablauf

C Eingabe folgender Daten in die entsprechenden Felder:

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:

Kapitel 8 – Einführung in die Bedienung von CATT


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


A Menüpfad: WERKZEUGEpABAP/4-WORKBENCH
B Menüpfad: TESTpTEST WORKBENCHpCATT-ABLÄUFE

229
Sandini Bib
8.4 Komplexer CATT-Ablauf

C Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Testablauf KBC02108

D Ausführen
E Menüpfad: SPRINGENpEXTERNE VARIANTENpEINBINDEN
F Eingabe folgender Daten in die entsprechenden Felder:

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

Protokollart Lang Markieren

Abspielmodus Hell Markieren

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

Abbildung 8.45 © SAP AG


Protokoll zum Testablauf KBC02108 mit externen Varianten

8.5 Pflege von Customizing–Tabellen über


Dynpros bzw. Transaktionen

Kapitel 8 – Einführung in die Bedienung von CATT


8.5.1 Testbaustein anlegen für neue Tabelleneinträge
A Menüpfad: WERKZEUGEpABAP/4-WORKBENCH
B Menüpfad: TESTpTEST WORKBENCHpCATT-ABLÄUFE
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

F Eingabe folgender Daten in die entsprechenden Felder:

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
D Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Transaktionscode 0VA8 (= Automatische Kreditlimitprüfung)

E Positionieren
F Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

KKBR 0001

RKI 001

KG 01

G Weiter mit (¢)

Kapitel 8 – Einführung in die Bedienung von CATT


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
8.5 Pflege von Customizing–Tabellen über Dynpros bzw. Transaktionen

N Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Kurztext Customizingprofil Kreditlimitprüfung


automatisch

Stichwort A020020435

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


A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE
C Kopieren
D Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Testablauf KBC00036

E Kopieren anklicken
F Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Kurztext Customizingprofil Kreditlimitprüfung


automatisch

Stichwort A020020435

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

Kapitel 8 – Einführung in die Bedienung von CATT


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
8.5 Pflege von Customizing–Tabellen über Dynpros bzw. Transaktionen

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


A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE
C Anlegen

236
Sandini Bib

D Im Attributspflegebildschirm sind nun folgende Felder zu füllen:

Felder Daten

Kurztext Customizingprofil Kreditlimitprüfung


automatisch

Stichwort A020020435

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

Kapitel 8 – Einführung in die Bedienung von CATT


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
8.5 Pflege von Customizing–Tabellen über Dynpros bzw. Transaktionen

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


A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE
C Eingabe folgender Daten in die entsprechenden Felder:

Kapitel 8 – Einführung in die Bedienung von CATT


Felder Daten

Testablauf KBC00251

D Ausführen
E Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Protokollart Lang Markieren

Abspielmodus Hell Markieren

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 Sonstige Funktionen

8.6.1 CATT über Komponenten suchen


A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE
C Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Testablauf Taste (F4) drücken

240
Sandini Bib

D Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Applikation SD

Subapplikation BF

Komponente CM

Hinweis: Zum Belegen der Felder Applikation, Subapplikation und Komponente


existieren jeweils (F4)-Hilfen.
E Ausführen
F Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

CATT-Ablauf Markieren

G Auswählen ((¢))

8.6.2 CATT über Funktion/Funktionsvariante suchen


A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE

Kapitel 8 – Einführung in die Bedienung von CATT


C Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Testablauf F4

D Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Stichwort A020020435

E Ausführen

241
Sandini Bib
8.6 Sonstige Funktionen

F Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

CATT-Ablauf Markieren

G Auswählen ((¢))

8.6.3 CATT übersetzen


A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE
C Menüpfad: ÜBERSETZUNG pKURZTEXTE pWEITERE TEXTE pCATT-ABLÄUFE
D Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Einzelobjekt bearbeiten Markieren

E (¢)
F Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

CATT-Ablauf-Nr. KBC00251

Quellsprache D

Zielsprache E

G Übersetzen und Überarbeiten


H Sichern
I Zurück

8.6.4 CATT transportieren


A Menüpfad: WERKZEUGE pABAP/4-WORKBENCH
B Menüpfad: TEST pTEST WORKBENCH pCATT-ABLÄUFE

242
Sandini Bib

C Eingabe folgender Daten in die entsprechenden Felder:

Felder Daten

Testablauf KBC00251

D Transportieren
E Eingabe folgender Daten in die entsprechenden Felder:

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

Kapitel 8 – Einführung in die Bedienung von CATT


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.

Kapitel 8 – Einführung in die Bedienung von CATT


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-

Kapitel 8 – Einführung in die Bedienung von CATT


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

Abbildung 9.1 © SAP AG


CATT-Repository-Informationssystem – Teil1

Kapitel 9 – CATT-Management

Abbildung 9.2 © SAP AG


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:

Abbildung 9.4 © SAP AG


CATT-Statusanalyse – Auswertung Teil 1

Durch Rechtsscrollen wird die in Abbildung 9.4 zu sehende Übersicht vervoll-


ständigt:

256
Sandini Bib

Abbildung 9.5 © SAP AG


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
Kapitel 9 – CATT-Management

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.

Kapitel 9 – CATT-Management

Abbildung 9.6 © SAP AG


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:

Abbildung 9.7 © SAP AG


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

Abbildung 9.8 © SAP AG


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
Kapitel 9 – CATT-Management

(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

Abbildung 9.9 © SAP AG


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

Abbildung 9.10 © SAP AG


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

Abbildung 9.11 © SAP AG


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.

Kapitel 9 – CATT-Management

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.

Kapitel 10 – Verwaltung von CATT-Testfällen


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

Abbildung 10.1 © SAP AG


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

Kapitel 10 – Verwaltung von CATT-Testfällen


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.

Abbildung 10.2 © SAP AG


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

Kapitel 10 – Verwaltung von CATT-Testfällen


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.

Kapitel 10 – Verwaltung von CATT-Testfällen

279
Sandini Bib
10.6 Testpaket zuordnen

Abbildung 10.3 © SAP AG


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.

Abbildung 10.4 © SAP AG


Übersicht der Benutzer des Testpaketes YTESTPAKET1

Kapitel 10 – Verwaltung von CATT-Testfällen


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-

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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.

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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
abgebildet in den CATT-Testbausteinen ZDCE0108, ZDCE0086
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
abgebildet in den CATT-Testbausteinen ZDCE0057, ZDCE0085

292
Sandini Bib

Testdaten

Materialnummer: 10019010090

Werk: DEAA

Prozessauftragstyp: P101

Gesamtmenge: 5000 kg

Zieldatum: Tag des Tests + 1 Tag

e) Transaktion Rückmeldung Prozessauftrag CORK


abgebildet im CATT-Testbaustein ZDCE0058
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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


abgebildet im CATT-Testbaustein ZDCE0085
g) Transaktion WIP-Ermittlung Auftrag KRAX
abgebildet im CATT-Testbaustein ZDCE0086
h) Transaktion Abweichungen Fertigungsauftrag KKS2
abgebildet im CATT-Testbaustein ZDCE0091
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


abgebildet im CATT-Testbaustein ZDCE0050
Testdaten

Auftragstyp: TA

Vertriebsorganisation: DE10

Vertriebsweg: 01

Sparte: 51

Kundennummer: 100263

Materialnummer: 10019010090

Lieferdatum: freie Auswahl

k) Transaktion Anlegen Lieferung VL01


abgebildet im CATT-Testbaustein ZDCE0111
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


abgebildet im CATT-Testbaustein ZDCE0052
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-

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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.

Bedeutung Parametername Vorschlagswert(e)

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:

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


Bedeutung Parametername Vorschlagswert(e)

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:

Bedeutung Parametername Vorschlagswert(e)

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:

Bedeutung Parametername Vorschlagswert(e)

Auftragsnummer &AB_AUFNR Nr. des Prozessauftrags

Periode (Monat) &CO_PERIO 3

Geschäftsjahr &GJAHR 1998

298
Sandini Bib

Testbaustein »WIP-Ermittlung Auftrag« (Transaktion KRAX)


Folgende Importparameter sind hier zu vereinbaren:

Bedeutung Parametername Vorschlagswert(e)

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)


Folgende Importparameter sind hier zu vereinbaren:

Bedeutung Parametername Vorschlagswert(e)

Auftragsnummer &AB_AUFNR Nr. des Prozessauftrag

Geschäftsjahr &YEAR 1998

Periode &PERIOD 3

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


Testbaustein »Ist-Abrechnung: Auftrag« (Transaktion K088)
Folgende Importparameter sind hier zu vereinbaren:

Bedeutung Parametername Vorschlagswert(e)

Auftragsnummer &AB_AUFNR Nr. des Prozessauftrag

Geschäftsjahr &YEAR 1998

Periode &PERIOD 3

Testbaustein »Kundenauftrag anlegen« (Transaktion VA01)


Folgende Importparameter sind hier zu vereinbaren:

Bedeutung Parametername Vorschlagswert(e)

Kundennummer &KUNAG 100263

Lieferdatum &LIEFERDATUM 19980311

Materialnummer &MATNR1 10019010090

299
Sandini Bib
11.1 Testplanung

Bedeutung Parametername Vorschlagswert(e)

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.
Folgende Importparameter sind hier zu vereinbaren:

Bedeutung Parametername Vorschlagswert(e)

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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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

Abbildung 11.1 © SAP AG


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:

Bedeutung Parametername Vorschlagswert(e)

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

Bedeutung Parametername Vorschlagswert(e)

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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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)

SAPMM06E 0121 Positionsübersicht zweizeilig Bestellung

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

SAPMM06E 0121 Positionsübersicht zweizeilig Bestellung

EKPO-EMATN(1) &MATERIAL = 100190

EKPO-MENGE(1) &QUANTITY = 10000

EKPO_NETPR(1) &PRICE = 20

BDC_OKCODE =/00

BDC_CURSOR = EKPO-NETPR(01)

SAPMM06E 0121 Positionsübersicht zweizeilig Bestellung

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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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)

SAPLCTMS 0100 Merkmalbewertung: Klassifikation

BDC_OKCODE = BACK

BDC_CURSOR = RCTMS-MWERT (04)

307
Sandini Bib
11.1 Testplanung

SAPMM07M 0221 Auswahlliste: Wareneingang zur Bestellung

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

SAPMM07M 0221 Auswahlliste: Wareneingang zur Bestellung

BDC_OKCODE = SEUE

BDC_CURSOR = MSEG-ERFMG (01)

SAPMM07M 0221 Auswahlliste: Wareneingang zur Bestellung

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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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)

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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)

SAPLCOMK 5120 Prozessauftrag: Materialliste zweizeilig

BDC_OKCODE = Frei

BDC_CURSOR = RESBD-MENGE(01)

SAPLCOMK 5120 Prozessauftrag: Materialliste zweizeilig

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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


SAPLM610 0135 P1 Auf Komponenten einzeilige Übersicht

BDC_OKCODE = WEIT

BDC_CURSOR = MDPM-ERFMG (01)

SAPLCTMS 0100 Merkmalbewertung: Klassifikation

RCTMS-MWERT(4) = de

BDC_OKCODE = /00

BDC_CURSOR = RCTMS-MWERT (04)

SAPLCTMS 0100 Merkmalbewertung: Klassifikation

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

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


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

SAPMV45A 0400 Auftrag Übersicht zweizeilig

VBAP-MATNR (1) &MATNR1 = 10019010090

RV45A-KWMENG (1) &PRO-QUANTITY = 75

BDC_OKCODE = ENT1

BDC_CURSOR = RV45A-KWMENG (01)

SAPMV45A 0400 Auftrag Übersicht zweizeilig

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)

SAPMV50A 0220 Kommissionierbild

Kapitel 11 – Fallstudie zum praxisnahen Einsatz von CATT


LIPSD-PIKMG (2) &PRO_QUANTITY = 75

BDC_OKCODE = ENT1

BDC_CURSOR = LIPSD-PIKMG (02)

SAPMV50A 0220 Kommissionierbild

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

Abbildung 12.2 © SAP AG


CATT zum Geschäftsprozess »Absatzplanung«

Standard-CATTs
keine

320
Sandini Bib

12.2 Kosten-/Erlösartenbearbeitung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 318ff.].
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

Abbildung 12.4 © SAP AG


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
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 526ff.].
Der Testablauf

YTL_Kreditor (Kreditorenstammbearbeitung)

YBS_FK01

Testbaustein - Pool

Abbildung 12.5
Testablauf zum Geschäftsprozess »Kreditorenstammbearbeitung«

YTL_Kreditorenstammbearbeitung

Abbildung 12.6 © SAP AG


CATT zum Geschäftsprozess »Kreditorenstammbearbeitung«

Standard-CATTs
K1100833, K1101716, K1102364

322
Sandini Bib

12.4 Debitorenstammbearbeitung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 734ff.].
Der Testablauf

YTL_Debitor (Debitorenstammbearbeitung)

YBS_FD01

Testbaustein - Pool

Abbildung 12.7
Testablauf zum Geschäftsprozess »Debitorenstammbearbeitung«

YTL_Debitorenstammbearbeitung

Kapitel 12 – Testabläufe zu Geschäftsprozessen des Referenzmodells

Abbildung 12.8 © SAP AG


CATT zum Geschäftsprozess »Debitorenstammbearbeitung«

Standard-CATTs
K1100477, K1101754

323
Sandini Bib
12.5 Bestellanforderungsbearbeitung

12.5 Bestellanforderungsbearbeitung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 496ff.].
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

Abbildung 12.10 © SAP AG


CATT zum Geschäftsprozess »Bestellanforderungsbearbeitung«

Standard-CATTs
K1102132, K1101501, S1100739, S1100740

324
Sandini Bib

12.6 Materialstammbearbeitung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 504ff.].
Der Testablauf

YTL_Material (Materialstammbearbeitung)

YBS_MM01

Testbaustein - Pool

Abbildung 12.11
Testablauf zum Geschäftsprozess »Materialstammbearbeitung«

YTL_Materialstammbearbeitung

Kapitel 12 – Testabläufe zu Geschäftsprozessen des Referenzmodells

Abbildung 12.12 © SAP AG


CATT zum Geschäftsprozess »Materialstammbearbeitung«

Standard-CATTs
S1100085, P3002913, P3002920, P3002422, P3002435

325
Sandini Bib
12.7 Kundenkontraktbearbeitung

12.7 Kundenkontraktbearbeitung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 698ff.].
Der Testablauf

YTL_Kontrakt (Kundenkontraktbearbeitung)

YBS_VA41 YBS_VA01 YBS_VA41

Testbaustein - Pool

Abbildung 12.13
Testablauf zum Geschäftsprozess »Kundenkontraktbearbeitung«

YTL_Kundenkontraktbearbeitung

Abbildung 12.14 © SAP AG


CATT zum Geschäftsprozess »Kundenkontraktbearbeitung«

Standard-CATTs
K1100336, K1101145, P3004529

326
Sandini Bib

12.8 Fakturabearbeitung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 740ff.].
Der Testablauf

YTL_Faktura (Fakturabearbeitung)

YBS_VF01

Testbaustein - Pool

Abbildung 12.15
Testablauf zum Geschäftsprozess »Fakturabearbeitung«

YTL_Fakturabearbeitung

Kapitel 12 – Testabläufe zu Geschäftsprozessen des Referenzmodells

Abbildung 12.16 © SAP AG


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
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 406ff.].
Der Testablauf

YTL_Stückliste (Materialstücklistenbearbeitung)

YBS_CS01

Testbaustein - Pool

Abbildung 12.17
Testablauf zum Geschäftsprozess »Materialstücklistenbearbeitung«

YTL_Materialstücklistenbearbeitung

Abbildung 12.18 © SAP AG


CATT zum Geschäftsprozess »Materialstücklistenbearbeitung«

Standard-CATTs
S1100068, S1100087, S1100099

328
Sandini Bib

12.10 Arbeitsplatzbearbeitung
Ausführliche Informationen zu den betriebswirtschaftliche Aspekten und den
SAP-spezifischen Besonderheiten sind zu finden in [/Keller98/ 418ff.].
Der Testablauf

YTL_Arbeitsplatz (Arbeitsplatzbearbeitung)

YBS_CR01

Testbaustein - Pool

Abbildung 12.19
Testablauf zum Geschäftsprozess »Arbeitsplatzbearbeitung«

YTL_Arbeitsplatzbearbeitung

Kapitel 12 – Testabläufe zu Geschäftsprozessen des Referenzmodells

Abbildung 12.20 © SAP AG


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
13.2 Testlösungen von Mercury – Executive Summary

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
13.2 Testlösungen von Mercury – Executive Summary

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
13.2 Testlösungen von Mercury – Executive Summary

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
13.2 Testlösungen von Mercury – Executive Summary

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