8.1 Qualität und Qualitätssicherung 8.2 Softwaretest 8.3 Black-Box Testen 8.4 Zusammenfassung. H. Lichter, RWTH Aachen - 1 -

Transkript

1 8.1 Qualität und Qualitätssicherung 8.2 Softwaretest 8.3 Black-Box Testen 8.4 Zusammenfassung H. Lichter, RWTH Aachen - 1 -

2 8.1 Qualität und Qualitätssicherung 8.1 Qualität und Qualitätssicherung Der Qualitätsbegriff SW-Qualitäten - Klassifikation Qualitätsmerkmale Fehler-Begriffe Fehlerentstehung und -Behebung Schwerpunkte der SW-QS Validierung und Verifikation 8.2 Softwaretest 8.3 Black-Box Testen 8.4 Zusammenfassung H. Lichter, RWTH Aachen - 2 -

3 QS im Kontext der SW-Entwicklung Projektmanagement (Projekt initiieren, planen, kontrollieren, abschließen) Plan-/Istdaten Plan-/Istdaten Plan-/Istdaten (Produkt entwickeln) Produkte Systemerstellung Qualitätssicherung Konfigurationsmanagement (QS planen, Produkte prüfen) (Produkte und Änderungen verwalten) Produkte 8.1 Qualität und QS H. Lichter, RWTH Aachen - 3 -

4 Qualität Der Qualitätsbegriff ist die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. (ISO 8402) Eine Einheit kann ein Produkt, eine Dienstleistung, eine Tätigkeit, ein Prozess, ein System, eine Person, eine Organisation, etc. sein. Qualität ist Zielerfüllung. Die Ziele können explizit festgelegt oder implizit durch gemeinsame Vorstellungen der Beteiligten gegeben sein. Beispiele: Qualität ist kein absolutes Maß für die Güte einer Einheit 8.1 Qualität und QS H. Lichter, RWTH Aachen - 4 -

5 SW-Qualitäten - Klassifikation Prozeß-Qualität Qualität der Software-Entwicklung äußere Prozeß-Qualität Planungssicherheit innere Prozeß-Qualität Prüfbarkeit Inverse Dauer Inverser Aufwand Termin-Einhaltung Aufwandseinhaltung Prozeß-Transparenz Baustein-Gewinn Know-How-Gewinn Projekt-Klima Spezifikations-Vollständigkeit Lokalität Testbarkeit Wartbarkeit Änderbarkeit Portabilität Strukturiertheit Simplizität Knappheit Lesbarkeit Geräte-Unabhängigkeit Abgeschlossenheit Produkt-Qualität Brauchbarkeit Zuverlässigkeit Nützlichkeit Korrektheit Ausfallsicherheit Genauigkeit Effizienz Sparsamkeit Leistungs-Vollständigkeit Handbuch-Vollständigkeit Bedienbarkeit Konsistenz Verständlichkeit Einfachheit 8.1 Qualität und QS Qualitätenbaum in Anlehnung an B.Boehm, 1976 H. Lichter, RWTH Aachen - 5 -

6 Merkmale der Prozess-Qualität Inverse Dauer Die inverse Dauer ist hoch, wenn das Resultat nach kurzer Zeit zur Verfügung steht. (Wie viel Zeit wurde benötigt?) Inverser Aufwand Der inverse Aufwand ist hoch, wenn der Entwicklungsaufwand gering ist. (Welcher Aufwand wurde benötigt?) Termin-Einhaltung Die Termineinhaltung ist um so höher, je genauer der prognostizierte Termin eingehalten wird. Aufwandseinhaltung Die Aufwandseinhaltung ist um so höher, je genauer der prognostizierte Aufwand eingehalten wird. Prozess-Transparenz Die Prozess-Transparenz ist hoch, wenn der Bearbeitungsprozess wohl definiert ist und gemäß der Definition abläuft. Baustein-Gewinn Der Baustein-Gewinn ist hoch, wenn viele wiederverwendbare Software-Komponenten entstehen oder verbessert werden. Know-How-Gewinn Der Know-How-Gewinn ist hoch, wenn die Mitarbeiter viele neue Kenntnisse und Erfahrungen mit Anwendungen, Methoden, Werkzeugen erwerben. Projekt-Klima Das Projekt-Klima ist um so besser, je angenehmer die Mitarbeiter ihre Zusammenarbeit empfinden. Es beeinflusst andere Projekte und die Bereitschaft der Mitarbeiter, im Unternehmen zu bleiben. 8.1 Qualität und QS H. Lichter, RWTH Aachen - 6 -

