Stefan Lohmaier
8ea3f3d8f4
The 25 files under templates-de/ lived in ~/ownCloud/Persönlich/slohmaier.com/vorlagen/
with no version control. They are the German-language counterpart of the
templates renamed to English in 247b831 — this repo already describes itself as
holding the ASPICE 4.0 / ISO 26262 methodology, templates and tools, so a
second home for templates would have been a duplicate.
Structure preserved as found (business/, engineering/, projekt/, qualitaet/).
No file renamed, no template content changed.
Not moved: vorlagen/slohmaier-doc-template.docx was byte-identical (MD5
31b2d0748eadf0314babf469725ee0b1) to templates-word/slohmaier-doc-template.docx
already in this repo.
Path references fixed in templates-de/README.md, which pointed at locations
that no longer exist: the ownCloud cp examples now clone from Gitea, the
generator script name follows the vorlagen/ -> templates/ rename
(generate_word_vorlagen.sh -> generate_word_templates.sh), the edit workflow
names templates/ and templates-de/ instead of the removed ownCloud copy, and
the master template is referenced at ../templates-word/.
4.9 KiB
4.9 KiB
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.