Grundgedanke
Mit der Konfiguration wird das Verhalten des Programms gesteuert und kann damit die Programmlogik abstrahieren und vereinfachen. Das Wissen, das die Konfiguration erfordert, wird von unterschiedlichen Beteiligten beigesteuert, und zwar:
- Automatisierungswissen
- Anwendungswissen
- Installationswissen
Konfigurationshierarchie
Die Konfigurationshierarchie entspricht einer Vererbungshierarchie, in der die speziellste Konfiguration genommen wird und ansonsten von der nächst höheren Ebene geerbt wird. Die Ebenen entstammen dabei der Baum-Hierarchie der Konfigurationsdateien zu den Komponenten und Umgebungen.
---?---
Eine zu testende Anwendung besteht aus verschiedenen Komponenten, die jeweils im Testframework abgebildet werden. Die Abhängigkeit der Komponenten untereinander kann als ein Abhängigkeitsbaum dargestellt werden:
Testanwendung
+ Hauptanwendung_A
+ Hauptkomponente_A1
+ Subkomponente_A1A
+ Datenbank_A1B
+ DBMS
+ Hauptkomponente_A2
+ Hauptanwendung_B
+ Hauptkompnente_B1
+ Hauptkomponente_B2
+ Datenbank_B2A
+ DBMS
Es werden jeweils Anwendungen getestet - dies muss dem Programm auch immer als Startparameter mitgegeben werden. Die Auflösung des Anwendungsnamens in die Komponenten wird in der zentralen Basiskonfiguration definiert.
Die Komponenten selbst werden hinsichtlich des fachlichen Aspektes als Komponente konfiguriert, die teechnischen Aspekte der Installation in der Konfiguration zur Umgebung.
Basiskonfiguration
Wenn die Anwendung als ganzes oder nur in ihren Teilen getestet werden soll, kann das
Komponentenkonfiguration
Die Konfiguration der Komponenten erfolgt über folgende Dateien:
- Hauptkonfiguration
grundlegende Konfiguration der Komponente, Datei CONFIG.yml/json - Umgebungskonfiguration
umgebungsspezifische Konfiguration überschreiben ggf. die grundlegende Konfiguration - Tabellenkonfiguration
separate Konfiguration für Datenbanktabellen
conf:
instance: # sollte in Umgebungskonfiguration konfiguriert sein
count: 1 # für redundante
single: y # für mehrfache Nutzung einer Instanz
components: # FÜR FACHLICH ABHÄNGIGE KOMPONENTEN
none: none # Dummy-Eintrag
function: # IN WELCHEM TESTSCHRITT DIE KOMPONENTE AUFZURUFEN IST
check_environment: "todo"
init_testcase: "todo" # -> precondition, load testdata
finish_testcase: "todo" # -> postcondition, check data
artifact: # FÜR SCHNITTSTELLEN-ARTEFAKTE
db: # Haupttyp eines Artefakte (db, cli, api)
type: csv
lofts:
tabname: lofts
Instanziierungsblock
Bei der Initialisierung werden die Komponenten-Objekte instanziiert, die als Proxy zur Anwendungskomponente dient. Als Einstiegspunkt dient der Parameter anwendung, anhand dem die Hauptkomponenten instanziiert werden. Über das Attribut components können Sub-Komponenten instanziiert werden, wodurch ein Abhängigkeitsbaum entsteht.
Für redundante Anwendungsinstanzen können hier mehrere Komponenten-Objekte erstellt werden (count > 1). Es ist auch möglich, dass eine Komponente - insb. bei der Middleware - von mehreren Komponenten benutzt wird (single != y).
Aus der Umgebungskonfiguration werden insbesondere die Verbindungsdaten ergänzt.
Funktionsblock
Der Funktionsblock listet die Testschritte auf, bei denen die betreffende Komponente aufzurufen ist. Das wesentlich Bearbeitungsergebnis wird anstelle des Wertes "todo" eingetragen.
Die Komponenten werden mit den bis hier gesammelten Attributen im Ausführungsverzeichnis hinterlegt.
Artefakte-Block
Im Artefakte-Block werden die für den Test relevanten Schnittstellen konfiguriert. Sie bestehen aus einem der Haupttypen:
- db Datenbank
- cli Kommandozeilen-Interface
- api fachliche Schnittstelle zum Aufrufen
- file Eingabe-/Ergebnisdateien
Datenbank-Artefakte
Die Grundkonfigurationen können hier oder in den Umgebungskonfiguration angegeben werde. Diese sind:
- type Datenbanktyp wie csv, mysql, db2, ...
Für jeden erlaubten Datenbanktyp ist eine Subklasse zur DB-Klasse implementiert für die DB-Bearbeitungen select, insert, update und delete, die für die Initialisierung und für das Einsammeln benötigt werden.
Die eigentlichen Tabellen werden hier nur aufgelistet mit speziellen Konfigurationen - auch die Grundkonfigurationen können hier überschrieben werden.
Kommandozeilen-Artefakte
Die Grundkonfigurationen können hier oder in den Umgebungskonfiguration angegeben werde. Diese sind:
- type Kommandozeile des Betriebssystems wie bash, cmd ...
Für jeden erlaubten Kommandotyp ist eine Subklasse zur CLI-Klasse erstellt, so dass die Standardbearbeitung in den jeweiligen Dialekt übersetzt und ausgeführt werden kann.
API-Artefakte
Die Grundkonfigurationen können hier oder in den Umgebungskonfiguration angegeben werde. Diese sind:
- type API wie nifi, ...
Für jeden erlaubten API-Typ muss eine Subklasse zur API-Klasse implementiert sein.
Datei-Artefakte
Die Grundkonfigurationen können Komponetenkonfiguration (Datei CONFIG) oder in den Umgebungskonfiguration angegeben werde. Diese sind:
- type Dateityp wie xml, json, log ...
Die Datei-Typen sind Standardtypen. - reset Zeitpunkt, an dem der Tabelleninhalt bei der Testinitialisierung gelöscht wird:
- testsuite - nur am Anfang einer Testsuite
- testsequence - nur am Anfang einer Sequenz von Tesfällen
- testcase - am Anfang jedes Testfalls
- none - nie
- database technischer Name der Datenbank
- scheme technischer Name des Datenbankschemas
- tabname technischer Name der Tabellen (optional, default ist der
- prestep Tabelle, die als Quelle dieser Tabelle gelten kann für einen Quell-Ziel-Vergleich in Form database:[schema:]table
Werte, die nicht aus diesen Schlüsselworten bestehen, werden als Tabellenknoten aufgefasst. In den Tabellenknoten können eben diese Attribute gefüllt sein, die dann herangezogen werden.
Tabellenkonfiguration
Für die Bearbeitung der Datenbanktabellen sind unterschiedliche Informationen erforderlich, die in einer csv-Datei konfiguriert sein kann. Hierin sind folgende Attribute zu füllen:
- Feldname
- Datentyp
Neben dem technischen Datentyp wie date, int, string können fachliche Datentypen genutzt werden, die einen Wertebereich enthalten und einem technischen Typ zugeordnet sind. Diese werden initial katalogisiert. - Länge
- Akzeptanzregel
Bei der Auswertung können einzelne Felder wie ID-Felder ignoriert werden, was mit "ignore" einzugeben ist. Datumsfelder werden in Bezug auf das Durchführungsdatum validiert. Weitere - Genereierungsregel
Um Testdaten vereinfacht zu erstellen gibt es die Möglichkeit, dass ableitbare Felder aus anderen Feldern entsprechend einer zu implementierenden Regel abgeleitet werden. - Schlüssel
Zur Zuordnung der zu vergleichenden Zeilen müssen die passenden Zeilen gematcht werden. Hier ist ein fachliches oder technisches Matching möglich. Als Matchkriterium werden die fachlichen ("F:1", "F:2", ..) bzw. technischen ("T:1", ..) Felder entsprechend ihrer Rangfolge verglichen und zugeordnet.
Umgebungskonfiguration
testb:
instance: 1
inst1:
ip: 192.178.168.14
hostname: my-app-store-2
port: 54500
dompath: /opt/app/testb
Release-Abhängigkeit
Durch Releaseänderungen kann es zu strukturellen Änderungen der Anwendung kommen. Diese müssen von den Automatisierungskomponenten berücksichtigt werden und ggf. auch in den Testdaten. Die Konfigurations- und Testfalldaten müssen entsprechend weiterentwickelt werden.
Um Hotfixe zu testen muss ggf. auf eine ältere Version zurückgegriffen werden.
Welches Release auf einer Umgebung installiert ist, muss aus der jeweiligen Umgebung ermittelt oder hinterlegt sein -> hierzu Attrribut release zur jeweiligen Komponente.
Lösung A: Auschecken der passenden Version zum Vor-Release
Für die s
Lösung B: Versionieren der Konfigurationen
An den Konfigurationsdateien der Komponenten.