Test-Impact-Analyse : Fehler schnell und zuverlässig aufdecken

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

CQSE GmbH

Große Test-Suites haben oft eine lange Laufzeit. Daher werden sie in der Praxis meistens nicht als Teil der Continuous Integration (CI) ausgeführt, sondern erst in späteren Testphasen. Somit werden viele Fehler erst spät gefunden, was hohen Aufwand verursacht. Der Einsatz von Test-Impact-Analyse kann hier Abhilfe schaffen: Durch strategische Auswahl und Sortierung von Testfällen ermöglicht sie es, 90% der fehlerhaften Builds in nur 2% der Laufzeit der gesamten Test-Suite zu identifizieren.

Wenn Software wächst, muss auch ihre Test-Suite wachsen, sollen Fehler zuverlässig gefunden werden. Damit steigt aber auch die Ausführungsdauer aller Tests. Wir sehen in der Praxis immer öfter Test-Suites, die mehrere Stunden oder sogar Tage laufen.

Nach unserer Erfahrung werden aber langlaufende Suites typischerweise aus der Continuous Integration herausgenommen. Oft werden sie dann nur noch in nachgelagerten Testphasen ausgeführt, die beispielsweise vor jedem Release stattfinden. Durch die seltenere Ausführung der Test-Suite verlängert sich jedoch der Zeitraum zwischen Fehlerentstehung und -aufdeckung. Das hat umfassende negative Konsequenzen:

• Fehler können sich gegenseitig überlagern und so erst erkannt werden, wenn andere Fehler behoben sind.

• Debugging von Regressionsfehlern wird aufwändiger, da eine immer größere Anzahl von Code-Änderungen den Fehler verursacht haben kann.

• Fehlerkorrekturen dauern länger, da sich Entwickler in ihren eigenen Code neu einarbeiten müssen, wenn ein Fehler erst Wochen nach seinem Einbau aufgedeckt wird.

Diese Effekte nehmen zu, je stärker System und Test-Suite wachsen. Ironischerweise gefährdet das die Effektivität von Continuous Integration gerade bei großen Systemen, die oft einen besonders hohen strategischen Wert haben und bei denen kurze Feedback-Zyklen daher besonders wichtig wären. Wie können wir das verhindern und trotz steigender Ausführungsdauer unserer Test-Suites in der Continuous Integration schnell neue Fehler finden?

Unser Ansatz für Test-Impact-Analyse (TIA) adressiert dieses Problem, indem Testfälle auf Basis von Code-Änderungen selektiert und priorisiert werden. Dazu werden die Code-Änderungen analysiert, die seit dem letzten erfolgreichen Testlauf durchgeführt worden sind. Dann werden nur die Testfälle ausgewählt, die auch geänderten Code durchlaufen. Diese Tests werden dann so sortiert, dass sie Fehler möglichst früh im Testlauf finden. Je häufiger TIA durchgeführt wird, desto weniger Änderungen liegen zwischen zwei Testläufen, und desto größer ist die zu erwartende Laufzeitersparnis.

Test-Impact-Analyse

Bild 1 gibt einen Überblick über den Aufbau der von uns eingesetzten TIA. Wie dargestellt, lässt sich die Analyse grob in zwei Phasen aufteilen.

Das Ziel von Phase 1 ist die Erhebung von Coverage für die einzelnen Testfälle sowie die Messung ihrer Laufzeit. Hierzu werden Testfälle einzeln auf der Testumgebung unter Verwendung eines Profilers ausgeführt. Dabei wird gemessen, welche Teile des Quelltexts pro Testfall durchlaufen werden und wie viel Zeit dies in Anspruch nimmt. Diese „Test-Impact-Daten“ werden in einer Datenbank gespeichert.

Das Ziel von Phase 2 ist die eigentliche Generierung von Vorschlägen, welche Testfälle in welcher Reihenfolge ausgeführt werden sollen. Diese Phase wird immer dann durchgeführt, wenn Änderungen am Quelltext des Systems unter Test vorgenommen wurden und in der Folge Tests zur Ausführung kommen sollen. Ein solcher Vorschlag wird basierend auf diesen Änderungen und den in der vorherigen Phase gesammelten testfallspezifischen Test-Impact-Daten erzeugt:

