SoftwareLoft Testing Suite. Schnelleinstieg

Transkript

1 SoftwareLoft Testing Suite Schnelleinstieg SoftwareLoft IT-Solutions GmbH SL Testing Suite, Schnelleinstieg Version

2

3 IMPRESSUM 2009 SoftwareLoft IT-Solutions GmbH Dammtorstraße Hamburg Telefon: products@softwareloft.de Internet: Alle Rechte vorbehalten. Kein Teil des Handbuches oder der darin beschriebenen Software darf in irgendeiner Form ohne vorherige schriftliche Genehmigung der SoftwareLoft IT-Solutions GmbH reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Schutzrechte. Einige der in diesem Handbuch verwendeten Bezeichnungen unterliegen Warenzeichen-, Marken- oder patentrechtlichem Schutz.. Nicht alle eingetragenen Warenzeichen und Gebrauchsmuster sind in diesem Handbuch ausdrücklich als solche gekennzeichnet. Daraus kann nicht geschlossen werden, dass die betreffenden Bezeichnungen frei sind oder frei verwendet werden können. Haftungsausschluss. Dieses Handbuch und die darin beschriebene Software wurdem mit größter Sorgfalt erstellt. Es kann jedoch keinerlei Gewähr für die Fehlerfreiheit der Software, der mitgelieferten Daten sowie des Handbuchs übernommen werden. Insbesondere haftet die SoftwareLoft IT-Solutions GmbH nicht für Schäden insbesondere nicht für unmittelbare oder mittelbare Folgeschäden, Datenverlust, entgangenen Gewinn, System- oder Produktionsausfälle, die auf die Anwendung der in diesem Handbuch beschriebenen Software oder auf Fehler in der Dokumentation zurückgeführt werden können. Da die in diesem Dokument beschriebene Software kontinuierlich weiterentwickelt wird, können die beschriebenen Sachverhalte und Vorgehensweisen unter Umständen von der installierten Software abweichen. Gern nehmen wir Anregungen unter der -Adresse products@softwareloft.de entgegen. Schnelleinstieg Seite 3

4

5 INHALT Über dieses Dokument Systemübersicht Die Aufgabe Die Vision Das Werkzeug Die Vorgehensweise Grundlegende Konzepte Das zu testende System Das Testprojekt Die Testablaufbeschreibungen Die Testdaten Die Testausführung Die Rollen Die Bedienung Testen eines Systems Vorbereitung Testprojekt anlegen Verbindung zu den Applikationen herstellen Test Environment definieren Installationen beschreiben Testabläufe beschreiben Testsuite anlegen Testdaten erstellen Testfälle erstellen Tests ausführen Weiterführendes Beispiel Aufbereitung von Testdaten...65 Glossar Index Abbildungsverzeichnis Schnelleinstieg Seite 5

6

7 ÜBER DIESES DOKUMENT Inhalt Dieses Dokument beschreibt die grundlegenden Konzepte der SL Testing Suite in der Version 1.x und erläutert anhand eines Beispiels Vorbereitung und Durchführung von Systemtests mit der SL Testing Suite. Informationen zur Installation der Software sind in dem mit der Software ausgelieferten Installationshandbuch zu finden. Weiterführende Informationen hält die Programm-Hilfe bereit. Aufbau Abschnitt 1 Systemübersicht gibt einen Überblick über das Einsatzgebiet und die grundlegenden technische Eigenschaften der SL Testing Suite. Abschnitt 2 Grundlegende Konzepte erläutert die Philosophie und Terminologie der SL Testing Suite und führt in grundlegende Bedienkonzepte ein. Abschnitt 3 Testen eines Systems erklärt die einzelnen Bedienschritte und führt anhand eines kompletten Beispiels von der Testvorbereitung bis zur Testausführung. Der Schnelleinstieg beschränkt sich dabei auf die grundlegenden Funktionen. Das Leistungsspektrum der SL Testing Suite ist wesentlich umfangreicher und wird durch die Programm-Hilfe erschlossen. Typografische Hinweise Fettdruck kennzeichnet an den Stellen, an denen diese erläutert werden Begriffe aus der Terminologie der SL Testing Suite und zum Teil auch wichtige Stichworte eines Absatzes. Elemente der grafischen Bedienoberfläche sind darüber hinaus in der Schriftart Arial gesetzt. Menüeinträge sind in der Form Hauptmenüpunkt > Untermenüpunkt > weiterer Menüpunkt oder Reiter dargestellt. Erläuternde Beispiele sind grau hinterlegt. Programmcode und Dateinamen sind in der Schriftart Courier gesetzt. Schnelleinstieg Seite 7

8

9 1 SYSTEMÜBERSICHT 1.1 Die Aufgabe Die erfolgreiche Entwicklung komplexer Software-Systeme ist undenkbar ohne eine aufmerksame Planung der Tests, die jeden Schritt der Softwareentwicklung begleiten. Aktuelle Paradigmen in der Softwaretechnik wie Testgetriebene Entwicklung (Test-Driven Development, TDD) machen, indem sie nicht nur die Testplanung sondern sogar die Tests an den Anfang des Implementierungsprozesses stellen, deutlich, wie notwendig Tests in der Softwareentwicklung sind. Unabhängig davon, wie frühzeitig im Entwicklungsprozess Tests beginnen: Vor einer Produktivstellung oder einer Auslieferung eines Software-Systems stellt sich immer die Aufgabe, das Gesamtsystem in einer Umgebung, die die Produktivumgebung möglichst genau abbildet, einem Systemtest zu unterziehen und zur Revisionssicherheit Tests und Testergebnisse zu dokumentieren. Komplexe Software-Systeme kommen nicht umhin, das Zusammenspiel ihrer Teile (Applikationen, Komponenten) in einem Integrationstest unter Beweis zu stellen. Dabei werden Teilsysteme, die ihre jeweiligen Unit-Tests erfolgreich bestanden haben, mit Umsystemen (oder für den Test aufgebauten Attrappen derselben) und Mocks von noch nicht fertiggestellten Komponenten zusammengebracht und Tests unterzogen, die sicherstellen, dass der Datenaustausch zwischen den Komponenten fehlerfrei arbeitet, gemeinsame Schnittstellen spezifikationsgemäß funktionieren und die Datenverarbeitung im Gesamtsystem korrekte Ergebnisse liefert. Aussagekräftige und qualitätssichernde System-, Integrations- und Regressionstests von Software-Entwicklungen erfordern einen zeitlichen Aufwand, der für komplexe Systeme nicht ohne Automatisierung zu bewältigen ist. Eine erfolgreiche Kontinuierliche Integration (Continuous Integration) kann ohne Testautomatisierung gar nicht realisiert werden. Dies ist Ausgangspunkt für die Vision, die zur Entwicklung der SL Testing Suite führte. Schnelleinstieg Seite 9

