Stefan Lohmaier
247b8311f3
Final German naming cleanup in dev-process: - vorlagen/ -> templates/ - vorlagen-word/ -> templates-word/ - tools/generate_word_vorlagen.sh -> tools/generate_word_templates.sh - *-vorlage.md / *-vorlage.docx -> *-template.md / *-template.docx - Review-Protokoll-vorlage.* -> Review-Minutes-template.* - angebot-vorlage.* -> quote-template.* - angebot-beispiel.html -> quote-example.html All references in README.md, toolstack/toolstack.md, build_word_template.py, and generate_word_templates.sh updated. The master Word style template (slohmaier-doc-template.docx) was already English-named. The dev-process repo is now fully English in both content and structure.
70 lines
2.4 KiB
Markdown
70 lines
2.4 KiB
Markdown
# Test Plan
|
|
|
|
| Field | Value |
|
|
|-----------------|--------------------------------|
|
|
| Project | [Project name] |
|
|
| Date | [YYYY-MM-DD] |
|
|
| Version | [1.0] |
|
|
| Status | [Draft / Released] |
|
|
|
|
---
|
|
|
|
## 1. Test strategy
|
|
|
|
[Describe the approach: e.g. test-first, requirement-based, risk-based.]
|
|
|
|
Each requirement has at least one test (`@reqs` tag in the test). Coverage targets as in the SWE Plan section 8.
|
|
|
|
## 2. Test levels
|
|
|
|
| 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] |
|
|
|
|
## 3. Test management
|
|
|
|
- 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
|
|
|
|
## 4. Test selection per component
|
|
|
|
| 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 |
|
|
|
|
## 5. Entry and exit criteria
|
|
|
|
**Entry to test execution:**
|
|
- Code compiles
|
|
- Doorstop check is green
|
|
- Static analysis has no critical findings
|
|
|
|
**Exit:**
|
|
- All tests green
|
|
- Coverage target reached
|
|
- Test report archived
|
|
|
|
## 6. Defect handling
|
|
|
|
- Test failure = blocking issue
|
|
- Issue raised via Gitea Issues, referenced in the PR
|
|
- Severity classification per QA Plan section 4
|
|
|
|
## 7. Reporting
|
|
|
|
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/`
|
|
|
|
---
|
|
|
|
*Changes to this plan are versioned in the Gitea wiki.*
|