Get best of the week

Sagen Sie einfach Nein zu End-2-End-Tests

Sie hatten dies wahrscheinlich, als Sie und Ihre Freunde wirklich einen Film sehen wollten, und bedauerten dann, dass Sie Zeit damit verbracht haben. Oder vielleicht erinnern Sie sich an den Moment, als Ihr Team dachte, es hätte ein „Killer-Feature“ gefunden und seine „Fallstricke“ erst nach der Veröffentlichung des Produkts gefunden.

Gute Ideen scheitern oft in der Praxis, und in der Testwelt ist eine Teststrategie, die auf einer durchgängigen Testautomatisierung basiert, ein gutes Beispiel dafür.

Tester können ihre Zeit damit verbringen, viele Arten von automatisierten Tests zu schreiben, einschließlich Komponententests, Integrationstests und End-2-End-Tests. Diese Strategie zielt jedoch hauptsächlich auf End-2-End-Tests ab, mit denen das Produkt oder die Dienstleistung als Ganzes getestet wird. In der Regel ahmen diese Tests reale Benutzerszenarien nach.

Quelle

End-2-End-Tests in der Theorie


Obwohl es eine schlechte Idee ist, sich hauptsächlich auf End-2-End-Tests zu verlassen, können Sie theoretisch mehrere Argumente für diese Aussage vorbringen. 

Die Nummer eins auf der Google-Liste von zehn Dingen , die bekanntlich wahr sind: "Vor allem die Interessen der Nutzer." Die Verwendung von End-2-End-Tests, die sich auf reale Benutzerszenarien konzentrieren, scheint daher eine gute Idee zu sein. Darüber hinaus ist diese Strategie für viele Teilnehmer des Prozesses im Allgemeinen attraktiv.

  • Entwickler mögen diese Strategie, weil Sie die meisten Tests, wenn nicht alle, auf andere übertragen können.
  • , , , , , , .
  • ,   , ; .

End-2-end


Wenn diese Teststrategie theoretisch so gut aussieht, was ist dann in der Praxis daran falsch? Um dies zu demonstrieren, werde ich im Folgenden ein fiktives Szenario geben, das jedoch auf realen Situationen basiert, die mir und anderen Testern vertraut sind. 

Angenommen, ein Team erstellt einen Dienst zum Online-Bearbeiten von Dokumenten (z. B. Google Text & Tabellen). Nehmen wir an, das Team verfügt bereits über eine fantastische Infrastruktur zum Testen. Jede Nacht:

  • Erstellt die neueste Version des Dienstes.
  • Dann wird diese Version in der Team-Testumgebung bereitgestellt.
  • In dieser Testumgebung werden dann alle End-to-End-Tests ausgeführt.
  • Das Team erhält einen E-Mail-Bericht mit einer Zusammenfassung der Testergebnisse.

Die Frist nähert sich schnell. Nehmen wir an, dass mindestens 90% der erfolgreichen End-2-End-Tests erforderlich sind, um ein hohes Maß an Produktqualität aufrechtzuerhalten, sodass wir davon ausgehen, dass die Version fertig ist. Nehmen wir an, die Frist endet an einem Tag.


Trotz zahlreicher Probleme ergaben die Tests schließlich echte Fehler.

Was gut

gelaufen ist Fehler, die den Benutzer betreffen, wurden identifiziert und korrigiert, bevor sie ihn erreichten.

Etwas ist schief gelaufen

  • Das Team beendete seine Programmierphase eine Woche später (und machte viele Überstunden).
  • Das Auffinden der Grundursache für den fehlgeschlagenen End-2-End-Test ist zeitaufwändig und kann viel Zeit in Anspruch nehmen.
  • Ausfälle des Parallelteams und Fehlfunktionen in der Ausrüstung haben die Testergebnisse um mehrere Tage verschoben.
  • Viele kleine Fehler waren hinter großen Fehlern verborgen.
  • End-2-End-Testergebnisse waren zeitweise unzuverlässig.
  • Die Entwickler mussten bis zum nächsten Tag warten, um herauszufinden, ob das Update funktioniert oder nicht.