7 Merkmale der Produkt-Qualität - 1 Spezifikations-Vollständigkeit Die Spezifikations-Vollständigkeit ist hoch, wenn die Spezifikation die tatsächlichen Anforderungen und nur diese vollständig angibt. Lokalität Die Lokalität der Software ist hoch, wenn Fernwirkungen in der Software vermieden sind. Testbarkeit Die Testbarkeit der Software ist hoch, wenn die Programme unter definierten Bedingungen ausgeführt und die relevanten Resultate vollständig erfasst werden können. Die Ausführung ist damit reproduzierbar. Strukturiertheit Die Strukturiertheit ist hoch, wenn die Software in logisch abgeschlossene Einheiten mit hohem Zusammenhalt und geringer Kopplung gegliedert ist. Simplizität Die Simplizität ist gering, wenn in der Software viele schwer verständliche Konstruktionen enthalten sind. Knappheit Die Knappheit der Software ist hoch, wenn ihr Umfang durch Vermeidung von Redundanz aller Art gering gehalten wurde. Lesbarkeit Die Lesbarkeit der Software ist hoch, wenn ein (fremder) Leser in der Lage ist, mit minimalem Aufwand den Inhalt korrekt zu erfassen. Geräteunabhängigkeit Die Geräteunabhängigkeit ist hoch, wenn Merkmale spezieller Geräte darin eine geringe Rolle spielen. 8.1 Qualität und QS H. Lichter, RWTH Aachen - 7 -

8 Merkmale der Produkt-Qualität - 2 Abgeschlossenheit Die Abgeschlossenheit ist hoch, wenn die Software eine gut abgegrenzte Leistung erbringt und damit kaum Schnittstellen zu anderen Systemen hat. Korrektheit Die Korrektheit ist hoch, wenn die Spezifikation zutreffend und die übrige Software korrekt in Bezug auf die Spezifikation ist. Ausfallsicherheit Die Ausfallsicherheit ist hoch, wenn die Software nur sehr selten die erwartete Funktion nicht erbringt. Genauigkeit Die Genauigkeit ist hoch, wenn die Resultate vom mathematisch korrekten Resultat nur wenig abweichen. Effizienz Die Effizienz ist hoch, wenn die Software kaum mehr Rechenzeit benötigt, als minimal erforderlich wäre. Sparsamkeit Die Sparsamkeit ist hoch, wenn die Software kaum mehr Speicherplatz und andere Betriebsmittel benötigt, als minimal erforderlich wäre. 8.1 Qualität und QS H. Lichter, RWTH Aachen - 8 -

9 Merkmale der Produkt-Qualität - 3 Leistungsvollständigkeit Die Leistungsvollständigkeit ist hoch, wenn die Software alle geforderten Leistungen tatsächlich erbringt. Konsistenz Die Konsistenz ist hoch, wenn die Software sich gegen den Benutzer in ähnlichen Situationen ähnlich verhält. Das betrifft die Bedienung, Fehlermeldungen, auch Datenformate usw. Handbuch-Vollständigkeit Die Handbuch-Vollständigkeit ist hoch, wenn die Handbücher erschöpfend Auskunft auf alle sinnvollen Fragen des Benutzers geben. Verständlichkeit Die Verständlichkeit ist hoch, wenn der Benutzer rasch versteht, wie er mit der Software umgehen muss. Einfachheit Die Einfachheit ist hoch, wenn die Software dem Benutzer konzeptionell einfach erscheint. 8.1 Qualität und QS H. Lichter, RWTH Aachen - 9 -

