Evaluation der Leistungsfähigkeit ausgewählter Mutationstestwerkzeuge


Projektarbeit, 2014

59 Seiten, Note: 1,0


Leseprobe

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Ziele Der Arbeit
1.3 Gliederung

2 Grundlagen Des Softwaretestens
2.1 Der Fundamentale Testprozess
2.1.1 Planung und Steuerung
2.1.2 Analyse und Design
2.1.3 Realisierung und Durchführung
2.1.4 Auswertung und Bericht
2.1.5 Abschluss
2.2. Testarten Und Testbenennung
2.2.1 Teststufe
2.2.2 Testperson
2.2.3 Testmethode
2.2.4 Testziel

3 Mutationstests
3.1 Der Mutationstestprozess
3.2 Kernhypothesen
3.2.1 Die Competent Programmer Hypothesis
3.2.2 Der Coupling Effect
3.3 Lösungsansätze Für Bekannte Schwachstellen
3.3.1 Äquivalente Mutanten
3.3.2 Der Faktor Mensch
3.3.3 Mutanten-Erzeugung
3.3.4 Testausführung

4 Vorstellung der Mutationswerkzeuge
4.1 MuJava
4.2 Jumble
4.3 Pitest
4.4 Judy
4.5 Major
4.6 Zusammenfassung

5 Vergleich Der Mutationstestwerkzeuge
5.1 Beschreibung Der Testumgebung
5.2 Vorstellung Der Testkriterien
5.2.1 Leistungskriterien
5.2.2 Bedienbarkeitskriterien
5.3 Vorgehensbeschreibung
5.4 Darstellung Der Ergebnisse
5.4.1 Leistungsbewertung
5.4.2 Bedienbarkeitsbewertung

6 Bewertung Der Werkzeuge
6.1 MuJava
6.2 Jumble
6.3 Pitest
6.4 Judy
6.5 Major
6.6 Handlungsempfehlung

7 Fazit

Literaturverzeichnis

Zusammenfassung

Mutationstests dienen zur Qualitätsbestimmung von Softwaretests. Um die Ausführung dieser Tests zu automatisieren, gibt es eine Reihe von Mutati- onstestwerkzeugen. Diese Arbeit beschäftigt sich mit den öfentlich verfüg- baren Werkzeugen für die Programmiersprache Java und dem Testframe- work JUnit. Sie vergleicht die Werkzeuge MuJava, Jumble, Pitest, Judy und Major hinsichtlich ihres Funktionsumfangs, ihrer Leistungsfähigkeit und ihrer Praxistauglichkeit miteinander. Die Ergebnisse dieser Evaluation dienen als Entscheidungshilfe bei der Auswahl eines Werkzeugs zur Testver- besserung.

1 Einleitung

Diese Arbeit beschäftigt sich mit dem Vergleich von ausgewählten Mutati- onstestwerkzeugen für die Programmiersprache Java. Sie geht dabei der Frage nach, welches dieser Werkzeuge sich am Besten für einen Einsatz in der Praxis eignet. Dieses Kapitel leitet die Fragestellung dieser Arbeit ein und bietet eine Übersicht über Zielsetzung und Aufbau der Arbeit. Dazu erfolgt in Abschnitt 1.1 die Motivation der Evaluation und in Abschnitt 1.2 werden die Ziele der Arbeit erläutert. Abschnitt 1.3 beschreibt den weiteren Aufbau dieser Arbeit.

1.1 Motivation

Softwaretests sind ein wichtiger Bestandteil der Softwareentwicklung. So spart frühzeitiges Testen nicht nur Geld, da ein Fehler umso mehr Kosten verursacht, je später er gefunden wird [Boe79, S. 2, Fig. 1], sondern sorgt auch für eine Sicherung der Softwarequalität. Gerade bei sicherheits- kritischen Systemen ist beispielsweise Zuverlässigkeit unabdingbar: Wer nicht darauf vertrauen kann, dass die Software eines Flugzeugs verlässlich funktioniert, wird auch nicht in das Flugzeug einsteigen.

Testen hat jedoch nur einen geringen Nutzen, wenn die Tests selbst eine schlechte Qualität haben und das Programm auch nach ausführlichem Tes- ten noch viele Fehler aufweist. Um herauszufnden, wie gut ein Test ist, muss auch dieser getestet werden. Dazu eignet sich die in den 1970er Jah- ren entwickelte Technik des Mutationstestens [DLS78]. Hierbei werden Feh- ler in ein Programm eingebaut, welche die Tests entdecken müssen. Je mehr Fehler entdeckt werden, umso besser ist die Qualität der Tests.

