Funktionale Regressionstests mit SOAtest als Teil eines kontinuierlichen Integrationsprozesses

Was ist ein funktionaler Regressionstest?

Eine Regression wird als „ein Trend oder eine Verschiebung hin zu einem niedrigeren oder nicht perfekten Zustand“ definiert, was wir alle bei der Entwicklung von Software zu vermeiden versuchen. Regressionstests entdecken Fehler, die sich in unsere Software einschleichen, wenn wir neue Funktionen hinzufügen, Fehler beheben oder die Anwendung anderweitig ändern.

Regressionstests sind eine gängige Methode, die in den meisten Softwareentwicklungsprozessen eingesetzt wird, um die Funktionalität einer Software nach der Durchführung von Änderungen noch einmal zu überprüfen. Bei diesen Tests wird ermittelt, ob die neuen Änderungen Auswirkungen auf die aktuelle Funktionalität der Software haben. Für neue Funktionalitäten sind natürlich neue Tests nötig. Regressionstests stellen sicher, dass das, was bereits getestet wurde, weiterhin funktionsfähig bleibt.

Regressionstests spielen eine wichtige Rolle bei der kontinuierlichen Integration (CI) in der Softwareentwicklung, indem sie sicherstellen, dass der neu integrierte Code keine bestehenden Funktionen beeinträchtigt oder Regressionen einführt. Diese Tests liefern das für CI unerlässliche schnelle Feedback, indem sie Fehler in neu integriertem Code erkennen, sodass diese schnell identifiziert und behoben werden können, bevor sie die Stabilität der Software beeinträchtigen.

Funktioneller Regressionstest vs. Funktionstest

Regressionstests umfassen Funktionstests. In der Praxis werden die meisten Funktionstests im Laufe der Zeit zu Regressionstests. Der große Unterschied besteht im Zeitpunkt und Ziel dieser Tests.

Funktionstests werden typischerweise während der Entwicklung durchgeführt, wenn neue Funktionen entwickelt, implementiert und getestet werden. Es konzentriert sich auf bestimmte Funktionen, Features oder Anwendungsfälle der Software, um zu überprüfen, ob sie sich wie erwartet verhalten. Dabei kann es sich um verschiedene Testtechniken wie Unit-Tests, API-Tests, UI-Tests und andere handeln.

Regressionstests hingegen werden während der Entwicklung als Teil der CI-Pipeline und/oder nach wichtigen Entwicklungsmeilensteinen, beispielsweise am Ende eines Sprints oder eines Release-Zyklus, durchgeführt. Regressionstests werden so weit wie möglich automatisiert, damit sie wiederholbar und effizient sind, und sie umfassen sowohl funktionale als auch nichtfunktionale Tests. Mehr dazu weiter unten.

Tools für funktionale Regressionstests

Regressionstests profitieren erheblich von der Automatisierung, und daher unterstützen Tools, die zur Unterstützung der Praxis entwickelt wurden, auch die Automatisierung aller Arten von Tests. Diese Tools helfen bei der Automatisierung der Ausführung von Testfällen, die die Softwarefunktionalität überprüfen, Ergebnisse sammeln und analysieren und über etwaige Regressionsprobleme berichten. Hier sind einige häufig verwendete Klassen von Software-Automatisierungstools für funktionale Regressionstests.

