vault backup: 2025-07-02 14:34:34

Semester 6/ITSARCH/Klausurvorbereitung.md

@@ -1,4 +1,4 @@
-# Skripte (durch KI zusammengefasst)
+# Skripte
 - [x] Hashfunktionen
 - [x] TLS 4.5
 - [x] Firewalling

Semester 6/ITSARCH/Skript_Notizen/Exploits IDS_IPS.md

@@ -126,6 +126,4 @@
 - Signaturerkennung: gezielt, aber blind für neue Angriffe
 - Anomalieerkennung: erkennt Neues, aber komplex
 - Snort = praxisnahes IDS, regelbasiert
-- Honeypots zur Analyse & Täuschung von Angreifern
----
-Wenn du willst, kann ich daraus **Karteikarten**, ein **Quiz**, oder eine **Lernmatrix** erstellen – sag einfach Bescheid!
+- Honeypots zur Analyse & Täuschung von Angreifern

Semester 6/ITSARCH/Skript_Notizen/Hash-Algorithmen.md

@@ -82,6 +82,4 @@
 - **Kollision = 2 verschiedene Eingaben → gleicher Hash**
 - **MDC = prüft Integrität**, **MAC = prüft Integrität + Authentizität**
 - **SHA-2 & SHA-3 = derzeit sicher**
-- **HMAC ≠ Signatur**, da symmetrisch!
----
-Wenn du willst, kann ich dir auch Lernkarten (Flashcards), ein Quiz oder eine Mindmap aus diesem Material erstellen. Sag einfach Bescheid!
+- **HMAC ≠ Signatur**, da symmetrisch!

Semester 6/ITSARCH/Skript_Notizen/IPSEC.md

@@ -81,6 +81,4 @@
 - **IKEv2** wird bevorzugt eingesetzt (schneller, mobiler, sicherer).
 - **Anti-Replay-Schutz** ist standardmäßig aktiv (Sequenznummern + Fenster).
 - SPD regelt, **ob IPsec angewendet wird**; SAD enthält die Parameter dazu.
-- AH & ESP sind bei IPv6 **verpflichtend**, bei IPv4 **optional**.
----
-Möchtest du daraus ein **Quiz**, eine **Mindmap**, oder **Lernkarten** zur Wiederholung haben? Sag einfach Bescheid!
+- AH & ESP sind bei IPv6 **verpflichtend**, bei IPv4 **optional**.

Semester 6/ITSARCH/Skript_Notizen/IPTables.md

@@ -97,10 +97,4 @@ $FW -A INPUT -p icmp -j DROP
 ## ✅ BEST PRACTICE
 - **Besser**: „Blockiere alles, erlaube nur was nötig ist“ (Default: DROP)
 - Verwende `--state ESTABLISHED, RELATED`, um gültige Verbindungen zu erlauben
-- Speichere Regeln in Skripten (z. B. `/etc/network/firewall`) und rufe sie über `/etc/rc.local` auf
----
-Wenn du möchtest, kann ich dir daraus auch:
-- eine **Befehlstabelle zum Auswendiglernen**
-- ein **Mini-Quiz**
-- oder eine **interaktive Übung** zur Regel-Erstellung erstellen.
-Sag einfach Bescheid!
+- Speichere Regeln in Skripten (z. B. `/etc/network/firewall`) und rufe sie über `/etc/rc.local` auf

Semester 6/ITSARCH/Skript_Notizen/SSH.md

@@ -102,10 +102,4 @@
 - Tools wie `ssh-agent` & `ssh-add` erhöhen Sicherheit & Komfort
 - **Passwortauthentifizierung deaktivieren** (wo möglich)
 - **ssh-audit** zur Analyse verwenden
-- SSH2/OpenSSH = **Standard**, SSH1 = **veraltet**
----
-Wenn du möchtest, kann ich dir daraus gerne:
-- **Lernkarten (Flashcards)**
-- eine **Mindmap**
-- oder ein **Mini-Quiz** erstellen.
-Sag einfach Bescheid!
+- SSH2/OpenSSH = **Standard**, SSH1 = **veraltet**

Semester 6/ITSARCH/Skript_Notizen/TLS 4.5.md

@@ -101,6 +101,4 @@ Aus dem **Master Secret** werden erzeugt:
     - Authentifizierung via Zertifikaten (X.509)
     - Session Keys für symmetrische Verschlüsselung
 - SSL ist **applikationsunabhängig**
-- **SSL Record Layer** = zentrale Schicht zur Absicherung der Nutzdaten
----
-Wenn du willst, kann ich dir daraus auch **Karteikarten**, ein **Quiz**, oder eine **grafische Übersicht** (z. B. Ablaufdiagramm) für den Handshake oder die Schlüsselableitung erstellen. Sag einfach Bescheid!
+- **SSL Record Layer** = zentrale Schicht zur Absicherung der Nutzdaten

