Stefan Lohmaier
1855162e6d
Vollstaendige Demo des slohmaier Dev Process anhand einer EPB-Steuergeraet- Software. Zeigt ASPICE 4.0 / ISO 26262-konforme Entwicklung im Monorepo. Inhalte: - 5 Plaene (PID, PM-, QA-, SWE-, Test-Plan) in Word, ausgefuellt mit EPB-spezifischen Inhalten - 10 System-Anforderungen + 25 Software-Anforderungen (Doorstop-MD) - 5 System-Architektur-Elemente + 10 Software-Architektur-Elemente mit PlantUML-Diagrammen und vollstaendigem Mapping - 3 implementierte Komponenten (Apply Controller D, Actuator Driver B, Switch Debouncer QM) plus 7 Header-Stubs - 28 Unit-Tests, alle gruen, mit Coverage- und MISRA-Build-Targets - Audit-Artefakte: 1 Review-Protokoll, 1 Non-Conformity, 1 MISRA-Record - Gitea-Actions-CI-Pipeline (validate.yml) - Doorstop-Konfiguration fuer bidirektionale Traceability - Generator-Skript fuer alle 50 Reqs/Arch-Elemente aus Strukturdaten - README mit gefuehrter Tour fuer Prospects
64 lines
2.4 KiB
Markdown
64 lines
2.4 KiB
Markdown
# 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/`
|