Einführung automatisiertes Testen

... [ Seminar "Haskell" ] ... [ Inhaltsverzeichnis ] ... [ zurück ] ... [ weiter ] ...

Die Motivation für das Testen von Software ist der Wunsch nach fehlerfreien Programmen.

Die Korrektheit von Software kann auf zwei Arten belegt werden, bzw. versucht werden zu belegen:

Formaler Beweis oder Test.

Hier finden wir das Spannungsfeld, dessen Qualitäten die weiter unten folgenden Zitate verdeutlichen.

Der Beweis ist aufwendig und nicht immer möglich, bzw. bekannt, im Besonderen bei umfangreicheren Programmen. Dieser Sachverhalt stellt in diesem Zusammenhang eines der großen Probleme dar.

Nach Modifiktion des Programmes ist ein neuer Beweis notwendig. Dieser unterliegt wiederum den oben genannnten Problemstellungen. (Es sei noch einmal explizit darauf hingewisen, dass auch durch minimale Modifikation des Programmes sich der Beweis verändern wird.)

Die Alternative zum Formalen Beweis der Korrektheit von Programmen ist der Test.

Dieser kann bezüglich seiner Aussage und Aussagekraft jedoch nicht direkt mit einem Beweis verglichen bzw. gleichgesetzt werden. Der Test kann nicht als Beweis gesehen werden, sondern lediglich als ein Versuch oder Ansatz eine Aussage bezüglich der Korrektheit von Programmen treffen zu können, die eine gewisse Zuverlässigkeit, Aussagekraft und Glaubhaftigkeit aufweist.

Die Motivation für automatisiertes Testen liegt in dem Wunsch bzw. der Forderung nach hoher Zuverlässigkeit, Aussagekraft und Glaubhaftigkeit bei minimalem Aufwand für die Überprüfung.

Vor allem nach Modifikation am Programmteilen stellen wiederholbare Testläufe einen erheblichen Vorteil dar.

Zitate zu allgemeinen Eigenschaften von Tests und Testverfahren:

mit diesem Satz im Bewustwein sollte die folgende Ausarbeitung gelesen werden.

In diesem Rahmen sollen die Begrifflichkeiten im Umfeld des automatisierten Testens vorgestellt werden.

Die hier angeführeten Begriffe entstammen der Literatur und gehorchen keiner klaren Begriffsbildung und sind somit nur vage umrissen.

Es sind hier zwei Arten von Begriffen zu unterscheiden.

beschreiben unterschiedliche Testformen; die sich alle auf die Korrekheit der Software (im Sinne einer Spezifikaztion) beziehen.

Die Begriffe Modultest bzw. UnitTest sind eng verknüpft mit den imperativen Programmiersprachen. Die Namensgebung "Modul" / "Unit" orientiert sich an der Strukturierung der Sprachen.

Es werden also kleinste Einheiten - Prozeduren und Funktionen innnerhalb von Modulen bzw. Units getestet.

Aus dem Bereich der objektorientierten Sprachen stammt der Begriff Komponententest. Die Ebene der Betrachtung sind in diesem Fall die Komponenten - wie sie beispielsweise in Java über JavaBeans realisiert sind. Die Test überprüfen auf der Ebene der Komponente die Korrektheit der Software.

Integrationstest und Interaktionstest zielen im Sinne des Integerations- bzw. Interaktionstest auf das Zusammenspiel von mehreren Komponenten oder im Sinne des Interaktion auf die SW / Nutzer Schnittstelle ab.

beschreiben Tests die über diesem Rahmen hinausgehen.

Der Akzeptanztest beschreibt die Überprüfung des Grades der Überdeckung der Erwartungen von Nutzern an Software im Sinne der Funktionalität und der Art und Weise wie diese zur Verfügung gestellt wird.

Der Performancetest und der Lasttest dient zur Überprüfung des korrekten, erwartungskonformen Verhalten von Software und Softwaresystemen unter besonderen Bedingungnen. Diese Testformen können als zusätzliche Messinstrumente für die Bestimmung der Qualität von Software herrangezogen werden.

Im Zusammenhang mit automatisiertem Testen spielt eXtreme Programming (XP) eine besondere Rolle.

Als Extreme Programming wird eine noch junge Methodik in der Softwareentwicklung bezeichenet.

Ihr Initiator Kent Beck hat sie vor ca. 6 Jahren 1997/1998 in das Bewustsein der Entwicklergemeinde gerückt. Es handelt sich bei XP um einen sogenannten "leichtgewichtigen, agilen Entwicklungsprozess", bei dem die klassische Analyse- und Design-Methodiken dem evolutionärem Design weicht, welches dem Kunden mehr Möglichkeiten zur Mitgestaltung bietet.

Mit diesem Ansatz soll unter anderem die Planbarkeit der Softwareentwicklung und der mit ihr jeweils verbundenen Projekte verbessert werden.

Auf Grund dieses Potentials wird und wurde der Ansatz intensiv diskutiert und erprobt, so dass die Ideen und Konzepte hinter XP in der

Entwicklergemeinde eine entsprechende Verbreitung finden.

Einige mit XP verbundene Techniken und Methodiken sind das Pair Programming, das Refactoring, und die entwickliungsbegleitende Durchführung von

Komponententests.

Von dem Ansatz des Pair Programming versprechen sich die Anhänger der XP Methodik ständigen Review des Sourcecodes und somit weiniger Fehler und mehr Konsistenz als durch das in wechselnden Zweier-Teams erfolgende Entwickeln die Verbreitung von Wissen.

XP sieht ein kleinschrittiges Vorgehen vor, bei dem User Stories in Tasks und Tasks in Untertasks (Mikroschritte) aufgebrochen werden. Durch das kleinschrittige Vorgehen soll erreicht werden, dass die Software die minimale Komplexität für die derzeit geforderte Funktionalität aufweist und

somit die Wartbarkeit erzwungen wird. Unter Refactoring versteht man in dem Kontext von Extrem Programming das ständige Umstrukturieren des Sourcecode mit dem Ziel das möglichst einfacheste Design zu erzeugen. Hierbei wird "Einfaches Design wie folgt beschrieben: Code kommuniziert

Designkonzepte; dh. keine Redundanz, min. Klassen u. Methoden.

Der Leitsatz "Test first" mit dem die Durchführung von Komponententests als zentrale Tätigkeit im Entwicklungszyklus eingefordert wird, zeigt die besondere Rolle von eXtreme Programming im Zusammenhang mit automatisiertem Testen auf.

... [ Seminar "Haskell" ] ... [ Inhaltsverzeichnis ] ... [ zurück ] ... [ weiter ] ... [ nach oben ] ...