Automatisierte Softwaretests

Warum ist Testautomatisierung wichtig für Continuous Delivery?

Bei Continuous Delivery (CD) geht es darum, Kunden so schnell wie möglich neue Codeversionen zu liefern. Automatisierte Tests sind entscheidend für dieses Ziel. Die Bereitstellung an die Benutzer kann nicht automatisiert werden, wenn innerhalb des Bereitstellungsprozesses manuelle, zeitraubende Schritte vorhanden sind.

CD ist Teil einer größeren Deployment-Pipeline. CD ist ein Nachfolger von Continuous Integration und ist auch davon abhängig. CI ist voll verantwortlich für die Durchführung automatisierter Tests für neue Codeänderungen und stellt sicher, dass diese Änderungen die etablierten Funktionen nicht stören oder neue Fehler verursachen. CD wird ausgelöst, sobald der Continuous-Integration-Schritt den automatisierten Testplan bestanden hat.

Diese Beziehung zwischen automatisiertem Testen, CI und CD bringt viele Vorteile für ein High-Velocity-Softwareteam. Automatisierte Tests gewährleisten die Qualität in jeder Phase der Entwicklung, indem sichergestellt wird, dass neue Commits keine Fehler verursachen, sodass die Software jederzeit einsatzbereit bleibt.

1. End-to-End-Tests

Die wohl wertvollsten Tests, die implementiert werden müssen, sind End-to-End-Tests (E2E). E2E-Tests simulieren eine User Experience des gesamten Stacks eines Softwareprodukts. Die Pläne für E2E-Tests umfassen im Allgemeinen Storys auf Benutzerebene wie: "Ein Benutzer kann sich einloggen", "Ein Benutzer kann eine Einzahlung vornehmen", "Ein Benutzer kann die E-Mail-Einstellungen ändern". Die Implementierung dieser Tests ist äußerst wertvoll, da sie die Gewissheit bieten, dass echte Benutzer eine reibungslose, fehlerfreie Erfahrung haben, selbst wenn neue Commits gepusht werden

E2E-Testtools erfassen und wiederholen Benutzeraktionen, sodass E2E-Testpläne dann zu Aufzeichnungen wichtiger Benutzererfahrungsabläufe werden. Wenn die automatisierte Testabdeckung eines Softwareprodukts Lücken aufweist, wird der größte Nutzen durch die Implementierung von E2E-Tests der kritischsten Geschäftsabläufe erzielt. E2E-Tests im Vorfeld zur Erfassung und Aufzeichnung von Benutzerabläufen können teuer sein. Wenn das Softwareprodukt keine täglichen schnellen Releases durchführt, kann es wirtschaftlicher sein, die E2E-Testpläne durch ein menschliches Team manuell ausführen zu lassen.

2. Unit-Tests

Wie der Name schon sagt, decken Unit-Tests einzelne Codeeinheiten ab. Codeeinheiten werden am besten in Funktionsdefinitionen gemessen. Ein Unit-Test deckt eine einzelne Funktion ab. Unit-Tests bestätigen, dass die erwartete Ausgabe für eine Funktion der erwarteten Eingabe entspricht. Code mit sensiblen Berechnungen (z. B. in den Bereichen Finanzen, Gesundheitswesen oder Luft- und Raumfahrt) wird am besten durch Unit-Tests abgedeckt. Unit-Tests sind kostengünstig und schnell umsetzbar und bieten eine hohe Kapitalrendite.

3. Integrationstests

Oft greift eine Codeeinheit auf einen externen Drittanbieterservice zu. Die primäre Codebasis, die getestet wird, hat keinen Zugriff auf den Code dieses Drittanbieter-Dienstprogramms. Integrationstests ahmen diese Abhängigkeiten von Drittanbietern nach und bestätigen, dass sich der Code wie erwartet verhält.

Integrationstests ähneln Unit-Tests im Hinblick auf Code und Tools. Integrationstests können eine kostengünstige Alternative zu E2E-Tests sein, aber der ROI ist fraglich, wenn bereits eine Kombination von Unit-Tests und E2E vorhanden ist.

4. Leistungstests

Im Zusammenhang mit der Softwareentwicklung wird "Leistung" verwendet, um die Geschwindigkeit, mit der ein Softwareprojekt reagiert, zu beschreiben. Einige Beispiele für Leistungsmetriken sind: "Zeit bis zum Laden der Seite", "Zeit bis zum ersten Rendern" und "Reaktionszeit der Suchergebnisse". Leistungstests erstellen Messungen und Aussagen für diese Beispielfälle. Automatisierte Leistungstests führen Testfälle für diese Metriken aus und warnen das Team dann bei Regressionen oder Geschwindigkeitsverlusten.

