Testdaten und Testdatenmanagement: Vorgehen, Methoden und Praxis

Von Janet Albrecht-Zölch

Testdaten werden in jedem Softwareentwicklungsprojekt benötigt. Das Management von Testdaten stellt sicher, dass diese jederzeit bedarfs-, zeit- und regelgerecht bereitstehen, und erhöht so die Effizienz und die Qualität des Testens.
Dieses Buch bietet eine umfassende Einführung in Testdaten und ein effizientes Testdatenmanagement. Dabei werden sowohl fachliche als auch technische Konzepte vorgestellt. Es gliedert sich in drei Teile:

- Teil I erläutert die Eigenschaften von Testdaten, die Anforderungen, Probleme und Risiken im Umgang mit ihnen sowie das Gewinnen und Archivieren. Auch auf Regelungen zum Datenschutz und auf Testdaten in der Cloud wird eingegangen.
- Teil II behandelt Modelle und Best Practices für das Testdatenmanagement, die Organisation und Test-Rollen sowie Werkzeuge und Metriken für Testdaten und Testdatenmanagement.
- Teil III enthält ein Vorgehen zum Einführen bzw. Verbessern eines Testdatenmanagements sowie Checklisten, Mustergliederungen und Fragenkataloge.Zahlreiche Erfahrungsberichte und Praxisbeispiele geben Einblicke in die reale Welt des Testdatenmanagements und erlauben dem Leser einen direkten Transfer zu seiner täglichen Arbeit.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 12. Jan. 2018
• ISBN: 9783960881933

Buchvorschau

1Einleitung

Etwa 30 bis 50 % des gesamten Testaufwands entfallen auf das Erzeugen und Pflegen von Testdaten [Chac11].

Testdaten als Automatisierungshindernis

40 % der Befragten im World Quality Report nannten die Verfügbarkeit der Testdaten und der Testumgebung als Hindernis für die Testautomatisierung [WQR17, S. 41]. Damit landeten Testdaten und Testumgebung auf Platz 2 der größten Hindernisse – direkt nach dem Mangel an geeigneten Automatisierungswerkzeugen (wurde von 45 % der Teilnehmer genannt [WQR17, S. 41]).

Echtdaten!

35 % der Befragten erstellen neue Testdaten mithilfe von Automatisierungswerkzeugen, 17 % davon nutzen Eigenentwicklungen. 16 % legen ihre Testdaten anhand von Spreadsheets manuell an. Nur noch 11 % erstellen die Testdaten über grafische Benutzungsoberflächen (GUI). 28 % nutzen Kopien der Produktionsdaten als Testdaten, wobei 13 % diese zuvor nicht weiterbearbeiten (also auch nicht anonymisieren). 18 % setzen ihre Testdaten nach jeder Iteration zurück, um sie erneut verwenden zu können [WQR17, S. 49].

Diese Zahlen zeigen, welche Herausforderung die Testdaten im Softwaretest darstellen. Meine Erfahrungen decken sich in etwa damit.

Ziele und Aufbau des Buches

Ziele des Buches

Im Wesentlichen verfolgt dieses Buch folgende drei Ziele:

Es bereitet bisher verstreutes theoretisches und praktisches Wissen über Testdaten und Testdatenmanagement auf und bringt die einzelnen Arbeiten in einen Zusammenhang.

Zahlreiche Erfahrungsberichte und Praxisbeispiele zeigen Einblicke in die reale Welt des Testdatenmanagements.

Das Buch bietet aufgrund der vorgestellten Methoden, Vorgehensweisen und Checklisten konkrete Unterstützung in der täglichen Arbeit.

Aufbau des Buches

Das Buch gliedert sich in drei Teile.

Teil I (Kapitel 2 bis 6) beginnt mit den Testdaten und beantwortet folgende Fragen: Was versteht man unter Testdaten? Welche Anforderungen werden an Testdaten gestellt? Welche Eigenschaften weisen Testdaten auf? Welche Herausforderungen bergen sie? Wie kann man Testdaten gewinnen, nutzen, archivieren und was muss man in Bezug auf den Datenschutz beachten?

Der erste Teil definiert wesentliche Begriffe und stellt wichtige Methoden vor; er schafft Grundlagen für Teil III. Daher sei allen Lesern zumindest ein Überfliegen des ersten Teils empfohlen.

Teil II (Kapitel 7 bis 13) behandelt die verschiedenen Aspekte des Managens von Testdaten. Auch dieser Teil beginnt mit der Klärung des Begriffs, hier des Testdatenmanagements, und einer Abgrenzung zu Datenmanagement und Konfigurationsmanagement. Überspringen wird nicht empfohlen. Des Weiteren stellt der Teil Modelle und Best Practices vor. Diese dienen der Erweiterung unseres Horizonts und als Anregungen für die eigene Testdatenmanagementpraxis. Im Testdatenmanagement erfahrene Leser können diese querlesen und bei Bedarf (z.B. bei der Lektüre des Kapitels 9 zum konkreten Vorgehen) darauf zurückkommen. Kapitel 10 über Rollenkonzepte für das Testdatenmanagement zeigt, dass es mit dem Erstellen von Testdaten längst nicht getan ist. Ein Kapitel ist den Werkzeugkategorien gewidmet (Kapitel 11), ein weiteres den Metriken für Testdaten und für das Testdatenmanagement (Kapitel 12). Erfahrene, die sich mit Testdatenmanagement-Werkzeugen oder Metriken gut auskennen, können diese Kapitel überfliegen.

Den Schluss dieses zweiten Teils bildet Kapitel 13, das Testdaten und Testdatenmanagement in verschiedenen Kontexten betrachtet. Wer sich auf seine konkrete Berufspraxis konzentrieren möchte, kann einzelne Abschnitte des Kontext-Kapitels überspringen. Sie sind als Blick über den Tellerrand gedacht.

Teil III (Kapitel 14 und 15) baut auf den ersten beiden Teilen auf. Er stellt Ihnen ein Vorgehen zum Verbessern eines Testdatenmanagements vor, denn überall dort, wo getestet wird, findet bereits ein Testdatenmanagement statt. Checklisten, Fragenkataloge und Mustergliederungen bieten Hilfe für die Umsetzung.

Erfahrungsberichte, Beispiele und Lessons Learned runden die Kapitel ab.

Was das Buch bietet – und was nicht

Was das Buch bietet

