Files

T

Stefan Lohmaier 247b8311f3 refactor(i18n): rename vorlagen/ -> templates/, *-vorlage -> *-template

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.

2026-05-12 12:09:06 -07:00

2.4 KiB

Raw Blame History

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.

2.4 KiB Raw Blame History