Skript zur Vorlesung Software Engineering I

1
Vorlesung Software Engineering I
Analytische Qualitätssicherung Von der
Anforderung zum Testfall
Software Engineering I VE Von der Anforderung
zum Testfall
Version 18.01.2017
2
Software-Qualitätssicherung (SW-QS)
Qualitätssicherung
Analytische QS
Konstruktive QS
Normen, Standards,Prozessmodelle,Projektleitung,
Software-Technik,Software-Architektur,Erfahrung
saustausch,Ausbildungsmaßnahmen...
Ergebnisse
Prozesse
Audits
Artefakte prüfen
Dokumente
Reviews,...
Software
Testen
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
3
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!

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
4
Fragestellungen bei der analytischen SW-QS
Wie geht man systematisch und professionell vor ?
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
5
Qualität Fehler vs. Mangel

• Eine Situation kann nur dann als fehlerhaft
  eingestuft werden, wenn vorab festgelegt wurde,
  wie die erwartete, korrekte, also nicht
  fehlerhafte Situation aussehen soll.
• Ein Fehler ist die Nichterfüllung einer
  festgelegten Anforderung, eine Abweichung
  zwischen dem Ist-Verhalten (während der
  Ausführung der Tests oder des Betriebs
  festgestellt) und dem Soll-Verhalten (in der
  Spezifikation oder den Anforderungen festgelegt).
  
• Ein Mangel liegt vor, wenn eine gestellte
  Anforderung oder eine berechtigte Erwartung in
  Bezug auf einen beabsichtigten Gebrauch nicht
  angemessen erfüllt wird. Ein Mangel ist z.B. die
  Beeinträchtigung der Verwendbarkeit bei
  gleichzeitiger Erfüllung der Funktionalität oder
  die Nichterfüllung einer angemessenen Erwartung
  (z.B. Benutzerfreundlichkeit).

Angelehnt an DIN EN ISO 90002005
Qualitätsmanagementsysteme Grundlagen und
Begriffe. Beuth Verlag, Berlin, 2005
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
6
Definition Validierung und Verifikation

• Validierung Prüfung, ob ein Entwicklungsergebnis
  die individuellen Anforderungen bezüglich einer
  speziellen beabsichtigten Nutzung erfüllt.
• Haben wir das richtige System realisiert?
• Wenn nicht ? Mangel
• VerifikationPrüfung, ob die Ergebnisse einer
  Entwicklungsphasedie Vorgaben der
  Phaseneingangs-Dokumente erfüllen.
• Haben wir das System richtig realisiert?
• Wenn nicht ? Fehler

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
7
Ursachenkette für Fehler

• Jeder Fehler oder Mangel ist seit dem Zeitpunkt
  der Fertigstellung in der Software vorhanden. Er
  kommt jedoch erst bei der Ausführung der Software
  zum Tragen.
• Dieser Sachverhalts wird als Fehlerwirkung
  (failure) bezeichnet (auch Fehlfunktion, äußerer
  Fehler, Ausfall).
• Mögliche Ursachen einer Fehlerwirkung
• Fehlerzustand (fault) in der Software (oder
  Hardware)(auch als Defekt, innerer Fehler
  bezeichnet)
• Fehlhandlung (error) einer Person

Angelehnt an DIN 662711995Informationstechnik
- Software-Fehler und ihre Beurteilung durch
Lieferanten und Kunden, Beuth Verlag, Berlin, 1995
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
8
Fehlhandlung - Definition

• Fehlhandlung (error)
• 1. Die menschliche Handlung (des Entwicklers),
  die zu einem Fehlerzustand in der Software
  führt.
• 2. Eine menschliche Handlung (des Anwenders),
  die ein unerwünschtes Ergebnis (im Sinne von
  Fehlerwirkung) zur Folge hat (Fehlbedienung).

• Problem (issue, incident)
• Verhalten anders als erwartet, aber Ursache noch
  unklar
• Fehlermaskierung
• Ist die Kompensierung eines Fehlerzustands durch
  andere, so dass keine Fehlerwirkung erkennbar
  ist. Ein Fehler wird also durch einen anderen
  Fehler verdeckt.

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
9
Zusammenhang
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
10
Motivation
Fehler in einer Software müssen gefunden werden,
ehe diese an die Anwender oder Kunden
ausgeliefert wird. Um diesem Ziel nahe zu
kommen, muss ein effektiver und effizienter
Testprozess vorhanden sein. Hierzu müssen
geeignete Methoden und Werkzeuge ausgewählt und
angewendet werden.
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
11
Austesten ?
Ein einfaches Programm soll getestet werden, das
drei ganzzahlige Eingabewerte hat. Übrige
Randbedingungen haben keinen Einfluss auf das
Testobjekt. Jeder Eingabewert kann bei 16 Bit
Integerzahlen 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
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
12
Austesten?
Ein einfaches Programm soll getestet werden,
das aus vier Verzweigungen (IF-Anweisungen) und
einer umfassenden Schleife besteht und somit
fünf mögliche Wege im Schleifenrumpf enthält.
Unter der Annahme, dass die Verzweigungen
voneinander unabhängig sind und bei einer
Beschränkung der Schleifendurchläufe auf
maximal 20, ergibt sich folgende Rechnung 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
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
13
Erste Übung zur Testfallanalyse

