vault backup: 2025-07-02 14:34:34
This commit is contained in:
104
Semester 6/SWTEST/CTFL-Kapitel 3.md
Normal file
104
Semester 6/SWTEST/CTFL-Kapitel 3.md
Normal file
@@ -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|
|
||||
Reference in New Issue
Block a user