Planung von Tests - Versionsgeschichte

Romana am 29. April 2017 um 10:26 Uhr

2017-04-29T10:26:20Z

Romana: /* Einleitung */

2017-04-28T07:57:09Z

‎Einleitung

Romana: /* Ein Beispiel hierzu: */

2017-04-28T07:51:08Z

‎Ein Beispiel hierzu:

Romana: /* Alle Testfälle erfassen */

2017-04-28T07:49:07Z

‎Alle Testfälle erfassen

Romana: /* Alle Testfälle erfassen */

2017-04-28T07:48:29Z

‎Alle Testfälle erfassen

Romana: /* Startpunkte der Tests bestimmen */

2017-04-28T07:43:25Z

‎Startpunkte der Tests bestimmen

Romana: /* Tests testen */

2017-04-20T07:04:37Z

‎Tests testen

Romana: /* Startpunkte der Tests bestimmen */

2017-04-20T06:42:05Z

‎Startpunkte der Tests bestimmen

Romana am 18. April 2017 um 17:04 Uhr

2017-04-18T17:04:36Z

Romana: Romana verschob die Seite BwPostman Wiki:Planung von Tests nach Planung von Tests, ohne dabei eine Weiterleitung anzulegen: sorry, falscher Titel

2017-04-18T17:04:05Z

Romana verschob die Seite BwPostman Wiki:Planung von Tests nach Planung von Tests, ohne dabei eine Weiterleitung anzulegen: sorry, falscher Titel

← Nächstältere Version		Version vom 29. April 2017, 10:26 Uhr
Zeile 89:		Zeile 89:
	Vielleicht ist das nur einfach einen Haken auf einer ToDo-Liste, vielleicht ist es ein Einpflegen in sein System für Continuous Delivery, ein Eintrag in Jenkins oder was auch immer. Jedenfalls ist das im Sinne von DevOps eine Auslieferung an den Kunden in diesem Fall ist der Kunde die Programmierung.		Vielleicht ist das nur einfach einen Haken auf einer ToDo-Liste, vielleicht ist es ein Einpflegen in sein System für Continuous Delivery, ein Eintrag in Jenkins oder was auch immer. Jedenfalls ist das im Sinne von DevOps eine Auslieferung an den Kunden in diesem Fall ist der Kunde die Programmierung.

−	[[Kategorie:Testing]]	+
		+
		+	[[Kategorie:Testing allgemein]]

@@ Zeile 9: / Zeile 9: @@
 * Nur ein Item pro Test. Das ist etwas Definitionssache und muss gegebenenfalls für den nächsten Punkt passend definiert werden.
 * DRY - Don't Repeat Yourself! Auch bei den Tests sollte natürlich im Hinblick auf die Wartbarkeit und Erweiterbarkeit der Tests mehrfach derselbe Code vermieden werden. Das lässt sich nicht immer machen, gerade bei Akzeptanz-Tests muss gelegentlich derselbe Test mit unterschiedlichen Parametern von außerhalb durchlaufen werden.
 ==Planung der Tests==

@@ Zeile 72: / Zeile 72: @@
 ====Ein Beispiel hierzu:====
-Ich habe für das Plugin Buyer2Subscriber einen Test, der erst mal dafür sorgt, dass ich einen sauberen Ausgangszustand habe (wenn die Tests am Stück laufen, dann kann es durchaus passieren, dass der vorausgegangene Test fehl schlägt und Leichen hinterlässt). Dann wird das Registrierungsformular im Frontend ausfüllt und abschickt, dann im Backend erst mal nach sieht, ob der Account an gelegt wurde, der Abonnent als unbestätigt eingetragen ist. Dann wird wieder ins Frontend gewechselt und der Account bestätigt. Jetzt muss ich natürlich wissen, ob der Account bestätigt und vor allem, ob das Abonnement bestätigt wurde, also der Abonnent nun bei den bestätigten gelistet ist. Anschließend wird noch aufgeräumt.
+Ich habe für das Plugin Buyer2Subscriber einen Test, der erst mal dafür sorgt, dass ich einen sauberen Ausgangszustand habe (wenn die Tests am Stück laufen, dann kann es durchaus passieren, dass der vorausgegangene Test fehl schlägt und Leichen hinterlässt). Dann wird das Registrierungsformular im Frontend ausfüllt und abschickt, dann im Backend erst mal nachgesehen, ob der Account angelegt wurde, der Abonnent als unbestätigt eingetragen ist. Dann wird wieder ins Frontend gewechselt und der Account bestätigt. Jetzt muss ich natürlich wissen, ob der Account bestätigt und vor allem, ob das Abonnement bestätigt wurde, also der Abonnent nun bei den bestätigten gelistet ist. Anschließend wird noch aufgeräumt.
 Ich hatte das in der ersten Version alles mit einer "Klick-Orgie" in Codeception gelöst. Damit läuft dieser Test 48 Sekunden.

