Software Engineering 6) Verifikation und Validation

Transkript

1 Software Engineering 6) Verifikation und Validation Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: Studiengang WiBac 4 (Stand: ), Hochschule Augsburg, 2014

2 Gliederung 1. Grundlagen 2. SW Tests statisch dynamisch diversifizierend 2

3 1. Grundlagen (1) SW-Qualität nach ISO 9126 (DIN 66272) Funktionalität Korrektheit, Angemessenheit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit Zuverlässigkeit Reife, Fehlertoleranz, Wiederherstellbarkeit Benutzbarkeit Verständlichkeit, Bedienbarkeit, Erlernbarkeit, Robustheit Effizienz Wirtschaftlichkeit, Zeitverhalten, Verbrauchsverhalten Wartungsfreundlichkeit Analysierbarkeit, Änderbarkeit, Stabilität, Testbarkeit Übertragbarkeit Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit (Deutsches Institut für Normung e. V.,1994) Beispielmaß für Zuverlässigkeit: MTBF = gesamte Betriebszeit Anzahl der Ausfälle 3

4 1. Grundlagen (2) Testen Aktivität die ausgeführt wird um die SW Qualität zu evaluieren und zu verbessern indem Defekte und Probleme identifiziert werden Geprüft wird gegen erwartetes Verhalten (Anforderungsspezifikation) 4

5 1. Grundlagen (3) Ablauf Testfälle Test- Daten Test- Ergebnisse Test- Protokolle Entwerfen der Testfälle Erstellen der Testdaten Testausführung mit Testdaten Vergleich: Ergebnisse Testfälle Warum Testen? SW-Qualität Verifikation Spezifikation SW-Produkt Validierung (I. Sommerville, 2001, S. 427 ) Eignung SW-Produkt bezogen auf Einsatzzweck 5

6 1. Grundlagen (4) Aufgaben Tests planen Tests organisieren Tests durchführen Letzte Kontrollinstanz vor Freigabe Beteiligte SW Entwickler Prüfpersonal (z.b. unabhängige Organisation) SW Designer 6

7 2. SW Tests (1) Statischer Test Merkmale Es erfolgt keine Ausführung der zu prüfenden Software Alle statischen Analysen können prinzipiell ohne Computerunterstützung ausgeführt werden Es werden keine Testfälle gewählt Vollständige Aussagen über die Korrektheit oder Zuverlässigkeit können nicht erzeugt werden statisch verifizierend formal Zusicherungsverfahren symbolisch analysierend Maße Stilanalyse Grafiken und Tabellen Slicing Datenflussanomalieanalyse Inspektions- u Review-Technik Algebraische Techniken Automatenbasierte Techniken Sitzungstechnik formal Kommentartechnik informal (Liggesmeyer, SW-Qualität, 2002, S.34) 7

8 2. SW Tests (2) Statischer Test Stilanalyse (analysierende Technik) Beschreibung: Werkzeuge arbeiten ähnlich wie Compiler (lexikalische, syntaktische Prüfung) Analyse der Struktur des Codes Prüfung auf Einhaltung von Programmierrichtlinien Werkzeugunterstützung ist sinnvoll Beispiel: Syntaktische Prüfung: If (a==b) { Öffnende und schließende Klammer a=3; eines Blocks stehen stets alleine } else { in einer Zeile b=7; } Semantische Prüfung: Namenskonventionen: Keine Variablen die nur einen Buchstaben lang sind 8

9 2. SW Tests (3) Statischer Test Stilanalyse Einsatz: Die Stilanalyse ist bei Programmiersprachen mit liberaler, qualitätsmindernder Syntax (z.b. C im Gegensatz zu Ada) oft wichtig Vorteile: Werkzeugunterstützte Prüfung einiger Programmierrichtlinien Nachteile: Zusätzlicher Arbeitsschritt Keine Aussage zu Laufzeitverhalten 9

10 2. SW Tests (4) Statischer Test Inspektions- und Reviewtechnik (analysierende Technik) Beschreibung: Varianten Reviews in Kommentartechnik: grob, schnell, unkompliziert Informale Reviews: gründlich, zeitaufwendig, günstig Formale Reviews: sehr gründlich, sehr zeitaufwendig, teuer Prinzip der externen Qualitätskontrolle Eigenschaften: Festgelegte Eingangs- und Ausgangskriterien Definierte Inspektionsphasen mit QS-Zielvorgaben Teilnehmer mit verteilten Rollen Sammlung, Analyse von Inspektionsdaten einschließlich Rückkopplung auf den Inspektionsprozess Protokoll über erkannte Fehler 10

11 2. SW Tests (5) Statischer Test Inspektions- und Reviewtechnik (analysierende Technik) Inspektionsphasen Planung Organisatorische Vorbereitung Überblicksveranstaltung Informationsverteilung über das Produkt Vorbereitung Jeder Inspektor bereitet sich getrennt vor mit Inspektionsunterlagen Inspektionssitzung Durchführung in Sitzungstechnik Nacharbeit Durchführung der Fehlerkorrekturen Follow-Up Überprüfung der Fehlerkorrekturen und Anfertigung der Inpektionsberichte 11