Semester 6/SWTEST/CTFL-Kapitel 0.md

@@ -0,0 +1,127 @@
+## 🎯 ZIELE DER LEHRVERANSTALTUNG
+
+- Vermittlung von **Grundlagen im Softwaretesten**
+    
+- Verständnis für **Begriffe, Aufgaben, Methoden & Verfahren**
+    
+- Vorbereitung auf die **CTFL-Prüfung** (international anerkannt)
+    
+
+---
+
+## 🧪 WARUM SOFTWARETEST?
+
+### Beispiele schwerwiegender Softwarefehler:
+
+- ❌ Ariane 5: Absturz durch Reuse fehlerhafter Lageregelungssoftware
+    
+- ❌ T-Mobile (2009): Netzstörung durch Fehler im HLR
+    
+- ❌ Deutsche Bank / BAföG / GM / Roche: Fehler mit realen Konsequenzen
+    
+
+➡️ Softwarefehler führen zu:
+
+- **wirtschaftlichen Schäden**
+    
+- **Lebensgefahr (z. B. Medizintechnik, Automotive)**
+    
+- **Imageverlust**
+    
+
+---
+
+## 💥 BEGRIFFE: Fehler, Bug, Defekt
+
+- **Fehler (Defect)**: Abweichung vom erwarteten Verhalten
+    
+- **Bug**: oft als Synonym genutzt
+    
+- **Erster dokumentierter Bug**: Motte im Relay (1947)
+    
+
+---
+
+## 🧠 TESTBARENGRUNDLAGEN
+
+- Vollständiges Austesten ≠ realistisch möglich
+    
+    - Beispiel 1: 3 Eingabewerte à 16 Bit → 2⁴⁸ Kombinationen → **ca. 90 Jahre**
+        
+    - Beispiel 2: Schleifen + Verzweigungen → 10¹⁴ Testfälle → **38 Jahre**
+        
+
+➡️ **Testen ist selektiv & risikobasiert notwendig!**
+
+---
+
+## 🔍 TESTKATEGORIEN (am Beispiel „Dreieckprogramm“)
+
+### Testziele:
+
+- **Funktionalität prüfen**: korrektes Verhalten bei Eingaben
+    
+- **Fehlerhafte Eingaben erkennen**: negative Zahlen, zu viele/wenige Werte etc.
+    
+- **Grenzwerte testen**: z. B. `0`, `Max_Int`
+    
+
+### Beispiel-Testfälle:
+
+- Gleichseitig: 2,2,2
+    
+- Ungleichseitig: 2,3,4
+    
+- Ungültig: -5, 0, Zeichen, zu viele Werte
+    
+- Spezialfälle: Kombinationen nahe Grenzwerten
+    
+
+➡️ **Testdaten ≠ zufällig**, sondern **gezielt konstruiert**
+
+---
+
+## 🚗 PARALLELEN ZUR INDUSTRIE
+
+**Automobilindustrie**:
+
+- Komponententest → Integrationstest → Systemtest → Abnahmetest → Stresstest
+    
+
+➡️ Übertragbar auf Software: **Teststufen & strukturiertes Vorgehen**
+
+---
+
+## 💬 FAZIT / MERKSPRÜCHE
+
+- **„Testen zeigt die Anwesenheit von Fehlern, nicht ihre Abwesenheit.“**
+    
+- **„Ein Test ohne definiertes Ziel ist Zeitverschwendung.“**
+    
+- **„Keine Software ist fehlerfrei.“**
+    
+- **„Vollständiges Austesten ist meist unmöglich.“**
+    
+
+---
+
+## 📚 LITERATUR & WEITERFÜHRENDES
+
+- Lehrbuch: **Spillner/Linz** – _Basiswissen Softwaretest_
+    
+- Weitere: Beizer, Myers, Liggesmeyer, TMap, ISO 29119
+    
+- Fachzeitschriften & Konferenzen: _GTB_, _EuroSTAR_, _ICST_
+    
+
+---
+
+## ✅ KLAUSURRELEVANTE KERNAUSSAGEN
+
+|Thema|Prüfungstauglicher Merksatz|
+|---|---|
+|Fehlerauswirkungen|Kleine Fehler können große Folgen haben|
+|Austestbarkeit|Testabdeckung muss begrenzt & gezielt sein|
+|Dreieck-Programm|Guter Einstieg zur **Testfallerstellung**|
+|Zertifizierung|ISTQB CTFL ist international anerkannt|
+|Test ist wichtig|Auch einfache Programme sind schwer zu testen|

