bi testing media_factory_0.10
Post on 15-Jul-2015
454 Views
Preview:
TRANSCRIPT
Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und uns selbst.
„Stimmen meine Zahlen?“
Automatisiertes Testen von BI-Applikationen
mit dem Open Source Framework „Fitnesse“
20.01.2012
Stefan Kirner
inovex GmbH
Senior Consultant BI
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
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; ;
Wer soll wann testen?
• 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
• Entwickler
• Fachabteilung
• Operatoren
• Prozesse
Testen im Team
Besonderheiten von BI Projekten
und Konsequenzen für das Testing
• Focus auf Datentests, weil
höchste Prio
• Persistenz: Tests auf Layer mit
konsistentem Stand
• Volumen: Testen einer
Teilmenge der Daten mit
Mustern
• Inhalt: Testen von Kennzahlen
& Dimensionsdaten
• Laufzeitfehler: Auswertung der
Metadaten!
• BI Projekte sind data-driven
• 80 % Entwicklungsaufwand im
Bereich ETL
• Persistenz in relationalem DWH
• Hohe Datenvolumina
• Erfassung von Metadaten
• Daten fachlicher Natur
• Technische Constraints
• Performance
• Security
• Code
Rahmenbedingungen
Zu testen
Konsequenz für Testing
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
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
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/
Was ist FitNesse?
s. u. http://fitnesse.org
9 9
Projektbeispiel: Einstiegsseite
Projektbeispiel: Definition eines Tests als Wiki-Seite
11 11
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)
Projektbeispiel: Testergebnis
Projektbeispiel: Überblick Regressionstests
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
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
Projektbeispiel: Ergebnis der TestSuite
Bildquelle:Stefan Baudy:-bast-@flickr.com
Gibt es Fragen?
Interessante Informationen
• Fitnesse Acceptance Testing Framework
• http://fitnesse.org/
• DBFit for Test Driven database development
• http://gojko.net/fitnesse/dbfit/
• Buchtipp 1: Test Driven .Net Development with Fitnesse von Gojko Adzik
• amazon.de http://goo.gl/2GuqY
• Buchtipp 2: Agile Datawarehousing von Ralph Hughes
• amazon.de http://goo.gl/82d4z
• Ansprechpartner bei inovex:
• Patrick Thoma (patrick.thoma@inovex.de, Tel. 0173/3181009)
• Stefan Kirner (stefan.kirner@inovex.de, Tel. 0173/3181012)
top related