12 2. SW Tests (6) Statischer Test Inspektions- und Reviewtechnik Einsatz: Semantische Prüfungen Ergebnis ist oft Meilenstein am Ende jeder Entwicklungsphase Wird häufig zu frühen Phasen sehr genau durchgeführt Vorteile: Effektivität in Bezug auf Anzahl gefundener Fehler steigt Nachteile: Keine Aussage zu Laufzeitverhalten 12

13 2. SW Tests (7) Merkmale Übersetzte, ausführbare SW wird mit konkreten Eingabewerten versehen und ausgeführt Es kann in der realen Betriebsumgebung getestet werden Dyn. Testtechniken sind Stichprobenverfahren Dyn. Testtechniken können die Korrektheit der getesteten SW nicht beweisen Ziel ist Testfälle zu erzeugen die repräsentativ fehlersensitiv redundanzarm und ökonomisch sind 13

14 2. SW Tests (8) dynamisch strukturorientiert kontrollflussorientiert Anweisungsüberdeckungstest Zweigüberdeckungstest Bedingungsüberdeckungstest Strukturierter Pfadtest und boundary interor Pfadtest Pfadtest LCSAJ-basierter Test Pfadüberdeckungstest datenflussorientert Defs-/Uses Kriterien Required k-tupels Test Datenkontext- Überdeckung funktionsorientiert funktionale Äquivalenzklassenbildung Zustandsbasierter Test Ursache-Wirkungs- Analyse Syntaxtest Transaktionsflussbasierter Test Test auf Basis von Entscheidungstabellen Unit Test (Liggesmeyer, SW-Qualität, 2002, S.34) 14

15 2. SW Tests (9) Techniken White-Box Techniken Strukturorientiert Testvollständigkeit anhand der Abdeckung der Strukturelemente des Codes Korrektheit wird anhand der Spezifikation beurteilt Einteilung kontrollflussorientiert datenflussorientiert (Liggesmeyer, SW-Qualität,2002, S.37) 15

16 2. SW Tests (10) Zweigüberdeckungstest (strukturorientierte, kontrollflussorientierte Technik) Beschreibung: Zweigüberdeckungstest subsumiert Anweisungsüberdeckungstest Ziel ist die Ausführung aller Zweige des Codes Testfälle mit definierten Eingabedaten finden, so dass alle Zweige abgedeckt werden Testmaß: C primitv = Anzahl ausgeführter primitiver Zweige Anzahl primitiver Zweige 16

17 2. SW Tests (11) Zweigüberdeckungstest Beispiel: Funktionsaufruf: Gesamtzahl=0 Eingelesene Zeichen: A, B, 1 Durchlaufener Pfad: (n start, n 1,n 2,n 3,n 4,n 5,n 2,n 3,n 5,n 2 n final ) (Liggesmeyer, SW-Qualität,2002, S.82) 17

18 2. SW Tests (12) Zweigüberdeckungstest Überdeckungsrate als Funktion der Testfallanzahl 18

19 2. SW Tests (13) Zweigüberdeckungstest Einsatz: Zweigüberdeckungstest ist weit verbreitet und oft Standard in Modultestwerkzeugen Vorteile: Aufspüren von nicht ausführbaren Programmzweigen Nachteile: Ungeeignet für den Test von zusammengesetzten Entscheidungen und für den Test von Schleifen Nichtlinearer Zusammenhang zwischen Überdeckungsrate und Testfallanzahl 19

20 2. SW Tests (14) Techniken Black-Box Techniken Funktionsorientiert Umsetzung der Spezifikation in Testfälle Testvollständigkeit anhand der Abdeckung der Eingabewerte und Äquivalenzklassen Korrektheit wird anhand der Spezifikation beurteilt Keine garantierte Vollständigkeit der Abdeckung der Programmstruktur (Liggesmeyer, SW-Qualität,2002, S.38) 20

21 2. SW Tests (15) Äquivalenzklassenbildung (funktionsorientierte Technik) Beschreibung: Es ist schwierig eine Auswahl von aussagekräftigen Testfällen aus einer großen Menge von Betriebssituationen zu gewinnen Es darf kein Fall ungetestet bleiben Gute Stellvertreter der Grundgesamtheit an Testfällen werden benötigt Äquivalenzklassenbildung durch Teile-und-herrsche Prinzip Komplexität wird durch Zerlegung reduziert Ein Wert einer Äquivalenzklasse wird stellvertretend für alle anderen der Klasse ausgeführt Durchführung von fortgesetzten Fallunterscheidungen für Eingabe- und Ausgabebedingungen 21