Es existiert eine Menge unterschiedlicher Werkzeuge, mit denen Mutationstests durchgeführt werden können. Jedes dieser Werkzeuge besitzt einen unterschiedlichen Funktionsumfang. Auch die Leistungsfähigkeit der Werkzeuge variiert. Dadurch erfordert die Entscheidung für ein geeignetes Werkzeug eine gründliche Abwägung der Vor- und Nachteile.

1.2 Ziele der Arbeit

Die Zielsetzung dieser Arbeit lässt sich in zwei Hauptbereiche unterteilen:

Die Einführung in die benötigten Grundlagen der Softwaretests im Allgemeinen und der Mutationstests im Speziellen.

Die Bewertung der getesteten Werkzeuge. Dies beinhaltet einen Vergleich ihrer Leistungen, Fähigkeiten und der genutzten Ansätze.

Die Einführung in die Grundlagen der Softwaretests schaft eine gemein- same Basis für die Einordnung und das Verständnis von Mutationstests. Auf Grundlage dieser Basis erfolgt dann eine ausführlichere Einführung in die Grundprinzipien und Vorgehensweisen der Mutationstests. Dies dient als theoretische Grundlage für das Verständnis der vorgestellten Testwerk- zeuge.

Darauf aufbauend werden zunächst die Kriterien für die Auswahl der Werkzeuge hergeleitet um dann die ausgewählten Werkzeuge vorzustellen. Diese Vorstellung verfolgt den Zweck einer ersten Gegenüberstellung der Testwerkzeuge. So werden Schwachstellen und Stärken der einzelnen Ansätze der Werkzeuge beleuchtet und Unterschiede aufgezeigt.

Zum Schluss erfolgt dann die praktische Umsetzung der Evaluation um die Praxistauglichkeit der Werkzeuge zu überprüfen. Dabei werden ver- schiedene Aspekte betrachtet um eine d f renzierte Sicht auf die Testwerk- zeuge zu ermöglichen. Auf dieser Basis erfolgt dann die Einzelbewertung der Werkzeuge und die Empfehlung für eine geeignete Werkzeugauswahl.

1.3 Gliederung

Dieser Abschnitt bietet eine Übersicht über die Gliederung dieser Arbeit. Dazu erfolgt eine schrittweise Vorstellung der einzelnen Kapitel inklusive einer kurzen Inhaltsangabe.

Kapitel 1 beinhaltet die Einleitung der Arbeit. Hier werden die Frage- stellungen vorgestellt und das Thema motiviert. Zudem werden die Zielset- zungen vorgegeben und die inhaltliche Struktur der Arbeit dargelegt.

In Kapitel 2 werden die für diese Arbeit relevanten theoretischen Grund- lagen des Testens im Bereich der Softwareentwicklung beschrieben. Dazu werden notwendige Begr fee klärt und einige grundlegende Bestandteile des Testprozesses in der Softwareentwicklung vorgestellt. Darüber hinaus werden ausgewählte Testarten erläutert, welche für das Verständnis und für die Einordnung von Mutationstests in den Softwareentwicklungsprozess not- wendig sind.

Darauf aufbauend erläutert Kapitel 3 den Mutationstestprozess und führt wichtige Grundbegr feausdem Bere ch der Mutationstests ein. Au- ßerdem werden die Kernhypothesen vorgestellt, auf denen die Mutations- tests basieren. Abschließend erfolgt eine kurze Einführung in die verschiede- nen Problemlösungsansätze für bekannte Schwachstellen der Mutations- tests.

In Kapitel 4 erfolgt die Vorstellung der untersuchten Mutationstestwerkzeuge und ihrer genutzten Ansätze. Hier wird ein erster Überblick über die Eigenschaften und Anwendungsmöglichkeiten der Werkzeuge geboten. Außerdem erfolgt ein Vergleich der Funktionsumfänge.

