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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Testen von Softwaresystemen. 13. Januar 2015

Testen von Softwaresystemen. 13. Januar 2015 Testen von Softwaresystemen 13. Januar 2015 Überblick Was umfasst das Testen von Software? Warum sollte man Software testen? Motivation für Software-Tests Wie sollte man Software testen? Grundlegende Teststrategien

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

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

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

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

FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java

FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java FWP Komponentenorientierte Softwareentwicklung Test-Driven-Development mit Java Hochschule München FK 07 SS 2009 Theis Michael - Senior Developer HVB Information Services GmbH März 2009 Grundlagen des

Mehr

Requirements Engineering & Software Test - Synergien effektvoll nutzen

Requirements Engineering & Software Test - Synergien effektvoll nutzen Requirements Engineering & Software Test - Synergien effektvoll nutzen Software & Systems Quality Conference, 27.-29. Mai 2009 Düsseldorf, Deutschland Bernhard Rauter, BSc (Hons) Software-Test Berater

Mehr

T4 - Testen im Software- Lebenszyklus

T4 - Testen im Software- Lebenszyklus AK 2 am Armin Beer, Siemens PSE und Wirtschaftlichkeitsaspekte Armin Beer, Siemens PSE 2 1 Aufgabe: Test einer Applikation aus dem Sozialversicherungsbereich Client-side Web Browser Network Internet Web

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

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

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

Testkonzept. Tipp-Star

Testkonzept. Tipp-Star Tipp-Star Version: V1.0-27.09.2015 Ablageort: Tipp-Star/01_Projektmanagement/03_Test Status: Fertig gestellt (In Bearbeitung / fertig gestellt / geprüft / freigegeben) Anzahl Seiten: 9 Autoren: tse Sergeyeva

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

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

Softwaretest. Algorithmen und Programmieren II SS 2008 Objektorientierte Programmierung. Algorithmen und Programmierung II SS 2008

Softwaretest. Algorithmen und Programmieren II SS 2008 Objektorientierte Programmierung. Algorithmen und Programmierung II SS 2008 Algorithmen und Programmieren II SS 2008 Objektorientierte Programmierung Softwaretest 03.07.2008 Softwaretest Ingo Dageförde 1 Agenda VL Softwaretest am 03.07.2008 Qualitätssicherung in der Softwareentwicklung

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

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

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

SQS TEST (THEORIE) SS14. Testfragenausarbeitung bis SS14

SQS TEST (THEORIE) SS14. Testfragenausarbeitung bis SS14 SQS TEST (THEORIE) SS14 Testfragenausarbeitung bis SS14 Anmerkungen Diese Ausarbeitung beruht auf der Sammlung der bisherigen Testfragen vom VoWi stand Mai. 2014. Herzlichen Dank an meine Vorarbeiter.

Mehr

Software Testen 2.0 VL

Software Testen 2.0 VL Software Testen 2.0 VL Software Testen VO2 2009W http://www.inso.tuwien.ac.at/lectures/software_testen INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische

Mehr

Software Engineering Testen von Software (1)

