Upload
rosemarie-stockinger
View
105
Download
1
Embed Size (px)
Citation preview
1
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Von der Anforderung zum Testfall
Vorlesung
Software Engineering I
Analytische Qualitätssicherung:
Von der Anforderung zum Testfall
2
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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:
3
Dozenten:Markus RentschlerAndreas Stuckert
Analytische QS: Testen Debugging
• 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!
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
4
Dozenten:Markus RentschlerAndreas Stuckert
Verifikation:Die Software ist richtig!
Debugging:Warum ist die Software
nicht richtig?
Validation: Ist es die richtige Software?
Test:Ist die Software richtig?
Fragestellungen bei der analytischen SW-QS
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
Wie geht man systematisch und professionell vor ?
5
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
6
Dozenten:Markus RentschlerAndreas Stuckert
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 Entwicklungsphasedie Vorgaben der Phaseneingangs-Dokumente erfüllen.
– Haben wir das System richtig realisiert?– Wenn nicht Fehler
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
7
Dozenten:Markus RentschlerAndreas Stuckert
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 PersonAngelehnt an: DIN 66271:1995Informationstechnik - Software-Fehler und ihre Beurteilung durch Lieferanten und Kunden, Beuth Verlag, Berlin, 1995
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
8
Dozenten:Markus RentschlerAndreas Stuckert
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
• FehlermaskierungIst die Kompensierung eines Fehlerzustands durch andere, so dass keine Fehlerwirkung erkennbar ist. Ein Fehler wird also durch einen anderen Fehler verdeckt.
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
9
Dozenten:Markus RentschlerAndreas Stuckert
Zusammenhang
Fehlerwirkung
die zum Tragen kommt
Fehlerzustandbzw. Defekt
in einem Programm
Fehlhandlungeiner Person
1. Testen
2. Debugging
3. Standards, Normen, Ausbildung ...
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
10
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
11
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
12
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
13
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
14
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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./11. -5,5,9 / 5,9,-5 - Permutationen
15
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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?
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
16
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
17
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
18
Dozenten:Markus RentschlerAndreas Stuckert
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)
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
19
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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 sindimmer nur Stichproben!
20
Dozenten:Markus RentschlerAndreas Stuckert
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!
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
21
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
22
Dozenten:Markus RentschlerAndreas Stuckert
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 undBericht
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
23
Dozenten:Markus RentschlerAndreas Stuckert
Entwicklungsprozess und Testprozess
• Teststufen im Entwicklungsprozess nach V-Modell
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
24
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
Analytische Qualitätssicherung
Statischer Test
25
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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«.
26
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
27
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
28
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
29
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
30
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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)
31
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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)
32
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
33
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
34
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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– Polyspace
• http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
35
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
Analytische Qualitätssicherung
Dynamischer Test
36
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
37
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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“ bezeichnetProzessor
TestobjektAusgangsdatenEingangsdaten
Vorbedingungen NachbedingungenRandbedingungen
Prozessor
TestobjektAusgangsdatenEingangsdaten
Vorbedingungen NachbedingungenRandbedingungen
38
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
39
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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)
40
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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 !
41
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
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
42
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
Übersicht Testentwurfsverfahren
Eingangsdaten
Ohne Kenntnis derProgrammlogik abgeleitet
Ausgangsdaten
Black-box Test
Testobjekt
Eingangsdaten
Mit Kenntnis der Programmlogikabgeleitet
Ausgangsdaten
White-box Test
43
Dozenten:Markus RentschlerAndreas Stuckert
Planung und
Analyse und Design
Realisierung und Durchführung
Abschluss
Beginn
Ende
Steuerung
Auswertung undBericht
Testfallentwurf (1)
• 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!
Anforderungs-Definition
Test
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
44
Dozenten:Markus RentschlerAndreas Stuckert
Anforderungs-Definition
Test
Testfallentwurf (2)
Teststrategie
Anforderungs-Definition
Testentwurfstechniken Test
Review
Teststrategie bestimmt die Wahl der Testentwurfstechniken!
Planung und
Analyse und Design
Realisierung und Durchführung
Abschluss
Beginn
Ende
Steuerung
Auswertung undBericht
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
45
Dozenten:Markus RentschlerAndreas Stuckert
Bekannte Teststrategien
AnforderungsbasiertErfahrungsbasiert
Geschäftsprozessbasiert
White-Box-basiert
Anwendungsfallbasiert
Risikobasiert
Black-Box-basiert
ÄnderungsbasiertIntuitionsbasiert
Modellbasiert
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
46
Dozenten:Markus RentschlerAndreas Stuckert
Bekannte Testfallentwurfsmethoden
Äquivalenzklassenanalyse
Ursache-Wirkungs-Graph
Entscheidungstabellen
Grenzwertanalyse
Paarweise KombinationTest spezieller Werte
KlassifikationsbaummethodeModellbasiert
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
47
Dozenten:Markus RentschlerAndreas Stuckert
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
0min_int max_int1-1
min_int-1 min_int+1
......
max_int-1 max_int+1
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
48
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
Äquivalenzklassenbildung...
...in der Schlangenschule
49
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
Äquivalenzklassen und Grenzwerte...
50
Dozenten:Markus RentschlerAndreas Stuckert
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
Dozenten:Markus RentschlerAndreas Stuckert
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
SRS
• [SRS.FEATURE.ID] Feature Name
– Description1. …
2. …
3. …
– Limitations1. …
2. …
– Interfaces1. …
– Default Settings1. …
2. …
Traceability OK !
Requirements Traceability
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
52
Dozenten:Markus RentschlerAndreas Stuckert
Testfallentwurfs-Prozess
SRS
Identifikation eines Testfalls (STP)
Testfall entwerfen und optimieren (TCS)
Alle Anforderungen abgedeckt ?
STP
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
53
Dozenten:Markus RentschlerAndreas Stuckert
1. Anforderungen in SRS reviewen
• Qualitätsansprüche an Anforderungen:
Vollständigkeit Verständlichkeit (für alle Stakeholder)
Korrektheit EindeutigkeitVerfolgbarkeit TestbarkeitGewichtbarkeit Aktualität
• Feedback an Requirements Engineer- wenn Nachbesserung erforderlich
Anforderungs-Definition
Anforderungsreview
Feedback
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
54
Dozenten:Markus RentschlerAndreas Stuckert
2. Testfälle ableiten im STP
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
55
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
56
Dozenten:Markus RentschlerAndreas Stuckert
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=192.168.0.1,GW=192.168.0.1, NM=255.255.255.0, Name = Device_1
Properties dialog is opened. Valid parameters can be set; invalid parameters produce the display of an error message.
3 Click on the properties symbol in the toolbar and fill in the following data:IP=10.10.0.1,GW=0.0.0.0, NM=255.255.0.0, Name = Device_1
Properties dialog is opened. Valid parameters can be set; invalid parameters produce the display of an error message.
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
57
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
58
Dozenten:Markus RentschlerAndreas Stuckert
6. Optimierter Testfall
• z.B. Testfallbeschreibung mit separierten TestdatenTest 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.
Test data: TD.001
Dataset IP address Default gateway Net mask Name
01 192.168.0.254 192.168.0.1 255.255.255.0 X_%&/()=?
02 192.168.0.1 192.168.0.0 255.255.255.0 Device_1
03 10.10.0.1 1.2.3.4 255.255.0.0 XDeviceY
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
59
Dozenten:Markus RentschlerAndreas Stuckert
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
Voraussetzung für Automatisierbarkeit:System muss automatisierbare PoC und PoO für die zu testende
Funktionalität bereitstellen!
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
60
Dozenten:Markus RentschlerAndreas Stuckert
Ergebnis
• Resultierende Tests sind:
–Effizient und Effektiv
–Strukturiert
–Nachvollziehbar
–Übersichtlich
–Übertragbar und Wartbar
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
61
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
62
Dozenten:Markus RentschlerAndreas StuckertVersion 11.04.23
Software Engineering I VE 20: Von der Anforderung zum Testfall
Vorlesung SWE I
Testfall-Managementsystem
63
Dozenten:Markus RentschlerAndreas Stuckert
Traceability Matrix
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch
64
Dozenten:Markus RentschlerAndreas Stuckert
Requirements Coverage & Traceability
Version 11.04.23
Software Engineering I VE: Qualitätssicherung analytisch