Kapitel 5 befasst sich mit der praktischen Umsetzung der Evaluation. Dazu werden zunächst die Testumgebung und das Vorgehen beschrieben, um die Nachvollziehbarkeit der Ergebnisse zu gewährleisten. Auch die an- gewendeten Testkriterien werden hergeleitet und erörtert. Danach folgt die Vorstellung der gewonnenen Ergebnisse sowie eine anschließende Diskussi- on.

Auf dieser Basis erfolgt in Kapitel 6 die Bewertung der getesteten Werk- zeuge. Basierend darauf wird schließlich eine Empfehlung für die Auswahl eines der Testwerkzeuge ausgesprochen. In Kapitel 7 wird ein Fazit gezogen und auf mögliche Perspektiven hinsichtlich weiterer Entwicklungen einge- gangen.

2 Grundlagen des Softwaretestens

Softwaretests sichern die Qualität von Software, indem sie überprüfen, ob die Software sich so verhält, wie sie es soll [SL10, S. 6f]. Ziel dieser Über- prüfung ist es, Fehler in der Software zu entdecken. Dadurch soll die Menge der im Programm enthaltenen Fehler minimiert werden. Ganz eliminieren lassen sich Softwarefehler bei größeren Programmen aber nie, da die Anzahl der Fehlermöglichkeiten unüberschaubare Dimensionen annimmt [SL10, S. 10]. Anders gesagt, ein Softwaretest kann zwar die An- und Abwesenheit ei- nes konkreten Fehler nachweisen, aber niemals die absolute Abwesenheit al- ler Fehler. Edsger W. Dijkstra hat das ganze sehr tr f nd zusammenge- fasst:

„ Program testing can be used to show the presence of bugs, but never to show their absence!” [Dij72, S. 6].

Aus diesem Grund sollte es das Ziel eines jeden Softwaretesters sein, die Tests so zu gestalten, dass sie mit geringst möglichem Aufwand die größt- mögliche Menge an Fehlern aufdecken. Um dies zu ermöglichen, müssen vielfältige Faktoren berücksichtigt werden, unter anderem Zeitpunkt, Um- fang, Testart, Aufwand, mögliche Unterstützung durch Werkzeuge und Testnutzen.

In diesem Kapitel werden daher die für das Verständnis von Mutations- tests relevanten Grundlagen des Softwaretestens erläutert. Dabei befasst sich Abschnitt 2.1 mit dem Aufbau und den Bestandteilen des Testprozes- ses. In diesem Zusammenhang werden wichtige Grundbegr fee ngeführt und erklärt. Abschnitt 2.2 erläutert ausgewählte Testarten, um eine spätere Zuordnung der Mutationstests zu den verschiedenen Testkatarten zu er- möglichen.

2.1 Der fundamentale Testprozess

Dieser Abschnitt gibt einen kurzen Überblick über den fundamentalen Testprozes s nach [SL10, S. 18 - 33] und seiner Rolle im Softwarelebenszy- klus. Je nachdem, für welchen Entwicklungsansatz man sich entscheidet, va- riieren Anwendungszeitpunkt und -dauer der Softwaretests. Dies wirkt sich wiederum auf die Auswahl an möglichen Testarten und -werkzeugen aus.

So kann das Testen zum Beispiel eine elementare Grundlage sein, wie bei der Testgetriebenen Entwicklung [Bec02, S. ixff]. Bei diesem in der agi- len Entwicklung häufg verwendeten Ansatz wird zunächst ein Test ge- schrieben, der fehlschlägt. Danach wird erst der Programmcode implemen- tiert, der den Test erfolgreich durchlaufen lässt. Dieser Prozess wird zy- klisch und in möglichst kurzen Abständen wiederholt [JS05, S. 44]. Andererseits kann der Testprozess auch eine weniger grundlegende Rolle einnehmen, wie beispielsweise beim Wasserfallmodell. Hier wird die Test-phase jeweils nur nach Abschluss der Implementierungsphase ausgeführt [Roy70, S. 330], siehe die rot markierte Phase in Abbildung 1. Ein dritter Ansatz fndet sich im V-Modell nach [Boe79, S. 4, Fig. 2], welches einen hohen Verbreitungsgrad hat [SL10, S. 18]. Hier werden Tests jeweils parallel zu Anforderungserfassung, Design und Implementierung durchgeführt. Auf diesen Ansatz wird in Abschnitt 2.2.1 noch ausführlicher eingegangen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Wasserfallmodell nach [Roy70, S. 3, Fig. 3]

