Fehler in Änderungen vermeiden
Regressionstests von Software Code
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. Bestehen Zweifel an den Effekten der letzten Codeänderungen, ist es üblich, standardmäßig alle Regressionstests durchzufü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.
Jobangebote+ passend zum Thema
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 Regressionstests 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-Abdeckung.
- 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.
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 konzentrieren, die speziell den geänderten und betroffenen Code testen. Ein Kombinieren von
Prozessen wie Agile, Continous Integration/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.
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 Testautomatisierung von embedded Echtzeit-, Sicherheits- und sicherheitskritischen Anwendungen sowie in der Konformität von Software mit Industriestandards.
E-Mail: ricardo.camacho@parasoft.com
- Regressionstests von Software Code
- Was ist zu testen und was nicht?
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Debugging
Mehr Sicherheit für Cypress-SoC
Interview mit Dr. Johan Kraft
»Tracealyzer erreicht eine neue Stufe«
Angriff auf CPU-Markt
Nvidia stellt »Grace« vor
Zertifizieren von Systemen
Mit dem richtigen Tool zum Erfolg
Schutz für vernetzte Maschinen
Technik als Tresor
Embedded-Design
Geräte sicher entwerfen mit PSA Certified
