it-swarm.com.de

Wann haben Sie genug automatische Tests, um sich auf Ihre kontinuierliche Integrationspipeline verlassen zu können?

Die kontinuierliche Integration in das Testen ist hilfreich, um sicherzustellen, dass ständig "versandfähiger" Code eingecheckt ist.

Es ist jedoch wirklich schwierig, eine umfassende Reihe von Tests aufrechtzuerhalten, und oft scheint es, dass der Build sowieso fehlerhaft sein wird.

Wie viele Tests sollten Sie benötigen, um sich bei Ihren CI-Pipeline-Tests sicher zu fühlen? Verwenden Sie eine Art Metrik, um zu entscheiden, wann genügend Tests vorhanden sind?

10
stonefruit

Allgemein

Wann haben Sie genug automatische Tests, um sich auf Ihre kontinuierliche Integrationspipeline verlassen zu können?

Die Antwort wird wahrscheinlich klar, wenn Sie darüber nachdenken, worüber Sie sicher sein möchten. Letztendlich bildet es 1-1 ab; Jeder Test macht Sie zuversichtlich, was er testet:

  • Unit-Tests geben Ihnen die Gewissheit, dass eine Klasse (oder ein Modul) das tut, wofür sie getestet wurde.
  • Integrationstests geben Ihnen die Gewissheit, dass mehrere Einheiten auf die Art und Weise zusammenarbeiten, auf die getestet wurde.
  • End-to-End-Tests geben Ihnen die Gewissheit, dass die gesamte Anwendung eine bestimmte Funktion ausführt, wie sie im Test beschrieben wird.

Nach der Art und Weise, wie Sie Ihre Frage formuliert haben, denken Sie wahrscheinlich gerade im geschäftlichen Sinne, zum Beispiel:

Ich möchte sicher sein, dass meine App X kann.

Sie schreiben also einen End-to-End-Test, der versucht, X auszuführen, und prüft, ob dies korrekt ausgeführt wird.

Konkreter

Das ist alles sehr selbstreferenziell, aber das liegt daran, dass es darauf ankommt. Es gibt einfach ist nicht mehr dazu.

Stellen Sie sich zum Beispiel vor, Sie schreiben eine App, um Kochrezepte zu erstellen. Ein Merkmal ist, dass Sie, wenn Sie verschiedene Mengen verschiedener Käsesorten hinzufügen, die richtige Temperatur und Zeit erhalten, damit alle schmelzen.

Sie können also einen Komponententest für Ihr CheeseMeltCalculator schreiben, bei dem Sie ihm 100 g Gouda und 200 g Emmentaler geben, und dann überprüfen, ob Temperatur und Zeit richtig sind. Das heißt, Sie können jetzt sicher sein, dass CheeseMeltCalculator für 100 g Gouda und 200 g Käse funktioniert. Wenn Sie diesen Test nun mit 300 g Gouda anstelle von 200 g wiederholen, können Sie ziemlich sicher sein, dass er für verschiedene Werte korrekt funktioniert. Sie können Tests für 0, -1 und int.MaxValue g von Gouda, um sicher zu sein, dass der Code für seltsame Eingaben nicht ausgelöst wird (oder wie beabsichtigt korrekt ausgelöst wird).

Sie können einen Integrationstest schreiben, um zu überprüfen, ob CheeseMeltCalculator korrekt in den gesamten Prozess zur Berechnung der Temperatur und Zeit des Lebensmittels integriert ist. Wenn dies schief geht, aber die obigen CheeseMeltCalculator -Tests in Ordnung sind, können Sie sicher sein, dass der Fehler in anderen Taschenrechnern oder in der Art und Weise liegt, wie die Daten von verschiedenen Taschenrechnern kombiniert werden.

Und schließlich können Sie einen End-to-End-Test zum Erstellen eines vollständigen Rezepts schreiben. Eines der Dinge, auf die Sie prüfen, ist die Ergebnistemperatur und -zeit. Wenn die vorherigen 2 Teststufen in Ordnung sind, dies jedoch schief geht, können Sie erneut sicher sein, dass diese Teile korrekt sind und der Fehler darin besteht, wie die Temperaturberechnung in die Anwendung integriert wird. Beispielsweise wird die Benutzereingabe möglicherweise nicht korrekt übertragen.

