Belegarbeit: Methoden und Techniken zur Qualitätssicherung

Transkript

1 Fachhochschule für Technik und Wirtschaft Berlin Fachgebiet Informationsmanagement Belegarbeit: Methoden und Techniken zur Qualitätssicherung Eingereicht von: Markus Menzel Matrikel-Nr Steffen Knieling Matrikel-Nr Lehrbeauftragter: Prof. Dr. Pietsch Berlin,

2

3 Vorwort Der Unternehmenserfolg hängt in sämtlichen Bereichen zunehmend von IT-Infrastrukturen und damit von der Prozessunterstützung durch die Informationstechnologie im Unternehmen ab. Trotz steigender Komplexität der Software muss gewährleistet sein, dass IT-gestützte Systeme zuverlässig funktionieren. Eine unzureichende Qualitätssicherung während der Software-/Systementwicklung kann zu hohen Personen- und Sachschäden führen und die Kosten für die Entwicklung und Wartung in die Höhe treiben. Der Test ist das wichtigste und gebräuchlichste Prüfverfahren. In dieser Ausarbeitung werden Methoden und Techniken vorgestellt, die die korrekte Funktionsweise von Software-Anwendungen sicherstellt. Bei der Durchführung von Software-Tests ist zu überprüfen, ob das Testobjekt mit ausgewählten Eingabeparametern in der Anwendung fehlerfrei reagiert. Das Ziel eines Tests ist es, eine Aussage darüber zu treffen, welchen Zustand das Testobjekt nach Beendigung besitzt. Dabei kann das Ergebnis 2 Zustände annehmen: 1. Fehler in Anwendung entdeckt und 2. Anwendung reagiert erwartungsgemäß. Je nach Zustand erfolgt nach dem Test ein Re-Test, Fehler wurde behoben, bzw. ein Regressionstest, erneuter Nachweis auf Korrektheit nach Veränderung der Anwendung. Zunächst wird die Qualitätssicherung als Bestandteil des Qualitätsmanagements näher erläutert. Schließlich wird am Ende der Belegarbeit ein Beispiel, aus einem realen Projekt, für einen systematischen Test mit der Klassifikationsbaum-Methode herangezogen. An dieser Stelle möchten wir die Gelegenheit nutzen uns bei der DaimlerChrysler AG für die Kooperation und Bereitstellung von Werkzeugen zu bedanken. Markus Menzel / Steffen Knieling Seite 3 von 34

4 Inhaltsverzeichnis 1 Begriff der Qualitätssicherung Qualitätssicherung als Bestandteil des Qualitätsmanagements Qualitätspolitik Qualitätsplanung Qualitätsverbesserung Qualitätssteuerung Qualitätssicherung Klassifikation von Prüfverfahren Softwaretests als dynamischer Test Klassifikationsbaum-Methode Einordnung der Klassifikationsbaum-Methode Klassifikationen Funktionsweise von Klassifikationsbäumen Vorgehensmodell zum Aufstellen eines Klassifikationsbaums Techniken der Qualitätssicherung Definition von Testfällen Automatisiertes Testen Werkzeuge des Testmanagements Praktische Anwendung Fazit...33 Markus Menzel / Steffen Knieling Seite 4 von 34

5 Abbildungsverzeichnis Abbildung 1: Modell eines prozessorientierten Qualitätsmanagementsystems...8 Abbildung 2: Qualitätsmerkmale nach ISO Abbildung 3: Testphasen im Softwaretest...17 Abbildung 4: Klassifikationsbaum...22 Abbildung 5: Kombination von Klassen in einem K-Baum...23 Abbildung 6: Modellierung eines K-Baums im Classification Tree Editor...26 Abbildung 7: Generieren von Testfällen mit dem Classification Tree Editor...27 Abbildung 8: Trennung von Testskript und Testdaten...29 Abbildung 9: Protokollierung eines Testergebnisses...30 Abbildung 10: Anforderungsdefinitionen im TestDirector...31 Tabellenverzeichnis Tabelle 1: Phasen des PDCA-Modells...7 Tabelle 2: Einfluss konstruktiver Maßnahmen auf die Qualitätsmerkmale...11 Tabelle 3: Klassen von Prüfverfahren und deren Ziele...12 Tabelle 4: Testverfahren...21 Tabelle 5: Vorgehensmodell der K-Baum-Methode...24 Definitionen Definition 1: Qualitätssicherung...6 Definition 2: Qualitätsmanagement...7 Markus Menzel / Steffen Knieling Seite 5 von 34

6 1 Begriff der Qualitätssicherung Der Begriff Qualitätssicherung ist nach wie vor ein oft fälschlich verwendeter Begriff. Eine ganze Reihe auch neuerer Publikationen, wie zum Beispiel (DGQ 1992), verstehen Qualitätssicherung als den Oberbegriff aller qualitätsbezogener Tätigkeiten und Zielsetzungen. Tatsächlich wurde der Begriff Qualitätssicherung 1990 durch den internationalen Ausschuss ISO/TC 176 neubewertet. Die Normen DIN und (DIN EN ISO 8402:1995) definieren Qualitätsmanagement als den neuen Oberbegriff. Qualitätssicherung ordnet sich nunmehr unter dem Qualitätsmanagement ein. 1 Qualitätssicherung wird in dieser Norm folgendermaßen definiert: Definition 1: Qualitätssicherung Qualitätssicherung bzw. QM-Darlegung beinhaltet alle geplanten und systematischen Tätigkeiten, die innerhalb des QM-Systems verwirklicht sind, und die wie erforderlich dargelegt werden, um ausreichendes Vertrauen zu schaffen, dass eine Einheit die Qualitätsforderungen erfüllen wird. Der Begriff der Qualitätssicherung wird zudem oft synonym zu den Begriffen Qualitätskontrolle und Qualitätsprüfung verwendet. (Hering 1999) geht davon aus, dass zumindest der Begriff der Qualitätsprüfung praktisch mit dem Begriff der Qualitätssicherung gleichzusetzen ist, da beide nur dem Zweck dienen, sicherzustellen, dass die Qualitätsanforderungen auch tatsächlich erfüllt worden sind. Innerhalb dieser Ausarbeitung wird detailliert darauf eingegangen, wie die Qualitätssicherung im Qualitätsmanagement einzuordnen ist und aus welchen Maßnahmen sie sich zusammensetzt. 1 Vgl. Qualitätsmanagement für Ingenieure, E. Hering, J. Triemel, H.-P. Blank (Hrsg), Springer Verlag, 1. Auflage 1999, ISBN: X, S.1 f Markus Menzel / Steffen Knieling Seite 6 von 34