10 Fehler-Begriffe Eine Person begeht einen Irrtum (mistake). Als mögliche Folge davon enthält die Software einen Defekt (defect, fault). Wird der Defekt durch Prüfen der Software gefunden, so ergibt das einen Befund (finding). Bei der Ausführung von Software mit einem Defekt kommt es zu einem Fehler (error). Die tatsächlichen Ergebnisse weichen von den erwarteten / den richtigen ab. Dies kann zum Ausfall (failure) eines software-basierten Systems führen. Entwickler Software Programm Irrtum (mistake) Defekt (defect) Fehler (fault) statische Prüfung Test oder Betrieb Befund (finding) Benutzer Fehlbedienung (mistake) Versagen (failure) Irrtum (mistake) Fehlverhalten (error) 8.1 Qualität und QS H. Lichter, RWTH Aachen

11 Fehlerentstehung und -Behebung Fehler werden immer auf der Abstraktionsebene entdeckt auf der sie begangen werden! Analyse Betrieb Design Integrationstest konstruktive QS-Maßnahmen Codierung Modultest analytische QS-Maßnahmen Ziel ist, Fehler zu vermeiden und Fehler zum frühest möglichen Zeitpunkt zu entdecken! 8.1 Qualität und QS H. Lichter, RWTH Aachen

12 Schwerpunkte der SW-QS Software- Qualitätssicherung organisatorische Maßnahmen - Verantwortung - Richtlinien - Audits... konstruktive Maßnahmen - Vorgehensmodelle - Information Hiding - Hochsprachen... analytische Maßnahmen - Tests - Reviews - Metriken... Kontrolle organisieren Fehler vermeiden Fehler entdecken Qualität bewerten 8.1 Qualität und QS H. Lichter, RWTH Aachen

13 Validierung ist Validierung und Verifikation der Prozess der Beurteilung eines Systems oder einer Komponente während oder am Ende des Entwicklungsprozesses, mit dem Ziel, festzustellen, ob die spezifizierten Anforderungen erfüllt sind. (IEEE). Verifikation ist (1) der Prozess der Beurteilung eines Systems oder einer Komponente mit dem Ziel, festzustellen, ob die Resultate einer gegebenen Entwicklungsphase den Vorgaben für diese Phase entsprechen, (2) der formale Beweis der Korrektheit eines Programms. (IEEE ). 8.1 Qualität und QS H. Lichter, RWTH Aachen

14 Validierung und Verifikation Benutzer-Erwartungen Anforderungsspezifikation Architektur der Lösung (Detail-) Entwurf Code Validierung Verifikation 8.1 Qualität und QS H. Lichter, RWTH Aachen

15 8.2 Softwaretest 8.1 Qualität und Qualitätssicherung 8.2 Softwaretest Definition und Ziele Klassifikation nach der Systematik Prinzipien des Testens Testfälle Vorgehensweise beim Test Testverfahren 8.3 Black-Box Testen 8.4 Zusammenfassung H. Lichter, RWTH Aachen

16 Testen - Definition Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. (Myers 1979) Wurde ein Programm sorgfältig getestet (und sind alle gefundenen Fehler korrigiert), so steigt die Wahrscheinlichkeit, dass das Programm sich auch in den nicht getesteten Fällen wunschgemäß verhält. Unter Testen versteht man die Ausführung eines Programms unter Bedingungen,für die das korrekte Ergebnis bekannt ist und mit dem des Programms verglichen werden kann; Stimmen beide nicht überein, so liegt ein Fehler vor. 8.2 Softwaretest H. Lichter, RWTH Aachen

