Stefan Schmerler - Softwaretest in der Praxis

Abb. 1-14: Steckbrief Mutationentest

1.3.6.5 Evolutionärer Test

Ein Traum wird wahr.

Ein besonders interessanter und eher forschungsorientierter testmethodischer Ansatz ist die evolutionäre Testfallableitung. In der Praxis hinter dem funktionalen Test zurückbleibend, wird ein Verfahren zur vollautomatischen Testfallgenerierung verfolgt – dem Traum jedes Testverantwortlichen.

vollautomatische Testgenerierung für

Funktions-, Struktur- und Realzeittest

Den evolutionären Testverfahren ist im weiteren Verlauf dieses Buchs ein eigenes Kapitel gewidmet, deshalb sei hier nur festgehalten, dass sich diese Methodik der Testfallableitung für verschiedene Anwendungen von Funktionstest über Strukturtest bis hin zum Realzeittest (z. B. Ermittlung der längsten Ausführungszeit, Worst Case Execution Time) eignet. Genetischen Algorithmen folgend werden zielgerichtet Stimuli iterativ so lange immer weiterentwickelt und (im Hinblick auf die Eigenschaft, ein Fehlverhalten hervorzurufen) optimiert, bis ein Fehler auftritt, das SUT quasi »gebrochen« wurde. Gelingt die Herbeiführung eines Fehlverhaltens nicht in einer gewissen Zeit, weist das System den Fehler mit hoher Wahrscheinlichkeit auch nicht auf und das Verfahren bricht ab.

Evolutionäre Verfahren zeichnen sich dadurch aus, dass man nur sehr wenig über das SUT wissen muss (Black Box) und eine Eignung für große Parameterräume bei vollständiger Automatisierbarkeit vorliegt.

Abb. 1-15: Steckbrief evolutionärer Test

1.3.7 Back-to-Back-Test und Testorakel

Beim Einsatz von automatisierten Methoden zur Testfallableitung ist es natürlich erforderlich, zu den erlangten Testfällen auch die Ermittlung der spezifikationskonformen (also korrekten) Antworten sowie auch die Testbewertung automatisieren zu können.

Wie funktioniert ein Testorakel?

Systeme zur Ermittlung spezifikationskonformer Antworten bezeichnet man als Testorakel. Beim Soll-/Istwert-Vergleich unterstützen sie bei der Feststellung der Sollwerte. Dies ist nicht in allen Fällen möglich, es wird z. B. nicht gelingen, aus einem Lastenheft diese Informationen automatisiert zu extrahieren. Je nachdem, in welcher Weise die Spezifikation vorliegt, ergeben sich allerdings gewisse Möglichkeiten der Automatisierung.

Ein Testorakel kann z. B. ein ausführbarer Prototyp eines Lastenhefts sein. In der Tat werden oftmals statt eines textuellen Lastenhefts ausführbare Modelle vom Auftraggeber an den Zulieferer übergeben, die exemplarisch die wesentlichen Aspekte des zu implementierenden Verhaltens aufweisen – allerdings nur als Hülle und ohne reale Implementierung. Auch auf Robustheitsmaßnahmen wird hier weitgehend verzichtet. Liegt ein derartiger ausführbarer Prototyp vor, kann er als Testorakel genutzt werden.

Back-to-Back-Tests arbeiten

nur scheinbar redundant ...

Ein weiteres Einsatzgebiet für Testorakel ist der Back-to-Back-Test. Das zu testende Programm wird zweimal parallel und unabhängig voneinander erstellt. Jede Version wird mit denselben Testdaten beaufschlagt. Bei unterschiedlichen Ergebnissen ist eine Version fehlerhaft. Nur diejenigen Fehlerzustände, die in beiden Versionen mit selber Fehlerwirkung vorhanden sind, bleiben unentdeckt.

... und sind vor allem voll-

ständig automatisierbar!

Der Vorteil eines Back-to-Back-Tests ist die Automatisierbarkeit. Es ist ein Leichtes, beide Programmversionen mit denselben Testdaten zu beaufschlagen und die Antworten zu vergleichen.