10 1.2 Die Vision Die SL Testing Suite entstand aus dem Wunsch nach einer leicht handhabbaren Test-Umgebung ähnlich dem JUnit-Framework für Unit-Tests für den Integrationstest komplexer Software-Systeme unter Einbeziehung ihrer Umsysteme. Teststrategien für Integrationstests mit Umsystemen und für Regressionstests können mit der SL Testing Suite von Fachexperten per Mausklick definiert, Testdaten als Excel-Sheet oder als XML-Dateien angelegt und gepflegt werden. Kenntnisse über Implementierungsdetails (Schnittstellenformate) sind dafür nicht erforderlich. Umfangreiche Testszenarien können dokumentiert und versioniert abgelegt werden. Die Testdurchführung kann automatisiert, z. B. im Rahmen der Kontinuierlichen Integration, oder über die Bedienoberfläche angestoßen werden. Die SL Testing Suite kann als zentrales Testwerkzeug für eine Vielzahl von unterschiedlichen Systemen agieren. Alle notwendigen Konfigurationsdaten (Nutzerkennungen, Datenbankverbindungen, Rechnernamen, etc.), um konkrete Installationen eines Systems zu testen, werden von der SL Testing Suite verwaltet. Parallele Installationen (z. B. von einem System in verschiedenen Versionsständen) können auf einfachste Art und Weise identischen Tests unterworfen werden. Ebenso problemlos lassen sich unterschiedliche Systeme, die auf gleichen oder ähnlichen Daten arbeiten, in ihrem Verhalten vergleichen. Den Entwicklungsprozess eines komplexen Systems kann die SL Testing Suite durch datengetriebene Tests begleiten und so die Erfüllung von Anforderungen sicherstellen. Zulieferungen können mit der SL Testing Suite auf die Einhaltung von Schnittstellenvereinbarungen geprüft werden. 1.3 Das Werkzeug Die SL Testing Suite nutzt die weit verbreitete, plattformunabhängige integrierte Entwicklungsumgebung Eclipse. Als Eclipse Plug-in stellt sie den Nutzern eine vertraute Bedienoberfläche zur Verfügung. Testabläufe und Testdaten können über die Bedienoberfläche definiert, editiert und dokumentiert werden. Gemeinsam mit Konfigurationsdaten können diese in Testprojekten strukturiert und versioniert abgelegt werden. Die so erstellten Tests lassen sich über die Bedienoberfläche starten, zeitgesteuert über einen Test-Scheduler oder als eine Task im Build-Prozess. Das Reporting erfolgt in der Bedienoberfläche oder als HTML- bzw. XML-Dokument. Seite 10 SL Testing Suite

11 Das zu testende System, das aus mehreren Applikationen bestehen kann, und ggf. notwendige Mock-Systeme (Attrappen für Umsysteme) werden in der Testausführung in einen definierten Ausgangszustand versetzt und dann über die System-Schnittstellen (Datenbank, Message Queue, Service, Dateien) mit Testdaten befüllt. Verarbeitungsergebnisse können an den Systemschnittstellen abgeholt und überprüft werden. Alle Eingangsdaten für die Tests und Vergleichsdaten für die Verarbeitungsergebnisse können vom Benutzer unabhängig von dem Format der jeweiligen Schnittstelle als Excel-Datenblätter oder XML-Dateien editiert und für unterschiedliche Testabläufe genutzt werden. Die Testabläufe können modular aufgebaut und in verschiedenen Testszenarien genutzt werden. Einen Überblick über die möglichen Komponenten im Testaufbau gibt Abbildung 1. Neben dem zu testenden System und der SL Testing Suite können Mock-Systeme und ggf. Steuerungsprogramme für die Testausführung an dem Aufbau eines Integrationstests beteiligt sein. Abbildung 1: Übersicht über die Komponenten in der Testumgebung. Schnelleinstieg Seite 11

12 1.4 Die Vorgehensweise Vorbereitung und Durchführung von Integrationstests mit der SL Testing Suite lassen sich grob in drei Schritte gliedern: 1. Einrichten der Testumgebung und der SL Testing Suite 2. Auswahl des zu testenden Systemverhaltens 3. Testfälle inkl. zugehöriger Testdaten anlegen und ausführen. Schritt 1: Wie bei jedem Systemtest ist zunächst das zu testende System in einer Testumgebung, die ggf. Umsysteme oder Mocks bereit stellen muss, zu installieren. Die Installation und die äußeren Schnittstellen des zu testenden Systems sind in der SL Testing Suite in einem Testprojekt zu beschreiben. Ggf. müssen Konverter für bestimmte Schnittstellen definiert werden, damit diese via Excel befüllt und abgefragt werden können. Schritt 2: Testabläufe kann der Test-Architekt dann in der grafischen Bedienoberfläche definieren. Ein gebräuchliches Muster für Testabläufe ist die Sequenz Setup (Vorbereitung, Initialisierung des Tests), Operation (Verarbeitungsanweisung, die aus mehreren Schritten bestehen kann), Assert (Prüfung der Verarbeitungsergebnisse). Schritt 3: Aufbauend auf der Dokumentation, die der Test-Architekt in das Testprojekt stellt, kann der Test-Autor Testfälle anlegen und diese ausführen. Sowohl Eingangsdaten für die Tests als auch Vergleichsdaten für die Prüfung sind komfortabel via Excel erstellbar oder ggf. auch aus dem System extrahierbar. Dafür muss der Test-Autor ausschließlich sein Wissen über die Domäne einsetzen; Kenntnisse über den softwaretechnischen Hintergrund des zu testenden Systems sind nicht erforderlich. Idealerweise wird eine Systementwicklung durch kontinuierliches Testen begleitet. Testprojekte lassen sich deshalb einfach modifizieren und erweitern, so dass auch die einzelnen Schritte zum Testaufbau mehrfach zu bearbeiten sind, z. B. wenn neue Verfahren im System fertiggestellt sind oder weitere Schnittstellen hinzukommen. Das Testprojekt kann so gemeinsam mit der entwickelten Anwendung wachsen. Die SL Testing Suite bietet die Möglichkeit, Testprojekte zu versionieren (konsistent mit Entwicklungs- oder Auslieferungsständen des zu testenden Systems), verschiedene Installationen zu verwalten (für unterschiedliche Plattformen, auf denen das System läuft) und Tests automatisiert auszuführen (z. B. für die Testausführung im Rahmen der Kontinuierlichen Integration). Seite 12 SL Testing Suite

13 2 GRUNDLEGENDE KONZEPTE 2.1 Das zu testende System Aus der Sicht der SL Testing Suite besteht ein zu testendes System (system under test, SUT) aus einer Menge von Datensenken, über die das SUT Daten entgegennehmen kann, und einer Menge von Datenquellen, an die das SUT Daten übergibt. An die Datensenken kann die SL Testing Suite Daten liefern; an den Datenquellen kann sie Daten lesen, diese speichern und überprüfen. Datenquellen und Datensenken werden in der Terminologie der SL Testing Suite Komponenten (component) genannt. Eine Komponente kann gleichzeitig Datenquelle und -senke sein. Gängige Komponenten sind u a. Datenbanken, Message Queues, Dateischnittstellen und EJBs. Sie sind Teile des zu testenden Systems, das ohne Bezug auf eine konkrete Installation Test Environment genannt wird. Ein Test Environment kann aus einer oder aus mehreren Applikationen (application) bestehen, von denen jede wiederum potentiell mehrere Komponenten (Datenbank, Queues, EJBs, etc.) enthalten kann. Abbildung 2: Schematische Darstellung des zu testenden Systems. Alle Komponenten, die in Tests mit Daten befüllt oder deren Daten geprüft werden sollen, werden über sogenannte Konnektoren (connector) an die SL Testing Suite angebunden. Weitere Informationen zu den Konnektoren liefert Abschnitt Schnelleinstieg Seite 13

