Testwerkzeuge

Für das Testen von BIS existieren keine speziellen Testwerkzeuge. [vgl. Inf10, S. 9;

Sun07, S. 3] Da das gesamte BIS kein eigenes Produkt ist, sondern aus Bausteinen verschiedenster Hersteller zusammengesetzt wird (Beispiel im Anhang A), ist die Schaffung eines zentralen und allgemeingültigen Testwerkezuges unrealistisch. Es muss somit auf die bestehenden Möglichkeiten der einzelnen BI Produkte und auf die Testwerkzeuge aus der klassischen Softwareentwicklung zurückgegriffen wer-den.

Die visuellen Hilfsmittel finden Einsatz in nahezu allen Teilbereichen des BIS. Für relationale Datenmodelle gibt es eine Reihe von Modellierungswerkzeugen, die so-wohl eine Vorwärts- als auch Rückwärtsentwicklung erlauben. Dabei kann soso-wohl aus einem bestehenden Tabellenschema ein Diagramm (z.B. ER-Diagramm) gene-riert werden kann, als auch umgekehrt aus einem Diagramm ein Tabellenschema.

Für den Bereich der multidimensionalen Modellierung sieht die Werkzeugauswahl weitaus schwieriger aus. Für die in dieser Arbeit verwendete ADAPT-Notation exis-tiert eine kostenlose Schablonenvorlage für Microsoft Visio²⁴. Eine automatisierte Generierung von Würfelstrukturen im OLAP-System ist damit leider nicht möglich und umgekehrt müssen Änderungen an dem physischen Datenmodell manuell in dem Diagramm nachgepflegt werden. Trotzdem empfiehlt es sich, gerade während der Analyse und Entwurfsphase auf die Möglichkeiten der Modellierung zurückzu-greifen. Vor der endgültigen Festlegung auf eine Notationsform, ist daher der Markt auf zur Verfügung stehende Modellierungswerkzeuge zu untersuchen.

Aus funktionaler Sicht werden im BIS Daten aufbereitet und dabei in andere Sche-mata oder Darstellungsformen überführt. Bei der Durchführung der funktionalen Tests gilt es zu prüfen, ob Eingangsdatensätze tatsächlich in das erwartete Aus-gangsformat überführt wurden. Wird etwa durch einen Harmonisierungsprozess der Schlüssel für das Geschlecht vereinheitlicht, so wird erwartet, dass ein Datensatz mit der Ausprägung „männlich“ anschließend die Ausprägung „M“ besitzt. Grundsätzlich kann diese Prüfung manuell erfolgen, indem per SQL das Ergebnis eines Prozesses

24 http://www.symcorp.com/tech_expertise_design.html (Abgerufen 27.01.2012)

Kapitel 5 - Testinfrastruktur

selektiert und vom Tester selbst abgeglichen wird. Ein manueller Abgleich ist jedoch zum einen zu langsam und zum anderen auch zu ungenau, weil das menschliche Auge sich bei einer Überflutung von Zahlen schnell irren kann. Somit wird für die ef-fektive Testdurchführung ein Werkzeug benötigt, das Datensätze automatisch ab-gleicht.

<column>GESCHLECHT</column>

<row>

Listing 5-1: Erwartete Datenätze als XML-Datei (DbUnit) [Eigene Darstellung]

Genau diesen Ansatz verfolgt das freie Datenbank-Testwerkzeug DbUnit²⁵. DbUnit ist eine Erweiterung des bekannten Java-Testwerkzeugs JUnit²⁶ und nutzt dessen Methoden zum Abgleichen eines erwarteten und tatsächlichen Sachverhaltes. Die erwarteten Datensätze lassen sich hierbei sehr einfach in eine XML-Datei eintragen (Listing 5-1), somit fällt das unter Umständen aufwendige Erstellen einer Vergleich-stabelle innerhalb der Datenbank weg. Der Inhalt der zu prüfenden Tabellen wird mittels getTable() komplett geladen oder alternativ über ein selbstgeschriebenes SQL-Statement eingeschränkt. Dann werden die geladenen Datensätze mittels

25 Weitere Informationen unter http://www.dbunit.org (Abgerufen 29.01.2012)

26 Weitere Informationen unter http://www.junit.org (Abgerufen 29.01.2012)

Kapitel 5 - Testinfrastruktur

assertEquals()gegen die Testdatensätze der XML-Datei geprüft (Listing 5-2). Je nachdem, ob der Test erfolgreich war oder nicht, ist der „JUnit-Balken“ entsprechend grün oder rot. Im Fehlerfall wird ein kurzer Hinweistext ausgegeben, welcher Ver-gleich fehlgeschlagen ist (Abbildung 5-1).

