Stefan Lohmaier
6e458ae76f
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
122 lines
4.9 KiB
Markdown
122 lines
4.9 KiB
Markdown
# 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.*
|