Analytische Qualitätssicherung: Von der Anforderung zum Testfall

Präsentation zum Thema: "Analytische Qualitätssicherung: Von der Anforderung zum Testfall"—  Präsentation transkript:

1 Analytische Qualitätssicherung: Von der Anforderung zum Testfall
Vorlesung Software Engineering I Analytische Qualitätssicherung: Von der Anforderung zum Testfall Software Engineering I VE: Von der Anforderung zum Testfall Version 1

2 Software-Qualitätssicherung (SW-QS)
Analytische QS Konstruktive QS Normen, Standards, Prozessmodelle, Projektleitung, Software-Technik, Software-Architektur, Erfahrungsaustausch, Ausbildungsmaßnahmen ... Ergebnisse Prozesse Artefakte prüfen: Audits Dokumente Reviews, ... Software Testen Software Engineering I VE: Qualitätssicherung analytisch Version 2

3 Analytische QS: Testen  Debugging
Funktion im Laufversuch überprüfen (unsystematischer Ad-hoc-Test). Fehlerursache lokalisieren, analysieren und beheben. Konstruktiver Ansatz Testen: Fehlverhalten provozieren, reproduzieren und dokumentieren. Destruktiver Ansatz Wenn Entwickler von „Testen“ sprechen, meinen sie oft „Debugging“. Problem: Gleichzeitig konstruktiv und destruktiv zu denken, ist schwierig! Testen sollte grundsätzlich systematisch erfolgen! Software Engineering I VE: Qualitätssicherung analytisch Version

4 Fragestellungen bei der analytischen SW-QS
Verifikation: Die Software ist richtig! Debugging: Warum ist die Software nicht richtig? Validation: Ist es die richtige Software? Test: Ist die Software richtig? Wie geht man systematisch und professionell vor ? Software Engineering I VE: Qualitätssicherung analytisch Version

5 Qualität: Fehler vs. Mangel
Eine Situation kann nur dann als fehlerhaft eingestuft werden, wenn vorab festgelegt wurde, wie die erwartete, korrekte, also nicht fehlerhafte Situation aussehen soll. Ein Fehler ist die Nichterfüllung einer festgelegten Anforderung, eine Abweichung zwischen dem Ist-Verhalten (während der Ausführung der Tests oder des Betriebs festgestellt) und dem Soll-Verhalten (in der Spezifikation oder den Anforderungen festgelegt). Ein Mangel liegt vor, wenn eine gestellte Anforderung oder eine berechtigte Erwartung in Bezug auf einen beabsichtigten Gebrauch nicht angemessen erfüllt wird. Ein Mangel ist z.B. die Beeinträchtigung der Verwendbarkeit bei gleichzeitiger Erfüllung der Funktionalität oder die Nichterfüllung einer angemessenen Erwartung (z.B. Benutzerfreundlichkeit). Angelehnt an: DIN EN ISO 9000:2005 Qualitätsmanagementsysteme – Grundlagen und Begriffe. Beuth Verlag, Berlin, 2005 Unterscheidung wichtig für Auftragnehmer und Auftraggeber im Rahmen der Vertragsgestaltung Software Engineering I VE: Qualitätssicherung analytisch Version

6 Definition: Validierung und Verifikation
Validierung Prüfung, ob ein Entwicklungsergebnis die individuellen Anforderungen bezüglich einer speziellen beabsichtigten Nutzung erfüllt. Haben wir das richtige System realisiert? Wenn nicht  Mangel Verifikation Prüfung, ob die Ergebnisse einer Entwicklungsphase die Vorgaben der Phaseneingangs-Dokumente erfüllen. Haben wir das System richtig realisiert? Wenn nicht  Fehler Software Engineering I VE: Qualitätssicherung analytisch Version

7 Ursachenkette für Fehler
Jeder Fehler oder Mangel ist seit dem Zeitpunkt der Fertigstellung in der Software vorhanden. Er kommt jedoch erst bei der Ausführung der Software zum Tragen. Dieser Sachverhalts wird als Fehlerwirkung (failure) bezeichnet (auch Fehlfunktion, äußerer Fehler, Ausfall). Mögliche Ursachen einer Fehlerwirkung: Fehlerzustand (fault) in der Software (oder Hardware) (auch als Defekt, innerer Fehler bezeichnet) Fehlhandlung (error) einer Person Fehlerwirkungen können (selten) auch durch Höhenstrahlung, elektromagnetische Felder oder Hardwarefehler hervorgerufen werden. Angelehnt an: DIN 66271:1995 Informationstechnik - Software-Fehler und ihre Beurteilung durch Lieferanten und Kunden, Beuth Verlag, Berlin, 1995 Software Engineering I VE: Qualitätssicherung analytisch Version

