Ich wollte nur hinzufügen und etwas mehr Kontext dazu geben, warum wir diese Teststufen haben, was sie mit Beispielen wirklich bedeuten
Mike Cohn hat in seinem Buch „Erfolg mit Agilität“ die „Testpyramide“ entwickelt, um automatisierte Tests in Projekten anzugehen. Es gibt verschiedene Interpretationen dieses Modells. Das Modell erklärt, welche Art von automatisierten Tests erstellt werden müssen, wie schnell sie Feedback zur zu testenden Anwendung geben können und wer diese Tests schreibt. Grundsätzlich sind für jedes Projekt drei Ebenen automatisierter Tests erforderlich, die wie folgt lauten.
Komponententests -
Diese testen die kleinste Komponente Ihrer Softwareanwendung. Dies könnte buchstäblich eine Funktion in einem Code sein, der einen Wert basierend auf einigen Eingaben berechnet. Diese Funktion ist Teil mehrerer anderer Funktionen der Hardware- / Software-Codebasis, aus der die Anwendung besteht.
Zum Beispiel - Nehmen wir eine webbasierte Taschenrechneranwendung. Die kleinsten Komponenten dieser Anwendung, die einem Unit-Test unterzogen werden müssen, können eine Funktion sein, die eine Addition ausführt, eine andere, die eine Subtraktion ausführt, und so weiter. Alle diese kleinen Funktionen zusammen bilden die Taschenrechneranwendung.
In der Vergangenheit schreibt der Entwickler diese Tests, da sie normalerweise in derselben Programmiersprache wie die Softwareanwendung geschrieben sind. Zu diesem Zweck werden Unit-Test-Frameworks wie JUnit und NUnit (für Java), MSTest (für C # und .NET) und Jasmine / Mocha (für JavaScript) verwendet.
Der größte Vorteil von Unit-Tests besteht darin, dass sie unter der Benutzeroberfläche sehr schnell ausgeführt werden und wir schnelles Feedback zur Anwendung erhalten können. Dies sollte mehr als 50% Ihrer automatisierten Tests umfassen.
API / Integrationstests -
Diese testen verschiedene Komponenten des Softwaresystems zusammen. Die Komponenten können Testdatenbanken, APIs (Application Programming Interface), Tools und Dienste von Drittanbietern sowie die Anwendung umfassen.
Beispiel: In unserem obigen Taschenrechnerbeispiel verwendet die Webanwendung möglicherweise eine Datenbank zum Speichern von Werten, verwendet APIs, um einige serverseitige Überprüfungen durchzuführen, und verwendet möglicherweise ein Tool / einen Dienst eines Drittanbieters, um Ergebnisse in der Cloud zu veröffentlichen, um sie für verschiedene Zwecke verfügbar zu machen Plattformen.
In der Vergangenheit hat ein Entwickler oder eine technische Qualitätssicherung diese Tests mit verschiedenen Tools wie Postman, SoapUI, JMeter und anderen Tools wie Testim geschrieben.
Diese werden viel schneller ausgeführt als UI-Tests, da sie immer noch unter der Haube ausgeführt werden. Sie benötigen jedoch möglicherweise etwas mehr Zeit als Unit-Tests, da die Kommunikation zwischen verschiedenen unabhängigen Komponenten des Systems überprüft und eine nahtlose Integration sichergestellt werden muss. Dies sollte mehr als 30% der automatisierten Tests umfassen.
UI-Tests -
Schließlich haben wir Tests, die die UI der Anwendung validieren. Diese Tests werden normalerweise geschrieben, um End-to-End-Flüsse durch die Anwendung zu testen.
Beispiel: In der Taschenrechneranwendung kann ein End-to-End-Ablauf darin bestehen, den Browser zu öffnen -> die URL der Taschenrechneranwendung einzugeben -> sich mit Benutzername / Passwort anzumelden -> die Taschenrechneranwendung zu öffnen -> einige Vorgänge am Taschenrechner auszuführen -> Überprüfen dieser Ergebnisse über die Benutzeroberfläche -> Abmelden von der Anwendung. Dies könnte ein End-to-End-Ablauf sein, der ein guter Kandidat für die Automatisierung der Benutzeroberfläche wäre.
In der Vergangenheit schreiben technische QS oder manuelle Tester UI-Tests. Sie verwenden Open Source-Frameworks wie Selenium oder UI-Testplattformen wie Testim, um die Tests zu erstellen, auszuführen und zu warten. Diese Tests geben mehr visuelles Feedback, da Sie anhand von Screenshots, Protokollen und Testberichten sehen können, wie die Tests ausgeführt werden und wie unterschiedlich die erwarteten und tatsächlichen Ergebnisse sind.
Die größte Einschränkung von UI-Tests besteht darin, dass sie im Vergleich zu Tests auf Einheiten- und API-Ebene relativ langsam sind. Es sollte also nur 10-20% der gesamten automatisierten Tests ausmachen.
Die nächsten beiden Arten von Tests können je nach Projekt variieren, aber die Idee ist:
Rauchtests
Dies kann eine Kombination der oben genannten 3 Teststufen sein. Die Idee ist, es bei jedem Code-Check-in auszuführen und sicherzustellen, dass die kritischen Funktionen des Systems weiterhin wie erwartet funktionieren. nachdem die neuen Codeänderungen zusammengeführt wurden. Sie müssen normalerweise 5 bis 10 Minuten laufen, um eine schnellere Rückmeldung zu Fehlern zu erhalten
Regressionstests
Sie werden in der Regel mindestens einmal täglich ausgeführt und decken verschiedene Funktionen des Systems ab. Sie stellen sicher, dass die Anwendung weiterhin wie erwartet funktioniert. Sie sind detaillierter als die Rauchtests und decken mehr Szenarien der Anwendung ab, einschließlich der unkritischen.