Und endlich Wenn alle diese Tests in Ordnung sind, können Sie sicher sein, dass " wenn Sie verschiedene Mengen verschiedener Käsesorten hinzufügen, erhalten Sie die richtige Temperatur und Zeit, damit sie alle schmelzen "

Um es kurz zu machen

Der Punkt ist, dass Sie keinen Test haben können "es funktioniert richtig". Sie können nur "Wenn ich X mache, passiert Y" testen.

Dies ist jedoch genau das, was in den technischen Spezifikationen für das Projekt enthalten sein sollte. Eine Aussage wie " Wenn Sie verschiedene Mengen verschiedener Käsesorten hinzufügen, erhalten Sie die richtige Temperatur und Zeit, damit alle schmelzen" gibt dem Kunden nicht nur klare Erwartungen an das, was fertig ist Produkt reicht aus, kann aber auch in automatisierte Tests umgewandelt werden.

Zusätzliche Information

Benutzer Richard hat diese Informationen in einer Bearbeitung hinzugefügt:

Martin Fowler hat auf seiner Website eine sehr schöne Zusammenfassung der gängigsten Strategien: https://martinfowler.com/articles/microservice-testing/

Ich möchte dies nicht entfernen, aber ich möchte Folgendes sagen: Im Vergleich zu dieser Antwort handelt es sich nicht um eine "Zusammenfassung", sondern um eine viel ausführlichere Erklärung mit schönen Grafiken und allem.

Mein Rat wäre: Wenn nach dem Lesen meiner Antwort alles für Sie Sinn macht, sind Sie fertig. Wenn die Dinge immer noch unklar erscheinen, nehmen Sie sich etwas Zeit und lesen Sie den verlinkten Artikel durch.

16
R. Schmitz

Es gibt keine Metrik, die Sie berechnen können und die Ihnen das Vertrauen gibt, das Sie suchen. Vertrauen entsteht, indem man etwas tut und es dann schafft oder scheitert und etwas daraus lernt.

Die einzigen "Metriken", die ich gefunden habe und die mir Vertrauen in unsere Testabdeckung geben, sind:

  1. Anzahl der in der Produktion gefundenen Mängel
  2. Können Sie die Codebasis umgestalten und sich auf Ihre Testabdeckung verlassen, um Regressionsfehler zu erkennen?

Automatisierte Tests sind keine Wunderwaffe. Sie müssen nachverfolgen, wie viele Produktionsfehler in jedem Release-Zyklus gefunden werden. Wenn diese Zahl sinkt, liefern Sie bessere Software. Automatisierte Tests und kontinuierliche Integration sind nur Tools, mit denen Sie bessere Software liefern.

Die einzige Metrik, die Sie wirklich messen können, ist "Liefern Sie bessere Software?"

Und selbst dann ist es subjektiv.

4
Greg Burghardt

Wann haben Sie genug automatische Tests, um sich auf Ihre kontinuierliche Integrationspipeline verlassen zu können?

In den meisten wirtschaftlichen Umgebungen verfügen Sie nicht über das Budget, um genügend Vertrauen zu schaffen (> 99%), aber Sie müssen ein begrenztes Budget verwalten: Es geht nur um das Kosten-Nutzen-Verhältnis.

  • Einige automatisierte Tests sind billig zu implementieren, andere sind äußerst kostspielig.
  • Abhängig von Ihrem tatsächlichen Risikomanagement müssen einige Risiken durch Tests abgedeckt werden, andere nicht.

In der Realität werden also die einfachen/billigen/riskanten Tests implementiert, während die teuren/unwahrscheinlichen Tests dies nicht tun.

Ein Unterziel der Softwareentwicklung besteht darin, eine Architektur zu erstellen, die einfach/kostengünstig zu testen ist (Design für Testbarkeit durch Anwendung von Testgetriebene Entwicklung ), um automatisierte Tests erschwinglich zu halten.

Ich gehe davon aus, dass das Pareto_principle auch hier für wartbare/testbare Software angewendet werden kann: Wenn Sie 20% mehr Geld ausgeben, erhalten Sie 80% zusätzlichen Nutzen. Um die verbleibenden 20% mehr Nutzen zu erzielen, müssen Sie zusätzliche 80% Geld ausgeben.