7 2 Qualitätssicherung als Bestandteil des Qualitätsmanagements Um Qualitätssicherung in das Qualitätsmanagement einzuordnen, ist es notwendig, einen kurzen Überblick über das Qualitätsmanagement und seine Bestandteile zu geben. Wie der Begriff Qualitätssicherung ist auch der Begriff des Qualitätsmanagements in (DIN EN ISO 8402:1995) genau definiert. Definition 2: Qualitätsmanagement Qualitätsmanagement (QM) (quality management) umfasst sowohl die Arbeitsmittel zur Erfüllung der Qualitätsforderungen (quality control), als auch die Qualitätssicherung (QS) im Sinne der QM-Darlegung (quality assurance), ebenso die Qualitätspolitik, Qualitätsplanung und Qualitätsverbesserung. Somit kann man folgende Bestandteile des Qualitätsmanagements identifizieren: Qualitätspolitik Qualitätsplanung Qualitätssteuerung Qualitätssicherung Qualitätsverbesserung In den Anmerkungen zur (ISO/TS 16949:2002/1) wird die Definition des Qualitätsmanagements in einem prozessorientierten Ansatz in Form des PDCA-Modells umgesetzt. PDCA steht dabei für Plan-Do-Check-Act oder übersetzt für Planen-Durchführen- Prüfen-Handeln. Tabelle 1 beschreibt die Phasen und ordnet ihnen die Bestandteile des Qualitätsmanagements zu. Tabelle 1: Phasen des PDCA-Modells Phase Beschreibung QM-Bestandteil Planen (plan) Festlegen der Ziele und Prozesse, die zum Erzielen von Ergebnissen in Übereinstimmung mit den Kundenanforderungen und den Politiken der Organisation notwendig sind. Qualitätspolitik Qualitätsplanung Durchführen (do) Verwirklichen der Prozesse Qualitätssteuerung Markus Menzel / Steffen Knieling Seite 7 von 34

8 Phase Beschreibung QM-Bestandteil Prüfen (check) Handeln (act) Überwachen und Messen von Prozessen und Produkten anhand der Politiken, Ziele und Anforderungen an das Produkt sowie Berichten der Ergebnisse. Ergreifen von Maßnahmen zur ständigen Verbesserung der Prozessleistung. Qualitätssicherung Qualitätsverbesserung Quelle: Vgl. Qualitätsmanagementsysteme, Besondere Anforderungen bei Anwendung von ISO 9001:2000 für die Serien- und Ersatzteil-Produktion in der Automobilindustrie, DIN; ISO, IATF 200, S. XV Abbildung 1 stellt die verschiedenen QM-Bestandteile in einem Prozess grafisch dar. Abbildung 1: Modell eines prozessorientierten Qualitätsmanagementsystems Quelle: Vgl.: (ISO/TS 16949:2002/1, S. XVI) Nachfolgend sollen die verschiedenen QM-Bestandteile kurz erläutert werden, um zu veranschaulichen, was mit ihnen gemeint ist und um im weiteren Verlauf den Unterschied zur Qualitätssicherung deutlich zu machen. Der Bestandteil Qualitätssicherung wird daraufhin in einem eigenen Hauptkapitel ausführlicher beschrieben. Markus Menzel / Steffen Knieling Seite 8 von 34

9 2.1 Qualitätspolitik Das Festlegen der Qualitätspolitik ist ein Prozess, auf den die strategische Ausrichtung des Konzerns einen bedeutenden Einfluss hat. Hier werden im Abgleich mit anderen Unternehmenszielen, wie z.b. Technologieführerschaft oder Preisführerschaft, die Bedeutung des Faktors Qualität beschrieben sowie langfristige, strategische Ziele festgelegt und priorisiert, die erreicht werden sollen. 2.2 Qualitätsplanung Während die Qualitätspolitik noch recht abstrakt ist und oft nur einen unternehmensweiten Leitfaden darstellt, geht die Qualitätsplanung weiter und beschreibt den Prozess des Qualitätsmanagements anhand konkreter Schritte und Qualitätsziele. Weiterhin werden hier bereits Verantwortungen festgelegt. 2 (ISO :2001) gibt dabei anhand eines prozessorientierten Modells eine ganze Reihe Vorgaben für Qualitätsmerkmale, nach denen sich auch DaimlerChrysler im Bereich Research and Technology richtet. 3 Eine Darstellung dieser Merkmale gruppiert nach Funktionalität, Zuverlässigkeit, Benutzerfreundlichkeit, Effizienz, Wartbarkeit / Änderbarkeit und Portabilität findet sich in Abbildung 2. Abbildung 2: Qualitätsmerkmale nach ISO Quelle: Vgl. (PitRix 2004) 2.3 Qualitätsverbesserung Die Qualitätsverbesserung stellt die Aufgabe dar, stetig die geforderten Qualitätsziele sowie die Maßnahmen zur Umsetzung entsprechend den Unternehmens- und Kundenzielen als auch den sich ändernden Umweltbedingungen anzupassen. Dazu zählt auch 2 Vgl. Qualitätsmanagement (QM), Abruf am Gespräch mit Herrn R. Pitschinetz von der DaimlerChrysler AG- Research and Technology am Markus Menzel / Steffen Knieling Seite 9 von 34

10 das Nichterreichen von Qualitätszielen zu evaluieren und Schwachstellen ausfindig zu machen, um ihnen mit einer veränderten Qualitätsplanung entgegenzuwirken. 2.4 Qualitätssteuerung Um den durch das Management und den Kunden vorgegebenen Qualitätsanforderungen gerecht zu werden, bedarf es einer Auswahl an Methoden und Verfahren, deren Einsatz während des Softwareentwicklungsprozesses sicherstellt, dass die Qualitätsmerkmale auch in der gewünschten Ausprägung erreicht werden können. Diese Methoden und Verfahren, die hauptsächlich den operativen Betrieb betreffen, fast man oft auch als konstruktive Maßnahmen zusammen. Sie bilden damit das Rückrad der Qualitätssteuerung. Als Beispiele für konstruktive Maßnahmen sollen folgende Methoden bzw. Verfahren dienen: Anwendung von Vorgehensmodellen (z.b. das V-Modell) Definition und Umsetzung von Dokumentenstandards Einsatz von Glossaren und DataDictionaries Auswahl von geeigneten Spezifikations- und Analyseverfahren Verwendung von bestimmten Programmierstandards und -sprachen Einsatz ausgewählter Bibliotheken Codegenerierung durch Programmgeneratoren Sicherung der Dateien über ein Versions- und Konfigurationsmanagement Konstruktive Maßnahmen zur Qualitätssteuerung beschäftigen sich demzufolge damit, Methoden und Verfahren auszuwählen und einzusetzen, die zu einer bestmöglichen Erreichung der geforderten Qualitätsmerkmale befähigen. Um die Auswahl geeigneter Maßnahmen und Verfahren zu vereinfachen, kann man die geforderten Qualitätsmerkmale und die möglichen konstruktiven Maßnahmen und Verfahren in einer Matrix gegenüberstellen und deren Einfluss auf die Qualitätsmerkmale bewerten. Somit ist es leichter zu bestimmen, welche Maßnahmen zu treffen sind. Ein Beispiel für eine solche Matrix ist in Tabelle 2 abgebildet. Markus Menzel / Steffen Knieling Seite 10 von 34