• Ein Programm ist zu testen, das 3 ganzzahlige
  positive Werte einliest und als Längen eines
  Dreiecks interpretiert.
• Das Programm gibt eine Meldung aus, ob es sich
  um ein ungleichseitiges, gleichschenkliges oder
  gleichseitiges Dreieck handelt.
• Welche Testfälle werden benötigt ?
• Welche Testdaten sind sinnvoll ?

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
14
Mögliche Testfälle (1)
Testfälle bestehen aus Testdaten und dem
Soll-Ergebnis 1. 2,3,4 - zulässiges
ungleichseitiges Dreieck 2. 2,2,2 - zulässiges
gleichseitiges Dreieck 3. 2,2,1 - zulässiges
gleichschenkliges Dreieck 4./5. 1,2,2 / 2,1,2 -
Testfälle mit Permutationen für gleichschenklige
Dreiecke 6. 1,0,3 - kein Dreieck, eine
Seitenangabe 0 7./8. 0,1,3 / 1,3,0 -
Permutationen 9. 5,-5,9 - kein Dreieck, eine
Seitenangabe lt 0 10./11. -5,5,9 / 5,9,-5 -
Permutationen
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
15
Mögliche Testfälle (2)
12. 1,2,3 - kein Dreieck Summe der beiden
kürzeren Seiten 3. Seitenlänge 13./14. 2,3,1 /
3,1,2 - Permutationen 15. 1,2,4 - kein Dreieck
Summe der beiden kürzeren Seiten lt 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
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
16
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
altbltc Prüfung der Dreiecksbedingung mit abgtc,
führt ab zum Überlauf, s.a. Testfall 20) Wie
viele Tests hatten Sie überlegt?
in Anlehnung anGlenford J. Myers Methodisches
Testen von Programmen.7. Auflage 2001
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
17
Spitz-, stumpf- und rechtwinklige Dreiecke
Werden spitz-, stumpf- und rechtwinklige
Dreiecke zusätzlich berücksichtigt, ergeben sich
insgesamt 47 Testfälle. Fazit Einfaches
Problem, aber aufwendiger Test!
E. H. RiedemannTestmethoden für sequentielle
und nebenläufige Software-Systeme. Teubner
Verlag, Stuttgart 1997
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
18
Was ist eigentlich Testen ?

• Testen ist ein Verfahren, um
• Vertrauen in die Realisierung eines Systems zu
  schaffen
• Aussagen über die Qualität des Systems zu machen
• Aber zuerst und vor allem, Fehler zu finden.
• Diese Aufgabe soll der Test
• So früh wie möglich
• So kostengünstig wie möglich
• Für die wichtigsten Fehler zuerst leisten
• Testarten werden unterschieden in
• Statisch (Reviews, Codeanalyse)
• Dynamisch (stichprobenhafte Ausführung des
  Testobjekts)

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
19
Ziele des dynamischen Tests

• Nachweis der Erfüllung der festgelegten
  Anforderungen durch das Testobjekt
• Aufdeckung von eventuellen Abweichungen und
  Fehlerwirkungen
• Mit möglichst wenig Aufwand (Testfällen)
  möglichst viele Anforderungen überprüfen bzw.
  Fehler nachweisen
• Dynamische Tests sindimmer nur Stichproben!

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
20
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!

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
21
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. unterhttp//www.dpunkt.de/bueche
  r/2679.html

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
22
Der Testprozess

• Testplanung und Steuerung
• Testanalyse und Testdesign
• Testrealisierung und Testdurchführung
• Testauswertung und Bericht
• Abschluss der Testaktivitäten
• Diese Aktivitäten werden z.T. zeitlich
  überlappend oder parallel ausgeführt.
• Der fundamentale Testprozess ist für jede
  Teststufe geeignet zu gestalten.

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
23
Entwicklungsprozess und Testprozess

• Teststufen im Entwicklungsprozess nach V-Modell

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
24
Analytische Qualitätssicherung
Statischer Test
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
25
Statischer Test vs. dynamischer Test

• Im Entwicklungsprozess werden unterschiedliche
  Produkte (Artefakte) erstellt
• Informelle Texte
• Modelle
• Formale Texte
• Programmcode
• Maschinencode
• Programme sind statische Beschreibungen von
  dynamischen Prozessen.