Nachdem wir nun wissen, was in der End-2-End-Strategie schief gelaufen ist, müssen wir unseren Testansatz ändern, um viele der oben genannten Probleme zu vermeiden. Aber was ist der richtige Ansatz?

Der wahre Wert von Tests


In der Regel endet die Arbeit des Testers, wenn der Test fehlschlägt. Der Fehler wird protokolliert. Anschließend muss der Entwickler den Fehler beheben. Um jedoch festzustellen, wo die End-2-End-Strategie nicht funktioniert, müssen wir über dieses Denken hinausgehen und das Problem anhand unserer Grundprinzipien angehen. Wenn wir uns auf den Benutzer konzentrieren (und alles andere folgt), müssen wir uns fragen: Kommt der fehlgeschlagene Test dem Benutzer zugute? 

Hier ist die Antwort: "Ein fehlgeschlagener Test kommt dem Benutzer nicht direkt zugute."

Obwohl diese Aussage auf den ersten Blick schockierend erscheint, ist sie wahr. Wenn das Produkt funktioniert, funktioniert es, unabhängig davon, ob der Test angibt, dass es funktioniert oder nicht. Wenn ein Produkt defekt ist, ist es defekt, unabhängig davon, ob der Test angibt, dass es defekt ist oder nicht. Wenn fehlgeschlagene Tests dem Benutzer nicht zugute kommen, was kommt ihm dann zugute?

Fehlerkorrekturen kommen dem Benutzer direkt zugute.

Der Benutzer wird nur glücklich sein, wenn dieses unvorhersehbare Verhalten (Fehler) verschwindet. Um einen Fehler zu korrigieren, müssen Sie natürlich wissen, dass er existiert. Um herauszufinden, dass ein Fehler vorliegt, sollten Sie idealerweise einen Test haben, der ihn erkennt (denn wenn der Test den Fehler nicht erkennt, wird er vom Benutzer gefunden). Während dieses Prozesses, vom Fehlschlagen des Tests bis zur Korrektur des Fehlers, erscheint der Mehrwert jedoch im allerletzten Schritt.


Um eine Teststrategie zu bewerten, können Sie nicht einfach bewerten, wie Fehler gefunden werden. Sie sollten auch bewerten, wie Entwickler sie dadurch korrigieren (und sogar verhindern) können.

Das richtige Feedback aufbauen


Tests erzeugen eine Rückkopplungsschleife, die den Entwickler darüber informiert, ob das Produkt funktioniert oder nicht. Eine ideale Rückkopplungsschleife hat mehrere Eigenschaften.

  • . , , . ( ), . . , .
  • . , , , . , , .
  • Es sollte Ihnen ermöglichen, Fehler schnell zu finden. Um den Fehler zu beheben, müssen Entwickler die spezifischen Codezeilen finden, die den Fehler verursachen. Wenn ein Produkt Millionen von Codezeilen enthält und der Fehler überall auftreten kann, ist es wie der Versuch, eine Nadel im Heuhaufen zu finden.

Denken Sie klein, nicht groß


Wie erstellen wir diese perfekte Rückkopplungsschleife? Ich denke an das Kleine, nicht an das Größere.

Unit-Tests

Unit-Tests nehmen ein kleines Stück des Produkts und testen es isoliert von allem anderen. Sie erzeugen fast dieselbe perfekte Rückkopplungsschleife:

  • Unit-Tests sind schnell. Wir müssen einen kleinen Codeblock schreiben und können ihn bereits testen. Unit-Tests sind normalerweise recht klein. Tatsächlich ist eine Zehntelsekunde für Unit-Tests zu lang.
  • . , , . , — , , — .
  • . , , , , .

