Qualitätssicherung Development Testing – denn Softwarequalität geht vor

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Coverity Deutschland

Angesichts immer komplexerer Systeme sind heute Code-Analyse und Software-Tests bereits während der Produktentwicklung erforderlich. Das Stichwort heißt Development Testing.

Software ist in so gut wie allen Embedded-Systemen zu finden: medizinischen Geräten, Steuerungen und mobilen Geräte aller Art. Hinzu kommen neue Trends wie das Internet der Dinge (Internet of Things, IoT), Wearables und Smart Watches. Allein die Steuerungs-, Infotainment- und Assistenz-Systeme eines Pkw enthalten nach Angaben der Automobilhersteller mittlerweile mehr als 10 Millionen Zeilen Programmcode. Diese Zahl wird in den kommenden Jahren ansteigen, etwa durch Hybrid-Fahrzeuge mit einem Elektro- und Benzinmotor und entsprechend komplexen Motorsteuerungen.

Dazu kommt: Im Embedded-Bereich werden verstärkt Mehrkern-Prozessoren eingesetzt. Diese CPUs bieten eine hohe Rechenleistung bei niedrigem Energieverbrauch. Eine Besonderheit solcher CPUs ist, dass sie Prozesse parallel ausführen. Laut einer Umfrage des Fraunhofer-Instituts für Eingebettete Systeme und Kommunikationstechnik (ESK) unter Entwicklern von Software für Embedded-Systeme führt das zu Problemen – so mangelt es etwa an Tools für das Debugging von Code, der für Embedded-Multicore-Komponenten erstellt wird. Das gilt vor allem für Werkzeuge, die sporadische Fehler in hochverfügbaren Systemen identifizieren.

Der Mangel an Entwicklungs- und Debugging-Tools im Embedded-Bereich kann Unternehmen teuer zu stehen kommen. So belaufen sich alleine in den USA nach Angaben des National Institute of Standards & Technology (NIST) die Kosten durch schlechte Software auf 60 Milliarden US-Dollar pro Jahr. Um Software-Fehler zu vermeiden, setzten die meisten Unternehmen auf eine Qualitätssicherung (Quality Assurance, QA). Das Problem dabei: Die QA findet erst nach der Entwicklung der Software statt. Außerdem ist für die Qualitätsüberprüfung ein separates QA-Team zuständig.

Nun beginnt oft ein Ping-Pong-Spiel: Die QA entdeckt Fehler, die bereits während der Entwicklung hätten auffallen müssen und verweist das Produkt zurück in die Entwicklungsabteilung. Die bessert nach und legt das Ergebnis dem QA-Team erneut vor – und so weiter. Die Entwicklungskosten steigen und es ist kaum möglich, eine konkrete Zeitplanung zu erstellen.

Praxiserfahrungen zeigen, dass 80 Prozent der Entwicklungsbudgets für Fehlerreparaturen in einer späten Phase des Entwicklungs- und Prüfzyklus ausgegeben werden. Ein Fehler, der in dieser Phase gefunden wird, ist zehnmal so teuer, als wenn er beim Schreiben des Codes entdeckt und beseitigt würde. Noch teurer wird es, wenn der Fehler erst nach dem Release entdeckt wird. Dann steigen die Kosten auf das Dreißigfache. Etliche Rückrufe von Autoherstellern etwa sind auf Softwarefehler zurückzuführen.

Lösung: Bereits während der Entwicklung testen

Um die Kosten zu senken und die Qualität der Produkte frühzeitig sicherzustellen, sollte daher das Testen in den Entwicklungsprozess integriert werden. Dazu empfehlen sich automatisierte Tests. Sie analysieren beispielsweise automatisch Nightly Builds, identifizieren Fehler frühzeitig und zeigen Lösungen für diese Probleme direkt auf.

Statische Analysen lassen sich in jedem Code-Zweig einsetzen, etwa dann, wenn mehrere Varianten einer Embedded-Komponente für verschiedene Abnehmer erstellt werden. Die Analysen fassen die Fehler in einer Aufstellung zusammen. Der Entwickler weist daraufhin den Fehlern in dieser Sammlung Prioritätsstufen zu. Ein Fehler, der viele Produktversionen betrifft, erhält eine höhere Priorität als einer, der nur wenige Systeme tangiert. Außerdem muss der Entwickler wissen, in welchen Code-Zweigen er welche Bugs auszumerzen hat. Das erfordert Analyseergebnisse, die detaillierte Informationen liefern: über die betroffenen Funktionen, Dateien, Projekte und Code-Zweige.

Die statische Analyse ist aber nur die halbe Miete: Sie erkennt syntaktische oder semantische Probleme, aber nicht, ob der Code die funktionalen Anforderungen erfüllt. Zu diesem Zweck schreiben Entwickler Testfälle, die als Teil einer Validierungs-Suite ausgeführt werden. Solche Tests sollten mit der statischen Analyse kombiniert werden.

Im Rahmen von Tests messen viele Unternehmen die Code-Abdeckung mit Tools 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. Denn diese enthält auch den Wert der Untersuchung verschiedener Teile der Code-Basis. Die Testabdeckung spezifischer Assemblierungen, Klassen oder Methoden zu ermitteln, kann helfen. Oft machen es aber uninteressante oder nicht testbare Teile des Codes schwer, ein konsistentes Abdeckungsziel zu erreichen.

Die Auswahl der Tests ist entscheidend

So mag es beispielsweise nicht sinnvoll sein, einen Test zur Behandlung einer Out-of-Memory Situation zu entwickeln. Obwohl man diesen Code gerne testen würde, schöpfte man das Testbudget der Abteilung besser aus, indem man sich auf Tests konzentrierte, die vielgenutzte Code-Pfade mit wichtigen, noch ungetesteten Funktionen abdecken. Hier kann das Testen während der Entwicklung helfen. Analyse-Tools unterstützen Testentwickler dabei, sich auf das Wesentliche zu konzentrieren, indem sie Informationen über die Abdeckung und andere Testparameter und -ziele sammeln.

So können sie nicht nur herausfinden, welcher Code noch nicht getestet wurde, sondern Regeln einsetzen, die automatisch die wichtigsten Code-Bereiche identifizieren und mögliche Beeinträchtigungen melden. Sie weisen auf Anschlusspfade hin, die nicht an Bedingungen geknüpft sind, und empfehlen, ob ein Test von Code mit Debug Handling, Fehler- oder Ausnahmebehandlung Sinn ergibt.

So können Entwickler die Einhaltung der Test-Regeln überprüfen und die Effektivität des gesamten Testverfahrens erhöhen. Man kann sogar noch einen Schritt weiter gehen: Eine solche Lösung zum Development Testing kann die Testläufe optimieren. Denn sie kennt alle wichtigen Parameter, etwa die letzten Änderungen am Code, deren Auswirkungen und die Testabdeckung. Daher kann eine solche Lösung Tests in der richtigen Reihenfolge ablaufen lassen.

Letztlich sollte eine Lösung für das Development Testing auf eine breite Grundlage von Code Intelligence zurückgreifen und sie nutzen, um Probleme zu identifizieren, die Entwickler häufig beschäftigen: Syntaxfehler, semantische oder Formatfehler oder Verstöße gegen Testregeln. Eine gute Lösung muss zudem die vorhandenen Daten aus den Analyse-Tools in den Gesamtdatenbestand überführen und einen brauchbaren Workflow für Entwickler bieten.

Dieser Beitrag ist ursprünglich auf unserem Schwesterportal Elektronikpraxis.de erschienen.

* Richard Walker ist Marketing Director beim Tool-Spezialisten Coverity.

(ID:44418333)