Diskussion:Buyer2Subscriber Tests - Versionsgeschichte

Romana: /* Gruppierung und Sortierung der Tests */

2017-04-19T09:13:55Z

‎Gruppierung und Sortierung der Tests

Romana: /* Schritt 6: Überprüfung der Ergebnisse */

2017-04-19T06:43:04Z

‎Schritt 6: Überprüfung der Ergebnisse

Romana: /* Eingabe- und Ergebnisdaten */

2017-04-19T06:41:16Z

‎Eingabe- und Ergebnisdaten

Romana: /* Folgerung 1 */

2017-04-19T06:38:40Z

‎Folgerung 1

Romana: /* Folgerung */

2017-04-19T06:38:21Z

‎Folgerung

Romana: /* Eingabe- und Ergebnisdaten */

2017-04-18T20:26:05Z

‎Eingabe- und Ergebnisdaten

Romana: /* Schritt 6: Überprüfung der Ergebnisse */

2017-04-18T20:21:07Z

‎Schritt 6: Überprüfung der Ergebnisse

Romana: /* Schritt 6: Überprüfung der Ergebnisse */

2017-04-18T20:18:58Z

‎Schritt 6: Überprüfung der Ergebnisse

Romana: /* Schritt 6: Überprüfung der Ergebnisse */

2017-04-18T20:14:35Z

‎Schritt 6: Überprüfung der Ergebnisse

Romana: /* Testdaten */

2017-04-18T20:04:45Z

‎Testdaten

@@ Zeile 14: / Zeile 14: @@
 # aufräumen
-Die Schritte 1-4 sind immer dieselben. Schritt 7 hat kleinere Modifikationen, denn es gibt Tests, da muss ich nur die Bestellung aufräumen und solche, wo auch der Abonnent archiviert und gelöscht werden muss.
+Die Schritte 1-4 sind immer dieselben, deshalb habe ich sie in einer Hilfsmethode zusammen gefasst. Schritt 7 hat kleinere Modifikationen, denn es gibt Tests, da muss ich nur die Bestellung aufräumen und solche, wo auch der Abonnent archiviert und gelöscht werden muss.
 Schritt 5 ist der Schritt, der die eigentlichen Funktionstests zu diesem Plugin aus macht. Davon hängt dann ab, was ich zu kontrollieren habe. Also sollte ich diese beiden Schritte noch genauer zerlegen.

@@ Zeile 53: / Zeile 53: @@
 ==<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Schritt 6: Überprüfung der Ergebnisse<br /></span>==
-<span class="mw-headline">Bei den Testfällen und beim Gerüst für die einzelnen Tests habe ich schon notiert, was für ein Ergebnis ich jeweils erwarte. Durch geschickte Bestückung des Arrays für die Ergebnisse und Setzen der Eigenschaften der Testklasse kann ich die Prüfung in einer einzigen Hilfsmethode durchführen. Da ich hier grundsätzlich zwei verschiedene Ergebnisbereiche abdecken muss, macht es allerdings wenig Sinn, wenn die Arrays geschickt bestückt sind. Da kann ich auch eine Ergebnisprüfung für '''kein Abonnement''' und eine für '''Abonnement''' anlegen. Die Prüfung für '''Abonnement''' kann sowohl die Tests für neues Abonnement als auch die Tests für bereits vorhandenes Abonnement abdecken. Die zu prüfenden Einzelwerte sind ja immer dieselben.<br /></span>
+<span class="mw-headline">Bei den Testfällen und beim Gerüst für die einzelnen Tests habe ich schon notiert, was für ein Ergebnis ich jeweils erwarte. Durch geschickte Bestückung des Arrays für die Ergebnisse und Setzen der Eigenschaften der Testklasse kann ich die Prüfung in einer einzigen Hilfsmethode durchführen. Da ich hier grundsätzlich nur zwei verschiedene Ergebnisbereiche abdecken muss, macht es allerdings wenig Sinn, wenn die Arrays geschickt bestückt sind. Da kann ich auch eine Ergebnisprüfung für '''kein Abonnement''' und eine für '''Abonnement''' anlegen. Die Prüfung für '''Abonnement''' kann sowohl die Tests für '''neues Abonnement''' als auch die Tests für bereits '''vorhandenes Abonnement''' abdecken. Die zu prüfenden Einzelwerte sind ja immer dieselben.<br /></span>
 <span class="mw-headline">Es ist noch zu überlegen, ob neues Abonnement und vorhandenes Abonnement möglicherweise getrennte Arrays bekommt, damit ich nicht zu viele gleiche Einzel-Arrays anlegen muss.</span>