14 Die Konnektoren stellen mögliche Operationen auf den Komponenten (z. B. Insert für Datenbank-Komponenten oder Write für Dateischnittstellen) zur Verfügung. Diese Operationen werden Component Steps genannt. Sie bilden die Basis für die Definition von Testabläufen und stellen damit die Verbindung zwischen Testdaten und dem zu testenden System her. Informationen zu Testabläufen liefert Abschnitt 2.3. Ein zentrales Konzept der SL Testing Suite ist es, dem Benutzer alle Test- und Prüfdaten für die unterschiedlichen Komponenten in einem einheitlichen Format als sogenannte Datasets zugänglich zu machen. Datasets können mit Excel oder als XML-Dateien editiert werden. Weitere Informationen zu den Datasets liefert Abschnitt 2.4. Die wichtigsten Component Steps lesen Testdaten im Dataset-Format und geben diese an ihre Komponente weiter oder lesen Daten aus der Komponente und vergleichen diese mit Prüfdaten. Die Konvertierung der Datasets in die Formate der einzelnen Komponenten übernehmen Konverter (converter). Weitere Informationen zu den Konvertern liefert Abschnitt Das Test Environment nimmt noch keinen Bezug auf eine konkrete Installation des zu testenden Systems. In der SL Testing Suite werden konkrete Installationen (installation) beschrieben als eine Sammlung von Locations. Eine Location hält jeweils die installationsabhängigen Parameter (Datenbank-Connection, Zugangsdaten, Rechnernamen, etc.) einer Applikation. Informationen zur Beschreibung der Installationen liefert Abschnitt 3.5. Seite 14 SL Testing Suite

15 2.2 Das Testprojekt Die SL Testing Suite hält alle Daten für die Testausführung in Testprojekten. Im Allgemeinen sollte für jedes zu testende System ein Testprojekt angelegt werden. Ein Testprojekt beinhaltet folgende Teile: Beschreibung des zu testenden Systems Testdaten Testabläufe Testfälle. Die Beschreibung des zu testenden Systems erfolgt wie in Abschnitt 2.1 dargelegt über das Test Environment (mit den Applikationen und deren Komponenten) und die Installationen. Testdaten - sowohl Eingangsdaten für Tests (input-dataset) als auch Prüfdaten (expected-dataset) werden in einem einheitlichen Format (unabhängig von der konkreten Schnittstelle) als Datasets beschrieben. Das Format der Datasets ist in Abschnitt 2.4 dargelegt. Testablaufbeschreibungen werden als sogenanntes Verhalten (Behavior) modelliert. Ein Behavior besteht aus einer Menge von Schritten, die Behavior Calls genannt und sequenziell ausgeführt werden. Behaviors können modular (aus zuvor definierten, wiederverwendbaren Behaviors) aufgebaut werden. Die feinste Ebene der Interaktion mit Komponenten bilden die über den Konnektor bereitgestellten Operationen (Component Steps). Detaillierte Informationen zu Testabläufen liefert Abschnitt 2.3. Testablaufbeschreibungen und Testdaten werden in sogenannten Testfällen zusammengebracht. Zu einem Testfall (Testcase) gehören: Name zur eindeutigen Identifizierung eine Testablaufbeschreibung (Behavior) Testdaten, evtl. mit Parametrisierung zur Datenaufbereitung (z.b. Filterung). In einer Testsuite werden Testfälle für eine gemeinsame Ausführung gruppiert. Eine Testsuite ist eindeutig einem Test Environment zugeordnet; weitere Einschränkungen für das Gruppieren von Testfällen gibt es nicht. Als Extreme können alle Testfälle für ein zu testendes System in einer Testsuite zusammengefasst oder für jeden Testfall eine eigene Testsuite erstellt werden. In der Praxis sollte eine Testsuite eingesetzt werden, um Testfälle übersichtlich zu strukturieren. Die Testfälle in einer Testsuite sollten daher eine Gemeinsamkeit Schnelleinstieg Seite 15

16 haben, die sich idealerweise im Namen der Testsuite widerspiegeln sollte. Typischerweise ist dies ein gemeinsamer Testablauf oder Variationen eines Ablaufs. Das Anlegen einer Testsuite beschreibt Abschnitt 3.7. Testfälle können ausschließlich über eine Testsuite angelegt werden. Das Verfahren ist beschrieben in Abschnitt 3.9. Das folgende Klassendiagramm gibt einen Überblick über die Struktur eines Testprojekts. Das Anlegen eines Testprojekts beschreibt Abschnitt 3.2. Abbildung 3: Bestandteile eines Testprojekts in UML-Darstellung. Oberste Strukturelemente in einem Testprojekt sind die Testsuites. Eine Testsuite wird immer für genau ein Test Environment erstellt. Ein Test Environment kann aus einer oder mehreren Applikationen (Application) bestehen. Eine Application besteht aus Components, die über bestimmte Operationen (Component Steps) verfügen. Für das Test Environment enthält die Testsuite eine beliebige Anzahl von Testfällen (Testcases). Ein Testcase testet genau ein Behavior mit der notwendigen Menge von Datasets als Testdaten. Ein Behavior besteht aus BehaviorCalls. Ein BehaviorCall kann ein Component Step oder ein Complex Behavior sein (weitere Möglichkeiten, s. Abschnitt 2.3, sind aus der Darstellung ausgeklammert). Ein Complex Behavior ist ein Behavior, das ein anderes Behavior als Behavior Call enthält. Seite 16 SL Testing Suite