Der Testprozess ist somit trotz der möglichen unterschiedlichen Gewich- tung ein fester Bestandteil der Softwareentwicklung, dessen Durchführung sorgfältig geplant werden will. Zudem besteht der Testprozess selbst aus verschiedenen Phasen, die wiederum je nach Gegebenheit beispielsweise in ihrem Umfang oder dem Ausführungszeitpunkt angepasst werden müssen [SL10, S.20].

Die folgenden Abschnitte bieten daher eine kurze Übersicht über die ein- zelnen Phasen des fundamentalen Testprozesses nach [SL10, S. 18 - 33]. Abbildung 2 illustriert dabei die Abfolge der Phasen. Die Erläuterungen beschränken sich dabei auf die für das Verständnis von Mutationstests rele- vanten Aspekte inklusive der Einführung wichtiger Grundbegr fe.

2.1.1 Planung und Steuerung

Der hier folgende Abschnitt beschäftigt sich mit der ersten Phase des fundamentalen Testprozesses nach [SL10, S. 21 - 23]. Diese Phase gliedert sich in Planungsphase und Steuerung des Testprozesses.

Die Steuerungsphase des Testprozesses bildet eine Besonderheit, da sie sich über den gesamten Testprozess erstreckt. Dies ist notwendig, da grade komplexere Tests eine fortwährende Kontrolle und eventuelle Anpassungen der Vorgehensweise erfordern. So wird in der Steuerungsphase auch festgelegt, ob eine der anderen Phasen erneut durchlaufen werden muss oder ob in die nächste Testphase übergegangen werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Der fundamentale Testprozess nach [SL10, S. 20, Abb. 2.4]

Kernaufgabe der Planungsphase ist die Festlegung der Aufgaben und Zielsetzung der Tests, sowie die zu verwendende Testart. Außerdem fndet die Planung der verfügbaren Zeit und Ressourcen statt. Darüber hinaus erfolgt die Wahl der Teststrategie. Diese Strategie legt fest, wie die Prioritäten bei der Testreihenfolge und der Verteilung der Ressourcen gesetzt werden. Hierzu fndet eine Abwägung von Kosten und Nutzen der Tests statt. Besonders wichtige Programmsegmente sollten dementsprechend eher getestet werden als unwichtigere Nebenfunktionen.

Bei der Zuweisung der Prioritäten spielt auch die Qualität der Tests eine wichtige Rolle, da qualitativ schlechte Tests natürlich einen geringen Nut- zen haben. Wie gut die Tests eines Programms sind, lässt sich anhand von

Qualitätskriterien wie zum Beispiel dem Testüberdeckungsgrad oder der Entdeckungsfähigkeit feststellen.

Die Testüberdeckungsmaße sind in verschiedene Kategorien unterteilt. Sie geben an, wie viel Prozent beispielsweise der Anweisungen während der Tests zur Ausführung gebracht wurden. Besteht eine Software aus 100 Anweisungen von denen 90 während des Testlaufs ausgeführt wurden, bedeutet dies eine Anweisungsüberdeckung von 90%. Weitere Überdeckungsmaße sind die Zweig-, Pfad- und Bedingungsüberdeckung.

Bei der Entdeckungsfähigkeit von Softwaretests geht es hingegen darum, wie viele Fehler die Tests innerhalb der Software entdecken. Je mehr Fehler entdeckt werden, desto besser ist auch die Entdeckungsfähigkeit der Tests.

Diese Qualitätskriterien dienen unter anderem als Grundlage für die Testendekriterien, welche am Ende der Planungsphase festgelegt werden. Ein Testendekriterium gibt dabei an, wann der Testlauf beendet wird. Dies kann zum Beispiel beim Erreichen einer Anweisungsüberdeckung von 95% der Fall sein. Zusätzlich könnte der Kunde verlangen, dass aus wirtschaftlichen Gründen nicht mehr weiter getestet wird, wenn beispielsweise während eines Testlaufs weniger als drei Fehler auftreten.

Zudem spielt auch die Ressourcenplanung eine Rolle bei der Festlegung von Testendekriterien. So muss auch aufgehört werden zu testen, wenn die vorhandenen Ressourcen verbraucht sind.

Dadurch ergeben sich beispielsweise folgende Testendekriterien:

- Überschreiten der Arbeitszeit von 42 Personenstunden oder
- Erreichen einer Anweisungsüberdeckung von 95% oder
- Entdeckung von weniger als drei Fehlern pro Testlauf

Als letztes wird in der Planungsphase noch die Auswahl von Testwerk- zeugen diskutiert. Diese Werkzeuge können eine sinnvolle und hilfreiche Un- terstützung sein, erfordern aber in der Regel besondere Vorbereitungen und Fachwissen. So ist es ratsam. vorher zu überprüfen, ob die Werkzeuge auf dem neuesten Stand sind und ohne Probleme angewendet werden können.

2.1.2 Analyse und Design

In diesem Abschnitt wird die zweite Phase des fundamentalen Testprozesses nach [SL10, S. 23 - 27] behandelt. Hauptaufgabe dieser Phase ist die Über- prüfung und Festlegung von Testbasis und Testobjekten sowie der Entwurf der Testfälle. Darauf aufbauend wird außerdem die Testinfrastruktur fest- gelegt.

Zu Beginn erfolgt zunächst die Untersuchung der Testbasis auf ihre Tauglichkeit. Die Testbasis bildet die Grundlage für die Erstellung der Tests, deswegen muss sich anhand der enthaltenen Informationen eindeutig ableiten lassen, wie das Ergebnis eines Tests auszusehen hat. Als Testbasis eignen sich daher besonders Kundenanforderungen beziehungsweise die Spez f ation, die das Soll-Verhalten des Programms festlegt. Entspricht das getestete Verhalten nicht der Spez fka ion, spricht man von einem Fehler.

Als nächstes folgt die Überprüfung der Testobjekte. Als Testobjekt wird der Bestandteil der Software bezeichnet, der getestet werden soll, beispielsweise eine Funktion zur Berechnung der Fakultät einer Zahl oder die grafische Anzeige der aktuellen Uhrzeit. Grundvoraussetzung für ein Testobjekt ist seine Testbarkeit, also ob das korrekte Verhalten des Objektes anhand eines Tests überprüft werden kann. Idealerweise wird dies bereits beim Entwurf des jeweiligen Objektes sichergestellt.

Waren die Analysen von Testbasis und Testobjekten erfolgreich, kann mit dem Design der Testfälle begonnen werden. Dazu wird eine Testfalls- pez f ation erstellt, in der genau festgelegt werden muss, welche Testfälle welche Anforderungen überprüfen, damit die Rückverfolgbarkeit gegeben bleibt. Außerdem erfolgt die Festlegung von Vor-, und Nachbedingungen der Testfälle. Eine beispielhafte Spez fka ion eines Testfalls fndet sich in Tabelle 1.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Beispielhafte Spez f ation eines logischen Testfalls

Die Vorbedingung d fn ert die Ausgangssituation des Tests und gibt an, welche Voraussetzungen erfüllt sein müssen, damit der Test korrekt durch- geführt werden kann. Die Nachbedingung legt fest, unter welchen Umstän- den der Test als erfolgreich gewertet wird und welche Ausgaben zu erwar- ten sind. Diese Erwartungen werden vom Testorakel festgelegt. Als Testora- kel kann die Spez fka ion dienen, bei komplexeren Tests ist aber oftmals auch ein Mensch notwendig, der die Ergebnisse korrekt interpretieren und einordnen kann.

Die Designphase endet mit der vollständigen Spez fka ion der Testfälle. Diese Testfälle werden dann logische Testfälle genannt, da sie den logischen Aufbau des Testfalles vorgeben.

2.1.3 Realisierung und Durchführung

Nachfolgend wird die Realisierungs- und Durchführungsphase des fundamentalen Testprozesses nach [SL10, S. 27 - 29] behandelt. In dieser Phase werden Testfälle, Testinfrastruktur und Testrahmen implementiert. Danach können die Tests ausgeführt und protokolliert werden.

Die Realisierung der Testfälle bedeutet den vorher spez f ierten logi- schen Fällen konkrete Werte zuzuordnen, sodass der Testfall ausführbar und somit zum konkreten Testfall wird. Diese Ausführung muss einem fest- gelegten und später leicht nachvollziehbaren Testablauf folgen. Dazu kön- nen die einzelnen Testfälle zu Testszenarien oder -sequenzen gruppiert wer- den, die dann in einem festgelegten Testrahmen durchgeführt werden. Die Durchführung kann entweder manuell, oder automatisiert durch Testwerk- zeuge geschehen. Eine beispielhafte Darstellung einer Testsequenz fndet sich in Tabelle 2.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Beispielhafte Darstellung einer Testsequenz