• Dynamische Tests prüfen die durch
  Interpretation (Ausführung) der Beschreibung
  resultierenden Prozesse.
• Statische Tests untersuchen die Beschreibung als
  solche,sie wird nicht ausgeführt.

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
26
Statischer Test

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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
27
Prüfende Verfahren

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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
28
Ein Selbsttest

• Wie viele "F" kommen im folgenden Text vor?

FINISHED FILES ARE THE RE- SULT OF YEARS OF
SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE
OF YEARS
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
29
Selbsttest

• Es sind sechs!
• Wie viele hatten Sie gezählt?
• Drei zu finden ist normal - sechs wirklich gut!
• Irren ist menschlich ?

FINISHED FILES ARE THE RE- SULT OF YEARS OF
SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE
OF YEARS
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
30
Die magische Zahl Sieben

• Problem Begrenzte menschliche Wahrnehmungsfähigke
  it
• Die Millersche Zahl bezeichnet die von George A.
  Miller festgestellte Tatsache, dass ein Mensch
  gleichzeitig nur 72 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/Millers
  che_Zahl)

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
31
Manuelle vs. automatisierte Prüfung

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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
32
Statische Analyse und Reviews

• Stehen in einem engen Zusammenhang
• Wird vor dem Review eine statische Analyse
  durchgeführt, können bereits eine Anzahl von
  Fehlern und Unstimmigkeiten nachgewiesen werden
  und die Menge der im Review zu berücksichtigenden
  Aspekte ist erheblich geringer
• Da statische Analysen werkzeuggestützt
  durchgeführt werden, ist der Aufwand wesentlich
  niedriger als beim Review
• Also
• Statische Analyse und
• Review

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
33
Statische Analyse von Programmcode

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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
34
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_sta
  tic_code_analysis

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
35
Analytische Qualitätssicherung
Dynamischer Test
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
36
Statischer Test vs. dynamischer Test

• Programme sind statische Beschreibungen von
  dynamischen Prozessen
• Statische Tests untersuchen die Beschreibung als
  solche, sie wird nicht ausgeführt
• Artefakte des Entwicklungsprozesses, z.B
  informelle Texte, Modelle, formale Texte,
  Programmcode, ...
• Dynamische Tests prüfen die durch
  Interpretation (Ausführung) der Beschreibung
  resultierenden Prozesse.
• Das Testobjekt wird im dynamischen Test auf
  einem Prozessor ausgeführt
• Bereitstellen von Eingangsdaten
• Beobachten der Ausgangsdaten

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
37
Dynamischer Test in unteren Teststufen

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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
38
Aufbau eines Testrahmens
Point of Control Schnittstelle, über die das
Testobjekt mit Testdaten versorgt wird
PoC
Testausgaben Vergleich Protokoll
Testobjekt
PoO
Point of Observation Schnittstelle, an der die
Reaktionen und Ausgaben des Testobjekts
beobachtet und aufgezeichnet werden
Laufzeitumgebung, Analysewerkzeuge, Simulatoren,
Monitore
Prozessor
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
39
Unit Test Begriffe

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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
40
Fragestellungen beim Entwurf von Testfällen

• Wie viele Tests sind notwendig ?
• Welche Testdaten sollen verwendet werden ?
• Wie können fehler-sensitive Tests gefunden werden
  ?
• Wie vermeidet man redundante Test ?
• Wurden Testfälle übersehen ?
• Wann kann man mit Testen aufhören ?
• ? Testentwurfsverfahren !

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
41
Dynamischer Test Testentwurfsverfahren

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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
42
Übersicht Testentwurfsverfahren
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
43
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!

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
44
Testfallentwurf (2)
Teststrategie bestimmt die Wahl der
Testentwurfstechniken!
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
45
Bekannte Teststrategien
Anforderungsbasiert
Erfahrungsbasiert
Intuitionsbasiert
Änderungsbasiert
Black-Box-basiert
Risikobasiert
White-Box-basiert
Modellbasiert
Geschäftsprozessbasiert
Anwendungsfallbasiert
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
46
Bekannte Testfallentwurfsmethoden
Äquivalenzklassenanalyse
Entscheidungstabellen
Ursache-Wirkungs-Graph
Klassifikationsbaummethode
Modellbasiert
Test spezieller Werte
Paarweise Kombination
Grenzwertanalyse
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
47
Testdatenbestimmung

• Äquivalenzklassenmethode
• Klassen von gleichartigen Eingabewerten anhand
  der Spezifikation gt 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

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
48
Äquivalenzklassenbildung...
...in der Schlangenschule
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
49
Äquivalenzklassen und Grenzwerte...
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
50
Systemtest Grundsätzliche Methodik

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

51
Requirements Traceability