• Test-Selektion: Es werden alle Tests ausgewählt, die die gegebenen Änderungen durchlaufen. Diese Tests bezeichnen wir als „Impacted Tests“.

• Test-Priorisierung: Die Impacted Tests werden so sortiert, dass möglichst schnell Fehler gefunden werden. Um dies zu erreichen wollen wir die Tests so sortieren, dass möglichst schnell alle Änderungen überdeckt werden. Dieses Problem kann jedoch auf das Mengenüberdeckungsproblem reduziert werden, welches NP-vollständig ist. Daher verwenden wir einen heuristischen Greedy-Algorithmus, der Tests anhand ihrer zusätzlichen Coverage sortiert und in der Praxis auch bei großen Testmengen schnell genug ist.

Empirische Studie: Anwendbarkeit von Test-Impact-Analyse

In unserer empirischen Studie haben wir die Zuverlässigkeit und den Nutzen auf 12 Java-Systemen aus der Praxis quantifiziert. Die Studienobjekte unterscheiden sich in Größe, Historienlänge und Anzahl der Testfälle. Die kleinsten Systeme umfassen 7k LOC (System- und Testcode), die größten über 300k, die Historienlänge geht von 44 bis 82.164 Commits. Durch die starken Unterschiede zwischen den Systemen ist es unwahrscheinlich, dass ein systemspezifischer Einzeleffekt die Studienergebnisse dominiert. Eine detaillierte Übersicht der Studienobjekte findet sich in Bild 2.

TIA hat in der Praxis eine sehr hohe Zuverlässigkeit von 99,26% über alle Studienobjekte (im schlechtesten Einzelfall von 90,6%). Während die Einsparung bei Ausführung aller Impacted Tests zwischen den Systemen stark schwankt, ist die Verkürzung der Testzeiten bis zur Aufdeckung des ersten Fehlers über alle Systeme hinweg sehr deutlich.

Das größte Potential von TIA ist daher die Verkürzung des Zeitraums zwischen Start eines Testlaufs und Aufdeckung des ersten Fehlers. Bei nur 1% Testlaufzeit deckt TIA im Mittel (und im Median) in über 80% der Fälle, bei 2% Testlaufzeit in über 90% der Fälle auf, dass die untersuchte Systemversion fehlerhaft ist.

Anders ausgedrückt kann die Testlaufzeit um 98% verkürzt werden und trotzdem werden nur in 10% der Fälle fehlerhafte Builds nicht als solche erkannt. Gerade für Systeme, deren Tests so lange laufen, dass sie überhaupt nicht im Rahmen der Continuous Integration ausgeführt werden, stellt das eine substantielle Verbesserung dar, da nun 90% aller Fehler im Rahmen der CI erkannt werden, und nicht erst in späten Testphasen aufgedeckt werden, die ggf. Monate später stattfinden.

Da TIA nicht alle Fehler aufdeckt, müssen in regelmäßigen Abständen nach wie vor alle Tests ausgeführt werden. Da die meisten Fehler allerdings bereits im Rahmen der CI aufgedeckt werden, sollten bei der Ausführung aller Tests vergleichsweise weniger Fehler auftreten. Dadurch sollte auch der zusätzliche Aufwand, der durch die Verzögerung und die Überlagerung von Fehlern auftritt, vergleichsweise geringer sein.

Automatisierte Softwaretests in einer Continuous-Delivery-Pipeline

‚Shift Left‘: Wie man Performance-Tests in der Software-Entwicklung vorverlegt

Statische Code-Analyse in Continuous-Integration und -Deployment-Prozessen

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2019 entnommen.)

Der Autor

Dr. Elmar Juergens hat für seine Doktorarbeit über Qualitätsanalyse den Software-Engineering-Preis der Ernst Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH, spricht regelmäßig auf internationalen Konferenzen und wurde zum Junior Fellow der Gesellschaft für Informatik ernannt.

(ID:46417054)