Testen der Systemumgebung vorbereiten 

Einführung

Es können mehrere unterschiedliche Systeme an einem Geschäftsprozess, den Sie testen wollen, beteiligt sein. Folgendes Szenario dient als Beispiel:

...

       1.      Auf dem ersten System wird ein Kaufauftrag eingegeben.

       2.      Die Bestellung wird zu einem zweiten System weitergeleitet, in dem die Produktion geplant wird.

       3.      Das zweite System leitet die Informationen zu einem dritten System weiter, in dem die Tabelle aktualisiert wird.

Sie wollen die Transaktionen testen und die Tabellenaktualisierung überprüfen. eCATT ermöglicht es Ihnen, die Tests in einem einzigen System durchzuführen und die Tests gegen die verschiedenen Zielsysteme auszuführen.

Gewöhnlich ändern sich die zu testenden Systeme im Laufe der Zeit.Zum Beispiel fangen Sie damit an, eCATT für das Testen eines bestimmten Releases eines zu testenden Systems zu verwenden. Wenn Sie Ihre Tests entwickelt haben, wollen Sie sie vielleicht für spätere Releases des zu testenden Systems wiederverwenden. Durch die Verwendung eines zentralen Testsystems für Ihr Test-Werkzeug und Testobjekte und durch das entfernte Testen der zu testenden Systeme können Sie für die zu testenden Systeme Upgrades vornehmen oder sie sogar austauschen, ohne Ihre Testobjekte zu ändern.

Sie verwenden Systemdaten für die Beschreibung eines (Netzwerk)-Pfades zu einem zu testenden System.

Zentrales Testsystem

Das zentrale Testsystem umfasst:

·        eCATT

·        Ein Repository von eCATT-Objekten (Testskript, Testdatencontainer, Systemdatencontainer und Testkonfigurationen).

·        Protokolle

·        RFC-Destinationen für die Zielsysteme

Die zu testenden Anwendungen befinden sich auf den Zielsystemen. Das zentrale Testsystem kann auch ein Zielsystem sein. Für die Kommunikation mit dem Zielsystem wird RFC verwendet. Je nach Anwendung handelt es sich um eine Typ 3- oder HTTP-Verbindung.

Systemdatencontainer

Die zu testende Systemumgebung wird durch einen Systemdatencontainer repräsentiert.

Der Systemdatencontainer enthält eine Liste von Zielsystemen. Jedes Zielsystem hat Attribute, die den Kommunikationskanal zwischen dem eCATT-System und dem zu testenden System beschreibt. Mögliche Attribute sind RFC-Destinationen vom Typ 3 (Destinationen zu SAP-Systemen) und vom Typ G (HTTP-Destinationen).

Wie andere eCATT-Objekte enthält der Systemdatencontainer obligatorische Attribute (Titel, Paket und Verantwortlicher) sowie Attribute mit Verwaltungsinformationen.

Im Systemdatencontainer wird jeder RFC-Destination ein logischer Name zugewiesen, den Sie selbst angeben. Sie verwenden in den Testskripten den logischen Namen eines Zielsystems, nicht den Namen der RFC-Destination selbst. Aufgabe des Systemdatencontainers ist es, den im Skript verwendeten logischen Namen in jener RFC-Destination (vom Typ 3 oder Typ G) aufzulösen, die ein bestimmtes System identifiziert. Weitere Informationen finden Sie unter Zielsysteme angeben.

RFC-Hinweise

Sie definieren RFC-Destinatinen mithilfe der Transaktion SM59. Dort können Sie die Benutzerdaten angeben, die für die Anmeldung bei den relevanten Systemen erforderlich sind. Wenn die in der RFC-Destination angegebenen Anmeldedaten unvollständig sind, müssen Sie die fehlenden relevanten Informationen gewöhnlich eingeben, sobald ein Test versucht, auf das System zuzugreifen. Das bedeutet, dass Tests nicht unbeaufsichtigt durchgeführt werden sollten, wenn RFC-Destinationen mit unvollständigen Anmeldedaten verwendet werden. Um dieses Problem zu vermeiden, empfiehlt SAP, das zentrale Testsystem zu einem Trusted System von jedem System in der Testumgebung zu machen. Dadurch wird es überflüssig, ein Passwort in der RFC-Destination zu speichern, aber es erlaubt eine unbeaufsichtigte Anmeldung. Informationen über das Anlegen eines Trusted und Trusting System finden Sie im SAP-Hinweis 128447.