Warum, so fragen Sie, sollte aber jemand auf die Idee kommen, dasselbe Programm zweimal zu entwickeln? Die Antwort lautet: Wenn Aufwände eine untergeordnete Rolle spielen, z. B. bei hochsicherheitskritischen Systemen. Die Wahrscheinlichkeit, dass dieselben Fehler bei unabhängigen Entwicklungen unterlaufen, ist vergleichsweise gering. Werden diese Programmversionen im Betrieb eingesetzt, spricht man von heterogener Redundanz. Dies ist z. B. bei Flugsteuerungen der Fall. Mehrere Einheiten (z. B. drei) bearbeiten dieselbe sicherheitskritische Aufgabe, und wenn alle Systeme zum selben Ergebnis führen (ein einfacher Vergleich genügt), wird das Ergebnis akzeptiert. Falls ein System abweicht, nimmt man das Ergebnis der beiden anderen übereinstimmenden.

homogene/heterogene Redundanz

Während sich die heterogene Redundanz als robust gegen Entwurfs- und Implementierungsfehler erweist, zeigt sich die homogene Redundanz (exakt das gleiche System kommt mehrfach zum Einsatz) nur robust gegen den Ausfall einer Einheit (z. B. Hardwaredefekt). Auch beim autonomen Fahren wird sicheres Verhalten durch Redundanz erkauft.

1.4 Psychologische Aspekte des Testens

Ein Sprichwort sagt »Irren ist menschlich«, und so ist es nicht verwunderlich, dass Entwicklern bei einer so anspruchsvollen Aufgabe wie der Softwareerstellung Fehler unterlaufen. Entscheidend ist die Art und Weise, wie Fehler im Unternehmen kommuniziert werden, sei es nun die Mitteilung eines Reifegrads an das Management oder die Information eines betroffenen Entwicklers durch die Testergruppe.

Fingerspitzengefühl und fakten-

orientierte Dokumentation

Die Art und Weise, wie dies erfolgt, kann für die Zusammenarbeit der betroffenen Personengruppen positive oder negative Auswirkungen haben. Es ist immer ein besonderes Fingerspitzengefühl gefragt, um zu vermeiden, dass die Kommunikation von Fehlerzuständen nicht als Kritik am Produkt und seinem Autor aufgefasst wird. Die Testergruppe darf auch nicht als Überbringer schlechter Botschaften für deren Inhalte verantwortlich gemacht werden. Gewisse soziale Kompetenzen helfen, dieses Konfliktpotenzial deutlich zu senken und den respektvollen Umgang miteinander aufrechtzuerhalten. Laute Töne oder gar Streit sind stets zu vermeiden, da sie nicht förderlich sind für eine gute Zusammenarbeit zwischen Entwicklern und Testern.

das Gute im Fehler sehen!

Erkannte Fehlerwirkungen sind positiv aufzufassen, nicht als persönliches Versagen der beteiligten Autoren – können die Fehler doch erst nach deren Finden behoben werden. Dies verbessert die Qualität des Testobjekts. Dem Management kann dieser Sachverhalt ebenfalls als eine Verminderung des allgemeinen Produktrisikos auf positive Weise kommuniziert werden.

aus Fehlern lernen

Ein positiver Seiteneffekt ist die Möglichkeit, dass der Entwickler anhand erkannter konkreter Fehlerbilder seine eigenen Fähigkeiten verbessert. Aus Fehlern kann und sollte man lernen!

Ebenso spielt auch die Art der Dokumentation eine Rolle bei der Kommunikation. Testergebnisse und andere Resultate sind stets neutral und faktenorientiert zu dokumentieren. Fehlerberichte und Reviewergebnisse müssen objektiv und tatsachenbasiert verfasst werden.

sich in die Rolle der anderen

Fraktion hineinversetzen

Ein weiterer wichtiger Aspekt für die konstruktive Zusammenarbeit von Entwicklern und Testern ist die Fähigkeit, sich in die Rolle des anderen hineinversetzen zu können. Entwickler benötigen Testwissen und Tester benötigen Kenntnisse aus der Entwicklung. Dies ist sowohl fachlich von erheblichem Nutzen als auch bedeutsam für eine konstruktive Umgangsweise miteinander. Entwickler erwerben die Möglichkeit, ihre Testmethodik über die eines klassischen Entwicklertests hinaus zu verbessern und ihre Arbeit aus dem Blickwinkel der Testergruppe zu betrachten. Einer bei Entwicklertests häufig anzutreffenden Blindheit gegenüber den eigenen Fehlern kann hierdurch entgegengetreten werden.