17 2.3 Die Testablaufbeschreibungen Testablaufbeschreibungen können unabhängig von konkreten Ein- und Ausgangsdaten modelliert und damit für verschiedene Testfälle (Testcases) genutzt werden. Ein typischer Testablauf besteht aus den Schritten Setup versetzt das zu testende System in einen definierten Ausgangszustand. Das Auslösen einer oder mehrerer Operationen auf dem zu testenden System (z. B. durch Aufruf eines Services oder Senden einer Message) Im Assert wird der Systemzustand nach der Testausführung mit dem erwartetem Zustand verglichen. Stimmen der aktuelle Systemzustand und der erwartet Zustand nicht überein, wird der Test mit einer Fehlermeldung abgebrochen. Weitere Operationen und Asserts können folgen. Testabläufe heißen Behavior (Verhalten) und sind als eine Sequenz von Behavior Calls aufzubauen. Es gibt vier verschiedene Arten von Behavior Calls: Ein Complex Behavior ist ein Behavior, das ein zuvor definiertes anderes Behavior als Behavior Call enthält. Behaviors können so zu einem komplexeren Verhalten zusammengesetzt werden. Ein Component Step ist ein einzelner (atomarer) Verarbeitungsschritt einer Komponente. Welche Component Steps eine Komponente bereitstellt, wird durch diese bestimmt. Ein Environment Step ist eine Aktion/Operation, die auf der Testumgebung ausgeführt wird. Ein Testdata Step ist ein Verarbeitungsschritt, der auf Testdaten (Dataset) ausgeführt wird. Die Component Steps werden durch das Anbinden einer Komponente mit einem Konnektor bereitgestellt. Folgende Konnektoren stellt die SL Testing Suite im Package com.softwareloft.test.runtime.connector.impl standardmäßig bereit: JdbcConnector EjbConnector JmsConnector WMQConnector WebServiceConnector für den Zugriff auf Datenbanken über JDBC für EJBs (Enterprise Java Bean) für JMS-Provider mit Lookup über JNDI für Websphere MQ mit nativem Lookup aber Zugriff über JMS für SOAP-basierte WebServices Schnelleinstieg Seite 17

18 FileConnector ShellConnector PojoConnector für Dateischnittstellen für Shell-Befehle für den direkten Zugriff auf Java-Klassen (Plain Old Java Object) Weitere Konnektoren können implementiert werden. Component Steps können Parameter besitzen, die ein Dataset erwarten. Die Component Steps können darüber Daten an die Komponente liefern (z. B. Datenbank-Insert), Daten aus der Komponente lesen (z. B. Datenbank-Export) und ggf. prüfen (assert). Die Dataset-Parameter dieser Component Steps heißen: input output Das Dataset dient als Datenquelle für die Komponente. Beispiel: Insert in eine Datenbank. Das Dataset erhält Daten von einer Komponente. Beispiel: Select aus einer Datenbank. expected Das Dataset enthält Prüfdaten, die mit aktuellen Systemdaten zu vergleichen sind. Die folgende Tabelle zeigt eine Auswahl an Component Steps für einige Konnektoren. Die Dataset-Parameter sind in Klammern (input, output, expected) angegeben. Für die vollständige Dokumentation der Konnektoren, Component Steps und deren Parameter ist die Programm-Hilfe zu konsultieren. Component Step Funktion JdbcConnector für Datenbanken assertdata assertequals cleaninsert delete vergleicht Datenbankeinträge mit Prüfdaten (expected). Es werden nur diejenigen Spalten und Tabellen in den Vergleich mit einbezogen, die in den erwarteten Daten enthalten sind. Optional können die aktuellen Datenbankeinträge (output) in eine Datei geschrieben werden. arbeitet analog zu assertdata; es wird jedoch auf exakte Gleichheit der Daten verglichen. Insbesondere müssen die tatsächlichen Daten genau die gleichen Tabellen und Spalten enthalten wie die erwarteten Daten und die Reihenfolge der Zeilen ist relevant. stellt Daten (input) in die Datenbank und leert zuvor die betroffenen Tabellen. löscht Daten (input) aus der Datenbank. Seite 18 SL Testing Suite

19 Component Step deleteall execsql execstoredproc export insert waitforassert Funktion leert in der Datenbank alle Tabellen, die im Dataset (input) enthalten sind. führt ein SQL-Script aus. Als Aufrufparameter sqlfile erwartet dieser Step den Namen einer Datei, die ein SQL-Script enthält. führt eine Prozedur (stored procedure) in der Datenbank aus. Dieser Step erwartet den Namen der auszuführenden Prozedur im Parameter operation. Optional können Parameter der Prozedur über ein Dataset (input) gefüllt und Rückgabewerte in einem Dataset (output) gespeichert oder mit Prüfdaten (expected) verglichen werden. exportiert Daten aus der Datenbank in eine Dataset- Datei (output). stellt Daten (input) in die Datenbank. arbeitet wie assertdata, jedoch wird bei einem fehlgeschlagenen Vergleich die Operation so lange wiederholt, bis der Vergleich mit einem vorgegebenen Dataset (expected) erfolgreich ist oder die maximale Zeitspanne (Parameter waitmillisforassert) überschritten wurde. Dieser Step ist insbesondere für asynchrone Operationen hilfreich. Über den Parameter waitmillisbetweenasserts wird die Wartezeit zwischen zwei Versuchen eingestellt. FileConnector für Dateischnittstellen append assertdata export waitforassert write hängt die Daten eines Datasets (input) an eine Datei. vergleicht den Dateiinhalt mit Prüfdaten (expected). liest den Dateiinhalt und schreibt diesen in eine Dataset-Datei (output). arbeitet wie assertdata, jedoch wird hier bei einem fehlgeschlagenen Vergleich die Operation so lange wiederholt, bis der Vergleich erfolgreich ist oder die maximale Zeitspanne überschritten wurde. schreibt die Daten eines Datasets (input) in eine Datei. JmsConnector für JMS-Provider (Java Message Service) und WmqConnector für den Zugriff auf Websphere MQ Queues assertdata vergleicht Daten aus einem DataSet (expected) gegen den Inhalt der Message Queue. Schnelleinstieg Seite 19

20 Component Step assertmessagecount clear export send waitforassert Funktion prüft die Anzahl der in der Queue enthaltenen Nachrichten gegen erwartete Werte (min, max) löscht alle Nachrichten in der Queue liest Nachrichten aus der Queue und schreibt diese in eine Dataset-Datei (output) stellt Nachrichten aus einem Dataset (input) in die Queue arbeitet wie assertdata, jedoch wird hier bei einem fehlgeschlagenen Vergleich die Operation so lange wiederholt, bis der Vergleich erfolgreich ist oder die maximale Zeitspanne überschritten wurde. EjbConnector für Enterprise Java Beans und PojoConnector für Plain Old Java Objects call ermöglicht den Aufruf einer Methode der EJB. Der Methodenname wird im Parameter operation erwartet. Die Parameter der Methode können über ein Dataset (input) gefüllt werden. Ausgabedaten können in eine Dataset-Datei (output) geschrieben oder mit Prüfdaten (expected) verglichen werden. Für alle Methoden der EJB ohne Parameter und für alle Methoden, für die in der Komponentenbeschreibung ein Konverter angegeben wurde, wird dynamisch ein Component Step angelegt, der den Namen der Methode trägt. Environment Steps ermöglichen u. a. das Ausführen von Kommandos (env.exec), das Manipulieren von Dateiinhalten (env.replaceinfile) und das Warten (env.sleep). Testdata Steps ermöglichen die Manipulation von Datasets (z. B. Filterung). Alle Parameter von Behavior Calls können als Parameter des Behavior deklariert werden. In einem Testfall (Testcase, s. Abschnitt 2.2) können diese Parameter dann mit konkreten Testdaten belegt werden. Das Anlegen von Testabläufen ist beschrieben in Abschnitt 3.6. Seite 20 SL Testing Suite

