Bewertung

Nachdem in den vorherigen Abschnitten analysiert wurde, welches die zu prüfenden Besonderheiten und Fehlersituationen bei der Entwicklung eines BIS sind und wel-che Prüftechniken dafür anwendbar sind, folgt in diesem Abschnitt eine Bewertung der Analyseergebnisse. In der Tabelle 3-17 sind die Prüftechniken und deren An-wendbarkeit noch einmal als Übersicht zusammengetragen.

Äquivalenzkl. Urs.-Wirk. Kontrollfluss Datenfluss Anomalie Slicing Vis. Hilfsm. Stilanalyse Review Metriken Effizienz Sicherheit Benutzbarkeit

Modellie-rung ✔ ✔ ✔

Daten-integration ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Data

Warehouse ✔ ✔ ✔ ✔ ✔

OLAP-System ✔ ✔ ✔ ✔

Reporting

Front-End ✔ ✔

Automati-sierung ✔ ✔ ✔ ✔

Äquivalenzkl. = Äquivalenzklassen, Urs.-Wirk. = Ursache-Wirkung-Analyse, Vis. Hilfsm. = Visuelle Hilfsmittel

Tabelle 3-17: Prüftechniken Big Picture [Eigene Darstellung]

Modellierung

Bei der Entwicklung klassischer Software gehört der Einsatz visueller Hilfsmittel (z.B.

UML-Fachklassendiagramm) während der Analyse- und Entwurfsphase zum bewähr-ten Stand der Technik. Die Verwendung einer multidimensionalen

Modellierungsno-Kapitel 3 - Testen während der Entwicklung

tation als gemeinsame Sprache zwischen Auftraggeber und Entwickler kann helfen, Fehler aufgrund von Missverständnissen oder unzureichender Spezifikationen zu vermeiden. Mithilfe der Stilanalyse und der vorgestellten Metriken lassen sich dar-über hinaus Fehler und Schwächen der Modellierung aufdecken.

Da in dieser frühen Phase des Entwicklungsprozesses viele Fehler ihren Ursprung haben, sind sowohl die visuellen Hilfsmittel als auch die Stilanalyse und Metriken sehr effektive Prüftechniken. Der Aufwand für die Anwendung der Prüftechniken ist sehr gering. Für die Modellierung gibt es entsprechende Modellierungswerkzeuge und die Ermittlung der Metriken kann beispielsweise mithilfe von Excel geschehen.

Datenintegration

Das Verarbeiten von Daten aus Legacy-Systemen ist oftmals sehr komplex und feh-leranfällig. Mithilfe der Äquivalenzklassenbildung lassen sich die verschiedenen Aus-prägungen der Datenformate ermitteln und dann überprüfen. Die Äquivalenzklassen-bildung ist ein einfaches Verfahren, das bei der Analyse und Implementierung von Datenformaten oftmals bereits implizit angewendet wird. Der Aufwand für die Prüf-technik ist somit gering. Die systematische und bewusste Anwendung der Prüftech-nik hilft dem Tester, mehr Fehler zu finden als bei der impliziten Anwendung.

Für die Überprüfung der Verarbeitungsregeln müssen auch Kombinationen bzw.

Wechselwirkungen der Äquivalenzklassen berücksichtigt werden. Auch hier wird die Ursache-Wirkungs-Analyse oftmals implizit durchgeführt. Eine systematische An-wendung ist also ebenfalls wenig aufwendig, kann jedoch bei der Testdurchführung ihre vollen Stärken ausspielen und Fehler effektiver aufdecken. Gerade das Aufstel-len eines Ursache-Wirkungs-Graphen und der daraus abgeleiteten Entscheidungsta-belle hilft, alle Situationen während der Datenintegration zu prüfen.

Das kontrollflussorientierte Testen gilt für die Beurteilung der Testfallabdeckung als unverzichtbar. [vgl. Lig09, S. 138] Bei der Nutzung eines grafischen Datenintegrati-onswerkzeuges liegt der Kontrollflussgraph automatisch vor. Somit ist die Grundlage des kontrollflussorientierten Tests bereits geschaffen und es ist kein gesondertes Testwerkzeug notwendig. Der gesamte Testaufwand ergibt sich aus dem angewen-deten Überdeckungsgrad. Da der Anweisungsüberdeckungstest im Allgemeinen als zu schwach gilt [vgl. Lig09, S. 87], empfiehlt sich der Zweigüberdeckungstest als Mi-nimalanforderung. Hierfür müssen alle Knoten und Kanten des

Datenintegrationspro-Kapitel 3 - Testen während der Entwicklung

zesses einmal durchlaufen werden. Der Aufwand ist also überschaubar. Der Bedin-gungsüberdeckungstest hingegen ist zwar noch effektiver, aber auch sehr aufwen-dig. Liggesmeyer schreibt in seiner Bewertung des kontrollflussorientierten Testens, dass die Entscheidung für bzw. gegen den Bedingungsüberdeckungstest von der Komplexität der Verarbeitungslogik abhängt:

