Stefan Lohmaier
fb2c083551
Validate / build-test (macos-latest) (push) Failing after 3s
Validate / build-test (windows-latest) (push) Failing after 15s
Validate / build-test (ubuntu-latest) (push) Successful in 17s
Validate / reports (push) Successful in 50s
Release / release (push) Successful in 50s
Phase 2 of the English translation: Word documents (filled, EPB-specific): - 8 plans (PID, PM, QA, SWE, Test, Project Manual, CM, RM) - 6 safety docs (HARA, Safety Case, FMEDA, MISRA Compliance, Verification Report, Tool Qualification Cppcheck) - 2 manuals (User, Service) - 3 audit artefacts (Review minutes, NC-001, MISRA-REC-001) - All regenerated via pandoc from English markdown sources Code, tests, headers: - All file headers, struct comments, function docstrings in English - All test names (TEST_BEGIN strings) translated - Inline comments translated - 46 tests still green after translation CI workflows: - All step names in English - Step descriptions, comments, release notes template in English README.md fully rewritten in English with proper guided tour. Phase 3 (still pending): dev-process repo templates + toolstack/setup docs.
2.4 KiB
2.4 KiB
Test Plan
| Field | Value |
|---|---|
| Project | demo-epb |
| Date | 2026-05-11 |
| Version | 1.0 |
| Status | Released |
1. Test strategy
Test-first for all demo components. Every 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 | Demo status |
|---|---|---|---|---|
| Unit | Functions / modules | CppUTest | host x86 | Available |
| Integration | Module interaction | CppUTest | host x86 | TBD |
| System | End-to-end | manual | SiL / HiL | not in demo |
| Acceptance | Customer acceptance | manual | HiL / vehicle | not in demo |
3. Test management
- Tests live in
tests/unit/(one file per module) - Each test file carries an
@reqstag with the covered requirement IDs - Tests run automatically in CI on every push
- Coverage report is uploaded as a CI artefact under
tests/results/coverage/
4. Test selection per component
| Component | ASIL | Test file | Method |
|---|---|---|---|
| Apply Controller | D | tests/unit/test_apply_controller.c | Equivalence classes + boundary + MC/DC |
| Actuator Driver | B | tests/unit/test_actuator_driver.c | Equivalence classes + boundary |
| Switch Debouncer | QM | tests/unit/test_switch_debouncer.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 is filed via Gitea Issues, referenced in the PR
- Severity classification per QA Plan section 4
7. Reporting
Test reports are generated automatically:
- Console output of CppUTest (TAP / JUnit XML)
- Coverage HTML from lcov
- Both as CI artefacts under
tests/results/