Das Schreiben effektiver Komponententests erfordert Kenntnisse in Bereichen wie Abhängigkeitsmanagement, Schreiben von Stubs / Mocks und strengen Tests. Ich werde diese Fähigkeiten hier nicht beschreiben, aber zunächst ist das typische Beispiel für den neuen Googler (oder wie sie in Google als Noogler bezeichnet werden), wie Google die Stoppuhr erstellt und testet .

Komponententests gegen End-2-End-Tests

Bei End-2-End-Tests müssen Sie warten: Zuerst müssen Sie das gesamte Produkt erstellen, dann bereitstellen und schließlich alle End-2-End-Tests abschließen. Wenn die Tests noch funktionieren, schlagen sie höchstwahrscheinlich regelmäßig fehl. Und selbst wenn der Test einen Fehler feststellt, kann er sich an einer beliebigen Stelle im Produkt befinden.

Obwohl End-to-End-Tests die Modellierung realer Benutzerszenarien besser können, wird dieser Vorteil schnell durch alle Mängel der End-to-End-Rückkopplungsschleife aufgewogen:


Integrationstests

Unit-Tests haben einen großen Nachteil: Selbst wenn die Module separat gut funktionieren, wissen Sie nicht, ob sie gut zusammenarbeiten. Aber selbst dann müssen Sie keine End-2-End-Tests durchführen. Hierfür können Sie den Integrationstest verwenden. Der Integrationstest besteht aus einer kleinen Gruppe von Modulen, häufig zwei, und testet deren Verhalten als Ganzes.

Wenn sich die beiden Blöcke nicht richtig integrieren lassen, warum dann einen End-to-End-Test schreiben, wenn Sie einen viel kleineren, fokussierteren Integrationstest schreiben können, der denselben Fehler erkennt? Natürlich müssen Sie beim Testen den gesamten Kontext verstehen, aber um die Arbeit von zwei Modulen zusammen zu testen, müssen Sie nur die Perspektive ein wenig erweitern.

Testpyramide


Selbst bei Unit- und Integrationstests benötigen Sie wahrscheinlich eine kleine Anzahl von End-2-End-Tests, um das gesamte System zu testen. Um das richtige Gleichgewicht zwischen allen drei Testarten zu finden, verwenden Sie am besten eine visuelle Testpyramide. Hier ist eine vereinfachte Version der Testpyramide aus der Eröffnungsrede der Google Test Automation- Konferenz 2014 .


Der Großteil Ihrer Tests sind Unit-Tests am unteren Rand der Pyramide. Wenn Sie die Pyramide nach oben bewegen, werden Ihre Tests umfassender, aber gleichzeitig nimmt die Anzahl der Tests (die Breite Ihrer Pyramide) ab.

In guter Weise bietet Google eine Trennung von 70/20/10 an: 70% Unit-Tests, 20% Integrationstests und 10% End-2-End-Tests. Das genaue Verhältnis ist für jedes Team unterschiedlich, sollte jedoch im Allgemeinen die Form der Pyramide beibehalten. Vermeiden Sie die folgenden „Formulare“:

  • Umgekehrte Pyramide / Eistüte. Das Team stützt sich hauptsächlich auf End-to-End-Tests mit mehreren Integrationstests und sehr wenigen Komponententests.
  • Sanduhr. Das Team beginnt mit einer großen Anzahl von Komponententests und verwendet dann End-to-End-Tests, bei denen Integrationstests verwendet werden sollten. Die Sanduhr hat viele Unit-Tests unten und viele End-to-End-Tests oben, aber nur wenige Integrationstests in der Mitte.

So wie eine gewöhnliche Pyramide im wirklichen Leben die stabilste Struktur ist, ist auch eine Testpyramide die stabilste Teststrategie.

Arbeitsplätze


Wenn Sie es lieben und wissen, wie man Unit-Tests schreibt, sind Sie herzlich willkommen! Die Firma LANIT hat eine Stelle für den Java-Entwickler im DevOps-Team eröffnet, in der Sie Gleichgesinnte finden.

More articles:


All Articles