Release 1.3 Produktspezifikation

Transkript

1 Release 1.3 Produktspezifikation Dokument Nr. Königsallee Ludwigsburg Germany

2 2

3 Inhaltsverzeichnis Produkteigenschaften...5 Übersicht...5 Produktvarianten...6 savvytest Rational Developer for System z plug-in...6 savvytest SAA...6 Funktionale Anforderungen...7 Einlesen von technischen Strukturbeschreibungen...7 Spezifizieren von technischen Schnittstellen...7 Spezifizieren der fachlichen Sicht auf Schnittstellen...7 Spezifizieren von Testszenarien...8 Spezifizieren von Testsuites...8 Ausführung von Tests...9 Aufbereitung von Testergebnissen...9 Nicht-funktionale Anforderungen...10 Architektur...10 Persistenz...10 Usability...10 Einschränkungen...11 Funktionale Einschränkungen...11 Nicht-funktionale Einschränkungen...11 Liefergegenstände...12 savvytest Rational Developer for System z plug-in...12 savvytest SAA...12 Systemvoraussetzungen...13 Kontakt

4 4

5 Produkteigenschaften Übersicht savvytest wurde entworfen und implementiert, um den Test von Programmschnittstellen auf einem IBM System z Mainframe zu ermöglichen. Um dies zu ermöglichen, transformiert savvytest auf Anforderung technische Strukturbeschreibungen in eine sprach-unabhängige Beschreibung. Unter Verwendung dieser Strukturbeschreibungen können über die Anwenderoberfläche von savvytest technische Schnittstellen definiert werden. Diese beschreiben, welches zu testende Programmmodul mit welchen Strukturen in welcher Reihenfolge aufgerufen werden muss. Die Definition der technischen Schnittstellen kann über die Anwenderoberfläche durch weitere Informationen über die Verwendungsweise der Strukturen und der darin enthaltenen Unterstrukturen und Einzelattribute über die rein technische Sicht hinaus in einen fachlichen Kontext gebracht werden. Auf Basis der definierten Schnittstellen ermöglicht savvytest es, über die Anwenderoberfläche Testszenarien zu erstellen. Testszenarien werden zum einen spezifiziert durch die Angabe von Eingabedaten, also denjenigen Daten, die an das zu testende Programmmodul übergeben werden. Zum anderen durch die Kriterien, die darüber entscheiden, ob ein Test als erfolgreich oder fehlgeschlagen gedeutet wird (sog. Prüfbedingungen). Mehrere solcher Testszenarien können über die Anwenderoberfläche zu einer Testsuite zusammengefasst werden. Von der Anwenderoberfläche kann die Ausführung eines Testszenarios oder einer Testsuite gestartet werden. Die hierfür erforderlichen Definitionen und Daten werden automatisch an die Zielplattform übertragen. Dann wird dort automatisch die Transformation dieser Daten in eine maschinenlesbare Form vorgenommen und die zu testenden Programmmodule aufgerufen. Anschließend werden die Ergebnisdaten aus der maschinenlesbaren Form in die sprachunabhängige Form transformiert und diese Daten auf den Client übertragen. Die Auswertung der Ergebnisdaten anhand der Prüfbedingungen erfolgt maschinell. Das Ergebnis wird in einer lesbar aufbereiteten Form summarisch und im Detail dargestellt. Testergebnisse werden lokal gespeichert und können jederzeit erneut betrachtet werden. 5

6 Produktvarianten savvytest liegt im vorliegenden Release in zwei Produktvarianten vor: savvytest Rational Developer for System z plug-in Bei dieser Produktvariante handelt es sich um ein Plugin für den Rational Developer for System z von IBM. Sie ist speziell darauf zugeschnitten, in dieser Entwicklungsumgebung verwendet zu werden. Dort fügt sie sich nahtlos ein und profitiert unter anderem von der automatischen Übernahme der Daten zur dort bereits konfigurierten Zielplattform. savvytest SAA Bei dieser Produktvariante handelt es sich um eine Standalone-Anwendung mit einer vereinfachten Funktionalität. Sie kann separat installiert werden und zielt speziell auf den technisch weniger versierten Anwender ab. Abhängig von der eingesetzten Variante sind einige Produkteigenschaft nicht oder nur eingeschränkt verfügbar. 6