Welche Arten von Softwaretests sollten manuell durchgeführt werden?

Es ist umstritten, ob alle Tests, die automatisiert werden können, automatisiert werden sollten. Automatisierung erzielt einen enormen Gewinn an Produktivität und Mitarbeiterzeit. Trotzdem gibt es Zeiten, in denen sich der ROI der Entwicklung einer automatisierten Testsuite im Vergleich zur Durchführung eines manuellen Tests nicht lohnt.

1. Exploratives Testen

Automatisierte Tests sind skriptbasiert und führen eine Reihe von Schritten zur Verhaltensvalidierung aus. Exploratives Testen ist zufälliger und versucht, mit ungeskripteten Sequenzen Fehler oder unerwartetes Verhalten zu finden. Es sind zwar Softwaretools zur Einrichtung einer explorativen Softwaretestsuite verfügbar, sie sind jedoch noch nicht vollständig ausgereift und kaum verbreitet. Es kann viel effizienter sein, einen manuellen QS-Tester zuzuweisen und mit menschlicher Kreativität zu untersuchen, wie ein Softwareprodukt zum Absturz gebracht werden kann.

2. Visuelle Regressionstests

Eine visuelle Regression tritt auf, wenn ein visueller Designfehler in die Software-Benutzeroberfläche eingeführt wird. Dies können falsch positionierte Elemente der Benutzeroberfläche, falsche Schrift, falsche Farben usw. sein. Wie beim explorativen Testen gibt es Tools zum Schreiben automatisierter Tests, um diese Regressionen zu erfassen. Diese Tools erfassen Screenshots aus verschiedenen Zuständen eines Softwareprodukts und verwenden dann OCR, um sie mit den erwarteten Ergebnissen zu vergleichen. Diese Tests sind teuer in der Entwicklung und die Tools sind nicht weit verbreitet. Es kann viel effektiver sein, einen menschlichen Blick auf die Software zu werfen und sich anzusehen, ob es irgendwelche visuellen Probleme gibt.

3. Aufbau eines Frameworks zur Testautomatisierung für dein DevOps-Team

Es gibt keine allumfassende Lösung für automatisierte Tests. Bei der Planung einer automatisierten Testlösung für dein Team müssen einige wichtige Überlegungen angestellt werden.

4. Häufigkeit der Releases

Für Softwareprodukte, die in festen Intervallen wie monatlich oder wöchentlich veröffentlicht werden, sind möglicherweise manuelle Tests besser geeignet. Softwareprodukte, die schneller veröffentlicht werden, werden von automatisierten Tests erheblich profitieren, da CI und CD von automatisierten Tests abhängig sind.

5. Verfügbare Tools und Ökosystem

Jede Programmiersprache hat ihr eigenes Ökosystem ergänzender Tools und Dienstprogramme. Jede Art von automatisierten Testmustern verfügt über ein eigenes Toolset, das in einem bestimmten Ökosystem für Programmiersprachen verfügbar ist oder nicht. Für die erfolgreiche Implementierung eines automatisierten Testmusters muss ein Schnittpunkt der Sprach- und Toolunterstützung vorhanden sein.

6. Markteignung und Codebasisreife des Produkts

Wenn dein Team daran arbeitet, ein neues Produkt zu entwickeln, das sich noch nicht bei einer Zielgruppe als Geschäftsmodell bewährt hat, ist es möglicherweise nicht sinnvoll, in automatisierte Tests zu investieren. Automatisierte Tests fungieren als Versicherungsmechanismus, um unerwartete Coderegressionen einzuschränken. Wenn dein Team sich mit hoher Geschwindigkeit bewegt, kann es frustrierend teuer sein, automatisierte Tests aktualisieren und pflegen zu müssen, wenn sich der Code drastisch und rasant ändert.

Automatisierte Tests als Bestandteil der CD-Pipeline

Automatisiertes Testen ist ein Standardverfahren der modernen Softwareentwicklung. Die besten Teams und Unternehmen verwenden automatisierte Tests. CI/CD ist auf automatisierte Tests angewiesen und unterstützt die erfolgreichsten Teams entscheidend dabei, zuverlässige und robuste Software an ihre Kunden auszuliefern.

Atlassian Open DevOps ist eine offene Toolketten-Plattform, mit der du eine CD-basierte Entwicklungspipeline mit den Tools aufbauen kannst, die du liebst. Schau dir in unseren DevOps-Testtutorials an, wie du mit den Tools von Atlassian und Drittanbietern einen Testschritt in deinen Workflow integrierst.