Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Dozenten: Markus Rentschler Andreas Stuckert Version 16.07.2015 Software Engineering I VE 16: Qualitätssicherung II Vorlesung Software Engineering I.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Dozenten: Markus Rentschler Andreas Stuckert Version 16.07.2015 Software Engineering I VE 16: Qualitätssicherung II Vorlesung Software Engineering I."—  Präsentation transkript:

1 1 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Vorlesung Software Engineering I Qualitätssicherung II Analytische QS

2 2 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Software-Qualitätssicherung (SW-QS) Qualitätssicherung Analytische QSKonstruktive QS ErgebnisseProzesse Dokumente Software Reviews,... Testen Audits Normen, Standards, Prozessmodelle, Projektleitung, Software-Technik, Software-Architektur, Erfahrungsaustausch, Ausbildungsmaßnahmen... Artefakte prüfen:

3 3 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Verifikation: Die Software ist richtig! Debugging: Warum ist die Software nicht richtig? Validation: Ist es die richtige Software? Test: Ist die Software richtig? Fragestellung beim Testen

4 4 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 2 16 unterschiedliche Werte annehmen. Bei drei unabhängigen Eingabewerten ergeben sich 2 16 * 2 16 * 2 16 = 2 48 Kombinationen. Jede dieser Kombinationen ist zu testen. Wie lange dauert es bei Tests pro Sekunde? Es sind Testfälle Dauer: ca. 90 Jahre

5 5 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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

6 6 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 = b  c a  b = c a = c  b

7 7 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 2 weitere 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./11. -5,5,9 / 5,9,-5 - Permutationen

8 8 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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

9 9 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 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

10 10 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Spitz-, stumpf- und rechtwinklige Dreiecke Werden spitz-, stumpf- und rechtwinklige Dreiecke zusätzlich berücksichtigt, ergeben sich insgesamt 47 Testfälle. Resümee: Einfaches Problem, aber aufwendiger Test! E. H. Riedemann: Testmethoden für sequentielle und nebenläufige Software-Systeme. Teubner Verlag, Stuttgart 1997

11 11 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Definition Qualität Die Erfüllung von Qualitätszielen, die durch Vorgaben für Qualitätsmerkmale und ihre Teilmerkmale definiert sind Qualität ist der Grad, in dem von einem Satz inhärenter Merkmale (eines Produkts) die Anforderungen erfüllt werden. (DIN EN ISO 9000:2005) Qualitätsmerkmale beziehen sich immer auf Anforderungen –Funktionale Anforderungen (Fachlichkeit, Funktionen, Schnittstellen,...) –Nicht-Funktionale Anforderungen (Qualitäts- und Realisierungsanforderungen, Projektspezifische Anforderungen,...) Angelehnt an: DIN EN ISO 9000:2005 Qualitätsmanagementsysteme – Grundlagen und Begriffe. Beuth Verlag, Berlin, 2005

12 12 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Validierung und Verifikation - Definition Validierung Prüfung, ob ein Entwicklungsergebnis die individuellen Anforderungen bezüglich einer speziellen beabsichtigten Nutzung erfüllt. –Haben wir das richtige System realisiert? Verifikation Prüfung, ob die Ergebnisse einer Entwicklungsphase die Vorgaben der Phaseneingangs-Dokumente erfüllen. –Haben wir das System richtig realisiert?

13 13 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Software-Qualität nach DIN/ISO/IEC 9126 (1) Softwarequalität ISO/IEC 9126:1991 Bewerten von Softwareprodukten, Qualitätsmerkmale und Leitfaden zu ihrer Verwendung (identisch mit DIN 66272, 94) Gebrauchsqualität Äußere und innere Qualität Aufgabenerfüllung innerhalb der Aufwandsgrenzen für Benutzer (Zeit, Kosten,...) Aufgabenerfüllung innerhalb der Risikogrenzen (Leben und Gesundheit, Business,...) Subjektive Zufriedenheit der Benutzer innerhalb des Nutzungskontexts ProduktivitätSicherheitZufriedenheit Aufgabenerfüllung innerhalb der Genauigkeit- und Vollständigkeits- grenzen Effektivität Validierung

14 14 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Software-Qualität nach DIN/ISO/IEC 9126 (2) Richtigkeit Angemessenheit Interoperabilität (Daten-)Sicherheit Ordnungs- mäßigkeit Reife Fehlertoleranz Wiederher- stellbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität Zeitverhalten Verbrauchs- verhalten Analysierbarkeit Modifizierbarkeit Stabilität Testbarkeit Anpassbarkeit Installierbarkeit Konformität Austausch- barkeit Softwarequalität FunktionalitätZuverlässigkeitBenutzbarkeitEffizienzÄnderbarkeitPortierbarkeit Gebrauchsqualität Äußere und innere Qualität Verifikation

15 15 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Analytische Qualitätssicherung Statischer Test

16 16 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Zunächst 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

17 17 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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

18 18 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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.George A. MillerChunksKurzzeitgedächtnisPsychologie (Quelle:

19 19 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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

20 20 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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

21 21 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 Ziel eines Walk-Throughs ist, Problembereiche zu entdecken, sie aber erst nach Abschluß des Walk-Throughs und nach Zustimmung des Erstellers zu beheben Peer Review entspricht dem Walk Through. Es geht dabei um eine methodische Examinierung der Ergebnisse 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

22 22 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 (z.B. Programmtext, UML-Diagramme)

23 23 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Zielsetzung statische Analyse Aufdeckung vorhandener Fehlerzustände oder fehlerträchtiger Stellen in einem formalen Dokument. Durch werkzeuggestützte Prüfung, z.B. –Rechtschreibprüfprogramme als eine Art statische Analysatoren, die (Rechtschreib- und – eingeschränkt – Grammatik-) Fehler in Texten nachweisen und damit zur Qualitätsverbesserung beitragen Ermittlung von Metriken (Messgrößen), um eine Qualitätsbewertung durchführen und somit Qualität messen und nachweisen zu können.

24 24 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Statische Analyse und Werkzeugunterstützung Statische Analyse mit Werkzeugunterstützung kann nur auf einem formal strukturierten Dokument durchgeführt werden. Formale Dokumente können z. B. sein: –Technische Anforderungen –Softwarearchitektur-Modelle –Softwareentwurf-Modelle –Programmcode Informeller Text kann unterhalb der Oberflächenstruktur (Rechtschreibung und elementare Grammatik) nur mit Methoden der KI (künstliche Intelligenz) analysiert werden –Linguistische semantische Analyse ist aktueller Forschungsgegenstand –Aber: Einführung einer »Normsprache« ermöglicht auch hier einfachere Analysen

25 25 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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: 1.Statische Analyse und 2.Review Problem:

26 26 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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

27 27 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Statische Analysewerkzeuge Einige freie Werkzeuge zur statischen Codeanalyse –CCCC (http://sourceforge.net/projects/cccc/)http://sourceforge.net/projects/cccc/ –JUtils (http://www.jutils.com/)http://www.jutils.com/ –PyChecker (http://c2.com/cgi/wiki?PyChecker)http://c2.com/cgi/wiki?PyChecker Einige kommerzielle Werkzeuge zur statischen Codeanalyse –PC-Lint –Klocwork –Coverity

28 28 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Analytische Qualitätssicherung Dynamischer Test

29 29 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 AusgangsdatenEingangsdaten VorbedingungenNachbedingungen Randbedingungen

30 30 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 Aber: Dynamische Tests sind immer nur Stichproben!

31 31 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Dynamischer Test – Begriffe und Zusammenhänge Prozessor Testobjekt AusgangsdatenEingangsdaten VorbedingungenNachbedingungen Randbedingungen Testfall und Testszenarien Testlauf Testfallspezifikation Testkriterium verifiziert Testbasis Testentwurfsspezifikation Testvorgehens- spezifikation beschreibt Erwartete Testobjekt- reaktion / Rückverfolgbarkeit Testausführungsplan ordnet Siehe auch IEEE 829 und ISTQB Glossar

32 32 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 –Bieten oft Operationen/Dienste für andere Softwareeinheiten an –Haben kein „Hauptprogramm“ zur Koordination des Ablaufes –Stützen sich oft auf Operationen/Diensten anderer Softwareeinheiten ab In den „unteren“ Teststufen Klassen-/Modultest, Komponententest und Integrationstest muss das Testobjekt also in einen entsprechenden „Testrahmen“ eingebettet werden  Oft als „Unit-Test“ bezeichnet

33 33 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 Testumgebung –Gesamtheit aller Hardware- und Softwarekomponenten (auch der Testrahmen), die notwendig sind, um Testfälle durchzuführen 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) Simulator –Werkzeug, mit dem die Einsatz- bzw. Produktivumgebung nachgebildet wird

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

35 35 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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 ?

36 36 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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. –Keine Informationen über den Programmtext und den inneren Aufbau –Beobachtet wird 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 der internen Struktur einer Komponente oder Systems

37 37 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Black-box Test vs. White-box Test Eingangsdaten Mit Kenntnis der Programmlogik abgeleitet Ausgangsdaten White-box Test Eingangsdaten Ohne Kenntnis der Programmlogik abgeleitet Ausgangsdaten Black-box Test Testobjekt

38 38 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Übersicht Testentwurfsverfahren

39 39 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Testfall- und Testdatenermittlung Y (1,...,m) X (1,...,n) Y = F (X) Parameter Ergebnisse Wertebereiche Gültige Ausgaben Ungültige Ausgaben Wertebereiche Gültige Eingaben Ungültige Eingaben Funktion Äquivalenzklassenbildung –Repräsentative Eingaben –Gültige Dateneingaben –Ungültige Dateneingaben Grenzwertanalyse –Wertebereiche –Wertebereichsgrenzen Entscheidungstabellentest –Bedingungen und Aktionen Zustandsbezogener Test –Komplexe (innere) Zustände und Zustandsübergänge Anwendungsfallbasierter Test –Szenarien der Systemnutzung

40 40 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Äquivalenzklassenbildung Die Definitionsbereiche der Ein- und Ausgaben werden so in Äquivalenzklassen (ÄK) zerlegt (partitioniert), dass alle Werte einer Klasse äquivalentes Verhalten des Prüflings ergeben –Wenn ein Wert der ÄK einen Fehler aufdeckt, wird erwartet, dass auch jeder andere Wert der ÄK diesen Fehler aufdeckt –Wenn ein Wert der ÄK keinen Fehler aufdeckt, wird erwartet, dass auch kein anderer Wert der ÄK einen Fehler aufdeckt Aus jeder Äquivalenzklasse wird dann nur ein Repräsentant getestet! engl. „Partition Testing“ Definitionsbereich Äquivalenzklasse Ein beliebiger Wert der Äquivalenzklasse

41 41 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Äquivalenzklassenbildung Äquivalenzklassenbildung in der Schlangenschule

42 42 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Analytische Qualitätssicherung Strukturorientierter Test

43 43 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II White-Box Tests Eingangsdaten Mit Kenntnis der Programmlogik abgeleitet Ausgangsdaten White-box Test

44 44 Dozenten: Markus Rentschler Andreas Stuckert Beispiel: Kontrollflussgraph von ggT() 1.public int ggt (int m, int n) { // pre: m > 0 and n > 0 // post: return > 0 and // = 0 and // int r; 3.if (n > m) { 4. r = m; 5. m = n; 6. n = r; } 7.r = m % n; 8.while (r != 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12.return n; 13. } n start n final Block Version Software Engineering I VE 16: Qualitätssicherung II

45 45 Dozenten: Markus Rentschler Andreas Stuckert Strukturorientierte Testverfahren Kontrollflussbasiert –Anweisungsüberdeckung ( statement coverage ): (C0-Überdeckung, alle Knoten des Kontrollflussgraphen) –Entscheidungsüberdeckung ( decision coverage ): (C1-Überdeckung, Zweigüberdeckung, d.h. bei Knoten mit mehr als einer ausgehenden Kante alle diese Kanten) –Pfadüberdeckung ( path coverage ): (C  -Überdeckung, alle Pfade) Datenflussbasiert –Alle Definitionen ( all defs ) –Alle Definition-Benutzung-Paare ( all def-uses ) Bedingungsbasiert –Einfache Bedingungsüberdeckung ( branch condition testing) –Mehrfachbedingungsüberdeckung ( branch condition combination testing) –Minimale Mehrfachbedingungsüberdeckung ( modified branch condition decision testing) Version Software Engineering I VE 16: Qualitätssicherung II

46 46 Dozenten: Markus Rentschler Andreas Stuckert Beispiel: Anweisungsüberdeckung für ggt() n start n final 1. public int ggt(int m, int n) { // pre: m > 0 and n > 0 // post: return > 0 and // = 0 and // int r; 3. if (n > m) { 4. r = m; 5. m = n; 6. n = r; } 7. r = m % n; 8. while (r != 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 13. } Pfad = (1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13)

47 47 Dozenten: Markus Rentschler Andreas Stuckert Beispiel: Entscheidungsüberdeckung für ggt() public int ggt (int m, int n) { // pre: m > 0 and n > 0 // post: return > 0 and // = 0 and // int r; 3. if (n > m) { 4. r = m; 5. m = n; 6. n = r; } 7. r = m % n; 8. while (r != 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 13. } Pfad 1 = (1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13) Pfad 2 = (1, 2-3, 7, 8, 12, 13)

48 48 Dozenten: Markus Rentschler Andreas Stuckert Beispiel: Pfadüberdeckung für ggt()

49 49 Dozenten: Markus Rentschler Andreas Stuckert Testfall zur Anweisungsüberdeckung Pfad: (1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13) Logischer Testfall: { n > m  n % m ≠ 0  n % (n % m) = 0 ; ggt(m, n) } Konkreter Testfall: { m = 4, n = 6; 2 } public int ggt(int m, int n) { 2. int r; 3. if (n > m) { 4. r = m; 5. m = n; 6. n = r; } 7. r = m % n; 8. while (r != 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 13. } mnr 46?

50 50 Dozenten: Markus Rentschler Andreas Stuckert Testfall zur Entscheidungsüberdeckung Pfad: (1, 2-3, 7, 8, 12, 13) Logischer Testfall: {n  m  m % n = 0 ; ggt(m, n) } Konkreter Testfall: { m = 4, n = 4; 4 } 1. public int ggt(int m, int n) { 2. int r; 3. if (n > m) { 4. r = m; 5. m = n; 6. n = r; } 7. r = m % n; 8. while (r != 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 13. } mnr 44?

51 51 Dozenten: Markus Rentschler Andreas Stuckert White-Box Tests und Instrumentierung Bei den White-box Verfahren wird gefordert, dass bestimmte Programmteile zur Ausführung kommen bzw. Bedingungen unterschiedliche Wahrheitswerte annehmen Um den Test auswerten zu können, muss ermittelt werden, welche Programmteile bereits ausgeführt wurden und welche noch nicht zur Ausführung gekommen sind Dazu muss das Testobjekt an strategisch wichtigen Stellen vor der Testausführung instrumentiert werden –Es werden zusätzlich Anweisungen wie z.B. Zähler eingebaut und mit Null initialisiert, die dann beim Durchlauf an den entsprechenden Stellen inkrementiert werden –Ist ein Zähler auf Null geblieben, so sind die entsprechenden Programmteile nicht ausgeführt worden Instrumentierung größerer Programme nur mit Werkzeugen sinnvoll!

52 52 Dozenten: Markus Rentschler Andreas Stuckert Bewertung der White-Box-Techniken ÜberdeckungsmaßLeistungsfähigkeitBewertung Anweisungsüberdeckung (C 0 ) Niedrig Entdeckt knapp ein Fünftel der Fehler Notwendig, aber nicht hinreichend Entdeckt »dead-code« Mit anderen Verfahren kombinieren! Entscheidungsüberdeckung (Zweigüberdeckung, C 1 ) Mittel, schwankt aber stark Entdeckt ca. 30% aller Fehler und ca. 80% der Kontrollfluss-Fehler Minimales Testkriterium Entdeckt nicht ausführbare Zweige Zielt auf Verzweigungen Bedingungsüberdeckung (C 2 )Niedrig Umfasst i.Allg. nicht die Anweisungs- und Entscheidungsüberdeckung Mehrfach- Bedingungsüberdeckung Hoch Zielt auf komplexe Bedingungen Umfasst Entscheidungsüberdeckung Aufwand wächst stark Datenflusstest Mittel bis hoch, All c-uses ca. 50%, All p- uses ca. 34%, all defs ca. 25% (keine Berechnungsfehler!) Zielt auf Variablen-Verwendung c-uses findet viele Berechnungsfehler Kaum Tools verfügbar Pfadüberdeckung (C  ) Sehr hoch Entdeckt über 70% der Fehler In den meisten Fällen nicht praktikabel

53 53 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Analytische Qualitätssicherung Bewertung Testverfahren

54 54 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II *** ** * häufiger weniger häufig selten Ergebnis Maßnahmen Anforderungen Systemkonzept DesignProgrammSystem Analyse Test Verifikation Validierung ***** **** ** ****** Quelle: im wesentlichen nach Trauboth, „Software Qualitätssicherung“, Oldenbourg, 1996 Inspektionen Dokumente *** ** () * Bewertung Testverfahren

55 55 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Zusammenfassung Testen hat zum Ziel, Fehler zu finden Testfälle sind stichprobenhafte Eingaben an das System mit definierten erwarteten Ergebnissen Testfall-Spezifikationsmethoden sind strukturierte Anweisungen zur Generierung von qualitativ hochwertigen Testfällen mit vielen Vorteilen gegenüber „zufälligen“ Tests Eine Teststrategie hat zum Ziel, die wichtigsten Fehler so früh wie möglich mit geringen Kosten zu finden Testen ist ein Prozess, der den gesamten Software-Lebenszyklus begleitet Der Testprozess basiert auf vier Eckpfeilern: –Phasenmodell –Passende Methoden –Ressourcen und Infrastruktur –Organisatorische Einbettung

56 56 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II 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:

57 57 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Nützliche Links Stickyminds Portal mit vielen Informationen zum Test von SQE Web Site »Test obsessed« Information for people with a passion for software testing Center for Software Testing Education & Research Artikel zum Thema Testen sowie Vorlesungsunterlagen Atlantic Systems Guild Artikel zum Testen von Anforderungen und vieles mehr Introduction to Software Testing

58 58 Dozenten: Markus Rentschler Andreas Stuckert Version Software Engineering I VE 16: Qualitätssicherung II Nützliche Links Web Sites von bekannten Testfachleuten meist mit Literaturempfehlungen, Links, lesenswerten Artikeln, Tool-Hinweisen u.a. Brian Marick James Bach Elisabeth Hendrickson Hans Schäfer Bret Pettichord (ed.) ISTQB/GTB Test-Glossar


Herunterladen ppt "1 Dozenten: Markus Rentschler Andreas Stuckert Version 16.07.2015 Software Engineering I VE 16: Qualitätssicherung II Vorlesung Software Engineering I."

Ähnliche Präsentationen


Google-Anzeigen