Schneller zur Produktivsetzung

Feature | 10. November 2003 von admin 0

Die Einführung, Erweiterung und Aktualisierung komplexer Softwarelösungen, die mehrere Anwendungen, etwa SAP R/3, SAP APO oder Fremdsysteme, über Schnittstellen verbinden, machen Systemintegrationstests erforderlich. Dazu werden üblicherweise komplexe Prüfpläne erstellt. Sie schreiben vor, wie in manuellen Verfahren vorzugehen, zu kontrollieren und zu protokollieren ist. Bei einer Veränderung eines bestehenden Systems, zum Beispiel ein Releasewechsel, Customizinganpassungen oder erweiterte Schnittstellen, verzichten die Betreiber meist auf diese umfangreiche Prozedur. Sie erwarten vielmehr, den Anwendern würden während des täglichen Betriebs eventuelle Schwachstellen schon auffallen. Da aber nicht alle Abläufe gleich intensiv genutzt werden, tauchen Probleme und Fehler manchmal erst spät – zu spät – auf. Dann lässt sich nur sehr schwierig zurückverfolgen, wann und wie die Fehlfunktionen Eingang in das System gefunden haben. Ein Fehler lässt sich also nicht mehr mit einer diesen Fehler verursachenden Veränderung in Zusammenhang bringen. Dieses Manko führt zu einem sehr hohen Aufwand bei der Fehlersuche, zu Frustration und gegenseitigen Schuldzuweisungen. Darum wünschen die Anwender komplexer Software automatisierte Verfahren, die jeweils nach einer Veränderung oder auch in regelmäßigen Abständen die Systeme prüfen.

OR Soft nutzt innerhalb der von ihr durchgeführten SAP R/3- und SAP APO-Projekte automatisierte Tools. Sie kontrollieren, ob die Abbildung eines Modells in beiden Systemen, in SAP R/3 und SAP APO, adäquat ist, ob die wichtigsten Abläufe zuverlässig funktionieren und beide Systeme bezüglich der Bewegungsdaten synchron sind.

Systemveränderungen auf dem Prüfstand

Die Integrationstexts werden nicht innerhalb der zu testenden Software SAP R/3 und SAP APO durchgeführt, sondern außerhalb auf einer von OR Soft eingerichteten Testsuite. Die Testsuite ist ein Add-On zu den führenden Systemen ohne eigene Datenhaltung, aber mit beiden Anwendungen über Standardtransaktionen schreibend und lesend verbunden. Sie errichtet einen lokalen LiveCache, um die Modelle aus beiden Systemen zusammen zu führen. Die Testsuite als externes Add-On erlaubt eine Beschreibung des Testgegenstands unabhängig von der konkreten Modellierung. Damit lassen sich die Tests ohne den Einfluss von Systemveränderungen reproduzieren.
Was und wie im Einzelnen getestet werden soll, beschreibt und definiert das prüfende Fachpersonal in einem Testscript. Testscripts und die gewonnenen Testergebnisse lassen sich systemunabhängig speichern. Die Dokumentation erlaubt jederzeit eine genaue Wiederholung dieser Tests. Nach vollzogenen Veränderungen am System führt also der Vergleich der ursprünglichen Testergebnisse mit den neu gewonnenen zu eindeutigen Hinweisen.
Für die Tests werden die benötigten Daten aus SAP R/3 und SAP APO geladen, beziehungsweise von der Testsuite in SAP R/3 und SAP APO erzeugt.
Die aus den Quellsystemen geladenen Datenobjekte landen im LiveCache des PCs, um dort miteinander oder mit vorgegebenen Sollwerten verglichen und protokolliert zu werden. Die Tests können automatisiert im Hintergrund ablaufen. Das Protokoll ist so konfigurierbar, dass es nur Auffälligkeiten oder Abweichungen erfasst.

Testfall “Produktionsmodell”

Testsuite

Testsuite