Software Engineering Testen von Software (1) Software Engineering Testen von Software (1) Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Hochschule Kaiserslautern, Standort Zweibrücken 1 Qualitätssicherung (engl.:

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

Das automatisierte Testen mit JUnit

Das automatisierte Testen mit JUnit Das automatisierte Testen mit JUnit SWT Seminar (SS03) Ausgearbeitet von Sundui Baatarjav Am Fachbereich Informatik der TU-Berlin EINLEITUNG 3 JUNIT - FRAMEWORK 4 Aufbau und Struktur 4 TestCase 4 Assert

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

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

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

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

Programmierung 2 Studiengang MI / WI

Programmierung 2 Studiengang MI / WI Programmierung 2 Studiengang MI / WI Dipl.-Inf., Dipl.-Ing. (FH) Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik mwilhelm@hs-harz.de Raum 2.202 Tel. 03943 / 659 338 FB Automatisierung

Mehr

Testen in KMU Projekten Bern, November 2013

Testen in KMU Projekten Bern, November 2013 Testen in KMU Projekten Bern, November 2013 Beraterprofil Stephan Wiesner Beratungsschwerpunkte Beratungsschwerpunkte Testmanagement Testautomation Entwicklung und Testen im Mobile-Umfeld Applikationsschwerpunkte

Mehr

Funktionale Testverfahren. Black Box-Tests. Unsystematisches Testen. Unsystematisches Testen (2) Überblick:

Funktionale Testverfahren. Black Box-Tests. Unsystematisches Testen. Unsystematisches Testen (2) Überblick: Funktionale Testverfahren Überblick: Programmstruktur hat keinen Einfluss auf Testfälle Funktionale Testverfahren Black Box-Tests 155 Testfälle werden aus der Spezifikation abgeleitet hat das Programm

Mehr

Qualitätssicherung von Software am Beispiel von Unit Testing. Klaus Kusche, Mai 2012

Qualitätssicherung von Software am Beispiel von Unit Testing. Klaus Kusche, Mai 2012 Qualitätssicherung von Software am Beispiel von Unit Testing Klaus Kusche, Mai 2012 Inhalt Motivation Definition von Unit Tests, Einordnung in der QA, Nutzen Einordnung im V-Modell (==> Tafel) Inhalt,

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 25. Juni 2007 75

Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 25. Juni 2007 75 Software Engineering, SoSe 07, WSI, D. Huson, (Original Author: A. Zeller), 25. Juni 2007 75 10 Qualitätssicherung Nach einer Vorlesung von Prof. Andreas Zeller Lehrstuhl Softwaretechnik, Universität des

Mehr

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

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

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

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

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 von Data-Warehouse- und Business-Intelligence-Systemen

Testen von Data-Warehouse- und Business-Intelligence-Systemen Edition TDWI Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte von Herbert Stauffer, Beat Honegger, Hanspeter Gisin 1. Auflage Testen von Data-Warehouse- und

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Übersicht. Informatik 2 Teil 3 Anwendungsbeispiel für objektorientierte Programmierung

Übersicht. Informatik 2 Teil 3 Anwendungsbeispiel für objektorientierte Programmierung Übersicht 3.1 Modell Konto 3.2 Modell Konto - Erläuterungen 3.3 Benutzer Ein- und Ausgabe mit Dialogfenster I 3.4 Benutzer Ein- und Ausgabe mit Dialogfenster II 3.5 Klassen- und Objekteigenschaften des

Mehr

Testmanagement. Dirk Tesche

Testmanagement. Dirk Tesche Testmanagement Dirk Tesche Agenda Einführung in die Thematik Testarten Testprozess Agile Methoden und Techniken Testautomatisierung Eingrenzung und Motivation Abbildung entnommen aus: www.campero.de Ziele

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

Zusammenfassung V7 - Verifikation und Validierung

Zusammenfassung V7 - Verifikation und Validierung Zusammenfassung V7 - Verifikation und Validierung Zusätzlich aus SCR (=> Verständnis) Verifikation: Sicherstellung, dass Ergebnisse einer Phase des Projektes mit der vorangegangenen Phase konsistent sind

Mehr

Zusammenfassung. Software Engineering 1 WS 2011/12. Dr.-Ing. Ina Schaefer. Software Systems Engineering TU Braunschweig

Zusammenfassung. Software Engineering 1 WS 2011/12. Dr.-Ing. Ina Schaefer. Software Systems Engineering TU Braunschweig Zusammenfassung Software Engineering 1 WS 2011/12 Dr.-Ing. Ina Schaefer Software Systems Engineering TU Braunschweig Ina Schaefer SE 1 - WS 2011/12 1 Inhalte Vorgehensmodelle Anforderungsanalyse Objektorientierte

Mehr

Qualitätssicherung in der Praxis der Softwareerstellung

Qualitätssicherung in der Praxis der Softwareerstellung Thomas Kugel Qualitätssicherung in der Praxis der Softwareerstellung Dresden 18.10.2001 Quality Quality for for Success Success Inhalt Die SQS AG Einführung / Motivation Aufwandsschätzung Testorganisation

Mehr

1. Zweckdes Dokuments

1. Zweckdes Dokuments Testplanung Testplanung 1.Zweck des Dokuments 2.Testziele 3.Teststrategie 4. Inkrementeller Test 5. Dokumentation der Tests 6. Performance Test 7. Literaturreferenzen 1. Zweckdes Dokuments Dokumentation

Mehr

Zwischenbericht - Großer Beleg

Zwischenbericht - Großer Beleg 6WXGLH]XPV\VWHPDWLVFKHQ 7HVWHQYRQZHEEDVLHUWHQ &OLHQW6HUYHU$QZHQGXQJHQ Zwischenbericht - Großer Beleg Thomas Förster Betreuerin: Dipl.-Softwaretechnol. Anne Thomas Hochschullehrer: Prof. Dr. rer. nat. habil.

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Phase 3: Komponenten (Testen)

