IT-Sicherheit in Produktion und Technik
12.09.17 - 13.09.17
In Berlin

Be CIO: IT Management im digitalen Wandel
13.09.17 - 13.09.17
In Köln

IBC 2017
14.09.17 - 18.09.17
In Amsterdam

Orbit IT-Forum: Auf dem Weg zum Arbeitsplatz der Zukunft
27.09.17 - 27.09.17
In Leverkusen

it-sa 2017
10.10.17 - 12.10.17
In Nürnberg

TestSoftwarequalität ist kein Bonus-Feature und keine Luxus-Option. Softwarehersteller mussten lernen, dass eine hohe Code-Qualität unabdingbar ist, um sich von der Konkurrenz ab- und im Markt durchzusetzen. Um Code zu testen und die Qualität sicherzustellen, existieren unterschiedliche Methoden; viele Unternehmen nutzen heute vor allem die statische Analyse, um Fehler bereits in den frühen Stadien der Entwicklung festzustellen.

VDC Research, ein Analystenhaus im Embedded- Markt, hat in der letzten Zeit verschiedene Reports veröffentlicht, die alle darauf hinweisen, dass besonders jene Unternehmen stark wachsen, die auf statische Analyse als wichtiges Werkzeug zur Testautomatisierung setzen.

Einer der Gründe für dieses Wachstum ist die fortgeschrittene Reife der Technologie, was die Identifikation kritischer Defekte anbelangt. Sehr viele schwer zu entdeckende Fehler, die Funktionen und Dateigrenzen überschreiten, können heutzutage sehr gut ausfindig gemacht werden. Die echte Innovation liegt darin, dass diese neuen Werkzeuge weniger False Positives produzieren und zugleich zu jedem gefundenen Fehler den nötigen Kontext liefern. Jede Fehlermeldung soll dadurch erklären, warum dieser Fehler aufgetreten ist, welche Auswirkungen er haben könnte und wie man diesen am besten behebt.

„Defekte stammen oft aus mehreren Orten im Quellcode und durch Branching, Code Merging, Versionierung und die Wiederverwendung von Codeteilen kann sich jeder Fehler in verschiedenen Versionen und Produkten festsetzen.“
Jon Jarboe, Coverity

Die Frage nach dem „Wo“ ist mit Dateiname und Zeilennummer alleine noch nicht beantwortet. Defekte stammen oft aus mehreren Orten im Quellcode und durch Branching, Code Merging, Versionierung und die Wiederverwendung von Codeteilen kann sich jeder Fehler in verschiedenen Versionen und Produkten festsetzen.


Vielfalt bringt Komplexität bringt Fehler


Stellen Sie sich ein Team von Softwareentwicklern vor, das ein Betriebssystem für Mobilgeräte entwickeln soll. Das System muss verschiedene Gerätehersteller unterstützen; durchaus möglich, dass daraus für jeden Hersteller ein Entwicklungszweig folgt. Jeder Anbieter hat typischerweise mehrere Geräte, diese wiederum als verschiedene Releases und Produktgenerationen. Mehr und mehr Verzweigungen lassen die Komplexität schnell anwachsen.

Statische Analyse kann in jedem Code-Zweig eingesetzt werden und produziert jeweils eine Liste an entdeckten Fehlern. Je nachdem, wann ein Fehler zuerst auftritt, kann er in einem, mehreren oder in vielen Zweigen sitzen. Die Herausforderung für die Entwickler ist es, die Sammlung entdeckter Fehler zu priorisieren. Ein Fehler, der viele Versionen, Produkte oder Hersteller beeinträchtigt, könnte in der Wichtigkeit über Fehlern stehen, die weniger ausrichten können. Außerdem muss der Entwickler exakt wissen, in welchen Zweigen er etwas zu reparieren hat. Erst Analyseergebnisse, die akkurate Informationen liefern – betroffene Funktionen, Dateien, Projekte und Code- Zweige – helfen dem Entwickler, den Fehler zu verstehen und schnell zu beseitigen. 

Der Trend hin zu entwicklungsseitigen Testmethoden wie die statische Analyse ist ein positiver Trend der Softwareindustrie. Dennoch ist sie nur einer von vielen Faktoren, der für Softwarequalität sorgt. Um ein vollständigeres Bild der Software zu bekommen, ist es wichtig, statische Analyse mit funktionalem Testing zu kombinieren.