• Testen der Benutzeroberfläche. Diese Tools automatisieren die Testen von Benutzeroberflächen basierend auf einem Aufnahme- und Wiedergabeparadigma. Tester zeichnen Anwendungsfälle oder Benutzerworkflows auf und die Tools geben dieselben Aktionen in der Benutzeroberfläche wieder. Selenium ist beispielsweise ein beliebtes Open-Source-Automatisierungstool, das häufig zum Testen von Webanwendungen verwendet wird. Es unterstützt mehrere Programmiersprachen und bietet ein Framework zur Automatisierung von Browserinteraktionen.
• API-Tests. Testautomatisierung auf API-Ebene Für deren Ausführung sind Testfälle und Kabelbäume erforderlich, die direkt mit den zugrunde liegenden Anwendungs-APIs interagieren. Tests auf dieser Ebene haben Vorteile gegenüber manuellen und automatisierten UI-Tests, da sie widerstandsfähiger gegenüber UI-Änderungen sind und die Geschäftslogik direkter testen.
• Unit Testing. Unit-Test erfolgt in der untersten Softwarekomponente, bei der es sich in der Regel um eine Methode in C++ oder Java oder eine Funktion in C handelt. Unit-Tests funktionieren durch individuelles Testen von Codefunktionen und/oder -prozeduren in einer Quelldatei auf Sicherheit, Schutz und Robustheit. Während Unit-Tests ausgeführt werden, werden Ausgabewerte der Funktionen gesammelt und auf Richtigkeit überprüft. Berichte können zu Prüf- oder Compliance-Zwecken gespeichert werden. Viele Entwicklungsteams messen auch die Codeabdeckung, um nicht getesteten Code offenzulegen. Zu wissen, dass jede einzelne Codeeinheit getestet wurde und einwandfrei ist, eliminiert Risiken und trägt dazu bei, die Bereitstellung einer qualitativ hochwertigen Anwendung sicherzustellen.
• Testdatenverwaltung. Während des Testprozesses müssen den zu testenden Anwendungen geeignete Testdaten zur Verfügung gestellt werden, damit die Testfälle die Anwendungsfunktionalität validieren können, einschließlich allgemeiner oder kritischer Benutzerpfade und Eckfälle. Wenn realistische Testdaten verwendet werden, hilft es auch, Fehlerzustände und Mängel nachzubilden. Testdatenmanagement (TDM) bietet eine Möglichkeit, sichere und geeignete Datensätze zu erstellen und zu verwalten, die Ihr Unternehmen von mehreren Teams zur Validierung der Funktionalität und Leistung einer Anwendung verwenden kann.
• Berichterstellung und Analyse. Nach der Durchführung von Regressionstests werden die Ergebnisse analysiert, um beides bereitzustellen Status und umsetzbare Erkenntnisse die im Web, auf dem Desktop oder in statischen HTML-Berichten angezeigt werden können. Im Idealfall werden Analysen in benutzerfreundlichen, anpassbaren Dashboards präsentiert, die aus hochflexiblen Widgets bestehen, die die Risiken innerhalb Ihrer Codebasis klar darstellen und einen umfassenden Überblick über den Projektstatus und die Qualität bieten.

Diese Arten von Tools sind eine Teilmenge der vielen verschiedenen Tools, die möglicherweise für die vollständige Validierung einer Anwendung erforderlich sind. Es ist wichtig, dass diese Tools nahtlos zusammenarbeiten, um die CI/CD-Pipeline zu erleichtern.

Erzielen Sie Geschwindigkeit und schützen Sie Ihre Anwendung gleichzeitig vor Regressionen

CI ist eine gut verstandene, gut angewandte Praxis und ein notwendiger erster Schritt, um die Geschwindigkeit der Anwendungsbereitstellung deutlich zu verbessern. Es ermöglicht Entwicklern, ihre Änderungen direkt in einen Hauptzweig des Quellcodes zu übertragen. Ein einzelner Entwickler kann möglicherweise an einem einzigen Tag viele Änderungen an der Hauptniederlassung vornehmen. Um sicherzustellen, dass der Master-Zweig makellos, erstellbar und produktionstauglich ist, ist es wichtig, für jede Änderung über geeignete Testfälle zu verfügen, da er als goldene Kopie des Quellcodes für die Anwendung dient.

Sehen wir uns an, wie man Parasoft SOAtest für die Durchführung von Funktionstests und Regressionstests als Teil eines kontinuierlichen Integrationsprozesses konfiguriert. Wir werden die Schritte zum Konfigurieren von Parasoft SOAtest mit Jenkins, einer beliebten Automatisierungsplattform unter Verwendung der Open-Source-Demoanwendung Parabank, durchgehen und sie mit Docker bereitstellen, um die Dinge einfacher zu halten.

Wie wird das funktionieren?

Das folgende Diagramm zeigt den in diesem Artikel beschriebenen Workflow. Folgen Sie den Schritten von links nach rechts.

