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
This commit is contained in:
Stefan Lohmaier
@@ -0,0 +1,121 @@
|
||||
# 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.*
|
||||
Reference in New Issue
Block a user