„Die Bedingungsüberdeckungstests sind insbesondere dann als Testtechniken interessant, wenn eine komplizierte Verarbeitungslogik vorliegt, die zu kompli-ziert aufgebauten Entscheidungen führt. [...] Die Verwendung von Bedingungs-überdeckungstests ist in manchen kritischen Fällen verbindlich.“ [Lig09, S. 117]

Obwohl das datenflussorientierte Testen eine sehr effektive Prüftechnik ist, hat es in der Praxis kaum eine Bedeutung. [vgl. Lig09, S. 177] Gerade für das Überprüfen von Datenintegrationsprozessen, wo es genau auf das korrekte Verarbeiten von Daten-flüssen ankommt, bietet sich diese Prüftechnik sehr an. Für das datenflussorientierte Testen muss der Kontrollflussgraph um die Datenzugriffe ergänzt werden. Diese Er-weiterung ist jedoch nicht Bestandteil des vom Datenintegrationswerkzeug bereitge-stellten Kontrollflussgraphen und ist manuell durchzuführen. Da in einem Dateninteg-rationsprozess oft hundert oder mehr Attribute verarbeitet werden, ist diese manuelle Durchführung nicht praxistauglich.

Diese Problematik ergibt sich folglich auch für die Durchführung einer Anomalieana-lyse. Für triviale Anomalien, wie unerreichbare Prozessschritte als auch nicht ver-wendete Attribute (du-Anomalie), bieten Datenintegrationswerkzeuge integrierte Funktionalitäten, die einen Entwickler direkt auf solche Anomalien hinweisen.

Das Slicing in Form der Data Lineage bzw. Impact Analyse kann für die Fehlersuche als ergänzende Prüftechnik angewendet werden. Wenn bei der Testdurchführung fehlerhafte Attribute aufgefallen sind, können mithilfe der beiden Analysen die parti-zipierenden Prozessschritte aufgedeckt werden. Die Slicing-Funktionalität ist in vie-len Datenintegrationswerkzeugen enthalten.

Die Durchführung eines Reviews geschieht manuell durch einen unabhängigen Ent-wickler. Somit ist diese Prüftechnik mit einem hohen Aufwand verbunden. Da durch eine unabhängige Kontrolle sowohl Fehler in der Verarbeitungslogik als auch Miss-achtungen von Programmierkonventionen aufgedeckt werden (Stilanalyse), empfiehlt sich diese Prüftechnik trotz des hohen Aufwandes. Eine automatisierte Stilanalyse durch das Datenintegrationswerkzeug ist nicht möglich, weil nur ein Mensch die

Ver-Kapitel 3 - Testen während der Entwicklung

ständlichkeit der Benennung sowie die Übersichtlichkeit der Anordnung von Pro-zessschritten beurteilen kann. Besonders im Hinblick auf die Dokumentationspflicht wird die Notwendigkeit eines Reviews verdeutlicht.

Neben der korrekten Verarbeitung muss der Datenintegrationsprozess auch effizient mit den zur Verfügung stehenden Hardware-Ressourcen umgehen. Ein Effizienztest ist somit unerlässlich. Die Informationen über die Verarbeitungsgeschwindigkeit (Da-tensätze pro Sekunde) werden durch das Datenintegrationswerkzeug aufgestellt. Die Überwachung der Prozessor- und Arbeitsspeicherauslastung geschieht über die vom Betriebssystem bereitgestellten Mittel (z.B. Windows Task-Manager). Der Effizienz-test wird mit einem echten Datenabzug durchgeführt, es müssen somit keine separa-ten Testdasepara-tensätze aufgestellt werden.

Da die Datenintegration insgesamt der komplexeste und aufwendigste Teil während der Entwicklung eines BIS ist [vgl. Gol11, S. 1197], muss sie entsprechend ausgiebig und umfangreich getestet werden. Das Anwenden der vielen genannten Prüftechni-ken ist somit gerechtfertigt und auch sehr sinnvoll.

Data Warehouse

Das Bilden von Äquivalenzklassen für die Überprüfung von Tabellen-Strukturen ist eine einfach anwendbare Prüftechnik. Nur so kann sichergestellt werden, ob eine Tabelle korrekt definiert ist und die für sie vorgesehenen Daten speichern kann. Im Abschnitt 5.1 wird für diesen Test ein passendes Werkzeug vorgestellt.

Sowohl die Nutzung visueller Modellierungswerkzeuge, als auch die Definition von Programmier- und Sicherheitskonventionen gehören zum Stand der Technik bei der Verwendung von Datenbanken. Somit sind die visuellen Hilfsmittel, die Stilanalyse und ein Sicherheitstest obligatorisch. Auch das Überprüfen der Geschwindigkeit und des Speicherverbrauches ist in vielen Unternehmen ein verpflichtender Test. Der Test wird automatisch mit dem Effizienztest der Datenintegration durchgeführt, es entsteht kein zusätzlicher Aufwand.

OLAP-System

