Qualitätsmanagement. Software Engineering 1 WS 2011/2012. Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig

Größe: px
Ab Seite anzeigen:

Download "Qualitätsmanagement. Software Engineering 1 WS 2011/2012. Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig"

Transkript

1 Qualitätsmanagement Software Engineering 1 WS 2011/2012 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von Prof. B. Rumpe und Dr. A. Herrmann)

2 Was ist Qualität? Qualität: Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht [DIN 55350, Teil 11] Achtung: bezieht sich auf Produkt und Prozess. Achtung: Qualitäts-Anforderungen ändern sich mit der Zeit! Achtung: Qualität muss gegenüber Kosten und Zeit abgewogen werden Dr. Ina Schaefer Software Engineering 1 Seite 2

3 Qualität nach ISO9216 Funktionalität Angemessenheit Sicherheit Genauigkeit der Berechnung Interoperabilität Konformanz zu Standards Zuverlässigkeit Reife Fehlertoleranz Wiederherstellbarkeit Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Effizienz Zeitverhalten Verbrauchsverhalten Änderbarkeit Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Konformanz zu Standards Austauschbarkeit Dr. Ina Schaefer Software Engineering 1 Seite 3

4 Verifikation & Validierung Benutzererwartungen Anforderungsdokument... Code Verifikation: haben wir es richtig gemacht? Validierung: haben wir das Richtige gemacht? Dr. Ina Schaefer Software Engineering 1 Seite 4

5 Übersicht Konstruktive Qualitätssicherung Qualität von Prozessen Reifegradmodelle Analytische Qualitätssicherung Statische Tests (Reviews) Dynamische Tests Begriffe und Grundsätze Testprozess Testmethoden Testarten (Unit-, Integrations-, System-, Akzeptanztest) Dr. Ina Schaefer Software Engineering 1 Seite 5

6 Produktqualität und Prozessqualität Software: Kaum Qualitätsmängel durch Massenproduktion Qualitätsmängel im Herstellungsprozess begründet Qualitätsmanagement: Organisatorische Maßnahmen zur Prüfung und Verbesserung der Prozessqualität Beachtung von internen Kunden-/Lieferantenbeziehungen Konstruktive Qualitätssicherung: Qualität des Prozesses Analytische Qualitätssicherung: Qualität des Produkts Dr. Ina Schaefer Software Engineering 1 Seite 6

7 ISO 9000 Internationales Normenwerk ISO 9000: Allgemeiner Leitfaden ISO : Leitfaden zur Anwendung von ISO 9001 auf Software ISO 9001: Modelle zur Darlegung der Qualitätssicherung insbesondere in Entwurf und Entwicklung Allgemeingültige Forderungen an die Organisation eines Unternehmens: Regelung von Zuständigkeiten Erstellung und korrekte Verwaltung wesentlicher Dokumente Existenz eines unabhängigen Qualitätssicherungs-Systems Zertifizierung: durch unabhängige (zertifizierte) Prüforganisationen Audit, Prüfsiegel ISO 9000 prüft nicht die Qualität des Produkts, sondern die Qualität der Organisation! Dr. Ina Schaefer Software Engineering 1 Seite 7

8 Reifegradmodelle: Ziele und Nutzen messen Reife des gesamten Software-Entwicklungsprozesses entdecken Schwachstellen und Verbesserungspotenzial schlagen Maßnahmen zur Qualitätsverbesserung vor messen die Wirkung dieser Maßnahmen helfen bei Bewertung von Lieferanten bei Auftragsvergabe Dr. Ina Schaefer Software Engineering 1 Seite 8

9 Reifegradmodelle: Beispiele CMM CMMI (Weiterentwicklung von CMM, quasi V2.0) BOOTSTRAP (Erweiterung und Anpassung von CMM für Europa) SPICE/ ISO (Weiterentwicklung von Bootstrap) DIN ISO 9000 TQM = Total Quality Management Dr. Ina Schaefer Software Engineering 1 Seite 9

10 Capability Maturity Model (CMM) Entwickelt 1987 von Software Engineering Institute (SEI), Vorläufer Mutter vieler späterer Modelle 1991 CMM Version 1.0, 1993 CMM V CMMI = Capability Maturity Model Integrated, löst CMM ab Fragebögen mit ja/nein-fragen 5 Reifegrad-Stufen Um Stufe x+1 zu erreichen, müssen alle Bedingungen von Stufe x erfüllt sein. Dr. Ina Schaefer Software Engineering 1 Seite 10

11 Capability Maturity Model (CMM) Stufe 4: Gesteuert Stufe 5: Optimierend Kontrolle über Produktqualität Kontrolle über Prozessqualität Stufe 3: Definiert Kosten und Termine zuverlässig, aber Qualität schwankend Stufe 2: Wiederholbar Stufe 1: Stufe1: Initialer Prozess Initial Terminkontrolle, aber Kosten und Qualität schwanken Kosten, Zeit, Qualität unvorhersehbar Dr. Ina Schaefer Software Engineering 1 Seite 11

12 5 Stufen in CMMI 1. Ad hoc (Initial) Keine formelle Planung und Kontrolle Kein oder schlechtes Konfigurationsmanagement 2. Wiederholbar (Repeatable) Etabliertes Projektmanagement Abwicklung von Standardprojekten wird beherrscht. bei neuartigen Projekten größere Risiken Prozess ist abhängig von den Personen, die ihn durchführen. Keine etablierten Maßnahmen zur Verbesserung des Prozesses 3. Definiert (Defined) Der Prozess ist klar definiert und läuft definitionsgemäß ab. Es existiert eine Gruppe mit der Aufgabe, den Software Engineering Prozess zu lenken und zu verbessern. Dr. Ina Schaefer Software Engineering 1 Seite 12

13 5 Stufen in CMMI (2) 4. Geführt (Managed) Eine Mindestmenge an Qualitäts- und Produktivitätsmessgrößen wird erhoben und ausgewertet. Es gibt eine Datenbank, in der alle relevanten Daten über den Prozess abgelegt werden und Mittel zur Pflege und Auswertung dieser Daten. 5. Optimierend (Optimizing) Etablierter Regelkreis für Messung und Verbesserung des Prozesses Datenerhebung und Erkennung von Schwachstellen weitgehend automatisiert. Durchgeführte Maßnahmen aus dem erhobenen Datenmaterial begründet. Etablierte Ursachenanalyse für alle Fehler und zugehörige Fehlerpräventionsmaßnahmen. Dr. Ina Schaefer Software Engineering 1 Seite 13

14 Analytische Qualitätssicherung Ziel: Überprüfen, ob Produkt die Aufgabenspezifikation erfüllt Prüfmethoden: Beweis (mathematischer Nachweis, nur bei einfachen Programmen händisch möglich, ansonsten komplexe Beweis- Werkzeuge) Test (Ausprobieren für eine sorgfältig ausgewählte Menge von Eingaben) Inspektion (systematisches Durchlesen) Metriken (automatische Bestimmung von Charakteristika) Dr. Ina Schaefer Software Engineering 1 Seite 14

15 Statische und Dynamische Tests Statische Tests: Überprüfung nicht-ausführbarer Entwicklungsartefakte (Dokumente) durch Inspektionen und Reviews Dynamische Tests: Überprüfung ausführbarer Artefakte (Prototypen, Programmcode) durch Testdaten Dr. Ina Schaefer Software Engineering 1 Seite 15

16 Test-Arten im V-Modell Reviews, Prototyp der Oberfläche Reviews, Konsistenzprüfungen, Machbarkeitsstudien Code-Reviews, Test-Planung Dr. Ina Schaefer Software Engineering 1 Seite 16