17 Testen - Ziele Ziel des Tests ist es, Fehler zu entdecken! Ein Test ist erfolgreich, wenn er einen Fehler gefunden hat. Ein erfolgloser Test ist niemals ein Beweis für ein korrektes Programm Es wurden lediglich keine Fehler gefunden! Die Korrektheit eines Programms kann durch Testen (außer in trivialen Fällen) nicht bewiesen werden. Grund: Alle Kombinationen aller möglichen Werte der Eingabedaten müssten getestet werden Anzahl möglicher Eingaben: = 2 32 Ein vollständiger Test erfordert mehr als 4'000'000'000 Testfälle x y + Ausnahme: x+y arithm. Überlauf x, y ganze Zahlen, mit 16 Bit repräsentiert Ein Programm kann niemals ausgetestet werden! 8.2 Softwaretest H. Lichter, RWTH Aachen

18 Klassifikation nach der Systematik Laufversuch Entwickler übersetzt, bindet und startet sein Programm Es gelingt, das Programm auszuführen Resultate sind nicht offensichtlich falsch Wegwerf-Test Jemand führt das Programm aus und gibt dabei Daten vor Er erkennt in einigen Fällen Fehler Systematischer Test Jemand (nicht der Autor!) leitet aus der Spezifikation Testdaten (Testeingaben und Soll-Resultate) ab Ausführung des Programms Vergleich der Ist-Resultate mit den Soll-Resultaten Dokumentation von Prüfling, Testdaten, Ist-Resultaten 8.2 Softwaretest H. Lichter, RWTH Aachen

19 Prinzipien des Testens Vollständiges Testen ist unmöglich! Testen ist eine kreative und anspruchsvolle Tätigkeit! Tests müssen geplant sein! Testen erfordert Unabhängigkeit! Frage der Prioritäten: Termin- oder Qualitätsziele? Zu jedem Testfall gehört ein Soll-Resultat! Eine Entwicklungsorganisation sollte ihre Produkte nicht selbst testen! Überprüfe die Ergebnisse jedes Tests gründlich! Vermeide Wegwerftestfälle, es sei denn das Programm ist wirklich ein Wegwerfprogramm! Ein Test ist nur so gut wie seine Testfälle! 8.2 Softwaretest H. Lichter, RWTH Aachen

20 Testfälle Auswahl der Testfälle ist die zentrale Aufgabe des Testens! Anforderungen an Testfälle repräsentativ fehlersensitiv redundanzarm ökonomisch Ziel: Mit einer möglichst kleinen Auswahl der Testfälle möglichst vielen Fehlern auf die Spur kommen. Alternativen Auswahl entsprechend der angestrebten Merkmale des Programms Black-Box-Test (Funktionstest) Auswahl unter Einfluss der inneren Struktur des Prüflings Glass-Box-Test (Strukturtest) 8.2 Softwaretest H. Lichter, RWTH Aachen

21 Vorgehensweise beim Test Code Entwurf, Codierung Test Ist-Resultate Anforderungen Vergleich Test-Eingabe Testdaten Testdatenentwurf Test- Orakel simulierte Ausführung Soll-Resultate Abweichungen 8.2 Softwaretest H. Lichter, RWTH Aachen

22 Testverfahren - 1 funktionsorientiert (Black-Box-Test) Testfall-Auswahl aufgrund der Spezifikation Programmstruktur kann unbekannt sein x1 x2 x3 y1 y2 y1 = f(x1,x2,x3) y2 = g(x1,x2,x3) strukturorientiert (White-Box-Test, Glass-Box-Test) Testfall-Auswahl aufgrund der Programmstruktur Spezifikation muss ebenfalls bekannt sein (wegen der erwarteten Resultate) 8.2 Softwaretest H. Lichter, RWTH Aachen

23 Testverfahren - 2 Ursache-Wirkungsgraphen Black-Box- Ansatz Eingabeüberdeckung Ausgabeüberdeckung Äquivalenzklassenbildung Funktionsüberdeckung Testfallbestimmung White-Box- Ansatz Error Guessing Ablaufgraphenüberdeckung Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung Termüberdeckung Datenflussanalyse Symbolischer Test Diversifizierender Test 8.2 Softwaretest H. Lichter, RWTH Aachen

