feat(i18n): dev-process repo in English
- README.md: full English rewrite - All 13 vorlagen MD templates hand-translated: PID, PM-Plan, QA-Plan, SWE-Plan, Test-Plan, SA, SWA, Review-Protokoll, Non-Conformity, MISRA-Deviation-Permit, MISRA-Deviation-Record, Traceability-Matrix, angebot (quotation) - Master Word template (slohmaier-doc-template.docx) regenerated in English: cover page, document control, TOC headers, classification banner all English - All derived Word vorlagen regenerated from English MD sources Still to translate: toolstack.md, gitea-aspice-setup.md
This commit is contained in:
Stefan Lohmaier
@@ -1,121 +1,69 @@
|
||||
# Testplan
|
||||
# Test Plan
|
||||
|
||||
| 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] |
|
||||
| Field | Value |
|
||||
|-----------------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Testziele
|
||||
## 1. Test strategy
|
||||
|
||||
- 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
|
||||
[Describe the approach: e.g. test-first, requirement-based, risk-based.]
|
||||
|
||||
## 2. Teststrategie
|
||||
Each requirement has at least one test (`@reqs` tag in the test). Coverage targets as in the SWE Plan section 8.
|
||||
|
||||
| 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 |
|
||||
## 2. Test levels
|
||||
|
||||
### Unit Tests
|
||||
| Level | Scope | Tool | Environment | Status |
|
||||
|---------------|----------------------|------------|-------------|---------------|
|
||||
| Unit | Functions / modules | [CppUTest] | host x86 | [planned] |
|
||||
| Integration | Module interaction | [CppUTest] | host / SiL | [planned] |
|
||||
| System | End-to-end | [manual] | SiL / HiL | [planned] |
|
||||
| Acceptance | Client acceptance | [manual] | HiL / vehicle | [planned] |
|
||||
|
||||
- Framework: [CppUTest / Google Test / Unity+CMock]
|
||||
- Laufen auf Host-Plattform (x86)
|
||||
- Jede Anforderung hat mindestens einen zugehoerigen Testfall
|
||||
- Negative Tests und Grenzwerte sind Pflicht
|
||||
## 3. Test management
|
||||
|
||||
### Integrationstests
|
||||
- Tests live in `tests/unit/`, `tests/integration/`, ...
|
||||
- Each test file carries `@reqs` tags pointing to the covered requirements
|
||||
- Tests run automatically in CI on every push
|
||||
- Coverage report is published as a CI artefact
|
||||
|
||||
- Pruefen Schnittstellen zwischen Modulen
|
||||
- Laufen auf Host oder SiL-Umgebung
|
||||
- Kommunikationsschnittstellen (CAN, SPI, UART) werden per Mock oder Simulator getestet
|
||||
## 4. Test selection per component
|
||||
|
||||
### System-Tests
|
||||
| Component | ASIL | Test file | Method |
|
||||
|--------------------|------|----------------------------------|---------------------------------|
|
||||
| [Component A] | [D] | tests/unit/test_componentA.c | Equivalence classes + boundary + MC/DC |
|
||||
| [Component B] | [B] | tests/unit/test_componentB.c | Equivalence classes + boundary |
|
||||
| [Component C] | [QM] | tests/unit/test_componentC.c | Equivalence classes |
|
||||
|
||||
- Pruefen gegen System-Anforderungen
|
||||
- Laufen auf SiL oder HiL
|
||||
- Testfaelle werden aus System-Requirements abgeleitet
|
||||
## 5. Entry and exit criteria
|
||||
|
||||
## 3. Coverage-Ziele
|
||||
**Entry to test execution:**
|
||||
- Code compiles
|
||||
- Doorstop check is green
|
||||
- Static analysis has no critical findings
|
||||
|
||||
| Metrik | Zielwert | Messung |
|
||||
|---------------------|----------------|------------------|
|
||||
| Statement Coverage | >= [X]% | gcov/lcov |
|
||||
| Branch Coverage | >= [X]% | gcov/lcov |
|
||||
| MC/DC | >= [X]% (falls anwendbar) | MCDC-Star / kommerziell |
|
||||
**Exit:**
|
||||
- All tests green
|
||||
- Coverage target reached
|
||||
- Test report archived
|
||||
|
||||
Referenz: ISO 26262 Part 6, Table 9.
|
||||
## 6. Defect handling
|
||||
|
||||
| ASIL | Statement | Branch | MC/DC |
|
||||
|------|-----------|---------|--------------|
|
||||
| QM | empfohlen | — | — |
|
||||
| A | Pflicht | empfohlen | — |
|
||||
| B | Pflicht | Pflicht | — |
|
||||
| C | Pflicht | Pflicht | empfohlen |
|
||||
| D | Pflicht | Pflicht | Pflicht |
|
||||
- Test failure = blocking issue
|
||||
- Issue raised via Gitea Issues, referenced in the PR
|
||||
- Severity classification per QA Plan section 4
|
||||
|
||||
## 4. Testumgebung
|
||||
## 7. Reporting
|
||||
|
||||
| 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
|
||||
Test reports are generated automatically:
|
||||
- Console output of the test framework (TAP / JUnit XML)
|
||||
- Coverage HTML from lcov
|
||||
- Both as CI artefacts under `tests/results/`
|
||||
|
||||
---
|
||||
|
||||
*Aenderungen an diesem Plan werden im GitLab-Wiki versioniert.*
|
||||
*Changes to this plan are versioned in the Gitea wiki.*
|
||||
|
||||
Reference in New Issue
Block a user