Schwerpunkte

Fehler in Änderungen vermeiden

Regressionstests von Software Code

08. April 2021, 07:00 Uhr   |  Von Ricardo Camacho


Fortsetzung des Artikels von Teil 1 .

Was ist zu testen und was nicht?

Die größte Schwierigkeit bei Regressionstests ist, zu entscheiden, welche
Teile des Codes zu testen sind. Beste­hen Zweifel an den Effekten der letzten Codeänderungen, ist es üblich, standard­mäßig alle Regressions­tests durchzu­führen – der »Alles-oder-nichts-Ansatz«.

Bei großen Softwareprojekten wird das jedoch zu einem riesigen Unterfangen und verlangsamt die Produktivität des Teams. So verhindert die Unfähigkeit, das Testen zu fokussieren, einen Großteil der Vorteile iterativer und kontinuierlicher Prozesse – was sich bei Embedded-Software, bei der Testziele eine begrenzte Ressource darstellen, noch verschärfen kann.

Entwickler brauchen also einen Weg, um zu erkennen, welche Tests sie erneut ausführen müssen. Außerdem müssen sie die Testaufwände (Unit-Tests, automatisierte Funktionstests und manuelle Tests) auf das Validieren der Funktionen und des zugehörigen Codes konzentrieren, die von den jüngsten Änderungen betroffen sind. Mit der Kombination von Parasofts proprietären Analyse-Tools (C/C++test für C und C++, Jtest für Java und dotTEST für C#) und der Process Intelligence Engine (PIE) innerhalb der Development Testing Platform (DTP) des Tool-Herstellers, können Entwickler die Änderungen in der Codebasis zwischen den Builds verstehen und mit einer hohen Effizienz das Versprechen von Agile erreichen. Die Form, Tests intelligent auszuführen, wird Test-Impact-Analyse genannt, manchmal ebenso als Change Based Testing bezeichnet.

Testbericht
© Parasoft

Bild 3. Ein Beispiel für einen änderungsbasierten Testbericht der Development Testing Platform (DTP) von Parasoft, der Bereiche des Codes aufzeigt, die getestet und nicht getestet werden.

Die Test-Impact-Analyse

Die Test-Impact-Analyse nutzt die während der Testläufe gesammelten Daten und Änderungen im Code zwischen Builds, um festzustellen, welche Dateien sich geändert haben und von welchen spezifischen Tests die Dateien berührt wurden. So kann die Analyse-Engine von Parasoft das Delta zwischen zwei Builds analysieren
und die Teilmenge der auszuführenden Re­­gressionstests identifizieren.
Sie versteht außerdem die Abhängigkeiten zu den geänderten Units, um festzustellen, welchen Ripple-Effekt die Änderungen gegebenenfalls auf andere Units hatten.

Die Tools C/C++test, Jtest und dotTest geben Einblick in die Auswirkungen von Softwareänderungen und empfehlen, wo Tests hinzugefügt und wo mehr Regressionstests auszuführen sind. In Bild 3 ist ein Beispielbericht für änderungsbasierte Tests abgebildet.

Frühe und häufige Regressionstests

Das Rationalisieren von Regressionstests mit der Testauswirkungsanalyse senkt den Gesamtaufwand für Tests enorm. Entwickler und Tester können sich so völlig auf den betroffenen Code und die Tests konzentrieren. Das Ergebnis?

  • Mehr Tests erhöhen die Code-Ab­deckung.
  • Mehr Zyklen, um zu einem besseren Produkt zu gelangen.
  • Oder eine Kombination aus beidem.

Regressionstests sind nicht länger eine Last, sondern ein wichtiger Schritt zum Verbessern der Produktqualität und -sicherheit. Sie generieren Metriken, die helfen, Qualität, Sicherheit und den Gesamtfortschritt zu messen.

Softwareentwicklung
© Parasoft

Bild 4. Fehler zu einem früheren Zeitpunkt in der Softwareentwicklung aufzufinden, senkt die Kosten für das Beheben und reduziert die Auswirkungen auf nachgelagerte Aktivitäten.

Mit modernen Tools und zielbasierten Tests ist es möglich, schon beim Schreiben von Code mit Regressionstests zu beginnen. Jeder neue Unit-Test entwickelt sich im Lauf der Zeit zu einem Regressionstest und Entwickler können das änderungsbasierte Testen sofort nutzen. Frühzeitige Regressionstests bedeuten ein früheres Erkennen von Fehlern. Shifting Left spart sofort Zeit und Geld und zahlt sich später im Lebenszyklus der Software noch mehr aus. Entwickler sollten den Nutzen nicht unterschätzen, denn so lässt sich großer nachgelagerter Aufwand einsparen, wie Bild 4 zeigt.

Bewältigen der Testlast

Regressionstests sind beim Testen von Embedded-Software unerlässlich. Jede neu hinzugefügte Funktion, jeder behobene Fehler oder jedes Anpassen der Konfiguration erfordert Tests, um zu bestätigen, was bereits funktioniert und weiterhin funktioniert. Mit dem Anwachsen eines Projekts und der zunehmenden Komplexität der Software steigt ebenso die Anzahl an Regressionstests. Letztendlich ist ein Automatisieren der Tests nötig, um die Testlast zu bewältigen. Neue Techniken, wie intelligente Tests, vereinfachen Regressionstests. Sie bewirkt, dass sich Entwickler und Tester auf solche Tests konzen­trieren, die speziell den geänderten und betroffenen Code testen. Ein Kombinieren von
Prozessen wie Agile, Continous Integra­tion/Continous Development (CI/CD) und DevOps
mit automatisierten Softwaretests ermöglicht es, mit Regressionstests schon beim Schreiben des Codes anzufangen. Hiermit verlagern Entwickler das Testen auf einen früheren Zeitpunkt und decken Fehler früher auf – dann sind sie kostengünstiger und einfacher zu beheben.

Camacho-Ricardo
© Parasoft

Ricardo Camacho ist Senior Technical Product Marketing Manager für Parasofts Embedded-Testlösungen.

Der Autor

Ricardo Camacho ist Senior Technical Product Marketing Manager für Parasofts Embedded-Testlösungen. Ricardo hat Erfahrung im Software Development Lifecycle und in der Test­automatisierung von embedded Echtzeit-, Sicherheits- und sicherheitskritischen Anwendungen sowie in der Konformität von Software mit Industriestandards.
E-Mail: ricardo.camacho@parasoft.com

Seite 2 von 2

1. Regressionstests von Software Code
2. Was ist zu testen und was nicht?

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

Parasoft Corp.