Dies ist das erste deutschsprachige Buch, das sich direkt dem Thema Testdaten und Testdatenmanagement widmet. Es führt detailliert in dieses Thema ein. Damit unterstützt dieses Werk Softwaretester und Interessierte in einem bisher nur am Rande betrachteten Bereich – nämlich im Umgang mit Testdaten. So ermöglicht es dem Leser1, sich einen Eindruck darüber zu verschaffen, wo das eigene Testprojekt bzgl. Testdaten und Testdatenmanagement steht.

Dieses Buch soll Anregungen bieten. Sie werden an keiner Stelle dieses Buches lesen, dass diese oder jene Vorgehensweise die einzig richtige darstellt. Da jedes Softwareentwicklungsprojekt einzigartig ist und jedes Unternehmen seine eigenen Regeln schreibt, kann es keine Lösung geben, die wirklich auf alle passt. Daher spreche ich bestenfalls Empfehlungen aus.

Was das Buch nicht bietet

Konkrete Testdatenmanagement-Werkzeuge werden in diesem Buch nicht behandelt, denn das Buch beschränkt sich auf methodische Aspekte, und der Markt für Softwaretools ist sehr schnelllebig.

Dieses Buch bietet Ihnen keine maßgeschneiderte Testdatenmanagementlösung für genau Ihr spezifisches Projekt – dafür aber einen Vorschlag für eine Vorgehensweise, die Ihnen und Ihren Vorgesetzten genug Freiraum bieten sollte.

ISTQB® Certified Tester, GTB Certified Tester

Dieses Buch deckt keinen der Lehrpläne des »ISTQB® Certified Tester«-Programms ab. Überschneidungen sind jedoch möglich. Das Buch basiert im Wesentlichen auf den dort gelehrten Inhalten und ist insofern als eine Ergänzung zur vorhandenen Literatur zu verstehen.

Während der Entstehung dieses Buches erstellte eine Arbeitsgruppe des ASQF e.V. einen Zertifizierungslehrplan für das Testdatenmanagement. Dieser ist seit April 2017 auf den Seiten des German Testing Board e.V. veröffentlicht als GTB Certified Tester Foundation Level Test Data Specialist [GTB+17a]. Über den Inhalt des Lehrplans führt das Buch weit hinaus.

Einsteigern in das Thema Softwaretest sei zunächst die Lektüre von »Basiswissen Softwaretest. Aus- und Weiterbildung zum Certified Tester – Foundation Level nach ISTQB-Standard« [SpLi12] und ggf. auch »Praxiswissen Softwaretest – Testmanagement. Aus- und Weiterbildung zum Certified Tester – Advanced Level nach ISTQB-Standard« von Spillner, Roßner, Winter und Linz [SRWL08] empfohlen.

Beispielanwendung: Mein Onlineshop

Um verschiedene Sachverhalte anhand von Beispielen illustrieren zu können, stelle ich Ihnen hier die Beispielanwendung Mein Onlineshop vor. Es handelt sich um einen klassischen Onlineshop, über den verschiedene Artikel zum Kauf angeboten werden.

Ähnlichkeiten mit eventuell existierenden oder gar gleichnamigen Shops sind zufällig und nicht beabsichtigt.

Unsere Beispielanwendung Mein Onlineshop besteht aus folgenden Teilen:

Shop (Website; repräsentiert Mein Onlineshop im Internet.)

Artikelverwaltung (System enthält Angaben zu allen im Shop verfügbaren oder ab einem bestimmten Zeitpunkt verfügbaren Artikeln mit Artikelnummer, Abbildungen, Artikelname und -beschreibung, Preis, Rabattfähigkeit.)

Kundenverwaltung (Stammdaten der registrierten Kunden: Kundennummer, Vor- und Zuname, Geburtsdatum, Post- und Lieferanschrift, gekaufte Produkte)

Bestellungsverwaltung (Kundennummer, Bestellungsnummer, zur Bestellung alle Artikel mit Menge und Preis, Rechnungsnummer)

Abrechnungsmodul (Rechnungsnummer, Kundennummer, Bestellnummer, Rechnungsbetrag, …)

Kundenservice (Webanwendung für den Kundenservice; anrufende Kunden werden in Echtzeit per Kundennummer oder Name und Geburtsdatum im System identifiziert. Die Anwendung zeigt dem Kundenservicemitarbeiter für diesen Kunden alle abgeschlossenen und laufenden Bestellungen, offene und bezahlte Rechnungen sowie Retouren.)

Data Warehouse

Nicht in allen Fällen lässt sich diese Beispielanwendung sinnvoll einsetzen. Daher finden sich in diesem Buch auch davon abweichende Beispiele.

Teil I

Testdaten

2Testdaten – ein Überblick

Testdaten sind Bestandteil der Testumgebung. Dort dienen sie unterschiedlichen Zwecken. Dieses Kapitel bietet Ihnen einen Überblick über die verschiedenen gebräuchlichen Begriffe für Testdaten und beleuchtet die Bedeutung ihrer Metadaten.

Dieses Kapitel schafft ein Basisverständnis über den Testdaten-Begriff, wie er in diesem Buch verwendet wird, es sollte daher zumindest quergelesen werden.

2.1Begriffe Testdaten, ideale Testmenge, gute Testdaten

Softwaresysteme verarbeiten elektronisch Daten, basierend auf dem sogenannten EVA-Prinzip: Eingabe, Verarbeitung, Ausgabe. Wir geben Daten ein, das (zu testende) System verarbeitet diese und gibt Daten wieder aus. Zum Testen von Software, genauer zum Prüfen des Verhaltens der Software, verwendet man Testdaten.

Eckehard Kruse formuliert treffend: »Testdaten ermöglichen die Durchführung von Tests« [Krus11]. Testdaten werden benötigt, um Testfälle gegen das zu testende System oder Teile davon laufen zu lassen.

Abstrakte Testfälle enthalten zunächst keine Testdaten und können daher nicht ausgeführt werden. Indem man einen abstrakten Testfall um Testdaten ergänzt, entstehen ein oder mehrere ausführbare konkrete Testfälle. Die konkreten Testfälle verwenden Daten als Eingabe, die Eingabedaten, und enthalten Angaben über die erwarteten Ausgaben, die Ausgabedaten. Darüber hinaus benötigt das Durchführen konkreter Testfälle weitere Daten im zu testenden System. Dies können z.B. Stammdaten oder Konfigurationen sein.

Alle Daten in einer Testumgebung sind Testdaten. Darunter fallen Werte für Konfigurationsparameter ebenso wie Ausgabedaten nach Durchführung von Testfällen.