Semester 6/SWTEST/CTFL-Kapitel 1.md

@@ -0,0 +1,115 @@
+## 📘 KAPITEL 1: GRUNDLAGEN DES TESTENS
+
+---
+
+### 1.1 Warum ist Testen notwendig?
+
+- Softwarefehler können **Kosten, Sicherheitsprobleme, Rufschädigung** verursachen.
+    
+- Gründe für Fehler:
+    
+    - Missverständnisse, Zeitdruck, komplexe Systeme, neue Technologien.
+        
+- **Testen reduziert Risiken**, aber **kann Fehler nicht vollständig beseitigen**.
+    
+
+---
+
+### 1.2 Was ist Testen?
+
+- Testen = **Planung, Vorbereitung, Durchführung & Bewertung** von Softwaretests.
+    
+- Ziel:
+    
+    - Fehler finden
+        
+    - Vertrauen schaffen
+        
+    - Konformität mit Anforderungen prüfen
+        
+    - Grundlage für Qualität liefern
+        
+
+---
+
+### 1.3 Allgemeine Testziele
+
+|Zieltyp|Beschreibung|
+|---|---|
+|**Fehlervorbeugung**|Schon in frühen Phasen vermeiden|
+|**Fehlererkennung**|Möglichst früh entdecken|
+|**Verifikation**|Korrektheit prüfen: „bauen wir es richtig?“|
+|**Validierung**|Zweck prüfen: „bauen wir das Richtige?“|
+
+---
+
+### 1.4 Testen und Debuggen
+
+- **Testen**: Fehler _finden_
+    
+- **Debuggen**: Fehler _analysieren und beheben_
+    
+
+➡️ Zwei **komplementäre Aktivitäten** im Lebenszyklus
+
+---
+
+### 1.5 Sieben Prinzipien des Testens (💡 Prüfungsrelevant)
+
+1. **Testen zeigt Anwesenheit von Fehlern, nicht deren Abwesenheit**
+    
+2. **Vollständiges Testen ist nicht möglich**
+    
+3. **Frühes Testen spart Zeit und Geld**
+    
+4. **Fehlerhäufung in bestimmten Bereichen (Pareto-Prinzip)**
+    
+5. **Testwiederholungen → Testfälle anpassen (Testfallverfall)**
+    
+6. **Testen ist kontextabhängig (z. B. sicherheitskritisch vs. Webshop)**
+    
+7. **Trugschluss Fehlerfreiheit ≠ Gebrauchstauglichkeit**
+    
+
+---
+
+### 1.6 Testprozess (Phasenmodell)
+
+1. **Testplanung und -steuerung**
+    
+2. **Testanalyse und -design**
+    
+3. **Testrealisierung und -durchführung**
+    
+4. **Testauswertung und -abschluss**
+    
+
+➡️ Unterstützt durch **Testüberwachung, Metriken & Dokumentation**
+
+---
+
+### 1.7 Psychologie des Testens
+
+- Zielkonflikt Entwickler vs. Tester:
+    
+    - Entwickler: „Software funktioniert!“
+        
+    - Tester: „Software hat Schwächen!“
+        
+
+🧠 Gute Zusammenarbeit & Kommunikation sind entscheidend:
+
+- **Objektivität, Kritikfähigkeit, keine Schuldzuweisungen**
+    
+
+---
+
+## ✅ KLAUSURRELEVANTE MERKSÄTZE
+
+|Thema|Merksatz|
+|---|---|
+|Testzweck|Fehler _finden_, nicht beseitigen|
+|Prinzipien|7 Prinzipien **verstehen & benennen können**|
+|Test vs. Debugging|Zwei **getrennte Prozesse**|
+|Testprozesse|Test hat **strukturierte Phasen**|
+|Testpsychologie|**Konstruktives Konfliktmanagement** notwendig|

Semester 6/SWTEST/CTFL-Kapitel 2.md