21 2.4 Die Testdaten In einem Testprojekt kann der Test-Autor alle Komponenten des zu testenden Systems in dem universellen Format der Datasets befüllen und abfragen. Das Format der Datasets entspricht dem relationalen Datenbankmodell. Ein Dataset ist also eine Sammlung von Relationen (den Tabellen). Jede Relation (Tabelle) enthält gleichartige Datensätze (die Zeilen einer Tabelle, records). Datensätze bestehen aus Attributwerten. Datensätze einer Relation sind gleichartig hinsichtlich der Attribute (den Spalten einer Tabelle, columns). Datasets können in Excel editiert werden. Der Blattname steht dann für den Tabellennamen. Die Einträge in Zeile 1 stehen für die Spaltennamen (Attribute) einer Tabelle. Mit Zeile 2 beginnend folgen zeilenweise die Datensätze (Tabelleneinträge). Datasets werden nativ in Tabelleneinträge umgesetzt, wenn sie als Dataset- Parameter an einen Component Step einer Datenbank (genauer: einer Komponente, die über einen JdbcConnector angebunden ist) übergeben werden. Details zu Dataset-Parametern und Component Steps sind zu finden in Abschnitt 2.3. Für andere Konnektoren erfolgt die Konvertierung der Datasets in das Format der jeweiligen Komponente über die in Abschnitt beschriebenen Konverter. Als Ein-, Ausgangs- oder Vergleichsdaten werden Datasets in einem Testfall (Testcase) den Parametern eines Behaviors zugeordnet. Dies ist beschrieben in Abschnitt Die Testausführung Tests können in der grafischen Oberfläche der SL Testing Suite angestoßen und deren Ergebnisse begutachtet werden. Alternativ kann eine Testausführung aus einem Ant-Script oder einem Scheduler getriggert werden. Testergebnisse werden dann als HTML- und XML-Reports geliefert. Als Parameter einer Testausführung sind anzugeben: Testprojekt Installation zur Beschreibung eines konkreten zu testenden Systems Testsuites, deren Testfälle ausgeführt werden sollen ggf. Testfälle, wenn nicht alle Testfälle einer Testsuite ausgeführt werden sollen. Das Ausführen von Testfällen beschreibt Abschnitt Schnelleinstieg Seite 21

22 2.6 Die Rollen Für eine effiziente Nutzung der SL Testing Suite kann sich an einem Rollenmodell orientiert werden, das die folgenden Benutzerrollen unterscheidet: Der System-Integrator bindet die Schnittstellen des zu testenden Systems an die SL Testing Suite an. Der Test-Architekt entwirft den Rahmen für verschiedene Kategorien von daten-getriebenen Tests. Der Test-Autor erstellt Testfälle und Testdaten und führt die Tests aus. Der System-Integrator ist ausschließlich in der Testvorbereitung tätig. Er muss wissen, welche Schnittstellen das zu testende System nach Außen hat und in welchen Formaten an diesen Schnittstellen Daten entgegengenommen oder abgegeben werden. Er muss außerdem die Konzepte der SL Testing Suite zur Anbindung an ein zu testendes System kennen und in der Lage sein, die notwenigen Konverter-Funktionen in Java zu kodieren. Aufgabe des System-Integrators ist es, die äußeren Schnittstellen des zu testenden Systems an die SL Testing Suite anzubinden, d. h. für diese beschreibbar und lesbar zu machen. Dazu sind die Systemschnittstellen den Konnektoren zuzuordnen oder eigene Konnektoren zu implementieren. Für Schnittstellen, die nicht direkt mit Datasets arbeiten können, sind Konverter zu implementieren. Die SL Testing Suite stellt Basis-Klassen zur Verfügung, die den Kodierungsaufwand dafür minimieren. Des Weiteren sollte der System-Integrator sein Wissen über die Systemschnittstellen und die Parameter konkreter Testaufbauten (Rechnernamen, Message Server, Zugangsdaten, etc.) an den Test-Architekten weitergeben. Die Tätigkeiten des System-Integrators sind beschrieben in Abschnitt 3.1. Der Test-Architekt gibt vor, welche Verarbeitungsabläufe zu testen sind. Er benötigt gute Kenntnisse über das zu testende System. Er muss insbesondere wissen, welches die äußeren Schnittstellen des Systems sind, welche Verarbeitungsabläufe mit dem System möglich sind, an welchen Schnittstellen Eingangsdaten dafür erforderlich sind und wo die Ergebnisdaten geliefert werden. Des Weiteren benötigt er Kenntnisse über die konkreten zu testenden Installationen (Zugangsdaten, Rechnernamen). Aufgabe des Test-Architekten ist es, das zu testende System hinsichtlich der äußeren Schnittstellen und die konkreten Installationen im Testprojekt zu dokumentieren (Test Environment und Installation). Durch das Erstellen von Testsuites gibt der Test-Architekt vor, welches Verhalten (Behavior) zu testen ist und teilt dem Test-Autor darüber mit, welche Arten von Daten als Eingangs- und Prüfdaten erwartet werden. Seite 22 SL Testing Suite

23 Die Tätigkeiten des Test-Architekten sind beschrieben in den Abschnitten 3.2 bis 3.7. Der Test-Autor erstellt Testfälle und führt diese aus. Er sollte ein tiefes Verständnis der fachlichen Domäne mitbringen und muss in der Lage sein, Eingangs- und Prüfdaten zu erstellen, mit denen das zu testende System validiert werden kann. Der Test-Autor erstellt anhand der Dokumentation in den Testsuites Testfälle und dazu passende Testdaten als Datasets. Er erstellt sowohl Eingangs- als auch Prüfdaten für die Verarbeitungsabläufe (Verhalten, Behavior) der jeweiligen Testsuites. Des Weiteren führt der Test-Autor die Testfälle aus, analysiert die Testergebnisse und versucht auszuschließen, dass nicht bestandene Tests in fehlerhaften Testdaten begründet sind. Die Tätigkeiten des Test-Autors sind beschrieben in den Abschnitten 3.8 bis Die Bedienung Die SL Testing Suite ist als Eclipse Plug-in realisiert. Informationen zum Umgang mit Eclipse bietet die Online-Hilfe, erreichbar über den Menüpunkt Help > Help Contents, mit dem Tutorial Getting Started im Workbench User Guide. Eclipse organisiert Daten in sogenannten Projekten (project). Ein Testprojekt wie in Abschnitt 2.2 beschrieben ist ein solches Projekt. Der Speicherort wird durch den sogenannten Workspace bestimmt. Beim erstmaligen Start verlangt Eclipse die Angabe eines Verzeichnisses, das als aktueller Workspace genutzt wird. Über den Menüpunkt File > Switch Workspace kann der Workspace gewechselt werden. In einem Workspace können mehrere Projekte lagern. Alle Daten eines Testprojekts liegen in einem Unterverzeichnis des Workspace, das den Namen des Testprojekts trägt. Alle Daten eines Testprojekts sind in XML-Dateien abgelegt; Testdaten können zusätzlich als Excel-Dateien vorliegen. Um Versionsstände eines Testprojekts zu verwalten und ein Testprojekt mit mehreren Nutzern zu teilen, empfiehlt es sich, die entsprechenden Dateien in ein Repository zu stellen. Eclipse lässt sich für viele Versionsverwaltungsprogramme so einrichten, dass Projekte direkt in Eclipse ein- und ausgecheckt werden können. Für CVS ist dies in dem Tutorial Team cvs tutorial im Help Book Workbench User Guide beschrieben. Die Eclipse-Oberfläche besteht aus einzelnen Teilfenstern (Sichten, parts, views). Eine Sammlung von Teilfenstern. Menüs und Symbolleisten, kann zu einer sogenannten Perspektive (perspective) zusammengefasst werden. Die SL Testing Suite definiert die Perspektive Test. Die Perspektive lässt sich über den entsprechenden Button im Panel für die Auswahl der Perspektive einstellen, siehe Abbildung 4. Testprojekte sollten generell in der Perspektive Test bearbeitet werden. Schnelleinstieg Seite 23