24 8.3 White-Box Testen 8.1 Qualität und Qualitätssicherung 8.2 Softwaretest 8.3 Black-Box Testen Testauswahlkriterien Äquivalenzklassenbildung Grenzwertbetrachtung Beispiele 8.4 Zusammenfassung H. Lichter, RWTH Aachen

25 8.3 Black-Box Box Test Ausgangspunkt für Testfälle ist die Spezifikation Fehlt eine Spezifikation, dann hat das erhebliche Konsequenzen auch für das Testen. Wogegen soll getestet werden? Was sind die Sollergebnisse? Motivation Es ist nicht zulässig, ein Programm lediglich gegen sich selbst zu testen. Ziel und Vorteil Möglichst umfassende Prüfung der spezifizierten Funktionalität. Nachteile Die konkrete Implementierung wird nicht geeignet berücksichtigt. 8.3 Back-Box Testen H. Lichter, RWTH Aachen

26 Black-box - Testfallauswahlkriterien Funktionsüberdeckung Jede spezifizierte Funktion wird mindestens einmal ausgeführt. Eingabeüberdeckung Jedes Eingabedatum wird in mindestens einem Testfall verwendet. Macht in der Regel Probleme! Ausgabeüberdeckung Jede Ausgabesituation wird mindestens einmal erzeugt. Beispiele: Bildschirmmasken, Fehlermeldungen, etc. Aufwand dafür ist z.t. erheblich Beispiel: Textverarbeitungsprogramm Häufig müssen Funktionen in ihrem Zusammenspiel geprüft werden. Zusätzlich müssen Leistungs- und Robustheitsprüfungen gemacht werden 8.3 Back-Box Testen H. Lichter, RWTH Aachen

27 Techniken der Testfall-Auswahl Äquivalenzklassenbildung Um eine repräsentative Menge von Eingabedaten zu testen, werden die Eingaben in Äquivalenzklassen eingeteilt. Aus jeder Klasse wird ein Repräsentant getestet. Grenzwertüberprüfung An den Grenzen zulässiger Datenbereiche treten erfahrungsgemäß häufig Fehler auf. Es werden Testfälle für solche Grenzfälle definiert. 8.3 Back-Box Testen H. Lichter, RWTH Aachen

28 Prinzip Äquivalenzklassenbildung Zerlegung aller möglicher Eingabedaten in gültige und ungültige Äquivalenzklassen Jede Äquivalenzklasse wird durch einen (oder mehrere) Repräsentanten getestet. Werte aus einer Äquivalenzklasse verursachen ein identisches funktionales Verhalten. Somit können alle Programmfunktionen getestet werden. Die Anzahl der Testfälle wird reduziert. Zerlegung mit Hilfe von spezifizierten Gültigkeitsbereichen spezifizierten (oder vermuteten) Sonderbehandlungen 8.3 Back-Box Testen H. Lichter, RWTH Aachen

29 Vorgehensweise - 1 Schritt 1: Aufstellung von Eingabebedingungen Die Eingabebedingungen des Programms werden anhand der (informellen) Spezifikation des Programm gebildet. Eine Eingabebedingung ist in der Regel ein Satz oder ein Abschnitt des Spezifikation. Beispiel: Schritt 2: Bildung von Äquivalenzklassen Zu jeder Eingabebedingung werden bestimmt gültige Äquivalenzklassen (Normalfall) ungültige Äquivalenzklassen (Sonderfall) Beispiel: 8.3 Back-Box Testen H. Lichter, RWTH Aachen

30 Regeln zu Bildung von Äquivalenzklassen Wertebereich Spezifiziert eine Eingabebedingung einen Wertebereich 1 gültige Ä-Klasse 2 ungültige Ä-Klassen Beispiel: Datenstrukturen (Mengengerüst) Wenn untere und obere Schranken angegeben sind 1 gültige Ä-Klasse 2 ungültige Ä-Klassen Beispiel: 8.3 Back-Box Testen H. Lichter, RWTH Aachen