@@ -0,0 +1,102 @@
+## 📘 KAPITEL 2: TESTEN IM SOFTWARELEBENSZYKLUS
+
+---
+
+### 2.1 Softwareentwicklungsmodelle
+
+**Testen muss in den gesamten Entwicklungsprozess integriert sein!**
+
+#### a) Sequenzielle Modelle (klassisch, Wasserfall, V-Modell)
+
+- **Vorteil**: frühzeitige Planung, klare Phasen
+    
+- **Nachteil**: späte Fehlererkennung, wenig flexibel
+    
+
+#### b) Iterative/inkrementelle Modelle (z. B. Agile)
+
+- **Testen** = integraler Bestandteil jeder Iteration
+    
+- Kontinuierliches Feedback, frühe Tests
+    
+- Flexibler, aber aufwändiger
+    
+
+---
+
+### 2.2 Teststufen (💡 Prüfungsrelevant)
+
+|Teststufe|Fokus|Testbasis|Ziel|
+|---|---|---|---|
+|**Komponententest**|Einzelprogramme/Funktionen|Source Code, Design Specs|Fehler in Modulen erkennen|
+|**Integrationstest**|Zusammenspiel von Komponenten|Schnittstellenspezifikation|Fehler in Modulen & Interfaces|
+|**Systemtest**|Gesamtsystem|Anforderungen|Anforderungen erfüllt?|
+|**Abnahmetest**|Validierung mit Nutzer|Businessanforderungen|Auslieferungsreife prüfen|
+
+🔄 **Statische Tests** (Reviews) ergänzen die Teststufen
+
+---
+
+### 2.3 Testarten (Was wird getestet?)
+
+#### Funktionale Tests
+
+- Verhalten & Funktionen
+    
+- z. B. Geschäftslogik, Benutzerinteraktion
+    
+
+#### Nicht-funktionale Tests
+
+- **Leistung**, **Benutzbarkeit**, **Zuverlässigkeit**, **Sicherheit**
+    
+- Beispiel: Lasttests, Sicherheitstests
+    
+
+#### Strukturbezogene Tests
+
+- Interne Struktur (z. B. Codeabdeckung, Verzweigungspfad)
+    
+
+#### Änderungsbezogene Tests
+
+- **Re-Tests**: Prüfen behobener Fehler
+    
+- **Regressionstests**: Prüfen unbeabsichtigter Nebeneffekte
+    
+
+---
+
+### 2.4 Wartungstest
+
+- Tests im Produktivsystem nach Änderungen (Fehlerbehebung, Anpassung)
+    
+- Besonders wichtig:
+    
+    - **Regressionstest**
+        
+    - **Impact-Analyse**
+        
+- Testdaten und Testumgebung **aktuell halten**
+    
+
+---
+
+### 2.5 Teststufen & Testarten kombinieren
+
+- Beispiel: Im **Systemtest** können **funktionale Tests** UND **nicht-funktionale Tests** durchgeführt werden.
+    
+- Jeder Teststufe können verschiedene **Testziele** zugeordnet werden.
+    
+
+---
+
+## ✅ KLAUSURRELEVANTE MERKPUNKTE
+
+|Thema|Prüfungswissen|
+|---|---|
+|V-Modell|Testaktivitäten sind klar definiert & gekoppelt mit Entwicklungsphasen|
+|Teststufen|**Komponente → Integration → System → Abnahme** (Reihenfolge merken!)|
+|Testarten|Funktional, Nicht-funktional, Struktur-, Änderungsbezogen|
+|Wartungstest|Regression und Impact-Analyse notwendig|
+|Agile Modelle|**Test = Teil jeder Iteration**|

Semester 6/SWTEST/CTFL-Kapitel 3.md