@@ Zeile 47: / Zeile 47: @@
 <span class="mw-headline">Für die Tests, die auf kein Abonnement prüfen sollen, kann ich immer dieselben Daten nehmen. Da wäre einer der Datensätze möglich, die ich für ein neues Abonnement verwende, warum also nicht gleich der erste? Das spart mehrfach gleiche Daten.</span>
-<span class="mw-headline">Es ist zu überlegen, ob ich die variablen Daten nicht auch als Array in einem Array anlege. Aber das macht die ganze Sache ziemlich unübersichtlich…</span>
+===<span class="mw-headline">Folgerung 2<br /></span>===
 ==<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Schritt 6: Überprüfung der Ergebnisse<br /></span>==

@@ Zeile 38: / Zeile 38: @@
 Eine Hürde, die Tests weiter zusammen zu fassen, liegt darin, dass ich ja nicht auf einem Screen bleiben und mehrere Werte ausprobieren kann, denn um das Ergebnis bei den Abonnenten zu sehen, muss ich die Bestellung abschicken. Eine Ausnahme aber gibt es: Die Tests, die auf leere Eingaben bei Pflichtfeldern prüfen. Da komme ich mit der Bestellung, ja nicht mal mit dem Speichern der Adressdaten weiter, solange die Felder leer bleiben. Da dies aber nur beim zusätzlichen Feld der Fall ist und hier sowieso nur jeweils 6 Testfälle vorhanden sind, hat das keine Auswirkung.
-Folglich komme ich wohl nicht unter die 18 Tests.
+Folglich komme ich hier wohl nicht unter die 18 Tests.
 ===<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Eingabe- und Ergebnisdaten<br /></span>===

@@ Zeile 29: / Zeile 29: @@
 Es ist zu überlegen, ob die Änderung an allen Adressdaten und der Mailingliste gegenüber einem vorhandenen Abonnement ebenfalls in einem Test realisiert werden. Hier bin ich noch unsicher. Grundsätzlich spricht nichts dagegen, auch das in einem oder einigen wenigen Tests zusammenzufassen. Ob ein oder mehrere Tests hängt von der Anzahl der Varianten/Eingabemöglichkeiten ab.
-===Folgerung===
+===Folgerung 1===
 Ich habe 17 Testfälle identifiziert, die alle in die Kategorie '''Käufer hat noch kein Abo''' fallen. Die meisten Varianten liegen beim Format des Newsletters vor, es sind derer 6. Also kann ich mit maximal 6 Tests alle 17 Testfälle abdecken, ohne etwas aus zu lassen.<br /><br />Des weiteren habe ich 32 Testfälle identifiziert, die in die Kategorie '''Käufer hat bereits ein Abo''' fallen. Die meisten Varianten liegen hier bei der Auswahl des Geschlechts vor, denn es gibt ja drei Möglichkeiten. Also drei Angaben für das vorhandene Abonnement kombiniert mit drei möglichen Eingaben, dazu noch die Möglichkeit, dass der Wert gar nicht (neu) erfasst werden soll. Ergibt maximal 12 Kombinationen. Also müsste ich auch mit maximal 12 Tests auskommen, wenn ich als gegeben ansehe, dass sich die Parameter nicht gegenseitig beeinflussen.

@@ Zeile 41: / Zeile 41: @@
 ===<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Eingabe- und Ergebnisdaten<br /></span>===