31 Regeln zu Bildung von Äquivalenzklassen Aufzählung werden die Werte der Aufzählung gleich behandelt 1 gültige Ä-Klasse 1 ungültige Ä-Klasse Beispiel: werden die Werte der Aufzählung nicht gleich behandelt pro Wert je eine gültige Ä-Klasse 1 ungültige Ä-Klasse Beispiel: 8.3 Back-Box Testen H. Lichter, RWTH Aachen

32 Vorgehensweise - 2 Schritt 3: Ä-Klassen identifizieren Jede gültige Ä-Klasse wird eindeutig identifiziert (z.b. Zahlen: 1, 2,..) Jede dazu gehörende ungültige Ä-Klasse wird davon abgeleitet identifiziert (z.b. 1a 1b). Schritt 4: Testfälle definieren (gültige Ä-Klassen) Testfälle werden so ausgewählt, dass die Eingaben möglichst viele bisher noch nicht abgedeckte gültige Ä-Klassen abdecken Dieses muss solange wiederholt werden, bis alle gültigen Ä-Klassen abgedeckt sind. Hinweis: Ein Testfall deckt genau dann eine Ä-Klasse ab, wenn er eine Eingabe definiert, die Element einer Ä-Klasse ist. D.h. eine Testfall kann mehrere Ä-Klassen abdecken. 8.3 Back-Box Testen H. Lichter, RWTH Aachen

33 Vorgehensweise - 3 Schritt 5: Testfälle definieren (ungültige Ä-Klassen) Testfälle werden so ausgewählt, dass diese nur genau eine bisher noch nicht abgedeckte ungültige Ä-Klasse abdecken. Hinweis: Mit der Zuordnung von einem Testfall zu einer genau einer ungültigen Ä- Klasse wird vermieden, dass ein Programm bei der Entdeckung einer fehlerhaften Eingabe weitere fehlerhafte Eingaben nicht mehr verarbeitet. Falls mehrere ungültige Äquivalenzklassen mit einem Testfall abgedeckt werden, ist nicht mehr transparent, welches falsche Testdatum die Fehlerbehandlung auslöst. 8.3 Back-Box Testen H. Lichter, RWTH Aachen

34 Beispiel: Ä-Klassenbildung Ä - 1 Spezifikation eines PRINT-Befehls Mit dem Ausgabebefehl PRINT wird die Datei auf den Bildschirm ausgegeben. Der Befehl hat zwei Parameter: Dateiname und Zeilenanzahl. Beide Parameter müssen angegeben werden. PRINT hat folgende Syntax: PRINT <Dateiname> <Zeilenanzahl> Der Dateiname besteht aus mindestens einem und bis zu sechs Zeichen, die Buchstaben oder Ziffern sein können. Das erste Zeichen des Dateinamens muss ein Buchstabe sein. Die Zeilenanzahl besteht aus mindestens einer und bis zu 3 Ziffern. Sie muss größer 0 und kleiner 1000 sein. 8.3 Back-Box Testen H. Lichter, RWTH Aachen

35 Beispiel: Ä-Klassenbildung Ä - 2 Schritt 1: Eingabebedingungen definieren Schritte 2 und 3: Äquivalenzklassen finden Eingabebedingungen gültige Ä-Klasse ungültige Ä-Klasse 1. Anzahl der Parameter 2. Dateiname (Länge) 3. Dateiname (Zeichen) 4. Dateiname (1. Zeichen) 5. Zeilenanzahl (Zeichen) 6. Zeilenanzahl (Ziffern) 7. Zeilenanzahl (Größe) 8.3 Back-Box Testen H. Lichter, RWTH Aachen

36 Beispiel: Ä-Klassenbildung Ä - 2 Schritte 4 und 5: Testfälle bestimmen gültige Ä-Klassen ungültige Ä-Klassen 8.3 Back-Box Testen H. Lichter, RWTH Aachen