Während der Durchführung ist es unbedingt ratsam, alles notwendige festzuhalten, um die Testergebnisse später nachvollziehen zu können. Dies ist besonders wichtig, um gefundene Fehler bei Bedarf nachstellen zu kön- nen und die Fehlerursache zu ident f ieren, denn nicht jeder fehlgeschlage- ne Test bedeutet auch wirklich einen Fehler im Programm. Die Ursache kann ebenso in einem fehlerhaften Test, an einer ungenauen Spez fka ion oder an einem Durchführungsfehler des Testers liegen.

Nach einem Testlauf korrigierte Fehler sollten in jedem Fall erneut überprüft werden, genau so wie eine Überprüfung auf ungewollte Seiten f kte ratsam ist. Ob und wie oft dies geschieht, ist abhängig von den zur Verfügung stehenden Ressourcen.

Hier ist eine automatisierte Testdurchführung natürlich von Vorteil, da sie bei wiederholten Tests deutlich weniger Ressourcen benötigt als das manuelle Testen. Außerdem besteht beim Testen durch Menschen auch immer ein erhöhtes Fehlerrisiko, da ein Mensch sich nicht unbegrenzt konzentrieren kann und die Aufmerksamkeit gerade bei monotonen, sich stetig wiederholenden Aufgaben schnell nachlässt.

Allerdings muss auch eine Testautomatisierung zunächst implementiert werden, was anfangs wiederum einen höheren Ressourcenbedarf mit sich bringt. Bei dieser Implementierung können Fehler gemacht werden, die sich dann auf die Testergebnisse auswirken. Deswegen ist es sinnvoll, auch auto- matische Tests zu testen, was weitere Ressourcen in Anspruch nimmt. Dies ist bei der Entscheidung für automatische Tests zu berücksichtigen und ent- sprechend vorher einzuplanen.

Die Realisierungs- und Durchführungsphase endet mit dem Erreichen von einem der Testendekriterien. Wie bereits in Abschnitt 2.1.1 erläutert, muss dies kein Qualitätskriterium sein, sondern kann auch ein wirtschaftli- ches Kriterium sein. Deshalb kann es auch passieren, dass mit dem Ab- schluss dieser Phase nicht alle Tests vollständig durchgeführt worden sind.

2.1.4 Auswertung und Bericht

Dieser Abschnitt erläutert die Auswertungs- und Berichtphase des fundamentalen Testprozesses nach [SL10, S. 30 - 32]. In dieser Phase werden die Ergebnisse der voran gegangenen Phase analysiert und an die zuständigen Personen weitergeleitet.

Das Kernelement der Auswertungsphase ist die Frage nach der Erfüllung der Testendekriterien. Wie in Abschnitt 2.1.3 erwähnt, endet die Durchfüh- rungsphase mit dem Erreichen eines der Endekriterien. Daher ist es not- wendig, zu überprüfen, ob es mehr als ein Endekriterium gibt und wenn ja, ob auch alle weiteren Endekriterien erreicht wurden. Falls dies der Fall ist, können die Testaktivitäten beendet werden und der Testprozess kann in die Abschlussphase übergehen.

Falls hingegen mindestens ein Testendekriterium nicht erreicht wurde, ist eine genauere Auswertung der Gründe dafür notwendig. Diese Gründe können bereits in der Planungsphase liegen, wenn für die Erreichung der Qualitätskriterien zu wenig Ressourcen eingeplant wurden. Um solch eine Fehlplanung in Zukunft besser vermeiden zu können, werden die Informationen aufbewahrt und in zukünftige Planungsphasen mit einbezogen. Ein weiterer möglicher Grund für das Verfehlen der Testendekriterien kann auch eine ungenaue Spez fka ion der Testfälle sein. In diesen Fällen ist ein erneuter Durchlauf der verantwortlichen Phasen angebracht. Dazu folgt nach Abschluss der Auswertungs- und Berichtphase der alternative Übergang in die Analyse- und Designphase.