@@ -0,0 +1,104 @@
+## 📘 KAPITEL 3: STATISCHES TESTEN
+
+---
+
+### 3.1 Was ist statisches Testen?
+
+- **Statisches Testen** = Analyse **ohne Programmausführung**
+    
+- Ziel: **Frühzeitiges Erkennen** von Fehlern und Schwächen
+    
+- Ergänzt dynamisches Testen (mit Programmausführung)
+    
+
+**Beispiele:**
+
+- Dokumentation, Code, Testfälle, Anforderungen prüfen
+    
+
+---
+
+### 3.2 Arten statischer Tests
+
+|Art|Merkmale|
+|---|---|
+|**Statische Analyse**|Automatisierte Tools analysieren Code-Struktur|
+|**Reviews (manuell)**|Menschen analysieren Dokumente & Artefakte|
+
+---
+
+### 3.3 Statische Analyse durch Tools
+
+#### Ziele:
+
+- Automatisierte Prüfung von Quellcode
+    
+- **Vermeidung technischer Schulden**
+    
+
+#### Erkennbar durch Tools:
+
+- **Syntaxfehler**
+    
+- **Nicht initialisierte Variablen**
+    
+- **Dead Code / nicht erreichbarer Code**
+    
+- **Verletzungen von Codierstandards**
+    
+- **Sicherheitslücken (z. B. Buffer Overflow)**
+    
+
+➡️ **Ergänzung, kein Ersatz für Reviews!**
+
+---
+
+### 3.4 Reviewarten (💡 Prüfungsrelevant)
+
+|Reviewtyp|Beschreibung & Merkmale|
+|---|---|
+|**Informell**|z. B. Peer Review, keine Dokumentation|
+|**Walkthrough**|Autor führt Gruppe durch Dokument|
+|**Technisches Review**|Fokus auf Inhalte, nicht auf Format|
+|**Inspektion**|Strukturiert, mit Rollen, Protokollierung, Prüfprotokollen|
+
+➡️ **Inspektion ist die formalste & effektivste Methode.**
+
+---
+
+### 3.5 Rollen in einem Review
+
+|Rolle|Aufgabe|
+|---|---|
+|**Autor**|Ersteller des Prüflings|
+|**Moderator**|Leitung & Organisation|
+|**Prüfer**|Suchen nach Defekten|
+|**Protokollant**|Dokumentiert Ergebnisse|
+|**Manager**|Review-Rahmenbedingungen schaffen|
+
+---
+
+### 3.6 Reviewprozess (z. B. Inspektion)
+
+1. **Planung** (Teilnehmer, Artefakt, Reviewziel)
+    
+2. **Kick-off** (Einführung, Zielklärung)
+    
+3. **Einzelprüfung** (Teilnehmer sichten Artefakt individuell)
+    
+4. **Review-Meeting** (gemeinsame Sichtung, Diskussion)
+    
+5. **Nachbearbeitung** (Fehlerbehebung, Follow-up)
+    
+
+---
+
+## ✅ KLAUSURRELEVANTE MERKSÄTZE
+
+|Thema|Merksatz|
+|---|---|
+|Statisches Testen|Testen ohne Ausführen des Programms|
+|Reviewtypen|**Inspektion** = formal, **Walkthrough** = moderiert, informell|
+|Toolbasierte Analyse|Ergänzung zu manuellen Reviews, keine Ablösung|
+|Reviewrollen|Moderator ≠ Autor, Protokollant dokumentiert|
+|Nutzen|Frühes Feedback spart spätere Kosten|

Semester 6/SWTEST/CTFL-Kapitel 4-1.md

@@ -0,0 +1,118 @@
+## 📘 KAPITEL 4.1: TESTTECHNIKEN – GRUNDLAGEN
+
+---
+
+### 4.1 Einleitung: Warum Testverfahren?
+
+- Systematisches Vorgehen → bessere **Testabdeckung**
+    
+- Unterstützung bei der Erstellung **guter Testfälle**
+    
+- Ziel: Fehler früh entdecken & reproduzierbar testen
+    
+
+---
+
+## 🧪 HAUPTKATEGORIEN VON TESTVERFAHREN
+
+|Kategorie|Merkmale & Grundlage|
+|---|---|
+|**Black-Box**|Anforderungen / Spezifikation|
+|**White-Box**|Programmstruktur / Code|
+|**Erfahrungsbasiert**|Intuition, frühere Fehler, Exploratives Testen|
+
+---
+
+### 🔲 1. BLACK-BOX-VERFAHREN (💡 Prüfungsrelevant)
+
+Nutzen **Eingabe-Ausgabe-Beziehung**, ohne Quellcode zu betrachten.
+
+#### a) Äquivalenzklassenbildung
+
+- Eingaben in gültige/ungültige **Klassen** einteilen
+    
+- **Aus jeder Klasse → 1 Testfall**
+    
+
+#### b) Grenzwertanalyse
+
+- Grenzwerte sind **fehleranfällig**
+    
+- Testfälle **am Rand** der Äquivalenzklassen
+    
+
+#### c) Entscheidungstabellen
+
+- Repräsentieren **Regeln & Bedingungen**
+    
+- Kombinationen aus Bedingungen → Aktionen
+    
+
+#### d) Zustandsbasierter Test
+
+- Bei **zustandsbehafteten Systemen** (z. B. Automaten)
+    
+- Zustände, Übergänge, Events → modellieren & testen
+    
+
+#### e) Use Case Test
+
+- **Szenarien aus Benutzersicht** abdecken
+    
+- Ziel: reale Nutzungspfade testen
+    
+
+---
+
+### 🔳 2. WHITE-BOX-VERFAHREN
+
+Berücksichtigen **interne Struktur** des Systems/Programms
+
+#### a) Anweisungsüberdeckung
+
+- Jede Anweisung im Code muss mindestens **einmal ausgeführt** werden
+    
+
+#### b) Zweigüberdeckung
+
+- Jeder Entscheidungspunkt (z. B. `if`, `else`) → **jede Richtung** wird getestet
+    
+
+➡️ Für Entwicklernahe Tests (z. B. Komponententest)
+
+---
+
+### 💡 3. ERFAHRUNGSBASIERTE VERFAHREN
+
+- Beruhen auf **Intuition, Erfahrung, Bauchgefühl**
+    
+- Beispiele:
+    
+    - **Fehlerbasiertes Testen**
+        
+    - **Checklisten**
+        
+    - **Exploratives Testen**
+        
+
+Einsatz besonders:
+
+- wenn wenig Dokumentation vorhanden ist
+    
+- bei Timeboxing (agile Projekte)
+    
+- als Ergänzung zu strukturierten Verfahren
+    
+
+---
+
+## ✅ KLAUSURRELEVANTE MERKPUNKTE
+
+|Thema|Merksatz|
+|---|---|
+|Black-Box|Tests basieren auf **Spezifikationen**, nicht auf Code|
+|White-Box|Ziel: **Codepfade** und **Verzweigungen** abdecken|
+|Äquivalenzklassen|Jede Klasse mit **einem repräsentativen Testfall**|
+|Grenzwertanalyse|Fehler liegen oft **an den Rändern**|
+|Entscheidungs- & Zustandsbasierte Tests|gut bei komplexem Verhalten & Bedingungen|
+|Erfahrungsbasiert|Ergänzend, flexibel, intuitiv, explorativ|

