Eine Analyse kombinatorischer Testdesigntechniken

Ich werde hier nicht auf bekannte und weit verbreitete Testentwurfstechniken wie Äquivalenzklassen, Grenzwerttests und paarweise Tests eingehen, sondern auf andere, weniger verbreitete Techniken eingehen. Sie können auch meinen Artikel über Probleme mit kombinatorischen Testdesigntechniken lesen.

Testen von Entscheidungstabellen

Entscheidungstabellen sind ein hervorragendes Werkzeug zur Dokumentation von Anforderungen und zur Beschreibung der Funktionalität einer Anwendung. Diese Tabellen eignen sich sehr gut zur Beschreibung der Geschäftslogik der Anwendung und können darüber hinaus als solide Grundlage für die Erstellung von Testfällen dienen. Fehlt der getesteten Anwendung eine ordnungsgemäße Dokumentation, ist dies ein guter Grund, Entscheidungstabellen zu verwenden. Durch die kompakte und einfache Darstellung von Anforderungen ist die Erstellung von Testfällen ganz einfach.

Ansatz:

Entscheidungstabellen beschreiben die Logik der Anwendung basierend auf den Entitäten (Eigenschaften/Bedingungen) des Systemstatus. Jede Entscheidungstabelle sollte nur einen Zustand des Systems beschreiben.

	Regel 1	Regel 2	…	Regel N
Entitäten
Eigentum 1
…
Eigentum M
Aktionen
Aktion 1
…
Aktion P

Entität (Eigenschaft) von 1 bis M repräsentiert verschiedene Eigenschaften des Systems; Sie werden in der Tabelle als Eingabedaten dargestellt, die in das System eingegeben werden können. Aktionen von 1 bis P sind Aktionen, die mit der angegebenen Kombination von Entitäten ausgeführt werden können. Abhängig von der Kombination aller Eingabedaten von Entitäten nehmen Aktionen die erforderlichen Werte an. Jede Regel definiert einen eindeutigen Satz von Eingabedaten für alle Eigenschaften, die zur Ausführung bestimmter Aktionen führen.

Nach dem Erstellen der Entscheidungstabelle ist es normalerweise möglich, die Tabelle zu vereinfachen, indem beispielsweise einige oder alle der unmöglichen Szenarien entfernt werden. Anschließend kann die Tabelle in Testfälle umgewandelt werden.

---

Zustandsübergangstests

Zustandsübergangstests sind wie Entscheidungstabellentests ein wertvolles Werkzeug zur Dokumentation von Anforderungen und zur Beschreibung der Struktur und des Designs eines Systems. Im Gegensatz zum Entscheidungstabellentest, der einen bestimmten Systemzustand beschreibt, beschreibt der Zustandsübergangstest, wie sich diese Zustände des Systems ändern können. Diagramme definieren alle Ereignisse, die während des Betriebs der Anwendung auftreten, und wie die Anwendung auf diese Ereignisse reagiert.

Ansatz:

Es gibt zwei Arten der visuellen Darstellung dieser Technik:

1. Zustandsübergangsdiagramme
2. Zustandsübergangstabellen

Zustandsübergangsdiagramme

Betrachten wir als Beispiel die Reservierung von Flugtickets. Die Funktionsweise ist ungefähr wie folgt: Zunächst übermitteln Kunden der Fluggesellschaft Informationen zur Reservierung – Abflugort, Zielort, Datum und Uhrzeit des Abflugs. Ein Mitarbeiter einer Fluggesellschaft fungiert als Schnittstelle zwischen dem Kunden und dem Ticketreservierungssystem und nutzt die vom Kunden bereitgestellten Informationen, um eine Reservierung zu erstellen. Danach befindet sich die Reservierung des Kunden im Status „Gemacht“. Zusätzlich startet das System nach dem Erstellen der Reservierung einen Timer. Wenn der Timer abläuft und das reservierte Ticket nicht bezahlt wurde, storniert das System die Reservierung für dieses Ticket.

Der Kreis stellt den Zustand des Flugticketreservierungssystems dar, den „Made“-Zustand. Der Pfeil zeigt einen Übergang in den Zustand „Made“ an. Die Beschreibung unter dem Pfeil („get_info“) ist ein Ereignis, das von außerhalb des Systems stammt. Der Befehl in der Beschreibung unterhalb des Pfeils (nach „/“) bedeutet, dass das System als Reaktion auf das Ereignis eine Aktion ausgeführt hat – in diesem Fall das Starten eines Timers. Der schwarze Kreis markiert den Start-/Einstiegspunkt des Diagramms.

Wenn der Timer nicht abläuft und wir das reservierte Ticket bezahlt haben, wechselt das System in den Status „Bezahlt“. Dies wird durch den mit „payMoney“ beschrifteten Pfeil und den Übergang vom „Made“-Zustand zum „Paid“-Zustand dargestellt.

