Infrastructure as (real) Code – Manage your K8s resources with Pulumi
Bi testing media_factory_0.10
1. „Stimmen meine Zahlen?“
Automatisiertes Testen von BI-Applikationen
mit dem Open Source Framework „Fitnesse“
20.01.2012
Stefan Kirner
inovex GmbH
Senior Consultant BI
Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und uns selbst.
2. Kurzvorstellung inovex GmbH
• IT-Dienstleister in Pforzheim, München und Köln
• 1999 gegründet, heute 80 Mitarbeiter
• Portfolio:
• IT Consulting
• Business Intelligence,
• Application Development,
• Systems Operations
• Training
• Positionierung: Qualität, Technologiekompetenz, Kundenzufriedenheit
• Kunden: Marktführer aus DAX 100 und gehobenem Mittelstand,
z. B. 1&1, Bosch, buch.de, Daimler, DB Schenker, Ehrmann, EnBW,
GMX, Mahle, maxdome, Porsche, web.de
• mehr unter www.inovex.de
3. Warum automatisiert testen in BI Projekten?
oder „was BI von Softwareentwicklung lernen kann“
• Agiles Arbeiten auch im DWH Bereich
Ständige iterative Weiterentwicklung
Transparenz notwendig
Schnelles Feedback vom Kunden
Viele Änderungswünsche
Definition of Done
Sicherstellung hohe Qualität
Continuous Integration
Automatisierbare Tests
• Single Source of Truth
Vertrauen muss aufgebaut werden
• Wechselnde Team Members
Tests müssen reproduzierbar sein
Bildquelle: roomiccube@flickr.com; ;
4. Wer soll wann testen?
• Entwickler
• Fachabteilung
• Operatoren
• Prozesse
Testen im Team
• Vor und nach der Entwicklung
• Vor dem Deployment auf das System,
auf dem alles „done“ ist
• Nach dem Deployment auf dem Zielsystem
• Regelmäßig unbeaufsichtigte Ausführung
Automatisierung erforderlich
Bildquelle: wanderlinse@flickr.com. kheelcenter@flickr.com
5. Besonderheiten von BI Projekten
und Konsequenzen für das Testing
Rahmenbedingungen Konsequenz für Testing
• BI Projekte sind data-driven • Focus auf Datentests, weil
• 80 % Entwicklungsaufwand im höchste Prio
Bereich ETL • Persistenz: Tests auf Layer mit
• Persistenz in relationalem DWH konsistentem Stand
• Hohe Datenvolumina • Volumen: Testen einer
• Erfassung von Metadaten Teilmenge der Daten mit
Mustern
Zu testen • Inhalt: Testen von Kennzahlen
• Daten fachlicher Natur & Dimensionsdaten
• Technische Constraints • Laufzeitfehler: Auswertung der
• Performance Metadaten!
• Security
• Code
6. Welche Daten als Quelle nehmen?
• Daten direkt aus Quellsystemen?
+ Immer auf aktuellem Stand des DBMS
+ Keine Anpassung der Ladestrecken für Tests
− Keine definierten Zustände der Daten
− Existenz hängt von Quellsystem ab
• Daten auf separater TestDB der Quelle?
+ Definierte Zustände möglich
+ Kontrolle über Existenz der zu testenden Daten
− Doppelter Aufwand bei DBMS Changes
− Anpassung Ladestrecken für Tests
• Spezielle Test Daten innerhalb der Quellsysteme?
+ Alle obigen Vorteile
− Darf dem Quell- und abhängigen Systemen
keine Probleme machen
Bildquelle: avlxyz@flickr.com
7. Wie erstellt man definierte Zustände
innerhalb der Daten?
• Wiederholbarkeit der Tests ist wichtig
• Szenarien hängen ab von:
• Änderung der Quelldaten
• Zustand der Zieldaten
• Abbildung dieser Situationen in ETL Logik
• Möglichst alle Szenarien testen
• Benötigen Methoden für das
• Ändern der Testmuster in den Quelldaten /
Zieldaten
• Modaler Aufbau für Wiederholbarkeit
• Datenänderungen via Stored Procs
• Anstoßen ETL via SQL Server Agent
Bildquelle: palindrome6996@flickr.com
8. Wobei hilft uns da FitNesse?
• Testdefinition in wiki statt unit tests in Hochsprache
• Tests basieren auf Tabellen mit erwarteten Werten
• Zugriff auf Datenbanken mit dbfit
• Webbasierte Oberfläche
• Gruppierung von Tests
• Tests werden im xml-Format gespeichert
• Simples Setup
• Kommandozeilenaufrufe
• Erweiterbar durch eigene Fixtures
• Open Source & Free
Bildquelle: http://fitnesse.org/
12. Implementierung des Tests als Stored Procedure
Vorteile:
• rDBMS ist Homebase der BI Entwickler
• Einfache Bereitstellung von Methoden
zur Testdatenverwaltung
• Inhaltliche Vereinheitlichung Daten von
Quelle und Ziel in Views (z. B. Datum,
Dezimalstellen)
• Unterstützende Methoden in Functions
• Kapselung der Testlogik
• Rückgabe 0/1 erleichtert Interpretation
Tip:
• Datenrückgabe in XML erleichtert den
Vergleich (alle Daten in einem Feld)
15. Wie testet man im Team?
Integration in die Entwicklungsumgebung
• Daten für Tests in xml Source Control (SC)
• Subfolder Recent Changes und Error Logs
nicht in SC
• Lokale Runtime für Entwickler
(keine Installation, jdk)
• Zentrales abgekoppeltes Fitnesse
als Windows Service
• Automatisierte Tests
• Adhoc Tests
• Zugriff für Nicht-Entwickler
16. Wie geht das Ganze „elektrisch“?
Automatisierten Starten von Tests
• Kommandozeilentool Testrunner
• Steuerung über beliebigen Scheduluer, z.B.
• SQL Server Agent
• crontab
• Ergebnisse in xml/html
• Parsing xml für weitere Verarbeitung
• optional: Senden via Database Mail
Bildquelle: rehacare@flickr.com