Tests managen


Statische Analyse leistet ihren Anteil bei syntaktischen, semantischen oder Formatproblemen; sie sorgt aber nicht wirklich dafür, dass der Code die funktionalen Anforderungen erfüllt. Hierfür schreiben Entwickler Testfälle, die als Teil einer Validierungssuite ausgeführt werden. Diese Tests sind offensichtlich wichtig, aber wie effektiv sind sie wirklich?

Viele Unternehmen messen Code- Abdeckung mit einem Tool wie Cobertura, um die Lückenlosigkeit ihrer Tests zu prüfen. Obwohl die Abdeckung eine nützliche statistische Größe ist, reicht sie als Messgröße für die Effektivität nicht aus. Es scheint, dass Entwickler oft zu viel Zeit darauf verwenden, Tests zu schreiben, die die Abdeckung erhöhen, ohne die Qualität merklich zu steigern. Es braucht also etwas, das die Effektivität von Tests messen kann; etwas, das Tests hervorbringt, die spürbare Qualität liefern. Das Grundproblem mit der Abdeckung ist, dass sie nur wiedergibt, wie viel Code die Tests ausgeführt haben. Effektivität dagegen ist ein breiteres Konzept, das auch den Wert der Untersuchung verschiedener Teile der Code-Basis beinhaltet.

Die Testabdeckung spezifischer Assemblierungen, Klassen oder Methoden zu messen, kann helfen. Häufig machen es aber uninteressante oder untestbare Teile des Code extrem schwierig, ein konsistentes Abdeckungsziel zu schaffen. 100 Prozent Abdeckung bei einer einzigen Anwendung zu erreichen ist praktisch unmöglich. Aber wieviel Prozent sind ausreichend? 90 Prozent? 50 Prozent? Wie können Entwickler entscheiden, welche Tests weggelassen und welche hinzugenommen werden?


Auswahl der Tests entscheidend


Es mag beispielsweise nicht sinnvoll sein, einen Test zur Behandlung einer Out-of-Memory Situation zu entwickeln. Obwohl man diesen Code gerne testen würde, so würde man das Testbudget der Abteilung wahrscheinlich besser nutzen, indem man sich auf Tests konzentriert, die vielgenutzte Code- Pfade mit wichtiger, noch ungetesteter Funktionalität abdecken; oder solche Pfade, die schwerwiegende Auswirkungen haben könnten.

Hierbei kann das Testen während der Entwicklung Abhilfe schaffen. Analyse- Tools können Testentwicklern helfen, sich auf das Wesentliche zu fokussieren, indem sie Informationen über Abdeckung und andere Testparameter und -ziele sammeln. So können sie nicht nur herausfinden, welcher Code noch ungetestet ist – sondern sie können auch Regeln einsetzen, die automatisch die wichtigsten Code-Bereiche identifizieren und mögliche Änderungen oder Beeinträchtigungen sofort melden. Sie weisen auf Anschlusspfade hin, die nicht an Bedingungen geknüpft sind, und empfehlen, ob ein Test von Code mit Debug Handling, Fehleroder Ausnahmebehandlung überhaupt Sinn hat.


Nur neuen Code zu testen spart Zeit und Budget


So können Entwickler einfach messen, ob die Regeln zum Testen eingehalten werden oder nicht – was die Effektivität des gesamten Testverfahrens erhöht. Man kann sogar noch einen Schritt weiter gehen: Eine solche Lösung zum Development Testing kann die Testläufe optimieren. Da sie die letzten Code-Änderungen kennt, sowie deren Auswirkungen auf anderen Code und die Testabdeckung, kann sie Tests in der richtigen Reihenfolge ablaufen lassen – nämlich so, dass die Wahrscheinlichkeit steigt, Fehler schnell zu finden. Entwickler können die richtigen Tests zuerst laufen lassen, Funktionalitätsprobleme schnell erkennen und überflüssige oder falsche Tests vermeiden.