24 Abbildung 4: Aktivierte Perspektive Test. Eclipse zeigt in der Perpektive Test u. a. folgende Sichten: Der Test Navigator ermöglicht in einer Baumstruktur die Navigation zwischen den Bestandteilen des Testprojekts, siehe Abbildung 5. Die Auswahl eines Bestandteils durch Doppelklick öffnet das angewählte Element in einem Editor, der in einem (neuen) Teilfenster angezeigt wird. Alternativ können Bestandteile des Testprojekts nach Selektion über das Popup-Menü angezeigt werden. Die Menüpunkte Open und Open With > Default Editor öffnen das selektierte Element in dem spezifischen Editor. Mit dem Menüpunkt Open With > Text Editor erfolgt die Anzeige als XML-Daten. Zum Löschen kann der Popup-Menüeintrag Delete genutzt werden oder der Hauptmenüpunkt Edit > Delete. Abbildung 5: Test Navigator. Seite 24 SL Testing Suite

25 In der View Installations ist über eine Auswahlliste die zu testende Installation einstellbar. Die View Problems meldet während der Dateneingabe inkonsistente Zustände in der Testdefinition. In der View JUnit werden Testausführung und Testergebnisse angezeigt. Diese View öffnet sich mit erstmaliger Testausführung. Die View Console zeigt Logging-Ausgaben während der Testausführung. Die Bestandteile eines Testprojekts werden im Test Navigator und in den spezifischen Editoren durch folgende Icons und im Dateisystem durch folgende Dateiendungen gekennzeichnet: Icon Bestandteil Dateiendung Applikation.application Component Component Step / Primitive Step Environment Bestandteil einer Applikation Bestandteil einer Component.environment Installation.installation Location Bestandteil einer Installation Behavior / Verhalten.behavior Behavior Call Bestandteil eines Behaviors Dataset.dataset Testsuite.testsuite Testfall Bestandteil einer Testsuite Testprojekt Auf Dateiebene durch Ordner im Workspace repräsentiert. Schnelleinstieg Seite 25

26 Abbildung 7 zeigt eine schematische Darstellung eines Testprojekts, die sich an der Darstellung im Test Navigator anlehnt. Das Diagramm begleitet die detaillierten Beschreibungen in Abschnitt 3. Die Bestandteile Applikation, Environment, Installation, Behavior, Dataset und Testsuite sowie deren jeweilige Bestandteile können in spezifischen Editoren bearbeitet werden. Die Editoren werden über das Popup-Menü des Test-Navigators aufgerufen. So steht nach Selektion einer Testsuite der Menüpunkt Open With > Testsuite Editor zur Verfügung, um eine Testsuite zu bearbeiten. Abbildung 6: Testsuite Editor. Den Editoren sind die im Folgenden anhand des Testsuite-Editors beschriebenen Bestandteile gemeinsam. Das Arbeiten mit den Editoren ist beschrieben in Abschnitt 3. Die Kopfzeile eines Editors zeigt Icon und Name (hier Umsatz als Name der Testsuite). Enthält ein Element Fehler, so wird dies in der Kopfzeile durch ein rotes Icon und eine Fehlermeldung in roter Schrift signalisiert. Bei einem Fehler wird ein aussagekräftiger Fehlertext angezeigt. Bei mehreren Fehlern erscheint eine unspezifische Fehlermeldung in der Form 2 errors detected. Spezifische Fehlermeldungen werden beim Überfahren des Textes mit der Maus und in der View Problems angezeigt. Die Fehlerkennzeichnung erfolgt auch im Test Navigator durch ein rotes Icon bis zur obersten Ebene, dem Testprojekt. Seite 26 SL Testing Suite

27 Die Anzeigen und Bedienelemente eines Editors können auf mehrere Reiter ( Testcase und Common beim Testsuite-Editor) verteilt sein. Die Editoren sind in Bereiche untergliedert. Jeder Bereich ist durch eine blaue Überschrift (in Abbildung 6: All Test Cases, Test Case Documentation und Test Case Behavior ) benannt. Ist der Überschrift eine Pfeilspitze vorangestellt, so kann der Bereich durch Klicken in die Überschrift minimiert bzw. maximiert werden. Neben der Überschrift enthält die Kopfzeile eines Bereichs i. A. eine Buttonleiste, mit der die Elemente des Bereichs manipuliert werden können. Die Funktion der gebräuchlichsten Buttons ist in der folgenden Tabelle beschrieben. Icon Tooltip Funktion Add Fügt ein Element hier einen Testfall hinzu. Das Icon ist abhängig von dem Element; gemeinsam ist das gelbe Pluszeichen. Delete Löscht das selektierte Element. Add Fügt einen Parameter hinzu. Edit Browse Öffnet einen Dialog zum Editieren eines Parameter-Wertes. Öffnet einen Browser zur Selektion. Open Öffnet das selektierte Element. Move up Move down Stellt das selektierte Elemente in der Liste eine Position tiefer. Stellt das selektierte Elemente in der Liste eine Position höher. Informationen zu der Bedienung der Editoren bietet die Programm-Hilfe. Im aktiven Fenster öffnet die Funktionstaste F1 die entsprechende Hilfe-Seite. Weitere Unterstützung ist über den Menüpunkt Help > Help Contents erreichbar. Im Help Book SL Testing Suite ist die gesamte Programm-Hilfe zusammengefasst. Schnelleinstieg Seite 27

28 Abbildung 7: Schematische Darstellung eines Testprojekts. Seite 28 SL Testing Suite