-<span class="mw-headline">Die Eingabedaten kann ich in einem indizierten (Schlüssel ist eine Nummer) Array zusammenfassen, das ein assoziatives (Schüssel ist ein Name/String) Array pro Testfall enthält. Damit kann ich die gleiche Datenstruktur auch für die Erwarteten Ergebnisse verwenden.</span>
+<span class="mw-headline">Die Eingabedaten kann ich in einem indizierten (Schlüssel ist eine Nummer) Array zusammenfassen, das ein assoziatives (Schüssel ist ein Name/String) Array pro Testfall enthält. Damit kann ich die gleiche Datenstruktur auch für die erwarteten Ergebnisse verwenden.</span>
 <span class="mw-headline">Sicherer wäre es allerdings, wenn ich den Testfällen Namen und damit aus den Nummern des äußeren Arrays ebenfalls Strings machen könnte. Dann wäre es auch möglich, die Eingabedaten und die Ergebnisdaten in einer anderen Reihenfolge vor zu halten. Die Herausforderung hier besteht darin, dass sprechende Namen gefunden werden müssen, die allerdings nicht zu lang sein sollten.<br /></span>
 ==<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Schritt 6: Überprüfung der Ergebnisse<br /></span>==

@@ Zeile 46: / Zeile 46: @@
 ==<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Schritt 6: Überprüfung der Ergebnisse<br /></span>==
-<span class="mw-headline">Bei den Testfällen und beim Gerüst für die einzelnen Tests habe ich schon notiert, was für ein Ergebnis ich jeweils erwarte. Durch geschickte Bestückung des Arrays für die Ergebnisse und Setzen der Eigenschaften der Testklasse kann ich die Prüfung in einer einzigen Hilfsmethode durchführen</span>
+<span class="mw-headline">Bei den Testfällen und beim Gerüst für die einzelnen Tests habe ich schon notiert, was für ein Ergebnis ich jeweils erwarte. Durch geschickte Bestückung des Arrays für die Ergebnisse und Setzen der Eigenschaften der Testklasse kann ich die Prüfung in einer einzigen Hilfsmethode durchführen. Da ich hier grundsätzlich zwei verschiedene Ergebnisbereiche abdecken muss, macht es allerdings wenig Sinn, wenn die Arrays geschickt bestückt sind. Da kann ich auch eine Ergebnisprüfung für '''kein Abonnement''' und eine für '''Abonnement''' anlegen. Die Prüfung für '''Abonnement''' kann sowohl die Tests für neues Abonnement als auch die Tests für bereits vorhandenes Abonnement abdecken. Die zu prüfenden Einzelwerte sind ja immer dieselben.<br /></span>
 ===<span class="mw-headline">Eigenschaften der Testklasse</span>===

← Nächstältere Version		Version vom 18. April 2017, 20:14 Uhr
Zeile 46:		Zeile 46:

	==<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Schritt 6: Überprüfung der Ergebnisse<br /></span>==		==<span id="Schritt_5:_Eingaben_je_nach_Testfall" class="mw-headline">Schritt 6: Überprüfung der Ergebnisse<br /></span>==
		+	<span class="mw-headline">Bei den Testfällen und beim Gerüst für die einzelnen Tests habe ich schon notiert, was für ein Ergebnis ich jeweils erwarte. Durch geschickte Bestückung des Arrays für die Ergebnisse und Setzen der Eigenschaften der Testklasse kann ich die Prüfung in einer einzigen Hilfsmethode durchführen</span>
		+
		+	===<span class="mw-headline">Eigenschaften der Testklasse</span>===
		+	<span class="mw-headline">Die Eigenschaften der Testklasse werden vornehmlich dazu verwendet, die Anzahl der Übergabe-Parameter an die Hilfsmethoden so gering wie möglich zu halten. So könnte ich auch die Prüfung der Ergebnisse für die Tests, die kein Abonnement bewirken, in die Methode zur Überprüfung der Ergebnisse integrieren. Oder ich lege eine generelle Methode Überprüfung der Testergebnisse an, wo ich dann anhand der entsprechenden Eigenschaft auf eine weitere Hilfsmethode weiterleite. Schalter an, Methode 1, Schalter aus Methode 2. Viel Sinn macht es nicht, denn es erhöht die Lesbarkeit des Codes nicht wirklich.</span>
		+
		+	<span class="mw-headline">In anderen Fällen macht es durchaus Sinn, Eigenschaften der Testklasse statt Parameter als Transporteur zu verwenden.</span>