Since this post accompanies a talk in German, it is written in German, too.

Koordinaten

• Sprecher: Dr. Stefan Staudt (TRUMPF), Dr. Elmar Jürgens (CQSE)
• Konferenz: Saec Days 2020
• Datum: 22. Juli 2020, 12:10-12:55 Uhr
• Raum: Rom
• ID: Mi1.2

Zusammenfassung

Im Test möchten wir Fehler finden, bevor diese in Produktion gelangen. Trotzdem gelingt dies nicht immer zu 100 Prozent. Studien zeigen, dass das Risiko für Fehler in den Bereichen eines Softwaresystems besonders hoch ist, die seit dem letzten Release geändert, aber nicht im Test ausgeführt wurden.

Die Test-Gap-Analyse kombiniert statische und dynamische Verfahren, um bereits während der Entwicklung genau diese Bereiche zu identifizieren und so frühzeitig und kontinuierlich Feedback an Entwickler und Tester zu liefern. In diesem Vortrag gibt Dr. Elmar Jürgens (CQSE GmbH) einen allgemeinen Überblick über die Test-Gap-Analyse und zeigt verschiedene Einsatzszenarien auf, die das von der CQSE entwickelte Werkzeug Teamscale unterstützt. Dr. Stefan Staudt (TRUMPF Werkzeugmaschinen GmbH + Co. KG) gibt einen Einblick in die Hintergründe zur Einführung der Test-Gap-Analyse bei TRUMPF und berichtet von Erfahrungen bei deren Einsatz insbesondere auch im Hinblick auf die Instrumentierung von C++-Anwendungen, um die Testausführung zu messen.

Nach positiven Erfahrungen mit der Test-Gap-Analyse im .NET-Umfeld sollte diese Analyse auch für ein bei TRUMPF entwickeltes bereits Jahrzehnte existierendes CAD/CAM-System (Sprache C++, ca. 4,2 MLOC) eingesetzt werden. Hierfür bietet Teamscale mit der Test-Gap-Analyse eine große Hilfestellung, da es die Möglichkeit bietet Abdeckung einzelner Tests festzustellen sowie Differenzanalysen unterstützt, um damit die Testabdeckung von neuem und geändertem Code zu bestimmen. Dieser Projektteil ist also ziemlich schnell zu erledigen (was sich auch bewahrheitete).

Als größere Herausforderung erwies sich das Gewinnen der Coverageinformationen an sich: verschiedene auch teils bewährte Tools wie Microsoft-Profilerstellungstools und die Microsoft Dynamic Coverage Tools als Nachfolger sowie Opensourcetools wie OpenCoverage führten nicht zum erwünschten Erfolg. Entweder waren die Coverageinformation nicht gewinnbar bzw. trotz hoffnungsvollem Start schlicht und ergreifend falsch.

Andererseits mussten massivste Perfomanceeinbußen (teilweise Verlangsamung um den Faktor 10!!!) in Kauf genommen werden, aber es gelang hierbei wenigstens korrekte Coverageinformation zu erhalten. Da die Auswahl zwischen schnellen falschen und unperformanten richtigen Ergebnisse zwar nicht toll aber relativ einfach zu entscheiden ist, war wenigstens ein gangbarer Weg verfügbar. Um einen Ausweg zu finden, wurde zusätzlich ein anderer Ansatz versucht. Instrumentierung des Codes vor dem Kompilieren durch BullseyeCoverage. Hierbei dauert zwar das Kompilieren ca. doppelt so lange, aber da dies nur einmal erfolgen muss, ist das verschmerzbar. Die Performanceeinbußen bewegen sich mit ca. Faktor 1,5 ebenfalls im vertretbaren Rahmen.

Als die Ergebnisse in Teamscale importiert werden konnten und plausibel aussahen, konnten auch die Irritationen der Kollegen auf Grund der Jubelschreie leicht verschmerzt werden. Als nächste Schritte wurden der Ablauf automatisiert und in den täglichen Softwareerstellungsprozess eingebunden, um eine zeitnahe Auswertung über neue und geänderte Methoden zu erhalten, die nicht bei den Tests durchlaufen wurden.

Folien