11 Tabelle 2: Einfluss konstruktiver Maßnahmen auf die Qualitätsmerkmale Konstruktive Maßnahmen Dokumentenstandards Glossar Data Dictionary Structured Analysis (als ein Analyseverfahren) + + Formale Spezifikation (als ein Spezifikationsverfahren) Rapid Prototyping Programmierstandards + + Programm-Bibliothek Programm-Generatoren Versions- und Konfigurationskontrolle + Quelle: (DGQ 1992, S. 55) DaimlerChrysler erweitert diese Sicht noch um eine Dimension, indem es davon ausgeht, dass die Qualitätsmerkmale Interdependenzen unterliegen. So bedingt beispielsweise die Verständlichkeit eines Softwaresystems auch dessen Wartbarkeit. 4 Anpassbarkeit Benutzerfreundlichkeit Effizienz Funktionsabdeckung Instandsetzbarkeit Korrektheit Auf Grundlage dieses Wissens kann sichergestellt werden, dass die vom Management als auch die vom Kunden vorgegebenen Qualitätsmerkmale durch den Einsatz geeigneter Maßnahmen im Softwareentwicklungsprozess selbst erreicht werden können. Da die Durchführbarkeits- und Risikoanalyse zum Teil auch auf ähnlichen Überlegungen beruhen, ist eine strikte Abgrenzung zur Qualitätsplanung nicht immer möglich. 5 4 Standards Übersicht, Vortrag von R. Pitschinetz, DaimlerChrysler, RIC/SM Vgl. Methoden und Verfahren der Software-Qualitätssicherung Arbeitsgruppe 13 Qualitätssicherung der DV der Deutschen Gesellschaft für Qualität e.v. und Informationstechnische Gesellschaft im VDE (ITG), 1. Auflage 1992, Beuth-Best.Nr.: 32840, S. 54) Markus Menzel / Steffen Knieling Seite 11 von 34

12 3 Qualitätssicherung Die Qualitätssicherung grenzt sich von den anderen QM-Bestandteilen dadurch ab, dass sie hauptsächlich analytische Verfahren einsetzt, mit Hilfe derer im Nachhinein die (Zwischen-) Produkte überprüft werden. Zu den (Zwischen-) Produkten des Softwareentwicklungsprozesses zählen dabei Anforderungsdefinitionen und Datenflussmodelle genauso wie das eigentliche Programm. Entsprechend unterschiedlich sind die Verfahren, die zum Überprüfen eingesetzt werden. 3.1 Klassifikation von Prüfverfahren In diesem Abschnitt sollen die unterschiedlichen Prüfverfahren in verschiedene Klassen unterteilt werden. Die Klassen können anhand ihrer Ziele unterschieden werden. So werden Inspektionsverfahren angewendet, um in wenig formalisierten Dokumenten Fehler möglichst frühzeitig zu erkennen, zu lokalisieren und zu beheben. Statische Analysen zur Fehlerfindung ermöglichen es Fehler in der statischen Semantik zu finden. Das Beheben der Fehler wird durch diese Verfahren jedoch nicht in jedem Fall möglich sein. Bei den Testverfahren werden in der Regel nur Fehler erkannt. Über deren Ort oder Behebung kann keine Aussage gemacht werden. Einen etwas anderen Blickwinkel auf das Programm haben die Beweisverfahren. Ihr Ziel ist es die tatsächlichen Datenund Kontrollflüsse mit denen in der Spezifikation formulierten zu vergleichen. Es handelt sich daher nicht um einen Beweis, dass das Programm funktionstüchtig ist, da ja auch die Spezifikation bereits fehlerhaft gewesen sein könnte. Für diesen Zweck bilden Zustandsübergangsdiagramme eine geeignete Form der Darstellung und einen Ausgangspunkt für die Simulation. Bei DaimlerChrysler wird für diese Aufgaben MathLab in Verbindung mit Simulink eingesetzt. Tabelle 3: Klassen von Prüfverfahren und deren Ziele Prüfverfahrenklasse Fehlererkennung Fehlerlokalisierung Fehlerbehebung Anmerkungen Inspektionsverfahren Geeignet für wenig formale Objekte, wie z.b. Dokumente der Anforderungsdefinition. Statische Analyse zur Fehlerfindung Geeignet für formalisierte Semantik. Markus Menzel / Steffen Knieling Seite 12 von 34

13 Prüfverfahrenklasse Fehlererkennung Fehlerlokalisierung Fehlerbehebung Anmerkungen Testverfahren Geeignet beim Vorliegen des fertigen Programms. Beweisverfahren Es handelt sich hier um einen Abgleich der Zustände des Programms mit den formulierten Zuständen in der Spezifikation. Quelle: Vgl. (DGQ 1992, S. 84/99) Nachfolgend wird erläutert, für welche Anwendungsfälle innerhalb der Qualitätssicherung sich die Klassen von Prüfverfahren eigenen. Darüber hinaus werden immer ausgewählte Beispiele benannt und kurz erklärt Inspektionsverfahren Inspektionsverfahren wenden sich in erster Linie an wenig formalisierte Dokumente oder Programmmodule. Es wird davon ausgegangen, dass Dokumente von einem Menschen gelesen werden müssen. Die Analyse erfolgt hier also hauptsächlich auf einer semantischen Ebene. Eine Unterstützung durch Werkzeuge ist hier nur bedingt möglich. Oft erfolgen Inspektionen, indem sich Entwickler und Inspektoren treffen und z.b. Modulbeschreibungen oder Quellcode durchsehen. Um die Diskussion möglichst effektiv zu gestallten, gilt dabei als Empfehlung, die Gruppe der beteiligten Personen zwischen vier und sechs Personen zu halten und die Dauer der Sitzung auf nicht mehr als zwei Stunden zu begrenzen. 6 Hintergrund dieser Empfehlung ist, dass die Kommunikationsbeziehungen sonst zu komplex werden und nach zwei Stunden ein rapider Abfall der Konzentration zu beobachten ist. Kritisch anzumerken ist dabei, dass der Erfolg dieser Verfahren entscheidend von den (Kommunikations-) Fähigkeiten der beteiligten Personen abhängig ist und einen hohen Zeit- und Organisationsaufwand verursacht, da solche Inspektionen mit allen Personen zeitlich abgestimmt und auch innerhalb des Projekts zu bestimmten Anlässen fest eingeplant werden müssen. 6 Vgl. (DGQ 1992, S. 86) Markus Menzel / Steffen Knieling Seite 13 von 34

14 Beispiele: Inspektion nach Fagan Untersuchung eines Objektes anhand von Checklisten bzgl. Ablaufverhalten, Pfade der Ein- und Ausgabe, der Datenverwendung sowie kritischer Werte bei der Ein- und Ausgabe und internen Variablen Einsatzgebiet: Programmentwurf und Implementierung Meilensteinprüfung (Formal Review) Zusammentreffen des Managements mit den Entwicklern und den Vertretern der Benutzer. Es wird zunächst ein grober Überblick über die wesentlichen Dokumente gegeben, woraufhin anhand einer Tagesordnung bestehende Probleme i- dentifiziert und Maßnahmen zu deren Beseitigung entwickelt werden. Abschließend wird ein Ergebnisdokument erstellt und die entstandenen Aufgaben mit einer Fristsetzung den Verantwortlichen zugewiesen. Einsatzgebiet: Am Ende einer Phase zur Entscheidung über das weitere Vorgehen (Nachbesserung, Abbruch oder Fortsetzung) Statische Analyse zur Fehlerfindung Verfahren, die statische Aspekte der Semantik untersuchen, werden dem Bereich der statischen Analyse zugerechnet. Statisch bezeichnet hierbei, dass es sich um Aspekte handelt, die nicht von der Ausführung des Programms abhängig sind. Verschiedene Eingabedaten in Form von Testfällen werden hier nicht untersucht. Vielmehr wird überprüft, ob Beschreibungen, die nach formalen Regeln aufgebaut sein sollten, auch den geforderten Regeln entsprechen. Als Beispiel können Schnittstellendefinitionen zwischen verschiedenen Programmmodulen gelten. Bei DaimlerChrysler werden beispielsweise Tools eingesetzt, die überprüfen, ob sämtliche definierte Funktionen innerhalb eines C-Programms auch mit Beschreibungen ausgestattet sind. Diese Aufgaben lassen sich durch Werkzeuge (teil-) automatisieren. Oft ist jedoch ein manueller Eingriff nicht zu vermeiden, da für viele Fälle keine formalen Beschreibungen existieren. Um bei dem Beispiel von DaimlerChrysler zu bleiben: Es ist zwar möglich zu prüfen, dass eine Funktion dokumentiert ist, die Qualität der Dokumentation hängt jedoch auch von deren Inhalt ab, der jedoch äußerst schwer durch Tools bewertet werden kann. Beispiele: Anforderungsanalyse Anforderungen müssen dazu in formaler oder halbformaler Form vorliegen, z.b. als UML-Modelle. Einsatzgebiet: Anforderungs-/Festlegungsphase Markus Menzel / Steffen Knieling Seite 14 von 34