Doch was versteht man im Detail unter Testdaten? Und wann sind Testdaten gute Testdaten? Wie sieht die ideale Testmenge aus?

2.1.1Testdaten

Im Glossar des German Testing Board findet sich folgende Definition von Testdaten:

Definition: Testdaten (nach German Testing Board)

»Daten, die (z.B. in einer Datenbank) vor der Ausführung eines Tests existieren, und die die Ausführung der Komponente bzw. des Systems im Test beeinflussen bzw. dadurch beeinflusst werden.« [GTB+15, S. 66]

Damit umfasst diese Definition ausschließlich vor oder während der Testausführung existierende Testdaten, nicht aber die Daten, die bei der Ausführung eines Testfalls entstehen.

Im Lehrplan zum Certified Test Data Specialist (GTB) heißt es in Ergänzung der vorgenannten Definition: »Testdaten sind konkrete Werte von Datenobjekten, die zur Ausführung eines Testobjekts benötigt werden. Sie können z.B. in Dateiform, in Form von Datenbanktabellen oder in Listenform vorliegen« [GTB+17a, S. 17].

In »Basiswissen Softwaretest« formulieren die Autoren Andreas Spillner und Tilo Linz [SpLi12, S. 263] darüber hinaus folgende Definition zu Testdaten:

Definition: Testdaten (nach Andreas Spillner und Tilo Linz)

»Eingabe- und Zustandswerte für ein Testobjekt und die Sollwerte nach Ausführung des betreffenden Testfalls« und »Daten, die (z.B. in einer Datenbank) vor der Ausführung eines Tests existieren und die Ausführung der Komponente bzw. des Systems im Test beeinflussen bzw. dadurch beeinflusst werden.« [SpLi12, S. 263]

Abb. 2–1 Testdaten-Begriffe

Ein sehr ähnliches Begriffsverständnis findet sich in Kruses oben erwähntem White Paper zum Testdatenmanagement [Krus11].

In den vorgestellten Begriffen ist der Zusammenhang zwischen Testdaten und Testumgebung nicht berücksichtigt. ISO 29119 betrachtet die Testdaten als Bestandteil der Testumgebung.

Die folgende Definition, basierend auf den vorgestellten TestdatenBegriffen, formuliert etwas expliziter:

Testdaten-Begriff

Definition: Testdaten

Testdaten bezeichnen alle Daten, die in die Testumgebung eingegeben (Eingabe- und Zustandswerte für ein Testobjekt) oder aus ihr ausgelesen werden (Sollwerte, Istwerte) sowie alle Daten, die in der Testumgebung vorhanden sind bzw. verwendet werden (z.B. in einer Datenbank, aber auch Umgebungsdaten wie Konfigurationsdateien, Ports usw.).

Testdaten beeinflussen die Ausführung der zu testenden Komponente bzw. des zu testenden Systems oder werden dadurch beeinflusst.

Einordnung

Folgt man dem Glossar des ISTQB® [GTB+15], so zählen die Testdaten zu den Testmitteln:

Definition: Testmittel (nach German Testing Board)

»Alle Artefakte, die während des Testprozesses erstellt werden und die erforderlich sind, um die Tests zu planen, zu entwerfen oder auszuführen. Dazu gehören: Dokumente, Skripte, Eingabedaten, erwartete Ergebnisse, Prozeduren zum Aufsetzen und Aufräumen von Testdaten, Dateien, Datenbanken, Umgebungen und weitere zusätzliche Software- und Dienstprogramme, die für das Testen verwendet werden.« [GTB+15]

Die obigen Definitionen beschreiben, wann Testdaten vorhanden sind und worauf sie Einfluss nehmen. Außerdem erfahren wir etwas über die Aufgabe der Testdaten, nämlich ihre Verwendung als Eingabe- und Zustandswerte für ein Testobjekt und als Sollwerte für Testfälle.

Testdaten versus Testdaten(mengen)

Wenn von Testdaten die Rede ist, dann sind entweder eine Menge von Testdaten oder auch Testdaten eines konkreten Testfalls oder gar einzelne Testdaten (Testdatum) gemeint.

Welche Alternative zutrifft, sollte aus dem jeweiligen Kontext hervorgehen. Wo eine explizite Unterscheidung notwendig ist, finden Sie diese im Text dargestellt.

2.1.2Gute Testdaten

Nachdem der Begriff der Testdaten eingeführt ist, betrachten wir einen Qualitätsaspekt: Wann sind Testdaten gute Testdaten?

Gute Testdaten, bezogen auf einen konkreten Testfall, sind diejenigen Testdaten, die das mit dem Testfall verfolgte Ziel unterstützen.

Doch was sind gute Testdaten im Sinne einer Menge von Testdaten?

Bei Redwine [Redw83, S. 192 o.] findet sich eine Definition für qualitativ gute Testdaten; er bezieht sich auf eine Menge. Demnach stellen gute Testdaten eine sinnvoll bemessene Menge von Daten dar, die alle oder fast alle Teile der Software ausführen, sodass die Resultate unterscheiden zwischen korrektem Funktionieren und möglichen Fehlern [Redw83, S. 192 o.].

Um mit dieser Menge an Daten alle bzw. fast alle1 Softwareteile ausführen zu können, müssen Testdaten enthalten sein, die – bezogen auf Anwendungsfälle – sowohl den Normalfall als auch Alternativen sowie Sonderfälle und Fehlerfälle umfassen.

Abb. 2–2 Gute Testdaten

Dies geht implizit auch aus der zweiten der von Chace genannten Eigenschaften hervor. Gute Testdaten, im Sinne einer Menge von Testdaten, lassen sich nach Chace [Chac11] mit zwei wesentlichen Eigenschaften beschreiben:

Sie repräsentieren die gesamte Bandbreite der Produktionsdaten oder »Echtweltdaten«.

Sie sind angemessen dimensioniert, sodass sie die Anforderungen des Tests unterstützen.

Testdaten zu Testobjekt

Die oben dargestellten Ausführungen zu guten Testdaten sind nicht nur auf das Gesamtsystem als Testobjekt, sondern auch auf das jeweils betrachtete Testobjekt (auch Systemteile) sowie das verfolgte Testziel zu beziehen. So unterscheiden sich Testdaten für Testfälle im Regressionstest einer bestimmten Komponente von Testdaten für Testfälle in einem ausführlichen funktionalen Test während der Entwicklung dieser Komponente.