Sie können Testmetriken wie Codeabdeckung und Mutationsabdeckung anwenden, um Ihnen potenziellen ungetesteten Quellcode anzuzeigen.

Aber selbst bei 100% Deckung können Sie nicht sicher sein, dass Ihr Code frei von Fehlern ist.

Management mag Codemetrie. Wenn "Codeabdeckung> = 80%" vom Management erzwungen wird, während die Entwickler automatisierte Tests nicht unterstützen/mögen, gibt es Möglichkeiten, Testcode mit hoher Abdeckung zu schreiben, der nichts beweist, was ein falsches Sicherheitsgefühl vermittelt.

2
k3b

Der Trick dabei ist nicht, sich um die vollständige Abdeckung zu sorgen, sondern das Risiko Ihrer Änderungen zu steuern.

Angenommen, Sie verwenden Ihre Pipeline, um genau dieselbe Version bereitzustellen, die bereits in der Produktion vorhanden ist. Wie hoch ist das Risiko von Regressionsfehlern? Null (weil es keine Änderung gibt).

Angenommen, ich möchte einen Text auf einem der Bildschirme ändern. Ich habe den Test hinzugefügt, um zu überprüfen, ob der Text jetzt korrekt angezeigt wird (nehmen wir aus Gründen der Argumentation an, dass es sich um einen WIRKLICH wichtigen Text handelt). Welche anderen Tests muss ich durchführen, um sicherzustellen, dass keine Regressionsfehler vorliegen? Realistisch keine ...

Die Anzahl der automatisierten Tests, die für jede Version erforderlich sind, hängt also nicht von der Größe Ihrer Anwendung ab, sondern von der Größe Ihrer Änderung. Wenn Sie kleine Änderungen mit geringem Risiko vornehmen, benötigen Sie viel weniger Tests, um die Risiken zu minimieren.

Aber Moment mal ... passt das nicht sehr gut zu CI und CD?

Ja! Indem Sie alle Ihre Änderungen und Deltas sehr klein halten, verringern Sie viele der Regressionsrisiken durch Prozesse und nicht durch Tests. Darüber hinaus geht es bei der Frage nicht um Automatisierung (das ist nur das Werkzeug, das wir verwenden werden), sondern lediglich um Tests und Risikoappetit. Vergessen Sie die Automatisierung vollständig. Welche Tests würden Sie gegen eine Änderung durchführen, um sicherzustellen, dass durch eine Änderung keine Probleme aufgetreten sind? Die Antwort auf diese Frage ändert sich nicht von einem manuellen Testprozess zu einem CI-System. Der einzige Vorteil besteht darin, dass viele dieser Regressionstests möglicherweise bereits in früheren Funktionen entwickelt wurden und CI Sie dazu ermutigt, kleinere, sicherere Änderungen vorzunehmen.

TLDR

Ihre Tests sollen das Risiko der Änderung verringern. Ein Einsatz mit einem Delta von Null birgt kein Risiko und birgt daher kein Risiko. Indem Sie Ihre Änderungen klein halten, können Sie die zur Validierung erforderlichen Tests viel einfacher identifizieren. Die Wiederverwendbarkeit der Automatisierung ist ein Bonus.

1
Liath

Dies ist dieselbe Metrik wie beim manuellen Testen Ihres Produkts.

In der Praxis ist es einfach, diese Zonen mit geringem Vertrauen zu identifizieren: Unter der Annahme, dass Sie das Produkt versenden, haben Sie vermutlich einige manuelle Schritte nach der Pipeline, die Ihr Vertrauen in den Versand verbessern. Dies sind die Bereiche, die Sie automatisieren sollten, um das Vertrauen in den automatischen Prozess selbst zu verbessern.

Ihre Automatisierung ist eine ständige Anstrengung. Es wächst und verbessert sich, wenn sich Ihr Produkt verbessert. Ein Defekt ist ein Grund, Ihren Code zu überdenken und das CI neu zu verknüpfen. Und die Sonnenseite hier ist, dass das Vertrauen in das Produkt selbst erreichbar ist - das Vertrauen in die Automatisierung ist auch erreichbar.

0
ittays