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.
64 lines
2.4 KiB
Markdown
64 lines
2.4 KiB
Markdown
# 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 `@reqs` tag 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/`
|