22 2. SW Tests (16) Äquivalenzklassenbildung Beispiel: Die Spezifikation lässt ausschließlich positive ganzzahlige Eingabewerte zu Gültige Äquivalenzklassen: 1: positive ganzzahlige Werte 2: Grenzwert: 0 Ungültige Äquivalenzklassen: 3: negative ganzzahlige Werte 4: nicht ganzzahlige Werte 5: Andere Zeichen Zugehörige Ausgabewertebereiche finden Aufstellen von Ergebnistabellen 22

23 2. SW Tests (17) Äquivalenzklassenbildung Einsatz: Modultest: Test konkreter Ein- Ausgabewerte Integrationstest: Test der Interaktionen über Schnittstellen Systemtest: Test unterschiedlicher Anwendungsfälle Vorteile: Test sehr einfach verständlich Nachteile: Programmcode wird nicht vollständig getestet Wechselwirkungen zwischen Äquivalenzklassen sind nicht testbar Nicht geeignet bei zustandsbasierter SW 23

24 2. SW Tests (18) Unit-Test (funktionsorientierte Technik) Beschreibung: Automatisierte Unit-Tests werden implementieren und stetig wiederholt Zu jeder Klasse wird eine entsprechende Testklasse implementiert Prüfung eines sehr kleinen und autarken Teil z.b. eine Methode Ein Testfall ist eine Methode und mit Testdaten zu konfrontieren Die laut Spezifikation zu erwartenden Ausgabewerte werden verglichen Stimmt das erwartete Ergebnis mit dem gelieferten Ergebnis der Funktion oder Methode überein, so gilt der Test als bestanden Häufig Betrachtung von Grenzfällen (sehr große/kleine Werte) und besonderer Werte (Null-Zeiger, Objekte in speziellen Zuständen) 24

25 2. SW Tests (19) Unit-Test Beispiel: (Test-) Attribut Klasse //Programmcode public class LaengenEinheiten{ Methode public float GetZollNumber(float zoll_value) { float meter_val = zoll_val/ 39,370; // Console.WriteLine( zoll->meter {0}=={1} ", zoll_val, meter_val); return meter_val; } } [TEST] //Testmethoden public class TestLaengenEinheiten { public void TestGetZollNumber () { LaengenEinheit LaeEinh = new LaengenEinheit(); } } Assertion.AssertEquals(LaeEinh.GetZollNumber(39,370f), 1f); Testklasse Testmethode Zusicherungsbefehl 25

26 2. SW Tests (20) Unit-Test Einsatz: Modultest OO-orientierte Systeme Vorteile: Automatisierte stetige Wiederholung eines minimalen Modultests Entwickler hält Methoden möglichst einfach und entwirft Objektstrukturen sauber, um einfache Tests implementieren zu können Unglücklich gewählte Schnittstellen fallen auf Komplexer Code fällt auf und wird refaktorisiert (vereinfacht) Weg zu Test-Driven Development Nachteile: Nicht geeignet für Benutzeroberflächen Bibliotheksfunktionen sind nicht testbar Nebenläufigkeit ist schwierig zu testen 26

27 2. SW Tests (21) Techniken diversifizierende Techniken Vergleich der Testergebnisse der diversitären SW Vermeidung der aufwändigen Bewertung der Korrektheit der Testergebnisse gegen die Spezifikation Häufig ist Automatisierung möglich (Liggesmeyer, SW-Qualität,2002, S.174) 27

28 2. SW Tests (22) - diversifizierend dynamisch diversifizierend Back to Back-Test Mutationen-Test Regressionstest (Liggesmeyer, SW-Qualität, 2002, S.34) ergänzt um Stresstest 28

29 2. SW Tests (23) Regressionstest (diversivizierende Technik) Beschreibung: Nachweis das Modifikationen keine unerwünschten Auswirkungen auf die Funktionalität besitzen Mehrmalige Ausführung einer Teilmenge der Testfälle ist nötig Vergleich der Ergebnisse mit Spezifikation und Vorgänger-Version der SW Automatisierter Test mit Werkzeug ist sinnvoll 29

30 2. SW Tests (24) Regressionstest Beispiel: (Liggesmeyer, SW-Qualität,2002, S.188) 30

31 2. SW Tests (25) Regressionstest Einsatz: Modultest Integrationstest Systemtest Vorteile: Erkennung von Veränderungen zur Vorversion einer SW Praxis-relevant Tools bieten oft auch Möglichkeiten zur Lasterzeugung für Leistungs- und Stresstests Nachteile: Fehler die in Vorversion schon vorhanden waren werden nicht sicher erkannt 31

32 Lernziel 1. Welche Merkmale enthält Qualitäts-SW? Nennen Sie jeweils ein passendes Testverfahren dazu. 2. Wie unterscheiden sich statische Testverfahren von dynamischen Testverfahren? 3. Was ist eine Äquivalenzklasse und wofür wird Sie eingesetzt beim Testen? 32