1. Ein Entwickler oder Tester checkt seine Testfälle in ein Quellcodeverwaltungs-Repository ein. In diesem Beispiel verwenden wir GitHub.
2. Jenkins wird das Repository von GitHub auschecken, das das SOAtest-Projekt mit dem Namen „Parabank”, das unsere funktionalen Testfälle enthält. Jenkins wird auch ein Docker-Image namens abrufen Parasoft/Parabank vom Docker Hub. Dieses Image enthält nicht nur Parabank, sondern auch den Anwendungsserver und die zum Ausführen der Anwendung erforderlichen Abhängigkeiten.
3. Jenkins erstellt ein Parabank-Image (als „Container“ bezeichnet) und konfiguriert die zu testende Anwendung (AUT) entsprechend den Besonderheiten der Testumgebung.
4. Jenkins wird dann Parasoft SOAtest veranlassen, von GitHub abgerufene Funktionstests auszuführen, damit wir unsere Parabank-Anwendung validieren und alle erforderlichen Fehlerkorrekturen implementieren können.

Zugegebenermaßen entspricht dies nicht ganz dem Geist einer echten kontinuierlichen Integration, da wir mit einem vorgefertigten Docker-Image beginnen. Aber das erspart uns die Mühe, Parabank mit Maven zu erstellen und Tomcat/Java zu installieren und zu konfigurieren.

Das folgende Diagramm zeigt ein realistischeres, praxisnahes Diagramm von CI. Sobald ein Entwickler den Quellcode in GitHub eincheckt, möchten wir die erforderlichen Regressionstests und alle neuen Funktionstestfälle durchführen, um zu überprüfen, ob die Anwendung auch nach den Änderungen des Entwicklers noch in einem guten Zustand ist.

Eine Änderung des Quellcodes in GitHub löst automatisch einen Build in Jenkins aus, und Jenkins startet eine Maven-Build-Phase, die alle statischen Codeanalysen und JUnit-Tests ausführt und unsere Anwendung erstellt. Wenn alle Komponententests erfolgreich sind, wird die gepackte Anwendung parabank.war im Rahmen der Bereitstellungsphase auf einem Anwendungsserver – in diesem Fall Tomcat – bereitgestellt. SOAtest startet dann die Testphase und führt Regressionstests und Funktionstests durch.

Erst nachdem die Unit-Tests und Black-Box-Testfälle während der SOAtest-Ausführung bestanden wurden, gelten die ursprünglichen Änderungen des Entwicklers als gut.

Sehen wir uns die Voraussetzungen und Schritte zum Konfigurieren des Prozesses im ersten Diagramm an.

Konfigurieren von SOAtest und Jenkins

Voraussetzungen:

• Eine Maschine, die Docker ausführen kann. Dieses Tutorial verwendet Windows, daher können einige der Befehle in diesem Artikel eine andere Syntax haben. Dieses Gerät muss mit dem Internet verbunden sein.
• Erstellen Sie irgendwo auf Ihrem Computer eine Datei „localsettings.properties“. Kopieren Sie den Inhalt davon Beispieldatei hinein. Wenn Sie eine Node Locked-Lizenz haben, fügen Sie diese zu Zeile 5 hinzu. Wenn Sie einen Lizenzserver verwenden, setzen Sie Zeile 6 auf true und fügen Sie Ihren Lizenzserver-Hostnamen in Zeile 3 hinzu. Der Pfad zu dieser Datei wird später benötigt.
• Jenkins 2.387.1 oder neuer auf demselben Computer installiert.
• Parasoft SOAtest 2022.1 oder neuer installiert und im PATH zum Aufrufen von soatestcli aus einem beliebigen Verzeichnis.
• Docker installiert und auf dem Pfad derselben Maschine.
• Git installiert.

Shritte

1. Melden Sie sich in Ihrem Webbrowser bei Jenkins an. Jenkins wird normalerweise unter einer URL wie http:// bereitgestellt. :8080/jenkins.

2. Wir beginnen mit der Installation einiger Jenkins-Plugins. Wählen Sie links „Jenkins verwalten“ und dann im neuen Menü „Plugins verwalten“ aus.

