# Test-Plan

| Feld            | Wert                                |
|-----------------|--------------------------------------|
| Projekt         | demo-epb                             |
| Datum           | 2026-05-11                           |
| Version         | 1.0                                  |
| Status          | Freigegeben                          |

---

## 1. Teststrategie

Test-First fuer alle Demo-Komponenten. Jede Anforderung erhaelt mindestens einen Test (`@reqs` Tag im Test). Coverage-Ziele wie im SWE-Plan Abschnitt 8.

## 2. Teststufen

| Stufe         | Scope              | Tool       | Umgebung   | Demo-Status |
|---------------|--------------------|------------|------------|-------------|
| Unit          | Funktionen / Module| CppUTest   | Host x86   | Vorhanden   |
| Integration   | Modulzusammenspiel | CppUTest   | Host x86   | TBD         |
| System        | End-to-end         | manuell    | SiL / HiL  | nicht im Demo |
| Abnahme       | Kundenabnahme      | manuell    | HiL / KFZ  | nicht im Demo |

## 3. Test-Verwaltung

- Tests liegen in `tests/unit/` (eine Datei pro Modul)
- Test-Datei enthaelt `@reqs` Tag mit den abgedeckten Anforderungs-IDs
- Test-Lauf erfolgt automatisch in der CI bei jedem Push
- Coverage-Report wird als CI-Artefakt unter `tests/results/coverage/` abgelegt

## 4. Test-Auswahl je Komponente

| Komponente         | ASIL | Test-Datei                          | Methodik                |
|--------------------|------|--------------------------------------|--------------------------|
| Apply Controller   | D    | tests/unit/test_apply_controller.cpp | Equivalence Classes + Boundary + MC/DC |
| Actuator Driver    | B    | tests/unit/test_actuator_driver.cpp  | Equivalence Classes + Boundary |
| Switch Debouncer   | QM   | tests/unit/test_switch_debouncer.cpp | Equivalence Classes      |

## 5. Eingangs- und Abschlusskriterien

**Eingang fuer Testdurchfuehrung:**
- Code kompiliert
- Doorstop-Check gruen
- Statische Analyse ohne kritische Findings

**Abschluss:**
- Alle Tests gruen
- Coverage-Ziel erreicht
- Test-Report archiviert

## 6. Fehlerverwaltung

- Test-Fehlschlag = blockendes Issue
- Issue wird ueber Gitea Issues angelegt, im PR referenziert
- Schwere-Kategorisierung wie in QA-Plan Abschnitt 4

## 7. Reporting

Test-Reports werden automatisch erzeugt:
- Konsolen-Output von CppUTest (TAP / JUnit XML)
- Coverage-HTML aus lcov
- Beides als CI-Artefakt unter `tests/results/`