Weiterhin gibt es auch die Möglichkeit, dass das Endekriterium selbst zu hoch gewählt wurde, sodass es nicht mit angemessenem Aufwand erreicht werden kann. Diese Aufwand-Nutzen-Bewertung ist ein weiterer wichtiger Bestandteil der Auswertungsphase. So muss genau abgewogen werden, ob ein erneuter Durchlauf der anderen Phasen überhaupt wirtschaftlich und sinnvoll ist.

Mit Abschluss der Auswertungsphase werden die zuvor gesammelten Analysen gesammelt und als Bericht verfasst. Dieser Bericht ist eine wichti- ge Grundlage für die nachfolgende Phase, unabhängig davon, ob es sich um die Abschlussphase oder um den erneuten Durchlauf der voran gegangenen Phasen handelt.

2.1.5 Abschluss

Diese Abschlussphase ist die letzte Phase des fundamentalen Testprozesses nach [SL10, S. 33]. Sie dient der Nachbereitung der in den voran gegangenen Phasen gemachten Erfahrungen und dem Lernen aus eben jenen. Sie wird nachfolgend erläutert.

Um aus gemachten Erfahrungen lernen zu können, müssen diese in jedem Falle ausreichend dokumentiert werden. Dazu eignet sich auch der in der Auswertungs- und Berichtphase erstellte Abschlussbericht. Besonders gemachte Fehler sind in dem Bericht nachvollziehbar zu beschreiben, um sie beim nächsten Testprozess nicht zu wiederholen.

Der andere wichtige Aspekt der Abschlussphase ist die Pfege der Test- mittel über das Ende der Testaktivitäten hinaus. So ist es ratsam, die Test- werkzeuge auf dem neuesten Stand zu halten, um Komplikationen bei einer erneuten Benutzung zu vermeiden. Genau so empfehlt sich eine Weiterver- wendung der automatisierten Tests, da diese mit sehr geringem Aufwand weiter betrieben und beim nächsten Testprozess erneut verwendet werden können.

2.2 Testarten und Testbenennung

Darüber, ob überhaupt getestet wird, sollte nicht diskutiert werden, wenn man gute Software schreiben möchte. Wohl aber darüber, welche Testarten zur Anwendung kommen und welchen Aspekt der Software man überhaupt testen möchte. Dabei gibt es einige unterschiedliche Ansätze, von denen die für diese Arbeit relevanten im folgenden kurz erläutert werden. Die Unterabschnitte gliedern sich dabei in die verschiedenen Möglichkei-ten der Testbenennung [SL10, S. 11]. In der Softwareentwicklung kann der selbe Test mehrere Bezeichnungen haben, je nachdem, aus welchem Blick-winkel der Test betrachtet wird. So gibt zum Beispiel die Bezeichnung Mu-tationstest nur Auskunft darüber, welche Testmethode angewandt wird, nicht aber darüber, welches Ziel der Test verfolgt oder auf welcher Teststufe diese Tests stat fnden.

2.2.1 Teststufe

Organisiert man die Softwareentwicklung in Anlehnung an ein Vorgehensmodell wie zum Beispiel das V-Modell nach [Boe79, S. 4, Fig. 2], können die Tests in verschiedene Teststufen eingeteilt werden. Eine Stufe gibt darüber Auskunft, in welcher Phase der Entwicklung man sich gerade b fndet [SL10, S. 11]. In Abbildung 3 ist ein Ausschnitt des V-Modells dargestellt, wobei die verschiedenen Teststufen rot hervorgehoben sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Das V-Modell nach [Boe79, S. 4, Fig. 2].

[...]

Ende der Leseprobe aus 59 Seiten

Details

Titel
Evaluation der Leistungsfähigkeit ausgewählter Mutationstestwerkzeuge
Hochschule
Universität Hildesheim (Stiftung)
Note
1,0
Autor
Jahr
2014
Seiten
59
Katalognummer
V335396
ISBN (eBook)
9783668255418
ISBN (Buch)
9783668255425
Dateigröße
1466 KB
Sprache
Deutsch
Schlagworte
Mutationstests, Mutationstestwerkzeuge, Softwaretests
Arbeit zitieren
Lea Kristin Gerling (Autor), 2014, Evaluation der Leistungsfähigkeit ausgewählter Mutationstestwerkzeuge, München, GRIN Verlag, https://www.grin.com/document/335396

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Evaluation der Leistungsfähigkeit ausgewählter Mutationstestwerkzeuge



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden