Blog
Eine einfache, effektive Strategie zur Testautomatisierung
DevOps-Teams automatisieren alles. Wenn Sie mit der Testautomatisierung beginnen, ist es wichtig, sich zu fragen, warum jemand Tests automatisieren möchte. Und was ist Testen überhaupt? Dieser Artikel beschreibt, was Testen ist und welche Teile dieses Prozesses automatisiert werden können. Glücklicherweise wird die Testautomatisierung das manuelle Testen auf keinen Fall überflüssig machen, sondern diesen Prozess lediglich effizienter gestalten.
Hier ist der Grund dafür:
Es ist nicht die Idee des Kunden, die in die Produktion geht, es ist die Annahme des Entwicklers.
Kommunikation beginnt mit einer Idee. Das Gehirn wandelt diese Idee in Worte um, und der Mund überträgt diese Worte durch die Luft. Das Ohr des Zuhörers empfängt sie, und das Gehirn interpretiert die Worte und versucht, dasselbe Bild zu erzeugen, das der Sender hatte. Es überrascht jedoch nicht, dass bei diesem Prozess der wichtigste Teil der ursprünglichen Nachricht verloren geht.
Da der größte Teil der anfänglichen Botschaft in der Übersetzung verloren geht, besteht ein großer Teil des Testens in der Kommunikation; im Gespräch mit dem Kunden und dem Entwickler. Gibt es fehlinterpretierte, übersehene oder fehlende Anforderungen? Beim Testen geht es darum, den Unterschied zwischen der ursprünglichen Idee des Kunden und der Interpretation durch den Entwickler zu finden.
Sie können das Testen nicht automatisieren
Verwechseln Sie nicht Testen mit Prüfen. Überprüfungen können automatisiert werden, Tests nicht. Wenn Sie
Wenn sich die Software ändert (neue Funktionen werden implementiert, der Code wird überarbeitet usw.), möchten Sie im Allgemeinen sicherstellen, dass sich das bestehende Verhalten des Systems nicht geändert hat. Zu diesem Zweck müssen Sie die Funktionen der Software validieren, indem Sie bestimmte (Kombinationen von) Parametern durch das System laufen lassen. Legen Sie das korrekte Ergebnis im Voraus fest, damit es einfach validiert werden kann. Dieser Prozess wird auch als Prüfung bezeichnet, die automatisiert werden kann .
Automatisieren Sie Prüfungen, um effizienter zu testen
In einer Welt der kontinuierlichen Auslieferung wird Software ständig ausgeliefert. Das bedeutet, dass jemand die bekannten Funktionen überprüfen und die neuen Funktionen gründlich testen muss. Die Automatisierung der wiederkehrenden Arbeiten führt zu weniger Fehlern und zu mehr Zeit, um manuelle Sondierungstests richtig durchzuführen.
Normalerweise wird ungetestete Software nicht ausgeliefert. Je kürzer es dauert, die Software zu validieren, desto schneller und häufiger kann das Produkt ausgeliefert werden. Legen Sie den gewünschten Zustand des Systems in einer Reihe von schnellen, automatisierten Prüfungen fest, die jederzeit ausgeführt werden können, so dass Sie das System jederzeit testen und ausliefern können, wenn Sie wollen.
Täuschen Sie sich nicht. Die automatische Überprüfung der vorhandenen Funktionen zeigt, dass das System immer noch das tut, was es tun soll. Nicht weniger. Was aber, wenn sich herausstellt, dass das System mehr tut, als angegeben wurde? Ist das gut oder schlecht? Testen Sie die vorhandenen Funktionen gelegentlich, um Fehler zu finden, und fügen Sie automatisierte Prüfungen hinzu.
Implementieren Sie die Testpyramide von Martin Fowler
Wenden Sie verschiedene Arten von Tests für das jeweilige Problem an. Testen Sie nicht alles als Einheit. Stellen Sie sicher, dass die resultierende Testsuite schnell ausgeführt werden kann und den Ort des Problems im Code lokalisiert, damit Probleme schnell gefunden und behoben werden können. Verwenden Sie so viele der billigsten und schnellsten automatisierten Tests wie möglich und langsame, teure Tests mit Bedacht.
die Testpyramide
Stellen Sie sich Ihre Testsuite wie eine Pyramide vor, deren Basis aus vielen Unit-Tests besteht. Sie sind billig und schnell, und Sie brauchen viele von ihnen. Die Entwickler sind Eigentümer dieser Tests und sollten testgetriebene Entwicklung einsetzen, um eine so große Menge an Tests zu produzieren. Die Mitte der Pyramide sollte eine beträchtliche Anzahl von Tests enthalten, mit denen überprüft wird, ob die einzelnen Einheiten zusammen den erwarteten geschäftlichen Nutzen erbringen. Verwenden Sie für diese Schicht die verhaltensorientierte Entwicklung.
Die Komponenten-/Integrationsschicht testet den funktionalen Aspekt der Anwendung, und die Unit-Tests testen die Randfälle der Anwendung. Die oberste Schicht ist die langsamste. Verwenden Sie diese Schicht, um die bereitgestellte Anwendung zu testen - stellen Sie sicher, dass die Komponenten gerendert werden und die Anwendung starten kann. Verwenden Sie nur eine Handvoll dieser Tests, da sie langsam und kostspielig sind.
Sie können diese Strategie nicht auf jede beliebige Codebasis anwenden; sie erfordert SOLID-Prinzipien.
Beschleunigen Sie den Kodierungsprozess durch testgetriebene Entwicklung
Wenn Sie mit der Automatisierung von Prüfungen beginnen, sollten Sie mit Test Driven Development beginnen. Aber Vorsicht! Bei der testgetriebenen Entwicklung geht es nicht ums Testen. Es ist eine Methode zur Softwareentwicklung. Sie hilft bei der Gestaltung einer guten Software und beschleunigt den Entwicklungsprozess.
Aus Wartungsgründen sollte der Code auf mehrere Dateien verteilt werden. Sie alle haben eine einzige Verantwortung und nur wenige Wenns. Das bedeutet, dass diese zusammengefügt werden müssen, damit Sie sehen können, ob alle Teile zusammen funktionieren. Testgetriebene Entwicklung ermöglicht es den Entwicklern, schneller Feedback zu erhalten. Jede Komponente kann einzeln getestet werden, was einen viel kürzeren Feedback-Kreislauf ermöglicht.
Unit-Tests validieren oft nicht den Geschäftswert. Die Einheiten sind in der Regel zu klein und zu technisch, um den Geschäftswert auf dieser Ebene zu testen, und ihr Ergebnis kann an anderer Stelle in der Anwendung manipuliert werden. Die Annahme, dass Unit-Tests immer den geschäftlichen Wert überprüfen, kann zu falsch positiven Ergebnissen führen. Hüten Sie sich davor! Validieren Sie stattdessen den wesentlichen Geschäftswert in der Komponenten-/Integrationsprüfungsschicht.
Verwenden Sie eine angemessene Namenskonvention, die das Verhalten beschreibt und deutlich macht, warum ein Test repariert werden muss und was repariert werden muss, wenn er fehlschlägt. Etwa so: WhenTooManyProductsSelected_ShouldDisableAddToBasketButton().
Verwenden Sie Behavior Driven Development zur Erstellung einer lebendigen Dokumentation
Es macht keinen Sinn, Software zu testen, die sich nicht geändert hat - es sei denn, sie ist richtig dokumentiert. Testen dokumentiert das System, damit die Entwickler es ändern können. Automatisierte Prüfungen sind die Dokumentation des Systems und sie sollten die Änderung des Systems erleichtern und nicht erschweren.
Wie vertrauenswürdig ist ein Testergebnis, wenn sich Klassen ändern und ihre Tests ebenfalls überarbeitet wurden? Unit-Tests sind eng an die Klassenstruktur gekoppelt. Daher werden sie sich häufig ändern. Einige werden entfernt, einige werden geändert und einige werden hinzugefügt.
Stellen Sie mehrere Einheiten zusammen, um den Geschäftswert auf Komponentenintegrationsebene zu testen. Sie müssen die Tests, die den Geschäftswert enthalten, nicht ständig ändern. Das macht die Ergebnisse vertrauenswürdiger und gibt den Entwicklern die Freiheit, den Code zu refaktorisieren, wann immer sie wollen.
Verwenden Sie die Gherkin-Sprache, um Ihre Spezifikationen zu definieren, damit Ihr Kunde überprüfen kann, ob Sie die richtigen Dinge testen. Verknüpfen Sie die Spezifikation mit dem Code, indem Sie Cucumber, SpecFlow oder ein anderes BDD-Framework verwenden, um eine lebendige Dokumentation zu erstellen, die immer auf dem neuesten Stand ist.
Stellen Sie sicher, dass die Anwendung wie erwartet läuft
Nach Abschluss der Komponenten-/Integrationstests für alle funktionalen Anforderungen und der Unit-Tests für alle Randfälle müssen nur noch die Infrastruktur, die Konfiguration und die Berechtigungen getestet werden.
Wird die Anwendung gestartet und mit der Datenbank verbunden? Wurde sie richtig konfiguriert? Automatisieren Sie auch diese Tests und testen Sie sie auf einem bereitgestellten System.
Stellen Sie sicher, dass alle Komponenten an den erwarteten Stellen verwendet werden und verwenden Sie BDD, um diese Stellen zu spezifizieren. Es ist wichtig, dass diese Informationen in der Dokumentation des Systems enthalten sind.
Testen Sie den Test!
Jeder Code muss getestet werden, einschließlich automatischer Prüfungen. Diese sollen fehlschlagen und das Team warnen, wenn sich der Code ändert und das System beschädigt wird. Testen Sie diese, indem Sie if-Anweisungen im Code ändern und dann die Tests ausführen, um zu sehen, ob die Tests fehlschlagen. Wenn das nicht der Fall ist, haben Sie zu tun. Dieser Prozess wird als "Mutationstest" bezeichnet und kann manuell oder mit Hilfe von Frameworks durchgeführt werden.
Überwachen Sie auch weiter! Ich kann Ihnen gar nicht sagen, wie oft ich erlebt habe, dass Tests bestanden wurden und die Produktionsumgebung nicht funktionierte. Es reicht nicht aus, die Protokolldateien auf Fehler zu überprüfen. Wer sagt, dass Fehler protokolliert werden? Stellen Sie sicher, dass die Konvertierungspunkte noch erreicht werden. Nutzen Sie das Feedback aus der Produktionsumgebung, um die Testfälle zu vervollständigen.
Zusammenfassung
Testautomatisierung gibt es nicht. Automatisierung von Prüfungen schon. Verwenden Sie automatisierte Prüfungen, um effizienter zu testen und um sicherzustellen, dass der Zustand des Systems immer schnell ermittelt werden kann. Implementieren Sie die Testpyramide von Martin Fowler und verwenden Sie TDD, um den Kodierungsprozess zu beschleunigen. Testen Sie die Anforderungen des Systems auf einer abstrakteren Ebene, um ein einfaches Refactoring zu ermöglichen. Verwenden Sie nur wenige technische Tests, um die Infrastruktur und die Berechtigungen zu überprüfen. Verlassen Sie sich nicht blind auf Ihre automatisierten Prüfungen, testen Sie auch den Test.
Contact