An zwei Beispielen lässt sich das Verfahren der automatisierten Systemstests erläutern. Das erste Beispiel betrachtet, wie unterschiedliche Customizing-Einstellungen und Modellierungen bei der Planung in SAP APO und SAP R/3 zu unterschiedlichen Ergebnissen führen. Wenn die Terminierung der Aufträge in beiden Systemen unter allen Bedingungen übereinstimmt, gilt das als Indiz für eine korrekte Modellierung. Im Einzelnen geht es um den Nachweis, dass Production Process Models (PPMs) im SAP APO richtig modelliert sind, wesentliche Customizing-Einstellungen modelltechnisch einwandfrei vorgenommen wurden und zu den SAP R/3-Einstellungen passen.
Dazu läuft eine besondere Prüfroutine ab. Sie umfasst mehrere Verarbeitungsschritte und simuliert die Wochenenden und Arbeitspausen durch Schichtregimes. Zunächst werden alle PPMs nacheinander automatisch als Aufträge technologisch zulässig eingeplant, anschließend um sechs mal 24 Stunden verschoben – um Wochenendeffekte zu testen –, im Rahmen der gültigen Losgröße vergrößert (um den Faktor 2 skaliert), wieder zurück verschoben und abschließend um den gleichen Skalierungsfaktor geschrumpft. Parallel dazu beobachten die Systemtests das Verhalten des dazu gehörigen Prozessauftrages im SAP R/3. Dort sollten, selbst bei nicht übereinstimmender Modellierung, zumindest die Start- und Endzeiten des entsprechenden Prozessauftrages übereinstimmen. Wenn alle Operationen nacheinander ausgeführt wieder die ursprüngliche Ausgangssituation erreichen, liefert das automatisch ein Indiz (gemäß einer in der Mathematik definierten “notwendigen Bedingung”) für die Korrektheit der Einstellungen. Treten jedoch Abweichungen auf, wurde entweder formal nicht korrekt modelliert, oder aber die Customizing-Einstellungen sind bezüglich Nichtarbeitszeit oder Einlaststrategien fehlerhaft.

Testfall “Bestandsentwicklung in der Zukunft”

Test "Produktionsmodell"

Test "Produktionsmodell"

Im zweiten Beispiel ist die Übereinstimmung zu prüfen zwischen Materialbedarfs- und Bestandslisten in SAP APO und SAP R/3 einerseits und den vergleichbaren Dispo-Elementen andererseits. Es gilt zu prüfen, ob die Zukunft bezogen auf die Bestandssituation in beiden Systemen trotz der höheren Planungsgenauigkeit von SAP APO gegenüber SAP R/3 gleich abgebildet ist. Dazu vergleicht die Prüfroutine für eine Planungssituation alle Materialbedarfs- und Bestandslisten hinsichtlich der gemeinsamen Auftragskategorien (Planauftrag, Prozessauftrag, Kundenbedarf, Vorplanbedarf). Stimmen die Eckdaten und korrespondierenden Elemente überein, so ist gesichert, dass Planung und Rückmeldung in beiden Systemen nicht zu widersprüchlichen Informationsgehalten in den verbundenen Systemen führen.

Simulation extremer Situationen

Nicht zu unterschätzen ist auch der psychologische Wert der Tests. Eine Veränderung am System löst häufig Ungewissheit unter den Anwendern aus. Ein Eingriff, so lauten die Vermutungen, werde sehr wahrscheinlich Fehler verursachen, die irgendwann im laufenden Betrieb zu Tage treten könnten. Dem bauen die Systemtests vor. Sie sind in der Lage, auch gegenüber den Anwendern stabile Lösungen zu demonstrieren. Das erhöht die Nutzerakzeptanz, entlastet die IT und verkürzt Einführungs- und Updatezeiten.
Ähnliches gilt für kundenspezifische Anpassungen. Die Tests prüfen schnell und sicher die Funktionsfähigkeit der Abläufe und die Algorithmen bei Softwareänderungen. Bei großen Datenmengen, die manuell nicht zu bewältigen wären, und bei extremen Situationen, etwa sehr lange Transaktionen oder hohe Schnittstellenbelastung, liefern sie bereits in frühen Projektphasen nützliche Erkenntnisse. Wenn sie das Verhalten der Anwender simulieren, zum Beispiel gleichzeitige Planungsaktionen von verschiedenen Anwendern, rechenintensive Reihenfolgeoptimierung, Rückmeldung von vielen Aufträgen, sind gesicherte Vorhersagen über das Laufzeit- und Speicherbedarfsverhalten der Software möglich.
Schließlich eignen sich Systemtests auch für Abnahmeprozeduren, um eine Software und die einem Kunden zugesagten Leistungsparameter auf den Prüfstand zu stellen. Ebenso lassen sich in einem Softwareeinführungsprojekt Programmierfehler, Konzeptfehler und mangelnde Datenqualität schnell erkennen.
Bisher hat OR Soft diese Tests im Rahmen verschiedener eigener SAP APO- und SAP R/3-Projekte angewandt und dadurch die Aufwendungen für die Systemintegration reduziert. Mittlerweile ist die Testsuite so ausgeprägt, dass sie als unabhängiges Softwaretool von den IT-Abteilungen für die permanente Qualitätskontrolle und Integrationssicherung verwendet werden kann.

Dr. Winfried Jänicke

Dr. Winfried Jänicke

Dirk Schmalzried

Dirk Schmalzried

Leave a Reply