Semester 6/SWTEST/CTFL-Kapitel 4-2.md

@@ -0,0 +1,159 @@
+## 📘 KAPITEL 4.2: BLACK-BOX-TESTVERFAHREN (DETAIL)
+
+---
+
+### 🎯 Ziel
+
+- Testfälle auf Basis der **Anforderungen/Spezifikation** ableiten
+    
+- Fokus: **funktionales Verhalten** (ohne Quellcode)
+    
+
+---
+
+## 1. ✅ ÄQUIVALENZKLASSEN-BILDUNG
+
+### Ziel:
+
+- Eingaberaum in **repräsentative Klassen** aufteilen (gültig + ungültig)
+    
+
+### Vorgehen:
+
+1. Klassen identifizieren (z. B. Wertebereiche)
+    
+2. Gültige & ungültige Klassen bilden
+    
+3. Pro Klasse → 1 Repräsentant
+    
+
+**Beispiel: Eingabe 1–10**
+
+- Gültig: 1–10 → z. B. Testwert 5
+    
+- Ungültig: <1, >10 → z. B. Testwert 0 und 11
+    
+
+---
+
+## 2. ⚠️ GRENZWERTANALYSE
+
+### Ziel:
+
+- **Fehler an Grenzen** von Wertebereichen erkennen
+    
+
+### Vorgehen:
+
+- Testfälle an & um die Grenze: `Grenze - 1`, `Grenze`, `Grenze + 1`
+    
+
+**Beispiel: Bereich 1–10**
+
+- Testfälle: 0, 1, 2 | 9, 10, 11
+    
+
+➡️ Ergänzt Äquivalenzklassen
+
+---
+
+## 3. 🧾 ENTSCHEIDUNGSTABELLEN
+
+### Ziel:
+
+- **Regelbasierte Entscheidungen** systematisch testen
+    
+
+### Bestandteile:
+
+- Bedingungen (z. B. "Kunde zahlt bar?")
+    
+- Aktionen (z. B. "Rabatt gewähren")
+    
+- Tabelle listet alle möglichen **Kombinationen**
+    
+
+### Vorteile:
+
+- Gute Testabdeckung bei **Kombinatorik**
+    
+- Auch für Geschäftsregeln & Konfigurationen geeignet
+    
+
+---
+
+## 4. 🔄 ZUSTANDSÜBERGANGSTEST
+
+### Ziel:
+
+- Testen von Systemen mit **internen Zuständen**
+    
+
+### Elemente:
+
+- **Zustände** (z. B. „angemeldet“, „abgemeldet“)
+    
+- **Ereignisse/Übergänge** (z. B. „Login“, „Logout“)
+    
+- **Aktionen** (z. B. „Zugriff erlaubt“)
+    
+
+### Arten von Tests:
+
+- Alle Übergänge
+    
+- Alle Zustände
+    
+- Ungültige Übergänge
+    
+
+➡️ Modellierung über **Zustandsdiagramme** sinnvoll
+
+---
+
+## 5. 👤 USE CASE TEST
+
+### Ziel:
+
+- **Benutzerverhalten / Interaktionen** mit dem System testen
+    
+
+### Merkmale:
+
+- Abbildung typischer **Szenarien**
+    
+- Fokus auf **End-to-End-Abläufe**
+    
+- Kann auch **nicht-funktionale Aspekte** einbeziehen
+    
+
+### Beispiele:
+
+- "Benutzer meldet sich an"
+    
+- "Benutzer gibt Bestellung auf"
+    
+
+---
+
+## ✅ ZUSAMMENFASSUNG DER BLACK-BOX-VERFAHREN
+
+|Verfahren|Fokus|Typische Anwendung|
+|---|---|---|
+|Äquivalenzklassen|Eingaberaum abdecken|Wertebereiche, Formate|
+|Grenzwertanalyse|Fehler an Bereichsgrenzen|Zahlen, Datumswerte|
+|Entscheidungstabellen|Regeln & Kombinationen prüfen|Rabattlogik, Konditionen|
+|Zustandsübergänge|Zustandssysteme abbilden|Automaten, Sitzungen|
+|Use Cases|Nutzerverhalten simulieren|Geschäftsprozesse, UI|
+
+---
+
+## 📝 KLAUSURRELEVANTE MERKPUNKTE
+
+|Thema|Merksatz|
+|---|---|
+|Äquivalenzklassen|Pro Klasse genau **ein Testfall**|
+|Grenzwertanalyse|Teste **an, vor und nach** der Grenze|
+|Entscheidungstabellen|**Alle Regelkombinationen** prüfen|
+|Zustandsbasierte Tests|Übergänge & Reaktionen prüfen, auch **ungültige**|
+|Use Case Tests|Nutzer-Szenarien, oft End-to-End|