17 Qualitätssicherung für Analyse und Entwurf Hohe Bedeutung früher Phasen für Produktqualität! Deshalb: Alle Dokumente frühzeitig überprüfen ("Validation"). Techniken: Anforderungskatalog-Begutachtung Echte Benutzer einbeziehen Anforderungskatalog auf Vollständigkeit und Korrektheit prüfen Use-Case-Szenarien Echte Benutzer einbeziehen "Funktionsfähigkeit" der abstrakten Modelle demonstrieren Prototyping Prototyp auf der Basis der Analyse/Entwurfs-Dokumente Echte Benutzer einbeziehen Vorgezogener Akzeptanztest Abgleich des Entwurfs mit Use-Cases/Anforderungskatalog Erste verifizierende Tätigkeiten Dr. Ina Schaefer Software Engineering 1 Seite 17

18 Begutachtung (Review) Produkt wird von Expertengremium begutachtet Anwendbar auf fast alle Phasen der Entwicklung Was wird begutachtet? Genau definiertes Dokument (Art, Status, Prozesseinbindung) Teil der Gesamtplanung des Projekts (Termin) Wer begutachtet? Teammitglieder (Peer-Review) Externe Spezialisten Echte Benutzer Moderator, Manager Wie läuft die Begutachtung ab? Einladung Vorbereitung, Sammlung von Kommentaren Begutachtungssitzung(en), Protokolle Auswertung und Konsequenzen (Wiederholung, Statusänderung) Dr. Ina Schaefer Software Engineering 1 Seite 18

19 Regeln für wirkungsvolle Begutachtung "Checklisten" für die Gutachter vorbereiten z.b. "Enthält das Dokument alle laut Firmenstandard vorgesehenen Informationen?" - "Gibt es für jede Klasse eine informelle Beschreibung?" - "Sind Kardinalitäten im Klassendiagramm vollständig und korrekt?" - "Sind alle Klassen kohärent?" -... Das Dokument wird begutachtet, nicht die Autoren! Richtige Vorkenntnisse der Gutachter sind wesentlich. Die Rolle des Moderators ist anspruchsvoll: Vermittlung in persönlichen Konflikten und Gruppenkonflikten Fachlicher Gesamtüberblick Das Ziel ist Einigkeit, nicht ein Abstimmungsergebnis! Ergebnisse von Begutachtungen müssen Auswirkungen haben. Wesentliche Beiträge von Gutachtern müssen Anerkennung finden. Begutachtung ist auch anwendbar auf Programm-Code (Code-Inspektion). Dr. Ina Schaefer Software Engineering 1 Seite 19

20 Dynamisches Testen: Begriffe Testgegenstand (Testling, Prüfling): Programm bzw. Komponente, die zu testen ist Testfall: Satz von Eingabedaten, der die (vollständige) Ausführung des Testgegenstands bewirkt Testdaten: Daten, die für den Testfall benötigt werden Testtreiber: Rahmenprogramm für Ausführung von Tests Attrappe (Stub, Dummy): Ersatz für ein (noch) nicht vorhandenes Unterprogramm Regressionstest: Nachweis, dass eine geänderte Version des Testgegenstands früher durchgeführte Tests erneut besteht Alphatest: Test experimenteller Vorversion durch Benutzer Betatest: Test funktional vollständiger Software durch Benutzer Dr. Ina Schaefer Software Engineering 1 Seite 20

21 Fehlfunktionen Fehlfunktion (fault): Unerwartete Reaktion des Testlings Unterscheidung zwischen dem fehlerhaften Code (error, bug) und dem Auftreten des Fehler (fault): Ein fault kann aufgrund mehrerer bugs auftreten. Ein bug kann mehrere faults hervorrufen. Arten von Fehlfunktionen: Falsches oder fehlendes Ergebnis Nichtterminierung Unerwartete oder falsche Fehlermeldung Inkonsistenter Speicherzustand Unnötige Ressourcenbelastung (z.b. von Speicher) Unerwartetes Auslösen einer Ausnahme, "Abstürze" Falsches Abfangen einer Ausnahme Dr. Ina Schaefer Software Engineering 1 Seite 21

22 Grundsätze des Testens Nach: ISTQB Syllabus Certified Tester Foundation Level Grundsatz 1 Vollständiges Testen - Austesten - ist nicht möglich. Grundsatz 2 Mit Testen wird die Anwesenheit von Fehlerwirkungen nachgewiesen. Dass keine Fehlerzustände im Testobjekt vorhanden sind, kann durch Testen nicht gezeigt werden. Program testing can be used to show the presence of bugs, but never to show their absence! Edsger Dijkstra Dr. Ina Schaefer Software Engineering 1 Seite 22

23 Grundsätze des Testens (2) Grundsatz 3 Testen ist keine späte Phase in der Softwareentwicklung, es soll damit so früh wie möglich begonnen werden. Durch frühzeitiges Prüfen (z.b. Reviews) werden früher Fehler(zustände) erkannt und somit Kosten gesenkt. Grundsatz 4 Fehlerzustände sind in einem Testobjekt nicht gleichmäßig verteilt, vielmehr treten sie gehäuft auf. Dort wo viele Fehlerwirkungen nachgewiesen wurden, finden sich vermutlich auch noch weitere. Dr. Ina Schaefer Software Engineering 1 Seite 23

24 Grundsätze des Testens Grundsatz 5 Tests nur zu wiederholen, bringt keine neuen Erkenntnisse. Testfälle sind zu prüfen, zu aktualisieren und zu modifizieren. Grundsatz 6 Testen ist abhängig vom Umfeld. Sicherheitskritische Systeme sind intensiver zu testen als beispielsweise der Internetauftritt einer Einrichtung. Grundsatz 7 Ein System ohne Fehlerwirkungen bedeutet nicht, dass das System auch den Vorstellungen der späteren Nutzer entspricht. Dr. Ina Schaefer Software Engineering 1 Seite 24

25 Pareto-Prinzip % der Fehlfunktionen % der betroffenen Module Fenton/Ohlsson 2000 und andere empirische Untersuchungen: 20 % der Module sind verantwortlich für 60 % der Fehler Diese 20 % der Module entsprechen 30 % des Codes Testmuster: "Scratch'n sniff" Fehlerhafte Stellen deuten oft auf weitere Fehler in der Nähe hin. Dr. Ina Schaefer Software Engineering 1 Seite 25

26 Testplanung und Testkonzept Testen ist aufwändig, deshalb ist gute Planung nötig! Testplanung sollte bereits mit der Anforderungsanalyse beginnen und im Entwurf verfeinert werden (V-Modell, Test-First-Ansatz)! Typische Bestandteile eines Testkonzepts: Phasenmodell des Testprozesses Zusammenhang zur Anforderungsspezifikation z.b. dort festgelegte Qualitätsziele Zu testende Produkte Zeitplan für die Tests Abhängigkeiten der Testphasen Aufzeichnung der Testergebnisse Hardware- und Softwareanforderungen Einschränkungen und Probleme Dr. Ina Schaefer Software Engineering 1 Seite 26

27 Testprozess Testspezifikation: Testfälle, Priorisierung, Testdaten und Soll- Ergebnisse Testplanung: Ressourcen, Aufwand, Termine Testdurchführung: sowie Testprotokollierung und Meldung des Fehlers an den Entwickler (Fehlerverwaltung) Testmanagement: Prüfen der Testberichte und Entscheidung über Testende Dr. Ina Schaefer Software Engineering 1 Seite 27

28 Details der Teststrategie Pro Dokument und Entwicklungsergebnis Festlegung der Testmethode Festlegung des Abdeckungsgrades Priorisierung der einzelnen Tests Eintrittswahrscheinlichkeit eines Fehlers (z.b. häufig vom Kunden genutztes Prüfobjekt, intern kritisches Prüfobjekt, komplexes Prüfobjekt) Fehlerschwere Für Kunden: Schaden beim Auftreten bzw. Zufriedenheit Für Hersteller: Größe des Behebungsaufwandes Priorität der Anforderungen Dr. Ina Schaefer Software Engineering 1 Seite 28