3. Wählen Sie auf der Registerkarte „Verfügbar“ das Parasoft Findings-Plugin aus und installieren Sie es.
4. Wählen Sie „Ohne Neustart installieren“ und aktivieren Sie dann auf der Seite „Installation“ das Kontrollkästchen „Jenkins neu starten, wenn die Installation abgeschlossen ist und keine Jobs ausgeführt werden“.
5. Kehren Sie zum Hauptmenü von Jenkins aus Schritt 1 zurück. Wählen Sie links „Neues Element“ aus.

6. Geben Sie den Namen „Parabank Deploy and Test“ ein, wählen Sie „Freestyle-Projekt“ und dann „OK“.

7. Scrollen Sie im angezeigten Konfigurationsmenü nach unten zu Quellcodeverwaltung und wählen Sie Git aus. Fügen Sie diese URL zum Repo-URL-Feld hinzu: https://github.com/sdebrosse/soatest-automation-example.git. Alle anderen Felder können mit ihren Standardwerten belassen werden.

8. Scrollen Sie zum Ende der Seite und fügen Sie unter „Erstellen“ den Build-Schritt „Windows-Batchbefehl ausführen“ hinzu. Wenn Sie Linux verwenden, wählen Sie stattdessen „Shell ausführen“.

9. Kopieren Sie den Inhalt des Skripts hier und fügen Sie es in das neue Build-Schritt-Feld ein. Sie müssen die Werte der beiden Variablen oben im Skript ändern, um den Pfad zu Ihrer eigenen Datei „localsettings.properties“ und den Ort anzugeben, an dem ein temporärer Arbeitsbereich erstellt werden soll. SOAtest erstellt diesen Arbeitsbereich während des Testprozesses. Kommentare im Skript erklären, was in jeder Zeile passiert.

10. Das ist es. Jetzt sind wir bereit, unseren Jenkins-Job auszuführen! Stellen Sie sicher, dass Sie zunächst alle geöffneten Instanzen von SOAtest schließen. Wählen Sie dann unten im Konfigurationsmenü „Speichern“ und klicken Sie links auf „Jetzt erstellen“.

11. Sie können links auf den laufenden Job klicken und dann die Live-Konsolenausgabe anzeigen.

12. Die Protokolle geben am Ende Ihres Auftrags den Status ERFOLGREICH aus, wenn alles korrekt funktioniert hat. Das bedeutet, dass Sie erfolgreich ein SOAtest-Testprojekt von GitHub abgerufen, einen Docker-Container mit Parabank bereitgestellt und Tests für diese Parabank-Anwendung ausgeführt haben. Am Ende des Prozesses haben wir den Parabank-Container automatisch beendet und unseren temp_workspace gelöscht, um die Build-Umgebung zu bereinigen. Aber vielleicht haben Sie beim Durchsehen der Protokolle bemerkt, dass es bei unseren Tests zu einigen Fehlern kam. Ja, einige unserer Tests gegen Parabank sind fehlgeschlagen.

Wenn wir möchten, dass unser Jenkins-Build aufgrund von SOAtest-Testfehlern fehlschlägt, fügen wir das Flag -fail hinzu, wenn wir soatestcli aufrufen. So was:

soatestcli.exe -fail -data %TEMP_WORKSPACE_PATH% -resource /Parabank -config “builtin://Demo Configuration” -localsettings %LOCALSETTINGS_PATH% 

Wenn Sie den Test in der SOAtest-Desktop-Benutzeroberfläche öffnen, werden Sie feststellen, dass es sich bei diesem Testfehler in erster Linie um ein Problem mit den Testdaten und der Testumgebungskonfiguration handelt. Der Loan Processor Service lehnte einen Kredit ab, den er hätte genehmigen sollen.

Zusammenfassung

Die Implementierung einer kontinuierlichen Integration in Ihren Softwareentwicklungsprozess erhöht die Geschwindigkeit der Anwendungsbereitstellung erheblich. Automatisierte Lösungen wie SOAtest bieten eine skalierbare und effiziente Regressionsteststrategie mit der Möglichkeit, Testfälle auszuführen, die die Softwarefunktionalität überprüfen, Ergebnisse sammeln und analysieren und etwaige Regressionsprobleme melden. Die Kombination hilft Teams, eine höhere Release-Geschwindigkeit zu erreichen, die Testproduktivität zu verbessern und eine hohe Testabdeckung sicherzustellen.