15 Codeanalyse Erkennen von Syntaxfehlern oder Verstöße gegen Programmierkonventionen, Typfehler, statische Fehler im Daten- und Kontrollfluss, durch eine Vielzahl von Werkzeugen unterstützt, z. T. sogar durch die Compiler selbst Einsatzgebiet: Konstruktionsphase Testverfahren Testverfahren stellen immer nur eine Stichprobe dar. Es wird ein bestimmtes Objekt zu einem festgelegten Zeitpunkt unter Verwendung bestimmter Eingabedaten untersucht. Anschließend erfolgt ein Abgleich der Ausgabewerte mit den erwarteten Werten. Die verschiedenen Varianten von Eingabedaten werden dabei auch Testfälle genannt. Testverfahren, wie der Black-Box-Test, bei denen die Durchführung und die Ergebnisse der Tests variabel sind und vom Verlauf des Programms abhängen, werden als dynamische Analysen bezeichnet. Dass Testverfahren nicht immer dynamischer Natur sind, zeigt der White-Box-Test. Hier werden anhand von formalen Strukturen, wie z.b. Quelltext, Abläufe sowie Daten- und Kontrollflüsse verfolgt. Aus diesen Kenntnissen werden dann Testfälle erstellt. Um zu halbwegs sicheren Aussagen zu kommen, ist der Einsatz von Werkzeugen zur Testfallgenerierung und -durchführung zumindest bei komplexeren Anwendungen unumgänglich. Im Abschnitt 5.1 Definition von Testfällen und 5.2 Automatisiertes Testen werden die bei DaimlerChrysler zu diesem Zweck zum Einsatz kommenden Tools CTE und Quicktest Professional vorgestellt. Problematisch im Bereich der Testverfahren ist, dass sie zwar Fehler aufdecken können, aber meist keine Möglichkeit zur Fehlerlokalisierung und -identifizierung bieten. Zudem lassen sich relativ sichere Aussagen über die allgemeine Korrektheit des Programms nur bei einem relativ kleinem Definitionsbereich der Eingabedaten machen. Schließlich werden nicht alle möglichen Fälle getestet, sondern in der Regel nur kritische Fälle. Aus diesem Grund wird die Bedeutung von Testverfahren oft überschätzt. Beispiele: Struktureller Test (White-Box Test) Durch Rückgriff auf die internen Programmstrukturen werden anhand von Daten- und Kontrollflüssen Testfälle erarbeitet und durchgespielt. Da die Anzahl der verschiedenen Pfade (if-else-anweisungen etc.) oft zu umfangreich ist, ist es schwierig wirklich Testfälle für alle Möglichkeiten durchzuführen. Funktionstest (Black-Box-Test) Hier werden ohne Kenntnis der inneren Strukturen des Programms Testfälle aus der entsprechenden Funktionsbeschreibung erarbeitet. Dies geschieht entweder durch Verwendung von Äquivalenzklassen oder durch Grenzwertanalysen. Eine Markus Menzel / Steffen Knieling Seite 15 von 34

16 genauere Beschreibung dazu findet sich im Kapitel 4.1 Einordnung der Klassifikationsbaum-Methode Beweisverfahren Im Wesentlichen bestehen die Beweisverfahren aus dem Verfahren der formalen Verifikation. Andere Verfahren, wie das der symbolischen Auswertung, den Beweisverfahren zuzurechnen, bezeichnet auch (DGQ 1995, S. 98) als problematisch. Ziel von Beweisverfahren ist es, die möglichen Zustände des Programms und deren Übergänge abzubilden. Zustandsübergänge sind dabei an Bedingungen geknüpft und lösen ggf. Ereignisse aus, die wiederum andere Zustände aktivieren können. Hat man das Zustandsübergangsdiagramm für das Programm erstellt und vergleicht es mit der Spezifikation des Programms, so lassen sich zum einen fehlerhafte Zustände im Programm, aber auch logische Widersprüche innerhalb der Spezifikation aufdecken. Bei DaimlerChrysler wird dieses Verfahren auch Modelltest genannt und kommt insbesondere bei komplexen Anforderungen in einer recht frühen Phase des Software- Entwicklungsprozesses zum Einsatz. 3.2 Softwaretests als dynamischer Test Nachdem ein Überblick über die Klassen der Prüfverfahren gegeben wurde, soll in diesem Abschnitt ein ausgewähltes Testverfahren ausführlicher beschrieben werden. Es werden zunächst die Phasen für einen Softwaretest dargestellt und anschließend die Vorgehensweise zur Durchführung näher erläutert. Markus Menzel / Steffen Knieling Seite 16 von 34

17 3.2.1 Testphasen Abbildung 3: Testphasen im Softwaretest Quell: Vgl. (DGQ 1995, S.80) u. (ASQF 2003, S.6/7) Die Testphasen, die es während der Entwicklung eines Softwareprodukts geben kann, lassen sich am einfachsten durch ihre Stellung im V-Modell veranschaulichen. Aus Abbildung 3 lassen sich folgende Testphasen identifizieren: Modultest Integrationstest Systemtest Modultest Ausgangspunkt für den Modultest ist die kleinste, unabhängig ausführbare Einheit des Softwareprogramms, das Modul. Dabei wird die Implementierung des Moduls in einer geeigneten Testumgebung mit seiner Spezifikation verglichen. An dieser Stelle kommen auch die verschiedenen Testverfahren, der Black-Box-Test und der White-Box- Test, zum Einsatz. Der Black-Box-Test stellt dabei die funktionale Abdeckung der Anforderungen sicher, während der White-Box-Test auch die strukturellen Faktoren, wie die Kontroll- und Datenflüsse im Quellcode, untersucht. Integrationstest Hierbei werden die Module Schritt für Schritt nach einer vordefinierten Integrationsstrategie zu einzelnen Subsystemen bis hin zur Gesamtsoftware zusammengeführt. Es wird Markus Menzel / Steffen Knieling Seite 17 von 34