• Zustand (im Diagramm als Kreis dargestellt) : Dies ist der Zustand des Systems, in dem es auf ein oder mehrere Ereignisse wartet. Der Zustand merkt sich die bisher empfangenen Eingabedaten und gibt an, wie das System auf die empfangenen Ereignisse reagieren wird. Ereignisse können Aktionen auslösen und/oder zu einer Zustandsänderung führen.
• Übergang (im Diagramm als Pfeil dargestellt) : Dies stellt einen Übergang von einem Zustand in einen anderen dar, der aufgrund eines Ereignisses auftritt.
• Ereignis (dargestellt als Rechteck über dem Pfeil) : Ein Ereignis ist etwas, das dazu führt, dass die Anwendung ihren Status ändert. Ereignisse können von außerhalb der Anwendung kommen, beispielsweise über die Benutzeroberfläche der Anwendung. Gleichzeitig kann die Anwendung selbst Ereignisse generieren, beispielsweise ein Ereignis wie „Timer abgelaufen“. Wenn ein Ereignis auftritt, kann die Anwendung im gleichen Zustand bleiben, den Zustand ändern oder eine Aktion ausführen. Ereignisse können Parameter haben; Beispielsweise kann das Ereignis „pay_money“ Parameter wie „Cash“, „Check“, „DebitCard“ oder „CreditCard“ haben.
• Aktion (dargestellt nach „/“ in der Beschriftung über dem Übergang) : Dies ist eine Aktion, die durch eine Zustandsänderung initiiert wird. Dabei kann es sich um Aktionen wie „Ticket drucken“, „Auf dem Bildschirm anzeigen“ usw. handeln. Typischerweise erzeugen Aktionen Ausgaben, die als Ausgabedaten des Systems dienen. Aktionen finden während Übergängen statt; Staaten selbst sind passiv.
• Der Einstiegspunkt wird im Diagramm als schwarzer Punkt dargestellt.
• Der Austrittspunkt wird im Diagramm als „Bullseye“-Symbol dargestellt.

Zustandsübergangstabellen

Zustandsübergangstabellen sind Tabellen, die aus vier Spalten bestehen: Aktueller Zustand, Ereignis, Aktion und Nächster Zustand. Der Vorteil von Zustandsübergangstabellen besteht darin, dass sie alle möglichen Zustandsübergangsszenarien definieren, nicht nur die richtigen. Daher führen Zustandsübergangstabellen häufig zur Entdeckung undefinierter, undokumentierter Zustandsübergangskombinationen, die vor dem Schreiben des Codes besser identifiziert werden sollten.

• Zustandsübergangsdiagramme können einfach zum Erstellen von Testfällen verwendet werden. Es ist notwendig, eine Reihe von Testfällen zu erstellen, die alle Übergänge mindestens einmal abdecken sollten.
• Aus Zustandsübergangstabellen lassen sich auch relativ einfach Testfälle generieren. Man muss alle gültigen Kombinationen durchgehen (wenn es die Zeit erlaubt oder die Risiken es nicht verbieten, ist es möglich, auch alle ungültigen Kombinationen durchzugehen).

---

Orthogonale Arrays

Wie viele Kombinationen gibt es für das Wertepaar „1“ und „2“? {1,1}, {1,2}, {2,1} und {2,2}. Ein orthogonales Array ist ein zweidimensionales Array mit einer besonderen Eigenschaft: In zwei beliebigen Spalten des Arrays sind alle Wertekombinationen in diesen Spalten vorhanden. Das heißt, wenn Sie zwei beliebige Spalten aus dem orthogonalen Array nehmen, in denen die Werte nur „1“ oder „2“ sein können, finden Sie die folgenden Zeilen für diese Spalten: {1,1}, {1,2}, { 2,1} und {2,2}. Betrachten Sie als Beispiel ein System mit drei Eingabeparametern, von denen jeder binär ist (dh den Wert „1“ oder „2“ annimmt).

Reihen	Variable 1	Variable 2	Variable 3
1	1	1	1
2	2	1	1
3	1	2	1
4	1	1	2
5	2	2	1
6	1	2	2
7	2	1	2
8	2	2	2

Orthogonales Array wird dargestellt als - L_4(2^3), wobei L_4 angibt, dass das orthogonale Array vier Zeilen hat, und (2^3) angibt, dass das Array drei Spalten hat, mit Werten, die entweder „1“ oder „2“ sein können ".

Reihen	Variable 1	Variable 2	Variable 3
1	1	1	1
2	1	2	2
3	2	1	2
4	2	2	1

L_4, wobei 4 die Anzahl der Zeilen ist 2^3, wobei 2 der Maximalwert (== 2, 3, …, N) und 3 die Anzahl der Spalten ist

Orthogonales Array – ist ein zweidimensionales Array mit der folgenden Eigenschaft: Wählen Sie zwei beliebige Spalten des Arrays aus, und Sie finden alle Wertekombinationen in diesen Spalten. Verwendung orthogonaler Arrays:

1. Identifizieren Sie Variablen (Anzahl der Eingabedaten). Es ist notwendig, Eingabedaten auszuwählen, alle Kombinationen von Werten, die logisch existieren können.
2. Bestimmen Sie die Anzahl der Werte, die jede Variable annehmen kann. Bis zur Bestimmung der Anzahl der Werte sollten bereits andere Testdesigntechniken zur Reduzierung der Werteanzahl angewendet worden sein (z. B. Grenzwerte, Äquivalenzklassen usw.).
3. Bestimmen Sie ein orthogonales Array, in dem es für jede Variable eine Spalte gibt (die Spalte des orthogonalen Arrays hat so viele Wertoptionen wie die Variable).
4. Projizieren Sie die Testaufgabe auf das orthogonale Array.
5. Schreiben Sie Testfälle.

---

AllPairs-Algorithmus

Der Kern des AllPairs-Algorithmus besteht darin, dass nicht alle Wertekombinationen für alle Variablen getestet werden müssen. Stattdessen konzentriert es sich auf das Testen aller Wertekombinationen für jedes Variablenpaar.

---