Zum einen sprechen wir hier wieder über die Menge an Testdaten, die in letzterem Falle umfangreicher ausfällt. Zum anderen meint Testdaten die Daten für einen einzelnen Testfall, wenn es darum geht, anhand der Resultate zwischen korrektem oder fehlerhaftem Verhalten zu unterscheiden.

Folgende Definition fasst die Aspekte guter Testdaten zusammen:

Definition: Gute Testdaten

Bezogen auf ein bestimmtes Testobjekt und ein bestimmtes Testziel werden Testdaten gute Testdaten genannt, wenn sie folgende Eigenschaften aufweisen:

Sie bestehen aus einer sinnvoll bemessenen Menge von Daten.

Sie repräsentieren die gesamte Bandbreite der Produktionsdaten (»Echtweltdaten«) und umfassen – ergänzend zu den Testdaten aus Produktionsdaten – Daten für Normalfälle, Sonder- und Fehlerfälle.

Sie bewirken in Testfällen die Ausführung aller oder fast aller Teile des Testobjekts. Die erzielten Testresultate unterscheiden zwischen korrektem Verhalten und möglichen Fehlern.

2.1.3Ideale Testmenge

Während der Begriff der guten Testdaten eher auf Eigenschaften fokussiert, steht beim Begriff der idealen Testmenge deren Wirkung im Vordergrund.

Die ideale Testmenge zu einem Programm weist nach Appelrath und Ludewig (Skriptum Informatik, [ApLu99]) folgende zwei Merkmale auf:

»Wenn das Programm korrekt ist, dann liefert es für alle Eingaben aus der Testmenge korrekte Ergebnisse.

Wenn umgekehrt das Programm für alle Eingaben aus der Testmenge korrekt arbeitet, so ist das Programm auch für alle anderen Eingaben korrekt.«

Leider können Appelrath und Ludewig uns nicht sagen, wie wir die ideale Testmenge bestimmen können, denn dafür existiert kein allgemeines Verfahren.

Sie ahnen es sicher: Der Grund dafür liegt darin, dass es die ideale Testmenge nicht gibt. Denn diese Testmenge müsste zeigen, dass die zu testende Anwendung korrekt arbeitet – und zwar korrekt in Bezug auf die Spezifikation, gegen die getestet wird. Die ideale Testmenge müsste also auch dazu führen, dass vergessene, fehlerhafte oder missverstandene Anforderungen durch den Test aufgedeckt werden. Welche Testmenge kann das leisten?

Wozu dann einen Abschnitt über ideale Testmengen schreiben und lesen, wenn es diese gar nicht gibt? Um uns genau das klarzumachen.

Halbwegs ideale Testmenge

Immerhin führen bekannte Vorgehensweisen zu einer »halbwegs idealen« Testmenge. Die halbwegs ideale Testmenge ist so beschaffen, dass »man, wenn das Programm sie ohne Fehler verarbeitet, auf seine Korrektheit hoffen kann« [ApLu99].

Mehr als Hoffnung bleibt auch nicht, denn erstens warnt der 7. Grundsatz des Softwaretestens vor dem Trugschluss, keine Fehler bedeute ein brauchbares System [SpLi12, S. 38], und zweitens ist vollständiges Testen nicht möglich.

»Darum bleibt der Kern des Tests, die Wahl der Testdaten, eine sehr kreative Tätigkeit, die viel Erfahrung voraussetzt und ausgesprochen zeitaufwendig ist« [ApLu99].

Zur Auswahl von Testfällen (inklusive der Testdaten) und dem Aufbau einer halbwegs idealen Testmenge siehe Anregungen in Abschnitt 5.1.3.

Abb. 2–3 Ideale Testmenge

Welche Daten wir zu den Testdaten zählen und welche weiteren Unterscheidungen möglich sind, wird nachfolgend erläutert.

2.2Kategorien von Testdaten

Es gibt unterschiedliche Kategorien von Testdaten. Eine Unterscheidung ist in mehreren Hinsichten nützlich. Sie ermöglicht zum Beispiel eine strukturierte Anforderungsermittlung zu Testdaten und erlaubt es, sich einen Überblick über benötigte Testdaten zu verschaffen. Darüber hinaus gehen aus der Kategorie der Einsatzort und der Verwendungszweck der Testdaten hervor. Wie wir später sehen werden, lässt die Kategorie auch Rückschlüsse auf den spätesten Zeitraum der Bereitstellung dieser Testdaten zu.

Die folgenden beiden Definitionen von Testdaten fokussieren auf die Art der Testdaten. Hier geht es u.a. darum, was die Testdaten »beinhalten«.

2.2.1Kategorien nach Reimann

Reimann [Reim13] unterscheidet folgende drei Kategorien von Testdaten:

Testfalldaten,

Bestandsdaten/Historiendaten und

Umgebungsdaten.

Eingabedaten, Zustandsdaten, Ergebnisdaten und erwartete Ergebnisdaten (Sollwerte) nennt er als Beispiele für Testfalldaten.

Als Bestandsdaten/Historiendaten definiert er z.B. Stammdaten, Tarifdaten, Ergebnisdaten, historische Daten.

Abb. 2–4 Kategorien von Testdaten (nach Reimann)

Zu den Umgebungsdaten zählt er Systemdaten und PLZ-Verzeichnisse, aber auch Benutzerkennungen sowie die damit im System verbundenen Rechte.

2.2.2Kategorien nach Chace

Chace [Chac11] formuliert eine sehr ähnliche, aber detailliertere Klassifizierung der Testdaten:

Umgebungsdaten (»Environmental Data«)

Basisdaten (»Baseline Data«)

Eingabedaten (»Input Data«)

Demnach stellen die Umgebungsdaten nach [Chac11] den Ausführungskontext der Testfälle dar. Sie umfassen:

Systemkonfiguration: Betriebssystem, Datenbanken, Applikationsserver, Hardwarekonfigurationen usw.

Benutzerautorisierung, -authentifizierung, Berechtigungsnachweise: Benutzerkennungen, Passwörter, Systemzugriffslevel für generische, rollenbasierte oder testspezifische Benutzer

Konfigurationsmöglichkeiten: Port-Einstellungen der Firewall, Einstellungen der Applikationsserver, Speicherverwaltung (»machineresource allocation«)

Abb. 2–5 Kategorien von Testdaten (nach Chace)

Den Ausgangspunkt für die Testausführung und Grundlage für die erwarteten Ergebnisdaten bilden nach [Chac11] die Basisdaten. Aus Vorbedingungen von Testfällen, Datenmerkmalen und Testart ergibt sich demnach eine initiale Menge an Basisdaten.