Vor allem Projekte mit großen Mengen ungetestetem Legacy-Code profitieren von diesen Funktionen: Das Datum der letzten Änderung hilft dabei, den Fokus auf neuen Code zu legen, statt Tests für erprobten Legacy-Code laufen lassen zu müssen. Bei einer Legacy-Anwendung können sich Tester ans Unit Testing gewöhnen, wenn sie eine Regel aufstellen, nach der sich die Testentwicklung auf diejenigen Bereiche konzentriert, die von aktuellen Code-Änderungen betroffen sind.

„Der Trend hin zu entwicklungsseitigen Testmethoden wie die statische Analyse ist ein positiver Trend der Softwareindustrie. Um aber ein vollständiges Bild der Software zu bekommen, ist es wichtig, statische Analyse mit funktionalem Testing zu kombinieren.“
Jon Jarboe, Coverity

Am Ende sollte eine Lösung für Development Testing auf einer breiten Basis an Code Intelligence aufbauen. Die Lösung sollte diese Basis nutzen, um Probleme zu identifizieren, mit denen Entwickler viel zu tun haben – ob das nun Syntaxfehler, semantische oder Formatfehler sind, Verstöße gegen Testregeln oder andere Arten von Problemen, die andere Tools entdecken. Eine gute Lösung muss die vorhandenen Daten aus den Analyse-Tools in Gesamtdatenbestand überführen, und einen brauchbaren Workflow für Entwickler bieten, um sicherzustellen, dass sie Fehler schnell und akkurat beseitigen können.


Beides statt Entweder/Oder


Setzen Entwickler beim Testen von Entwicklungen auf einen integrierten Ansatz, der sowohl die statische Analyse als auch das funktionale Testen umfasst, haben sie bessere Möglichkeiten, qualitativ hochwertige Software zu schaffen. Sich nur auf einen der beiden Bereiche zu konzentrieren, ist nicht ratsam. Fehler müssen sich auf mehreren Ebenen und über einen längeren Zeitraum hinweg beheben lassen, um sauberen Code zu generieren. Dies ist wiederum nur mithilfe eines umfassenden Testansatzes möglich.

Wer Zuverlässigkeit schaffen will, braucht Werkzeuge, die sich an die Unternehmenskultur und vorhandene Workflows anpassen und gleichzeitig die Nutzung neuer Testmethoden ermöglichen. Denn nur wenn Entwickler ohne Störung während der Entwicklungsphase Fehler finden und beheben können, können sie hinterher die Verantwortung für etwaige Verstöße übernehmen, wenn die Software ausgeliefert wird. Hersteller können einen soliden Grundstock schaffen und dann eine Regel einführen, die neue Fehler verbietet. So erhält der Entwickler die Verantwortung für künftige Code-Unregelmäßigkeiten.

Um besagte Schritte in die Tat umzusetzen, müssen Fehler nicht nur durch statische Tests und Analysen aufdecken, sondern auch durchgehend verwaltet und verfolgt werden können. Dies ist jedoch enorm schwierig. Selbst die erfahrensten Entwickler schaffen dies nicht allein. Sie brauchen hierfür Tools, die oberflächliche Schwachstellen erkennen und beheben können und gleichzeitig Probleme je nach Dringlichkeit priorisieren. Ein derartiger Ansatz für das Qualitätsmanagement ist für Unternehmen, die ihre Software langfristig erfolgreich einsetzen wollen, essentiell.

Jon Jarboe

Artikel aus it management Juni 2014

Dieses Webinar könnte Sie ebenfalls interessieren:

Erfahrungen über die Test-Automatisierung in der agilen Entwicklung

Über seine Erfahrungen aus 3 Jahren Testautomatisierung in der Entwicklung spricht Dr. Andreas Kühlmann, Coverity, in diesem Webinar Zu den Lektionen, die er lernen musste, gehört u.a. die kontinuierliche Anpassung der Testautomatisierung an Software-Änderungen.

Termin: Dienstag, 30.09.2014, um 16:00 Uhr
Dauer: 60 Minuten
Sprecher: Dr. Andreas Kühlmann, Senior Vice President für Forschung und Entwicklung bei Coverity 

Info & Anmeldung:

https://attendee.gotowebinar.com/register/8823102885664079617

Frische IT-News gefällig?
IT Newsletter Hier bestellen:

Newsletter IT-Management
Strategien verfeinert mit profunden Beiträgen und frischen Analysen

Newsletter IT-Security
Pikante Fachartikel gewürzt mit Shortnews in Whitepaper-Bouquet