7 Funktionale Anforderungen Die vorliegende Version setzt im Detail folgende funktionalen Anforderungen um: Einlesen von technischen Strukturbeschreibungen COBOL-Copybooks werden analysiert und in sprach-unabhängige Beschreibungen auf der Basis von XML transformiert (sog. LiStructures). Übernommen wird der Feldname als Attributname, der Datentyp als numerisch oder alphanumerisch, die Vorbelegung mittels der VALUE-Klausel (falls vorhanden) als Vorgabewert. Es ist möglich, mehrere Copybooks in einem Import-Vorgang einzulesen. Das Einlesen von Strukturbeschreibungen auf der Basis anderer Syntax (Programmiersprachen, XML-Schemas o. ä.) ist prinzipiell vorgesehen und kann optional angeboten werden. Diese Anforderungen sind in der Produktvariante savvytest SAA nicht verfügbar, können aber auf Wunsch aktiviert werden. Spezifizieren von technischen Schnittstellen Der Anwender kann eine technische Schnittstelle spezifizieren durch Angabe des zu testenden Programmmoduls (sog. Target) und der gemäß der Programmschnittstelle zur übergebenden Strukturen und deren Reihenfolge. Diese Anforderungen sind in der Produktvariante savvytest SAA nicht verfügbar, können aber auf Wunsch aktiviert werden. Spezifizieren der fachlichen Sicht auf Schnittstellen Der Anwender kann neben dem technischen Namen auch einen fachlichen Namen und eine Beschreibung zur Schnittstelle erfassen. Der Anwender kann für die Strukturen sowie Unterstrukturen und einzelne Attribute deren Verwendungsart einstellen. Verwendungsarten sind: Nur als Eingabe, nur als Ausgabe, sowohl als Ein- als auch als Ausgabe, unveränderbarer Eingabewert. Der Anwender kann für die Attribute deren Vorgabewerte erfassen oder ändern. Diese Anforderungen sind in der Produktvariante savvytest SAA nicht verfügbar, können aber auf Wunsch aktiviert werden. 7

8 Spezifizieren von Testszenarien Der Anwender kann ein Testszenario erstellen, ohne dass hierfür Programmierung oder Scripting erforderlich ist. Der Anwender kann aus den erstellten Schnittstellen diejenige auswählen, für die er ein Testszenario erfassen will. Der Anwender kann neben dem technischen Namen auch einen fachlichen Namen und eine Beschreibung zum Testszenario erfassen. Im Testszenario-Editor werden nur die Erfassung der Eingabedaten relevanten Attribute angezeigt. Dies sind diejenigen mit der Verwendungsarten: Nur als Eingabe, sowohl als Ein- als auch Ausgabe. Der Anwender kann für die angezeigten Attribute Werte erfassen. Bereits erfasste Werte werden bei Datenstrukturänderungen automatisch übernommen, wenn sich der Name des Attributs nicht geändert hat. Der Anwender kann zu Arrays weitere Elemente hinzufügen. Der Anwender kann in einer einfachen Sicht Prüfbedingungen für die Testauswertung hinzufügen, für die das zu prüfende Attribut und ein Vergleichsoperator ausgewählt, sowie ein Vergleichswert erfasst wird. Für die einfache Sicht der Prüfbedingungen kann das zu prüfende Attribut aus den Attributen der Schnittstelle mit folgenden Verwendungsarten ausgewählt werden: Nur als Ausgabe, sowohl als Ein- als auch als Ausgabe. Beim Erstellen neuer Szenarien werden die einfachen Prüfbedingungen mit allen hierfür verwendbaren Attributen vorbelegt. Der Vergleichsoperator für diese Vorbelegungen bewirkt keine Prüfung. Für die einfache Sicht der Prüfbedingungen kann der Vergleichsoperator aus folgenden Operatoren ausgewählt werden: Gleich, ungleich, größer als, kleiner als, größer oder gleich, kleiner oder gleich, Wert unverändert. Zusätzlich wird ein Operator angeboten, der die Prüfung außer Kraft setzt (nicht prüfen). In der komplexen Sicht der Prüfbedingungen können beliebig komplexe Prüfbedingungen auf Basis der Java Expression Language (JEXL) eingegeben werden. Die Anzahl der Prüfbedingungen ist nicht beschränkt. Spezifizieren von Testsuites Der Anwender kann aus den erstellten Testszenarien mehrere Testszenarien auswählen, die in einem Testlauf ausgeführt werden sollen. Das gleiche Testszenario kann auch mehrfach in eine Testsuite übernommen werden. Der Anwender kann neben dem technischen Namen auch einen fachlichen Namen und eine Beschreibung zum Testszenario erfassen. 8