18 dabei getestet, ob die Module so zusammenarbeiten, wie es der Grobentwurf vorsieht. Hinsichtlich der Strategien kann man folgende Fälle unterscheiden: Incremental Hier wird ein noch nicht getestetes Modul zum Testen zu einer Sammlung bereits getesteter Module hinzugefügt. Non-Incremental Wenn nicht zu viele Abhängigkeiten zwischen den Modulen bestehen, können die Module unabhängig voneinander getestet werden und in einem Schritt zu einem größeren Block zusammengefügt werden. Top-Down Hier wird davon ausgegangen, dass zunächst die Steuerprogramme getestet werden, bevor die von ihnen aufgerufenen Module hinzugefügt werden. Bottom-Up Diese Strategie bildet den Gegensatz zur Top-Down Strategie. Dabei werden zuerst die aufgerufenen Module getestet und anschließend zum Test des Steuerprogramms mit diesem verbunden. Funktionsorientiert Ziel ist hier möglichst schnell Teilfunktionen fertig zu stellen. Aus diesem Grund werden zunächst alle Module zusammengeführt, die zur Erstellung der Teilfunktion notwendig sind. Ereignisorientiert Hier werden die Module zusammengesetzt und getestet, die zur Abarbeitung eines äußeren Ereignisses notwenig sind. Objekt- oder datenorientiert Diejenigen Module werden zusammengefügt und geprüft, die auf dem gleichen Objekt- und Datenbestand arbeiten. Neben den hier dargestellten Strategien, kann es noch andere dem Anwendungsfall entsprechende Strategien geben. So können im Einzelfall Aspekte wie die Aufrufreihenfolge der Module oder auch die Synchronisation einzelner Teile der Software zu anderen Strategien führen. Es ist zu bedenken, dass sich die angegebenen Strategien zum Teil auch kombinieren lassen. Systemtest Nachdem alle Module und Teile des Systems zusammengefügt wurden, wird das Gesamtsystem nun daraufhin getestet, ob es sich so verhält wie es die Anforderungsdefinition vorgesehen hat. Dazu werden oft Real-Life Testfälle erarbeitet. Schwerpunkte des Systemtests sind: Lasttests Markus Menzel / Steffen Knieling Seite 18 von 34

19 Fehlerinjektion (gezielte Provokation von Fehlern) Funktionale Überprüfung im realen Umfeld Überprüfung der Abnahmekriterien für die Software Vorgehensweise Neben einer sachlichen Einordnung der Softwaretests innerhalb des V-Modells muss auch klar sein, wie ein solcher Test konkret durchzuführen ist. Für sämtliche Softwaretests hat sich dabei die zeitliche Aufteilung in folgende Phasen als sinnvoll erwiesen 7 : Testplanung Testfallermittlung Testdatenerstellung Testausführung Testauswertung Testdokumentation Testplanung Als erstes müssen die Testobjekte ausgewählt werden. Dies können Module oder ganze Subsysteme oder auch nur einzelne Funktionen sein. Es ist notwendig die verschiedenen Testobjekte zu priorisieren. Diese Priorisierung kann einen nicht unerheblichen Einfluss auf die Reihenfolge haben, in der die für dieses Testobjekt notwendigen Programmteile entwickelt werden. Hat ein Testobjekt eine hohe Priorität, so sollten die notwendigen Programmteile auch diejenigen sein, die als erstes entwickelt werden müssen. Durch eine Schätzung des Testaufwands lässt sich schließlich ein Zeitplan erstellen. Die Aufwandsschätzung ist dabei ein nicht unproblematischer Teil. Die dazu existierenden Verfahren reichen vom einfachen Raten, über formelbasierte Systeme, wie die Function Point Methode bis hin zu Verfahren, die anhand von Erfahrungen und dem Anteil der neuen Testfälle eine empirische Abschätzung vornehmen. Hinzu kommt die Aufgabe Testendekriterien festzulegen. Dies sind Kriterien, die definieren, ab wann eine Phase des Testprozesses als abgearbeitet betrachtet werden kann und die nächste Phase begonnen werden darf. Testfallermittlung Die Aufstellung von Testfällen, welche möglichst alle funktionalen wie auch strukturellen Bedingungen testen, ist nicht möglich. Testfälle werden dabei in der Regel schon in früheren Phasen z.b. während der Anforderungsdefinition erstellt. Eine detaillierte Beschreibung zu dieser Phase wird in Kapitel 5.1 näher beleuchtet. 7 Vgl. (ASQF 2003, S 3 ff) Markus Menzel / Steffen Knieling Seite 19 von 34

20 Testdatenerstellung Hier werden die konkreten Eingabedaten für die Testfälle festgelegt. Die notwendigen Informationen dazu ergeben sich in der Regel direkt aus den Testfallbeschreibungen. So erfolgt die Testdatenerstellung gleichzeitig mit der Testfallermittlung, was in Kapitel 5.1 beispielhaft verdeutlicht wird. Lediglich bei der Erstellung von Testskripts innerhalb umfangreicher Testszenarios, die durch Automaten durchgeführt werden, muss die Testdatenerstellung explizit nachgelagert durchgeführt werden. Testdurchführung Sobald die Testfälle und Testdaten vorliegen, kann der eigentliche Test durchgeführt werden. Dazu gehört auch die Bereitstellung einer verifizierten Testumgebung. Je nach Art und Umfang der Tests sind zu diesem Zweck extra Räume, Arbeitsmittel, Werkzeuge, Personal, Hard- sowie Software, Berechtigungen und Kommunikationseinrichtungen zu beschaffen. Das Testergebnis wird in jedem Fall des Testausgangs protokolliert. Tools die automatisiert Tests durchführen, enthalten in der Regel auch entsprechende Protokollierungsmechanismen. Testauswertung Die wesentliche Aufgabe dieser Phase ist die fehlerfreie Funktionalität der Anwendung sicherzustellen. Dabei werden die Ergebnisse mit den Erwartungen aus der Anforderungsdefinition verglichen. Die Testauswertung ist in einem Ergebnisprotokoll zu dokumentieren. Mögliche Ursachen von Fehlern können sein: 8 Fehler in der Software Fehler in dem Testskript Fehler in den Testdaten Fehler in der Testumgebung Fehler in der Anforderungsspezifikation Etc. Testdokumentation Die Testdokumentation dient in erster Linie dem Zweck der Absicherung und Nachvollziehbarkeit. So soll durch eine entsprechende Dokumentation der Grad der Testabdeckung sowie die Prüfung der Vollständigkeit festgehalten werden. Um die Nachvollziehbarkeit zu gewährleisten, ist es notwendig, sich die Software- bzw. Komponentenversion und die mit ihr ausgeführten Testfälle zu merken. 8 Quelle (ASQF, S. 11) Markus Menzel / Steffen Knieling Seite 20 von 34