29 3 TESTEN EINES SYSTEMS In diesem Abschnitt werden die grundlegenden Tätigkeiten, die für das Testen eines Systems mit der SL Testing Suite durchzuführen sind, beschrieben. BEISPIEL: Begleitet wird die Beschreibung von einem sehr einfachen Beispiel eines zu testenden Systems: Der AmazingShop überrascht tatsächlich durch Einfachheit. In seiner Datenbank hält er nur die wichtigsten Informationen und diese sind für ein Shop-System: Kunden, Produkte und Bestellungen. Die Daten liegen in vier Tabellen mit den sprechenden Namen KUNDE, PRODUKT, BESTELLUNG, BESTELLPOSITION. Getestet werden sollen zwei Funktionen, die der AmazingShop über eine Funktions-Schnittstelle (hier Methodenaufrufe einer Java-Klasse) zur Verfügung stellt: die Berechnung von Gesamtumsatz je Kunde und Gesamtumsatz je Produkt. Die Berechnungsergebnisse stellen die Methoden reportkunde() und reportprodukt() in die Datenbank (jeweils Spalte UMSATZ in den Tabellen KUNDE und PRODUKT). Des Weiteren verfügt der AmazingShop über eine Import-Funktion für Produkte, die ebenfalls zu testen ist. Die Import-Funktion liest Daten aus einer Datei, deren einzelne Felder durch Semikolon getrennt sind, und stellt diese in die Tabelle PRODUKT. Die Import-Funktion ist als Methode importprodukte() mit einem Dateinamen als Parameter aufrufbar. Um mit dem Beispiel arbeiten zu können, starten Sie die SL Testing Suite (Eclipse mit dem entsprechenden Plug-in) und öffnen einen neuen Workspace. Importieren Sie die Beispielprojekte über File > Import > General > Existing Projects into Workspace > Next. Geben Sie bei "Select archive file" den Pfad zum ExampleTestingProjects.zip von dem Installationsmedium an. Stellen Sie sicher, dass alle Projekte in der Auswahlliste selektiert sind, und drücken Sie Finish. Schnelleinstieg Seite 29

30 3.1 Vorbereitung Gute Teststrategien setzen ein tiefes Verständnis der fachlichen Domäne und gute Kenntnisse über das zu testende System voraus. Idealerweise sollte deshalb ein Fachdomänenexperte für die Rolle des Test-Autor zur Verfügung stehen. Von dem zu testende System muss bekannt sein, was für Daten an den System- Schnittstellen (Komponenten) entgegengenommen und abgegeben werden und in welchen Formaten die Daten erwartet oder abgegeben werden. In vielen Fällen wird das zu testende System eine Datenbank beinhalten und Bearbeitungsergebnisse werden von Datenbankeinträgen abhängen; der Test-Architekt muss dann mit dem Datenmodell vertraut sein. Schließlich erfordert ein aussagefähiger Systemtest eine für den Test zur Verfügung stehende Installation des zu testenden Systems mit den entsprechenden Ressourcen und ggf. Attrappen (Mocks) für Umsysteme Zuordnung von Systemschnittstellen Wenn alle Komponenten identifiziert sind, über die Testdaten in das zu testende System eingespielt und an denen Ergebnisse geprüft werden sollen, sind diese den Konnektoren (connector) der SL Testing Suite zuzuordnen. Die Konnektoren stellen die Verbindung zwischen der SL Testing Suite und dem zu testenden System (genauer einzelnen Komponenten des Systems) her, vgl. auch Abschnitt 2.3. Standard-Komponenten sind wie folgt den Konnektoren zuzuordnen: Komponente Datenbank, auf die über JDBC zugegriffen werden kann Enterprise Java Bean JMS Message Queue Websphere MQ SOAP-basierter WebService Datei-Schnittstelle Java-Klasse (Plain Old Java Object) Passender Konnektor JdbcConnector EjbConnector JmsConnector WMQConnector WebServiceConnector FileConnector PojoConnector Existiert für eine im zu testenden System verwendete Komponente, die mit Daten versorgt oder aus der Daten exportiert werden müssen, kein passender Konnektor, so kann dieser implementiert werden. Seite 30 SL Testing Suite

31 Die Zuordnung der Konnektoren zu den Komponenten erfolgt im Testprojekt beim Anlegen einer Applikation (application), s. Abschnitt 3.3. BEISPIEL: Das zu testende System AmazingShop verfügt über drei Komponenten: die Datenbank, in die Testdaten einzuspielen und die Berechnungsergebnisse auszulesen und zu überprüfen sind, die Datei- Schnittstelle für den Import von Produkten sowie die Funktions-Schnittstelle, die in unserem Beispiel als Java-Klasse ansprechbar ist. Für die Datenbank ist der JdbcConnector einzusetzen, für die Datei-Schnittstelle der FileConnector und für die Funktions-Schnittstelle der PojoConnector Implementierung von Konvertern In einem Testprojekt kann der Test-Autor alle Schnittstellen in dem einheitlichen Format der Datasets befüllen und abfragen. Für Datenbanken erfolgt die Zuordnung eines Datasets zu einer Tabelle wie in Abschnitt 2.4 beschrieben. Für andere Komponenten ist jeweils ein Konverter zu implementieren, der Datasets in das erwartete Format umwandeln kann und umgekehrt. Die Implementierung von Konvertern unterstützt die SL Testing Suite durch das Bereitstellen folgender Basisklassen im Package com.softwareloft.test.runtime.dataset.converter.impl: Konverter ObjectDataSetConverter XmlDataSetConverter FixedLenghDataSetConverter CsvDataSetConverter JmsTextMessageDataSetConverter JmsObjektMessageDataSetConverter IntegerDataSetConverter StringDataSetConverter für die Konvertierung von Java-Objekten XML-Daten Daten mit festen Spaltenbreiten Daten mit einem Feldtrennzeichen JMS-Nachrichten vom Typ TextMessage JMS-Nachrichten vom Typ ObjectMessage Integer-Werte Strings Für die Konvertierung anderer Datentypen ist das Interface IDataSetConverter zu implementieren. Schnelleinstieg Seite 31

