1. Systemtest Framework
1.1. Eingabe
1.1.1. Prüfung ob ein bestimmter Datensatz ggf schon existiert
1.1.1.1. existiert der Datensatz nicht, dann erfolgt eine Insert
1.2. Verarbeitung
1.2.1. Wird vollständig durch das System Under Test gehandhabt (BlackBox)
1.3. Ausgabe (Verifikation)
2. Datenstrukturen
2.1. Prozesskette (Definition der anzustoßenden Prozesse und deren Reihenfolge)
2.2. Selektionsdatenstruktur (CriteriaListen)
2.2.1. Definieren die Constraints bei einer Selektion -> daraus müssen SQL Selects generiert werden
2.2.1.1. Generierung eines großen Selects für den Anfang am sinnvollsten
2.2.1.2. Enricherframework möglicherweise hilfreich
2.2.1.2.1. Problem: Fallback für alte Funktionalitäten, die kein Enricherframework verwenden, nötig
2.2.2. hierarchische Anordnung nötig (Nicht alle Daten hängen an nur einer Tabelle)
2.3. Insertdatenstruktur
2.3.1. Definieren die Daten für eine Datengenerierung -> daraus müssen SQL Inserts generiert werden
2.3.2. Muss zum Auswählen von OIDs auf Selektionsdatenstruktur verweisen können
2.4. Insertdatenstruktur und Selektionsdatenstruktur müssen problemlos ineinander überführbar sein
3. Stored Procedures
3.1. erlauben auch komplexere Selects/Inserts
3.1.1. erlauben bessere Performance
3.2. Verstecken die DB Logik
3.3. Verringern duplikaten Code
3.3.1. einfachere Wartung
3.4. Problem: Kosistenz von Select und zugehörigem Insert
3.5. Um Test und System Under Test zu trennen wäre ein weiteres Datenbankschema für die Stored Procedures sinnvoll
3.6. Kombination mit Enricherframework unmöglich
4. Exceldatei
4.1. allgemeine Funktionen
4.1.1. Einlesen einzelner Zellen
4.1.2. Schreiben einzelner Zellen
4.1.3. Anstoßen der excelinternen Berechnungen (evtl. autmatisch beim Schreiben einer Zelle)
4.2. wie können die hierarchischen Constraints übersichtlich in Excel dargestellt werden?
5. Hauptaufgaben
5.1. Definition und Schaffung der Funktionalität, welche die Prozessketten ausführt
5.1.1. CARUSO TestBG-Klasse sehr hilfreich
5.2. Entwicklung der Selektionsdatenstruktur
5.3. Entwicklung der Insertdatenstruktur
6. Baustufen
6.1. Baustufe 0
6.1.1. weitere verwendete Daten sind in der TestDB vorhanden und werden durch Oids spezifiziert
6.1.2. feste technische Schlüssel (Copy & Paste aus Tabellen; Duplikate Oids usw.)
6.2. Baustufe 1
6.2.1. Prozesskette statt nur ein Prozess
6.2.2. weitere verwendete Daten sind in der TestDB vorhanden und werden durch fach. Schlüssel spezifiziert
6.2.3. fachliche Schlüssel (statt STORE.OID; STORE.STORE_NO oder STORE.STATUS...)
6.2.4. Variable (Criteria, Selects)
6.2.5. Verweis auf Stored Procedures
6.2.6. Definition von Selects mit Variablen für Subselects und Criteria
6.2.7. Sehr große Schritte möglich
6.3. Baustufe 2
6.3.1. weitere verwendete Daten müssen in der TestDB nicht vorhanden sein
6.3.2. automatische Generierung der Daten (jedes select hat ein insert)Ideeautomatische Generierung der Daten (jedes select hat ein insert)
6.3.3. feste Definition von Selects nicht mehr möglich oder zumindest nur, wenn ein Insert hinterlegt wird
6.3.4. hoher Aufwand bis zu den ersten erfolgreichen Tests; kleine Schritte