Phase 3: Komponenten (Testen) Phase 3: Komponenten (Testen) Echtzeitsysteme 2 - Vorlesung/Übung Peter Ulbrich Fabian Scheler Wolfgang Schröder-Preikschat Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander

Mehr

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

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Fundamentaler Testprozess 11 xiii 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Fundamentaler Testprozess 11 2.1 Testplanung und -steuerung........................

Mehr

ISO 9001 und CMM im Vergleich

ISO 9001 und CMM im Vergleich ISO 9001 und CMM im Vergleich internationale Norm ISO 9001 umfasst 20 Forderungen/ Klauseln 1 Vorbereitung Audit Wie wird zertifiziert Wie erfolgt Dokumentation? Handbuch (QMH) Verfahrensanweisungen (QMV)

Mehr

In der Entwicklung werden die Phasen Systementwurf, Projekten mit Funktionaler Sicherheit. Testen in TESTMETHODEN

In der Entwicklung werden die Phasen Systementwurf, Projekten mit Funktionaler Sicherheit. Testen in TESTMETHODEN MESSEN UND TESTENl AUTOMOTIVE 11.2011l43 TESTMETHODEN Testen in Projekten mit Funktionaler Sicherheit Die ISO 26262 beschreibt die Aktivitäten, Methoden und Maßnahmen zur Funktionalen Sicherheit für elektrische

Mehr

Softwaretest. Methoden, Werkzeuge, Vorgehensweisen. Prof. Dr. Holger Schlingloff. Humboldt-Universität zu Berlin und.

Softwaretest. Methoden, Werkzeuge, Vorgehensweisen. Prof. Dr. Holger Schlingloff. Humboldt-Universität zu Berlin und. Softwaretest Methoden, Werkzeuge, Vorgehensweisen Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST Folie 2 Warum Testen? Teststufen Komponententests mit JUnit Oberflächentests

Mehr

Übung zur Vorlesung Einführung in Software Engineering

Übung zur Vorlesung Einführung in Software Engineering Übung zur Vorlesung Einführung in Software Engineering Wintersemester 2012/13, Richard Bubel und Martin Hentschel Übungsblatt 5: Testen Abgabeformat: Reichen Sie Ihre Lösung per SVN als eine PDF-Datei

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

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

Entwicklungs-Prozess

Entwicklungs-Prozess B e r e i c h e Software-Entwicklungs Entwicklungs-Prozess von Helmut Wolfseher (BWCE) als Partner der IndustrieHansa Kontakt Entwicklung der Kostenverhältnisse für Fehlerbeseitigung Kosten Kosten für

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 11. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr

Softwarequalität - Qualitätsmodelle

Softwarequalität - Qualitätsmodelle Softwarequalität - Qualitätsmodelle Proseminar IT-Kennzahlen und Codemetriken Clara Lange 17.05.2010 TU München Inhalt 1. Was ist Softwarequalität? 2. Sichten auf Softwarequalität 3. Messen von Qualität

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

T-Systems Enterprise Services GmbH. Test Factory. Testen nach ISTQB-Standard, Gastvortrag Fontys Hogescholen Venlo, April 2008

T-Systems Enterprise Services GmbH. Test Factory. Testen nach ISTQB-Standard, Gastvortrag Fontys Hogescholen Venlo, April 2008 T-Systems Enterprise Services GmbH. Test Factory. Testen nach ISTQB-Standard, Gastvortrag Fontys Hogescholen Venlo, April 2008 Kennzahlen unserer Leistung. zur Zeit 50 Projekte mit 1 bis zu 300 Mitarbeitern

Mehr

Software-Projekt. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen

Software-Projekt. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Software-Projekt Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Wintersemester 2008/09 Überblick I 1 Software-Test Software-Test 1 Software-Test

Mehr

Software Tests. Florian Ehmke. 21. Januar 2011 1 / 40

Software Tests. Florian Ehmke. 21. Januar 2011 1 / 40 Software Tests Florian Ehmke 21. Januar 2011 1 / 40 Gliederung Einleitung Umfang der Tests Testebenen Wer testet / Wie testen Testen wissenschaftlicher Software Zusammenfassung Literatur 2 / 40 Einleitung

Mehr

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1.

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1. Agile Testing Der agile Weg zur Qualität von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner 1. Auflage Hanser München 2013 Verlag C.H. Beck im Internet: www.beck.de

Mehr