8 Fehlhandlung - Definition
Fehlhandlung (error) 1. Die menschliche Handlung (des Entwicklers), die zu einem Fehlerzustand in der Software führt. 2. Eine menschliche Handlung (des Anwenders), die ein unerwünschtes Ergebnis (im Sinne von Fehlerwirkung) zur Folge hat (Fehlbedienung). Problem (issue, incident) Verhalten anders als erwartet, aber Ursache noch unklar Fehlermaskierung Ist die Kompensierung eines Fehlerzustands durch andere, so dass keine Fehlerwirkung erkennbar ist. Ein Fehler wird also durch einen anderen Fehler verdeckt. Die menschliche Handlung, die zu einem falschen Ergebnis führt [nach IEEE 610]. Unwissentlich, versehentlich oder absichtlich ausgeführte Handlung oder Unterlassung, die unter gegebenen Umständen (Aufgabenstellung, Umfeld) dazu führt, dass eine geforderte Funktion eines Produkts beeinträchtigt ist. Software Engineering I VE: Qualitätssicherung analytisch Version

9 Zusammenhang Fehlerwirkung Fehlerzustand bzw. Defekt
die zum Tragen kommt Fehlerzustand bzw. Defekt in einem Programm 1. Testen Debugging Standards, Normen, Ausbildung ... Fehlhandlung einer Person Behebung von aussen nach innen … Software Engineering I VE: Qualitätssicherung analytisch Version

10 Motivation Fehler in einer Software müssen gefunden werden, ehe diese an die Anwender oder Kunden ausgeliefert wird. Um diesem Ziel nahe zu kommen, muss ein effektiver und effizienter Testprozess vorhanden sein. Hierzu müssen geeignete Methoden und Werkzeuge ausgewählt und angewendet werden. Software Engineering I VE: Qualitätssicherung analytisch Version 10 10

11 Austesten ? Ein einfaches Programm soll getestet werden, das drei ganzzahlige Eingabewerte hat. Übrige Randbedingungen haben keinen Einfluss auf das Testobjekt. Jeder Eingabewert kann bei 16 Bit Integerzahlen unterschiedliche Werte annehmen. Bei drei unabhängigen Eingabewerten ergeben sich * 216 * 216 = 248 Kombinationen. Jede dieser Kombinationen ist zu testen. Wie lange dauert es bei Tests pro Sekunde? Es sind Testfälle Dauer: ca. 90 Jahre Software Engineering I VE: Qualitätssicherung analytisch Version

12 Austesten? Ein einfaches Programm soll getestet werden, das aus vier Verzweigungen (IF-Anweisungen) und einer umfassenden Schleife besteht und somit fünf mögliche Wege im Schleifenrumpf enthält. Unter der Annahme, dass die Verzweigungen voneinander unabhängig sind und bei einer Beschränkung der Schleifendurchläufe auf maximal 20, ergibt sich folgende Rechnung: Wie lange dauert das Austesten bei Tests pro Sekunde? Es sind Testfälle Dauer: ca. 38 Jahre A B Software Engineering I VE: Qualitätssicherung analytisch Version

13 Erste Übung zur Testfallanalyse
Ein Programm ist zu testen, das 3 ganzzahlige positive Werte einliest und als Längen eines Dreiecks interpretiert. Das Programm gibt eine Meldung aus, ob es sich um ein ungleichseitiges, gleichschenkliges oder gleichseitiges Dreieck handelt. Welche Testfälle werden benötigt ? Welche Testdaten sind sinnvoll ? a b c a = b = c a ≠ b ≠ c a = b ≠ c a ≠ b = c a = c ≠ b Software Engineering I VE: Qualitätssicherung analytisch Version

14 Mögliche Testfälle (1) Testfälle bestehen aus Testdaten und dem Soll-Ergebnis 1. 2,3,4 - zulässiges ungleichseitiges Dreieck 2. 2,2,2 - zulässiges gleichseitiges Dreieck 3. 2,2,1 - zulässiges gleichschenkliges Dreieck 4./5. 1,2,2 / 2,1,2 - Testfälle mit Permutationen für gleichschenklige Dreiecke 6. 1,0,3 - kein Dreieck, eine Seitenangabe = 0 7./8. 0,1,3 / 1,3,0 - Permutationen 9. 5,-5,9 - kein Dreieck, eine Seitenangabe < 0 10./ ,5,9 / 5,9,-5 - Permutationen Software Engineering I VE: Qualitätssicherung analytisch Version

15 Mögliche Testfälle (2) 12. 1,2,3 - kein Dreieck Summe der beiden kürzeren Seiten = 3. Seitenlänge 13./14. 2,3,1 / 3,1,2 - Permutationen 15. 1,2,4 - kein Dreieck Summe der beiden kürzeren Seiten < 3. Seitenlänge 16./17. 2,4,1 / 4,1,2 - Permutationen 18./19. 0,0,0 - kein Dreieck oder Fehlermeldung alle Seiten = 0, zusätzlich 2 Seiten = 0 - Permutationen? Max_int, Max_int, Max_int - zulässiges gleichseitiges Dreieck korrekte Dreiecksbestimmung beim Test mit maximalen Werten, zusätzliche Tests mit 2 oder 1 maximalem Wert Software Engineering I VE: Qualitätssicherung analytisch Version