29 Testfälle Logischer Testfall: abstrakte Beschreibung eines Testfalls Konkreter Testfall: Konkretisierung eines logischen Testfalls durch Testdaten Testlauf: Protokoll einer Durchführung eines konkreten Testfalls Logischer Testfall 1 1..n konkreter 1 1..n Testfall Testlauf Dr. Ina Schaefer Software Engineering 1 Seite 29

30 Testfallspezifikation Inhalt einer Test case specification : Test case specification identifier Test items Input specifications Output specifications Environmental needs (hardware, software, others) Special procedural requirements Intercase dependencies (nach IEEE Standard for Software Test Documentation ) Dr. Ina Schaefer Software Engineering 1 Seite 30

31 Testberichte/ Testendekriterium Testberichte: Welche Tests wurden mit welchem Ergebnis durchgeführt? Testabdeckung = Anzahl der durchgeführten Tests / Anzahl der durchzuführenden Tests Anzahl der noch offenen Fehler Priorisierung von Testfällen und Fehlern Testendekriterium: Wann wird die QS beendet? Alle Testfälle durchgeführt? Alle Fehler behoben? Alle schweren Fehler behoben? Nimmt Fehlerfindungsrate ab? Termin erreicht?/ Budget verbraucht? Dr. Ina Schaefer Software Engineering 1 Seite 31

32 Fehlerverwaltung Informationen pro Fehler: Testfall, Testdurchführung, Eingabedaten und Ergebnis Zuständiger Tester Zuständiger Entwickler (für Fehlerbehebung) Status Offen (von Tester entdeckt, Entwickler zuständig) in Bearbeitung (durch Entwickler) Behoben (durch Entwickler, Tester wieder zuständig) Erledigt (=Bestätigung durch Tester) Schwere. z.b.: schwer = Arbeit unmöglich + kein Workaround vorhanden mittel = Arbeit erschwert + Workaround vorhanden leicht = stört nicht beim Arbeiten) Dr. Ina Schaefer Software Engineering 1 Seite 32

33 Testarten Baustein- Test Modul- Test Integration Bausteintest (unit test): Traditionell: Prozeduren OO: Methoden Modultest: Traditionell: Module OO: Klassen Integrations- Test System- Test Akzeptanz- Test Integrationstest: OO: Pakete Dr. Ina Schaefer Software Engineering 1 Seite 33

34 Testmethoden Funktionaler Test (black box test):testfallauswahl beruht auf Spezifikation) Äquivalenzklassentest, Grenzwerte, Test spezieller Werte Zustandstest auf Spezifikationsbasis Strukturtest (white box test, glass box test):testfallauswahl beruht auf Programmstruktur Kontrollflussorientierter Test Anweisungsüberdeckung, Zweigüberdeckung, Pfadüberdeckung Datenflussorientierter Test: Definition/Verwendung von Variablen Weitere Testmethoden (Beispiele) Zufallstest ("monkey test") Stress-, Lasttest Dr. Ina Schaefer Software Engineering 1 Seite 34

35 Funktionaler Test (black box) Funktionale" Spezifikation" Erwartete" Ausgabedaten" Vergleich" Testfälle" (Eingabedaten)" Programm-" ausführung" Ausgabe-" daten" Dr. Ina Schaefer Software Engineering 1 Seite 35

36 Äquivalenzklassentest Äquivalenzklasse: Teilmenge der möglichen Datenwerte der Eingabeparameter Annahme: Programm reagiert für alle Werte aus der Äquivalenzklasse prinzipiell gleich Test je eines Repräsentanten jeder Äquivalenzklasse Finden von Äquivalenzklassen: Kriterien für Werte entwickeln und diese wo sinnvoll kombinieren Zulässige und unzulässige Teilbereiche der Datenwerte Unterteilung der zulässigen Bereiche nach verschiedenen Ausgabewerten Dr. Ina Schaefer Software Engineering 1 Seite 36

37 Äquivalenzklassentest: Beispiel int search (int[] a, int k) Vorbedingung: a.length >= 0 Nachbedingung: (result 0 a[result] == k) (result == 1 ( i. 0 i < a.length a[i] == k)) Kriterien für Äquivalenzklassen: Kriterium 1A: a.length == 0 Kriterium 1B: a.length > 0 Kriterium 2A: k in a Kriterium 2B: k nicht in a Äquivalenzklassen / Testfälle: drei Äq.-Klassen, da 1A und 2A nicht kompatibel a == [], k == 17, result == undef. (1A, 2B) a == [11, 17, 45], k == 17, result == 1 (1B, 2A) a == [11, 23, 45], k == 17, result == -1 (1B, 2B) Dr. Ina Schaefer Software Engineering 1 Seite 37

38 Grenzwertanalyse und Test spezieller Werte Grenzwerte: Randfälle der Spezifikation Werte, bei denen "gerade noch" ein gleichartiges Ergebnis zum Nachbarwert erzielt wird, bzw. "gerade schon" ein andersartiges Beispiele: Ränder von Zahl-Intervallen Schwellenwerte Spezielle Werte: Zahlenwert 0 Leere Felder, Sequenzen und Zeichenreihen Einelementige Felder, Sequenzen und Zeichenreihen Null-Referenzen Sonderzeichen (Steuerzeichen, Tabulator) Dr. Ina Schaefer Software Engineering 1 Seite 38

39 Grenzwertanalyse: Beispiel int search (int[] a, int k) Vorbedingung: a.length > 0 Nachbedingung: (result 0 a[result] == k) (result == 1 ( i. 0 i < a.length a[i] == k)) Weitere Kriterien für Äquivalenzklassen: 3A: Element am linken Rand a[0]==k 3B: Element am rechten Rand a.last==k 3C: Element an keinem Rand... 4A: a einelementig a.length==1 4B: a nicht einelementig a.length!=1 5A: k ist 0 k==0 5B: k ist nicht 0 k!=0 Neue Testfälle: a == [17], k == 17, result == 0 (Kriterien 1B, 2B, 3A+B, 4A, 5B) a == [11, 23, 0], k == 0, result == 2 (Kriterien 1B, 2B, 3B, 4B, 5A) Dr. Ina Schaefer Software Engineering 1 Seite 39

40 Strukturtest (glass-box) Programm-" Code" Testfälle" (Eingabedaten)" Programm-" ausführung" Ausgabe-" daten" Vergleich" Funktionale" Spezifikation" oder" "Orakel"" Erwartete" Ausgabedaten" Dr. Ina Schaefer Software Engineering 1 Seite 40

41 Überdeckungsgrad (coverage) Maß für die Vollständigkeit eines Tests Welcher Anteil des Programmtexts wurde ausgetestet? Messung der Überdeckung: Instrumentierung des Programmcodes Ausgabe statistischer Informationen Planung der Überdeckung: gezielte Anlage der Tests auf volle Überdeckung Überdeckungsarten: Anweisungsüberdeckung: Anteil ausgeführter Anweisungen Zweigüberdeckung: Anteil ausgeführter Anweisungen und Verzweigungen Pfadüberdeckung: Anteil ausgeführter Programmablaufpfade Hilfsmittel: Kontrollflussgraph Dr. Ina Schaefer Software Engineering 1 Seite 41

