© Excellent backgrounds/Shutterstock.com
Java Magazin
Testdaten mit Sparx Enterprise Architect

Testdaten mit Sparx Enterprise Architect

In der modernen Softwareentwicklung sind automatisierte Softwaretests mittlerweile gang und gäbe [1]. Leider ist die Erstellung von Testdaten durch den Entwickler speziell bei komplizierter Fachlichkeit des Problembereichs eine aufwändige und fehleranfällige Aufgabe. Anhand des proprietären Tools „Sparx Enterprise Architect“ [2] wird eine Lösung vorgestellt, Testdaten als Objektinstanzdiagramme zu erstellen. Damit ist es möglich, Testdaten in einer intuitiv verständlichen Form anzulegen und automatisch zu dokumentieren. Die inhaltliche Korrektheit dieser abstrakten Darstellung kann leicht von der Fachseite bestätigt werden. Dank mehrerer Sichten auf die Daten lassen sich auch komplexe Testinstanzen übersichtlich und verständlich darstellen.

Dominik Kleine


Wie erstellen Sie Ihre Testdaten? Ein häufig genannter Weg ist das Kopieren eines produktiven Datenbestands. Während des Transports oder im Anschluss werden die Daten anonymisiert und in einem Dateiformat oder beispielsweise als Datenbankinstanz den Entwicklern zugänglich gemacht. Die Entwickler suchen anschließend in den Daten nach passenden Konstellationen für einen bestimmten Testfall, was bei einem komplexen System mit zig Tabellen erfahrungsgemäß deutlich länger als die Implementierung des eigentlichen Testfalls dauert. Je nach Ausmaß des Datenqualitätsproblems befinden sich fachlich falsche Daten in der Kopie. Verwendet ein Entwickler diese fehlerhaften Daten als Grundlage seiner Tests, kann dies zu einer falschen Implementierung führen.

Eine andere Alternative ist die manuelle Erstellung der Testdaten durch den Entwickler. Hier werden häufig entweder reine SQL-Insert-Statements erstellt oder POJOs mit Werten gefüllt und z. B. per JPA in eine Datenbank persistiert. Der Vorteil dieses Ansatzes ist die hohe Flexibilität des Entwicklers, genau die Konstellation erstellen zu können, die er für einen Testfall benötigt, ohne lange nach passenden Daten suchen zu müssen. Nachteilig ist hier allerdings, dass dies nur für kleine Ausschnitte eines Problembereichs praktikabel ist. Referenzen über mehrere Entitäten, wie sie z. B. in Telekommunikations- [3] oder Stromnetzen [4] üblich sind, wären nur unübersichtlich abbildbar. Zudem muss der Entwickler die fachliche Bedeutung der Attribute und der Relationen zwischen den erstellten Entitäten beherrschen, damit er nicht anhand falscher Annahmen fehlerhafte Software implementiert.

Korrekte Testdaten von Fachspezialisten

Damit Tests auf einer validen Grundlage entwickelt werden können, müssen die Testdaten (sowohl die Eingabedaten als auch die Daten, gegen die getestet wird) von der Fachseite entweder direkt erstellt oder zumindest geprüft und freigegeben werden. Dazu ist eine Form der Testdatenbeschreibung notwendig, die sich auf die Fachlichkeit konzentriert und von technischen Details (wie POJOs oder Insert-Statements) abstrahiert.

Gleichzeitig darf die Beschreibung nicht von der tatsächlichen Umsetzung der Testdaten abweichen, da die Dokumentation sonst Aufwand verursacht ohne Mehrwert zu bieten. Dies ist nur durch einen automatisierten Prozess zu erreichen, sodass aus einer fachlichen Testdatenbeschreibung Testdaten in einer für Unit Tests verwendbaren Form werden.

Die Lösung: Objektinstanzdiagramme

Anhand des im F...

Java Magazin
Testdaten mit Sparx Enterprise Architect

Testdaten mit Sparx Enterprise Architect

In der modernen Softwareentwicklung sind automatisierte Softwaretests mittlerweile gang und gäbe [1]. Leider ist die Erstellung von Testdaten durch den Entwickler speziell bei komplizierter Fachlichkeit des Problembereichs eine aufwändige und fehleranfällige Aufgabe. Anhand des proprietären Tools „Sparx Enterprise Architect“ [2] wird eine Lösung vorgestellt, Testdaten als Objektinstanzdiagramme zu erstellen. Damit ist es möglich, Testdaten in einer intuitiv verständlichen Form anzulegen und automatisch zu dokumentieren. Die inhaltliche Korrektheit dieser abstrakten Darstellung kann leicht von der Fachseite bestätigt werden. Dank mehrerer Sichten auf die Daten lassen sich auch komplexe Testinstanzen übersichtlich und verständlich darstellen.

Dominik Kleine


Wie erstellen Sie Ihre Testdaten? Ein häufig genannter Weg ist das Kopieren eines produktiven Datenbestands. Während des Transports oder im Anschluss werden die Daten anonymisiert und in einem Dateiformat oder beispielsweise als Datenbankinstanz den Entwicklern zugänglich gemacht. Die Entwickler suchen anschließend in den Daten nach passenden Konstellationen für einen bestimmten Testfall, was bei einem komplexen System mit zig Tabellen erfahrungsgemäß deutlich länger als die Implementierung des eigentlichen Testfalls dauert. Je nach Ausmaß des Datenqualitätsproblems befinden sich fachlich falsche Daten in der Kopie. Verwendet ein Entwickler diese fehlerhaften Daten als Grundlage seiner Tests, kann dies zu einer falschen Implementierung führen.

Eine andere Alternative ist die manuelle Erstellung der Testdaten durch den Entwickler. Hier werden häufig entweder reine SQL-Insert-Statements erstellt oder POJOs mit Werten gefüllt und z. B. per JPA in eine Datenbank persistiert. Der Vorteil dieses Ansatzes ist die hohe Flexibilität des Entwicklers, genau die Konstellation erstellen zu können, die er für einen Testfall benötigt, ohne lange nach passenden Daten suchen zu müssen. Nachteilig ist hier allerdings, dass dies nur für kleine Ausschnitte eines Problembereichs praktikabel ist. Referenzen über mehrere Entitäten, wie sie z. B. in Telekommunikations- [3] oder Stromnetzen [4] üblich sind, wären nur unübersichtlich abbildbar. Zudem muss der Entwickler die fachliche Bedeutung der Attribute und der Relationen zwischen den erstellten Entitäten beherrschen, damit er nicht anhand falscher Annahmen fehlerhafte Software implementiert.

Korrekte Testdaten von Fachspezialisten

Damit Tests auf einer validen Grundlage entwickelt werden können, müssen die Testdaten (sowohl die Eingabedaten als auch die Daten, gegen die getestet wird) von der Fachseite entweder direkt erstellt oder zumindest geprüft und freigegeben werden. Dazu ist eine Form der Testdatenbeschreibung notwendig, die sich auf die Fachlichkeit konzentriert und von technischen Details (wie POJOs oder Insert-Statements) abstrahiert.

Gleichzeitig darf die Beschreibung nicht von der tatsächlichen Umsetzung der Testdaten abweichen, da die Dokumentation sonst Aufwand verursacht ohne Mehrwert zu bieten. Dies ist nur durch einen automatisierten Prozess zu erreichen, sodass aus einer fachlichen Testdatenbeschreibung Testdaten in einer für Unit Tests verwendbaren Form werden.

Die Lösung: Objektinstanzdiagramme

Anhand des im F...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang