+ All Categories
Home > Documents > 1 Dozenten: Markus Rentschler Andreas Stuckert Version 16.07.2015 Software Engineering I VE 16:...

1 Dozenten: Markus Rentschler Andreas Stuckert Version 16.07.2015 Software Engineering I VE 16:...

Date post: 06-Apr-2016
Category:
Upload: kristina-kuntz
View: 221 times
Download: 2 times
Share this document with a friend
57
1 Dozenten: Markus Rentschler Andreas Stuckert Version 22.01.22 Software Engineering I VE 16: Qualitätssicherung II Vorlesung Software Engineering I Qualitätssicherung II Analytische QS
Transcript

1Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Vorlesung

Software Engineering I

Qualitätssicherung IIAnalytische QS

2Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Software-Qualitätssicherung (SW-QS)

Qualitätssicherung

Analytische QS Konstruktive QS

Ergebnisse Prozesse

Dokumente

Software

Reviews,...

Testen

Audits

Normen, Standards,Prozessmodelle,Projektleitung,Software-Technik,Software-Architektur,Erfahrungsaustausch,Ausbildungsmaßnahmen...

Artefakte prüfen:

4Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 216 unterschiedliche Werte annehmen. Bei drei unabhängigen Eingabewerten ergeben sich 216 * 216 * 216 = 248 Kombinationen.

Jede dieser Kombinationen ist zu testen.

Wie lange dauert es bei 100.000 Tests pro Sekunde?

Es sind 281.474.976.710.656 TestfälleDauer: ca. 90 Jahre

5Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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:51 + 52 + ... + 518 + 519 + 520

Wie lange dauert das Austesten bei 100.000 Tests pro Sekunde?

Es sind 119.209.289.550.780 TestfälleDauer: ca. 38 Jahre

A

B

6Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 ≠ ca ≠ b = ca = c ≠ b

7Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Mögliche Testfälle (1)

Testfälle bestehen aus Testdaten und dem Soll-Ergebnis1. 2,3,4 - zulässiges ungleichseitiges Dreieck 2. 2,2,2 - zulässiges gleichseitiges Dreieck 3. 2,2,1 - zulässiges gleichschenkliges Dreieck4./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 = 07./8. 0,1,3 / 1,3,0 - Permutationen 9. 5,-5,9 - kein Dreieck, eine Seitenangabe < 010./11. -5,5,9 / 5,9,-5 - Permutationen

8Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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änge16./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?20.-22. 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

9Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Mögliche Testfälle (3)

23.-25. 1,1,4.4567 - Fehlermeldung »nicht ganzzahlige Werte« Permutationen? - zusätzlich mit 2 oder 3 Werten

26.-28. 1,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/2 + 10 - 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 anGlenford J. Myers: Methodisches Testen von Programmen.7. Auflage 2001

10Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

11Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

12Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 Entwicklungsphasedie Vorgaben der Phaseneingangs-Dokumente erfüllen.

– Haben wir das System richtig realisiert?

13Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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ätsmerkmaleund 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ät Sicherheit Zufriedenheit

Aufgabenerfüllunginnerhalb der

Genauigkeit- und Vollständigkeits-

grenzen

Effektivität

Validierung

14Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Software-Qualität nach DIN/ISO/IEC 9126 (2)

RichtigkeitAngemessenheitInteroperabilität

(Daten-)Sicherheit Ordnungs-mäßigkeit

ReifeFehlertoleranz

Wiederher-stellbarkeit

VerständlichkeitErlernbarkeitBedienbarkeit

Attraktivität

ZeitverhaltenVerbrauchs-

verhalten

AnalysierbarkeitModifizierbarkeit

StabilitätTestbarkeit

AnpassbarkeitInstallierbarkeit

KonformitätAustausch-

barkeit

Softwarequalität

Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Portierbarkeit

Gebrauchsqualität Äußere und innere Qualität

Verifikation

15Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Analytische Qualitätssicherung

Statischer Test

16Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 THEEXPERIENCE OF YEARS

17Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 THEEXPERIENCE OF YEARS

18Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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.

(Quelle: http://de.wikipedia.org/wiki/Millersche_Zahl)

19Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

20Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

21Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

22Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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)

23Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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.

24Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

25Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 und2. Review

• Problem:

26Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

27Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Statische Analysewerkzeuge

• Einige freie Werkzeuge zur statischen Codeanalyse– CCCC (http://sourceforge.net/projects/cccc/)– JUtils (http://www.jutils.com/)– PyChecker (http://c2.com/cgi/wiki?PyChecker)

• Einige kommerzielle Werkzeuge zur statischen Codeanalyse– PC-Lint– Klocwork– Coverity

• http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

28Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Analytische Qualitätssicherung

Dynamischer Test

29Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

TestobjektAusgangsdatenEingangsdaten

Vorbedingungen NachbedingungenRandbedingungen

30Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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!

31Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Dynamischer Test – Begriffe und Zusammenhänge

Prozessor

TestobjektAusgangsdatenEingangsdaten

Vorbedingungen NachbedingungenRandbedingungen

Testfall und Testszenarien

Testlauf

TestfallspezifikationTestkriteriumverifiziert

Testbasis

Testentwurfsspezifikation

Testvorgehens-spezifikation

beschreibt

Erwartete

Testobjekt-reaktion

/ Rückverfolgbarkeit

Testausführungsplanordnet

Siehe auch IEEE 829 und ISTQB Glossar

32Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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“ bezeichnetProzessor

TestobjektAusgangsdatenEingangsdaten

Vorbedingungen NachbedingungenRandbedingungen

Prozessor

TestobjektAusgangsdatenEingangsdaten

Vorbedingungen NachbedingungenRandbedingungen

33Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

34Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 1 Testfall 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

35Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 ?

36Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

37Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Black-box Test vs. White-box Test

Eingangsdaten

Mit Kenntnis der Programmlogikabgeleitet

Ausgangsdaten

White-box Test

Eingangsdaten

Ohne Kenntnis derProgrammlogik abgeleitet

Ausgangsdaten

Black-box Test

Testobjekt

38Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Übersicht Testentwurfsverfahren

39Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 AusgabenUngültige Ausgaben

WertebereicheGültige Eingaben

Ungültige EingabenFunktion

• Ä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

40Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 Wertder Äquivalenzklasse

41Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Äquivalenzklassenbildung

Äquivalenzklassenbildung in der Schlangenschule

42Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Analytische Qualitätssicherung

Strukturorientierter Test

43Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

White-Box Tests

44Dozenten:Markus RentschlerAndreas Stuckert

Beispiel: Kontrollflussgraph von ggT()

1.public int ggt (int m, int n) {// pre: m > 0 and n > 0// post: return > 0 and // [email protected](return) = 0 and //...

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. }

1

2-3

4-6

7

9-11

12

13

8

nstart

nfinal

Block

Block

Block

Version 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

45Dozenten:Markus RentschlerAndreas 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 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

46Dozenten:Markus RentschlerAndreas Stuckert

Beispiel: Anweisungsüberdeckung für ggt()

1

2-3

4-6

7

9-11

12

13

8

nstart

nfinal

1. public int ggt(int m, int n) {// pre: m > 0 and n > 0// post: return > 0 and // [email protected](return) = 0 and //...

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. }

Pfad = (1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13)

47Dozenten:Markus RentschlerAndreas Stuckert

Beispiel: Entscheidungsüberdeckung für ggt()

1

2-3

4-6

7

9-11

12

13

8

1. public int ggt (int m, int n) {// pre: m > 0 and n > 0// post: return > 0 and // [email protected](return) = 0 and //...

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. }

1

2-3

4-6

7

9-11

12

13

8

Pfad 1 = (1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13)Pfad 2 = (1, 2-3, 7, 8, 12, 13)

48Dozenten:Markus RentschlerAndreas Stuckert

Beispiel: Pfadüberdeckung für ggt()

1

2-3

4-6

7

9-11

12

13

8

1

2-3

4-6

7

9-11

12

13

8

1

2-3

4-6

7

9-11

12

13

8

1

2-3

4-6

7

9-11

12

13

8

1

2-3

4-6

7

9-11

12

13

8

...

49Dozenten:Markus RentschlerAndreas 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 }

1

2-3

4-6

7

9-11

12

13

8

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. }

m n r4 6 ?

50Dozenten:Markus RentschlerAndreas 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. }

m n r4 4 ?

1

2-3

4-6

7

9-11

12

13

8

51Dozenten:Markus RentschlerAndreas 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!

52Dozenten:Markus RentschlerAndreas Stuckert

Bewertung der White-Box-Techniken

Überdeckungsmaß Leistungsfähigkeit Bewertung

Anweisungsüberdeckung (C0)NiedrigEntdeckt knapp ein Fünftel der Fehler

Notwendig, aber nicht hinreichendEntdeckt »dead-code«Mit anderen Verfahren kombinieren!

Entscheidungsüberdeckung (Zweigüberdeckung, C1)

Mittel, schwankt aber starkEntdeckt ca. 30% aller Fehler und ca. 80% der Kontrollfluss-Fehler

Minimales TestkriteriumEntdeckt nicht ausführbare ZweigeZielt auf Verzweigungen

Bedingungsüberdeckung (C2) Niedrig Umfasst i.Allg. nicht die Anweisungs- und Entscheidungsüberdeckung

Mehrfach-Bedingungsüberdeckung Hoch

Zielt auf komplexe BedingungenUmfasst EntscheidungsüberdeckungAufwand 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-Verwendungc-uses findet viele BerechnungsfehlerKaum Tools verfügbar

Pfadüberdeckung (C)Sehr hochEntdeckt über 70% der Fehler

In den meisten Fällen nicht praktikabel

53Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Analytische Qualitätssicherung

Bewertung Testverfahren

54Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

*** ***

häufigerweniger häufigselten

Ergebnis

MaßnahmenAnforderungenSystemkonzept Design Programm System

Analyse

Test

VerifikationValidierung

*** **

** ** *** *

** *** ***

* ** ***

***

Quelle: im wesentlichen nach Trauboth, „Software Qualitätssicherung“, Oldenbourg, 1996

Inspektionen

Dokumente

***

**

( ) *

**

Bewertung Testverfahren

55Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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

56Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Lehrbuch zum Certified Tester - Foundation Level

• Andreas Spillner, Tilo LinzBasiswissen SoftwaretestAus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard

– 4. überarbeitete Auflage– dpunkt.verlag, 2010 – 308 Seiten, Gebunden– 39,90 Euro (D)– ISBN 978-3-89864-642-0

• Leseproben etc. unter:http://www.dpunkt.de/buecher/2679.html

57Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

Software Engineering I VE 16: Qualitätssicherung II

Nützliche Links

• Stickymindshttp://www.stickyminds.com/Portal mit vielen Informationen zum Test von SQE

• Web Site »Test obsessed«http://www.testobsessed.com/Information for people with a passion for software testing

• Center for Software Testing Education & Research http://www.testingeducation.com/ Artikel zum Thema Testen sowie Vorlesungsunterlagen

• Atlantic Systems Guildhttp://www.systemsguild.com/Artikel zum Testen von Anforderungen und vieles mehr

• Introduction to Software Testinghttp://www.cs.gmu.edu/~offutt/softwaretest/

58Dozenten:Markus RentschlerAndreas StuckertVersion 26.04.23

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 Marickhttp://www.exampler.com/

• James Bachhttp://www.satisfice.com/

• Elisabeth Hendricksonhttp://www.qualitytree.com/

• Hans Schäferhttp://home.c2i.net/schaefer/

• Bret Pettichord (ed.)http://www.io.com/~wazmo/qa/

• ISTQB/GTB Test-Glossarhttp://www.german-testing-board.info/downloads/pdf/CT_Glossar_DE_EN_V21.pdf


Recommended