-
Die
Erfindung betrifft ein Verfahren und eine Einrichtung zur automatischen
Generierung von Testdaten. Ferner betrifft die Erfindung ein Computerprogramm-Produkt
und ein computerlesbares Medium zur Testdatengenerierung.
-
Testen
ist bei der Softwareentwicklung eine anerkannte Maßnahme
zur Qualitätssicherung. Ziel des Testens ist es, vorhandene
Fehler in der zu testenden Software zu finden und wenn möglich
zu lokalisieren, um damit die Voraussetzung zur Beseitigung der
Fehler zu schaffen. Es gibt unterschiedliche Arten und Methoden
von Tests, z. B. Black-Box-Test (funktionaler Test), White-Box-Test
(struktureller Test), Modultest, Integrationstest, Systemtest.
-
Prinzipiell
werden beim Testen sog. Testfälle mit Testdaten zur Ausführung
auf der zu testenden Software gebracht und die dabei gewonnenen
Istwerte werden jeweils mit den zu erwartenden Sollwerten verglichen.
-
Der
Umfang und die Qualität von Testfällen und Testdaten
sind wichtige Parameter für die Qualität eines
Tests.
-
Die
Erstellung von Testfällen und die Bereitstellung geeigneter
Testdaten ist insbesondere zum Testen von Softwareprogrammen eine
zeitaufwändige Tätigkeit und erfordert neben Kenntnis
der zugrundeliegenden funktionalen und nicht funktionalen Anforderungen
auch strukturelles Denken.
-
In
der deutschen Patentschrift
DE 10 2007 004 361 A1 werden ein System und
ein Verfahren zur Akkumulation von Zusammenfassungen von Testdaten
angegeben, bei welchen die Testdaten auf Datenobjekte in einem Datenobjekt
abgebildet werden.
-
In
der europäischen Patentschrift
EP 1 505 399 B1 werden ein
Verfahren und eine Testentwurfsstation zur Erzeugung von Testprozeduren
für datenverarbeitende Schaltungen offenbart.
-
Der
Stand der Technik umfasst hinsichtlich der Testautomatisierung auch
den Einsatz von allgemeinen Testframeworks (z. B. im Java-Bereich
JUnit), oder sog. Mock-Tools (z. B. im Java-Bereich JMockIt), die
einzelne, gerade nicht zu testende Komponenten simulieren können.
-
Die
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren und eine
Einrichtung zur automatischen Generierung von Testdaten zum effektiven
und effizienten Testen von Softwareprogrammen bereitzustellen.
-
Die
Aufgabe wird mit einem Verfahren, das folgende Schritte umfasst,
gelöst:
- a) Bereitstellen eines Objektmodells,
das den technischen Rahmen für eine statistische Modifizierung
von Testdaten bildet;
- b) Einlesen eines ersten sequentiellen Eingabe-Testdatenstroms;
- c) Validierung des ersten Eingabe-Testdatenstroms zur Verwendung
im Objektmodell;
- d) Deserialisierung des ersten Eingabe-Testdatenstroms in das
Objektmodell;
- e) statistische Modifizierung des Objektmodells;
- f) Serialisierung des Objektmodells in einen zweiten sequentiellen
Eingabe-Testdatenstrom;
- g) Bereitstellen des zweiten sequentiellen Eingabe-Testdatenstrom
für Auswerteeinheiten.
-
Durch
das Einbringen von statistisch verteilten Datenfehlern bzw. Datenmodifizierungen
in einen Testdatenstrom lässt sich die Funktionalität
von angeschlossenen Auswerteeinheiten bzw. Clients insbesondere im
Hinblick auf deren Ausnahmebehandlung (Exception Handling) insbesondere
bei zu testenden Verfahren zur Datenkorrektur realitätsnah
simulieren und testen. Derartige Datenverfremdungen bzw. Datenmodifizierungen
können sich auf die Testdatensyntax, aber auch auf die
Testdatensemantik beziehen. Die Vorteile des beschriebenen Verfahrens
kommen insbesondere dann zum Tragen, wenn für die angeschlossenen
Auswerteeinheiten bzw. Clients aus Fremdsystemen bzw. anderen Datenquellen
stammende Zulieferungen simuliert werden sollen, die außerhalb
der eigenen Einflusssphäre bzw. Qualitätssicherung
liegen, oder für die sich etwa aufgrund der Transport-
oder Übermittlungsmethoden unvorhersehbare Datenverluste
oder Datendefekte ergeben könnten.
-
Eine
erste vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
im Schritt c) „Validierung” gefundenen Inkonsistenzen
im ersten Eingabe-Testdatenstrom herausgefiltert und/oder protokolliert
und/oder für eine anschließende Rekonstruktion
gespeichert werden. Eventuelle Abweichungen und Inkonsistenzen im Eingabe-Testdatenstrom,
die eine Deserialisierung teilweise oder vollständig verhindern
würden, werden identifiziert und nach einer späteren
Rekonstruktion und Verfremdung wieder eingebracht. Dadurch kann
für die konsistenten Daten das Verfahren sofort weitergeführt
werden. Die inkonsistenten Daten werden für eine spätere
Weiterverarbeitung gekennzeichnet.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
im Schritt c) „Validierung” gefundenen Inkonsistenzen
im ersten Eingabe-Testdatenstrom durch Korrektur oder durch Löschen
beseitigt werden. Dadurch ist sichergestellt, dass der Datenstrom
in einem validen, zur Deserialisierung geeigneten Datenformat vorliegt.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
die gespeicherten Inkonsistenzen des ersten Eingabe-Testdatenstroms
für eine Verwendung im zweiten Eingabe Testdatenstrom rekonstruiert
werden. Durch die Rekonstruktion der inkonsistenten Daten wird nicht
auf Daten verzichtet, was die Qualität des zweiten sequentiellen
Eingabe-Testdatenstroms erhöht.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
der zweite Eingabe-Testdatenstrom um statistische Modifizierungen
ergänzt wird, die außerhalb der Reichweite möglicher
Modifizierungen des Objektmodells liegen. Dies geschieht z. B. durch
zufälliges Umkopieren einer bestimmten Datensequenz innerhalb
des Datenstroms. Auch dadurch wird die Qualität des zweiten
sequentiellen Eingabe-Testdatenstroms erhöht.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
das Verfahren zum systematischen und automatischen Testen von Datenkorrekturverfahren
eingesetzt wird. Verfahren zur Datenkorrektur lassen sich somit
realitätsnah simulieren und testen. Mittels Testdatengeneratoren
erzeugte, fehlerfreie Testdatensätze werden nachträglich
automatisch verfremdet, so dass die Wirkung eines nachfolgend in
einer Auswerteeinheit angewendeten Datenkorrekturverfahrens genau
umgekehrt wird. Nach durchgeführter Datenkorrektur ergeben
sich also wieder die unverfälschten Ausgangs-Testdaten.
Damit lassen sich zwei Arten von Testdatensätzen automatisch
erzeugen: fehlerfreie sowie verfremdete. Sie können anschließend
als Testreferenz für einen Komponenten/Unittest der Auswerteeinheiten
herangezogen werden. Das beschriebene Verfahren ermöglicht
insbesondere für die Entwicklung von Datenkorrekturverfahren
durch die enge Einbindung von Testdatengeneratoren eine zusätzliche
Ebene des algorithmischen Tests, die ebenfalls mit einem hohen Automatisierungsgrad
abgedeckt werden kann.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
im Schritt e) die statistische Modifizierung des Objektmodells auf
Zufallswerten basiert, die durch Anwendung beliebiger statistischer
Verteilungen gewonnen werden. Dadurch ist das Verfahren flexibel
und variabel einsetzbar und nicht auf bestimmte mathematische Verteilungen
beschränkt.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
als statistische Verteilung eine Exponential-, eine Gamma-, eine
Hyperbolische-, eine Logarithmische- oder eine Normalverteilung
verwendet werden kann wird. Für diese mathematischen Verteilungen
existieren kommerzielle Softwarepakete (z. B. MatLabTM),
die für eine Implementierung des Verfahrens leicht zugänglich
sind.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
im Schritt e) die statistische Modifizierung des Objektmodells durch
einen Modellwandler erfolgt, der auf den zu modifizierenden Entitäten
des Objektmodells statistische Operationen zur Modifizierung der
Entitäten anwendet, wobei der Modellwandler eine bestimmte,
statistisch gewichtete Basisoperation zur Modifizierung am Objektmodell
repräsentiert. Die Modellwandler stellen die Basis-Einheiten
der kontrollierten Testdatenverfremdung dar. Sie ändern
die zugrunde liegenden Testdatensätze klar eingegrenzt
auf einer tiefliegenden technischen Ebene, z. B. einem einzelnen
Datenfeld oder Objektattribut. Eine solche Basisoperation kann wiederum
zufällige Modifizierungen bezüglich der Entitäten
(z. B. zufällige Attributbelegungen) ausführen.
Ein Modellwandler kann in verschiedenen Ausführungskontexten
wiederverwendet werden. Dies erhöht die Produktivität
beim Test.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
der Modellwandler parametrierbar ist hinsichtlich der zu modifizierenden
Entitäten des Objektmodels, hinsichtlich der anzuwendenden
statistischen Operationen sowie hinsichtlich einer Verknüpfung
und/oder statistisch gewichteten Kombination mit weiteren Modellwandlern.
Dies erhöht die Flexibilität beim Test und die
Ergiebigkeit (Yield) beim Generieren der Testdaten.
-
Eine
weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass
verschiedene Modellwandler, die bestimmte, statistisch gewichtete
Basisoperationen zur Modifizierung am Objektmodell ausführen,
mittels einer Pipeline in einen wiederum statistisch gewichteten
Ausführungskontexten zusammengeschaltet werden können,
so dass sich auf diese Weise zusammengesetzte statistische Modifizierungen
am Objektmodell ergeben. Durch das Pipelinekonzept lassen sich Modellwandler schnell
und effektiv verschalten oder miteinander kombinieren. Dies erhöht
die Flexibilität und Produktivität bei der Testdatengenerierung.
-
Die
Aufgabe wird weiterhin gelöst durch eine Einrichtung zur
Durchführung des Verfahrens. Die Einrichtung kann mit verkaufsüblicher
Hardware (z. B. PC oder Workstation) umfassend Schnittstellen zum Ein-/Auslesen
und Mittel zum Speichern der Testdaten, mit entsprechender Software
auf Basis gängiger Technologieplattformen realisiert werden,
z. B. als Testmodell-Fabrik.
-
Ferner
wird die Aufgabe gelöst durch ein Computerprogramm-Produkt
oder ein computerlesbares Medium, welche auf einer programmgesteuerten
Einrichtung die Durchführung des Verfahrens veranlassen.
Dies erleichtert die Flexibilität des Einsatzes und auch
die Verteilung und den kommerziellen Vertrieb des erfindungsgemäßen
Verfahrens.
-
Ein
Ausführungsbeispiel der Erfindung ist in der Zeichnung
dargestellt und wird im Folgenden erläutert.
-
Dabei
zeigen:
-
1 den
Einsatz des erfindungsgemäßen Verfahrens in einer
schematischen Übersichtsdarstellung,
-
2 ein
beispielhaftes Ablaufdiagramm für das erfindungsgemäße
Verfahren,
-
3 ein
beispielhaftes Übersichtsbild mit Komponenten für
eine Einrichtung zur Durchführung des Verfahrens,
-
4 ein
beispielhaftes Strukturbild für den Modellmodifizierer
in objektorientierter Notation,
-
5 mögliche
Verarbeitungsschritte zur Pipeline-Initialisierung in Sequenzdiagramm – Message
Sequence Chart-Darstellung (MSC),
-
6 mögliche
Verarbeitungsschritte zur Modellmodifizierung in Sequenzdiagramm – Message
Sequence Chart-Darstellung (MSC), und
-
7 ein
beispielhaftes Objektmodell für eine statistische Modifizierung
eines Test-Datenstroms.
-
1 stellt
den Einsatz des erfindungsgemäßen Verfahrens in
einer schematischen Übersichtsdarstellung dar. Eine technische
Anordnung mit einer Testausrüstung liefert einen sequenziellen
Testdatenstrom TD1, der statistisch modifiziert wird, und als modifizierter
Testdatenstrom TDM1 anschließend von einer oder mehrerer
Auswerteeinheiten AE bzw. Clients testweise verarbeitet wird (z.
B. zum Funktions- oder Stabilitätstest). Es ist sinnvoll,
in einen Eingangs-Testdatenstrom TD1 statistisch verteilte Datenfehler
bzw. Datenmodifizierungen einzubringen. Auf diese Weise lässt
sich die Funktionalität der angeschlossenen Auswerteeinheiten
AE bzw. Clients insbesondere im Hinblick auf deren Ausnahmebehandlung
(Exception Handling) bzw. in ihnen eventuell zur Anwendung kommender
Verfahren der Datenkorrektur realitätsnah simulieren und
testen. Derartige Verfremdungen bzw. Modifizierungen können
sich auf die Testdatensyntax bzw. -semantik beziehen. Das im Folgenden
beschriebene Verfahren zeigt auf, wie in einen sequenziellen (Binär-)Strom
von Eingangs-Testdaten TD1, als allgemeine Repräsentation
ihrer beliebigen DV-technischen Konkretisierung, derartige statistische
Datenverfremdungen und -modifizierungen weitreichend kontrollierbar
und konfigurierbar eingebracht werden können. Die technische
Realisierung des Verfahrens erfolgt dabei mit gängigen
Programmiermitteln (C, C++, Java, etc.) auf kommerziellen Technologieplattformen
(PC, Workstations, etc.).
-
2 zeigt
ein beispielhaftes Ablaufdiagramm für das erfindungsgemäße
Verfahren, mit den Verfahrensschritten S1 bis S8 zur Durchführung
des Verfahrens.
-
Im
Schritt S1 erfolgt das teilweise oder vollständige Einlesen
des sequenziellen Eingabe-Testdatenstroms (TD1; 1).
-
In
Schritt S2 wird geprüft, ob und inwieweit diese Eingabe-Testdaten
(TD1; 1) mit dem zugrunde liegenden Referenz-Daten-
bzw. Objektmodell, das den technischen Rahmen für die statistischen
Modifizierungen bildet, in Deckung gebracht werden können.
Eventuelle Abweichungen und Inkonsistenzen, die eine Deserialisierung
teilweise oder vollständig verhindern würden,
werden herausgefiltert, mitprotokolliert und zur späteren
Rekonstruktion (siehe Schritt S6) im System hinterlegt. Festgestellte
Datendefekte eines Testdatenstroms (TD1; 1) werden
möglichst durch Korrektur, in jedem Fall durch Löschung
beseitigt. Anschließend liegt er in einem validen, zur
Deserialisierung geeigneten Datenformat vor. Lassen die Eingabe-Testdaten
jegliche Strukturinformation vermissen, so schließt dieses
eine Deserialisierung in ein Daten- bzw. -Objektmodell aus, und
es wird mit Verfahrensschritt S7 fortgefahren.
-
In
Schritt S3 erfolgt die Deserialisierung des in Schritt S2 validierten
und ggf. korrigierten bzw. reduzierten Testdatenstroms (TD1; 1)
in das als Daten- bzw. Objektmodell, in welches nach seiner Ausführung alle
verfügbaren, validen Testdateninformationen übertragen
sind.
-
In
Schritt S4 erfolgt die statistische Modifizierung des in Schritt
S3 erzeugten Daten- bzw. Objektmodells (Details hierzu werden später
angegeben).
-
In
Schritt S5 wird das statistisch verfremdete bzw. modifizierte Daten-
bzw. Objektmodell aus Schritt S4 in die sequenzielle Darstellungsform
des Eingabedatenstroms (TDM1; 1) zurückgewandelt
(serialisiert).
-
In
Schritt S6 werden die in Schritt S2 gefundenen und zwischengespeicherten
Inkonsistenzen im Testdatenstrom aus Schritt S5 so weit wie möglich
rekonstruiert bzw. wieder eingebracht.
-
In
Schritt S7 kann der Testdatenstrom aus Schritt S6 um statistische
Modifizierungen ergänzt werden, die außerhalb
der Reichweite möglicher Modifizierungen bezüglich
des Daten- bzw. Objektmodells aus Schritt S5 liegen, z. B. indem
sie datentechnische Zusammenhangs- und Strukturinformationen selbst
invalidieren (z. B. durch zufälliges Umkopieren einer bestimmten
Datensequenz innerhalb des Datenstroms).
-
In
Schritt S8 erfolgt das Herausschreiben des sequenziellen Testdatenstroms
inklusive der aus den Schritten S5, S7 resultierenden statistischen
Modifizierungen in einem Transportformat, welches sich zur Weiterleitung
an die angeschlossenen Auswerteeinheiten (AE; 1)
bzw. Clients eignet.
-
3 zeigt
ein Übersichtsbild mit Komponenten für eine beispielhafte
Einrichtung zur Durchführung des Verfahrens zur Testdatenmodifizierung.
Die Einrichtung umfasst einen Testdatensatz-Leser TDL zum Lesen
der Eingangs-Testdaten TD2, einen Testdatensatz-Filter TDF, einen
Deserialisierer DS zur Abbildung der Eingangs-Testdaten TD2 in ein
Referenz-Objektmodell OM1, einen Modell-Modifizierer MM1 zur statistischen Modifizierung
der in das Referenz-Objektmodell OM1 abgebildeten Eingangs-Testdaten
TD2, einen Filterungs-Ergänzer FE zur Beseitigung von Inkonsistenzen
und zum Einbringen weiterer statistischer Modifizierungen und einen
Testdatensatz-Schreiber TDS zur Bereitstellung der modifizierten
Testdaten TDM2 für angeschlossene Auswerteeinheiten AE.
-
In 3 symbolisieren
die durchgezogenen Verbindungspfeile den Datenfluss zwischen den
Komponenten während der Verfahrrensausführung
und die gestrichelten Pfeile DV-technische Referenzen (z. B. Abbildung
und Zugriff auf das Objektmodell OM1). Im Folgenden sind die Komponenten
der beispielhaften Einrichtung zur Durchführung des Verfahrens
beschrieben: Der Testdatensatz-Leser TDL implementiert die zentrale
Eingabeschnittstelle des Systems, die dem Einlesen des eingehenden
Testdatenstroms TD2 dient, und stellt diesen systemintern in einer
geeigneten DV-technischen Repräsentation, die dem sequenziellen
Datenformat des Eingangs-Datenstroms entspricht, zur weiteren statistischen
Verfremdung und Modifizierung zur Verfügung.
-
Der
Testdatensatz-Filter TDF operiert auf der von Seiten des Testdatensatz-Leser
TDL bereitgestellten Testdaten-Repräsentation, und führt
die Prüfungen analog Verfahrensschritt S2 (2)
aus. Alle diesbezüglich identifizierten Datendefekte werden
zur späteren Rekonstruktion im System gespeichert (siehe
Schritt S6 in 2).
-
Der
Deserialisierer DS, überträgt die sequenziellen
Testdaten als Ausgangsprodukt des Testdatensatz-Filter TDF in ein
DV-technisches Daten- bzw. Objektmodell OM1. Zur technischen Umsetzung
können z. B. auf XML basierende Standardverfahren (etwa
XSD-Compiler) zum Einsatz kommen.
-
Der
statistische Modell-Modifizierer MM1, bringt in das von Seiten des
Deserialisierer DS aufgebaute und befüllte Daten- bzw.
Objektmodell OM1 statistische Verfremdungen und Modifizierungen
ein. Die Verfremdungen und Modifizierungen basieren auf statistischen
Verteilungen, wie z. B. Exponential-, Gamma, Hyperbolische-, Logarithmische-
oder Normalverteilung.
-
Der
Serialisierer S, wandelt das Daten- bzw. Objektmodell OM1, inklusive
der statistischen Modifizierungen zurück in das sequenzielle
Datenformat des Eingangs-Datenstroms.
-
Der
Filterungs-Ergänzer FE, liest die von Seiten des Testdatensatz-Filters
TDF im System gespeicherte Filterinformationen aus und übernimmt
sie in den sequenziellen Testdatenstrom analog Verfahrensschritt
S6 (2), soweit ihr Zusammenhang in den statistisch
verfremdeten bzw. modifizierten Testdaten rekonstruiert werden kann;
ansonsten bleiben diese Informati onen unberücksichtigt.
Zusätzlich kann der Filterungs-Ergänzer FE in
den Testdatenstrom auch eigene statistische Modifizierungen analog
Verfahrensschritt S7 (2) einbringen.
-
Der
Testdatensatz-Schreiber TDS schreibt die systeminterne, sequenzielle
Repräsentation des Testdaten-Ausgabestroms TDM2, inklusive
aller statistischen Verfremdungen bzw. Modifizierungen, in einem Transportformat
heraus, das demjenigen des Eingabe-Testdatenstroms TD2 entspricht
und sich zur Weiterleitung an die angeschlossenen Auswerteeinheiten
(AE; 1) bzw. Clients eignet.
-
4 zeigt
ein beispielhaftes Diagrammbild für den Modelimodifizierer
MM2 in objektorientierter Notation zur Darstellung des strukturellen
Zusammenhangs zwischen den Komponenten des Modellmodifizierers und
mit beispielhaften Aufrufmethoden.
-
Komponenten des Modellmodifizierers
-
Die
Modellwandler MW bilden Minimalcontainer zur Ausführung
der statistischen Testdatenverfremdungen und Testdatenmodifizierungen.
-
Die
Wandler-Pipelines WP fassen eine Menge von Modellwandlern MW zum
Zweck ihrer sequenziellen Ausführung zusammen. Sie gestatten
das flexible Hinzufügen oder Löschen von Wandlern
MW, sowie die Änderung ihrer Ausführungsreihenfolge
im Rahmen ihrer Initialisierung. Jeder Modellwandler MW, der in
eine Pipeline WP aufgenommen wird, wird durch eine so genannte Modellauswahl
MAU ergänzt.
-
Diese
Modellauswahlen MAU beschreiben eindeutig die von den einzelnen
Modellwandlern MW zu ändernden Modellentitäten,
inklusive der auf ihnen auszuführenden Operationen (d.
h. Modifizierungsalgorithmen) und den dafür gültigen
statistischen Wertebereich.
-
Die
Wandler-Aufrufer WA initialisieren die Wandler-Pipelines WP und
lösen die sequenzielle Ausführung ihrer gespeicherten
Modellwandler MW aus.
-
Die
in den jeweiligen Modellauswahlen MAU hinterlegten Selektionskriterien
entsprechen in ihrer Anordnung einer dreispaltigen Tabelle, deren
Zeilen jeweils einem einzelnen Modifizierungsschritt auf den Modellentitäten
zugeordnet werden können. Ihre erste Spalte enthält
eine Formalbeschreibung der zu modifizierenden Modell-Entitäten
(z. B. durch eine proprietäre Deklaration „Ehepartner
mit Kindern”, oder eine Beschreibung in einer bekannten
Deklarationssprache, z. B. in SQL für Datenbankzugriffe),
die zweite die auf der Ergebnismenge als eigentlicher Modifizierungsalgorithmus'
auszuführende Operation (z. B. durch proprietäre Deklaration „Referenz
zum Ehepartner trennen”, bzw. z. B. ein Verweis auf eine
Klasse einer OO-Sprache, welche ein entsprechendes Änderungsinterface
implementiert). Die dritte Spalte enthält das für
diese spezielle Operation (bzw. Modifizierungsalgorithmus) zu berücksichtigende,
zusammenhängende statistische Intervall [a,b] (Urbild)
einer zugrundeliegenden statistischen Dichtefunktion (probability
density function, pdf) als Zahlenpaar {a,b}, welches zur statistischen
Auswahl der zu ändernden Entitäten eines Selektionsergebnisses
berücksichtigt werden soll (z. B. „[1,2]” für
eine Gaußsche Standardnormalverteilung, siehe Folgebeschreibung der
Modellmodifizierung). Eine einzige Modellauswahl MAU kann einen
oder mehrere derartige Listeneinträge umfassen, die jeweils
einer einzigen Operation, oder auch mehreren entsprechen. Verschiedene
Selektionskriterien werden mit logisch OR (nicht-ausschließend)
miteinander verknüpft.
-
Zur
Umsetzung der statistischen Modellmodifizierung auf dem Daten- bzw.
Objektmodell (OM1; 3) kommen zudem die folgenden
Einheiten zur Anwendung:
Die Modell-Selektoren MS, die von
Seiten der Modellwandler MW aufgerufen werden, bestimmen anhand
der dem jeweiligen Modifizierungsschritt zugeordnete Zeile einer
Modellauswahl MAU die Treffermenge an Modellentitäten unter
Berücksichtigung des jeweiligen Modell-Kontextes und liefern
sie als Selektions-Ergebnis SE zurück an den aufrufenden
Modellwandler MW.
-
Die
Randomisierer R liefern Zufallswerte einer beliebigen, statistischen
Dichtefunktion bzw. Verteilung (z. B. Exponential-, Gamma-, Hyperbolische,
Logarithmische oder Normalverteilung). Sie werden von Seiten der
Modellwandler MW zur Bildung der statistisch zu bestimmenden Teilmenge
der Entitätsauswahl, sowie zur Ausführung der
statistischen Operationen (Modifizierungsalgorithmen) auf dieser
Teilmenge aufgerufen.
-
Die
Modell-Allokatoren MAL übertragen die von den Modellwandlern
MW statistisch verdichtete Ergebnismenge statistisch modifizierter
Modellentitäten in den Modell-Kontext MK und bringen die
jeweilige Modifizierung durch Modell-Schreibzugriffe zum Abschluss.
Für bestimmte logische Verknüpfungen mit anderen Selektionskriterien
können die Modell-Schreibzugriffe entfallen (Leerallokatoren).
-
Die
Modell-Kontexte MK steuern den Zugriffsmodus (Access Mode) von Seiten
der Modell-Selektoren MS:
- • Im Universalmodus
operieren alle Modellwandler MW einer Pipeline WP auf dem Gesamtmodell,
d. h. alle Modellentitäten können innerhalb eines
Durchlaufs potenziell von den Verfremdungen bzw. Modifizierungen
betroffen sein.
- • Im Selektionsmodus wird die Selektionsmenge der Modellwandler
MW mit der Entitäts-Teilmenge eines bzw. mehrerer vorausgegangener
Modellwandler MW bzw. Modell-Selektoren MS abgeglichen oder gefiltert
(AND = nur übereinstimmende Entitäten auswählen,
OR (ausschließend) = alle übereinstimmenden Entitäten
löschen). Die Entitätsmenge mit statistischen Änderungen
wird in den Modell-Kontexten MK gespeichert.
- • Im Negationsmodus operieren die Modellwandler MW
auf einer Differenzmenge von Modellentitäten, indem mit
Hilfe der Modell-Kontexte MK bereits ausgewählte Modell-Entitäten
aus dem Ergebnis der zuletzt ausgeführten Selektionen herausgefiltert
werden.
-
Mit
den in Tabelle 1 gezeigten Verbindungsmustern lassen sich verschiedene
logische Verknüpfungen zwischen den statistischen Modifizierungen
der Modellwandler MW darstellen. Dabei können die verschiedenen
Teilselektionen ohne Weiteres mit verschiedenen Aktionen belegt
sein.
-
Die
Gesamtwirkung der Modifizierung und Verfremdung des Verfahrens auf
das Modell resultiert aus derjenigen der einzelnen Modellwandler
MW in Kombination mit den Modellauswahlen MAU, die sich wiederum
mit Hilfe der Pipelines WP modular miteinander kombinieren lassen.
Das Umschalten des Zugriffsmodus während eines Pipeline-Verarbeitungslaufs
ist möglich.
-
Ein
Einzeldurchlauf zur statistischen Datenverfremdung einer einzelnen
Pipeline WP unterteilt sich einerseits in die Phase Pipeline-Initialisierung,
andererseits in diejenige der Modellmodifizierung
| Verknüpfungsart
der Selektionskriterien | Bedeutung | Mögliche
Realisierung |
| AND | Selektionsergebnis,
das alle Selektionskriterien der Modellauswahlen erfüllt. | Ausführung
im Selektionsmodus, Leerallokatoren der vorgeschalteten Wandler,
Modellallokation im abschließend ausgeführten Wandler. |
| OR
(nicht-ausschließend) | Selektionsergebnis,
das mindestens eine der Selektionskriterien einer Modellauswahl
erfüllt. | Ausführung
im Universalmodus, alle Modellwandler mit eigenen Operationen, Direktallokation
jedes Modellwandlers. |
| OR
(ausschließend) | Selektionsergebnis,
das genau ein angegebenes kombiniertes Selektionskriterium erfüllt. | Ausführung
im Selektionsmodus, Leerallokatoren der vorgeschalteten Wandler,
Modellallokation im abschließend ausgeführten Wandler. |
| NOT | Ausführung
einer oder mehrerer Operationen auf einer Modellauswahl, aus der
die Selektionsergebnisse vorheriger Modellauswahlen ausgeschlossen
sind. | Ausführung
im Negationsmodus, Leerallokatoren der vorgeschalteten Wandler,
Modellallokation im abschließend ausgeführten Wandler. |
Tabelle
1: Realisierung von logischen Verknüpfungsoperationen mittels
Modellwandlern (MW) und Pipelines (WP)
-
5 zeigt
eine beispielhafte Pipeline-Initialisierung in Sequenzdiagramm-Darstellung
(Message Sequence Chart – Notation, MSC) und stellt den
Ablauf der Pipeline-Initialisierung grafisch dar. Die Pipelines
WP' bieten den Wandler-Aufrufern WA' einen Einstiegspunkt zu ihrer
Initialisierung. Dabei werden die folgenden Schritte durchlaufen:
- • Die in dem jeweiligen Verfremdungslauf
anzuwendenden Modellwandler MW' und Modellauswahlen MAU' mit den
Elementar-Modifizierungen am Testdaten-Modell, werden angelegt und
initialisiert. Der Zugriffsmodus der Modellauswahlen MAU' wird festgelegt.
- • Sie werden in einer festgelegten Reihenfolge zur
späteren sequenziellen Ausführung abgespeichert.
-
Die
Initialisierung einer Pipeline WP' beeinflusst die Testdatenverfremdung
wesentlich, indem sie in den in den folgenden Punkten flexibel konfigurierbar
ist:
- • Verschiedene Modellwandler
MW' können in variabler Reihenfolge in Pipelines WP' zusammengefasst werden.
Deren Konfiguration, z. B. durch Zuordnung der gewünschten
Randomisierer R', oder der Art ihrer gegenseitigen logischen Verknüpfung
mittels der Modell-Kontexte, lässt sich frei festlegen.
- • Die den Modellwandlern MW' zugeordneten Modellauswahlen
MAU' enthalten die bereits beschriebenen Modell-Selektionskriterien,
inklusive der Operationen (Modifizierungsalgorithmen), die auf die
Modellentitäten angewendet werden, und den zugeordneten
statistischen Wertebereich. Diese Einstellungen lassen sich frei
bestimmen. Jede Modellauswahl MAU' wird im Zuge der Pipeline-Initialisierung
auch mit dem jeweiligen Zugriffsmodus hinsichtlich der Modell-Kontexte
(MK; 4) versorgt.
- • Die Modell-Selektoren MS' und Modell-Allokatoren
MAL' führen die Lese- und Schreiboperationen auf dem Daten-
bzw. Objektmodell (OM1; 3) der Testdaten aus. Sie stellen
hierfür alle notwendigen technischen Anschlüsse
zur Verfügung, die vor der Ausführung der Pipelines
WP' konfiguriert werden müssen. Zur Initialisierung der
Modell-Selektoren MS' bzw. Modell-Allokatoren MAL' wird dazu ein
jeweiliger, technischer Anschlussdeskriptor des Testdatenmodells übergeben
und durch ,AccessIni' symbolisiert. Er deckt die technischen Freiheitsgrade
der Konfiguration von Technologieadaptern zum Lese- und Schreibzugriff auf
das Testdatenmodell ab (z. B. Datenbank-, Datei-, oder Web Service-Zugriffe).
-
6 zeigt
mögliche Verarbeitungsschritte zur Modellmodifizierung
in Sequenzdiagramm-Darstellung (Message Sequence Chart – Notation,
MSC) und stellt den Ablauf der Modellmodifizierung grafisch dar.
Die Wandler-Aufrufer WA'' leiten diese Phase ein. Sie rufen die
entsprechende Schnittstelle der Wandler-Pipelines WP'' auf, die
ihrerseits ihre Modellwandler MW'' sequenziell ausführen.
-
Die
Modellwandler MW'' stellen die Basis-Einheiten der kontrollierten
Testdatenverfremdung dar. Sie ändern die zugrunde liegenden
Testdatensätze klar eingegrenzt auf einer tiefliegenden
technischen Ebene, z. B. einem einzelnen Datenfeld oder Objektattribut.
-
Die
Pipelines WP'' lesen den jeweiligen Folgewandler aus, und übergeben
ihm die jeweils zugeordnete Modellauswahl MAU''. Die Modellwandler
MW'' führen ihre Modell-Teilmodifizierungen anhand der
jeweiligen Modellauswahl MAU'' (und dem Modell-Kontext, bzw. Zugriffsmodus),
sowie der in den jeweiligen. Randomisierern R'' hinterlegten statistischen
Verteilungsfunktionen aus. Dabei durchlaufen sie die folgenden Schritte:
Die
jeweilige Modellauswahl MAU'' wird an den jeweiligen Modell-Selektor
MS” zur Auswertung übergeben. Dieser führt
Leseoperationen auf dem Modell unter Anwendung der entsprechenden
Selektionskriterien aus, filtert die Ergebnismenge unter Einbeziehung
des Zugriffsmodus und liefert schließlich als Selektions-Ergebnis die
statistisch zu modifizierende Treffermenge von Modellentitäten
zurück.
-
Die
Modellwandler MW'' verdichten dieses Selektions-Ergebnis unter Berücksichtigung
der statistischen Verteilungsfunktionen der jeweiligen Randomisierer
R'' folgendermaßen:
Ein Wandler MW'' ermittelt zu
jeder Entität aus der von den Modell-Selektoren MS'' unter
Berücksichtigung des jeweiligen Modell-Kontexts MK' zurückgegebenen
Treffermenge über die Randomisierer R'' einen Zufallswert und
prüft, ob dieser im korrelierten statistischen Wahrscheinlichkeitsintervall
der Modellauswahl MAU'' liegt.
-
Liegt
der Zufallswert außerhalb des statistischen Wahrscheinlichkeitsintervalls,
wird die entsprechende Entität aus dem Selektions-Ergebnis
gestrichen, und die Treffermenge um diese Entität reduziert.
-
Die
Modellwandler MW'' für auf alle im Selektions-Ergebnis
verbliebenen Entitäten statistische Operationen (Modifizierungsalgorithmen)
aus. Zur Erzeugung statistischer Entitäts-Verfremdungen
und -Modifizierungen des Daten- bzw. Objektmodells (OM1; 3)
können an dieser Stelle wiederum Randomisierer-Aufrufe
R'' stehen.
-
Die
modifizierten Entitäten werden an den zugeordneten Modell-Allokator
MAL'' übergeben, der – falls es sich nicht um
einen Leerallokator handelt – die Verfremdungen bzw. Modifizierungen
mittels Schreiboperationen in das Daten- bzw. Objektmodell (OM1; 3) überträgt.
-
Die
Vorteile des beschriebenen Verfahrens kommen insbesondere dann zum
Tragen, wenn für die angeschlossenen Auswerteeinheiten
(AE; 1) bzw. Clients aus Fremdsystemen bzw. anderen
Datenquellen stammende Zulieferungen simuliert werden sollen, die
außerhalb der eigenen Einflusssphäre bzw. Qualitätssicherung
liegen, oder für die sich etwa aufgrund der Transport-
oder Übermittlungsmethoden unvorhersehbare Datenverluste
und -defekte ergeben könnten. Außerdem eignet
sich das Verfahren etwa gut dazu, DV-technische Migrationsszenarien
(z. B. Umstellung einer Anwendung auf eine neue Bediensprache einer
Anwendung, z. B. vom Englischen ins Chinesische), bei denen vorhandene
Codeteile z. B. mit einer bestimmten Wahrscheinlichkeit neue Datentypen
oder Attributbelegungen verarbeiten müssen, wirklichkeitsnah
zu simulieren. Dieses gilt insbesondere dann, wenn bereits Generatoren
für die Erzeugung von Testdaten für die jeweilige
Altanwendung existieren. Die Verarbeitung in den angeschlossenen
Auswerteeinheiten (AE; 1) bzw. Clients kann im Hinblick
auf deren Ausnahme verhalten (Exception Handling) bzw. Datenkorrekturverhalten
systematisch getestet werden.
-
Insbesondere
bietet das beschriebene Verfahren die folgenden Vorteile:
- • Es ist von speziellen Modell-Darstellungsformen
bzw. Implementierungstechnologien unabhängig.
- • Zwischen Konfiguration und Initialisierung der Ausführungslogik
zur Datenmodifizierung (Konstruktion der Pipelines), sowie ihrer
Ausführung wird aus systemtechnischer Sicht klar unterschieden.
Strukturell unterschiedliche Testdaten-Modifizierungen sind in den
einzelnen Modellwandlern konzentriert, und lassen sich so entwicklungstechnisch,
organisatorisch und operationell eindeutig voneinander trennen.
- • Die separat entwickelten Kernalgorithmen zu Modellmodifizierung
in den jeweiligen Modellwandlern können unter Berücksichtigung
von beliebigen, statistischen Gewichtungen miteinander logisch,
unter Einbeziehung verschiedener Operationen für jede Selektion,
verknüpft werden.
- • Dieselben Modellwandler lassen sich deshalb auch
aus verschiedenen Veränderungs-Kontexten (d. h. Pipelines)
heraus anwenden und ausführen. Elementare Modifizierungen,
z. B. hinsichtlich einzelner Datenfelder bzw. Attribute, können
mit Hilfe des Pipeline-Konzepts ohne größeren
Aufwand in einen umfassenden Veränderungsrahmen eingebunden
werden. Die sich aus den Pipeline-Initialisierungen resultierende
Anwendung der statistischen Teilmodifizierungen einzelner Modellwandler
wird dadurch transparent, leicht konfigurier- und steuerbar.
- • Die Pipelines inklusive ihrer Modellwandler können
zentral in einem Repository gesammelt werden, was das Anlegen funktional
eindeutiger und wiederverwendbarer Testdaten-Änderungsprofile
erlaubt. Auf diese Weise können statistische Modifizierungs-Bibliotheken
zusammengestellt werden, die sich anhand ihres generellen Verfremdungs-
und Modifizierungs-Verhaltens in Bezug auf die Testdaten klassifizieren
lassen.
- • Die Modellwandler führen die eigentlichen
statistischen Modellveränderungen und -modifizierungen
wiederum anhand von Randomisieren aus. Die zugrunde liegenden, statistischen
Verteilungsfunktionen lassen sich daher einfach ersetzen bzw. ändern.
-
7 zeigt
ein Beispiel für die Anwendung des Verfahrens zur statistischen
Modifizierung eines Test-Datenstroms. In 7 ist das
Datenmodell OM2 eines einfachen Systems zur Auftragsverwaltung in
objektorientierter Notation dargestellt, mit Beziehungen zwischen
den Datenobjekten und mit Methoden der Objekte im beispielhaften
Datenmodell OM2. Dieses enthält die Entitäten „Kunde”, „Lieferauftrag” (mit
den verschiedenen Lieferungstypen „Schnelllieferung”, „Standardlieferung”)
sowie „Historie”. Die Entitäten sind
als Rechtecke dargestellt, die Beziehungen zwischen den Entitäten
als Pfeile bzw. als Linien.
-
Alle
offenen Aufträge sind einem Kunden direkt zugeordnet. Nach
dem Abschluss eines Auftrags wird dieser in die Kundenhistorie übertragen,
und die direkte Referenz zum jeweiligen Kunden gelöscht.
-
Szenario
-
Dieses
System wird neu entwickelt, und ersetzt ein bestehendes Altsystem.
Die im Altsystem vorhandenen Daten müssen in das Neusystem
migriert werden. Da ein Teil der Altaufträge zudem lediglich
in Papierform vorliegt, ist es erforderlich, deren Daten zur Übertragung
in das Neusystem manuell zu erfassen. Insgesamt ist deshalb davon
auszugehen, dass der zu migrierende Datenbestand zu einem bestimmten
Prozentsatz fehlerhaft sein wird.
-
Eine
statistische Abschätzung macht dabei die folgende Fehlerverteilung
wahrscheinlich:
- • In 5% der Fälle
ist der Typ eines Lieferauftrags (Schnell- und Standardlieferung)
fälschlicherweise vertauscht. Sie zeichnen sich durch eine
fehlerhafte bzw. unvollständige Attributbelegung aus.
- • Für 40% dieser fehlerhaften Lieferaufträge
besteht zusätzlich irrtümlich eine falsche Kundenzuordnung.
- • In 30% der Fälle fehlt in den Historien-Objekten
die Referenz auf einen Altauftrag. Diese wird während der Migration
mit einem Spezialalgorithmus aus den vorhandenen Daten rekonstruiert.
-
Diesen
statistischen Angaben liegt eine Gleichverteilung zugrunde, d. h.
es werden Randomisierer R, R', R'' gewählt, die den Modifizierern
MM1, MM2 alle Werte eines Werteintervalls, z. B. aus dem Grundintervall [0,1],
mit derselben Wahrscheinlichkeit zurückliefern.
-
Ziel
ist nun, Testdatensätze zu erhalten, die eine möglichst
hohe Testabdeckung dieser Statistik gewährleisten. Hierzu
wird mit einem Testdatengenerator eine große Zahl valider,
zufällig erzeugter Testdatensätze für
dieses Datenmodell OM2 erzeugt.
-
Anschließend
erfolgt deren statistische Modifizierung unter Anwendung des beschriebenen
Verfahrens wie folgt: Im Szenario kommen drei Modifizierer MM1,
MM2 zur Anwendung:
- • Modifizierer
1 setzt den Typ eines Lieferauftrags um, d. h. liegt eine Schnelllieferung
vor, wird diese in eine Standardlieferung gewandelt (und umgekehrt).
Fremdattribute werden in diesem Zusammenhang zufällig falsch
bzw. nicht belegt.
- • Modifizierer 2 löst einen offenen Auftrags
(bzw. seine Referenz) von einem Kunden und weist ihn einem aus dem
Gesamtbestand (der Grundgesamtheit) zufällig ausgewählten
anderen Kunden zu.
- • Modifizierer 3 löscht in einer Historie
die Referenz auf einen Altauftrag.
-
Den
im Szenario verwendeten Modifizierern (MM2;
4) sind
die folgenden Modellauswahlen (MAU, MAU', MAU'';
4–
6)
zugeordnet: Modellauswahl 1:
| Selektionskriterium | Operation | Statistik-Intervall |
| „Alle
Kunden-Lieferaufträge” | „Lieferungstyp
umsetzen” | [0,0.05]
(= 5%) |
Modellauswahl 2:
| Selektionskriterium | Operation | Statistik-Intervall |
| „Alle
Kunden” | „Einzelkunde ändern” | [0,1]
(= 100%) |
| „Lieferauftrag
eines speziellen Kunden” | „Auftrag
einem anderen Kunden zufällig zuweisen” | [0,0.4]
(= 40%) |
-
Die
beiden Operationen sind in Modifizierer 2 hinsichtlich der Ausführung
ineinander geschachtelt, d. h. m Rahmen der Operation „Einzelkunde ändern” wird
die Operation „Auftrag einem anderen Kunden zufällig zuweisen” ausgeführt. Modellauswahl 3:
| Selektionskriterium | Operation | Statistik-Intervall |
| „Alle
Historien” | „Auftragsreferenz
löschen” | [0,0.3]
(= 30%) |
-
Die
Modell-Selektoren (MS, MS', MS''; 4–6)
müssen die Selektionskriterien auswerten, und die Modell-Allokatoren (MAL,
MAL', MAL''; 4–6)
die geänderten Entitäten wieder in das zugrunde
liegende Modell übertragen können.
-
Das
Testszenario aus 7 wird mittels zweier Pipelines
(WP, WP', WP''; 4–6)
umgesetzt:
- • Pipeline 1, die zwei
Modifizierer/Modellauswahl-Paare enthält: Modifizierer
1/Modellauswahl 1 im Zugriffsmodus AND, Modifizierer 2/Modellauswahl
2 im Zugriffsmodus OR (nicht-ausschließend).
- • Pipeline 2, die ein Modifizierer/Modellauswahl-Paar
enthält: Modifizierer 3/Modellauswahl 3 im Zugriffsmodus
OR (nicht-ausschließend).
-
Auf
der Java-Technologieplattform kann für den Randomisierer
(R, R', R''; 4–6)
z. B. der RANDOM-Zufallsgenerator (aus dem Paket java.util.random)
eingesetzt werden. Auch andere Implementierungen von (deterministischen)
Zufallsgeneratoren können eingesetzt werden.
-
Die
Modell-Selektoren (MS, MS', MS''; 4–6)
und Modell-Allokatoren (MAL, MAL', MAL''; 4–6)
lassen sich auf Basis zahlreicher Anschlusstechnologien umsetzen.
Ist das Daten- bzw. Objektmodell OM2 in einer Datenbank gespeichert,
können die Modell-Selektoren bzw. -Allokatoren auf der
Java-Technologieplattform z. B. mittels der JDBC-Technologie (Java
Database Connectivity) auf diese Datenbank zugreifen.
-
Eine
besondere Stärke des Verfahrens liegt darin, dass sich
mit einem geringen Aufwand bereits erstellte Modifizierer (MM2; 4)
für andere, neu zu erstellende Testfälle wiederverwenden
lassen.
-
Hierzu
sei die folgende Testanforderung betrachtet:
In den historisierten
Daten sind für 10% aller Lieferaufträge Schnelllieferungen
mit Standardlieferungen verwechselt. Mit einer 30%-Wahrscheinlichkeit
sind sie zusätzlich einer anderen Historie zugeordnet.
-
Unter
Wiederverwendung des Modifizierers 1 kann das Verfahren folgendermaßen
angewendet werden:
Zwei Modifizierer kommen zur Anwendung:
- • Modifizierer 1 (ungeändert)
- • Modifizierer 4, mit der Operationen „Einzelhistorie ändern”, „Lieferauftrag
in andere Historie übertragen” (alternativ dazu
könnte ein geänderter Modifizierer 3' angelegt
werden, der um die beiden genannten Operationen erweitert wird,
vgl. Bemerkung unten).
-
Diesen
beiden Modifizierern sind die folgenden Modell-Auswahlen zugeordnet: Modell-Auswahl 1':
| Selektionskriterium | Operation | Statistik-Intervall |
| „Alle
Lieferaufträge aller Historien” | „Lieferungstyp
umsetzen” | [0,0.1]
(= 10%) |
Modell-Auswahl 4:
| Selektionskriterium | Operation | Statistik-Intervall |
| „Alle
Kundenhistorien” | „Einzelhistorie ändern” | [0,1]
(= 100%) |
| „Lieferaufträge
zu einer Historie” | „Lieferauftrag
in andere Historie übertragen” | [0,0.3]
(= 30%) |
-
Die
beiden Operationen sind in dem Modifizierer (MM2; 4)
ineinander geschachtelt, d. h. im Rahmen der Operation „Einzelhistorie ändern” führt
der Modifizierer die Operation „Lieferauftrag in andere
Historie überführen” ausgeführt.
-
Die
Modell-Selektoren müssen die Selektionskriterien auswerten,
und die Modell-Allokatoren die geänderten Entitäten
wieder in das zugrunde liegende Modell übertragen können.
-
Das
Testszenario wird mittels einer Pipeline umgesetzt:
Pipeline
3 mit zwei Modifizierer/Selektor-Paaren: Ungeänderter Modifizierer
1/Modellauswahl 1 im Zugriffsmodus AND, Modifizierer 4/Modellauswahl
4 im Zugriffsmodus OR (nicht-ausschließend) [Default-Einstellung].
-
Kombinatorisch
ergeben sich schließlich alle weiteren Varianten, Modifizierer
1–4 mittels Pipelines miteinander zu verknüpfen.
-
Der
Einsatz und die Anwendungsmöglichkeiten des beschriebenen
Verfahrens zur Testdatenverfremdung sind sehr flexibel:
- • Verschiedene Selektionskriterien einer Modellauswahl
werden logisch OR (nicht-ausschließend) miteinander verknüpft.
Zwischen den Einzelselektionen einer Modellauswahl, die von einem
Modifizierer verarbeitet wird, findet kein Aufruf der Modell-Allokatoren
statt.
- • Auf die Modell-Selektoren kann auch operationsweise
zugegriffen werden, sofern mehrere Operationen in einer Modellauswahl
vorhanden sind. D. h. die Modell-Selektoren liefern dann die Ergebnisse
der aktuellen Zeile der Modellauswahl zurück.
- • Die Verknüpfungsoperatoren könnten
in einer spezifischen Implementierungsausprägung auch als
zusätzliche Spalte in die Modellauswahlen übernommen
werden.
- • Wurden auf den Entitäten des Modell-Kontexts Änderungen
durchgeführt, bleiben diese im Selektionsmodus bei erneuter
Entitätsauswahl automatisch erhalten. Die Modell-Kontexte
führen ihren Abgleich in Bezug auf die geänderten
Entitäten durch, prüfen also in Bezug auf die
Einordnung in das Daten- bzw. Objektmodell, und nicht in Bezug auf
die aktuelle Wertbelegung.
- • Ob ein eigener Modifizierer angelegt wird, oder ein
bestehender um eine neue Operation erweitert wird, ist eine Frage
der Abwägung. Eine zu große Anzahl von Operationen
in einem Modifizierer sollte vermieden werden, und die Modifizierer
in Bezug auf seine Operationen vorzugsweise auf eine Modellentität
spezialisiert sein.
-
Tabelle
2 zeigt weitere besondere Vorteile des beschriebenen Verfahrens.
| Eigenschaft | Beschreibung |
| Rasche
Erzeugung von unterschiedlichen statistischen Testdatensätzen
zum Test des Korrekturverhaltens bzw. der Ausnahmebehandlung. | Gewissermaßen
auf Knopfdruck können geeignete Testdatensätze
unterschiedlicher Größe und Komplexität
(Modifizierungstiefe) mit kontrollierten Testdatenverfremdungen
und -modifizierungen bereitgestellt werden. Insbesondere im Hinblick
auf Last- und Performancetests in Bezug auf Korrekturverfahren und
Ausnahmebehandlung ergeben sich dadurch Anwendungsvorteile. |
| Klare
Trennung zwischen den statistischen Selektionskriterien der zu ändernden
Entitäten, sowie der auf sie anzuwendenden Operationen. | In
der konkreten Implementierung könnte z. B. für die
Implementierung in einer OO-Sprache etwa eine Oberklasse GenericModifizierer
gebildet werden, welche eine statistische Selektion auf den Entitäten, die
von Seiten der Modell-Selektoren zurückgeliefert werden,
vornimmt. In dem hier beschriebenen Beispiel kann für alle
Modell-Selektionen derselbe, eine Gleichverteilung realisierende
Randomisierer verwendet werden.
Modifizierer 1–4 würden
von dieser GenericModifizierer-Klasse erben. Konkret müssen
dann nur noch die statistischen Vorbelegungen korrekt initialisiert und
die Operationen implementiert werden. |
| Möglichkeit
zur systematischen Sammlung der statistischen Modifizierer, Modellauswahlen
und Pipelines in einer zentralen Verwaltungseinheit (Repository) | In
dem Beispiel nach Figur 7 könnte eine derartige Sammlung
folgendermaßen aussehen:
Modifizierer (inkl. anhängiger
Komponenten wie Randomisierer, Selektoren ...)
• Modifizierer
1 – „Kundenlieferaufträge umsetzen”
• Modifizierer
2 – „Offenen Lieferauftrag anderem Kunden zuweisen”
• Modifizierer
3 – „In Historie Referenz auf Altauftrag löschen”
• Modifizierer
4 – „Historisierten Lieferauftrag anderer Historie
zuweisen”
Pipelines
• Pipeline 1 – „Statistische
Migrationsabschätzung Lieferauftrag (5%/40%)”
• Pipeline
2 – „Statistische Migrationsabschätzung Historie
(30%)”
• Pipeline 3 – „Geänderte
Migrationsabschätzung Historie (10%/30%)” Die
Modifizierer können über die Pipelines auch zu
anderen statistischen Veränderungsprofilen zusammengesetzt
werden. |
| Flexible Änderung
der statistischen Verteilungen u. Gewichtungen, auch in Bezug auf
die Attributbelegung | Durch
Einschaltung entsprechender Randomisierer in den Modifizierern,
sowie geänderten statistischen Gewichtungen lassen sich
auf einfache Weise spezielle statistische Zusammenhänge
modellieren.
Z. B. könnte so die folgenden Testanforderung
abgedeckt werden:
• Das Datum von 35% der Lieferauftrags-Eingänge ist
um den 01.04.2008 herum standardnormalverteilt (z. B. zum Test eines
Lastszenarios für ein Auswertemodul).
• Die
Kundennamen sollen durch zufällige chinesische Schriftzeichen
ersetzt werden, mit einer um 12 Buchstaben herum normalverteilten
Länge (z. B. für den Test einer Internationalisierung
der Benutzerführung einer bereits vorhandenen Applikation) |
Tabelle
2: Weitere Vorteile des Verfahrens
-
Verfahren
und Einrichtung zur automatischen Generierung von Testdaten. Ein
sequentieller Eingabe-Testdatenstrom wird in ein Objektmodell abgebildet,
welches durch Modellwandler statistisch verfremdet und wieder als
sequentieller modifizierter Eingabe-Testdatenstroms für
Auswerte-Einheiten (z. B. Clients) zur Durchführung von
Tests (z. B. Funktionstest, Lasttests) bereitgestellt wird. Dadurch
können in einer kontrollierten Weise weitere Testdaten
erzeugt werden, mit denen spezielle Testfälle der angeschlossenen
Auswerte-Einheiten (z. B. in Bezug auf deren Ausnahmebehandlung)
realisiert werden können.
-
Bezugszeichen
-
-
- TD1, TD2
- Eingangstestdaten
- TDM1, TDM2
- Modifizierte Testdaten
- AE
- Auswerteeinheit
- S1–S8
- Verfahrensschritt
- OM1, OM2
- Objektmodell
- TDL
- Testdatensatz-Leser
- TDF
- Testdatensatz-Filter
- TDS
- Testdatensatz-Schreiber
- FE
- Filterungs-Ergänzer
- MM1, MM2
- Modell-Modifizierer
- S
- Serialisierer
- DS
- Deserialisierer
- WP, WP', WP''
- Wandler-Pipeline
- WA, WA', WA''
- Wandler-Aufrufer
- MAU, MAU', MAU''
- Modell-Auswahl
- MAL, MAL', MAL''
- Modell-Allokator
- MW, MW', MW''
- Modell-Wandler
- MK, MK''
- Modell-Kontext
- MS, MS', MS''
- Modell-Selektor
- SE
- Selektions-Ergebnis
- R, R', R''
- Randomisierer
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - DE 102007004361
A1 [0006]
- - EP 1505399 B1 [0007]