Als Eingabedaten bezeichnet [Chac11] die Daten, die Tester als Bestandteil eines Testfalls in das zu testende System eingeben, um dessen Reaktion zu prüfen.

In den vorangegangenen Abschnitten wurden die Testdaten in Gruppen unterteilt, die als Kategorien bezeichnet wurden. Im folgenden Abschnitt tragen die Testdatengruppen den Namen Testdatentyp. Bei Lichte betrachtet läuft es auf dasselbe hinaus.

2.2.3Testdatentypen nach Jagers und Kollegen

Jagers und Kollegen unterteilen in [JPH+09] die Testdaten ebenfalls in drei Gruppen: Konfigurationsdaten (»configuration data«), Operationsdaten (»operational data«), Eingabe- und Ausgabedaten (»input and output data«).

Mithilfe der Konfigurationsdaten wird die Testumgebung so eingestellt, dass Tests durchgeführt werden können.

Als Operationsdaten bezeichnen [JPH+09] eine ausgewählte Menge an Daten, die einen definierten Startpunkt darstellen. Dieser bildet die Ausführungsbasis für einen bestimmten Testfall oder ein bestimmtes Testszenario.

Testdaten, die im Zuge der Testfallausführung erzeugt, bearbeitet oder gelöscht werden, werden als Eingabe- und Ausgabedaten bezeichnet.

Abb. 2–6 Testdatentypen (nach [JPH+09])

Gemeinsamkeiten

Die drei vorgestellten Unterscheidungen von Testdaten ähneln sich. Sie unterteilen die Daten aus der Sicht des Testfalls in Daten, die eingegeben oder ausgegeben werden (Testfalldaten; Eingabedaten; Eingabe- und Ausgabedaten), und Daten, die im System vorhanden sein müssen, damit der Testfall ausgeführt werden kann (Bestandsdaten/Historiendaten; Basisdaten; Operationsdaten und Umgebungsdaten; Konfigurationsdaten).

2.2.4Definition Testdatenkategorien

In diesem Buch sind Kategorien von Testdaten unter Verwendung der oben vorgestellten Unterscheidungen wie folgt definiert:

Definition: Testdatenkategorien

Testdatenkategorien unterscheiden Testdaten nach ihrer Rolle, die sie in Bezug auf den Testfall einnehmen.

Folgende Testdatenkategorien werden unterschieden:

Testfalldaten

Bezeichnen die mit der Ausführung des Testfalls eingegebenen, bearbeiteten, gelöschten oder ausgegebenen Daten. Testfalldaten gibt der Tester im Zuge des Testfalls ein bzw. liest diese aus. Sie umfassen die Eingabedaten, die tatsächlichen Ausgabedaten sowie die erwarteten Ausgabedaten. Ebenfalls zu den Testfalldaten zählt das Testresultat, das angibt, ob das Testobjekt den Testfall bestanden hat oder nicht (passed/failed).

Operationsdaten/Basisdaten

Operationsdaten/Basisdaten bezeichnen diejenigen Daten, auf denen der Testfall arbeitet. Sie stellen den Ausgangspunkt der Testdurchführung dar und bilden die Grundlage der erwarteten Ergebnisse (Ausgabedaten, Testresultat).

Sie umfassen z.B. Stammdaten, Tarifdaten und historische Daten.

Umgebungsdaten/Konfigurationsdaten

Umgebungsdaten/Konfigurationsdaten dienen der Einstellung der Testumgebung und bilden eine Voraussetzung für die Testdurchführung. Sie definieren den Ausführungskontext der Testfälle.

Umgebungsdaten/Konfigurationsdaten lassen sich unterscheiden in:

Systemkonfiguration (Betriebssystem, Datenbanken, Applikationsserver, Hardwarekonfigurationen usw.)