@@ Zeile 39: / Zeile 39: @@
 Weiß man, von welcher Situation man ausgehen kann und was alles an Variationen möglich ist, kann man alle Testfälle erfassen. Sinnvollerweise gruppiert man die Tests erst mal so, dass immer nur ein Parameter verändert und alles andere beibehalten wird.
-Auf der Seite zu  sind die Testfälle für das Plugin Buyer2Subscriber für BwPostman erfasst, hoffentlich bereits vollständig. Dies ist die Sortierung 1.
+Auf der Seite zu [[Buyer2Subscriber Tests|Buyer2Susbcriber]] sind die Testfälle für das Plugin Buyer2Subscriber für BwPostman erfasst, hoffentlich bereits vollständig. Dies ist die Sortierung 1.
 ===Sortieren der Tests nach Items===

@@ Zeile 39: / Zeile 39: @@
 Weiß man, von welcher Situation man ausgehen kann und was alles an Variationen möglich ist, kann man alle Testfälle erfassen. Sinnvollerweise gruppiert man die Tests erst mal so, dass immer nur ein Parameter verändert und alles andere beibehalten wird.
-Auf der Hauptseite dieses Beitrags sind die Testfälle für das Plugin Buyer2Subscriber für BwPostman erfasst, hoffentlich bereits vollständig. Dies ist die Sortierung 1.
+Auf der Seite zu  sind die Testfälle für das Plugin Buyer2Subscriber für BwPostman erfasst, hoffentlich bereits vollständig. Dies ist die Sortierung 1.
 ===Sortieren der Tests nach Items===

@@ Zeile 20: / Zeile 20: @@
 Während die Tests laufen, werden diese Daten natürlich manipuliert. Folglich muss man dafür sorgen, dass für jeden einzelnen Test immer wieder dieselbe Ausgangssituation verfügbar ist. Das ist insbesondere wichtig, wenn ein vorausgegangener Test fehlschlägt (Unabhängigkeit der Tests).
-Zur Bestimmung, wie viele Startpunkte es für die Testreihen gibt, also wie viele Basis-Datenbestände man braucht, hilft es, zu überlegen, bei welchen Tests Ordner, Dateien oder Tabellen hinzu kommen. Die Wiederherstellung solcher Ausgangszustände ist aufwändiger, als wenn nur dafür gesorgt werden muss, dass die verwendeten Tabellen immer dieselben Ausgangsdaten haben.
+Zur Bestimmung, wie viele Startpunkte es für die Testreihen gibt, also wie viele Basis-Datenbestände man braucht, hilft es, zu überlegen, bei welchen Tests Ordner, Dateien oder Tabellen hinzu kommen oder weg fallen. Die Wiederherstellung solcher Ausgangszustände ist aufwändiger, als wenn nur dafür gesorgt werden muss, dass die verwendeten Tabellen immer dieselben Ausgangsdaten haben.
 Im Beispiel ist das ein Datenbestand, der den Abonnenten, der während der Tests verwendet wird, '''nicht''' bei den bereits vorhandenen Abonnenten ist. Außerdem wird dafür gesorgt, dass die Optionen von Komponente und der beiden Plugins immer einen definierten Ausgangszustand haben.

@@ Zeile 65: / Zeile 65: @@
 ===Tests testen===
 Ja, auch das gehört dazu! Wie will man behaupten, dass die Tests verlässlich sind, wenn man sie nicht getestet hat?
 ===Tests freigeben===

@@ Zeile 26: / Zeile 26: @@
 ====Warum mehrere Startpunkte?====
 Tests sollen so schnell wie möglich laufen, damit sie auch gerne verwendet werden!
 Da die meisten Tests zur Funktionalität nicht nur am Stück laufen sondern auch für Tests von Teilbereichen verwendet werden, macht es wenig Sinn, immer auch die Installation mit zu testen. Daher lege ich bei den Tests gerne mehrere Startpunkte an.

← Nächstältere Version		Version vom 18. April 2017, 17:04 Uhr
Zeile 66:		Zeile 66:
	===Tests freigeben===		===Tests freigeben===
	Vielleicht ist das nur einfach einen Haken auf einer ToDo-Liste, vielleicht ist es ein Einpflegen in sein System für Continuous Delivery, ein Eintrag in Jenkins oder was auch immer. Jedenfalls ist das im Sinne von DevOps eine Auslieferung an den Kunden in diesem Fall ist der Kunde die Programmierung.		Vielleicht ist das nur einfach einen Haken auf einer ToDo-Liste, vielleicht ist es ein Einpflegen in sein System für Continuous Delivery, ein Eintrag in Jenkins oder was auch immer. Jedenfalls ist das im Sinne von DevOps eine Auslieferung an den Kunden in diesem Fall ist der Kunde die Programmierung.
		+
		+	[[Kategorie:Testing]]

← Nächstältere Version	Version vom 18. April 2017, 17:04 Uhr
(kein Unterschied)