16 Mögliche Testfälle (3) ,1, Fehlermeldung »nicht ganzzahlige Werte« Permutationen? - zusätzlich mit 2 oder 3 Werten ,1,& - Fehlermeldung »Eingabe von Buchstaben oder Sonderzeichen« Permutationen? - zusätzlich mit 2 oder 3 Werten 29./30. 1,2,3,4 / 2,3 - Fehlermeldung »falsche Anzahl von Werten« (wenn Eingabe möglich) 31. Max_int/2 + 1, Max_int/2 + 1, Max_int/ zulässiges gleichschenkliges Dreieck (Überlauf oder richtige Berechnung? Bei a<=b<=c; Prüfung der Dreiecksbedingung mit a+b>c, führt a+b zum Überlauf, s.a. Testfall 20) Wie viele Tests hatten Sie überlegt? in Anlehnung an Glenford J. Myers: Methodisches Testen von Programmen. 7. Auflage 2001 Software Engineering I VE: Qualitätssicherung analytisch Version

17 Spitz-, stumpf- und rechtwinklige Dreiecke
Werden spitz-, stumpf- und rechtwinklige Dreiecke zusätzlich berücksichtigt, ergeben sich insgesamt 47 Testfälle. Fazit: Einfaches Problem, aber aufwendiger Test! E. H. Riedemann: Testmethoden für sequentielle und nebenläufige Software-Systeme. Teubner Verlag, Stuttgart 1997 Software Engineering I VE: Qualitätssicherung analytisch Version

18 Was ist eigentlich Testen ?
Testen ist ein Verfahren, um Vertrauen in die Realisierung eines Systems zu schaffen Aussagen über die Qualität des Systems zu machen Aber zuerst und vor allem, Fehler zu finden. Diese Aufgabe soll der Test So früh wie möglich So kostengünstig wie möglich Für die wichtigsten Fehler zuerst leisten Testarten werden unterschieden in Statisch (Reviews, Codeanalyse) Dynamisch (stichprobenhafte Ausführung des Testobjekts) Statisch: Software wird zum Test nicht ausgeführt, Dynamisch setzt Ausführbarkeit der Software voraus. Software Engineering I VE: Qualitätssicherung analytisch Version 18 18

19 Ziele des dynamischen Tests
Nachweis der Erfüllung der festgelegten Anforderungen durch das Testobjekt Aufdeckung von eventuellen Abweichungen und Fehlerwirkungen Mit möglichst wenig Aufwand (Testfällen) möglichst viele Anforderungen überprüfen bzw. Fehler nachweisen Dynamische Tests sind immer nur Stichproben! Software Engineering I VE: Qualitätssicherung analytisch Version

20 Gutes methodisches Wissen Planungsdaten
Was braucht der Tester ? Gutes methodisches Wissen Empfehlung: ISTQB Certified Tester ® Planungsdaten Wann sind Anforderungen spezifiziert? Wann sind sie implementiert? Wann soll der Kunde sie zur Verfügung haben? Testbare Anforderungen identifizierbar Klar formuliert verfolgbar nachweisbar  gut beschriebene Anforderungen sind unverzichtbar! International Software Testing Qualifications Board Software Engineering I VE: Qualitätssicherung analytisch Version 20

21 Lehrbuch zum Certified Tester - Foundation Level
Andreas Spillner, Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 4. überarbeitete Auflage dpunkt.verlag, 2010 308 Seiten, Gebunden 39,90 Euro (D) ISBN Leseproben etc. unter: Software Engineering I VE: Qualitätssicherung analytisch Version

22 Der Testprozess Testplanung und Steuerung Testanalyse und Testdesign
Testrealisierung und Testdurchführung Testauswertung und Bericht Abschluss der Testaktivitäten Diese Aktivitäten werden z.T. zeitlich überlappend oder parallel ausgeführt. Der fundamentale Testprozess ist für jede Teststufe geeignet zu gestalten. Planung und Analyse und Design Realisierung und Durchführung Abschluss Beginn Ende Steuerung Auswertung und Bericht Separat – aber verzahnt Software Engineering I VE: Qualitätssicherung analytisch Version 22

23 Entwicklungsprozess und Testprozess
Teststufen im Entwicklungsprozess nach V-Modell Software Engineering I VE: Qualitätssicherung analytisch Version

24 Statischer Test Analytische Qualitätssicherung Software Engineering I
VE: Qualitätssicherung analytisch Version

25 Statischer Test vs. dynamischer Test
Im Entwicklungsprozess werden unterschiedliche Produkte (Artefakte) erstellt Informelle Texte Modelle Formale Texte Programmcode Maschinencode Programme sind statische Beschreibungen von dynamischen Prozessen. Dynamische Tests prüfen die durch »Interpretation« (Ausführung) der Beschreibung resultierenden Prozesse. Statische Tests untersuchen die Beschreibung »als solche«, sie wird nicht »ausgeführt«. Im Gegensatz zum dynamischen Test finden statische Tests eher Fehlerzustände als Fehlerwirkungen Software Engineering I VE: Qualitätssicherung analytisch Version 25

26 Statischer Test Analyse des Testobjekts (meist ein Dokument) durch intensive Betrachtung Ziel: Finden von Fehlerzuständen (Defekten) im Dokument Verstöße gegen Spezifikationen oder einzuhaltende Standards, Fehler in Anforderungen, Fehler im Design, unzureichende Wartbarkeit und falsche Schnittstellenspezifikationen Nachweis der Verletzung von Projektplänen Ergebnisse der Untersuchungen werden darüber hinaus dazu benutzt, den Entwicklungsprozess zu optimieren Grundidee: Prävention! Fehlerzustände und Abweichungen sollen so früh wie möglich erkannt werden, noch bevor sie im weiteren Verlauf der Softwareentwicklung zum Tragen kommen und aufwändige Nach- oder Verbesserungen nach sich ziehen Software Engineering I VE: Qualitätssicherung analytisch Version 26

27 Prüfende Verfahren Reviews überprüfen am Ende jeder Entwicklungsphase Umfang und Qualität der Zwischenprodukte. Projektpersonal, Auftragnehmer-management und Auftraggeber entscheiden gemeinsam, ob die nächste Phase angegangen werden kann Audits sind offizielle Reviews zur Verifikation besonders kritischer Teile durch das QS-Personal Peer Review oder Walk-Through . Es geht dabei um eine methodische Examinierung der Zwischenprodukte durch sachkundige Kollegen (Peers). Ziel ist, Fehler zu finden und Bereiche, in denen Änderungen erforderlich sind Inspection ist eine sehr formale Gruppensitzung, in der die zu inspizierende Unterlage vom Autor vorgelesen und sequentiell Wort für Wort durchgearbeitet wird Software Engineering I VE: Qualitätssicherung analytisch Version

28 Wie viele "F" kommen im folgenden Text vor?
Ein Selbsttest Wie viele "F" kommen im folgenden Text vor? FINISHED FILES ARE THE RE- SULT OF YEARS OF SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE OF YEARS Software Engineering I VE: Qualitätssicherung analytisch Version 28

29 Wie viele hatten Sie gezählt?
Selbsttest Es sind sechs! Wie viele hatten Sie gezählt? Drei zu finden ist normal - sechs wirklich gut! Irren ist menschlich  FINISHED FILES ARE THE RE- SULT OF YEARS OF SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE OF YEARS Software Engineering I VE: Qualitätssicherung analytisch Version 29

30 Die magische Zahl Sieben
Problem: Begrenzte menschliche Wahrnehmungsfähigkeit Die Millersche Zahl bezeichnet die von George A. Miller festgestellte Tatsache, dass ein Mensch gleichzeitig nur 7±2 Informationseinheiten (Chunks) im Kurzzeitgedächtnis präsent halten kann. Die Größe des Kurzzeitgedächtnisses ist genetisch determiniert und kann auch durch "Training" nicht gesteigert werden. Der diesbezüglich von Miller verfasste Artikel "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" ist einer der meistzitierten Artikel im Bereich der Psychologie. (Quelle: Software Engineering I VE: Qualitätssicherung analytisch Version

31 Manuelle vs. automatisierte Prüfung
Betrachtung des Prüfobjekts durch Mensch oder Werkzeug Reviews Manuelle Prüfungen durch eine oder mehrere Personen Menschliche Analyse- und Denkfähigkeit wird genutzt, um komplexe Sachverhalte zu prüfen und zu bewerten Kann bei allen Dokumenten durchgeführt werden, die während des Softwareentwicklungsprozesses erstellt oder verwendet werden (z. B. Vertrag, Anforderungsspezifikation, Designspezifikation, Quelltext, Testkonzepte, Testspezifikationen, Testfälle, Testskripte oder Anwenderhandbücher) Statische Analyse Automatisierte Prüfungen durch entsprechende Werkzeuge Nur bei Dokumenten mit formaler Struktur möglich (z.B. Programmtext, UML-Diagramme) Software Engineering I VE: Qualitätssicherung analytisch Version 31

32 Statische Analyse und Reviews
Stehen in einem engen Zusammenhang Wird vor dem Review eine statische Analyse durchgeführt, können bereits eine Anzahl von Fehlern und Unstimmigkeiten nachgewiesen werden und die Menge der im Review zu berücksichtigenden Aspekte ist erheblich geringer Da statische Analysen werkzeuggestützt durchgeführt werden, ist der Aufwand wesentlich niedriger als beim Review Also: Statische Analyse und Review Software Engineering I VE: Qualitätssicherung analytisch Version 32

33 Statische Analyse von Programmcode
Fehler(zustände) bzw. fehlerträchtige Situationen, die mit der statischen Analyse von Programmcode nachgewiesen werden können, sind beispielsweise Verletzung der Syntax Abweichungen von Konventionen und Standards Kontrollflussanomalien Datenflussanomalien Alle Compiler führen eine statische Analyse des Programmtextes durch, indem sie die Einhaltung der Syntax der jeweiligen Programmiersprache prüfen Die meisten modernen Compiler bieten darüber hinaus noch zusätzliche statische Analysen Neben den Compilern gibt es spezielle Werkzeuge, sogenannte Analysatoren, die zur Durchführung bestimmter Analysen eingesetzt werden Software Engineering I VE: Qualitätssicherung analytisch Version 33

34 Statische Analysewerkzeuge
Einige freie Werkzeuge zur statischen Codeanalyse CCCC ( JUtils ( PyChecker ( Einige kommerzielle Werkzeuge zur statischen Codeanalyse PC-Lint Klocwork Coverity Polyspace Software Engineering I VE: Qualitätssicherung analytisch Version 34

35 Dynamischer Test Analytische Qualitätssicherung Software Engineering I
VE: Qualitätssicherung analytisch Version

36 Statischer Test vs. dynamischer Test
Programme sind statische Beschreibungen von dynamischen Prozessen Statische Tests untersuchen die Beschreibung »als solche«, sie wird nicht »ausgeführt« Artefakte des Entwicklungsprozesses, z.B informelle Texte, Modelle, formale Texte, Programmcode, ... Dynamische Tests prüfen die durch »Interpretation« (Ausführung) der Beschreibung resultierenden Prozesse. Das Testobjekt wird im dynamischen Test auf einem Prozessor „ausgeführt“ Bereitstellen von Eingangsdaten Beobachten der Ausgangsdaten Prozessor Testobjekt Ausgangsdaten Eingangsdaten Vorbedingungen Nachbedingungen Randbedingungen Software Engineering I VE: Qualitätssicherung analytisch Version 36

37 Die Ausführung dynamischer Tests erfordert ein ablauffähiges Programm
Dynamischer Test in »unteren« Teststufen Die Ausführung dynamischer Tests erfordert ein ablauffähiges Programm Einzelne Klassen, Module/Komponenten und Teilsysteme sind jedoch in der Regel für sich alleine nicht lauffähig, da sie oft nur Operationen/Dienste für andere Softwareeinheiten anbieten kein „Hauptprogramm“ zur Koordination des Ablaufes haben sich oft auf Operationen/Diensten anderer Softwareeinheiten abstützen In den „unteren“ Teststufen Klassen-/Modultest, Komponententest und Integrationstest muss das Testobjekt also in einen entsprechenden „Testrahmen“ eingebettet werden  Oft als „Unit-Test“ bezeichnet Software Engineering I VE: Qualitätssicherung analytisch Version 37

38 Aufbau eines Testrahmens
Point of Control: Schnittstelle, über die das Testobjekt mit Testdaten versorgt wird Testtreiber Testfall 1 Testfall 2 ... Testfall m Platzhalter PoC Stub 1 Stub 2 ... Stub n Testausgaben Vergleich & Protokoll Testobjekt PoO Point of Observation: Schnittstelle, an der die Reaktionen und Ausgaben des Testobjekts beobachtet und aufgezeichnet werden Laufzeitumgebung, Analysewerkzeuge, Simulatoren, Monitore Prozessor Software Engineering I VE: Qualitätssicherung analytisch Version

39 Unit Test – Begriffe Testrahmen (test bed)
Sammlung aller Programme (u. a. Testtreiber und Platzhalter), die notwendig sind, um Testfälle auszuführen, auszuwerten und Testprotokolle aufzuzeichnen Platzhalter (stub) Platzhalter werden beim dynamischen Komponenten- und Integrationstest benötigt, um noch nicht implementierte Komponenten für die Testdurchführung zu ersetzen bzw. zu simulieren Dummy Platzhalter mit rudimentärer Funktionalität Mock Platzhalter mit erweiterter Funktionalität für Testzwecke (Logging, Plausibilitätsprüfung) Software Engineering I VE: Qualitätssicherung analytisch Version 39

40 Fragestellungen beim Entwurf von Testfällen
Wie viele Tests sind notwendig ? Welche Testdaten sollen verwendet werden ? Wie können fehler-sensitive Tests gefunden werden ? Wie vermeidet man redundante Test ? Wurden Testfälle übersehen ? Wann kann man mit Testen aufhören ? → Testentwurfsverfahren ! Software Engineering I VE: Qualitätssicherung analytisch Version

41 Dynamischer Test – Testentwurfsverfahren
Testentwurfsverfahren (synonym: Testfallentwurfsverfahren) Eine Vorgehensweise, nach der Testfälle abgeleitet oder ausgewählt werden Black-Box (Spezifikationsorientierte) Testentwurfsverfahren Systematische Herleitung und Auswahl von Testfällen basierend auf einer Analyse der funktionalen oder nichtfunktionalen Spezifikation einer Komponente oder Systems ohne Berücksichtigung der internen Struktur. Also keine Informationen über den Programmtext und den inneren Aufbau Beobachtet wird nur das Verhalten des Testobjekts von außen (PoO - Point of Observation liegt außerhalb des Testobjekts) Steuerung des Ablaufs des Testobjektes nur durch die Wahl der Eingabetestdaten (PoC - Point of Control liegt außerhalb des Testobjektes) White-Box (Strukturorientierte) Testentwurfsverfahren Systematische Herleitung und Auswahl von Testfällen basierend auf Informationen über die interne Struktur einer Komponente oder Systems Software Engineering I VE: Qualitätssicherung analytisch Version 41

42 Testobjekt Übersicht Testentwurfsverfahren Black-box Test
Eingangsdaten Ohne Kenntnis der Programmlogik abgeleitet Ausgangsdaten Black-box Test Testobjekt Eingangsdaten Mit Kenntnis der Programmlogik abgeleitet Ausgangsdaten White-box Test Software Engineering I VE: Qualitätssicherung analytisch Version

43  Prozess und Methodik werden benötigt!
Testfallentwurf (1) Planung und Analyse und Design Realisierung und Durchführung Abschluss Beginn Ende Steuerung Auswertung und Bericht Anforderungs- Definition Test Aus den Anforderungen müssen Testfälle abgeleitet werden! Alle Anforderungen müssen durch Testfälle ausreichend abgedeckt werden! Wie soll man vorgehen ?  Prozess und Methodik werden benötigt! Man braucht Prozess und Methodik! Software Engineering I VE: Qualitätssicherung analytisch Version 43

44 Testfallentwurf (2) Planung und Analyse und Design Realisierung und Durchführung Abschluss Beginn Ende Steuerung Auswertung und Bericht Teststrategie Anforderungs- Definition Testentwurfstechniken Test Review Anforderungs- Definition Test Wahl der Testdesigntechniken wird durch die Teststrategie bestimmt Teststrategie bestimmt die Wahl der Testentwurfstechniken! Software Engineering I VE: Qualitätssicherung analytisch Version 44

45 Bekannte Teststrategien
Anforderungsbasiert Erfahrungsbasiert Intuitionsbasiert Änderungsbasiert Black-Box-basiert Risikobasiert White-Box-basiert Modellbasiert Geschäftsprozessbasiert Bekannte Testfallentwurfsmethoden. Besonders wichtig sind für systematischen Entwurf: Anforderungsbasiertes und Anwendungsfallbasiertes Testen Anwendungsfallbasiert Software Engineering I VE: Qualitätssicherung analytisch Version 45

46 Bekannte Testfallentwurfsmethoden
Äquivalenzklassenanalyse Entscheidungstabellen Ursache-Wirkungs-Graph Modellbasiert Klassifikationsbaummethode Test spezieller Werte Paarweise Kombination Betrachten werden nur die beiden fettgedruckten in dieser präsentation Bekannte Testfallentwurfsmethoden. Besonders wichtig sind für systematischen Entwurf: Äquivalenzklassenanalyse und Grenzwertanalyse! • Spezielle Werte: – Zahlenwert 0 – Leere Felder, Sequenzen und Zeichenreihen – Einelementige Felder, Sequenzen und Zeichenreihen – Null-Referenzen – Sonderzeichen (Steuerzeichen, Tabulator) Klassifikationsbaum =» Kombination von Äquivalenzklassen • Äquivalenzklassenmethode: Analyse und Spezifikation der Ein- und Ausgabedaten Annahme: jedes Objekt einer Klasse ruft selbe Fehler hervor wie jedes andere Objekt der Klasse Aus jeder Äquivalenzklasse wird dann nur ein Repräsentant getestet! – Gültige und ungültige Äquivalenzklassen unterscheiden: » Testdaten aus möglichst vielen gültigen Äquivalenzklassen => Minimierung der Testfälle für gültige Äquivalenzklassen » Ein Testdatum aus einer ungültigen Äquivalenzklasse in Kombination mit Werten ausschließlich aus gültigen Äquivalenzklassen • Grenzwertanalyse: Klassengrenzen werden als Testdaten verwendet. Grenzwertanalyse Software Engineering I VE: Qualitätssicherung analytisch Version 46

47 Äquivalenzklassenmethode
Testdatenbestimmung Äquivalenzklassenmethode Klassen von gleichartigen Eingabewerten anhand der Spezifikation => Ein Wert pro Klasse („Repräsentant“) genügt. Gültige und ungültige Äquivalenzklassen unterscheiden: Minimierung der Testfälle für gültige Äquivalenzklassen Ein Testdatum aus einer ungültigen Äquivalenzklasse nur in Kombination mit Werten aus gültigen Äquivalenzklassen anderer Parameter! Grenzwertanalyse Klassengrenzen werden als Testdaten verwendet Fehlerorientierte Erweiterung der Äquivalenzklassenbildung Engl. „Partition Method“, „Partition Testing“ Auswahl von Testdaten aus den Äquivalenzklassen:  Zufällig  Test spezieller Werte (z.B. 0, nil)  Grenzwertanalyse (Klassengrenzen werden als Testdaten verwendet) Grenzwerte, weil erfahrungsgemäss dort Fehler wahrscheinlicher sind. Grenzwerte müssen deshalb spezifiziert sein! Hohe Fehlerentdeckungsrate mit einer möglichst geringen Anzahl von Testfällen min_int max_int 1 -1 min_int-1 min_int+1 ... max_int-1 max_int+1 Software Engineering I VE: Qualitätssicherung analytisch Version 47

48 Äquivalenzklassenbildung...
...in der Schlangenschule Software Engineering I VE: Qualitätssicherung analytisch Version

49 Äquivalenzklassen und Grenzwerte...
Software Engineering I VE: Qualitätssicherung analytisch Version

50 Systemtest – Grundsätzliche Methodik
Testfallentwurf ist grundsätzlich anforderungsbasiert ! Anforderungen müssen identifizierbar sein Jede Anforderung in mindestens einem Testfall abdecken! Traceability sicherstellen! So wenig Testfälle wie möglich spezifizieren Ein Testfall kann auch mehrere Anforderungen abdecken! Systematische, nachvollziehbare Methodik anwenden! Geeignete Methoden zur Testfallreduktion sind: Äquivalenzklassenanalyse Grenzwertanalyse Paarweise Kombination Testfälle generisch spezifizieren Testdaten und Testanweisung separieren! Dann sind sie wartbarer und übertragbar

51  SRS STP Traceability OK ! Requirements Traceability Description
[SRS.FEATURE.ID] Feature Name Description … Limitations Interfaces Default Settings STP [TS.FEATURE] Testsuite Name [TC.FEATURE.001] Testcase Name [TC.FEATURE.002] Testcase Name [TC.FEATURE.003] Testcase Name [TC.FEATURE.004] Testcase Name [TC.FEATURE.005] Testcase Name  Traceability OK ! Software Engineering I VE: Qualitätssicherung analytisch Version

52 Testfallentwurfs-Prozess
SRS Testfall entwerfen und optimieren (TCS) Identifikation eines Testfalls (STP) Alle Anforderungen abgedeckt ? Iterativ-inkrementelles Vorgehen Erstellen des ersten Testfalls Alle Anforderungen müssen abgedeckt werden Eingangs und Ausgangsdokumente STP Software Engineering I VE: Qualitätssicherung analytisch Version 52

53 1. Anforderungen in SRS reviewen
Qualitätsansprüche an Anforderungen: Vollständigkeit Verständlichkeit (für alle Stakeholder) Korrektheit Eindeutigkeit Verfolgbarkeit Testbarkeit Gewichtbarkeit Aktualität Feedback an Requirements Engineer wenn Nachbesserung erforderlich Anforderungs- Definition Anforderungsreview Feedback Software Engineering I VE: Qualitätssicherung analytisch Version

54 2. Testfälle ableiten im STP
Traceability Anforderung  Testsuite/Testfall Software Engineering I VE: Qualitätssicherung analytisch Version 54

55 Namenskonvention für Testfälle
3. Testfallverwaltung Namenskonvention für Testfälle notwendig bei einer großen Anzahl von Testfällen! TCT.FUNC.REQID.SQNR.TT (Short Description of Test Objective) TCT = Testcase Type (TS = Test Suite TC = Testcase FUNC = Abbreviation for the related requirement functionality REQID = sequential numbering of testcase, related to requirement numbering (123) SEQNR = sequential numbering of testcase, not related to requirement numbering (001) TT = Test type (C = Conformance, F = Functional, L = Load/Stress, combined with A = Automated and/or S = Smoke/Regression, ) Short Description with less than 50 characters Korrekte Testfallbeschreibung beachten  „This testcase verifies…“  „The system supports…“ (Requirements-Beschreibung!) TCS enthält Testfallbeschreibungen Alternativ: Testfallmanagementsystem Software Engineering I VE: Qualitätssicherung analytisch Version

56 4. Testfälle anlegen in TCS
Test case ID: <TC.CONF.001.F> Name: Device parameter configuration Req.-ID: HID.GUI.001 (TBL); HID.GUI.006 (ERR); HID.DEVCONF.001; HID.DEVCONF.002; HID.DEVCONF.003; HID.DEVCONF.004 Description: The test case verifies the correct functionality of the device configuration of the IP address, net mask, default gateway and name. It verifies the display of the error message due to the input boundaries. The test case uses the test data from table TD.001 and TD.002. The test set up consists of a computer, with at least 2 devices connected to, and the software. Test Steps Step Action Expected result 1 Click on first line First line is selected 2 Click on the properties symbol in the toolbar and fill in the following data: IP= ,GW= , NM= , Name = Device_1 Properties dialog is opened. Valid parameters can be set; invalid parameters produce the display of an error message. 3 IP= ,GW= , NM= , Name = Device_1 Software Engineering I VE: Qualitätssicherung analytisch Version 56

57 5. Testfälle entwerfen und optimieren
Testfälle inhaltlich im Detail spezifizieren (TCS) Anwendung von Äquivalenzklassenbildung (gültige und ungültige!) Grenzwertanalyse Paarbildung …. Testfälle inhaltlich optimieren z.B. Datengetriebenen Ansatz anwenden Testfälle zusammenfassen Zum abdecken mehrerer Anforderungen Zum abdecken von Use-Case Szenarien Optimierung der Testfallanzahl Jede Äquivalenzklasse sollte möglichst wenig oft in Testfällen vorkommen, im Idealfall nur einmal je Äquivalenzklasse bzw. je Klassengrenze bei Grenzwertanalyse. Testfälle, welche nur Klassen bzw. Klassengrenzen testen, die auch von anderen Testfällen getestet werden, können gestrichen werden. Software Engineering I VE: Qualitätssicherung analytisch Version 57

58 6. Optimierter Testfall z.B. Testfallbeschreibung mit separierten Testdaten Test case ID: <TC.CONF.001.F> Name: Device parameter configuration Req.-ID: HID.GUI.001 (TBL); HID.GUI.006 (ERR); HID.DEVCONF.001; HID.DEVCONF.002; HID.DEVCONF.003; HID.DEVCONF.004 Description: The test case verifies the correct functionality of the device configuration of the IP address, net mask, default gateway and name. It verifies the display of the error message due to the input boundaries. The test case uses the test data from table TD.001 and TD.002. The test set up consists of a computer, with at least 2 devices connected to, and the software. Test Steps Step Action Expected result 1 Click on a line x in device list Line x is selected 2 Click on the properties symbol in the toolbar and fill in dataset of TD.001 Properties dialog is opened. Valid parameters can be set; invalid parameters produce the display of an error message. Datengetriebener Testfallentwurf: Trennung von Testfällen und Testdaten ▪Wiederverwendbarkeit der Testfälle und Testdaten getrennt voneinander ▪Die Wartbarkeit und Lesbarkeit der Testfälle und Testdaten wird erhöht. ▪Testfälle und Testdatenmengen können in m:n Verwendung stehen. ▪Testfälle können definiert werden, auch wenn die konkreten Testdaten noch nicht bekannt sind. ▪Eine Automatisierung der Testfälle ist leichter herzustellen bzw. es ergeben sich besser zu wartende automatisierte Tests. Strategie: Deterministisch versus Random Test data:  TD.001 Dataset IP address Default gateway Net mask Name 01 X_%&/()=? 02 Device_1 03 XDeviceY Software Engineering I VE: Qualitätssicherung analytisch Version 58

59 Voraussetzung für Automatisierbarkeit:
7. Automatisierung von Testfällen Separation von Testcode und Testdaten führt zu Besserer Wartbarkeit Testdaten und Testcode können unabhängig voneinander geändert werden Besserer Optimierbarkeit der Testdaten In Tabellenform Einfacher Automatisierbarkeit Testcode ist praktisch schon „Pseudocode“ Testdaten-Tabelle kann vom Automatisierungsskript eingelesen und abgearbeitet werden Datengetriebener Testfallentwurf: Trennung von Testfällen und Testdaten ▪Wiederverwendbarkeit der Testfälle und Testdaten getrennt voneinander ▪Die Wartbarkeit und Lesbarkeit der Testfälle und Testdaten wird erhöht. ▪Testfälle und Testdatenmengen können in m:n Verwendung stehen. ▪Testfälle können definiert werden, auch wenn die konkreten Testdaten noch nicht bekannt sind. ▪Eine Automatisierung der Testfälle ist leichter herzustellen bzw. es ergeben sich besser zu wartende automatisierte Tests. Strategie: Deterministisch versus Random Voraussetzung für Automatisierbarkeit: System muss automatisierbare PoC und PoO für die zu testende Funktionalität bereitstellen! Software Engineering I VE: Qualitätssicherung analytisch Version 59

60 Resultierende Tests sind:
Ergebnis Resultierende Tests sind: Effizient und Effektiv Strukturiert Nachvollziehbar Übersichtlich Übertragbar und Wartbar Effizienz und Effektivität - Ergebnis eines methodischen Testentwurfs Fehlerzustände werden sicherer erkannt als durch Spezifikation von Ad- Hoc-Testfällen Unabhängig von der Person, die die Testfälle spezifiziert und ausführt. Software Engineering I VE: Qualitätssicherung analytisch Version 60

61 Anforderungsbasierung ist IMMER die minimale Teststrategie
Fazit Anforderungsbasierung ist IMMER die minimale Teststrategie Gut beschriebene Anforderungen sind Voraussetzung Systematische Methodik macht Testfallentwurf und Testautomatisierung effizient Teststrategie Anforderungs- Definition Testentwurfstechniken Test Review Software Engineering I VE: Qualitätssicherung analytisch Version

62 Testfall-Managementsystem
Vorlesung SWE I Testfall-Managementsystem Software Engineering I VE 20: Von der Anforderung zum Testfall Version

63 Traceability Matrix Software Engineering I
VE: Qualitätssicherung analytisch Version

64 Requirements Coverage & Traceability
Software Engineering I VE: Qualitätssicherung analytisch Version