42 Beispielprogramm: Binäre Suche public static final int NOTFOUND = -1; // Binaere Suche auf Array a. // Annahme: a ist sortiert // Ergebnis ist NOTFOUND, wenn k nicht in A enthalten ist. // Ergebnis ist i falls a[i] gleich k ist. public static int binsearch (int[] a, int k) { int ug = 0, og = a.length-1, m, pos = NOTFOUND; while (ug <= og && pos == NOTFOUND) { m = (ug + og) / 2; if (a[m] == k) pos = m; else if (a[m] < k) ug = m + 1; else og = m - 1; }; return pos; } Dr. Ina Schaefer Software Engineering 1 Seite 42

43 Binäre Suche - Kontrollflussgraph public static final int NOTFOUND = -1; 1 public static int binsearch (int[] a, int k) { int ug = 0, og = a.length-1, m, pos = NOTFOUND; // 1 while (ug <= og && pos == NOTFOUND) { // 2 m = (ug + og) / 2; // 3 if (a[m] == k) // pos = m; // 5 else if (a[m] < k) // 6 ug = m + 1; // 7 else og = m - 1; // 8 }; return pos; // 9 } 9 Dr. Ina Schaefer Software Engineering 1 Seite 43

44 Anweisungsüberdeckender Test Überdeckung aller Anweisungen: C 0 -Test Jede Anweisung (numerierte Zeile) des Programms wird mindestens einmal ausgeführt. Beispiel: a = {11, 22, 33, 44, 55}, k = 33 überdeckt Anweisungen: 1, 2, 3, 4, 5, 9 a = {11, 22, 33, 44, 55}, k = 15 überdeckt Anweisungen: 1, 2, 3, 4, 6, 7, 8, 9 Beide Testfälle zusammen erreichen volle Anweisungsüberdeckung. Messen der Anweisungsüberdeckung: "Instrumentieren" des Codes (durch Werkzeuge) Einfügen von Zählanweisungen bei jeder Anweisung Dr. Ina Schaefer Software Engineering 1 Seite 44

45 Zweigüberdeckender Test Überdeckung aller Zweige: C 1 -Test Bei jeder Fallunterscheidung (einschließlich Schleifen) werden beide Zweige ausgeführt (Bedingung=true und Bedingung=false). Zweigtest zwingt auch zur Untersuchung "leerer" Alternativen: Beispiel: if (x >= 1) y = true; // kein else-fall Die beiden Testfälle der letzten Folie überdecken alle Zweige. Messung/Instrumentierung von Anweisung i: Fallunterscheidung: if (...) { bt[i]++;... } else { bf[i]++;... } While-Schleife: while (...) { bt[i]++;... } bf[i]++; Dr. Ina Schaefer Software Engineering 1 Seite 45

46 Pfadüberdeckung Pfad = Sequenz von Knoten im Kontrollflussgraphen, so dass in der Sequenz aufeinanderfolgende Knoten im Graphen direkt miteinander verbunden sind. Anfang = Startknoten, Ende = Endknoten. Theoretisch optimales Testverfahren Explosion der Zahl von möglichen Pfaden, deshalb nicht praxisrelevant. (Schleifen haben unendliche Pfad-Anzahlen) Praktikablere Varianten, z.b. bounded-interior-pfadtest: Alle Schleifenrümpfe höchstens n-mal (z.b. einmal) wiederholen Dr. Ina Schaefer Software Engineering 1 Seite 46

47 Testen objektorientierter Programme Klassische Verfahren anwendbar für einzelne Methoden aber: Methoden vergleichsweise kurz und einfach Komplexität liegt zum großen Teil in der Kooperation. Probleme mit Vererbung: Tests der Oberklassen müssen u.u. für alle Unterklassen wiederholt werden: Beeinflussung von Variablen der Oberklasse Redefinition von Methoden der Oberklasse Dr. Ina Schaefer Software Engineering 1 Seite 47

48 Klassentest Festlegung einer Testreihenfolge für einzelne Methoden Konstruktoren Get-Methoden Boolsche Methoden (is ) Set-Methoden Iteratoren Komplexe Berechnung oder Ablaufsteuerung in einer Klasse Sonstige Methoden Destruktoren Dr. Ina Schaefer Software Engineering 1 Seite 48

49 Klassentest (2) Festlegung einer Testreihenfolge für das Zusammenspiel der Methoden Berücksichtige Abhängigkeiten zwischen den Methodenaufrufen Nicht-modal: keine (z.b. Sortierung) Testfälle müssen internen Zustand nicht berücksichtigen Uni-modal: feste Reihenfolge (z.b. Ampel) Testfälle testen alle zulässigen und unzulässigen Reihenfolgen Quasi-modal: inhaltsabhängige Reihenfolge (z.b. Stack) Testfälle für alle Zustände und Zustandsübergänge Modal: fachliche Reihenfolge (z.b. Konto) Wie quasi-modal Zusätzliche Berücksichtigung fachlicher Zusammenhänge Dr. Ina Schaefer Software Engineering 1 Seite 49

50 Zustandstests Spezifikationsbezogen ("black box"): Verwendung von Zustandsdiagrammen (z.b. UML) aus Analyse und Entwurf Abdeckungskriterien: alle Zustände alle Übergänge für jeden Übergang alle Folgeübergänge der Länge n Praxistauglich Programmbezogen ("glass box"): Automatische Berechnung eines Zustandsdiagramms Zustand = Abstraktion einer Klasse zulässiger Attributwerte Bestimmung der Übergänge erfordert symbolische Auswertung von Methoden (problematisch bei Schleifen und Rekursion) Im Forschungsstadium Dr. Ina Schaefer Software Engineering 1 Seite 50

51 Test-driven Development Programmierer testen meist nicht gerne. Testen ist zerstörerische Tätigkeit. Zu spätes Testen führt zu komplizierten Fehlersuchen! Test-First-Ansatz: Tests entstehen parallel zum Code (oder sogar vor dem Code) Programmierer schreiben Tests für praktischen Nutzen: Klare Spezifikation von Schnittstellen Beschreibung kritischer Ausführungsbedingungen Dokumentation von Fehlerbeseitigung Festhalten von notwendigem Verhalten vor größerem Umbau ("Refaktorisierung") Tests werden archiviert und sind automatisch ausführbar. Weitere Information: K. Beck, E. Gamma: Programmers love writing tests (JUnit) K. Beck: Extreme programming explained, Addison-Wesley 2000 Dr. Ina Schaefer Software Engineering 1 Seite 51

52 Wohin mit dem Test-Code? Zur Durchführung von Tests entsteht zusätzlicher Code: Testtreiber Testattrappen (Stubs) Testsuiten Testcode muss aufbewahrt werden, da Tests nach allen größeren Änderungen wiederholt werden. Alternativen: Testcode als Bestandteil der Klassen einfach zu verwalten, vergrößert Code "Spiegelbildliche" Hierarchie von Testklassen Redundanzproblem Erleichtert Verwendung von Test-Frameworks (z.b. JUnit) Testskripten in eigenen Sprachen klassischer Ansatz, keine Vererbung von Testfällen möglich Test-Unterklassen problematisch wegen Mehrfachvererbung Dr. Ina Schaefer Software Engineering 1 Seite 52

53 Testfallerzeugung mit JUnit JUnit (http://www.junit.org/, aktuellw Version 4.0) kleines Test Framework hat für Java schnell weite Verbreitung gefunden Testfälle werden in Java codiert (kein Sprachwechsel für Tests) Framework kümmert sich um automatisierte Testfallausführung Testausführung ist wiederholbar. Dr. Ina Schaefer Software Engineering 1 Seite 53

54 JUnit & Test-First Test-First ist Grundsatz von XP (extreme Programming) Test a little, code a little 0. Wir überlegen uns erste Testfälle für die geforderte Funktionalität. Wiederholung der Schritte 1-6: 1. Auswahl des nächsten Testfalls. 2. Wir entwerfen einen Test, der zunächst fehlschlagen sollte. 3. Wir schreiben gerade soviel Code, dass sich der Test übersetzen lässt (Signatur). 4. Wir prüfen, ob der Test fehlschlägt. 5. Wir schreiben gerade soviel Code, dass der Test erfüllt sein sollte. 6. Wir prüfen, ob der Test durchläuft. 7. Die Entwicklung ist abgeschlossen, wenn uns keine weiteren Tests mehr einfallen, die fehlschlagen können. Dr. Ina Schaefer Software Engineering 1 Seite 54

55 Anwendungsbeispiel: Konto 0. Wir überlegen uns erste Testfälle Erzeuge neues Konto (Account) für Kunden Mache eine Einzahlung (deposit) Mache eine Abhebung (withdraw) Überweisung zwischen zwei Konten, Auswahl des nächsten Testfalls: Erzeuge Konto Dr. Ina Schaefer Software Engineering 1 Seite 55

56 2. Wir entwerfen einen Test import static org.junit.assert.*; import public class AccountTest { public void testcreateaccount() { Account account = new Account("Customer"); assertequals("customer", account.getcustomer()); assertequals(0, account.getbalance()); } } assertx-methoden werden genutzt, um Ergebnisse zu prüfen Testmethoden beginnen mit test : Sie führen die getesteten Methoden aus und prüfen das Ergebnis Dr. Ina Schaefer Software Engineering 1 Seite 56

57 3. Wir schreiben gerade soviel Code, dass sich der Test übersetzen lässt public class Account { public Account(String customer) { } } public String getcustomer() { } return null; public int getbalance() { } return 0; Die zu testende Klasse kennt die Testklasse nicht und kann daher auch ohne Tests eingesetzt werden. Übersetzbarkeit bedeutet: Signaturen + Default-Return-Werte sind vorhanden 4. Wir prüfen, ob der Test fehlschlägt: Dr. Ina Schaefer Software Engineering 1 Seite 57

58 5. Wir schreiben gerade soviel Code, dass der Test erfüllt sein sollte public class Account { private String customer; public Account(String customer) { this.customer = customer; } public String getcustomer() { return customer; } public int getbalance() { return 0; } } Im Beispiel werden also der Konstruktor und getcustomer umgesetzt sowie die notwendige Datenstruktur (String customer) definiert. 6. Wir prüfen, ob der Test durchläuft: Dr. Ina Schaefer Software Engineering 1 Seite 58

59 Weiterer Test: Abheben public class AccountTest {... private Account protected void setup() { account = new Account("Customer"); } public void testwithdraw() throws Exception { account.deposit(100); account.withdraw(50); assertequals(50, account.getbalance()); try { account.withdraw(51); fail("amountnotcoveredexception expected"); } catch (Exception expected) {} } wird vor jedem Test aufgerufen und erzeugt (gemeinsame) wird nach jedem Test aufgerufen, um aufzuräumen Mehrere tests in einer Testklasse sind möglich Auch erwartete Exceptions können getestet werden Dr. Ina Schaefer Software Engineering 1 Seite 59

60 TestSuite Testfälle organisieren import org.junit.runner.junitcore; public class AllTests { public static void main(string[] args) { JUnitCore.runClasses(AccountTest.class); } } Alle Tests in einer Testklassen können nacheinander ausgeführt werden. Dr. Ina Schaefer Software Engineering 1 Seite 60

61 Neuerungen von JUnit 3 zu JUnit 4 Man braucht nicht mehr von TestCase ableiten. Die Test-Methoden benötigen nicht mehr den Präfix test, stattdessen kann die verwendet werden. Statt setup() nun Statt teardown() nun Einfaches Testen von Exception-Auslösung durch die Alte JUnit-Testfälle können problemlos mit JUnit4 verwendet werden JUnit4-Testfälle können mit Hilfe des JUnit4TestAdapters auch in alten JUnit-Version ausgeführt werden Dr. Ina Schaefer Software Engineering 1 Seite 61

62 Integrationstests Integrationstests betrachten das Zusammenspiel von Komponenten. Falls Komponenten nicht allein lauffähig sind, muss Testrahmen bereitgestellt werden. Platzhalter (Stubs) Ersetzen nicht Vorhandene Codeteile Testobjekt Laufzeitumgebung, Monitore (protokol- lieren Ausgaben) Testtreiber (Driver) Liefern Testdaten, Stossen Ausführung an Dr. Ina Schaefer Software Engineering 1 Seite 62

63 Top-Down Integrationsteststrategie Benötigt viele Stubs, wenige Testtreiber Testing Level 1 Level 1 sequence... Level 2 Level 2 Level 2 Level 2 Level 2 stubs Level 3 stubs Dr. Ina Schaefer Software Engineering 1 Seite 63

64 Bottom-Up Integrationsteststrategie Benötigt viele Testtreiber, keine Stubs Test drivers Level N Level N Level N Level N Level N Testing sequence Test drivers Level Nœ1 Level Nœ1 Level Nœ1 Dr. Ina Schaefer Software Engineering 1 Seite 64

65 Inkrementelle Integration Test, dass neue Komponente nicht bisheriges Zusammenspiel stört. A T1 A T1 A T1 T2 B T2 T2 B T3 B T3 C T3 T4 C T4 D T5 Test sequence 1 Test sequence 2 Test sequence 3 Dr. Ina Schaefer Software Engineering 1 Seite 65

3. Qualitätsmanagement 3.1. Prozessqualität

3. Qualitätsmanagement 3.1. Prozessqualität Farbe! Softwaretechnik Vorlesung 3. Qualitätsmanagement Prof. Dr. Bernhard Rumpe Technische Universität Braunschweig http://www.sse-tubs.de/ 3. Qualitätsmanagement 3.1. Prozessqualität Analyse Entwurf

Mehr

Prof. Dr. B. Rumpe Software Systems Engineering TU Braunschweig. Seite 4. vl15.fse/02/01

Prof. Dr. B. Rumpe Software Systems Engineering TU Braunschweig. Seite 4. vl15.fse/02/01 Seite 4 Qualitätssicherung für Analyse und Entwurf Farbe! Softwaretechnik Vorlesung Prof. Dr. Bernhard Rumpe Technische Universität Braunschweig http://www.sse-tubs.de/ Hohe Bedeutung früher Phasen für

Mehr

Qualitätsmanagement. Software Engineering 1 WS 2010/2011. Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig

Qualitätsmanagement. Software Engineering 1 WS 2010/2011. Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig Qualitätsmanagement Software Engineering 1 WS 2010/2011 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von Prof. B. Rumpe und Dr. A. Herrmann) Was ist Qualität?

Mehr

7. Qualitätssicherung

7. Qualitätssicherung 7. Qualitätssicherung 7.1 Test und Integration Test, Integration Wartung Allg. Literatur: Sommerville 19-20 Balzert Band 2, LE 14-15 Ambler Kap. 12 Speziell: Robert V. Binder: Testing object-oriented systems,

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Thema: Testen von objektorientierter Software

Thema: Testen von objektorientierter Software Seminar Simulation und Bildanalyse mit Java Thema: Testen von objektorientierter Software Uta Dienst 1. Teil: Einführung in den Software-Test 2. Teil: JUnit-Einführung Uta Dienst 17.11.2003 2 1. Teil:

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

Programmiertechnik II

Programmiertechnik II Modultests Ziele Überprüfung der Korrektheit eines Moduls Korrektheit: Übereinstimmung mit (informaler) Spezifikation Modul: kleine testbare Einheit (Funktion, Klasse) Engl.: unit test White box testing

Mehr

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

Mehr

Qualitätssicherung. Was ist Qualität?

Qualitätssicherung. Was ist Qualität? Ein Überblick Methoden und Werkzeuge zur Softwareproduktion Was ist Qualität? "Als Qualität eines Gegenstandes bezeichnen wir die Gesamtheit seiner charakteristischen Eigenschaften" Hesse et al. 2 Was

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011 Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/2011 1 2 Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte der Softwareentwicklung.

Mehr

Einfaches Programmtesten

Einfaches Programmtesten http://www.constructionphotography.com Einfaches Programmtesten OOPM, Ralf Lämmel Naives Testen versus systematisches Testen (C) Ralf Lämmel, OOPM, Universität Koblenz-Landau 76 (C) Ralf Lämmel, OOPM,

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop

Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Christoph Niedermayr 20.01.2005 Überblick 1 2 X in the loop Rapid Prototyping Begriffe Was versteht man unter statischem

Mehr

Unit Testing, SUnit & You

Unit Testing, SUnit & You HUMBOLDT-UNIVERSITÄT ZU BERLIN MENSCH-TECHNIK-INTERAKTION ARBEITSGRUPPE SOFTWARETECHNIK (INSTITUT FÜR INFORMATIK) ARBEITSGRUPPE INGENEURPSYCHOLOGIE (INSTITUT FÜR PSYCHOLOGIE) Unit Testing, SUnit & You

Mehr

Lehrplan: SW- Qualitätssicherung

Lehrplan: SW- Qualitätssicherung Lehrplan: SW- Qualitätssicherung Tobias Brückmann Volker Gruhn Gliederung 1 Grundlagen und Kontext im SW- Prozess 1.1 Ursachen und Risiken von SW- Fehlern 1.2 KlassifikaGon von Fehlern 1.3 Begriffe (Qualität,

Mehr

Software Engineering. Produktqualität - Dynamische Testverfahren

Software Engineering. Produktqualität - Dynamische Testverfahren Software Engineering Produktqualität - Dynamische Testverfahren Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

Software Engineering. 9. Testen

Software Engineering. 9. Testen Software Engineering 9. Testen Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Testen Konfigurationsmanagement

Mehr

Unit Tests mit Junit 4. Dario Borchers

Unit Tests mit Junit 4. Dario Borchers Unit Tests mit Junit 4 Dario Borchers Agenda Warum testgetriebene Entwicklung von Software? - Motivation Was ist testgetriebene Entwicklung? - Prozess der testgetriebenen Entwicklung - Arten von Tests

Mehr

Konzeption. und prototypische Implementierung. eines Werkzeuges. für den funktionalen Klassentest

Konzeption. und prototypische Implementierung. eines Werkzeuges. für den funktionalen Klassentest Konzeption und prototypische Implementierung eines Werkzeuges für den funktionalen Klassentest Übersicht Motivation Zielsetzung Lösungsansatz und dessen Realisierung Anwendungs-Szenarien Präsentation von

Mehr

JUnit - Test Driven Development. Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1

JUnit - Test Driven Development. Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1 JUnit - Test Driven Development Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1 Gliederung 1.Einleitung 1.1 Geschichte 1.2 Was sind Unit-Tests? 1.3 Failures/Errors 1.4 Ziele und Nutzen

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Dirk Wischermann Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 18. Dezember 2006 Inhalt Nachlese

Mehr

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014 Programmierprojekt Anne0e Bieniusa Sommersemester 2014 Phasen der So;ware- Entwicklung Planungsphase DefiniConsphase Entwurfsphase ImplemenCerungsphase Testphase Wasserfall- Modell Einführungs- und Wartungsphase

Mehr

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit 1 DYNAMISCHER TEST Whitebox Testen mit JUnit Übersicht 2 1. Grundlagen des Unittests 1. Units 2. Unit Testing 2. Testverfahren 1. Blackbox 2. Whitebox 3. Unit Testing mit Eclipse 4. Besprechung der Übungsaufgabe

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung 2007 Dr. Klaudia Dussa-Zieger P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung Testberichterstattung Lehrplan

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

Fortgeschrittenes Programmieren mit Java. Test Driven Development

Fortgeschrittenes Programmieren mit Java. Test Driven Development Fortgeschrittenes Programmieren mit Java Test Driven Development Test getriebene Programmierung Benedikt Boeck Hochschule für Angewandte Wissenschaften Hamburg 6. November 2009 B. Boeck (HAW Hamburg) Test

Mehr

Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck

Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck Unit Tests Programmiermethodik Eva Zangerle Universität Innsbruck Überblick Einführung Java Ein erster Überblick Objektorientierung Vererbung und Polymorphismus Ausnahmebehandlung Pakete und Javadoc Spezielle

Mehr

QADVICE. Forum 7-it. Software- und System-Qualitätssicherung für IT-Infrastrukturlösungen. Hermann Will 18.05.2010

QADVICE. Forum 7-it. Software- und System-Qualitätssicherung für IT-Infrastrukturlösungen. Hermann Will 18.05.2010 Forum 7-it Software- und System-Qualitätssicherung für IT-Infrastrukturlösungen Hermann Will 18.05.2010 18.05.2010 Copyright Hermann Will 2010 Folie 1 Agenda Einführung QS Testobjekte Teststrategie Testtechniken

Mehr

Test-Driven Design: Ein einfaches Beispiel

Test-Driven Design: Ein einfaches Beispiel Test-Driven Design: Ein einfaches Beispiel Martin Wirsing in Zusammenarbeit mit Moritz Hammer und Axel Rauschmayer SS 06 2 Ziele Veranschaulichung der Technik des Test-Driven Design am Beispiel eines Programms

Mehr

,$ -. "+0 *+*+ ! / -#$%$. #$%'' $ () 1 2$ #$%$! 1 2$3 )!

,$ -. +0 *+*+ ! / -#$%$. #$%'' $ () 1 2$ #$%$! 1 2$3 )! *+*+ *,$ -.! / -#$%$. #$%'' $ () "+0 *+*+ 4 *+*+ 1 2$ #$%$! 1 2$3 )! 1 *+*+ $& #$%'!' '!' 5 1! 1 4$5%! 1 63$ 1 $7$! 1 3! 1 77 8'7 1 /!$' 1 83% *+*+ 0 #$%'' '' #$%'' ''$' )%! $' #$% 5 87 $ 8$! 7$+ 1 #$%9$

Mehr

Das Test-Framework JUnit ETIS SS04

Das Test-Framework JUnit ETIS SS04 Das Test-Framework JUnit ETIS SS04 Gliederung Motivation TestFirst Grundlagen Assert TestCase Lebenszyklus TestCase UML-Diagramm TestCase TestSuite Zusammenfassung 2 Motivation (I) Kostspielige Folgen

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Qualitätsmanagement. Grundlagen

Qualitätsmanagement. Grundlagen Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Allgemein: Klassen testbar machen. 5. Mocking. Mocks programmieren. Zusammenspiel von Klassen testen

Allgemein: Klassen testbar machen. 5. Mocking. Mocks programmieren. Zusammenspiel von Klassen testen 5. Mocking Allgemein: Klassen testbar machen Wie werden Klassen testbar Entwicklung von Mocks mit der Hand Einführung in JMock Spezifikation von Mocks mit JMock Wann ist Mocking-Werkzeug sinnvoll Literatur:

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit

Mehr

Testen mit JUnit. Martin Wirsing. Ziele. in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang

Testen mit JUnit. Martin Wirsing. Ziele. in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang Testen mit JUnit Martin Wirsing in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang 12/04 2 Ziele Lernen Unit Tests zu schreiben Lernen mit Unit-Testen mit JUnit durchzuführen 3 Testen Da

Mehr

Wie misst man Qualität?

Wie misst man Qualität? Software Systems Engineering Wie misst man Qualität? Dr. Privat-Doz. A Herrmann Institut Software Systems Engineering Ziele dieses Workshops Workshop Wie misst man Qualität? Methoden lernen: Herleitung

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Basiswissen Softwaretest Vergleich der Vorlesung Software-Engineering Wartung und Qualitätssicherung (Stand WS13/14) mit der 4. überarbeiteten und aktualisierten Auflage von Spillner&Linz: Basiswissen

Mehr

6 Systematisches Testen von Programmen

6 Systematisches Testen von Programmen 6 Systematisches Testen von Programmen Testen Untersuchung des Source-Codes nach Fehlern und Anomalien Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 6 p.1/24 Untersuchung des Source-Codes

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Praxiswissen Softwaretest - Testmanagement

Praxiswissen Softwaretest - Testmanagement Praxiswissen Softwaretest - Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard dpunkt.verlag 1 Einleitung 1 1.1 Basiswissen - komprimiert 4 1.2 Praxiswissen Testmanagement

Mehr

Unit Testing mit JUnit. Dr. Andreas Schroeder

Unit Testing mit JUnit. Dr. Andreas Schroeder Unit Testing mit JUnit Dr. Andreas Schroeder Überblick Was dieses Video behandelt Warum Testen? Was sind Unit Tests? Der Teufelskreis des Nicht-Testens JUnit Unit Test Vorteile Test-Inspiration Wann aufhören?

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Software - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

Mehr

T2 Fundamentaler Testprozess

T2 Fundamentaler Testprozess T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

Techniken im Software-Test

Techniken im Software-Test Techniken im Software-Test München, 4. Juli 2000 Heiko Lötzbeyer Institut für Informatik Lehrstuhl für Technische Universität München Inhalt Ziele des Software Tests Überblick Teststufen Unit-Test Integrationstest

Mehr

Software Tests (1) Unabhängige ngige Tests

Software Tests (1) Unabhängige ngige Tests Software Tests (1) Unabhängige ngige Tests Was ist? Was ist Software Qualität? DIN ISO 9126: Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen

Mehr

Testen von Software. Dr. Stefan Hanenberg Universität Duisburg-Essen. Universität Osnabrück, 17.11.2006. 1. Motivation und grundlegende Eigenschaften

Testen von Software. Dr. Stefan Hanenberg Universität Duisburg-Essen. Universität Osnabrück, 17.11.2006. 1. Motivation und grundlegende Eigenschaften University of Duisburg Essen (Germany) Institute for Computer Science and Business Information Systems Testen von Software Dr. Stefan Hanenberg Universität Duisburg-Essen Universität Osnabrück, 17.11.2006

Mehr

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1.

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1. Leitfaden API Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza Dokumentenstatus Freigegeben at work Version 1.0 Verteiler Fachgruppe API Änderungen Datum Version Autor Inhaltsverzeichnis 1 Beschreibung

Mehr

2.2 Ansätze zur Qualitätssicherung

2.2 Ansätze zur Qualitätssicherung 2.2 Ansätze zur Qualitätssicherung 13 2.2 Ansätze zur Qualitätssicherung Im folgenden Kapitel sollen bewährte Ansätze vorgestellt werden, die zur Bewertung und Verbesserung der Produkt- und Prozessqualität

Mehr

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG Unit-Test Theorie und Praxis Stephan Seefeld, INGTES AG Inhalt Was sind Unit-Test? NUnit für.net Demo Seite 2 Quellen Für diesen Vortrag verwendete Quellen: dotnet User Group Berlin Brandenburg http://www.dotnet-berlinbrandenburg.de/

Mehr

Unit Tests in der Testgetriebenen Entwicklung

Unit Tests in der Testgetriebenen Entwicklung Unit Tests in der Testgetriebenen Entwicklung Reduzierung des Testanteils am Gesamtsoftwareentwicklungsaufwand -- neue Strategien und Tools -- Hauptseminar Systemorientierte Informatik Christian Krauß

Mehr

Software-Engineering

Software-Engineering SWE8 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 8: Qualitätsmanagement SWE8 Slide 2 Qualitätsmanagement Qualitätskriterium: Korrektheit Korrektheit bedeutet: Übereinstimmung zwischen

Mehr

Softwarequalität: Einführung. 15. April 2015

Softwarequalität: Einführung. 15. April 2015 Softwarequalität: Einführung 15. April 2015 Überblick Warum ist Softwarequalität wichtig? Was ist Softwarequalität? Wie erreicht man Softwarequalität? Taentzer Softwarequalität 2015 8 Berühmte Software-Fehler

Mehr

SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST

SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST SOFTWARE ENGINEERING 3 TESTVORBEREITUNGEN UND UNIT-TEST Gliederung 2 0. 1. 2. 3. Vorstellung Testvorbereitungen Planungsphase Definitionsphase Implementierungs-, Abnahme-und Einführungsphase Testphasen

Mehr

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Objekt Objekt kapselt Variablen und Routinen Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten Eigenschaften jedes Objekts: Identität (identisch = mehrere

Mehr

Info: Standard DO-178B. 5. Mocking. Zusammenspiel von Klassen testen. Allgemein: Klassen testbar machen

Info: Standard DO-178B. 5. Mocking. Zusammenspiel von Klassen testen. Allgemein: Klassen testbar machen Info: Standard DO-178B Zertifizierung Federal AviationAdministration (FAA), Software für Luftverkehrssysteme durch Standard DO-178B für requirement-based Tests and Code Coverage Analyse DO-178B-Levels

Mehr

3: Systematisches Testen

3: Systematisches Testen Stefan Lucks 3: Systematisches Testen 70 E für Sichere Vert. Systeme (2007) 3: Systematisches Testen Testen ist ein Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. Man muss destruktiv

Mehr

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart Softwaretests Christoph Betschart 27. Oktober 2014 Inhaltsverzeichnis Einführung Arten von Softwaretests Prinzipien Seven Principles of Software Testing Continuous Integration Tests in FLOSS-Projekten

Mehr

Java Schulung. Objektorientierte Programmierung in Java Teil IV: Testen mit JUnit. Prof. Dr. Nikolaus Wulff

Java Schulung. Objektorientierte Programmierung in Java Teil IV: Testen mit JUnit. Prof. Dr. Nikolaus Wulff Java Schulung Objektorientierte Programmierung in Java Teil IV: Testen mit JUnit Prof. Dr. Nikolaus Wulff JUnit JUnit ist das Opensource Testframework. Es existieren Portierungen für fast alle objektorientierten

Mehr

Software-Test. Tests im Softwareentwicklungsprozess. Motivation. Literatur. schon gesehen: testgetrieben. traditionell

Software-Test. Tests im Softwareentwicklungsprozess. Motivation. Literatur. schon gesehen: testgetrieben. traditionell Tests im Softwareentwicklungsprozess traditionell test-getrieben: Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Testen 1 Tests vor Implementierung und Design

Mehr

Testen mit JUnit. Apcon Workplace Solutions Member of itelligence. Testen von Java-Code mit JUnit. ÿstruktur eines Testfalls

Testen mit JUnit. Apcon Workplace Solutions Member of itelligence. Testen von Java-Code mit JUnit. ÿstruktur eines Testfalls Testen von Java-Code mit JUnit ÿmotivation ÿjunit-testklassen ÿjunit-testfälle ÿstruktur eines Testfalls Henning Wolf APCON Workplace Solutions GmbH wolf@jwam.de Motivation: Werkzeugunterstützung für Tests

Mehr

Inhalt. 1 Einleitung 1. 2 Grundkonzepte 11. 3 Erfahrungen systematisch nutzen 39

Inhalt. 1 Einleitung 1. 2 Grundkonzepte 11. 3 Erfahrungen systematisch nutzen 39 xi 1 Einleitung 1 1.1 Softwarequalität betrifft viele................................ 1 1.2 Für wen dieses Buch gemacht ist.............................. 1 1.3 Was Sie von diesem Buch erwarten können......................

Mehr

Testen im Software- Entwicklungsprozess

Testen im Software- Entwicklungsprozess Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von

Mehr

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung Testen II (Management, Tools) Daniela Rose Fachgebiet Softwaretechnik und Systemgestaltung 12.12.2007 Gliederung 1. Motivation 2. Der grundlegende Testprozess 3. Testen im Softwareentwicklungsprozess 4.

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Inhalt. 1. Sprachspezifische Fehlerrisiken C++ Java. Smalltalk. 2. Coverage - Modelle. Statement Coverage. Branch Coverage

Inhalt. 1. Sprachspezifische Fehlerrisiken C++ Java. Smalltalk. 2. Coverage - Modelle. Statement Coverage. Branch Coverage Inhalt 1. Sprachspezifische Fehlerrisiken C++ Java Smalltalk 2. Coverage - Modelle Statement Coverage Branch Coverage Inkrementelles Testen von Klassen Testen Polymorpher Bindungen Optimistischer Ausblick

Mehr

Peter Liggesmeyer. Software-Qualität. Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum k-/l AKADEMISCHER VERLAG

Peter Liggesmeyer. Software-Qualität. Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum k-/l AKADEMISCHER VERLAG Peter Liggesmeyer Software-Qualität Testen, Analysieren und Verifizieren von Software 2. Auflage Spektrum k-/l AKADEMISCHER VERLAG 1 Inhaltsverzeichnis 1 Einführung 1 1.1 Motivation 2 1.2 Terminologie

Mehr

Ein paar Fragen zum Start

Ein paar Fragen zum Start Qualitätsmanagement Ein paar Fragen zum Start Was bedeutet für Sie Software Qualität oder was ist richtig gute Software? Was ist Ihre Lieblingssoftware und was gefällt Ihnen daran? Definition : Qualität

Mehr

Code verifizieren mittels

Code verifizieren mittels Code verifizieren mittels Unit- und Regressionstests Institut für Numerische Simulation, Universität Bonn Seminarreihe Technische Numerik Wozu sollen gut sein? Was für Testarten gibt es? Wie funktionieren

Mehr

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt Inhalt 1 Einführungsveranstaltung 1.1 Ziel der Veranstaltung Warum Qualität? Inhalt der Veranstaltung 1.2 Formaler Ablauf der Veranstaltung 1.3 Übungs- und Gruppeneinteilung 1.4 Bewertungskriterien mittels

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Software-Test: Funktionstest

Software-Test: Funktionstest Software-Test: Funktionstest Andreas Zeller Lehrstuhl für Softwaretechnik Universität des Saarlandes, Saarbrücken 2006-02-06 Funktionale Testverfahren Funktionale Testverfahren testen gegen die Spezifikation

Mehr

Testen mit JUnit. Motivation

Testen mit JUnit. Motivation Test First Design for Test in Eclipse (eigentlich: ) zu einer Klasse Beispiel zur Demonstration Ergänzungen Test First "Immer dann, wenn Du in Versuchung kommst, etwas wie eine print- Anweisung oder einen

Mehr

Wie spezifiziert man die Qualität eines Softwaresystems? Herausforderungen und erste Lösungsideen aus SIKOSA

Wie spezifiziert man die Qualität eines Softwaresystems? Herausforderungen und erste Lösungsideen aus SIKOSA Wie spezifiziert man die Qualität eines Softwaresystems? Herausforderungen und erste Lösungsideen aus SIKOSA Prof. Dr. St. Kirn (Sprecher) Prof. Dr. B. Paech Prof. Dr. D. Kossmann Prof. Dr. G. Müller Schematische

Mehr

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung Übersicht s s Gregoire Kemgne 1 Motivation Problem: Software wird immer größer und komplexer, dadurch ist diese immer schwerer zu überschauen Ein Projekt benötigt mehr Zeit und/oder Entwickler. Lösung:

Mehr

Systematische Testfallableitung und Tests durchführen

Systematische Testfallableitung und Tests durchführen Systematische Testfallableitung und Tests durchführen Testen Bereich Kontrolle Aktivität Interne Qualitätssicherung durchführen (Verifikation) Ziele Tests werden systematisch und zielgerichtet erstellt

Mehr

NTB Druckdatum: 31.03.13 InI I

NTB Druckdatum: 31.03.13 InI I TESTING Methoden der Software-Prüfung Definition Testen ist ein wesentlicher Teil im Qualitätsmanagement von Projekten der Softwareentwicklung Ziel Messen der Qualität des Softwaresystems Um den wirtschaftlichen

Mehr

Testgetriebene Softwareentwicklung

Testgetriebene Softwareentwicklung Testgetriebene Softwareentwicklung Fachhochschule Heilbronn 13. November 2006 Johannes Link E-Mail: business@johanneslink.net Internet: johanneslink.net Weblog: jlink.blogger.de Qualität Gerald M. Weinberg:

Mehr

Einsatz automatischer Testdatengenerierung im modellbasierten Test

Einsatz automatischer Testdatengenerierung im modellbasierten Test Einsatz automatischer Testdatengenerierung im modellbasierten Test Sadegh Sadeghipour sadegh.sadeghipour@itpower.de Gustav-Meyer-Allee 25 / Gebäude 12 13355 Berlin www.itpower.de Modellbasierte Software-Entwicklung

Mehr

Testen von graphischen Benutzeroberflächen. 24. Juni 2015

Testen von graphischen Benutzeroberflächen. 24. Juni 2015 Testen von graphischen Benutzeroberflächen 24. Juni 2015 Überblick Motivation für das automatische Testen von graphischen Benutzeroberflächen Entwicklungsprinzipien für GUIs Capture / Replay Testmethode

Mehr

Zusammenfassung der Testarten

Zusammenfassung der Testarten oftware-test Zusammenfassung der Testarten Komponententest Integrationstest Systemtest Grenztest Black Box Test zustands basierter Test White Box Test Pfadtest Strategie: Urknall Top Down Bottom Up Sandwich

Mehr

Testen. Robert Binder: Software Testing is the execution of code using combinations of input and state selected to reveal bugs.

Testen. Robert Binder: Software Testing is the execution of code using combinations of input and state selected to reveal bugs. Einführung in das systematische Testen ÿmotivation ÿkorrektheit von Software ÿtesten ist Handwerkszeug ÿpositives und Negatives Testen ÿäquivalenzklassen und Grenzwerte ÿblack-box-, White-Box- und Schreibtischtests

Mehr

Man schaut in den Kasten hinein Die innere Struktur (das "Wie") des Programms wird zur Überprüfung hinzugezogen

Man schaut in den Kasten hinein Die innere Struktur (das Wie) des Programms wird zur Überprüfung hinzugezogen 6. Test und Integration White-Box-Test Alternative Begriffe: Glas-Box-Test, Strukturtest Man schaut in den Kasten hinein Die innere Struktur (das "Wie") des Programms wird zur Überprüfung hinzugezogen

Mehr

Markus Wichmann. Testen von Java Code mit. JUnit

Markus Wichmann. Testen von Java Code mit. JUnit Markus Wichmann Testen von Java Code mit JUnit Demotivation... Am Anfang war der Zeitdruck... Hilfe, ich habe doch keine Zeit zum Testen! Ich schreibe einfach keine Tests, dadurch werde ich schneller fertig

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Software- Qualitätsmanagement

Software- Qualitätsmanagement Software- Qualitätsmanagement Thomas Kugel Brandenburg, den 10.12.2002 Agenda Einleitung Was heißt Softwarequalitätssicherung und Test Die Rolle von Test und QS in Softwareprojekten Wie wird getestet Statische

Mehr