• 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
• Description
• Limitations
• Interfaces
• Default Settings

?
Traceability OK !
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
52
Testfallentwurfs-Prozess
SRS
Testfall entwerfen und optimieren (TCS)
Identifikation eines Testfalls (?STP)
Alle Anforderungen abgedeckt ?
STP
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
53
1. Anforderungen in SRS reviewen

• Qualitätsansprüche an Anforderungen
• Vollständigkeit Verständlichkeit (für alle
  Stakeholder)
• Korrektheit Eindeutigkeit
• Verfolgbarkeit Testbarkeit
• Gewichtbarkeit Aktualität
• Feedback an Requirements Engineer
• wenn Nachbesserung erforderlich

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
54
2. Testfälle ableiten im STP
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
55
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-Beschreibun
  g!)
• TCS enthält Testfallbeschreibungen
• Alternativ Testfallmanagementsystem

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
56
4. Testfälle anlegen in TCS
Test case Test case Test case Test case
ID ID ltTC.CONF.001.Fgt ltTC.CONF.001.Fgt
Name Name Device parameter configuration Device parameter configuration
Req.-ID Req.-ID HID.GUI.001 (TBL) HID.GUI.006 (ERR) HID.DEVCONF.001 HID.DEVCONF.002 HID.DEVCONF.003 HID.DEVCONF.004 HID.GUI.001 (TBL) HID.GUI.006 (ERR) HID.DEVCONF.001 HID.DEVCONF.002 HID.DEVCONF.003 HID.DEVCONF.004
Description 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. 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 Test Steps Test Steps Test Steps
Step Action Action Expected result
1 Click on first line Click on first line First line is selected
2 Click on the properties symbol in the toolbar and fill in the following data IP192.168.0.1,GW192.168.0.1, NM255.255.255.0, Name Device_1 Click on the properties symbol in the toolbar and fill in the following data IP192.168.0.1,GW192.168.0.1, NM255.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 IP10.10.0.1,GW0.0.0.0, NM255.255.0.0, Name Device_1 Click on the properties symbol in the toolbar and fill in the following data IP10.10.0.1,GW0.0.0.0, NM255.255.0.0, Name Device_1 Properties dialog is opened. Valid parameters can be set invalid parameters produce the display of an error message.

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
57
5. Testfälle entwerfen und optimieren

• Testfälle inhaltlich im Detail spezifizieren
  (?TCS)
• Anwendung von
• Äquivalenzklassenbildung (gültige und ungültige!)
• Grenzwertanalyse
• Paarbildung
• .
• Testfälle inhaltlich optimieren
• z.B. Datengetriebenen Ansatz anwenden
• Testfälle zusammenfassen
• Zum abdecken mehrerer Anforderungen
• Zum abdecken von Use-Case Szenarien

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
58
6. Optimierter Testfall

• z.B. Testfallbeschreibung mit separierten
  Testdaten

Test case Test case Test case Test case
ID ID ltTC.CONF.001.Fgt ltTC.CONF.001.Fgt
Name Name Device parameter configuration Device parameter configuration
Req.-ID Req.-ID HID.GUI.001 (TBL) HID.GUI.006 (ERR) HID.DEVCONF.001 HID.DEVCONF.002 HID.DEVCONF.003 HID.DEVCONF.004 HID.GUI.001 (TBL) HID.GUI.006 (ERR) HID.DEVCONF.001 HID.DEVCONF.002 HID.DEVCONF.003 HID.DEVCONF.004
Description 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. 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 Test Steps Test Steps Test Steps
Step Action Action Expected result
1 Click on a line x in device list 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 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 Test data  TD.001  TD.001  TD.001  TD.001
Dataset IP address IP address Default gateway Net mask Name
01 192.168.0.254 192.168.0.254 192.168.0.1 255.255.255.0 X_/()?
02 192.168.0.1 192.168.0.1 192.168.0.0 255.255.255.0 Device_1
03 10.10.0.1 10.10.0.1 1.2.3.4 255.255.0.0 XDeviceY
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
59
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!
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
60
Ergebnis

• Resultierende Tests sind
• Effizient und Effektiv
• Strukturiert
• Nachvollziehbar
• Übersichtlich
• Übertragbar und Wartbar

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
61
Fazit

• Anforderungsbasierung ist IMMER die minimale
  Teststrategie
• Gut beschriebene Anforderungen sind Voraussetzung
• Systematische Methodik macht Testfallentwurf und
  Testautomatisierung effizient

Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
62
Vorlesung SWE I
Testfall-Managementsystem
Software Engineering I VE 20 Von der
Anforderung zum Testfall
Version 18.01.2017
63
Traceability Matrix
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017
64
Requirements Coverage Traceability
Software Engineering I VE Qualitätssicherung
analytisch
Version 18.01.2017