# Testplan

| Feld            | Wert                          |
|-----------------|-------------------------------|
| Projekt         | [Projektname]                 |
| Datum           | [YYYY-MM-DD]                  |
| Version         | [1.0]                         |
| Status          | [Entwurf / Freigegeben]       |
| ASIL            | [QM / A / B / C / D]         |
| Bezug           | SWE-Plan Version [X.Y]       |

---

## 1. Testziele

- Nachweis, dass die Software die spezifizierten Anforderungen erfuellt
- Nachweis der strukturellen Code-Abdeckung gemaess ASIL-Vorgaben
- Nachweis der Robustheit gegenueber Fehlbedienung und Grenzwerten
- Identifikation von Defekten vor der Integration / Auslieferung

## 2. Teststrategie

| Teststufe           | Testziel                                    | Methode          | Automatisierung |
|---------------------|---------------------------------------------|------------------|-----------------|
| Unit Test           | Einzelne Funktionen / Module korrekt        | White-Box        | CI (automatisch)|
| Integrations-Test   | Zusammenspiel der Module                    | Grey-Box         | CI / SiL        |
| System-Test         | Erfuellung der System-Anforderungen         | Black-Box        | SiL / HiL       |
| Regressionstest     | Keine Seiteneffekte durch Aenderungen       | Automatisiert     | CI              |

### Unit Tests

- Framework: [CppUTest / Google Test / Unity+CMock]
- Laufen auf Host-Plattform (x86)
- Jede Anforderung hat mindestens einen zugehoerigen Testfall
- Negative Tests und Grenzwerte sind Pflicht

### Integrationstests

- Pruefen Schnittstellen zwischen Modulen
- Laufen auf Host oder SiL-Umgebung
- Kommunikationsschnittstellen (CAN, SPI, UART) werden per Mock oder Simulator getestet

### System-Tests

- Pruefen gegen System-Anforderungen
- Laufen auf SiL oder HiL
- Testfaelle werden aus System-Requirements abgeleitet

## 3. Coverage-Ziele

| Metrik              | Zielwert       | Messung          |
|---------------------|----------------|------------------|
| Statement Coverage  | >= [X]%        | gcov/lcov        |
| Branch Coverage     | >= [X]%        | gcov/lcov        |
| MC/DC               | >= [X]% (falls anwendbar) | MCDC-Star / kommerziell |

Referenz: ISO 26262 Part 6, Table 9.

| ASIL | Statement | Branch  | MC/DC        |
|------|-----------|---------|--------------|
| QM   | empfohlen | —       | —            |
| A    | Pflicht   | empfohlen | —          |
| B    | Pflicht   | Pflicht | —            |
| C    | Pflicht   | Pflicht | empfohlen    |
| D    | Pflicht   | Pflicht | Pflicht      |

## 4. Testumgebung

| Komponente          | Beschreibung                                       |
|---------------------|----------------------------------------------------|
| Host-Plattform      | [Linux x86_64 / macOS ARM64]                       |
| Cross-Compiler      | [GCC ARM X.Y]                                      |
| Test-Framework      | [CppUTest / Google Test / Unity]                   |
| SiL-Framework       | [Python + pytest, Kommunikation: UART/CAN/TCP]     |
| HiL-System          | [dSPACE Scalexio / vom Kunden gestellt / entfaellt] |
| CI-Runner           | [GitLab Runner, Docker Image: ...]                  |

## 5. Testdaten

- Testdaten werden im Repository unter `tests/data/` versioniert
- Grenzwerte aus Anforderungen ableiten
- Ungueltige Eingaben explizit testen
- Testdaten fuer Regressionen aus Bug-Reports ableiten

## 6. Pass/Fail-Kriterien

### Einzelner Testfall

- **Pass:** Erwartetes Ergebnis stimmt mit tatsaechlichem ueberein
- **Fail:** Abweichung vom erwarteten Ergebnis

### Teststufe gesamt

| Kriterium                              | Bedingung fuer Pass                    |
|----------------------------------------|----------------------------------------|
| Alle Testfaelle ausgefuehrt            | Ja                                     |
| Alle Testfaelle bestanden              | Ja (oder Fails bewertet und genehmigt) |
| Coverage-Ziel erreicht                 | Ja                                     |
| Keine offenen Critical Findings        | Ja                                     |
| Traceability vollstaendig              | Jede Anforderung hat mindestens einen Test |

Fehlgeschlagene Tests, die nicht behoben werden, muessen per Non-Conformity oder Change Request dokumentiert und bewertet werden.

## 7. Traceability

Jeder Testfall muss auf mindestens eine Anforderung rueckfuehrbar sein.

```
Anforderung (GitLab Issue, Label: req::software)
  → Testfall (GitLab Issue, Label: test::unit / test::integration / test::system)
    → Testergebnis (CI-Artefakt / JUnit-XML)
```

Umsetzung:
- Testfall-Issue verlinkt auf Anforderungs-Issue ("relates to" oder "verified by")
- Im Testcode: Kommentar mit Anforderungs-ID (`// Verifies: SWR-042`)
- Traceability-Report wird per Skript aus GitLab API generiert

---

*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*