32 Für die Implementierung eines Konverters benötigt der Entwickler eine Beschreibung des zu konvertierenden Formats, grundlegende Programmierkenntnisse in der Sprache Java ggf. die Programm-Hilfe der SL Testing Suite. Idealerweise ist für die benötigten Konverter ein eigenes Eclipse Java-Projekt anzulegen. Bei sehr umfangreichen Systemen kann es empfehlenswert sein, für jede zu testende Applikation ein Konnektor-Projekt anzulegen. Zum Anlegen des Konnektor-Projekts ist von der View Test Navigator in die View Navigator oder die View Package Explorer der Java-Perspective zu wechseln. Das Konnektor-Projekt benötigt die Libraries aus dem mitgelieferten Library- Projekt. 1 Beim Anlegen des neuen Projekts über das Eclipse-Hauptmenü File > New > Java Project kann das Library-Projekt im Java-Project-Wizard auf dem Reiter Projects über den Add-Button dem Konnektor-Projekt bekannt gemacht werden. Existiert für einen benötigten Konverter eine passende Basisklasse (wie CsvDataSetConverter für Datensätze, deren Attribute jeweils durch das gleiche Trennzeichen voneinander abgegrenzt sind), so sollte der Konverter als Ableitung dieser Klasse erstellt werden. Andernfalls ist der Konverter als eine Klasse zu realisieren, die direkt das Interface IDataSetConverter implementiert. Das Interface besteht aus den Signaturen der beiden Methoden fromdataset() zur Wandlung eines Datasets in das Schnittstellen-Format und todataset() zur Wandlung des Schnittstellen-Formats in das Format der Datasets. Für schreibenden Zugriff auf die Komponenten- Schnittstelle ist fromdataset zu implementieren, für lesenden Zugriff todataset. Sollen an der Schnittstelle Daten abgefragt und mit erwarteten Daten verglichen werden, so ist es notwendig beide Funktionen zu implementieren. Die Methode fromdataset() erwartet als Eingangsparameter ein Objekt vom Typ IDataSet, die Methode todataset() muss ein solches Objekt zurückliefern. IDataSet ist ein Interface aus dem Framework DbUnit und unter umfassend dokumentiert. Ein Dataset enthält wie in Abschnitt 2.4 beschrieben eine Menge von Tabellen, die jeweils Datensätze als Zeilen enthalten. Der erste Schritt zur Implementierung eines Konverters besteht darin, das Schnittstellen-Format konzeptionell in diese Struktur zu überführen. Für die Codierung der Methode fromdataset(dataset) 1 Die benötigten Libraries sind: "xfire-jsr181-api.jar" "activation.jar" "antlr.jar" "asm.jar" "commons-collections.jar" "commons-lang.jar" "commons-logging.jar" "dbunit.jar" "ejb.jar" "groovy.jar" "jaxb-api.jar" "jaxb-impl.jar" "jaxb-xjc.jar" "jaxws-api.jar" "jaxws-rt.jar" "jline.jar" "jms.jar" "jsr173.jar" "junit.jar" "log4j.jar" "poi.jar" "saaj-api.jar" "saaj-impl.jar" "slf4j-api.jar" "slf4jnop.jar" "ssh2.jar" "stax.jar" "stax-api.jar" "stax-ex.jar" "streambuffer.jar" "swl-test.jar" "xbeanclassloader.jar" Seite 32 SL Testing Suite

33 können die Zugriffsfunktionen dataset.gettable() und dataset.gettable.getvalues() genutzt werden. Für die Codierung der Methode todataset(), die ein Dataset zurückgeben muss, stehen im DbUnit-Framework die Klassen DefaultDataSet, DefaultTable und Column zur Verfügung, um ein Dataset, eine Tabelle bzw. eine Tabellenspalte zu erzeugen. Das SL Testing Framework bietet weitere Methoden, um die Erstellung komplexer Konverter zu erleichtern. Hinweis: Durch den Konverter werden die Bezeichnungen vorgegeben, mit denen im Testdata Editor und in Excel die Tabellen und Spalten beschriftet sind. Die Bezeichnungen sollten so gewählt werden, dass der Test-Autor daraus auf die fachlichen Inhalte schließen kann. BEISPIEL: Für die Jdbc-Komponente (Datenbank) des AmazingShop wird kein Konverter benötigt, da Inhalte einer Komponente, die über den JdbcConnector angebunden ist, nativ in Datasets umgesetzt werden. Für die Datei-Schnittstelle zum Import von Produkten wird ein Konverter benötigt. Das Format der Import-Datei ist: Jede Zeile enthält alle Attribute eines Produktes getrennt durch Semikolon in der Reihenfolge ID, BEZEICHNUNG, PREIS, UMSATZ. Zur Beschreibung des Formats sind hier bereits die Spaltennamen der Tabelle PRODUKT angegeben. Die Überführung in ein Dataset ergibt sich auf natürliche Art: Die Datei ist in die Tabelle PRODUKT zu überführen, jede Dateizeile entspricht einer Tabellenzeile (row), jedes der durch Semikolon getrennten Feldinhalte ist einer Tabellenspalte zuzuordnen. Legen Sie zunächst ein neues Java-Projekt an (Eclipse-Menüpunkt File > New > Java Project) und geben Sie diesem den Namen amazing.connectorproject. Fügen Sie im nachfolgenden Wizard-Fenster über den Reiter Projects und den Add-Button das Projekt SLTestingSuiteLibraries hinzu. Erstellen Sie für den Konverter-Quellcode ein neues Package (Eclipse-Popup-Menü New > Package) mit dem Namen amazing.connectorproject.dataset.converter. Die Implementierung eines Konvertes für die Datei-Schnittstelle wird dadurch erleichtert, dass für das vorliegende Format der CsvDataSetConverter eingesetzt werden kann. Legen Sie im Package amazing.connectorproject.dataset.converter eine neue Klasse an mit dem Namen ProduktCsvFileDataSetConverter als Ableitung von der Superclass CsvDataSetConverter. Unter Zuhilfename der Klassen CsvFormatDescriptor und CsvRecordDescriptor können Sie den Converter wie folgt implementieren: package amazing.connectorproject.dataset.converter; import com.softwareloft.test.runtime.dataset.converter.impl.csvdatasetconverter; import com.softwareloft.test.runtime.dataset.converter.impl.csvformatdescriptor; import com.softwareloft.test.runtime.dataset.converter.impl.csvrecorddescriptor; Schnelleinstieg Seite 33

34 public class ProduktCsvFileDataSetConverter extends CsvDataSetConverter { public ProduktCsvFileDataSetConverter() { } super(buildformat()); } private static CsvFormatDescriptor buildformat() { CsvFormatDescriptor formatdesc = new CsvFormatDescriptor(";", 0); CsvRecordDescriptor recorddesc = new CsvRecordDescriptor("PRODUKT"); recorddesc.addcolumnname("id"); recorddesc.addcolumnname("bezeichnung"); recorddesc.addcolumnname("preis"); recorddesc.addcolumnname("umsatz"); formatdesc.addrecorddescriptor(recorddesc); return formatdesc; } Dieser Konverter ist nun einsatzbereit, um Dateien aus dem Format der Produkt- Importschnittstelle als Datasets darzustellen und umgekehrt aus Datasets Dateien zu schreiben. Alternativ könnte der Konverter direkt das Interface IDataSetConverter implementieren. Der gleiche Konverter wird unter Nutzung des DbUnit- Frameworks durch folgenden Quellcode realisiert: package amazing.connectorproject.dataset.converter; import java.util.arraylist; import java.util.list; import org.dbunit.dataset.column; import org.dbunit.dataset.datasetexception; import org.dbunit.dataset.defaultdataset; import org.dbunit.dataset.defaulttable; import org.dbunit.dataset.defaulttablemetadata; import org.dbunit.dataset.idataset; import org.dbunit.dataset.itable; import org.dbunit.dataset.datatype.datatype; import com.softwareloft.test.runtime.converterexception; import com.softwareloft.test.runtime.dataset.converter.idatasetconverter; public class ProduktCsvFileDataSetConverter implements IDataSetConverter { public List<? extends Object> fromdataset(idataset dataset) throws ConverterException, UnsupportedOperationException { try { ITable produkttable = dataset.gettable("produkt"); List<Object> result = new ArrayList<Object>(produktTable.getRowCount()); Seite 34 SL Testing Suite