Files

T

Stefan Lohmaier 6e458ae76f Initial commit: slohmaier Dev Process v1.0

ASPICE 4.0 / ISO 26262 Entwicklungsprozess fuer kleine Teams.

Inhalte:
- README mit hybrider Format-Strategie (Word + Markdown)
- Toolstack (Gitea, Doorstop, Cppcheck, gcov, CppUTest, pandoc)
- Markdown-Vorlagen fuer Requirements + Architektur (SA, SWA)
- Markdown-Vorlagen fuer formelle Dokumente (PID, PM-Plan, QA-Plan,
  SWE-Plan, Test-Plan, Reviews, Non-Conformity, MISRA Permits/Records)
- Word-Master-Template (slohmaier-doc-template.docx) mit ISO-9001-
  konformer Document Control, Formatvorlagen, Auto-Verzeichnissen
- Build-Scripts (build_word_template.py, generate_word_vorlagen.sh)
- gitea-aspice-setup.md, V-Modell-Infografik

2026-05-11 13:40:51 -07:00

4.9 KiB

Raw Blame History

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.

4.9 KiB Raw Blame History