9 Ausführung von Tests Der Anwender kann die Ausführung eines Testszenarios oder einer Testsuite auf der Zielplattform starten. Für die Ausführung relevante Definitionen und Daten werden automatisch auf die Zielplattform übertragen. Die in XML vorliegenden Eingabedaten werden automatisch in eine maschinenlesbare Form überführt. Ist ein Füllbyte angegeben, so werden alle Attribute, für die weder in der Struktur, noch in der Schnittstelle, noch im Testszenario ein Wert hinterlegt ist, vollständig mit dem im Füllbyte angegeben Bytewert befüllt. Die Targets werden automatisch mit den spezifizierten Daten ausgeführt. Die Ausführung eines Testszenarios erfolgt ggf. entsprechend dem REPEAT-Parameter mehrfach, wobei jeweils die originalen Übergabedaten verwendet werden. Die Ausführung kann im Hintergrund erfolgen, so dass der Anwender während dessen anderweitig weiterarbeiten kann. Die Ausgabedaten der Testausführung wird automatisch von der maschinenlesbaren Form wieder in ein XML-Format überführt. Für ungültige Daten wie numerische Daten, deren Speicherinhalt nicht den Spezifikationen des Datentyps entspricht, wird "kein Ausgabe-wert" ("null") ermittelt. Ist ein Füllbyte angegeben, wird für Daten, die vollständig aus dem Füllbyte bestehen, "kein Ausgabe-wert" ("null") ermittelt. Die Ausgabedaten werden automatisch anhand der spezifizierten Prüfbedingungen geprüft. Diese Anforderungen sind in der Produktvariante savvytest SAA nicht verfügbar. Aufbereitung von Testergebnissen Auf Basis der Prüfergebnisse wird automatisch ein Bericht erstellt, der zum einen die Ergebnisse der Prüfung summarisch auf Ebene der Testsuite und auf Ebene der einzelnen Testszenarios darstellt, und zum anderen die einzelnen Ergebnisse der einzelnen Prüfbedingungen. Für jedes Testszenario werden die verwendeten Eingabedaten und die resultierenden Ausgabedaten der Schnittstelle angezeigt. 9

10 Nicht-funktionale Anforderungen Die vorliegende Version setzt ferner im Detail folgende nicht-funktionalen Anforderungen um: Architektur Die Implementierung ist grundsätzlich plattform-unabhängig. Sprach- und plattform-spezifische Implementierung ist in separaten Komponenten isoliert und austauschbar. Persistenz Datenstrukturen, Schnittstellen-Definitionen, Testszenarien, Testsuites, Testausgaben und Testergebnisse werden im Dateisystem gespeichert. Eingabedaten und Ausgabedaten werden in einem XML-basierten Format gespeichert. Usability Dialoge, Views und Editoren sind optisch und in ihrer Verwendung an die Entwicklungsumgebung angepasst. Für den Import von Strukturen sowie für das Anlegen von Test-Schnittstellen, Testszenarios und Testsuites wird mit Hilfe eines Assistenten erleichtert. 10

11 Einschränkungen Folgende Einschränkungen sind aktuell bekannt: Funktionale Einschränkungen Migration von Testdaten: Werte von Attributen, deren Namen sich geändert hat, werden nicht automatisch übernommen. Arrays: Die Anzahl von Array-Elementen kann nicht vom Wert eines anderen Felds abhängig sein; stattdessen werden Array-Elemente, die ausschließlich ihren Initialwert enthalten, als leer angenommen. zrunner: Höchstens 10 Übergabebereiche sind möglich, die Übergabebereiche dürfen eine Länge von 16 MB nicht überschreiten (Compiler-Limit) und die Gesamtlänge aller Bereiche darf 96 MB nicht überschreiten. zrunner: Return-Values (über CALL.. RETURNING) werden nicht unterstützt. zrunner: Targets mit AMODE24 werden nicht unterstützt (Aufruf führt zu einer Exception). Nicht-funktionale Einschränkungen Schriftart und -größe können nicht eingestellt werden. Namen von Eclipse-Projekten dürfen keine Leerzeichen enthalten. Die genannten Einschränkungen werden teilweise in einem späteren Release aufgehoben. Einige Einschränkungen beruhen jedoch auf technischen Einschränkungen, auf die wir keinen Einfluss haben. Eine Eignung für jede denkbare spezielle Konstellation kann nicht zugesichert werden. Unabhängig von diesen Einschränkungen wird der Anbieter weitere an ihn heran getragene funktionale oder nicht-funktionale Anforderungen entgegen nehmen, hinsichtlich des Mehrwerts und der Machbarkeit bewerten und abhängig von dieser Bewertung in der künftigen Entwicklung des Produkts berücksichtigen. 11

12 Liefergegenstände savvytest Rational Developer for System z plug-in savvytest Rational Developer for System z plug-in besteht aus folgenden Liefergegenständen: Plugin für den Rational Developer for System z von IBM Mainframe-Komponenten für die Ausführung unter der System z/uss Mainframe-Komponente für die Ausführung des Targets unter z/os Details sind dem Installation Guide zu entnehmen. savvytest SAA savvytest SAA besteht aus folgenden Liefergegenständen: Windows-Applikation Details sind dem Installation Guide zu entnehmen. 12

13 Systemvoraussetzungen Um das ordnungsgemäße Funktionieren der Software zu ermöglichen, ist weitere Software von unabhängigen Anbietern Voraussetzung. Diese weitere Software ist nicht Bestandteil von savvytest. Benötigt werden auf dem Client Windows XP oder neuer IBM Rational Developer for System z in Version oder neuer Auf dem Mainframe z/os 1.9 oder neuer System z Unix System Services (z/uss) Der RSE-Daemon für den Rational Developer for System z Java oder neuer JzOS oder neuer Details sind dem Installation Guide zu entnehmen. Copyright 2010 by savignano software solutions 13

14 Kontakt Bei Fragen wenden Sie sich bitte an: savignano software solutions Königsallee Ludwigsburg Deutschland Tel / Fax / savvytest@savignano.net 14