Software Engineering
|
|
|
- Kristina Fuhrmann
- vor 9 Jahren
- Abrufe
Transkript
1 Software Engineering Prof. Adrian A. Müller, PMP Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering '12/'13 1
2 Inhalte: Testen von Software Definitionen Fehler Fehlermaskierung Fehlerzustand Fehlerwirkung Mangel Teststufen und Formen Komponententest Integrationstest Regressionstest Statischer Test Systemtest Abnahmetest Sieben allgemeine Grundsätze des Software Testens Testplanung und Testziele Dynamische Testverfahren white-box vs. black-box Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung Bedingungsüberdeckung Management von Fehlern Test Driven Development Prof. A. Müller, FH KL Software Engineering '12/'13 2
3 Prof. A. Müller, FH KL Software Engineering '12/'13 3 3
4 Prof. A. Müller, FH KL Software Engineering '12/'13 4 4
5 Prof. A. Müller, FH KL Software Engineering '12/'13 5 5
6 Prof. A. Müller, FH KL Software Engineering '12/'13 6 6
7 Prof. A. Müller, FH KL Software Engineering '12/'13 7 7
8 Prof. A. Müller, FH KL Software Engineering '12/'13 8 8
9 Prof. A. Müller, FH KL Software Engineering '12/'13 9 9
10 Prof. A. Müller, FH KL Software Engineering '12/'
11 Grundsatz 1 Grundsatz 2 Grundsatz 3 Grundsatz 4 Grundsatz 5 Grundsatz 6 Grundsatz 7 Testen zeigt die Anwesenheit von Fehlern Vollständiges Testen ist nicht möglich Mit dem Testen frühzeitig beginnen Häufung von Fehlern Tests lassen in ihrer Wirksamkeit nach Testen ist abhängig vom Umfeld Trugschluss: Kein Fehler bedeutet ein brauchbares System 16/ Prof. A. Müller, FH KL Software Engineering '12/'13 11
12 (1) Testen zeigt die Anwesenheit von Fehlern Nachweis der Existenz von Fehlerwirkungen Ausreichendes Testen verringert die Wahrscheinlichkeit, dass noch unentdeckte Fehlerzustände vorhanden sind Kein Beweis, dass keine Fehlerzustände im Testobjekt vorhanden sind 16/ Vorlesung PM 2010 / Testen 12 Prof. A. Müller, FH KL Software Engineering '12/'13 12
13 (2) Vollständiges Testen ist nicht möglich Vollständiger Test mit Prüfung aller möglichen Eingabewerte und deren Kombinationen unter Berücksichtigung aller Rand- und Vorbedingungen ist nicht möglich. Tests sind immer nur Stichproben. Testaufwand nach Risiko und Priorität steuern. Prof. A. Müller, FH KL Software Engineering '12/'
14 (3) Mit dem Testen frühzeitig beginnen Durch frühzeitiges Testen werden Fehler früher erkannt. Prof. A. Müller, FH KL Software Engineering '12/'
15 (4) Häufung von Fehlern In der Regel findet sich an bestimmten Stellen des Testobjekts eine signifikante Häufung von Fehlerzuständen (keine Gleichverteilung) Dort, wo Fehlerauswirkungen nachgewiesen wurden, sind auch noch mehr. Der Test muss auf eine solche Situation flexibel reagieren. Prof. A. Müller, FH KL Software Engineering '12/'
16 (5) Tests lassen in ihrer Wirksamkeit nach Wiederholungen von Tests haben keine Wirksamkeit, da sie keine neuen Fehlerwirkungen aufdecken. Neue oder noch verbliebene Fehlerzustände werden durch die Testfälle nicht berührt. Testfälle sind daher regelmäßig zu prüfen und ggf. zu ändern bzw. zu ergänzen. Prof. A. Müller, FH KL Software Engineering '12/'
17 (6) Testen ist abhängig vom Umfeld Testen ist abhängig vom Einsatzgebiet und Umfeld des zu prüfenden Systems, keine zwei Systeme sind auf die exakt gleiche Art und Weise zu testen. Unterschiede bestehen u. a. in der Intensität des Testens, der Definition der Testende - Kriterien, den gesetzlichen Bestimmungen etc. Sicherheitskritische Systeme verlangen andere Prüfungen als z.b. E Commerce Systeme oder Webapplikationen. Prof. A. Müller, FH KL Software Engineering '12/'
18 (7) Trugschluss: Keine Fehler bedeutet ein brauchbares System Fehlerwirkungen zu finden und Fehlerzustände zu beseitigen heißt nicht, dass das System auch den Vorstellungen und Erwartungen der Nutzer entspricht. Vorbeugende Maßnahmen: Frühzeitige Einbeziehung der späteren Nutzer in den Entwicklungsprozess Nutzung von Prototyping. Prof. A. Müller, FH KL Software Engineering '12/'
19 Prof. A Müller, FH KL Software Engineering '12/'13 19
20 ISTQB_Kap_01_Grundlagen_Sw_Test 20 Prof. A. Müller, FH KL Software Engineering '12/'13 20
21 Testformen und Teststufen im Softwareprojekt Übersicht: Komponententest Integrationstest Regressionstest Statische Tests Systemtest Abnahmetest Prof. A. Müller, FH KL Software Engineering '12/'13 21
22 Wiederholung aus 06: Software-Architektur: was sind Komponenten? Umgebung Systemkomponente 1 Systemkomponente 2 Systemkomponente 3 Prof. A. Müller, FH KL Software Engineering '12/'13 22
23 Komponententest Testen der kleinsten Software-Einheiten, z. B. Klassen Direkt im Anschluss an die Erstellung Isoliertes Testen der Komponente Hierdurch wird sichergestellt, dass gefundene Fehler tatsächlich in dieser Komponente liegen Testtreiber Ein Programm, das das Testobjekt aufruft, mit Eingabeparametern versorgt und das Ergebnis entgegennimmt Einsatz von Testwerkzeugen reduziert den Aufwand zur Programmierung der Testtreiber Auch Testen unzulässiger Eingaben (Negativtests) Sinnvolle Reaktionen und Ausnahebehandlungen Prof. A. Müller, FH KL Software Engineering '12/'13 23
24 Integrationstest Integration von Komponenten zu Teilsystemen Komponenten sollten bereits getestet sein Testen des Zusammenspiels aller Komponenten Fehler in Schnittstellen und im Zusammenspiel der Komponenten finden Schrittweises Zusammenfügen der Komponenten, wobei nach jedem Schritt Integrationstests durchgeführt werden. Ggf. Integration mit existierenden Drittsystemen (z. B. Standardsoftware) Ggf. weitere Diagnoseinstrumente, z. B. Monitore zur Überwachung und Protokollierung der ausgetauschten Daten Typen von Fehlern Eine Komponente übermittelt keine oder syntaktisch falsche Daten Übergebene Daten werden durch die Komponenten unterschiedlich interpretiert Zu späte Übergabe oder zu kurze Zeitintervalle (Timing, Lastprobleme) Prof. A. Müller, FH KL Software Engineering '12/'13 24
25 Integrationsstrategien Top-down-Integration Test beginnt mit der "obersten" Komponente, die selbst nicht von anderen Komponenten aufgerufen wird. Untergeordnete Komponenten werden zunächst durch Platzhalter ersetzt und später nach und nach gegen die richtigen Komponenten ausgetauscht Wenige verschiedene Testtreiber, aber Platzhalter programmieren Bottom-up-Integration Beginn mit elementaren Komponenten, nach und nach Zusammensetzen zu größeren Komponenten Keine Platzhalter, aber viele Testtreiber Ad-hoc-Integration Integration in der (zufälligen) Reihenfolge der Fertigstellung Zeitgewinn, aber sowohl Platzhalter als auch Treiber benötigt Big bang-integration Vermeiden, da großer Testaufwand am Ende, Fehler treten geballt auf und sind schwer zu lokalisieren. Prof. A. Müller, FH KL Software Engineering '12/'13 25
26 Regressionstest Nach Fehlerbehebung, Wartung, Weiterentwicklung muss die Software erneut getestet werden Nachweis, dass keine neuen Fehler eingebaut wurden Notwendiger Umfang? Fehlernachtest: Wiederholung aller Tests, die die Fehlerwirkung erzeugt hatten. Test geänderter Funktionalität Test neuer Funktionalität Das komplette System (vollständiger Regressionstest) Eigentlich wäre ein vollständiger Regressionstest erforderlich In der Praxis wägt man ab, welche Tests sinnvoll wiederholt werden können und sollen Automatisierte Tests lassen sich leichter wiederholen Prof. A. Müller, FH KL Software Engineering '12/'13 26
27 Prof. A. Müller, FH KL Software Engineering '12/'
28 Prof. A. Müller, FH KL Software Engineering '12/'
29 Prof. A. Müller, FH KL Software Engineering '12/'
30 Prof. A. Müller, FH KL Software Engineering '12/'
31 Prof. A. Müller, FH KL Software Engineering '12/'
32 Prof. A. Müller, FH KL Software Engineering '12/'
33 Prof. A. Müller, FH KL Software Engineering '12/'
34 Prof. A. Müller, FH KL Software Engineering '12/'
35 Prof. A. Müller, FH KL Software Engineering '12/'
36 Prof. A. Müller, FH KL Software Engineering '12/'
37 Systemtest Abnahmetest Prof. A. Müller, FH KL Software Engineering '12/'
38 Statischer Test Reviews Statische Analyse Compiler, Analysatoren Syntaxverletzungen, Inkonsistenzen, Abweichungen v. Standard, Einhaltung von Konventionen und Standards Datenflussanomalien Untersuchung der Daten auf Pfaden durch Programmcode Z. B. Eine Variable erhält zweimal einen Wert zugewiesen, ohne dass dieser inzwischen gelesen wird. Kontrollflussanomalien Z. B. Nicht erreichbare Anweisungen Metriken Z. B. Zyklomatische v. Zahl zur Bestimmung der Komplexität von Kontrollflussgraphen, sollte kleiner als 10 sein v(g) = e n + 2p wobei e: Zahl der Kanten, n: Zahl der Knoten, p: Zahl der verbundenen Komponenten (einzelne Kontrollflussgraphen) Prof. A. Müller, FH KL Software Engineering '12/'13 38
39 Dynamischer Test Quelle: Spillner/Linz: Basiswissen Softwaretest Prof. A. Müller, FH KL Software Engineering '12/'13 39
40 Dynamische Testverfahren Black-box Test Design White-box Test Design Programmtext und innerer Aufbau des Testobjekts nicht berücksichtigt Nur äußeres Verhalten des Testobjekts untersucht Insbesondere Systemtests i.d.r. nur als Black-box- Test durchgeführt Verwendung des Programmtexts Analyse des inneren Ablaufs (Point of Observation im Testobjekt) Evtl. Eingriffe in das Testobjekt Erstellung von Testfällen aufgrund innerer Programmstruktur (strukturelle Testverfahren) Eignet sich insbesondere für Komponententests, Kontrollflussorientierte Testverfahren Prof. A. Müller, FH KL Software Engineering '12/'13 40
41 Black-box-Verfahren: Äquivalenzklassenbildung Äquivalenzklasse Die Menge aller möglichen Eingabewerte wird in Äquivalenzklassen unterteilt Für Eingabewerte, die sich in einer Äquivalenzklasse befinden, müsste sich das Testobjekt gleich verhalten Es müssen daher nur einige Repräsentanten aus jeder Äquivalenzklasse getestet werden Auch Äquivalenzklassen für ungültige Eingaben Interessant: Prüfung der Grenzen von Äquivalenzklassen Weitere Black-box-Verfahren Zustandsbezogene Tests Berücksichtigung der Historie Z. B. Erreichen aller möglichen Zustände durch Testfälle Zufallstest Ursache-Wirkungs-Graph-Analyse Smoke-Test Versuch, das System zum Absturz zu bringen Prof. A. Müller, FH KL Software Engineering '12/'13 41
42 Beispiel für Äquivalenzklassenbildung Programm zur Berechnung von Weihnachtsgratifikationen Firmenzugehörigkeit (Jahre) Gratifikation x <= 3 0% 3 < x <= 5 50% 5 < x <= 8 75% x > 8 100% Prof. A. Müller, FH KL Software Engineering '12/'13 42
43 Beispiel für Äquivalenzklassenbildung Programm zur Berechnung von Weihnachtsgratifikationen Firmenzugehörigkeit (Jahre) Gratifikation x <= 3 0% 3 < x <= 5 50% 5 < x <= 8 75% x > 8 100% Testen mit Repräsentanten aus Äquivalenzklassen Äquivalenzklasse Repräsentant 0 <= x <= < x <= < x <= 8 7 x > 8 12 Prof. A. Müller, FH KL Software Engineering '12/'13 43
44 White-box-Verfahren Berücksichtigung des Programmtexts Alle Codeteile sollen mindestens einmal zur Ausführung gebracht werden Kontrollfluss-orientierte Verfahren zum Testfallentwurf: Anweisungsüberdeckung Zweigüberdeckung Test der Bedingungen Einfache Bedingungsüberdeckung Mehrfachbedingungsüberdeckung Minimale Mehrfachbedingungsüberdeckung Pfadüberdeckung Prof. A. Müller, FH KL Software Engineering '12/'13 44
45 Kontrollflussgraph if (Bedingung) then S1; else S2; if (Bedingung) then S1; while (Bedingung) S1; S1; S2; S1 S2 S1 S1 S1 S2 Kanten des Graphen Knoten des Graphen Prof. A. Müller, FH KL Software Engineering '12/'13 45
46 Anweisungsüberdeckung Durch die spezifizierten Testfälle sind x% aller Anweisungen des Programms zur Ausführung zu bringen Am besten 100% Gelegentlich gibt es Anweisungen zur Ausnahmebehandlung, die nur schwer erreichbar sind. Anweisungsüberdeckung = Zahl durchlaufener Anweisungen / Gesamtzahl Anweisungen Bewertung Nicht erreichbarer Code wird gefunden Leere "else"-teile werden nicht erkannt Wenn nur im if-teil Anweisungen vorkommen, im else-teil Anweisungen fehlen, werden diese nicht gefunden, da der else-teil mangels enthaltener Anweisung gar nicht durchlaufen wird Prof. A. Müller, FH KL Software Engineering '12/'13 46
47 Beispiel für Anweisungsüberdeckung Quelle: Spillner/Linz: Basiswissen Softwaretest Prof. A. Müller, FH KL Software Engineering '12/'13 47
48 Zweigüberdeckung Es sollen möglichst alle Zweige im Kontrollflussgraphen erreicht werden Bei Verzweigungen (if, case) soll jeder ausgehende Zweig mindestens einmal durchlaufen werden. Bei einer Schleife soll ein Pfad ohne Rücksprung sowie ein Rücksprung zum Anfang durchlaufen werden Zweigüberdeckung = Anzahl durchlaufener Zweige / Gesamtzahl Zweige Bewertung Es werden Fehler gefunden, die nur mit Anweisungsüberdeckung nicht gefunden werden Bei objektorientierten Systemen sind die Methoden meist wenig komplex, die Überdeckungen lassen sich leicht erreichen. Die Komplexität steckt in den Beziehungen zwischen Klassen, die bei den bisherigen Tests nicht berücksichtigt wird. Prof. A. Müller, FH KL Software Engineering '12/'13 48
49 Zweigüberdeckung Beispiel Es sind insgesamt vier Testfälle erforderlich: a, b, f, g, h, d, e a, b, c, d, e a, b, f, g, i, g, h, d, e a, k, e Prof. A. Müller, FH KL Software Engineering '12/'13 49
50 Test der Bedingungen Einfache Bedingungsüberdeckung Jede atomare Teilbedingung muss im Test sowohl den Wert wahr als auch falsch angenommen haben Bewertung Atomare Teilbedingung: Bedingung, die keine logischen Operatoren wie AND, OR, NOT enthält, höchstens Relationssymbole (>, =) Schwächer als Anweisungs- oder Zweigüberdeckung, da keine unterschiedlichen Wahrheitswerte der Gesamtbedingung verlangt sind Prof. A. Müller, FH KL Software Engineering '12/'13 50
51 Einfache Bedingungsüberdeckung Zusammengesetzte Bedingung x>3 OR y<5 Beispiel für Testfälle: Fall 1: x=6, y=8 (x>3): true, (y<5): false, gesamte Bedingung: true Fall 2: x=2, y=3 (x>3): false, (y<5): true, gesamte Bedingung: true Prof. A. Müller, FH KL Software Engineering '12/'13 51
52 Mehrfachbedingungsüberdeckung Möglichst alle Kombinationen der Wahrheitswerte der atomaren Teilbedingungen Erfüllt auch die Kriterien der Anweisungs- und Zweigüberdeckung Aufwändig 2 n Kombinationen bei n atomaren Bedingungen Es lassen sich nicht alle Kombinationen realisieren Bedingungen sind nicht immer unabhängig Prof. A. Müller, FH KL Software Engineering '12/'13 52
53 Mehrfachbedingungsüberdeckung: Beispiel Zusammengesetzte Bedingung x>3 OR y<5 Es gibt vier mögliche Kombinationen. Beispiele für vier entsprechende Testfälle: Fall 1: x=6, y=8 (x>3): true, (y<5): false, gesamte Bedingung: true Fall 2: x=2, y=3 (x>3): false, (y<5): true, gesamte Bedingung: true Fall 3: x=6, y=3 (x>3): true, (y<5): true, gesamte Bedingung: true Fall 4: x=2, y=8 (x>3): false, (y<5): false, gesamte Bedingung: false Beispiel für Bedingung, bei der manche Kombinationen nicht möglich sind: x<=3 AND x<5 Die Kombination (x<=3): true und (x<5): false ist nicht möglich Prof. A. Müller, FH KL Software Engineering '12/'13 53
54 Minimale Mehrfachbedingungsüberdeckung Unterschied zur Mehrfachbedingungsüberdeckung: Es müssen nur die Kombinationen betrachtet werden, bei denen die Änderung des Wertes einer atomaren Bedingung den Wert der zusammengesetzten Bedingung verändern kann Weniger Aufwändig Nur bis zu 2n Kombinationen bei n atomaren Bedingungen Evtl. schwierig, die Eingabedaten so zu wählen, dass eine bestimmte Teilbedingung den gewünschten Wert annimmt Prof. A. Müller, FH KL Software Engineering '12/'13 54
55 Minimale Mehrfachbedingungsüberd.: Beispiel Zusammengesetzte Bedingung x>3 OR y<5 Fall 1: x=6, y=8 (x>3): true, (y<5): false, gesamte Bedingung: true Fall 2: x=2, y=3 (x>3): false, (y<5): true, gesamte Bedingung: true Fall 3: x=6, y=3 (x>3): true, (y<5): true, gesamte Bedingung: true Fall 4: x=2, y=8 (x>3): false, (y<5): false, gesamte Bedingung: false Fall 3 muss nicht getestet werden Ändert sich der Wert einer atomaren Bedingung, so bleibt der Wert der gesamten Bedingung true In Fall 1 und 2 würde die Änderung der wahren Teilbedingung zu false dazu führen, dass die Gesamtbedingung ebenfalls den Wert false annimmt In Fall 4 würde die Änderung einer Teilbedingung dazu führen, dass die Gesamtbedingung wahr wird. Prof. A. Müller, FH KL Software Engineering '12/'13 55
56 Pfadüberdeckung Jeder mögliche Pfad muss durchlaufen werden D. h. nicht nur jeder mögliche Zweig, sondern auch jede Kombination von Zweigen Jeder Schleifendurchlauf ergibt mindestens einen neuen Pfad In der Praxis lässt sich keine 100%-Pfadüberdeckung erreichen. Meist legt man eine bestimmte Schleifendurchlaufzahl fest (z. B. 2), die getestet werden soll. Prof. A. Müller, FH KL Software Engineering '12/'13 56
57 Beispiel für Pfadüberdeckung Komplette Zweigüberdeckung: a, b, c, j, k, l, n a, d, e, f, i, j, m, n a, d, g, h, i, j, m, n Nicht durchlaufene Pfade: a, b, c, j, m, n a, d, e, f, i, j, k, l, n a, d, g, h, i, j, k, l, n Quelle: Spillner/Linz: Basiswissen Softwaretest Prof. A. Müller, FH KL Software Engineering '12/'13 57
58 Management von Fehlern Fehlerklassifikation Prioritäten für Fehlerbehebungen Fehlerstatusmodell Protokollierung / Nachvollziehbarkeit Prof. A. Müller, FH KL Software Engineering '12/'13 58
59 Test Driven Development Quelle: Schreibe Tests für das erwünschte fehlerfreie Verhalten, für schon bekannte Fehlschläge oder für das nächste Teilstück an Funktionalität, das neu implementiert werden soll. Diese Tests werden vom bestehenden Programmcode erst einmal nicht erfüllt bzw. es gibt diesen noch gar nicht. Ändere/schreibe den Programmcode mit möglichst wenig Aufwand, bis nach dem anschließend angestoßenen Testdurchlauf alle Tests bestanden werden. Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Code-Duplizierung), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen aus etc. Natürlich wieder mit abschließendem Testen. Ziel des Aufräumens ist es, den Code schlicht und verständlich zu machen. Prof. A. Müller, FH KL Software Engineering '12/'13 59
60 Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 Prof. A. Müller, FH KL Software Engineering '12/'13 60
61 Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 Prof. A. Müller, FH KL Software Engineering '12/'13 61
62 Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 Prof. A. Müller, FH KL Software Engineering '12/'13 62
63 Test Driven Development Quelle: Objektorientiertes Testen und Testautomatisierung in der Praxis, Vigenschow, 2004 Prof. A. Müller, FH KL Software Engineering '12/'13 63
64 Test Status Quelle: Prof. A. Müller, FH KL Software Engineering '12/'13 64
65 Wichtige Aussagen Vorteile Analyse des Codes Findet Fehler in verstecktem Code Hilft Programmierkenntnisse zu verbreiten Nachteile Sehr aufwendig Tester vergisst evtl. Fälle, die im Code nicht vorkommen, wiederholt somit Denkfehler des Entwicklers Wird geprüft, ob die Funktion/Klasse das Richtige tut? Prof. A. Müller, FH KL Software Engineering '12/'13 65
66 Klassifikation von kontrollfluss-orientierten 8 Testfallentwürfen Klassifikation C0 C1 Umfang des Tests Anweisungsüberdeckung Kantenüberdeckung C1+ Kantenüberdeckung und Ausführung von Schleifen mit Extremwerten C1p C2 Cik Ct Kantenüberdeckung und jede Bedingung wird einmal wahr und einmal falsch ausgeführt Kantenüberdeckung und jede Schleife wird 1. nicht ausgeführt 2. mit einem niederen Zählwert ausgeführt 3. mit einem hohen Zählwert ausgeführt Kantenüberdeckung und alle Schleifen werden für alle Zählwerte i bis k ausgeführt (i < k) Pfadüberdeckung Prof. A. Müller, FH KL Software Engineering '12/'13 66
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
Basiswissen Softwaretest
Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard Bearbeitet von Andreas Spillner, Tilo Linz überarbeitet 2005. Buch. XX, 284 S. Hardcover ISBN
Basiswissen Softwaretest
isqi-reihe Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard von Andreas Spillner, Tilo Linz 5., überarbeitete und aktualisierte Auflage Basiswissen
Wiederholung. Testen. Tests nach Methode zum Ableiten der Testfälle White Box Test Black Box Test
Testen Tests nach Lebenzykusphase Unit, Komponententests Integrationstets Systemtests Abnahmetests, Validierung Tests nach Testziel Lasttest Penetrationstests Funktionale Tests... Wiederholung Tests nach
1. Einführung 1.1. Definitionen
1 1. Einführung 1.1. Definitionen Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und Unterschiede zwischen
Qualitätssicherung von Software
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST 2.2 Integrations- und Systemtest 17.11.2004 Folie 2 Hinweise Übungen: Teilnahme wird dringend
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
Programmieren I. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011
Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/2011 1 Testen von Programmen 2 Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte
PHP 5.6. Grundlagen zur Erstellung dynamischer Webseiten. Stephan Heller. 1. Ausgabe, März 2015 ISBN: 978-3-86249-415-6 GPHP56
PHP 5.6 Stephan Heller 1. Ausgabe, März 2015 ISBN: 978-3-86249-415-6 Grundlagen zur Erstellung dynamischer Webseiten GPHP56 Kontrollstrukturen 5 5.7 Schleifen Schleifen verwenden Um einen bestimmten Teil
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,
Ü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 14 28. Januar 2003 www4.in.tum.de/~rumpe/se
Legt durch das Argument Dann bzw Sonst fest, wie nach einer Prüfung (Bedingung) verfahren werden soll.
Die Funktion WENN() Syntax WENN(Bedingung;Dann;Sonst) Definition Legt durch das Argument Dann bzw Sonst fest, wie nach einer Prüfung (Bedingung) verfahren werden soll. Argumente Prüfung: Prüft, ob eine
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
Handbuch zum Testen von Web-Applikationen
Klaus Franz Handbuch zum Testen von Web-Applikationen Testverfahren, Werkzeuge, Praxistipps Mit 28 Abbildungen und 26 Tabellen Springer Inhaltverzeichnis 1 Einleitung 1 1.1 Wieso dieses Buch? 1 1.2 Wem
zu große Programme (Bildschirmseite!) zerlegen in (weitgehend) unabhängige Einheiten: Unterprogramme
Bisher Datentypen: einfach Zahlen, Wahrheitswerte, Zeichenketten zusammengesetzt Arrays (Felder) zur Verwaltung mehrerer zusammengehörender Daten desselben Datentypes eindimensional, mehrdimensional, Array-Grenzen
Javaprogrammierung mit NetBeans. Variablen, Datentypen, Methoden
Javaprogrammierung mit NetBeans Variablen, Datentypen, Methoden Programmieren 2 Java Bezeichner Bezeichner: Buchstabe _ $ Buchstabe _ $ Ziffer Groß- und Kleinbuchstaben werden strikt unterschieden. Schlüsselwörter
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
zu große Programme (Bildschirmseite!) zerlegen in (weitgehend) unabhängige Einheiten: Unterprogramme
Bisher Datentypen: einfach Zahlen, Wahrheitswerte, Zeichenketten zusammengesetzt Arrays (Felder) zur Verwaltung mehrerer zusammengehörender Daten desselben Datentypes eindimensional, mehrdimensional, Array-Grenzen
Softwaretests Testgetriebene Entwicklung (TDD) vs wissenschaftliche Methode TDD Case Study Zusammenfassung
Antonia Bücklers Softwaretests Testgetriebene Entwicklung (TDD) vs wissenschaftliche Methode TDD Case Study Zusammenfassung - Antonia Bücklers 2 prüft und bewertet Software auf Erfüllung der spezifischen
Verifizierende Testverfahren
Spezifikation Um einen Algorithmus zu schreiben, muss das zu lösende Problem genau beschrieben sein. Eine Spezifikation ist Verifizierende Testverfahren vollständig, wenn alle Anforderungen/alle relevanten
Grundlagen der Wahrscheinlichkeitstheorie und Statistik für Studierende der Informatik
INSTITUT FÜR STOCHASTIK WS 07/08 UNIVERSITÄT KARLSRUHE Blatt 4 Dr. B. Klar Übungen zur Vorlesung Grundlagen der Wahrscheinlichkeitstheorie und Statistik für Studierende der Informatik Musterlösungen Aufgabe
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
bestehenden sind, weiterhin benutzt werden. Oft beleuchten unterschiedliche Formalismen Dinge nämlich von unterschiedlichen Blickwinkeln.
2 Endliche Automaten bestehenden sind, weiterhin benutzt werden. Oft beleuchten unterschiedliche Formalismen Dinge nämlich von unterschiedlichen Blickwinkeln. Fragen 1. Sei R = 0 1 + (0 + 1). In welchen
1. Erläutern Sie die Aufgaben von Datentypen in der imperativen Programmierung.
1. Erläutern Sie die Aufgaben von Datentypen in der imperativen Programmierung. Beschreiben Sie ferner je einen frei gewählten Datentyp aus der Gruppe der skalaren und einen aus der Gruppe der strukturierten
Verbundtests von Mobilgeräten und Backend-Systemen. Andreas Bartsch, exept Software AG
Verbundtests von Mobilgeräten und Backend-Systemen Andreas Bartsch, exept Software AG Andreas Bartsch COO exept Software AG Vor 30 Jahren als Consultant im Software Entwicklungsbereich gestartet Große
6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]
![6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]](/thumbs/27/12066220.jpg "6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]")
1 Software-Qualitätssicherung 2 Integrationsstrategien big bang 6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] nicht-inkrementell geschäftsprozeßorientiert Prof. Dr. Helmut Balzert Lehrstuhl
Softwaretechnik II. Sommersemester Grundlagen des Softwaretestens II. Stefan Berlik
1 / 65 Softwaretechnik II Sommersemester 2014 Grundlagen des Softwaretestens II Stefan Berlik Fachgruppe Praktische Informatik Fakultät IV, Department Elektrotechnik und Informatik Universität Siegen 24.
C++ Teil 2. Sven Groß. 16. Apr IGPM, RWTH Aachen. Sven Groß (IGPM, RWTH Aachen) C++ Teil Apr / 22
C++ Teil 2 Sven Groß IGPM, RWTH Aachen 16. Apr 2015 Sven Groß (IGPM, RWTH Aachen) C++ Teil 2 16. Apr 2015 1 / 22 Themen der letzten Vorlesung Hallo Welt Elementare Datentypen Ein-/Ausgabe Operatoren Sven
Informatik I Übung, Woche 40
Giuseppe Accaputo 1. Oktober, 2015 Plan für heute 1. Nachbesprechung Übung 2 2. Vorbesprechung Übung 3 3. Zusammenfassung der für Übung 3 wichtigen Vorlesungsslides Informatik 1 (D-BAUG) Giuseppe Accaputo
Software Engineering II (IB) Testen von Software / Modultests
Fakultät für Informatik und Mathematik Hochschule München Letzte Änderung: 16.05.2017 21:17 Inhaltsverzeichnis Programm-Tests.................................. 2 Ziele des Testens..................................
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
Testbarkeitsfaktoren und Testaufwand: Auswertung dreier Umfragen
Testbarkeitsfaktoren und Testaufwand: Auswertung dreier Umfragen Stefan Jungmayr Version 1.1 28. April 2006 Abstract Um den Testaufwand unter Kontrolle zu halten und die Testeffektivität zu erhöhen ist
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
Qualitätssicherung im Data Warehouse Bereich. Michael Cordes Holger Oehring Matthias Rein
Qualitätssicherung im Data Warehouse Bereich Michael Cordes Holger Oehring Matthias Rein Ziele Motivation / Notwendigkeit von QS-Maßnahmen Methoden der Qualitätssicherung Durchführung von Tests Etablierung
Erstellen einer Excel-Tabelle für die Bundesjugendspiele
Erstellen einer Excel-Tabelle für die Bundesjugendspiele Für die Nutzung des BJS-Programmes wird eine Excel-Datei in festgelegtem Format benötigt. Die Erstellung erfolgt in 3 Abschnitten: 1. Erzeugen der
Lösungen zum Aufgabenblatt Nr. 1: Konstruktion der reellen Zahlen
Lösungen zum Aufgabenblatt Nr. 1: Konstruktion der reellen Zahlen Aufgabe 1: Es sei D die Menge aller rationalen Dedekind-Mengen, also D := { M 2 Q M is Dedekind-Menge }. Auf der Menge D definieren wir
Im gesamten Kapitel sei Ω eine nichtleere Menge. Wir bezeichnen die Potenzmenge
1 Mengensysteme Ein Mengensystem ist eine Familie von Teilmengen einer Grundmenge und damit eine Teilmenge der Potenzmenge der Grundmenge. In diesem Kapitel untersuchen wir Mengensysteme, die unter bestimmten
5.3 Korrektheit und Verifikation
5.3 Korrektheit und Verifikation Korrektheit bedeutet, dass ein Algorithmus oder ein Programm das in der Spezifikation beschriebene Problem für beliebige Eingabedaten korrekt löst. Die Korrektheit kann
Datenstrukturen & Algorithmen
Datenstrukturen & Algorithmen Matthias Zwicker Universität Bern Frühling 2010 Übersicht Rot-schwarz Bäume Eigenschaften Rotationen Einfügen (Löschen) 2 Einführung Binäre Suchbäume Höhe h O(h) für Operationen
236 6 Fortgeschrittene Java-Konzepte für Nebenläufigkeit ***
236 6 Fortgeschrittene Java-Konzepte für Nebenläufigkeit *** Der Aufzählungstyp ThreadState Ab der Java-Version 5 sind die möglichen Zustände eines thread in dem Aufzählungstyp ThreadState definiert (siehe
Qualitätssicherung von Software
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST 2.3 strukturelle Tests 24.11.2004 Folie 2 Hinweis auf Umfrage wir, das Institut für Informatik
Software Engineering in der Praxis
Inhalt Nachlese Werkzeuge Software Engineering in der Praxis Praktische Übungen Inhalt Nachlese Werkzeuge Josef Adersberger Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität
Methodik der multiplen linearen Regression
Methodik der multiplen linearen Regression Sibel Aydemir Statistisches Amt, Direktorium Landeshauptstadt München Name, Stadt Regressionsanalyse: Schritt für Schritt Schritt 1 Schritt 2 Schritt 3 Schritt
TEIL 13: DIE EINFACHE LINEARE REGRESSION
TEIL 13: DIE EINFACHE LINEARE REGRESSION Die einfache lineare Regression Grundlagen Die einfache lineare Regression ist ebenfalls den bivariaten Verfahren für metrische Daten zuzuordnen 1 Sie hat einen
Konjunktive und disjunktive Normalformen
Konjunktive und disjunktive Normalformen Nachdem gesprochen wurde, wie man Boolesche Terme unter einer Belegung der Variablen interpretiert und dass somit jeder Boolesche Term eine Boolesche Funktion repräsentiert,
Java 8. Elmar Fuchs Grundlagen Programmierung. 1. Ausgabe, Oktober 2014 JAV8
Java 8 Elmar Fuchs Grundlagen Programmierung 1. Ausgabe, Oktober 2014 JAV8 5 Java 8 - Grundlagen Programmierung 5 Kontrollstrukturen In diesem Kapitel erfahren Sie wie Sie die Ausführung von von Bedingungen
Diskrete Optimierungsverfahren zur Lösung von Sudokus
Diskrete Optimierungsverfahren zur Lösung von Sudokus Seminarvortrag von Daniel Scholz am 6. Dezember 2006 Am Beispiel der Lösung von Sudokurätseln mit Hilfe der linearen Optimierung werden verschiedenen
Learning Object-Oriented Programming. Algorithmen. Algorithmusbegriff. Klärung der Herkunft des Begriffs Formale Definition von Algorithmus
Algorithmen Algorithmusbegriff Klärung der Herkunft des Begriffs Formale Definition von Algorithmus Algorithmusbegriff Algorithmen sind eine der ältesten (abstrakten) Beschreibungstechniken für Abläufe.
5.3 Korrektheit und Verifikation
5.3 Korrektheit und Verifikation Korrektheit bedeutet, dass ein Algorithmus oder ein Programm das in der Spezifikation beschriebene Problem für beliebige Eingabedaten korrekt löst. Die Korrektheit kann
Beispiel 1 zur Verifikation eines bedingten Anweisung. Hoare-Regel für die bedingte Anweisung. else
Hoare-Regel für die bedingte Anweisung I1 : I2 : {B P } S 1 {Q} { nicht B P } {Q} {P } if (B) then S 1 {Q} {B P } S 1 {Q} { nicht B P } S 2 {Q} {P } if (B) then S 1 else S 2 {Q} In der Regel für bedingte
Kapitel 5: Statische Analyse
Kapitel 5: Statische Analyse Inhalt 5.1 Grundlagen 5.2 Analyse von Programmen 5.3 Analyse von Algorithmen 5.4 Analyse von Spezifikationen, Entwürfen und Prüfvorschriften Schlüsselbegriffe Statische Prüfung
Klassen mit Instanzmethoden
Klassen mit Instanzmethoden Gerd Bohlender Institut für Angewandte und Numerische Mathematik Vorlesung: Einstieg in die Informatik mit Java 3.12.07 G. Bohlender (IANM UNI Karlsruhe) OOP und Klassen 3.12.07
Um dies zu vermeiden, werden nun drei so genannte Testbefehle eingeführt:
Folge 4 IF-ELSE-Anweisung - Testbefehle JAVA 4.1 Testbefehle (Boolesche Ausdrücke) Wenn Sie den Hamster in eine unlösbare Situation bringen (z.b. obwohl vor ihm eine Mauer steht), dann ist der Hamster
Methodiken zur Testautomatisierung eines Kanalsimulators
Methodiken zur Testautomatisierung eines Kanalsimulators von Ricardo Grywnow Mat. Nr.: 826980 Betreuer: Prof. Dr. rer. Nat. Bodo Kraft Dipl. Inf. Axel C. Voigt Aachen, 15. Dezember 2010 Inhaltsverzeichnis
Kurs 1613 Einführung in die imperative Programmierung Musterlösung zur Nachklausur am
1 Aufgabe 1 Analysiert man das Verfahren anhand des angegebenen Beispiels, ist schnell zu erkennen, dass das erste Element von infeld2 nach outfeld an Index 2 kopiert wird, das zweite den Index 4 bekommt,
Anti-Patterns. Zuverlässige Software SS2009 Friedrich Gensicke
Anti-Patterns Zuverlässige Software SS2009 Friedrich Gensicke Gliederung 1. Einführung Was sind Anti Patterns? Unterschiede Design Pattern Anti Pattern Grundursachen Klassifizierung 2. Anti Patterns in
Grundlagen der Risikoanalyse p. 64 Risikoanalyse in der Software-Entwicklung p. 64 Werkzeuge für die Risikoanalyse p. 68 Zusammenfassung p.
Einleitung p. 1 Wieso dieses Buch? p. 1 Wem nutzt dieses Buch wie? p. 2 Wie ist dieses Buch zu lesen? p. 3 Welche Testwerkzeuge werden genannt? p. 5 Was liefert dieses Buch nicht? p. 6 Wer sollte das Buch
8 Das Flussproblem für Netzwerke
8 Das Flussproblem für Netzwerke 8.1 Netzwerke mit Kapazitätsbeschränkung Definition 15 Ein Netzwerk N = (V, E, γ, q, s) besteht aus einem gerichteten Graph G = (V, E), einer Quelle q V und einer Senke
12. Rekursion Grundlagen der Programmierung 1 (Java)
12. Rekursion Grundlagen der Programmierung 1 (Java) Fachhochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm FH Darmstadt, 24. Januar 2006 Einordnung im Kontext der Vorlesung
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
3.5 Entscheidungen treffen: die WENN-DANN- Funktion
114 Tabellenkalkulation Aufgabe Arbeiten Sie folgende Adresse zur Diagrammerstellung durch: http://office.microsoft.com/de-at/excel/hp012163481031.aspx 3.5 Entscheidungen treffen: die WENN-DANN- Funktion
Übungsblatt 1. f(n) = f(n) = O(g(n)) g(n) = O(f(n)) Zeigen oder widerlegen Sie: 3 n = Θ(2 n ) Aufgabe 1.2 Gegeben sei die folgende Funktion:
Übungsblatt 1 Aufgabe 1.1 Beweisen oder widerlegen Sie, dass für die im Folgenden definierte Funktion f(n) die Beziehung f(n) = Θ(n 4 ) gilt. Beachten Sie, dass zu einem vollständigen Beweis gegebenenfalls
FACHHOCHSCHULE AUGSBURG Hochschule für Technik, Wirtschaft und Gestaltung
C Sprachelemente für Übung 2 Typumwandlungen (type casts) Bei Ausdrücken, in denen Operanden mit unterschiedlichem Typ vorkommen, werden diese vom Compiler vor der Ausführung automatisch in einen gemeinsamen
Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen
Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 16OH21005 gefördert. Die Verantwortung für den Inhalt dieser
Wahrscheinlichkeitsverteilungen
Wahrscheinlichkeitsverteilungen 1. Binomialverteilung 1.1 Abzählverfahren 1.2 Urnenmodell Ziehen mit Zurücklegen, Formel von Bernoulli 1.3 Berechnung von Werten 1.4 Erwartungswert und Standardabweichung
(Aufgaben zu Wertzuweisungen siehe Vorlesungsbeilage S. 49)
Anweisungen Eine Anweisung ist eine in einer beliebigen Programmiersprache abgefaßte Arbeitsvorschrift für einen Computer. Jedes Programm besteht aus einer bestimmten Anzahl von Anweisungen. Wir unterscheiden
White-Box-Test. Black-Box-Test. Testen. Testen. Vorlesung Methoden des Software Engineering. Martin Wirsing. Einheit D.2,
21.12.04 1 Ziele 21.12.04 2 Vorlesung Methoden des Software Engineering Techniken des Black-Box-Testens und des White-Box-Testens kennen lernen Block D Qualitätssicherung Black-Box-Test und White-Box-Test
Vorlesung Software Engineering
Vorlesung Software Engineering Kapitel 4 Qualitätsmanagement und Software-Metriken Software-Metriken mittels Werkzeug Understand - 1 - Neues Projekt anlegen New Project... - 2 - Neues Projekt anlegen Auswahl
Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 10
Prof. Dr. Wilhelm Schäfer Paderborn, 5. Januar 2015 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 10 Aufgabe 1 Decision-Tables
4.Grundsätzliche Programmentwicklungsmethoden
4.Grundsätzliche Programmentwicklungsmethoden 1.1 Grundlage strukturierter und objektorientierter Programmierung Begriff Software Engineering - umfaßt den gezielten Einsatz von Beschreibungsmitteln, Methoden
Einführung in die Programmierung Wintersemester 2011/12
Einführung in die Programmierung Wintersemester 2011/12 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund : Kontrollstrukturen Inhalt Wiederholungen - while
Webbasierte Programmierung
Webbasierte Programmierung Eine Einführung mit anschaulichen Beispielen aus der HTML5-Welt apl. Prof. Dr. Achim Ebert Inhalt Kapitel 6: JavaScript Kontrollstrukturen Verzweigungen Einseitig, zweiseitig,
Die qualitative Fehlerbaumanalyse am Beispiel einer Präsentation. -Sandra Mierz-
Die qualitative Fehlerbaumanalyse am Beispiel einer Präsentation -Sandra Mierz- Gliederung Definition Anwendungsgebiete der Fehlerbaumanalyse Vorgehen Fehlerbaum erstellen Fehlerbaum auswerten Vorteile
Excel VBA. Teil 11.8. Zusammenfassung! Was wir können sollten! V0.5 5.4.2013
Excel VBA Teil 11.8 Zusammenfassung! Was wir können sollten! V0.5 5.4.2013 1 von 17 Inhaltsverzeichnis Seite 3... Modul einfügen Seite 4... Prozeduren oder Funktionen Seite 5... Ein/Ausgaben Seite 6...
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.:
Grundlagen des Software Engineering
Gustav Pomberger und Günther Blaschek Grundlagen des Software Engineering Prototyping und objektorientierte Software-Entwicklung Mit 101 Abbildungen Technische Universität Darmstadt FACHBEREICH INFORMATIK
Objektorientierte Programmierung OOP Programmieren mit Java
Objektorientierte Programmierung OOP Programmieren mit Java 5.1 Elementare Anweisungen 5.1.1 Ausdrucksanweisung 5.1.2 Leere Anweisung 5.1.3 Blockanweisung 5.1.4 Variablendeklaration 5.2 Bedingungen 5.2.1
Beispiel 1 zur Verifikation eines bedingten Anweisung. Hoare-Regel für die bedingte Anweisung. Beispiel 2 zur Verifikation eines bedingten Anweisung
Hoare-Regel für die bedingte Anweisung I1 : I2 : {B und P } S 1 {Q} { nicht B und P } {Q} {P } if (B) then S 1 {Q} {B und P } S 1 {Q} { nicht B und P } S 2 {Q} {P } if (B) then S 1 S 2 {Q} In der Regel
Selbsteinstufungstest Vorkurs Programmieren
VPR Selbsteinstufungstest Vorkurs Programmieren Zeit 90 Minuten Aufgabe 1: Einzigartig (10 Punkte) Schreiben Sie eine Methode die angibt, ob ein String str1 in einem zweiten String str2 genau einmal vorkommt.
Logik. Ernest Peter Propädeutikum Mathematik Informatik/Wirtschaftsinformatik, Block Aussage
Logik Die Logik ist in der Programmierung sehr wichtig. Sie hilft z.b. bei der systematischen Behandlung von Verzweigungen und Schleifen. z.b. if (X Y und Y>0) then Oder beim Beweis, dass ein Algorithmus
Testen und Debugging
Testen und Debugging Testklassen, Unit Tests Blackbox Test, Whitebox Test Regressionstesten Zusicherungen mit assert Debugger Informatik II: Objektorientierte SW-Entwicklung, Algorithmik, Nebenläufigkeit
Testen mit Fit und Fitnesse. Ludger Solbach
Testen mit Fit und Fitnesse Ludger Solbach 22.09.2006 Agenda Agenda Einführung Teststufen, Testarten Probleme beim Testen Fit/Fitnesse Vorstellung Arbeitsweise Features Demo Fazit 09/22/06 SSE1 Ludger
4 Grundlagen von SQS-TEST/Professional New Line
4 Grundlagen von SQS-TEST/Professional New Line 4.1 Einführung SQS-TEST/Professional New Line (NL) ist ein umfassendes und flexibles Werkzeug für den Test von Softwareanwendungen. Eine Anwendung (z.b.