Abbildung 5-1: Fehlgeschlagener Datenbank-Testfall (DbUnit) [Eigene Darstellung]

public void testKunde() throws Exception { // Erwartete Daten aus XML

File xml = new File("C:\test.xml");

IDataSet expectedDataSet =

new XmlDataSet(new FileInputStream(xml));

ITable expected =

expectedDataSet.getTable("KUNDE");

// Tatsächliche Daten aus Tabelle IDataSet databaseDataSet =

getConnection().createDataSet();

ITable actual =

databaseDataSet.getTable("KUNDE");

// Vergleich

Assertion.assertEquals(expected, actual);

}

Listing 5-2: Datenbank-Testfall (DbUnit) [Eigene Darstellung]

Neben dem Abgleich von Datensätzen eignet sich DbUnit auch, um Strukturen von angelegten Datenbanktabellen zu überprüfen. In der XML-Datei können die bei der Grenzwertanalyse ermittelten Testdatensätze eingetragen und dann per

INSERT-Kapitel 5 - Testinfrastruktur

Statement abgesetzt werden. Das Ergebnis des Tests lautet entsprechend, dass die Datensätze erfolgreich oder nicht erfolgreich (SQLException) eingefügt wurden (Listing 5-3).

public void testInsert() throws Exception { // Erwartete Daten aus XML

// ...

// INSERT-Statement absetzen

DatabaseOperation.INSERT.execute(

getConnection(), expectedDataSet);

// Tatsächliche Daten aus Tabelle

public void testConstraint() throws Exception { // Negativ-Test, eine Exception wird erwartet DatabaseOperation.INSERT.execute(

getConnection(), faultyDataSet);

}

Listing 5-3: Datenbank-Testfall für Strukturen (DbUnit) [Eigene Darstellung]

DbUnit ist allerdings nur auf relationale Datenbanken ausgelegt und nicht auf mul-tidimensionale OLAP-Datenbanken. Als Testwerkzeug-Ersatz hierfür kann Excel herangezogen werden, wenn der Hersteller des OLAP-Systems eine Excel-Erweiterung anbietet. In dem Excel-Tabellenblatt werden dann für die aufgestellten Testfälle Selektionen vorbereitet und alle erwarteten Resultate in Vergleichszellen eingetragen. Zwischen den Zellen der erwarteten und tatsächlichen Werte wird dann jeweils mittels WENN-Funktion geprüft, ob die Werte gleich sind. Das Ergebnis des Vergleichs kann mittels bedingter Formatierung optisch aufbereitet werden, sodass

Kapitel 5 - Testinfrastruktur

wie in DbUnit rote und grüne Balken dargestellt werden. In der folgenden Abbildung ist ein exemplarisches Test-Tabellenblatt in Excel dargestellt.

Abbildung 5-2: OLAP-Testfall (Excel) [Eigene Darstellung]

Einige triviale Überprüfungen werden direkt durch die verwendeten BI-Produkte durchgeführt. Essbase prüft beim Laden der Daten automatisch, ob ungültige Koor-dinaten in dem Würfel referenziert werden und gibt eine entsprechende Warnung aus. Talend kann beispielsweise die einfachen Kontrollfluss- und Datenflussanoma-lien erkennen und gibt ebenfalls eine Warnung aus. Wie in Abbildung 3-12 darge-stellt, bietet Talend auch eine integrierte Slicing-Funktionalität. Für das automatisierte Testen eines Datenintegrationsprozesses schlägt Talend auf seiner Entwickler-Website²⁷ ein Verfahren vor. Das Vorgehen ist ähnlich zu DbUnit: Das tatsächliche Ergebnis eines Prozesses wird mit Erwartungswerten abgeglichen. Die Einschrän-kung bei diesem Verfahren ist allerdings, dass es nur mit einfachen CSV-Dateien funktioniert und nicht mit Datenbanktabellen. Das Resultat des Tests (erfolgreich, nicht erfolgreich) wird auf der Konsole ausgegeben. In der Abbildung 5-3 ist ein exemplarischer Test dargestellt. Dabei werden drei Dateien parallel gegen Erwar-tungswerte geprüft.

27 http://www.talendforge.org/wiki/doku.php?id=tests:automated_tests:design (Abgerufen 05.02.2012)

Kapitel 5 - Testinfrastruktur

Abbildung 5-3: Test Unit Job (Talend) [Eigene Darstellung]