21 4 Klassifikationsbaum-Methode Die zentrale Voraussetzung für einen gründlichen Test ist die Ermittlung von relevanten Testfällen, da bei ihr Art und Umfang der Prüfung festgelegt werden und damit die Güte des Tests bestimmt wird. In diesem Kapitel wird eine Methode vorgestellt, die von der DaimlerChrysler AG Research Information and Communication in den Neunziger- Jahren entwickelt wurde um auf anschauliche Art und Weise Testfälle systematisch zu ermitteln. Mit der Klassifikationsbaum-Methode hat der Tester die Möglichkeit, die für ihn relevanten Gesichtspunkte systematisch und nachvollziehbar zu testen. Eine Methode ist generell eine planmäßig angewandte, begründete Vorgehensweise zur Erreichung der festgelegten Ziele. In diesem Fall wird die Aufstellung von Testfällen durch mehrere Arbeitsschritte, Aktivitäten, siehe Kapitel 4.4, methodisch begleitet. Die angesprochenen Gesichtspunkte, auf die der Tester den Schwerpunkt setzt, werden in jeweils unabhängige Klassifikationen aufgeteilt. Dadurch entstehende Klassen können wiederum durch weitere Klassifikationen unterteilt werden. Testfälle ergeben sich aus der Kombination von Klassen unterschiedlicher Klassifikationen. Der dabei entwickelte Baum, im weiteren Verlauf als K-Baum (Klassifikationsbaum) bezeichnet, enthält alle möglichen Eingaben, die für den Tester relevant sind. Das besondere an dieser Methode ist das systematische Vorgehen bei der Ermittlung von Testfällen und Testfallspezifikationen. Im folgenden Unterkapitel werden weitere Verfahren vorgestellt. 4.1 Einordnung der Klassifikationsbaum-Methode Bei der Auswahl von Testfällen kann der Tester durch verschiedene Testverfahren unterstützt werden, die ihre Auswahl nach bestimmten Kriterien treffen. Eine Auflistung von verschiedenen methodischen Ansätzen wird in Tabelle 4 wiedergegeben. An dieser Stelle sollte zuvor erwähnt werden, dass bei fehlerbasierten Verfahren bereits eine Auswahl der Testfälle vorgenommen wurde und der Schwerpunkt auf die Wiederholung eines gesamten Tests liegt. Tabelle 4: Testverfahren Funktionale Verfahren Klassifikationsbaum- Methode Äquivalenzklassen- Methode Grenzwertanalyse Überdeckungs- Verfahren Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung Statische Verfahren Syntaxcheck Kontrollflussanomalien Datenflussanomalien Quelle: Vgl. (Grochtmann 1993, S. 4f) und (ASQF 2003, S. 22 f) Fehlerbasierte Verfahren Mutationstest Regressionstest Markus Menzel / Steffen Knieling Seite 21 von 34

22 Die in Tabelle 4 aufgelisteten Testverfahren fordern jeweils die Bildung von Testfällen nach bestimmten Kriterien. Zum Beispiel verlangt der Zweigtest, dass es zu jedem Zweig einen Testfall geben muss und somit die Eingabewerte dementsprechend zu setzen sind. Die üblichen Testverfahren stehen alle unabhängig zu einander. Die Auswahl von Testfällen nach nur einem Kriterium stellte sich jedoch als nicht günstig dar und verlangte nach einer Modernisierung der Testfallermittlung. Es entstand der Bedarf nach einer Methode, welche die Gesichtspunkte eines Testers berücksichtigen kann: Die Klassifikationsbaum-Methode Klassifikationen Das Ziel der Bildung von Klassifikationen ist es, das Testobjekt in unabhängige Bereiche aufzuteilen, damit die Übersicht in zunächst unklaren Situationen bewahrt werden kann. Sind die Klassifikationen erst einmal aufgestellt, fällt es nicht weiter schwer die dazugehörigen Merkmale in Klassen aufzustellen und zuzuordnen. Rekursiv ist die Anordnung mehrerer Klassifikationen unter jeder Klasse denkbar, das heißt, jede Klasse kann wiederum durch einen Unterbaum von Klassifikationen und Klassen dargestellt werden. Abbildung 4: Klassifikationsbaum Quelle: Vgl. (Grochtmann 1993, S. 7) Die eingeführten Klassifikationen in Grafik Abbildung 4 führen das Begriffsbildungsschema ein, mit dessen Hilfe ein Testobjekt identifiziert werden kann. Beispielsweise kann ein Objekt aus der Kategorie Größe mit der Klasse groß, der Kategorie Farbe mit der Klasse rot und der Kategorie Form mit der Klasse Quadrat eindeutig als großes, rotes Quadrat identifiziert werden. Klassifikationen sind für den Software-Test eine vollständige und unabhängige Aufteilung des Eingabedatenraums eines Testobjektes. Dabei besitzt jede Klassifikation eine 9 Vgl. Software-Verifikation: Systematischer Test mit der Klassifikationsbaum-Methode, Matthias Grochtmann, Klaus Grimm, 1993, S. 5 Markus Menzel / Steffen Knieling Seite 22 von 34

23 endliche Anzahl von Klassen. Die Testfälle können, im Anschluss an die Aufteilung des Testobjektes in Klassifikationen, durch die Kombination von disjunkten Klassen gebildet werden. Dabei ist darauf zu achten, dass aus jeder Klassifikation nur eine Klasse berücksichtigt werden kann. Ein Testfall kann als Bildung eines Durchschnitts aufgefasst werden, weil nur eine bestimmte Kombination von Klassen zu einem Testfall gehören können. Anschaulich bedeutet dies, dass das Testobjekt ein großer, roter Kreis aufgrund der roten Farbe gleichzeitig nicht gelb sein kann. 4.3 Funktionsweise von Klassifikationsbäumen Ein K-Baum enthält verschiedene Klassifikationen, die den jeweiligen Eingabedatenraum vollständig oder teilweise zerlegen. Erst durch Überlagerung der Klassen entsteht durch die Schnittmenge eine vollständige Identifikation eines Testobjektes. Abbildung 5: Kombination von Klassen in einem K-Baum Quelle: (Grochtmann 1993, S. 13) Markus Menzel / Steffen Knieling Seite 23 von 34

24 Aus der Abbildung 5 kann die maximale Anzahl der Testfälle abgeleitet werden. Diese ergibt sich aus der Multiplikation von Anzahl Klassen der Klassifikation A und Anzahl Klassen der Klassifikation B. Aus allen möglichen Testfällen werden aus der Kombinationstabelle genau so viele Testfälle als Prüfgrundlage ausgewählt, wie ihre Priorität es erfordert. Das heißt, dass die Überprüfung eines Überweisungsformulars einer Online-Banking-Anwendung zum Beispiel eine höhere Priorität als das Eingabeformular einer Adressdatenbank hat. Andernfalls wird die Anzahl der Testfälle je nach Budget und strategischer Ausrichtung, Niedrigpreisstrategie oder Qualitätsführerschaft, festgelegt. Schließlich ist festzuhalten, dass mit Hilfe der Klassifikationsbaum-Methode lediglich eine Auswahl von Testfällen aus einer Teilmenge notwendig ist und nicht mehr eine Auswahl von Testfällen aus einer Menge von Eingabewerten. Das Problem ist damit deutlich einfacher als das Ursprüngliche zu lösen Vorgehensmodell zum Aufstellen eines Klassifikationsbaums Im Folgenden wird eine Abfolge von Testschritten tabellarisch aufgelistet, welche sich in der Praxis beim Testen der meisten Eingabemasken von E-Business-Applikationen als hilfreich erwiesen hat. Natürlich lässt sich dieses Vorgehensmodell auch auf andere Testobjekte mit nur wenigen Änderungen anpassen. Tabelle 5: Vorgehensmodell der K-Baum-Methode Schritte Beschreibung 1 Damit das Testobjekt möglichst überschaubar bleibt, muss der Tester eine Aufteilung der zu testenden Eingabemaske in logische Abschnitte / Klassifikationen vornehmen. Dabei ist darauf zu achten, dass der Tester nach der Isolierung mehrerer Testobjekte noch genügend Spezifikationen zum Testen vorliegen hat. Eventuell müssen die verschiedenen Testobjekte in Abhängigkeit voneinander mittels Integrationstest geprüft werden, falls sie in einem logischen Zusammenhang stehen. 2 Nachdem das Testobjekt definiert worden ist, erfolgt die Ermittlung des Eingabedatenraums. Ziel ist es, eine Sammlung von konkreten Eingaben zu erhalten, welche zu einer abstrakteren Klasse zusammengefasst werden können. 3 In diesem Schritt muss der qualifizierte Tester eine Entscheidung über die zu testenden Gesichtspunkte treffen. Dabei greift dieser auf Erfahrungen aus vorherigen Projekten zurück. Entscheidend für einen hinreichenden Test ist die Unterscheidung zwischen einer semantischen und syntaktischen Prüfung. 10 Vgl. (Grochtmann 1993, S. 13 f) Markus Menzel / Steffen Knieling Seite 24 von 34

