Autor: Ingo Nickles, Vector Software<\/p>\n
In der modernen Softwareentwicklung gilt es, neue Funktionalit\u00e4ten in immer k\u00fcrzeren Zeitabst\u00e4nden zu implementieren. Der Quellcode wird immer umfangreicher und komplexer, dennoch wird erwartet, dass die Software Qualit\u00e4t gleich bleibt oder sich sogar noch verbessert. Die gr\u00f6\u00dfte Herausforderung ist sicherlich, Release-Zyklen zuverl\u00e4ssig vorherzusagen und einzuhalten. Oft werden Aufw\u00e4nde falsch eingesch\u00e4tzt und Ressourcen ung\u00fcnstig verteilt, denn die Projektleiter wissen h\u00e4ufig nicht genau, welche Code\u00e4nderungen welche Ressourcen ben\u00f6tigen.<\/strong><\/p>\n Nat\u00fcrlich tragen im Software-Entwicklungsprozess viele Dinge zur Software-Qualit\u00e4t bei. Neben einem funktionierenden Anforderungsmanagement sind dies z.B. eine entsprechende Software-Architektur und ein gutes Design. Nichts desto trotz wird die Software-Qualit\u00e4t aber am Ende im Testprozess gemessen bzw. nachgewiesen, und so ist es durchaus sinnvoll, sowohl den Testprozess als solches, als auch die sich daraus ergebenden Metriken n\u00e4her zu beleuchten.<\/p>\n Durch kontinuierliches Testen, sowie die kontinuierliche Integration von Code\u00e4nderungen und angepassten Testf\u00e4llen ins Configuration Management k\u00f6nnen h\u00e4ufig auftretende Terminverz\u00fcge vermieden werden. \u00c4nderungsbasiertes Ausf\u00fchren der Testf\u00e4lle erlaubt es jedem Entwickler, automatisiert alle Arten von Testf\u00e4llen auszuf\u00fchren, die von deiner Code\u00e4nderung betroffen sind.<\/p>\n Konsistente und nachvollziehbare Metriken k\u00f6nnen wichtige Hinweise auf den momentanen Entwicklungsstand, den Entwicklungsverlauf und den aktuellen Testfortschritt liefern. Durch Kenntnis dieser Daten ist es m\u00f6glich, einen sehr genauen \u00dcberblick \u00fcber den momentanen Projektstatus und die Software-Qualit\u00e4t zu erhalten. Dadurch l\u00e4sst sich ein m\u00f6glicher Release-Zeitpunkt genauer vorhersagen. Ebenso ist es zu jeder Zeit m\u00f6glich, eventuelle Engp\u00e4sse zu erkennen und Ressourcen besser zu planen.<\/p>\n Betrachtet man die Entwicklung von Software (SW)- zu Hardware (HW)-Anteilen in Produkten, so ist ein deutlicher Trend zu mehr SW erkennbar. SW wird mehr und mehr zum „Differentiator“ – zu dem, was den Unterschied zwischen den Produkten zweier Hersteller und damit den Wettbewerbsvorteil ausmacht. Dadurch, dass mehr Funktionalit\u00e4t in die SW wandert, wird diese nat\u00fcrlich immer komplexer – aber auch wichtiger f\u00fcr den Produkthersteller. Eine hohe Produktqualit\u00e4t h\u00e4ngt immer mehr auch von fehlerfreier Software ab. Durch Einf\u00fchrung entsprechender Entwicklungsrichtlinien, kann die Implementierung von Fehlern ins Produkt sicherlich vermindert werden – dennoch kann und darf man auf einen ausf\u00fchrlichen Testprozess nicht verzichten. Betrachten wir also den Testprozess innerhalb eines Entwicklungsprozesses etwas genauer.<\/p>\n Der wohl verbreiteste Entwicklungsprozess ist das V-Modell (siehe Abb. 1,\u00a0PDF<\/a>), das aufgeteilt ist in drei Phasen:<\/p>\n Obwohl im V-Modell die Testphase an das Ende des Entwicklungszyklus gestellt ist, hat man bald erkannt, dass es durchaus sinnvoll ist, sehr viel fr\u00fcher mit dem Testen zu beginnen, denn je fr\u00fcher ein Fehler gefunden wird, desto g\u00fcnstiger ist dessen Beseitigung.<\/p>\n Im klassischen V-Modell versucht man dieser Tatsache dadurch Rechnung zu tragen, dass man die kleinste isolierbarste Einheit der Software, sobald verf\u00fcgbar, auf Herz und Nieren testet: eine Unit bzw. ein einzelnes Source File. Nachdem das einzelne File bzw. die darin implementierten Funktionen alle Tests \u00fcberstanden haben, fasst man mehrere Files zusammen und \u00fcberpr\u00fcft deren Zusammenspiel im Integrationstest. Im Systemtest wird schlie\u00dflich die gesamte Software getestet. Betrachten wir also die „rechte Seite“ des V-Modells genauer (siehe\u00a0PDF<\/a>).<\/p>\n Eine zentrale Rolle im Test kommt der Automation zu. Das manuelle Wiederholen immer gleicher Testabl\u00e4ufe ist einem Menschen nicht zuzumuten, weshalb Test-Automation nicht nur der Mitarbeiterzufriedenheit dient, sondern auch dazu beitr\u00e4gt, dass Tests auch wirklich ausgef\u00fchrt werden. Daher sollte bei der Bildung der Test-Landschaft darauf geachtet werden, dass alles, was automatisierbar ist, auch automatisiert wird. Denn nur so ist ein vern\u00fcnftiger Regressionstest realisierbar.<\/p>\n Am Ende eines V-Entwicklungsprozesses steht eine gut getestete und qualitativ hochwertige Software. Wenn damit die M\u00f6glichkeiten einer SW-\u00c4nderung an Ihrem Produkt enden, weil Sie es z.B. zum Mars schie\u00dfen, spielt f\u00fcr Sie der Regressionstest keine gro\u00dfe Rolle. Aber auch dann, wenn Sie keine M\u00f6glichkeiten von Software\u00e4nderungen am fertigen Produkt haben, kann sich schon aus dem Einsatz eines anderen Entwicklungsmodells die Notwendigkeit eines Regressionstests ergeben. Z.B. erfordern agile Entwicklungsmethoden ein kontinuierlich erneutes Ausf\u00fchren der bereits vorhandenen Testf\u00e4lle. Weitere Gr\u00fcnde f\u00fcr SW-\u00c4nderungen und damit ein Wiederholen aller Tests k\u00f6nnen sein:<\/p>\n Tats\u00e4chlich haben Untersuchungen z.B. von der FDA (Food and Drug Administration, USA) ergeben, dass ein Gro\u00dfteil (79%) von SW-Fehlern, die zu einem Produktr\u00fcckruf gef\u00fchrt haben, nachtr\u00e4glich durch Code\u00e4nderungen ins fertige Produkt eingef\u00fchrt wurden[1]<\/sup>. Code\u00e4nderungen, deren Auswirkungen auf die SW-Qualit\u00e4t durch einen entsprechenden Regressionstest h\u00e4tten entdeckt werden k\u00f6nnen.<\/p>\n Betrachtet man die Anzahl der Testumgebungen, die in einem empfohlenen Entwicklungsprozess in einem Projekt entstehen, so kommt einiges zusammen:<\/p>\n Hinzu kommt, dass es in der Regel mehr als eine Konfiguration gibt, in der alle Testumgebungen ausgef\u00fchrt werden sollten. So ist es z.B. offensichtlich sinnvoll und von verschiedenen Standards auch gefordert, die Tests auf dem sp\u00e4teren Zielsystem bzw. einem entsprechenden Board auszuf\u00fchren. Nun findet ein Unit-Test in der Regel aber sehr fr\u00fch im Entwicklungsprozess statt. Ein Board zur Ausf\u00fchrung der Unit-Tests ist aber m\u00f6glicherweise selbst Teil des zu entwickelnden Produkts und steht dementsprechend nocht nicht f\u00fcr eine Ausf\u00fchrung von SW-Tests zur Verf\u00fcgung.<\/p>\n Aber auch bei vorhandener HW kann es sinnvoll sein, die echte HW zu meiden. Z.B. wird \u00fcblicherweise die Test-Applikation auf die HW „ge-flashed“ und die Anzahl der von der HW unterst\u00fctzten Flashzyklen ist dabei begrenzt. Um einen \u00fcberm\u00e4\u00dfigen Verschlei\u00df an HW zu vermeiden, kann man also auf Simulatoren oder Emulatoren umsteigen. Dies macht auch das Ausf\u00fchren von Testf\u00e4llen schneller, was der Ungeduld des Testers beim Erstellen der Testf\u00e4lle entgegenkommt.<\/p>\n Beim Nichtvorhandensein von Simulatoren kann es auch sinnvoll sein, eine Testumgebung auf den Host aufzusetzen. Nat\u00fcrlich ist dies mit gr\u00f6\u00dferem Aufwand bei der Testumgebungserstellung verbunden: Cross-Compiler-spezifische Keywords m\u00fcssen „weg-definiert“ werden, um den Code mit einem Host-Compiler kompilieren zu k\u00f6nnen. Hardware-Zugriffe m\u00fcssen „weg-gestubbt“ bzw. durch das Einbinden anderer Header Files ausgetauscht werden. Nichtsdestotrotz macht sich dieser intitiale Aufwand sp\u00e4ter bezahlt durch verschiedene Vorteile: schnellere Testfallerstellung, Schonen der HW-Ressourcen und nicht zuletzt ein \u00dcberpr\u00fcfen der Software in einem weiteren Testumfeld (anderer Compiler, anderes Betriebssystem). So wird Ihnen Windows z.B. einen „Segmentation Violation Error“ beim Zugriff auf invalide Pointer liefern, w\u00e4hrend der gleiche Testfall auf Ihrem RTOS im schlimmsten Fall sauber durchl\u00e4uft.<\/p>\n Last but not least wird SW h\u00e4ufig in mehr als einer Konfiguration an sp\u00e4tere Kunden \u00fcbergeben. Z.B. kann es verschiedene Ausbaustufen Ihres Produkts geben, die auf unterschiedlichen Boards laufen. Oft werden auch Funktionalit\u00e4ten in der SW per Compile-Defines an- bzw. ausgeschaltet. Oder zentrale Teile der Software laufen in komplett unterschiedlichen Produkten.<\/p>\n Was bedeutet das jetzt f\u00fcr die Anzahl der Testumgebungen? (siehe Abb. 2,\u00a0PDF<\/a>)<\/p>\n Anzahl der Testumgebungen\u00a0 = Die „Compile-Define-Kombinationen“, in denen Ihr Produkt schlie\u00dflich ausgeliefert wird, ist sinnvollerweise definiert, sodass die Anzahl bekannt ist. Ist dies nicht der Fall, da sich z.B. Kunden baukastenartig ihr Produkt zusammenstellen k\u00f6nnen, kann es sinnvoll sein, nach Bekanntwerden der Kundenanforderung s\u00e4mliche Testf\u00e4lle nochmals in der geforderten Konfiguration durchzuf\u00fchren.<\/p>\n Obige Formel erhebt keinen Anspruch auf Vollst\u00e4ndigkeit, und in Ihrem Umfeld mag ein Faktor oder ein Summand hinzukommen oder wegfallen. Es soll lediglich verdeutlicht werden, dass es „eigentlich“ nicht ausreicht, Testf\u00e4lle in nur einer Testumgebungskonfiguration durchzuf\u00fchren. Prinzipiell sollten alle Testarten\u00a0 (also Unit-, Integration-, und System-Tests) in allen m\u00f6glichen Konfigurationen durchgef\u00fchrt werden. Oder w\u00fcrden Sie in einem Flugzeug sitzen wollen, dessen SW nur auf dem Host getestet wurde? Oder die Bremsassistenz Ihres Fahrzeugs einem St\u00fcck SW \u00fcberlassen, das in dieser Compile-Define-Kombination auf diesem Board noch nie getestet wurde?<\/p>\n Nicht selten wird behauptet, dass in Testen in allen Kombinationen schlicht unm\u00f6glich sei. Durch Test-Automation und entsprechenden Optimierungs-Algorithmen wird die Menge an entstehenden Testf\u00e4llen aber beherrschbar, und notfalls muss die Varianz beim Kunden reduziert werden. Flexibilit\u00e4t darf nicht zu Lasten der SW-Qualit\u00e4t gehen.<\/p>\n Die zuletzt dargestellte Anzahl an Testf\u00e4llen f\u00fchrt nat\u00fcrlich zu einem Dilemma. Wie sollen immer k\u00fcrzere Produkt-Release-Zyklen realisiert werden, und wie soll ein Software-Entwickler „sauberen“ Code liefern, wenn das Ausf\u00fchren aller Testf\u00e4lle zwei Monate dauert? Stand der Technik ist es zurzeit, dass ein pragmatischer Ansatz verfolgt wird. Bei Code\u00e4nderungen werden alle Unit-Tests des ge\u00e4nderten Files in einer Konfiguration ausgef\u00fchrt, bevor die \u00c4nderung in die Code-Basis eingecheckt wird. Integrations-Tests werden sporadisch, z.B. einmal pro Woche, ausgef\u00fchrt und Systemtests z.B. nur alle zwei Monate. Das hat zur Folge, dass Fehler, die im Systemtest auffallen, ihre Ursache in einer Code\u00e4nderung haben, die eventuell vor zwei Monaten eingecheckt wurde. Neben dem zus\u00e4tzlichen Aufwand, der dadurch entsteht, dass zun\u00e4chst der Verursacher des Fehlers eruiert werden muss, ben\u00f6tigt dieser dann mehr Zeit, den Fehler zu korrigieren, als wenn er direkt am Tage der Code\u00e4nderung auf das Problem aufmerksam gemacht worden w\u00e4re.<\/p>\n Ziel muss es also sein, dass jede Code\u00e4nderung m\u00f6glichst zeitnah \u00fcberpr\u00fcft wird. Und zwar in allen Konfigurationen und in allen Test-Ebenen (Unit-, Integration-, System-Test). Um diesem Ziel n\u00e4her zu kommen, kann die Test-Landschaft zun\u00e4chst einmal dahingehend optimiert werden, dass das Ausf\u00fchren von Tests parallelisiert wird. Automatisierbare Tests k\u00f6nnen dann durch die Bereitstellung einer entsprechenden Anzahl von Test-Servern in sehr viel k\u00fcrzeren Zeitabschnitten durchlaufen werden. Manuelle Tests gilt es soweit wie m\u00f6glich zu reduzieren. Es ist tats\u00e4chlich nicht vertretbar, gleiche Tests in 300 verschiedenen Konfigurationen manuell durchzuf\u00fchren, wenn dies auch automatisiert m\u00f6glich w\u00e4re.<\/p>\n Neben einer Parallelisierung der Testaktivit\u00e4ten kann die Testausf\u00fchrungsdauer zus\u00e4tzlich durch eine intelligente Auswahl der Testf\u00e4lle drastisch reduziert werden. Zun\u00e4chst einmal ist es offensichtlich, dass von einer Source-Code-\u00c4nderung nur Testumgebungen betroffen sind, in denen das ge\u00e4nderte File vorhanden ist. Durch eine intelligente Auswahl (siehe Abb. 3,\u00a0PDF<\/a>) kann die Menge an durchzuf\u00fchrenden Tests aber auch dadurch reduziert werden, dass nur die Testf\u00e4lle innerhalb der betroffenen Testumgebungen erneut ausgef\u00fchrt werden, die von der Source-Code-\u00c4nderung betroffen sind. Insbesondere im Systemtest, der dadurch, dass \u00fcblicherweise alle Files zusammen getestet werden und der somit von jeder Code\u00e4nderung betroffen ist, kann durch eine intelligente Testfall-Auswahl ein erheblicher Aufwand eingespart werden.<\/p>\n Professionelle SW-Entwicklung arbeitet heute mit einem zentralen Configuration Management der Software. Zentral wird zum Beispiel auf einem Build Server eine Basisversion der Software gehalten. Entwickler k\u00f6nnen lokale Kopien der Basis erstellen, lokal \u00c4nderungen am Code durchf\u00fchren und diese dann wieder in die Basis einchecken. Das zentrale Management der Software hat verschiedene Vorteile (siehe Abb. 4,\u00a0PDF<\/a>):<\/p>\n Probleme k\u00f6nnen dann entstehen, wenn das Einchecken der lokalen Kopien in zu gro\u00dfen Abst\u00e4nden erfolgt. Dies hat oft zur Folge, dass auch der Test der Code\u00e4nderungen erst sehr sp\u00e4t erfolgt, denn \u00fcblicherweise ist ein Software-Entwickler nicht in der Lage, alle relevanten Testf\u00e4lle ausf\u00fchren zu k\u00f6nnen. Dar\u00fcber hinaus wird durch das verz\u00f6gerte „Mergen“ mit der Basis die Wahrscheinlichkeit eines Merge-Konflikts oder sogar einer Inkompatibilit\u00e4t des einzucheckenden Codes gr\u00f6\u00dfer. Eine optimierte Software-Entwicklung sollte daher …<\/p>\n Das Ziel muss es sein, die Basis-SW kontinuierlich in einem lauff\u00e4higen Zustand zu halten. Jede Code\u00e4nderung erfordert \u00fcblicherweise auch eine Anpassung der Testfall-Daten, sodass diese im Zuge der Code\u00e4nderung mit ge\u00e4ndert und eingecheckt werden sollten.<\/p>\n Ein nicht zu untersch\u00e4tzender Aspekt bei der Verbesserung eines Prozesses ist das Messen des Ist-Zustands. Leider wird dieses Messen allzuoft auch mit einem Kontrollieren der beteiligten Personen gleichgesetzt und daher h\u00e4ufig abgelehnt. Auch werden Metriken gerne als „Manager-Spielzeug ohne Mehrwert“ abgetan. Aber tats\u00e4chlich k\u00f6nnen Metriken auf allen Ebenen dabei helfen, Prozesse zu verbessern oder Abl\u00e4ufe zu optimieren. Zielsetzung der Bereitstellung von Metriken sollte also immer sein, jedem Mitarbeiter transparent die Zahlen zug\u00e4nglich und deren Nutzen plausibel zu machen.<\/p>\n Auch die Automobilindustrie misst der Bedeutung von Metriken eine immer gr\u00f6\u00dfere Bedeutung zu. So hat der Arbeitskreis Softwaretest der Herstellerinitiative Software (HIS, bestehend aus den Automobilherstellern Audi, BMW Group, DaimlerChrysler, Porsche und Volkswagen) eine Empfehlung von relevanten Metriken (HIS-Metriken) inklusiver akzeptabler Obergrenzen der jeweiligen Werte herausgegeben[4]<\/sup>.<\/p>\n Betrachten wir zun\u00e4chst relevante Messdaten im SW-Entwicklungs- und Testprozess:<\/p>\n In Bezug auf den Quellcode:<\/strong><\/p>\n Statische Code-Analyse:<\/strong><\/p>\n In Bezug auf dynamische Testf\u00e4lle:<\/p>\n Code Coverage:<\/strong><\/p>\n In Bezug auf Requirements:<\/strong><\/p>\n In Bezug auf Code\u00e4nderungen:<\/strong><\/p>\n <\/p>\n Fragen, die diese Metriken beantworten sollen, sind zum Beispiel:<\/strong><\/p>\n Die Kunst bei der Darstellung von Metriken ist es, die Zahlen in einer wahrnehmbaren Art zu pr\u00e4sentieren, ohne dabei Problemstellen im statistischen Rauschen untergehen zu lassen. So ist z.B. eine durchschnittliche zyklomatische Komplexit\u00e4t von 3,5 je Funktion ein guter Wert. Insgesamt ist aber vielleicht der eine Ausrei\u00dfer mit einem Wert von 158.<\/p>\n Um wirklich f\u00fcr jeden Entwicklungsprozess interessante Informationen zu liefern, ist es wichtig, die Metriken interaktiv zu pr\u00e4sentieren. D.h., der Benutzer muss in die Lage versetzt werden, die Daten angezeigt zu bekommen, die f\u00fcr ihn relevant sind. Au\u00dferdem sollte es m\u00f6glich sein, in einzelne Bereiche der SW tiefer hineinzublicken bzw. die Sicht mehr zu globalisieren.<\/p>\n Abbildung 5 (siehe\u00a0PDF<\/a>) zeigt ein Beispiel f\u00fcr die Darstellung von Metriken mit sowohl Durchschnittswerten als auch Ausrei\u00dfern.<\/p>\n Eine zus\u00e4tzliche Dimension l\u00e4sst sich in der Darstellung von Metriken durch die Verwendung von Farben erzielen. Der Mehrwert wird deutlich bei der Betrachtung von Abbildung 6 (siehe\u00a0PDF<\/a>), in der Code Coverage, also der Anteil des Quellcodes, der in dynamischen Softwaretests ausgef\u00fchrt wurde, farblich dargestellt ist. Die Gr\u00f6\u00dfe des Blicks gibt einen Hinweis auf die Codegr\u00f6\u00dfe (auf der linken Seite) bzw. die Komplexit\u00e4t des Codes (rechte Seite). In diesem Beispiel befindet sich ein gro\u00dfer roter Block oben links. Der Block repr\u00e4sentiert die Datei lvm.c, die nicht nur gro\u00df (im Sinne von „viele Statements“), sondern auch komplex und noch dazu schlecht getestet ist. Ein Hinweis f\u00fcr Tester, Test-Manager oder Projekt-Manager, dass noch ein gutes St\u00fcck Arbeit vor ihnen liegt.<\/p>\n Die zyklomatische Komplexit\u00e4t der Software ist ein nicht zu untersch\u00e4tzender Wert, der eine n\u00e4here Betrachtung lohnt. In der Luft- und Raumfahrt wird von den Zertifizierungsbeh\u00f6rden zum Beispiel eine Obergrenze von 10 festgelegt. Ebenso empfiehlt der HIS AK Softwaretest eine Obergrenze von 10[4]<\/sup>. Tats\u00e4chlich zeigen Erfahrungsberichte[3]<\/sup>, dass die Anzahl von „Abweichungen“ (unter einer Abweichung versteht man alles, was nach einem Review zu einer \u00c4nderung des Codes gef\u00fchrt hat, wie z.B. Typos, Bugs, fehlende Kommentare, Verst\u00f6\u00dfe gegen Coding Conventions …) im Code mit der zyklomatischen Komplexit\u00e4t steigt. Funktionen mit einer zyklomatischen Komplexit\u00e4t > 20 sollten generell vermieden werden, da diese sehr fehleranf\u00e4llig und schlecht wartbar sind.<\/p>\nEinf\u00fchrung<\/h2>\n
Softwaretest<\/h2>\n
\n
Regressionstest<\/h2>\n
\n
Testumgebungen<\/h2>\n
\n
\n1 Host Konfiguration
\n+ 1 Simulator Konfiguration
\n+ (Anzahl Boards * Anzahl Compile-Define-Kombinationen)<\/p>\n\u00c4nderungsbasiertes Testen<\/h2>\n
Configuration Management und Continuous Integration<\/h2>\n
\n
\n
Messen, Bewerten, Verbessern<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\nWie lange wird das dauern?<\/li>\n
\nWie lange dauert deren Ausf\u00fchrung?<\/li>\n<\/ul>\nBeispiele f\u00fcr Darstellungen von Metriken<\/h2>\n