Autoren: Dr. Stephan Gr\u00fcnfelder, Bernhard Peischl<\/p>\n
Seit einigen Jahren sind Werkzeuge zur automatischen Erzeugung von Unit-Testf\u00e4llen erh\u00e4ltlich. Diese erzeugen ohne jedes Wissen der korrekten Funktion der zu testenden Software Unit-Tests in kurzer Zeit. „Tests“ werden alleine auf Basis des existierenden Quellcodes erzeugt. Das Testwerkzeug zielt dabei auf Erzielen einer hohen strukturellen Testabdeckung ab. Eine v\u00f6llig andere Herangehensweise ist die Test-First-Strategie: Unit-Tests werden ausschlie\u00dflich auf Basis der (Design-)Spezifikation erstellt, noch bevor der Code existiert. Eine strukturelle Testabdeckung ist dabei nicht entscheidend f\u00fcr den Test, eine hohe funktionale Testabdeckung ist gefragt. Welche Vor- und Nachteile diese beiden Strategien haben und wie man diese scheinbar unvereinbaren Strategien gewinnbringend verheiraten kann, zeigt dieser Artikel.<\/strong><\/p>\n Test Driven Development (TDD), genannt auch Test-First-Strategie, ist eine Vorgehensweise aus dem Portfolio der agilen Software-Entwicklung. Es ist keine Testmethode sondern eine Entwicklungsmethode, bei der der Entwickler beginnt, den Unit-Test f\u00fcr den eigenen Code zu schreiben, bevor er mit dem Codieren beginnt. Zug um Zug werden in kleinen Iterationen zuerst der Test und dann der zu testende Code implementiert bzw. erweitert. Sobald der Test keine Fehler mehr meldet, beginnt eine neue Iteration.<\/p>\n Durch diese Entwicklungsmethode ist der Entwickler eines Software-Moduls gezwungen, das Modul-Design so zu gestalten, dass es an seinen Schnittstellen gut testbar ist. Weiters ist er gezwungen, seine Testf\u00e4lle ausschlie\u00dflich aus dem Design (der Spezifikation) des Moduls abzuleiten. Er ist nicht verf\u00fchrt, im Unit-Tests den Code blo\u00df zu durchlaufen, also sich nur am zu testenden Quellcode zu orientieren, und dessen Zweck nicht genau zu hinterfragen. Im Gegenteil: Der Test testet den Code definitiv gegen das korrekte Verhalten, der zu testende Code liegt noch gar nicht vor.<\/p>\n Im Gegensatz zum traditionellen Unit-Test, also dem Test nach der Programmierung, kann TDD nicht mit einem „Testendekriterium“ aufwarten. In der agilen Literatur wird empfohlen, dann mit dem Schreiben von Testf\u00e4llen aufzuh\u00f6ren, „wenn einem nichts mehr einf\u00e4llt“. Im klassischen Unit-Test ist \u00fcblicherweise das Erreichen einer gewissen strukturellen Testabdeckung eine notwendige Bedingung f\u00fcr das Testende. H\u00e4ufig wird bei eingebetteten Systemen das Erreichen von 100% Decision Coverage, also das Durchlaufen aller Verzweigungen des zu testenden Codes, verlangt. Dabei sollte der Tester aber, wie beim TDD, die zu testende Einheit gegen ihren Zweck (ihre Design-Spezifikation) testen und\u00a0zus\u00e4tzlich<\/em>\u00a0dazu die Testabdeckung messen [1]. Wenn der Quellcode schon existiert, ist man aber ohne Zweifel dazu verf\u00fchrt, die Testf\u00e4lle nur am Quellcode auszurichten und sich damit zufriedenzugeben, den Code blo\u00df zu durchlaufen, anstatt ihn (gegen die Design-Spezifikation) zu testen. Doch f\u00fcr das Erstellen von „Testf\u00e4llen“, die den Code blo\u00df durchlaufen, gibt es inzwischen moderne Unit-Test-Werkzeuge, die das in wenigen Sekunden automatisch fertig bringen: das Erzeugen von Testf\u00e4llen auf Basis des Codes.<\/p>\n Ein Test testet in der Regel f\u00fcr bestimmte Eingaben die Reaktion des Pr\u00fcflings gegen eine erwartete Reaktion. Wenn wir von der automatischen Erzeugung von Testf\u00e4llen sprechen, muss man einschr\u00e4nken, dass f\u00fcr gegebene Inputs das\u00a0erwartete<\/em>\u00a0Ergebnis einer zu testenden Funktion einem Testwerkzeug nicht bekannt sein kann. Ein Testwerkzeug, das automatisch Testf\u00e4lle f\u00fcr eine Funktion erzeugt, erzeugt daher nur Inputs f\u00fcr diese Funktion und kann f\u00fcr diese das tats\u00e4chliche Ergebnis berechnen und dieses als erwaretes Ergebnis\u00a0vorschlagen<\/em>.<\/p>\n Viele Werkzeuge gehen dabei so vor: sie suchen Testf\u00e4lle aus einer typischerweise riesigen Anzahl von M\u00f6glichkeiten so aus, dass sie die strukturelle Testabdeckung maximieren. Viele Autoren nennen das dann Search-based Testing [7]. Werkzeuge aus dem akademischen Bereich, wie z.B. das Java-Werkzeug EvoSuite, verwenden f\u00fcr diese Suche unter anderem genetische Algorithmen [2]. Ein genetischer Algorithmus versucht die Prozesse der Evolution zu imitieren, allen voran die Idee des „survival of the fittest“. Gut angepasst, also „fit“, bedeutet in unserem Fall das Erreichen einer guten Testabdeckung. Eine initiale Population von L\u00f6sungskandidaten (in unserem Fall sind das Sets von Testf\u00e4llen) wird durch Zufall oder mit Hilfe von heuristischen Methoden erzeugt. Die fittesten Paare dieser Kandidaten bringen gemeinsam Nachkommen hervor indem sie ihr Erbmaterial (ihre Testparameter) kombinieren. Dabei passiert mit einer gewissen Wahrscheinlichkeit crossing over oder eine Mutation. Mit jeder Iteration des Suchprozesses wird durch nat\u00fcrliche Selektion die fitness (die Testabdeckung) h\u00f6her bis entweder einer der Kandidaten der Population eine L\u00f6sung ist (also das Testset 100% Testabdeckung erreicht) oder bis ein anderes Testende-Kriterium erf\u00fcllt ist, wie zum Beispiel das \u00dcberschreiten einer Zeitschranke.<\/p>\n Pure genetische Such-Verfahren gehen bei ihrer Suche nicht gerade intelligent vor. Bis zum Beispiel ein String-Compare eine \u00dcbereinstimmug mit einem Passwort meldet, kann es tausende von Iterationen ben\u00f6tigen. Deshalb werden diese Verfahren auch manchmal durch\u00a0Dynamic Symbolic Execution<\/em>\u00a0ersetzt oder erg\u00e4nzt. Bei diesem intelligenteren Verfahren wird \u2013 vereinfacht gesagt \u2013 bei konkreten Testdurchl\u00e4ufen mitprotokolliert welche Parameter Verzweigungsbedingungen beeinflussen und diese dann f\u00fcr neue Testdurchl\u00e4ufe gezielt ge\u00e4ndert. Das Werkzeug PEX verwendet Dynamic Symbolic Execution f\u00fcr den Test von .NET-Sprachen [3].<\/p>\n Aus akademischen Publikationen l\u00e4sst sich schlie\u00dfen, dass Search-based Testing mehr und mehr an Bedeutung gewinnen k\u00f6nnte. Die Forschungsteams stellen aber in den seltensten F\u00e4llen Werkzeuge f\u00fcr Programmiersprachen der Hardware-nahen Programmierung vor. Eine Ausnahme ist da das Werkzeug AUSTIN (AUgmented Search-based TestINg), siehe\u00a0https:\/\/code.google.com\/p\/austin-sbst<\/a>. Auch dieses Werkzeug unterst\u00fctzt sowohl Search-based-Testing als auch Dynamic Symbolic Execution und ist ein frei verf\u00fcgbares Unit-Test-Werkzeug f\u00fcr C Programme und daher f\u00fcr Embedded-Entwickler besonders interessant. AUSTIN wurde sowohl im Automotive-Bereich [8] als auch zum Testen von Open-Source-Programmen eingesetzt [9]. Einer Studie am King\u2019s College in London verglich AUSTIN mit anderen evolution\u00e4ren Verfahren zur Testfallgenerierung und kam zum Schluss, dass AUSTIN bei der Generierung genauso effektiv hinsichtlich der strukturellen Abdeckung aber betr\u00e4chtlich effizienter ist [8].<\/p>\n Im Gegensatz zu den Werkzeugen akademischen Ursprungs ist bei kommerziellen Werkzeugen nat\u00fcrlich wenig bekannt, wie sie arbeiten. F\u00fcr Embedded Software Testing sind diese Werkzeuge aber gerade am interessantesten, weil sie Tests f\u00fcr C\/C++ erzeugen. Das Unit-Test-Werkzeug Cantata zum Beispiel d\u00fcrfte zur Suche von Testf\u00e4llen eine Art von\u00a0Backtracking<\/em>\u00a0verwenden. Beim Backtracking spielt der Zufall eine deutlich geringere Rolle. Wie bei der Suche eines Auswegs aus einem Labyrinth bewerten diese Algorithmen die momentane Situation immer wieder neu und laufen gegebenenfalls gezielt zu einem fr\u00fcher schon besuchten Ort zur\u00fcck um dort einen anderen L\u00f6sungsweg zu suchen. Als Startpunkt f\u00fcr diese Suche d\u00fcrfte Cantata f\u00fcr Umgebungswerte und Parameter der zu testenden Funktionen einfach Null w\u00e4hlen, wie die f\u00fcr Listing 1 durch dieses Werkzeug erzeugten Testf\u00e4lle vermuten lassen.<\/p>\n #include <malloc.h><\/p>\n #include <stdio.h><\/p>\n static int* values;<\/p>\n static int size = 0;<\/p>\n static int max_size = 3;<\/p>\n void init_stack()<\/p>\n {<\/p>\n \u00a0\u00a0 values = malloc(3 * sizeof(int));<\/p>\n }<\/p>\n static void resize()<\/p>\n {<\/p>\n \u00a0\u00a0 values = realloc(values, max_size * 2);<\/p>\n \u00a0\u00a0 max_size = max_size * 2;<\/p>\n }<\/p>\n void push(int x)<\/p>\n {<\/p>\n \u00a0\u00a0 if (size >= max_size) resize(); \/* full stack *\/<\/p>\n \u00a0\u00a0 if (size < max_size)<\/p>\n \u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 values[size++] = x;<\/p>\n \u00a0\u00a0 }<\/p>\n \u00a0\u00a0 \/* else branch is infeasible, thus 100% DC is infeasible *\/<\/p>\n }<\/p>\n int pop()<\/p>\n {<\/p>\n \u00a0\u00a0 if (size > 0)<\/p>\n \u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 return values[size–];<\/p>\n \u00a0\u00a0 }<\/p>\n \u00a0\u00a0 else<\/p>\n \u00a0\u00a0 {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 printf(„error“);<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0 return 0;<\/p>\n \u00a0\u00a0 }<\/p>\n }<\/p>\n Listing 1: Eine Stack-Implementierung aus [4] entnommen und von Java in C \u00fcbersetzt.<\/em><\/p>\n Listing 1 zeigt eine besondere Herausforderung f\u00fcr ein Testwerkzeug. F\u00fcr diesen Code gibt es eigentlich keine Testf\u00e4lle, die 100% Verzweigungsabdeckung erreichen k\u00f6nnen, denn f\u00fcr die Funktion\u00a0push()<\/span>\u00a0kann niemals der zweite\u00a0else<\/span>-Zweig erreicht werden. Das Werkzeug EvoSuite versucht durch wiederholge Aufrufe der angebotenen Funktionen die 100% Verzweigungsabeckung zu erreichen und l\u00f6st das Problem schlie\u00dflich indem es ab einer gewissen Zeit akzeptiert bestimmte Pfade nicht betreten zu k\u00f6nnen [4]. Cantata hat eine „brutalere“ L\u00f6sung, die es gestattet, dennoch 100% Decision Coverage f\u00fcr Listing 1 zu erreichen: die Variablen\u00a0max_size<\/span>\u00a0und\u00a0size<\/span>\u00a0werden vor dem Aufruf von\u00a0push()<\/span>\u00a0mit Null \u00fcberschrieben. Mit den Default-Settings eines Projekts ist es dem Werkzeug erlaubt auch\u00a0static<\/span>-Variablen von au\u00dfen zu manipulieren und so ist 100% Verzweigungsabdeckung f\u00fcr\u00a0push()<\/span>\u00a0erreichbar. Der dabei durchlaufene Pfad kann aber im Produktivsystem nie durchlaufen werden, weil max_size nie Null werden kann. Abbildung 1 (siehe\u00a0PDF<\/a>) zeigt wie Cantata die 6 automatisch erzeugten Testf\u00e4lle pr\u00e4sentiert und Abbildung 2 (siehe\u00a0PDF<\/a>) zeigt, wie der Benutzer in einem Summary Report \u00fcber die erzielte Testabdeckung informiert wird.<\/p>\n Forschungsteams statten manche akademische Werkzeugen noch mit Produktfeatures aus, die bei kommerziellen Unit-Test-Werkzeugen f\u00fcr Embedded Systems (noch) nicht zu finden sind und vielleicht auch in Zukunft garnicht wirklich gefragt sind: sie testen den Code gegen allgemeing\u00fcltige Anforderungen: kein \u00dcberlauf von arithmetischen Operationen, keine Nullpointerdereferenzierung, keine Division durch Null, Arraysindizes m\u00fcssen im definierten Wertebereich sein.<\/p>\n Die Abwesenheit einer der beschriebenen Fehler kann in einem Test nat\u00fcrlich nicht nachgewiesen werden, aber mann kann ja einmal danach suchen, ob es gelingt so einen Fehler zu provozieren. Um dem Such-Algorithmus das Provozieren eines Array-Index\u00fcberlaufs schmackhaft zu machen, transformiert das Werkzeug Evosuite im Java-Bytecode Zugriffe auf Arrays in der folgenden Art:<\/p>\n void test(int x)<\/p>\n {<\/p>\n \u00a0\u00a0 if (x < 0) throw new NegativeArraySizeException();<\/p>\n \u00a0\u00a0 if (x >= foo.length) throw new ArrayIndexOutOfBoundsException();<\/p>\n \u00a0\u00a0 foo[x] = 0;<\/p>\n }<\/p>\n Listing 2: Demo der Von EvoSuite verwendeten Code-Transfomation, siehe [3].<\/em><\/p>\n Hier werden \u2013 im Gegensatz zu den bisher diskutierten generierten Testf\u00e4llen \u2013 mit hoher Wahrscheinlichkeit tats\u00e4chlich Testf\u00e4lle erzeugt, die darauf abzielen die Einhaltung einer Anforderung der Spezifikation abzutesten: die Software soll nicht abst\u00fcrzen. Im Embedded-Bereich verzichtet man aber absichtlich manchmal um der Performance Willen auf robusten Code und verbietet z.B. \u00dcberl\u00e4ufe nicht, wenn dem Umfeld der Applikation diese \u00dcberl\u00e4ufe egal sind oder diese extrem unwahrscheinlich sind. Das hei\u00dft: viele, aber nicht alle auf diese Art automatisch erzeugten Tests machen in der Praxis auch wirklich Sinn.<\/p>\n An der Universit\u00e4t Sheffield gab es einen gro\u00df angelegten Versuch mit \u00fcber 100 Probanden mit dem Ziel herauszufinden, ob man bei Verwendung durch das Werkzeug EvoSuite automatisch erzeugter Unit-Tests mehr Fehler findet als bei h\u00e4ndischer Implementierung von Tests mit JUnit [5]. Die Probanden waren gro\u00dfteils Studenten. In der Studie wurden ihnen 2 bzw. 3 Stunden f\u00fcr eine Testaufgabe mit und ohne Testgenerator gegeben und kurz vor Erhalt der Aufgabe gab es einen Auffrischungskurs f\u00fcr JUnit. Die Aufgabensteller bem\u00fchten sich um m\u00f6glichst objektive Ergebnisse bei diesem Vergleich:<\/p>\n Ein Ergebnis des Versuchs war, dass man herausfand, dass die erreichte Testabdeckung mit und ohne Werkzeug etwa gleich hoch war \u2013 die Probanden hatten keine M\u00f6glichkeit die erzielte Testabdeckung zu messen. Das war recht erfreulich f\u00fcr die Wissenschafter, zeigte es doch, dass sich ihr Testgenerator mit meschlichen Gegenspielern messen konnte. Ergebnis Nummer Zwei war aber f\u00fcr manche Personen ern\u00fcchternd: auch die Quote an gefundenen Fehlern war mit und ohne Testgenerator etwa gleich hoch.<\/p>\n Die Autoren des Experiments merkten bei der Publikation ihrer Ergebnisse korrekterweise kritisch an, dass die Probanden den Code vor dem Versuch nicht kannten. Das ist eine Situation, die f\u00fcr die wenigsten Projekte zutrifft, denn fast immer ist der Autor von Unit-Tests der Autor des Codes. Aber da darf man wohl noch ein wenig weitere Kritik hinzuf\u00fcgen:<\/p>\n Der letzte Kritikpunkt ist eine m\u00f6gliche Erkl\u00e4rung der gleichen Feherquote mit und ohne Testgenerator: Fehler werden durch durchdachte und schlagkr\u00e4ftige Testf\u00e4lle gefunden. Dazu verhelfen einschl\u00e4gige Weiterbildung, Geschick und Erfahrung des Testers. Das Testwerkzeug kann dem Tester das Denken nicht abnehmen und wird daher die Anzahl der gefundenen Fehler nicht erh\u00f6hen. Sehr wohl kann es aber die Testerstellung\u00a0beschleunigen<\/em>, weil es dem Tester vergleichsweise stupide Arbeit abnimmt und mehr Zeit f\u00fcr die Konzentration auf die Teststrategie l\u00e4sst, wie die n\u00e4chsten Abs\u00e4tze des Artikels diskutieren.<\/p>\n Auch Unit-Test-Werkzeuge ohne automatische Testerstellung beschleunigen das Schreiben von Tests. So werden zum Beispiel Stubs (Mockups, R\u00fcmpfe des vom zu testenden Codees aufgerufenen aber nicht verf\u00fcgbaren Funktionen) automatisch erzeugt und Testtreiber auf Basis von tabellarischen Eingaben durch das Werkzeug erstellt. Diese Beschleunigung im Vergleich zur Test-First-Strategie ist m\u00f6glich, weil das Werkzeug die Schnittstellen des zu testenden Codes analysieren kann und dem Benutzer damit Tipp-Arbeit abnehmen kann.<\/p>\n Testwerkzeuge wie Cantata, Tessy, VectorCast und andere protokollieren auch auf Wunsch die strukturelle Testabdeckunng. Wie oben erw\u00e4hnt ist das Erreichen von 100% der gew\u00fcnschten Abdeckung zwar keine ausreichende Bedingung das Testen zu beenden, doch ist das Nicht-Erreichen von 100% fast immer ein Zeichen, dass noch Testf\u00e4lle fehlen. Auf diese Alarmanlage verzichtet die Test-First-Strategie.<\/p>\n Und noch eine Unterst\u00fctzung wird zumindest von Cantata zur Verf\u00fcgung gestellt, die bei TDD nicht m\u00f6glich ist: das Testwerkzeug gibt dem Tester in gewissem Umfang nicht nur die M\u00f6glichkeit festzustellen, dass der zu testende Code das tut was er soll (durch Definition der Testf\u00e4lle), sondern auch festzustellen, wenn etwas passiert, was\u00a0nicht<\/em>\u00a0passieren soll: Cantata \u00fcberpr\u00fcft nach jedem Testfall\u00a0alle<\/em>\u00a0Variablen auf Ver\u00e4nderung und kann somit z.B. feststellen, wenn eine verirrte Zeigervariable unbeabsichtigt andere Variablen \u00fcberschreibt.<\/p>\n Wenn sich diese drei Vorteile des Einsatzes eines zeitgem\u00e4\u00dfen Unit-Test-Werkzeugs im Vergleich zu TDD sich auch\u00a0ohne<\/em>\u00a0automatische Testerzeugung auswirken und wenn das Experiment der Universit\u00e4t Sheffield gezeigt hat, dass man mit Testgeneratoren auch nicht mehr Fehler findet als ohne: was bleibt dann von der automatischen Testerzeugung? Die Teschbeschleunigung. Die n\u00e4chsten Abs\u00e4tze zeigen wie man die zentralen Ideen von TDD im Test mit Testgeneratoren anwendet, dadurch eine weitere Verk\u00fcrzung der Testszeit erf\u00e4hrt und somit Unit-Tests profitabler werden l\u00e4sst.<\/p>\n Am Anfang des Artikels wurden Vorteile von TDD diskutiert. Im vorhergehenden Abschnitt wurden Nachteile von TDD gegen\u00fcber dem Einsatz von modernen Unit-Test-Werkzeugen erl\u00e4utert. Nun zeigen wir wie man die Vorteile beider Ans\u00e4tze kombinieren und nutzen kann und dabei die jeweiligen Nachteile \u00fcberdeckt.<\/p>\n Ohne Zweifel k\u00f6nnen Vorteile und die zentralen Ideen von TDD, (1) die der ausschlie\u00dflichen Orientierung an der Spezifikation bei der Definition der Testf\u00e4lle und (2) das Design von Units, die an ihren Schnittstellen gut testbar sind, auch im klassischen Test mit Werkzeug Anwendung finden. Dazu ben\u00f6tigt es nur einer gewissen Disziplin.<\/p>\n Auch sollte man Testgeneratoren nicht \u00fcbersch\u00e4tzen und sich nicht von ihnen in die Irre leiten lassen. Tests aus dem Generator k\u00f6nnen v\u00f6llig unsinnig sein. Das \u00fcberlegte Testdesign ist und bleibt Aufgabe des Testers. Doofe Tipparbeit kann durch den Generator reduziert werden, nicht das ideenreiche Testdesign. Wenn man also automatische Unit-Test-Erzeugung gewinnbringend einsetzen will, dann muss man wissen wie man die Werkzeuge einsatzt. Der folgende \u201eTEST Fast\u201c genannte \u201eVerhaltenskodex im Umgang mit Testgeneratoren\u201c kann dabei helfen das Beste aus einem Unit-Test-Projekt herauszuholen und im Vergleich zu anderen Vorgehensweisen Testzeit zu sparen. Dazu ein kleiner Appetitanreger: Die automatische Erstellung der Tests zu Listing 1 ben\u00f6tigt weniger als 2 Sekunden.<\/p>\n Zur Umsetzung von Test FAST wird das Beachten der folgende Regeln empfohlen:<\/p>\n So manche Firmen habe versucht Test First einzuf\u00fchren um Qualit\u00e4tsverbesserungen zu erfahren. Viele davon haben es wieder aufgegeben, weil die Programmierer es nicht besonders spannend fanden zuerst (auch banale) Testf\u00e4lle zu schreiben die sie sp\u00e4ter vielleicht wieder wegschmei\u00dfen mussten wenn sie im Zuge der Programmierung die Architektur einer Software-Unit ver\u00e4ndert haben. Test FAST hat das Potenzial hier gegenzusteuern: die Programmierer k\u00f6nnen sich zuerst auf die Implementierung des Produkts, dann auf die Implementierung der knackigen Testf\u00e4lle konzentrieren, die einfachen Tests werden automatisch erzeugt.<\/p>\n In diesem Artikel wurde gezeigt wie Unit-Test-Generatoren funktionieren und auf welche Art man sie gewinnbringend einsetzt. Dabei wurden unbestrittene Vorteile von TDD auf den Werkzeugeinsatz transportiert und das Vorgehensmodell Test FAST vorgestellt.<\/p>\n Im Artikel wurde darauf hingewiesen, dass f\u00fcr automatische wie manuell erstellte Tests das Erreichen von 100% Testabdeckung zwar meist eine notwendige Bedingung f\u00fcr gute Tests ist, aber ganz gewiss nicht hinreichend. Listing 3 zeigt ein weiteres Beispiel. Die Testf\u00e4lle erreichen 100% Verzweigungsabdeckung und finden dennoch einen ganz gravierenden Fehler nicht.<\/p>\n unsigned max(unsigned a, unsigned b, unsigned c) \u00a0\u00a0 unsigned max = 0;<\/p>\n \u00a0\u00a0 if (a > c) max = a; \u00a0\u00a0 return max;<\/p>\n }<\/p>\n \/*<\/p>\n \u00a0\u00a0\u00a0\u00a0 Test 1: max(3,5,7) == 7<\/p>\n \u00a0\u00a0\u00a0\u00a0 Test 2: max(5,7,3) == 7<\/p>\n \u00a0\u00a0\u00a0\u00a0 Test 3: max(7,5,3) == 7<\/p>\n *\/<\/p>\n Listing 3: Ein Beispiel von schlechten Tests aus [6]. Ein Bug wird nicht erkannt.<\/em><\/p>\n Auch die meisten momentan am Markt erh\u00e4ltlichen kommerziellen Werkzeuge zur automatischen Erzeugung von C\/C++ Unit-Tests haben zur Zeit f\u00fcr Listing 3 keine Testf\u00e4lle anzubieten, die den Benutzer auf den Fehler aufmerksam machen, weil sie nur die Testabdeckung maximieren aber noch keine intelligente Wahl von Testdaten anbieten. Die Hersteller arbeiten aber stets daran die Testgeneratoren intelligenter zu machen. F\u00fcr das Jahr 2016 ist zu erwarten, dass viele kommerzielle Generatoren intelligent genug sind, dass man f\u00fcr Listing 3 folgende Testvorschl\u00e4ge pr\u00e4sentiert bekommt und auf diese Art schnell den Fehler des Codes erkennt:<\/p>\n Eine Methode, die sich\u00a0ausschlie\u00dflich<\/em>\u00a0am Quellcode orientiert aber f\u00fcr die es kaum Werkzeug-Unterst\u00fctzung gibt, ist das\u00a0Baseline Testing<\/em>\u00a0\u2013 oft illustriert mit Hilfe von Kontrollflussgraphen. Die Idee dieses Verfahrens ist einen Satz von unabh\u00e4ngigen Pfaden durch den Kontrollflussgraphen der zu testenden Software zu erzeugen. Dabei wird, vereinfacht gesagt, ein neuer Testfall aus bestehenden erzeugt, indem immer nur eine einzige Richtungs-Entscheidung ver\u00e4ndert wird. So lange, bis das nicht mehr m\u00f6glich ist.<\/p>\n int x = 0;<\/p>\n int tu_nichts(int a, int b)<\/p>\n {<\/p>\n \u00a0\u00a0 if (a > 10) x += 47;<\/p>\n \u00a0\u00a0 if (b > 10) x -= 47;<\/p>\n \u00a0\u00a0 return x;<\/p>\n }<\/p>\n Listing 4: Dieser Code sollte x niemals ver\u00e4ndern. Tut er aber.<\/em><\/p>\n Beispielsweise k\u00f6nnte man mit diesem Verfahren f\u00fcr den Code aus Listing 4 die folgenden drei Testf\u00e4lle ableiten.<\/p>\n Um 100% Decision Coverage zu erreichen w\u00e4ren hier zwei Testf\u00e4lle ausreichend. Die beiden Testf\u00e4lle\u00a0foo(11,11)<\/span>und\u00a0foo(10,10)<\/span>\u00a0durchlaufen die beiden Entscheidungen in jeweils jede m\u00f6gliche Richtung, erkennen aber nicht, dass x unerlaubter Weise ver\u00e4ndert wird. Mit Hilfe von Baseline Testing h\u00e4tte man den Fehler in der Funktion\u00a0max()<\/span>\u00a0vergleichsweise leicht gefunden, au\u00dfer der Pfad, der alle drei if-Bedinungen nicht feuern l\u00e4sst, wird durch den Aufruf\u00a0max(0,0,0)<\/span>\u00a0betreten. Das ist die einzige Wahl von Parametern, die den Fehler beim Baseline-Testing nicht findet. Baseline-Testing w\u00e4hlt die Testf\u00e4lle anhand des Quellcodes zwar intelligenter, ist aber bei ungeschickter Wahl der Testdaten auch nicht schlagkr\u00e4ftiger.<\/p>\n Die Publikationen von Gordon Fraser et al kann man von www.evosuite.org kostenfrei herunterladen.<\/p>\n [1] Stephan Gr\u00fcnfelder,\u00a0Software-Test f\u00fcr Embedded Systems,\u00a0<\/em>Dpunkt-Verlag, Heidelberg 2013.<\/p>\n [2] Gordon Fraser, Andrea Arcuri, Phil McMinn: A Memetic Algorithm for Whole Test Suite Generation.\u00a0Journal of Systems and Software<\/em>, Volume 103, May 2015, pages 311\u2013327.<\/p>\n [3] Gordon Fraser, Andrea Arcuri: 1600 Faults in 100 Projects: Automatically Finding Faults While Achieving High Coverage with EvoSuite.\u00a0Empirical Software Engineering<\/em>, June 2015, Volume 20, Issue 3, pp 611-639.<\/p>\n [4] Gordon Fraser, Andrea Arcuri: Evolutionary Generation of Whole Test Suites. Proc.\u00a011th International Conference on Quality Software<\/em>, 2011, pp. 31-40.<\/p>\n [5] G. Fraser, M. Staats, P. McMinn, A. Arcuri, F. Padberg: Does Automated Unit Test Generation Really Help Software Testers? A Controlled Empirical Study.\u00a0ACM Transactions on Software Engineering Methodology<\/em>, vol. 24, no. 4, 2015.<\/p>\n [6] Andreas Spillner, „Agilit\u00e4t und systematischer Test“, Vortrag beim\u00a0BCD Acceptance Caf\u00e9<\/em>\u00a0am 16. April 2013 in Wien.<\/p>\n [7] Ali, S.; Briand, L.C.; Hemmati, H.; Panesar-Walawege, R.K., „A Systematic Review of the Application and Empirical Investigation of Search-Based Test Case Generation,“ in Software Engineering, IEEE Transactions on , vol.36, no.6, pp.742-762, Nov.-Dec. 2010.<\/p>\n [8] Lakhotia, K.; Harman, M.; Gross, H., AUSTIN: A Tool for Search Based Software Testing for the C Language and Its Evaluation on Deployed Automotive Systems, in Search Based Software Engineering (SSBSE), 2010 Second International Symposium on , vol., no., pp.101-110, 7-9 Sept. 2010.<\/p>\n [9] K. Lakhotia, P. McMinn, and M. Harman, Automated Test Data Generation for Coverage: Haven\u2019t We Solved This Problem Yet? in 4th Testing Academia and Industry Conference – Practice and Research Techniques, 2009, pp. 95\u2013104.<\/p>\n [10] P. McMinn, Search-based software test data generation: A survey, Software Testing, Verification and Reliability, vol. 14, no. 2, pp. 105\u2013156, Jun. 2004.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nTDD gegen traditionelles Unit-Testing<\/h2>\n
Automatische Erzeugung von Unit-Tests<\/h2>\n
Erforschung effizienter Suchverfahren<\/h2>\n
Kommerzielle Werkzeuge<\/h2>\n
Akademische Werkzeuge<\/h2>\n
Fehlerfindung mit und ohne Werkzeug, Teil 1<\/h2>\n
\n
A fool with a tool is still a fool<\/h2>\n
\n
Fehlerfindung mit und ohne Werkzeug, Teil 2<\/h2>\n
Test FAST statt Test FIRST<\/h2>\n
\n
Zusammenfassung und Ausblick<\/h2>\n
\n{<\/p>\n
\nif (b > a) max = b;
\nif (c > b) max = c;<\/p>\n\n
Fachliches Nachwort<\/h2>\n
\n
Literatur<\/h2>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug – Fachwissen<\/h2>\n