25 Schritte Beschreibung 4 Mit Hilfe des zuvor definierten Eingaberaums erfolgt die Einteilung von Eingabedaten in Klassen nach ausgewählten Gesichtspunkten. Klassen wiederum stellen die Ausgangsbasis für eine Gruppierung mittels Klassifikationen dar. Die ermittelten Klassen und Klassifikationen werden in diesem Schritt mit Hilfe des Klassifikationsbaum-Editors graphisch notiert. 5 Falls eine Unterteilung einer aufgestellten Klasse in weitere Klassen möglich ist, wird eine untergeordnete Klassifikation angelegt, welche Ausgangsbasis für die neuen Klassen ist. 6 Ist der Klassifikationsbaum einmal aufgestellt, dient er als Kopf für die Kombinationstabelle, in der die Auswahl von Testfällen, wie in Kapitel 5.1 beschrieben, erfolgt. Quelle: Vgl. (Grochtmann 1993, S. 14 f) Nachdem die Klassifikationsbaum-Methode für das Aufstellen von Testfällen näher erläutert wurde, wird im folgenden Kapitel die Technik für die Umsetzung dieser Methode erklärt. Dabei wird ein Werkzeug vorgestellt, welches ebenfalls in der Forschung der DaimlerChrysler AG entwickelt wurde und für die Öffentlichkeit im Internet unter zur freien Verfügung steht. Dieses Programm unterstützt die graphische Umsetzung für die Modellierung eines Klassifikationsbaums und die Testfallgenerierung. Markus Menzel / Steffen Knieling Seite 25 von 34

26 5 Techniken der Qualitätssicherung Um die Zuverlässigkeit von komplexen Software-Anwendungen zu garantieren, ist es wichtig, Software und IT-Systeme systematisch zu testen. Für einen ordnungsgemäßen Test ist es unabdingbar, dass sich qualifiziertes Personal mit Prüfobjekten ausreichend auseinandersetzt. Aufgrund der Komplexität der Prüfobjekte bedarf es eines guten Verständnisses über Testtechniken. Unter Techniken können Verfahren zur Umsetzung von Methoden subsumiert werden. Der im Folgenden näher beschriebene Klassifikationsbaum-Editor (CTE steht für Classification Tree Editor) wurde speziell für die rechnergestützte Anwendung der Klassifikationsbaum-Methode entwickelt. In den folgenden Unterkapiteln werden ein Klassifikationsbaum und mehrere Testfälle mittels CTE systematisch erstellt. 5.1 Definition von Testfällen Nachdem der Klassifikationsbaum aufgestellt ist erfolgt die Auswahl der Testfälle. Dabei dient der K-Baum als Kopf einer Tabelle, in der die Testfälle definiert werden. Zu jeder nicht mehr unterteilten Klasse wird eine Spalte angelegt. Es kann genau eine unter mehreren Klassen einer Klassifikation selektiert werden. Eine Klasse wird indirekt ausgewählt, wenn eine ihrer Unterklassen selektiert wurde. Das folgende Beispiel dient als Muster- Beispiel für die erste Anwendung der Klassifikationsbaum-Methode. Es soll dem Tester das Verständnis von Klassifikationen und Klassen sowie den Zusammenhang zu Kompositionen erläutern. Kompositionen sind lediglich künstlich geschaffene Gruppierungsmaßnahmen, die ein Tester für eine übersichtlichere Darstellung verwenden kann. Abbildung 6: Modellierung eines K-Baums im Classification Tree Editor Quelle: Eigener Screenshot Markus Menzel / Steffen Knieling Seite 26 von 34

27 Eine feste Anzahl der Testfälle je Klassifikationsbaum ergibt sich aus der gewünschten Kombinatorik. Man unterscheidet zwischen 3 Kriterien: 1. Minimalkriterium, 2. Maximalkriterium und 3. Individuelles Kriterium. Jede Klasse in mindestens einem Testfall zu prüfen, stellt ein sinnvolles Minimalkriterium dar. Bei kritischen Anwendungen kann das Maximalkriterium eine nahezu hundertprozentige Sicherheit der Funktionalität gewährleisten, weil dazu jede logische Kombination berücksichtigt wird. Voraussetzung dafür ist eine sorgfältige Aufstellung des Klassifikationsbaums. Nur wenn der Tester eine richtige Auswahl der testrelevanten Gesichtspunkte vornimmt, gehen keine Informationen gegenüber dem ursprünglichen Testproblem verloren. Die Klassifikationen sollten demnach eine repräsentative Teilmenge der konkreten Wertemenge bilden. Alle 3 Kriterien zur Testfallbestimmung lassen sich mit Hilfe eines in CTE eingebauten Regeleditors generieren. Abbildung 7: Generieren von Testfällen mit dem Classification Tree Editor Quelle: Eigener Screenshot In der erstellten Regel aus Abbildung 7 werden Testfälle aus einer Tupel-Kombination zwischen den Klassifikationen Saugdüse und Auslegware ermittelt. Es wird hierbei sichergestellt, dass jedes mögliche Paar durch jeweils einen Testfall abgedeckt ist. Die Anzahl der Testfälle aus Abbildung 7 wurde automatisch aus der abgebildeten Regel generiert. Die Multiplikation der Anzahl der Klassen aus den Klassifikationen Saugdüse und der Auslegware ergaben in diesem Fall 9 Testfälle. Nachdem die Klassifikationsbaum-Methode mit Unterstützung des Tools CTE angewendet wurde, erfolgt die eigentliche Testdurchführung. Diese spaltet sich im folgenden Unterkapitel in zwei Varianten auf. Markus Menzel / Steffen Knieling Seite 27 von 34