Das Überprüfen der Dimensionen und Kennzahlen in dem Würfel ist ein sehr auf-wendiges Verfahren. Aufgrund der verschiedenen Kombinationsmöglichkeiten der Dimensionen existiert eine sehr große Anzahl an unterschiedlichen Darstellungen

Kapitel 3 - Testen während der Entwicklung

bzw. Ausprägungen der Kennzahlen. Hier gilt es, die Anzahl der Testfälle auf ein durchführbares Maß zu beschränken. Die reine Prüfung der korrekten Dimensionali-tät ist wenig aufwendig, weil für jede Dimension ein Testfall ausreichend ist. Das Prü-fen der Kennzahl ist jedoch weitaus komplexer. Selbst mit dem Vorgehen nach Rainardi und der Bildung von Äquivalenzklassen können je nach Anzahl der Dimen-sionen und Kennzahlen mehrere hundert oder tausend Testfälle entstehen. Bei be-sonders großen Würfeln ist die Testfallanzahl dann noch weiter einzuschränken, bei-spielsweise indem je Dimension nur die obersten zwei sowie die unterste Hierarchie-ebene geprüft werden.

Auch für das OLAP-System empfiehlt sich der Einsatz visueller Hilfsmittel und der Stilanalyse. Durch die Verwendung einer multidimensionalen Notationsform während der Analyse und Entwurfsphase liegt ein visuelles Hilfsmittel bereits vor. Die vorge-schlagene Ergänzung der Notation um die Konsolidierungsvorschriften bringt weitere Informationen in das Modell mit ein.

Die Berechnung von Speicherbedürfnissen eines Würfels im Vorfeld kann nachträgli-che Anpassungsarbeiten vermeiden. Es empfiehlt sich, die vom Hersteller vorge-schlagenen Tipps für die physikalische Speicherform des Würfels zu berücksichtigen.

Ähnlich wie bei RDBMS gibt es auch für MDBMS eine Vielzahl von „Tuning“-Optionen (z.B. Kompression und Partitionierung), die angewendet werden kann.

Reporting Front-End

Das Überprüfen der Benutzbarkeit zusammen mit den tatsächlichen Anwendern des Reporting Front-Ends ist unverzichtbar. Selbst vermeintliche Kleinigkeiten wie Far-ben, die nicht zum Corporate Design passen, können eine Ablehnungshaltung bei den Anwendern verursachen. In vielen Unternehmen existieren mittlerweile soge-nannte Business Intelligence Competence Center (BICC). Diesem Kompetenzzent-rum gehören ausgewählte Fachbereichsmitarbeiter an, die in dem Unternehmen das Thema BI vorantreiben. Das BICC erteilt Vorgaben zu der Benutzbarkeit und ist so-mit auch für die Abnahme verantwortlich.

Auch Sicherheitskonzepte werden von dem BICC aufgestellt. Aufgrund der Sensibili-tät der Informationen ist ein Sicherheitstest der verschiedenen Benutzerrollen ver-pflichtend. Da es aber für gewöhnlich eine überschaubare Anzahl von Rollen gibt, ist der Sicherheitstest nicht sehr aufwendig.

Kapitel 3 - Testen während der Entwicklung

Automatisierungssystem

Ob der gesamte Job sein Zeitfenster einhält, kann nur unter annähernd realen Be-dingungen verlässlich überprüft werden. Die häufigsten Gründe, warum ein Prozess sein Zeitfenster überschreitet, sind Ressourcenengpässe der verfügbaren Hardware.

Solche Engpässe entstehen durch die vielen parallel laufenden Jobs für die ver-schiedenen Themenbereiche. Es kann daher ausnahmsweise vorkommen, dass der Test erst im Produktivsystem durchgeführt werden kann. Die Liste aller möglichen Fehlersituationen ist im Vorfeld nicht bestimmbar, da auch nichtvorhersehbare exter-ne Einflüsse Fehler verursachen könexter-nen, wie beispielsweise ein Brand im Rechen-zentrum. Somit kann nur geprüft werden, ob ein definierter Fehler, wie die Über-schreitung des Schwellwertes einer Qualitätsregel, während der Datenintegration auch tatsächlich gefangen und berücksichtig wird. Hierfür bietet sich die Ursachen-Wirkungs-Analyse an, um das Reagieren auf einen einzelnen Prozessabbruch zu testen. Eine kontrollflussorientierte Betrachtung kann zusätzliche Aussagen über die Testvollständigkeit geben.

Um stets den Überblick über die Abhängigkeiten der verschiedenen Abläufe sowie deren Zeitfenster zu bekommen, bieten sich visuelle Darstellungsformen an. Wäh-rend des Betriebes kann in einer Fehlersituation (Programmabbruch) mithilfe des Programmablaufplanes schnell festgestellt werden, welche Folgeprozesse von die-sem Abbruch betroffen sind und gegebenenfalls wiederholt werden müssen.

Dass Passwörter nicht in Klarschrift in Startskripten stehen dürfen, zählt zu den all-gemeinen Sicherheitsbestimmungen eines Unternehmens. Eine Prüfung mittels Re-view kann mögliche Verstöße gegen diese Bestimmung aufdecken.