Semester 6/SWTEST/CTFL-Kapitel 5.md

@@ -0,0 +1,104 @@
+## 📘 KAPITEL 5: TESTMANAGEMENT
+
+---
+
+### 5.1 Testorganisation
+
+* Testverantwortung kann in **Entwicklung integriert** oder **getrennt organisiert** sein.
+* Rollen können je nach Projektform variieren:
+
+  * **Testmanager**
+  * **Tester**
+  * **Testanalyst / Technical Test Analyst**
+  * **Testautomatisierer**
+
+---
+
+### 5.2 Testplanung und -steuerung
+
+#### Testplanung
+
+* Definition von:
+
+  * **Zielen**
+  * **Strategie**
+  * **Umfang**
+  * **Aufwand & Ressourcen**
+  * **Zeitplan**
+
+#### Teststeuerung
+
+* **Vergleich** von Ist- und Sollwerten
+* **Anpassung** des Testvorgehens bei Abweichungen
+
+---
+
+### 5.3 Testfortschritt und -abschluss
+
+#### Testfortschrittskennzahlen (Metriken)
+
+* Anzahl durchgeführter Tests
+* Anzahl gefundener Fehler
+* Testabdeckung
+* Aufwand vs. Fortschritt
+
+#### Abschlussaktivitäten:
+
+* Fehlerstatus prüfen
+* Lessons Learned
+* Testabschlussbericht erstellen
+
+---
+
+### 5.4 Konfigurationsmanagement
+
+* Sicherstellen, dass:
+
+  * **Testobjekte eindeutig versioniert** sind
+  * **Änderungen nachvollziehbar** bleiben
+* Tools zur Verwaltung von:
+
+  * Anforderungen
+  * Testfällen
+  * Codeversionen
+
+---
+
+### 5.5 Risikomanagement im Test
+
+| Begriff                  | Bedeutung                                                          |
+| ------------------------ | ------------------------------------------------------------------ |
+| **Risiko**               | Möglichkeit eines negativen Ereignisses                            |
+| **Risikobasierter Test** | Priorisierung nach Schadenspotenzial & Eintrittswahrscheinlichkeit |
+
+#### Risikoarten:
+
+* **Produktrisiko**: betrifft Software (z. B. Datenverlust)
+* **Projektrisiko**: betrifft Projekt (z. B. Terminüberschreitung)
+
+---
+
+### 5.6 Fehler- und Abweichungsmanagement
+
+* **Fehlermanagementprozess**:
+
+  1. Fehler identifizieren
+  2. Fehler dokumentieren (z. B. Reproduktionsschritte)
+  3. Status verfolgen (neu, in Bearbeitung, gelöst …)
+  4. Abschluss prüfen
+
+* Abweichung ≠ immer Fehler (z. B. unvollständige Anforderungen)
+
+---
+
+## ✅ KLAUSURRELEVANTE MERKSÄTZE
+
+| Thema                    | Merksatz                                               |
+| ------------------------ | ------------------------------------------------------ |
+| Testplanung              | Definiert **Was, Wie, Wer, Wann**                      |
+| Teststeuerung            | Vergleicht **Planung ↔ Realität**, passt an            |
+| Fortschrittsmetriken     | Basis für **objektive Steuerung**                      |
+| Konfigurationsmanagement | Kontrolliert Versionen & Änderungen                    |
+| Risikobasiertes Testen   | Priorisiert **nach Schadenshöhe & Wahrscheinlichkeit** |
+| Fehlermanagement         | Fehler dokumentieren & nachverfolgen bis Abschluss     |
+

Semester 6/SWTEST/CTFL-Kapitel 6.md

@@ -0,0 +1,123 @@
+## 📘 KAPITEL 6: TOOLUNTERSTÜTZUNG IM TESTPROZESS
+
+---
+
+### 6.1 Einsatzmöglichkeiten von Testwerkzeugen
+
+#### Ziele:
+
+- Effizienz steigern
+    
+- Wiederholbarkeit sicherstellen
+    
+- Fehler vermeiden
+    
+
+#### Typische Tool-Einsatzbereiche:
+
+|Einsatzbereich|Beispiele für Werkzeuge|
+|---|---|
+|**Testmanagement**|Testplanung, Fortschrittsverfolgung|
+|**Anforderungsmanagement**|Rückverfolgbarkeit von Anforderungen|
+|**Statische Analyse**|Code-Analyse, Einhaltung von Codestandards|
+|**Testfallerstellung**|manuell oder generiert|
+|**Testdurchführung & Auswertung**|Automatisierte Tests, Logging, Reports|
+|**Defektmanagement**|Bug-Tracking, z. B. Jira, Bugzilla|
+|**Testdaten- & Umweltverwaltung**|Konsistente Testdaten, Containerisierung|
+
+---
+
+### 6.2 Vorteile und Risiken von Tools
+
+#### ✅ Vorteile:
+
+- Automatisierung → **Zeitersparnis**
+    
+- **Konsistenz & Reproduzierbarkeit**
+    
+- **Skalierbarkeit** bei Regressionstests
+    
+
+#### ⚠️ Risiken:
+
+- **Einführungsaufwand** hoch
+    
+- **Wartung & Pflege** der Tools notwendig
+    
+- Gefahr von **Tool-Gläubigkeit** („Tool löst alle Probleme“)
+    
+- **Falsche Anwendung** kann schaden
+    
+
+---
+
+### 6.3 Toolklassifizierung nach ISTQB
+
+|Tooltyp|Beschreibung|
+|---|---|
+|**Statische Analyse-Tools**|z. B. Lint, SonarQube|
+|**Testdesign-Tools**|z. B. Testdaten-Generatoren|
+|**Testautomatisierung**|z. B. Selenium, JUnit|
+|**Defektmanagement-Tools**|z. B. Bugzilla, Jira|
+|**Performance-Testtools**|z. B. JMeter|
+|**Coverage-Tools**|z. B. Jacoco|
+
+---
+
+### 6.4 Auswahl & Einführung von Tools
+
+#### Auswahlkriterien:
+
+- Projekt- & Teamgröße
+    
+- Integration in bestehende Infrastruktur
+    
+- Schulungsbedarf
+    
+- Support & Lizenzmodell
+    
+
+#### Einführungsprozess:
+
+1. **Bedarf klären**
+    
+2. **Tool evaluieren & auswählen**
+    
+3. **Pilotphase**
+    
+4. **Rollout**
+    
+5. **Wartung & kontinuierliche Verbesserung**
+    
+
+---
+
+### 6.5 Automatisierung sinnvoll einsetzen
+
+#### Typische Einsatzszenarien:
+
+- **Regressionstests**
+    
+- **Build-Verifikation (CI/CD)**
+    
+- **Performance-Messung**
+    
+- **Datengetriebenes Testen**
+    
+
+➡️ **Automatisierung ≠ universell sinnvoll**
+
+- Bei **explorativem Testen**, UX-Tests oder stark ändernden UIs → lieber manuell
+    
+
+---
+
+## ✅ KLAUSURRELEVANTE MERKPUNKTE
+
+|Thema|Merksatz|
+|---|---|
+|Toolnutzen|**Effizienz & Konsistenz**, aber kein Allheilmittel|
+|Risiken|**Falsche Erwartungen**, hoher Einführungsaufwand|
+|Toolauswahl|Nach **Projektkontext & Integration** wählen|
+|Automatisierung|Gut für **wiederholbare, stabile Tests**|
+|Defektmanagement|Erlaubt **systematische Fehlerverfolgung**|

Semester 6/SWTEST/Klausurvorbereitung.md

@@ -0,0 +1,11 @@
+# Durchlesen der Zusammenfassungen
+- [ ] Kap 0
+- [ ] Kap 1
+- [ ] Kap 2
+- [ ] Kap 3
+- [ ] Kap 4-1
+- [ ] Kap 4-2
+- [ ] Kap 5
+- [ ] Kap 6
+
+## Bearbeitung der Aufgaben