28 5.2 Automatisiertes Testen Voraussetzung für manuelle und automatisierte Tests ist die abgeschlossene Testfallermittlung. Manuelles Testen bedeutet, dass die Überprüfung, in dem vorgestellten Beispiel sind es die Eingabemasken, händisch durch einen Tester erfolgt. Zwar testet dieser aufgrund der angewandten Klassifikationsbaum-Methode systematisch alle relevanten Testfälle, muss für die Dokumentation bzw. Berichterstellung jedoch erneut in den Test händisch eingreifen. Dazu kommt noch ein deutlich hoher Zeitaufwand für manuelle Tests, erst Recht, wenn diese mehrfach aufgrund von Regressionstests durchgeführt werden müssen. Auswege aus diesem Dilemma liefern Capture-Replay-Tools, auch Testroboter genannt. Diese zeichnen Tastatur und Mauseingaben des Benutzers sowie Antworten des Systems am Bildschirm auf ( Capture ) und können diese anschließend wieder auf dem Bildschirm simulieren ( Replay ). Graphical-User-Interface -basierte Werkzeuge verwenden während der Aufzeichnung Objekterkennungsverfahren für Fenster, Dialoge, Felder, Tasten und andere Kontrollelemente. Die aufgezeichneten Aktionen werden in einem Test-Skript gespeichert, welches jederzeit modifiziert werden kann, um die Wartbarkeit zu erleichtern. Eines der wichtigsten Ziele bei diesen Werkzeugen ist die klare Trennung zwischen Testdaten und Testskripten. 11 Mittels unterschiedlicher Testdaten kann die Ausführung desselben Testskripts parametrisiert werden. Dabei werden die Testdaten als Input in das System eingespeist und die Systembildschirmausgaben mit den erwarteten Ausgaben verglichen. In Abbildung 8 ist die angesprochene Trennung durch eine Zweiteilung der Applikation gewährleistet worden. Während im oberen Teil die Programmierung des Test-Skriptes möglich ist, erfolgt im unteren Bereich die Parametrisierung in einer Tabelle, wobei die Spalten die unterschiedlichen Eingabeparameter pro Testfall und die Testzeilen die Anzahl der Testfälle definieren. Neben der bereits erwähnten Testaufzeichnung mittels Tastatureingaben und Mausbewegungen kann zusätzlich eine Programmierung des Skripts im Experten-Modus vorgenommen werden. Dabei wird die objektorientierte Sprache Visual Basic for Applications (VBA) verwendet. 11 Vgl. Softwaretest Lehrplan zum Aufbaukurs, ASQF-Certified-Tester, Advanced Level, Version 1.2 von Juli 2003, S. 30 f Markus Menzel / Steffen Knieling Seite 28 von 34

29 Abbildung 8: Trennung von Testskript und Testdaten Quelle: Eigener Screenshot Das Werkzeug Quicktest Professional von der Firma Mercury Interactive bietet gegen Aufpreis verschiedene Plug-Ins an, um beispielsweise Active-X- oder Java-Anwendungen testen zu können. Außerdem sind neben der automatisierten Testdurchführung ebenfalls Protokollierungsmöglichkeiten für den abschließenden Testbericht vorhanden. In Abbildung 9 ist das Testergebnis einer Bestellmaske aus einer Java-Webstart-Anwendung protokolliert. Daraus ist zu entnehmen, dass es insgesamt 9 Testfälle gab, wobei 56 Prüfungen ein erwartetes und 5 Prüfungen ein unerwartetes Ergebnis lieferten. Markus Menzel / Steffen Knieling Seite 29 von 34

30 Abbildung 9: Protokollierung eines Testergebnisses Quelle: Eigener Screenshot 5.3 Werkzeuge des Testmanagements Testmanagementwerkzeuge bieten vielfältigste Funktionen an. Sie unterstützen die Erstellung, Verwaltung und Kontrolle von Dokumenten, z.b. Testplänen, Spezifikationen und Ergebnissen. Das Tool Test-Director von Mercury Interactive bietet zusätzlich noch die Möglichkeit aus den erfassten Anforderungen eines Pflichtenheftes Testpläne zu erstellen. Tests können zeitgesteuert durchgeführt werden, um die Entwicklung und das Netzwerk nicht unnötig zu belasten. Es unterstützt ebenfalls Projektmanagementaspekte, da eine zeitliche Planung mehrerer Tests aufgestellt wird. Dabei werden die Ergebnisse, Test erfolgreich durchgeführt oder nicht, im Anschluss in einem Repository aufbewahrt. In dem Test aus Kapitel 5.2, der fünf unerwartete Prüfungen ergab, werden die Fehler automatisch erfasst und der Test als noch nicht abgeschlossen markiert. Nachdem der Fehler behoben worden ist, erfolgt ein zeitlich gesteuerter Retest, um die Qualität der Anwendung erneut auf die Probe zu stellen. Ist dieser positiv verlaufen, das heißt, es wurden keine Fehler gefunden, ist der Test vorerst abgeschlossen. Werden weitere Änderungen in der Anwendung selbst oder im Umfeld vorgenommen, stellen Regressionstests sicher, dass die Anwendung auch nach indirekten Änderungen erwartungsgemäß funktioniert. Markus Menzel / Steffen Knieling Seite 30 von 34

31 Abbildung 10: Anforderungsdefinitionen im TestDirector Quelle: Eigener Screenshot In Abbildung 10 ist die Anforderungsdefinition vom Projekt YUCON (Young Cars Online) ausschnittsweise im TestDirector abgebildet. Anforderungen, die bisher durch keinen Testfall abgedeckt sind, erhalten in der zweiten Spalte den Status not covered. Tests können mehrere Anforderungsdefinitionen erfüllen. Dabei kann ein Test mehrere Male durchlaufen werden, damit auch Regressionsdurchläufe erfolgreich nachgewiesen werden können. Im Reiter TESTLAB erfolgt die eigentliche Testdurchführung. In diesem virtuellen Labor können zeitgesteuert mehrere Tests hintereinander bzw. parallel angestoßen werden. Die Testberichte können jederzeit aus der Anwendung aufgerufen werden. 5.4 Praktische Anwendung Die Klassifikationsbaum-Methode wird in der Forschung der DaimlerChrysler AG Abteilung Research, Information and Communication - Methoden und Tools für die Qualitätssicherung durchgängig in fast allen Projekten angewendet. Dabei wird die systematische Testfallermittlung durch das eigens entwickelte Werkzeug Classification Tree Editor unterstützt. CTE wird aufgrund der freien Verfügbarkeit von mehreren großen Firmen eingesetzt. Bekannt sind Projekte der AEG, die ein Leitsystem auf dem Frankfurter Flughafen systematisch testeten. Außerdem ist die Funktionsweise einer Komponente eines Kraftwerks sowie die Schubumkehr eines Flugzeugs durch die Klassifikationsbaum-Methode sichergestellt worden. Markus Menzel / Steffen Knieling Seite 31 von 34

32 Persönlich setzten wir in einer Werkstudententätigkeit die Methode ein, um Testfälle für eine E- Business Applikation zu erstellen, die von T-Systems seit 2 Jahren entwickelt wird um junge Gebrauchtwagen, wie zum Beispiel Miet- oder Jahreswagen an Händler zu verkaufen. Die Formulare und Masken werden in überschaubare Bereiche aufgeteilt und der mögliche Eingabedatenraum in K-Bäumen kategorisiert. Aufgrund dessen, dass die Aufteilung des Eingabedatenraums nach den Gesichtspunkten in verschiedenen Klassen Kreativität verlangt, kann dieser Prozess wahrscheinlich niemals automatisiert werden. Der Erfolg des Testens hängt in hohem Maß von der Qualifizierung und Erfahrung des Testers ab. Das Rating eines K-Baumes bestimmt die Anzahl der Testfälle. Ein triple A -Rating (AAA) sagt aus, dass die Testfälle nach dem Maximalkriterium aufzustellen sind. Es soll am Ende des Tests sichergestellt werden, dass die Maske 100% funktionstüchtig ist. Offensichtlich ist der Aufwand für die Erstellung eines solchen Test-Skripts am Größten, denn die Aufzeichnung bzw. Programmierung erfolgt ebenfalls durch einen Tester, der als Vorlage einen K-Baum zur Verfügung hat und eine Vielzahl von Eingabeparameter berücksichtigen muss. Bei dieser Tätigkeit wird der Tester durch das Werkzeug Quicktest Professional von der Firma Mercury Interactive unterstützt. Durch eine Kopplung zum Tool TestDirector, können dort Skripte Anforderungen zugeordnet und zeitgesteuert ausgeführt werden. Markus Menzel / Steffen Knieling Seite 32 von 34