Benutzerautorisierung, -authentifizierung, Berechtigungsnachweise (Benutzerkennungen, Passwörter, Systemzugriffslevel für generische, rollenbasierte oder testspezifische Benutzer

Konfigurationsmöglichkeiten (Port-Einstellungen der Firewall, Einstellungen der Applikationsserver, Speicherverwaltung usw.)

Für die Praxis

In der Praxis wird es nicht immer möglich sein, Testdaten eindeutig und global gültig einer Kategorie zuzuordnen. Dies ergibt sich aus der Sichtweise der Kategorien: Sie beziehen sich (auch) auf den konkreten Testfall. So können die Ausgabedaten des einen Testfalls als Eingabedaten eines anderen Testfalls fungieren.

Beispiel: Ergebnisdaten und Eingabedaten

Testfall 1 prüft das Anlegen einer Benutzerkennung: Anmelden mit der Administratorkennung (Benutzer admin, Passwort; Eingabedaten) und Erstellen eines Benutzers für Johann aus der Buchhaltung. Ergebnisdaten dieses Testfalls sind die konkrete Benutzerkennung mit Benutzername »johann« und Passwort »MP=8!5rt« sowie den damit verbundenen Berechtigungen im zu testenden System.

Testfall 2 prüft einen Anwendungsfall aus der Buchhaltung: Anmelden mit der Benutzerkennung des Buchhalters »johann« und dessen Passwort, danach Aufrufen eines Monatsberichts.

Die Benutzerkennung »johann« fällt in Testfall 2 in die Kategorie Eingabedaten bzw. Testfalldaten, während sie in Testfall 1 zu den Ergebnisdaten des Testfalls einzuordnen ist.

Darüber hinaus zählen Benutzerkennungen nach beiden oben zitierten Begriffen zu den Umgebungsdaten.

Für die Praxis des Testdatenmanagements bedeutet das Folgendes:

Ob Daten zu dieser oder jener Kategorie gehören, interessiert beim Aufbau und bei der Pflege des Testdatenbestands (Unterstützung der Anforderungsermittlung im Sinne einer Checkliste) sowie beim Aufbau und der Versorgung der Testumgebung mit den zuvor definierten und bestellten Testdaten. Ein Testdatenkonzept stützt sich beim Definieren der Testdaten ggf. auf diese Kategorien.

2.3Testdatenbestandstypen

Eine andere Sichtweise auf die Testdaten eröffnet die Unterscheidung in Testdatenbestandstypen. Während der Fokus der Testdatenkategorien eher auf der Bedeutung der Testdaten liegt, steht bei der Unterscheidung in Testdatenbestandstypen der Anwendungskontext im Vordergrund (Testobjekt, Testprojekt).

Bei Hettwer [HettoJ] unterscheidet man die Testdaten in drei Testdatenbestandstypen: projektübergreifende Steuerungsdaten, testobjektübergreifende Daten und testobjektspezifische Daten (Primär- und Sekundärdaten).

Definition: Testdatenbestandstypen

Testdaten lassen sich hinsichtlich ihres Anwendungskontextes unterscheiden in Testdatenbestandstypen. Diese verdeutlichen den Bezug der Testdaten zum Testprojekt und zum Testobjekt.

Folgende Testdatenbestandstypen werden unterschieden: projektübergreifende Steuerungsdaten, testobjektübergreifende Daten und testobjektspezifische Daten (Primär- und Sekundärdaten) (vgl. [HettoJ]).

Die projektübergreifenden Steuerungsdaten weisen folgende Eigenschaften auf:

Enthalten niemals kundenspezifische Daten

Können identisch sein zu Produktionsdaten

Anwendung greift nur lesend darauf zu (kein Editieren)

Bleiben i.d.R. über den Lebenszyklus der Anwendung gleich

Testobjektübergreifende Daten »stellen einen repräsentativen Umfang an Bestandsdaten dar, die jede Funktionalität der Anwendung als Ausgangszustand benötigt« [HettoJ]. Aus den verfügbaren Datensätzen sind zur Verwendung in den Testobjekten geeignete Datensätze auszuwählen. Die testobjektübergreifenden Daten dienen als Kopiervorlage für einzelne Testobjekte.

Bei den testobjektspezifischen Daten handelt es sich um Primär- und Sekundärdaten (mehr zu Primär- und Sekundärdaten siehe Abschnitt 2.4).

Abb. 2–7 Testdatenbestandstypen (nach Hettwer)

2.4Unterscheidung in Primär- und Sekundärdaten

Neben den oben vorgestellten Kategorien und Typen von Testdaten finden sich weitere Gruppierungsmöglichkeiten.

Im 1997 erschienenen Artikel der Computerwoche [Anon97] werden Primärdaten und Sekundärdaten zunächst wie folgt unterschieden:

Primärdaten sind Eingabedaten.

Sekundärdaten sind »Testdaten, die in Datenbanken, Parameterdateien etc. vorliegen müssen« [Anon97].

Eine detailliertere Beschreibung findet sich auf der Seite der Hettwer Unternehmensberatung [HettoJ]. Sie differenzieren testobjektspezifische Daten in Primär- und Sekundärdaten.

Demnach führen Primärdaten in Schnittstellen (auch GUI) zur Verarbeitung. Sie werden für jedes Testobjekt explizit erstellt.

Als Sekundärdaten bezeichnet Hettwer »Daten, die benötigt werden, damit die Verarbeitung laufen kann« (Bestandsdaten) [HettoJ]. Sie werden für jedes Testobjekt in der Regel aus der Kopierbasis erzeugt. Findet sich in der Kopierbasis kein passender Datensatz, dann erstellt und verwaltet man zum konkreten Testobjekt den/die fehlenden Datensätze. Beim Erstellen folgt man idealerweise dem Kopieren- und-Editieren-Ansatz, indem man einen ähnlichen Satz sucht, kopiert und »über eine Anwendung (funktionsgetestet!!) oder über ein entsprechendes Testdaten-Tool« [HettoJ] anpasst.

Auch [DaGl16] unterscheiden zwischen primären Testdaten und sekundären Testdaten.

Die »Daten, die während des Testablaufs die Eingaben bestimmen und meist in der Testfallspezifikation« zu finden sind, bezeichnen sie als primäre Testdaten. Sekundäre Testdaten dagegen bilden die Grundlage für den Testablauf und können sehr umfangreich sein (z.B. Konfigurationen oder Datenbankinhalte) (vgl. [DaGl16, S. 106]).

Abb. 2–8 Primärdaten und Sekundärdaten

Unter Rückgriff auf die vorgestellten Begriffe werden Testdaten als Primärdaten oder Sekundärdaten wie folgt definiert:

Definition: Primärdaten/Primäre Testdaten

Primärdaten bezeichnen die Eingabedaten eines Testfalls. Sie werden für jedes Testobjekt explizit erstellt. In Schnittstellen führen sie zur Verarbeitung. Primärdaten können in der Testfallspezifikation enthalten sein.

Primärdaten stellen demnach eine Teilmenge der Testdatenkategorie Testfalldaten dar (siehe Abschnitt 2.2).

Definition: Sekundärdaten/Sekundäre Testdaten

Sekundärdaten bezeichnen Testdaten, die in der Testumgebung vorliegen müssen. Sie umfassen Datenbanken, Parameterdateien, Konfigurationen. Sekundärdaten ermöglichen die Testdurchführung.

Die Sekundärdaten lassen sich daher den Testdatenkategorien Operationsdaten und Umgebungsdaten zuordnen.

2.5Unterscheidung nach Testobjekt in Testdatentypen

Testdaten lassen sich hinsichtlich des Testobjekts unterscheiden, für das sie verwendet werden. So geschehen in »Der Systemtest« [SBS12]. Die Autoren betrachten für die Teststufe Systemtest folgende Testobjekte: Benutzeroberflächen, Systemschnittstellen, Datenbanktabellen, Dateien. »Jedes dieser Testobjekte weist eine andere Art von Testdaten auf, die auf eine andere Art und Weise erzeugt werden« [SBS12, S. 135]. In Abhängigkeit von diesen Testobjekten unterscheiden sie verschiedene Testdatentypen:

Testdaten für das Testobjekt »Datenbanken«

Testdaten für Testobjekt »Systemschnittstellen«

Testdaten für Testobjekt »Benutzeroberflächen«

Sie erachten die Unterscheidung der Testdatentypen als notwendige Voraussetzung für das Erstellen von Testdaten2.

Analog zur obigen Verfahrensweise lassen sich für andere Teststufen ähnliche Unterscheidungen in Testdatentypen treffen, z.B. Testdaten für das Testobjekt Komponente (Modul, Unit, Klasse) im Komponententest.

Ergänzend zu den Testdatentypen finden sich die zugehörigen Überdeckungsmaße [SBS12, S. 136ff.], Datenüberdeckungsgrade genannt.

Diese Unterscheidung ist hier nur der Vollständigkeit halber genannt.

2.6Ergebnisse eines Testlaufs: Soll, Ist, Testergebnis

Ein Testdatenbegriff findet sich auch in der Norm ISO 29119. So unterscheidet die ISO 29119-2 bzgl. der Ergebnisse eines Testlaufs folgende drei Begriffe (vgl. [DaGl16, S. 82]):

Sollergebnis (Sollwert, Soll): »Der Wert, die Werte, der Zustand … – den das Testobjekt laut Testbasis hoffentlich liefern wird.«

Istergebnis (Istwert, Ist): »Der Wert, die Werte, der Zustand … – den man während der Testdurchführung beobachtet und der anders sein kann als geplant.«

Testergebnis: »Die Antwort auf die Frage, ob bestanden oder nicht (»passed« oder »failed«), je nachdem, ob Sollergebnis und Istergebnis übereinstimmen oder nicht.«

Nach meinem bisherigen Verständnis stellen Sollergebnis und Istergebnis Testdaten, genauer Testfalldaten, dar (nach [Reim13]); sie fallen in die Gruppe der Ausgabedaten.

Bisher konzentrierten wir uns auf die Testdaten selbst. Doch es existieren weitere Daten, die im Zusammenhang mit Testdaten relevant sind: die Metadaten der Testdaten.

2.7Metadaten für Testdaten

Metadaten, Metadatenmanagement

Grundsätzlich versteht man unter Metadaten Daten über Daten. Metadaten für Testdaten beschreiben demzufolge die eigentlichen Testdaten.

Eicker definiert Metadaten wie folgt:

Definition: Metadaten (nach Eicker)

»Daten über Objekte der Informationsverarbeitung beispielsweise über Daten, Funktionen, Prozesse, Anwendungssysteme, Komponenten der IT-Infrastruktur etc.« [Eick14]

Demnach umfasst das Metadatenmanagement analog zum Datenmanagement »alle Aufgaben, die für die adäquate Bereitstellung der Metadaten auf strategischer, taktischer und operativer Ebene wahrzunehmen sind« [Eick14].

Datenadministration

Einen Anwendungsbereich für Metadaten stellt die Datenadministration dar. Nach Eicker behandelt diese z.B. die Fragen, welche Daten in welcher Struktur wo gespeichert werden, wie die Zusammenhänge zwischen den Daten gestaltet sind und wo insbesondere Redundanzen bestehen.

Wozu man Metadaten im Testdatenmanagement benötigt

Weshalb soll man den Aufwand betreiben, neben den Testdaten auch noch Metadaten für selbige zu pflegen? Nun, unter anderem deshalb, weil fehlende oder unsauber gepflegte Metadaten zu den häufigen Problemen mit Testdaten gehören (siehe Kap. 4).

Betrachten wir ein paar konkrete Verwendungszwecke:

Zur Eigentumsregelung

Mithilfe von Metadaten soll z.B. vermieden werden, dass sich verschiedene Testteams, die sich eine Testumgebung oder eine Datenbasis teilen, beim Testen dadurch stören, dass sie sich gegenseitig die Daten »wegnehmen« oder »zerschießen«.

Als Auswahlkriterium

Metadaten dienen u.a. als Kriterium zur Auswahl von geeigneten Testdaten für einen bestimmten Testfall, Testlauf oder ein Testszenario.

»Auch die Zusammenstellung von Daten für einen übergreifenden Integrationstest ist ohne Metadaten erheblich aufwändiger« [Ende12].

Als Entscheidungshilfe

Unser Testdatenbestand soll einerseits nicht zu umfangreich sein, andererseits aber alle geplanten Tests unterstützen. Metadaten, die fachliche Informationen über Testdaten enthalten, helfen bei der Entscheidung darüber, ob vorhandene Testdatensätze angepasst werden können oder ob es fachlich sinnvoller ist, einen oder mehrere Testdatensätze neu anzulegen.

Die Informationen über den fachlichen Kontext helfen bei der Auswahl der Testdaten für Tests zu fachliche Szenarien. Sie werden benötigt, um festzustellen, ob ein bestimmtes fachliches Szenario in den Testdaten bereits abgebildet ist oder ob hierfür ein oder mehrere neue Datensätze angelegt werden sollten.

Erfolgt zum Testen neuer Funktionalitäten eine Anpassung der vorhandenen Testdaten, dann kann es passieren, dass aufgrund fehlender oder ungeeigneter Metadaten die »falschen« Testdaten ergänzt bzw. geändert werden. So können sich Testdatenkonstellationen ergeben, die aus fachlicher Sicht nicht sinnvoll oder sogar falsch sind.

Als Steuerinformation

Darüber hinaus dienen Metadaten Testern und Testwerkzeugen für Auswertungen oder als Steuerinformationen (vgl. [Ende12]).

Zur Unterstützung von Automatisierung

»Ein sauberes Metadaten-Management von Anfang an fördert die vollständige Automatisierung von Prozessen und verringert damit den manuellen Aufwand« [Ende12].

Metadaten unterstützen auch die Testautomatisierung. Zum Beispiel wenn aus den Metadaten hervorgeht, dass diese ausschließlich für bestimmte Testläufe (Smoke-Test, Health Check) verwendet werden dürfen.

Mit diesem Einblick in die Begriffe und den Verwendungszweck von Metadaten wollen wir das Thema Metadaten hier abschließen.

2.8Testdaten, Testfälle, Testentwurfsverfahren und Testabdeckung

Bevor wir in den nächsten Kapiteln intensiver in die Aspekte rund um Testdaten einsteigen, machen wir uns zunächst die Zusammenhänge zwischen Testdaten, Testfällen, Testentwurfsverfahren und Testabdeckung (Überdeckungsgrad) klar.

Diese Zusammenhänge sind wichtig für das Verständnis der folgenden Kapitel.

Testdaten und Testfall

Beginnen wir mit den Testfällen und den Testdaten: Abstrakte Testfälle enthalten noch keine Testdaten, weshalb sich die Testfälle nicht ausführen lassen. Erst dadurch, dass man einen abstrakten Testfall um Testdaten ergänzt, erhält man einen ausführbaren konkreten Testfall.

Testentwurfsverfahren

Testfälle lassen sich mittels Testentwurfsverfahren ableiten oder ermitteln. Testentwurfsverfahren werden unterschieden in spezifikationsbasierte, strukturbasierte und erfahrungsbasierte Verfahren (vgl. [SpLi12, S. 263]). Darüber hinaus unterscheidet man Blackbox-Verfahren und Whitebox-Verfahren.

Einige Testentwurfsverfahren wie z.B. die beiden Blackbox-Verfahren Äquivalenzklassenbildung und Grenzwertanalyse basieren auf der Analyse der Eingabewerte. Mithilfe dieser Methoden ermitteln wir also nicht nur Testfälle, sondern auch Testdaten! Denn als Eingabedaten zu den konkreten Testfällen fungieren die ermittelten Repräsentanten der Äquivalenzklassen und die Grenzwerte. Die Testfälle werden ergänzt um die erwarteten Sollwerte (Ausgabedaten). Eingabedaten und erwartete Sollwerte gehören zur Kategorie Testfalldaten.

Überdeckungsgrad

Der Überdeckungsgrad ist nach [GTB+15] definiert als der in einem Prozentsatz ausgedrückte Grad, zu dem ein spezifiziertes Überdeckungselement durch eine Testsuite ausgeführt wurde.

Daher müssen folgende Voraussetzungen erfüllt sein, um einen Überdeckungsgrad größer null berechnen zu können:

Alle gemäß vorgegebenem Testentwurfsverfahren erforderlichen konkreten Testfälle müssen identifiziert sein – sie verkörpern die 100 % Überdeckung.

Eine Menge an Testfällen muss ausgeführt sein – für die leere Menge an Testfällen beträgt die Überdeckung null Prozent.

Die Testumgebung enthält alle nötigen Testdaten, um die Testfälle durchführen zu können (Operationsdaten, Umgebungsdaten).

Überdeckung durch Testdaten

Im Abschnitt 8.2 lernen Sie ein Vorgehen kennen, anhand dessen Sie mittels verschiedener Überdeckungen Testdaten ermitteln können. Samuel T. Redwine formuliert es so, als überdeckten die erarbeiteten Eingabe- und Ausgabedaten das Überdeckungselement. Letztlich identifiziert er mit den Testdaten jedoch konkrete Testfälle.

Da ein Testfall ohne Testdaten nicht ausgeführt werden kann, sind die Testdaten als untrennbarer Bestandteil des jeweiligen Testfalls zu betrachten. Insofern erscheint es nicht sinnvoll, neben dem Überdeckungsgrad (nach [SpLi12]) einen eigenständigen Überdeckungsgrad für Testdaten zu betrachten.

2.9Zusammenfassung

Dieses Kapitel vermittelte einen Überblick über verschiedene Begriffe im Themenbereich Testdaten. Der Begriff der Testdaten selbst sowie die Unterscheidungen der Testdaten hinsichtlich der verschiedenen Kriterien bilden die Grundlage für ein umfassendes Verständnis der Testdaten.

So versetzt Sie dieses Kapitel in die Lage, die in Ihrem Testprojekt benötigten Testdaten zu analysieren und die Ergebnisse z.B. in einem Testdatenrahmenwerk festzuhalten (siehe Abschnitt 9.1).

Daneben sollten Sie aus diesem Kapitel mitnehmen, dass die Metadaten der Testdaten von großer Bedeutung sind für deren Lebenszyklus und Verwendung in Tests. Sie wissen nun, dass es sich lohnt, Metadaten zu erheben und zu pflegen, um den Testdatenbestand möglichst lange in guter Qualität zu erhalten.

Zum Weiterlesen

Weitere lesenswerte Ausführungen zu Testdaten in verschiedenen Teststufen finden sich in [Held16, S. 27ff.].

3Eigenschaften von und Anforderungen an Testdaten

Bevor wir die Anforderungen an Testdaten betrachten, machen wir uns zunächst bewusst, durch welche Eigenschaften Testdaten gekennzeichnet sind.

Welche Anforderungen müssen Testdaten erfüllen, damit sie gute Testdaten sein können und die Testaktivitäten sinnvoll unterstützen? Die Anforderungen an Testdaten sind vielfältiger Art und zum Teil widersprüchlich. Dieses Kapitel beleuchtet einige von ihnen.

Dass die Testdaten alle wesentlichen an sie gestellten Anforderungen erfüllen, soll das Testdatenmanagement sicherstellen.

3.1Eigenschaften von Testdaten

Im vorangegangenen Kapitel befassten wir uns mit verschiedenen Unterscheidungsmöglichkeiten von Testdaten. Doch welche Eigenschaften kennzeichnen Testdaten?

Testdaten sind Bestandteil der Testumgebung

Sie dienen dort unterschiedlichen Zwecken.

Während Umgebungsdaten bereits vor der Testdurchführung für das Einrichten der Testumgebung benötigt werden, dienen Basisdaten der eigentlichen Testdurchführung; daher können sie notfalls vor Beginn des Testlaufs eingepflegt werden. Die Eingabedaten gelangen während der Testdurchführung in das zu testende System und erreichen somit die Testumgebung. Die Ausgabedaten liegen erst nach der Testdurchführung in der Testumgebung vor.

Testdaten werden für alle Teststufen und Testarten benötigt

Kruse formuliert [Krus11, S. 5] unter Eigenschaften von Testdaten u.a., dass sie »für alle Teststufen und Testarten benötigt« werden. Damit ist ihr Einsatzzweck beschrieben.

Testdaten sind abhängig von der Domäne

Testdaten sind sehr stark abhängig von der Domäne, für die die zu testende Software implementiert wird.

Denken Sie an Ihren letzten Einkauf im Internet. Stellen Sie sich diesen als Testfall vor: Sie haben aus Artikeln gewählt (Basisdaten), sind zum Warenkorb gewechselt (Ausgabedaten: Warenkorb mit Artikeln, Preisen, Steuer usw.) und haben später Ihre Adressdaten eingegeben (Eingabedaten). Die vergessene Postleitzahl wurde mit einer Fehlermeldung quittiert (Ausgabedaten: Fehlermeldung). Als Schnittstelle zwischen dem System und dem Benutzer dient eine GUI.

Sogar innerhalb des Bereichs Testen eingebetteter Systeme unterscheiden sich die Testdaten. Denn sie kommen aus der Domäne des zu testenden Gerätes: Für das Testen von Videogeräten verwenden die Tester spezielle Videos (wie das Fernsehtestbild von früher), für Audiogeräte spezielle Audiodateien. Die Testbilder und Audiodateien erhalten sie als Testdaten vom Fachspezialisten der Domäne (auch deshalb empfiehlt es sich, Fachspezialisten, wie z.B. Elektroingenieure, in die Testaktivitäten einzubeziehen, z.B. für Reviews oder zur Unterstützung beim Testdesign).

Verfügt Ihr Auto über einen Einparkassistenten? Sensoren an Vorder- und Hinterseite