37 Diskussion Ä-KlassenbildungÄ Feststellung Bei der Äquivalenzklassenmethode ist die Güte der Testfälle abhängig von der Aussagekraft der Spezifikation Beispiel: Führende Nullen beim zweiten Parameter des PRINT-Befehls Die Spezifikation macht keine Aussagen dazu: Es entstehen zwei ungültige Ä-Klassen ( mehr als 3 Zeichen, Wert >= 1000) Die Definition der Testfälle hängt nicht nur von den Eingabebedingungen ab Welche Werte aus einer Ä-Klasse sollen gewählt werden? Welche Kombinationen von Eingabebedingungen sollen getestet werden? 8.3 Back-Box Testen H. Lichter, RWTH Aachen

38 Grenzwertanalyse -1 Wahl der Repräsentanten einer Ä-Klasse Besteht eine Ä-Klasse aus einer geordneten Menge von Werten, dann kann zur Auswahl von Repräsentanten die Grenzwertanalyse durchgeführt werden. Schritt 1 der Grenzwertanalyse Testdaten identifizieren, die direkt auf oder neben den Grenzen des Ä- Klasse liegen (plus einen mittleren Wert). Richtlinien Wertebereich : gültige Testwerte: kleinster und größter Wert ungültige Werte: Werte, die direkt daneben und außerhalb liegen Beispiel Natürliche Zahlen Repräsentanten: 0, 1, 255, 256 Liste maximal 100 Elemente 4 Repräsentanten der Längen: 0, 1, 100, Back-Box Testen H. Lichter, RWTH Aachen

39 Grenzwertanalyse -2 Schritt 2 der Grenzwertanalyse Zusätzlich zu den Eingabe-Ä-Klassen werden Ausgabe-Ä-Klassen für die erwarteten Resultate gebildet. Dies geschieht analog zur Vorgehensweise bei der Definition der Eingabe-Ä-Klassen. Ausgabe-Ä-Klassen stellen Soll-Werte dar, für die die Eingabedaten bestimmt werden müssen. Hinweis Es ist manchmal nicht möglich, diese Eingabedaten zu finden, da eine zu produzierende ungültige Ausgabe nicht vom Programm zugelassen wird. 8.3 Back-Box Testen H. Lichter, RWTH Aachen

40 Schritt 1 Beispiel PRINT-Befehl - 1 Nur die Ä-Klassen 1, 2, 6, 7 werden betrachtet, da diese geordnete Wertebereiche darstellen Ä-Klasse gültige Werte ungültige Werte 1 Anzahl Parameter 2 Länge des Dateinamens 6 Zeilenanzahl (Ziffern) 7 Zeilenanzahl (Größe) Testfälle nach GWA 8.3 Back-Box Testen H. Lichter, RWTH Aachen

41 Schritt 2: Beispiel PRINT-Befehl - 2 Erweiterung der Spezifikation des PRINT-Befehls Es werden maximal 20 Seiten gedruckt Eine Seite enthält bis zu 46 Zeilen Mit Ausnahme der letzten Seite müssen immer volle Seiten gedruckt werden. Ausgabebedingungen: Ä-Klasse gültige Werte ungültige Werte 1 Anzahl Seiten (x) 1, 20 0, 21 2 Anzahl der Zeilen (y) 1, 45 0, 46 Testfälle nach GWA PRINT abc 0 (x = 0, y = 0) PRINT abc 45 (x = 1, y = 45 PRINT abc 900 (x = 20, y = 45) PRINT abc 901 (x = 21, y = 1) PRINT abc 46 (x = 1, y = 46) 8.3 Back-Box Testen H. Lichter, RWTH Aachen

42 8.4 Zusammenfassung Qualität muss definiert und konstruiert werden! Qualität betrifft das Produkt (Software) und den Entwicklungsprozess! Qualitätssichernde Maßnahmen sollen Fehler vermeiden und Fehler entdecken. Tests diesen dazu, Fehler zu finden! Tests sind ein Stichprobenverfahren zeigen nicht die Fehlerursache Blak-Box Tests basieren auf der Spezifikation Äquivalenzklassenbildung und Grenzwertbetrachtung führen zu systematisch gewählten Testfällen. H. Lichter, RWTH Aachen