Automatisiertes Testen von BI-Projekten Teil 10: Namenskonventionen prüfen

Heute geht es beim automatisierten Testen mit dem Testframework von Ceteris mit NBi um die einfache Art der Überprüfung von Namenskonventionen. Sie haben festgelegt, dass in Ihrem Projekt Berichte im Namen keine Unterstriche („_“) enthalten sollen, um die Lesbarkeit für Benutzer zu erhöhen? Sie kennen Ihre Entwickler, die Unterstriche lieben und sie schleichen sich manchmal ein? Oder gibt es in ihrem DWH-Projekt die Konvention, dass Tabellen mit Dim oder Fact und immer mit einem Großbuchstaben beginnen sollen?

Sie können diese Konventionen nun automatisiert immer wieder prüfen.

Automatisiertes Testen von BI-Projekten Teil 7: Performancetests

Heute geht es im Rahmen der Blog-Serie zum Testframework von Ceteris mit NBi um Performancetests. Diese können als eine Teilmenge von Akzeptanztests beim automatisierten Testen regelmäßig mitgeprüft werden.

Zum Beispiel kann die Performance einer Abfrage gegen eine Datenbank ein Indikator dafür sein, wie schnell darauf basierende Berichte dem Benutzer zur Verfügung gestellt werden können. Wird eine gewisse Schwelle überschritten, kann es sein, dass an dieser Stelle gegengesteuert werden muss.

Automatisiertes Testen von BI-Projekten Teil 5: Ergebnisse zweier Abfragen müssen gleich sein

In unserer Blog-Reihe zum Testframework von Ceteris mit NBi geht es heute um den Vergleich zweier Abfrageergebnisse.

Stellen Sie sich vor, Sie möchten gerne, dass die Umsätze je Produkt in ihrem operativen System genauso hoch sind wie im Analysesystem. Wie stellen Sie die Abfragen so bereit, dass die ab sofort automatisch mitgetestet werden?

Automatisiertes Testen von BI-Projekten Teil 3: Testframework mit NBi

In den vergangenen Einträgen zum Thema automatisiertes Testen mit NBi habe ich beschrieben, dass automatisiertes Testen sinnvoll ist und wie schnell sich Fehler einschleichen, die man häufig erst spät bemerkt.

In diesem Eintrag stelle ich das Framework vor, welches Ceteris um NBi herum aufgebaut hat. Das Framework besteht aus drei Teilen: Datenbank, ETL-Paket und Ergebnisbericht.

Nicht nur explizit definierte Einzeltests sind damit möglich, sondern auch aus Metadaten generierte Massentests sind kein Problem.

Automatisiertes Testen von BI-Projekten Teil 2: Kleine aber feine Fehler

Eine klassische Fehlerquelle in BI-Projekten, die manchmal schwer zu entdecken ist, sind SQL-Abfragen, bei denen LEFT und INNER JOINs beim Laden von Daten eine Rolle spielen. Manchmal dürfen nur genau passende Datensätze geladen werden, manchmal soll jede Ausprägung gültig sein. Beides kann seine Berechtigung haben, solange der Umsatz im operativen System mit dem Analysesystem übereinstimmt!

Wie schnell passiert es, dass ein INNER JOIN dafür sorgt, dass Umsätze verschwinden? Je größer die Differenzen, desto leichter ist der Fehler zu entdecken. Aber besonders nervenaufreibend können kleine Abweichungen sein: Von 2 Mio. EUR Umsatz fehlen im Analysesystem 400 EUR. Aber vor 5 Wochen hat doch noch alles gepasst!? Der Controller oder Chef verliert schnell das Vertrauen in das BI-System, wenn sich solche Abweichungen nicht erklären lassen!

Automatisiertes Testen von BI-Projekten Teil 1: Warum testen?

Als Controller oder BI-Entwickler kennt man das: Ein Bericht zeigt eigenartige Zahlen an. Die Daten hatten wir aber schon getestet! Warum passen die Zahlen jetzt nicht mehr?

Nun kann es natürlich sein, dass das Bauchgefühl trügt. Aber oft genug zeigt sich: Änderungen in den darunterliegenden Datenflussprozessen hatten ungeplante Auswirkungen auf den Bericht. Katastrophe!

Auch durch noch so sorgsame manuelle Prüfungen lassen sich manche Fehler nicht vermeiden, die sich durch Anpassungen ergeben.