3.3: Test Specification Templates

What You'll Learn

By the end of this chapter, you'll have:

• Unit test specification templates that satisfy SWE.4
• Integration test templates for SWE.5 component interaction testing
• Qualification test templates for end-to-end SWE.6 verification
• Clear coverage targets for each ASIL level

Introduction

"We test our code" is nice. "Here's the test specification with traceability to every requirement, coverage metrics, and pass/fail criteria" is what gets you CL2.

Test specifications are the bridge between requirements and verification—they prove that your code does what it's supposed to do. ASPICE demands rigorous testing at three levels: unit (SWE.4), integration (SWE.5), and qualification (SWE.6). Each level has specific expectations, and this section gives you templates that meet all of them.

Unit Test Specification Template (SWE.4)

Complete Unit Test Spec

---
title: "Unit Test Specification"
document_id: "UTS"
project: "{{PROJECT_NAME}}"
software_component: "{{COMPONENT_NAME}}"
version: "{{VERSION}}"
date: {{DATE}}
status: "Draft | Review | Approved"
asil_level: "QM | ASIL-B"
aspice_process: "SWE.4 Software Unit Verification"
coverage_target: "80% Branch | 100% MC/DC"
---

# Unit Test Specification
## {{SOFTWARE_COMPONENT_NAME}}

## 1. Introduction

### 1.1 Purpose

This document specifies the unit tests for {{COMPONENT_NAME}}, verifying
individual software units (functions/modules) against software requirements.

**ASPICE Compliance**:
- SWE.4 BP1: Develop unit verification strategy
- SWE.4 BP2: Develop unit test specifications
- SWE.4 BP3: Test software units
- SWE.4 BP4: Achieve test coverage
- SWE.4 BP5: Establish bidirectional traceability

### 1.2 Scope

**Units Under Test**:
- `DoorLock_Init()` - Initialization function
- `DoorLock_MainFunction()` - Cyclic control loop
- `DoorLock_OnDoorCommand()` - Event handler for CAN commands
- `SWC_DoorLock_UnlockDoor()` - Server operation (unlock)
- `SWC_DoorLock_LockDoor()` - Server operation (lock)

**Coverage Target**: {{COVERAGE_TARGET}}% ({{METRIC}} coverage)
- ASIL-B: 100% MC/DC required for safety functions
- QM: 80% branch coverage acceptable

### 1.3 Test Environment

| Component | Tool/Framework | Version |
|-----------|----------------|---------|
| Test Framework | Unity + CMock | 2.5.2 |
| Coverage Tool | gcov + lcov | 1.15 |
| Build System | CMake + GCC | 3.25 / 11.3 |
| Target Platform | x86_64 Linux (host-based testing) | - |
| Stub Generator | CMock | 2.5.2 |

---

## 2. Test Cases

### 2.1 Unit: `DoorLock_Init()`

#### TC-042-001: Initialization - Valid State Detection (Locked)

**Requirement Coverage**: [SWE-042] Initialization Logic

**Test Objective**:
Verify that initialization correctly identifies locked state when position sensor
reads below locked threshold.

**Preconditions**:
- None (fresh initialization)

**Test Steps**:
```c
// Given: Position sensor indicates locked position
Mock_IoHwAb_ReadAdc_ExpectAndReturn(ADC_CH_POSITION, 100);  // Below threshold

// When: Initialization is called
DoorLock_Init(DOOR_ID_FRONT_LEFT);

// Then: State should be LOCKED
TEST_ASSERT_EQUAL(DOOR_STATE_LOCKED, doorData[DOOR_ID_FRONT_LEFT].state);
TEST_ASSERT_EQUAL(0, doorData[DOOR_ID_FRONT_LEFT].operationCount);

Expected Results:

• doorData[DOOR_ID_FRONT_LEFT].state == DOOR_STATE_LOCKED
• operationCount == 0

Pass Criteria: All assertions pass.

Traceability: Verifies [SWE-042]

TC-042-002: Initialization - Valid State Detection (Unlocked)

Requirement Coverage: [SWE-042] Initialization Logic

Test Steps:

// Given: Position sensor indicates unlocked position
Mock_IoHwAb_ReadAdc_ExpectAndReturn(ADC_CH_POSITION, 900);  // Above threshold

// When: Initialization is called
DoorLock_Init(DOOR_ID_FRONT_LEFT);

// Then: State should be UNLOCKED
TEST_ASSERT_EQUAL(DOOR_STATE_UNLOCKED, doorData[DOOR_ID_FRONT_LEFT].state);

Pass Criteria: State == UNLOCKED

TC-042-003: Initialization - Fault Detection (Unknown Position)

Requirement Coverage: [SWE-042] Fault Handling

Test Steps:

// Given: Position sensor indicates intermediate position (fault)
Mock_IoHwAb_ReadAdc_ExpectAndReturn(ADC_CH_POSITION, 500);  // Mid-range

// When: Initialization is called
DoorLock_Init(DOOR_ID_FRONT_LEFT);

// Then: State should be FAULT_TIMEOUT (unknown position)
TEST_ASSERT_EQUAL(DOOR_STATE_FAULT_TIMEOUT, doorData[DOOR_ID_FRONT_LEFT].state);

Pass Criteria: State == FAULT_TIMEOUT

2.2 Unit: SWC_DoorLock_UnlockDoor()

TC-043-001: Unlock - Normal Operation (Speed OK)

Requirement Coverage: [SWE-043] Unlock Logic

Test Objective: Verify unlock operation succeeds when vehicle speed is within safe limits.

Preconditions:

• Door in LOCKED state
• Vehicle speed <= 5.0 km/h

Test Steps:

void test_UnlockDoor_NormalOperation(void) {
    // Setup: Door is locked, speed is safe
    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_LOCKED;

    VehicleSpeedType speedData = {
        .speed_kmh = 2.5f,
        .signalValid = true
    };

    // Mock RTE call to read speed
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ExpectAnyArgsAndReturn(E_OK);
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ReturnThruPtr_data(&speedData);

    // Mock GPIO and PWM calls
    Rte_Call_DoorLockCtrl_R_IoControl_SetGpio_ExpectAndReturn(
        GPIO_DIR_PIN, UNLOCK_DIR, E_OK
    );
    Rte_Call_DoorLockCtrl_R_IoControl_SetPwm_ExpectAndReturn(
        PWM_CH_MOTOR, 80, E_OK
    );

    // Mock system time
    Mock_GetSystemTime_ms_ExpectAndReturn(1000);

    // When: Unlock command is issued
    Std_ReturnType result = SWC_DoorLock_UnlockDoor(DOOR_ID_FRONT_LEFT + 1);

    // Then: Operation succeeds
    TEST_ASSERT_EQUAL(E_OK, result);
    TEST_ASSERT_EQUAL(DOOR_STATE_UNLOCKING, doorData[DOOR_ID_FRONT_LEFT].state);
    TEST_ASSERT_EQUAL(1000, doorData[DOOR_ID_FRONT_LEFT].stateEntryTime_ms);
}

Expected Results:

• Return value: E_OK
• State transitions to DOOR_STATE_UNLOCKING
• PWM output activated with 80% duty cycle
• State entry time recorded

Pass Criteria: All assertions pass

Coverage: This test covers:

• Happy path (speed check pass)
• State transition logic
• RTE interface usage
• GPIO/PWM control

TC-043-002: Unlock - Rejected Due to High Speed

Requirement Coverage: [SWE-043] Safety Interlock, [SWE-045] Speed Check

Test Objective: Verify unlock operation is rejected when vehicle speed exceeds safety threshold.

Preconditions:

• Door in LOCKED state
• Vehicle speed > 5.0 km/h (safety limit)

Test Steps:

void test_UnlockDoor_RejectedHighSpeed(void) {
    // Setup: Door is locked, but speed is too high
    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_LOCKED;

    VehicleSpeedType speedData = {
        .speed_kmh = 15.0f,  // Above 5.0 km/h threshold
        .signalValid = true
    };

    // Mock speed read
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ExpectAnyArgsAndReturn(E_OK);
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ReturnThruPtr_data(&speedData);

    // When: Unlock attempted
    Std_ReturnType result = SWC_DoorLock_UnlockDoor(DOOR_ID_FRONT_LEFT + 1);

    // Then: Operation rejected
    TEST_ASSERT_EQUAL(E_NOT_OK, result);
    TEST_ASSERT_EQUAL(DOOR_STATE_LOCKED, doorData[DOOR_ID_FRONT_LEFT].state);
    // State must NOT change
}

Expected Results:

• Return value: E_NOT_OK
• State remains DOOR_STATE_LOCKED (no change)
• PWM NOT activated (verified by absence of mock expectations)

Pass Criteria: All assertions pass

Safety Relevance: ASIL-B critical test (safety interlock verification)

TC-043-003: Unlock - Already Unlocked (Idempotency)

Requirement Coverage: [SWE-043] Idempotency

Test Steps:

void test_UnlockDoor_AlreadyUnlocked(void) {
    // Setup: Door already unlocked
    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_UNLOCKED;

    VehicleSpeedType speedData = {.speed_kmh = 0.0f, .signalValid = true};
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ExpectAnyArgsAndReturn(E_OK);
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ReturnThruPtr_data(&speedData);

    // When: Unlock called again
    Std_ReturnType result = SWC_DoorLock_UnlockDoor(DOOR_ID_FRONT_LEFT + 1);

    // Then: Returns OK (idempotent), but no action taken
    TEST_ASSERT_EQUAL(E_OK, result);
    TEST_ASSERT_EQUAL(DOOR_STATE_UNLOCKED, doorData[DOOR_ID_FRONT_LEFT].state);
    // No PWM activation (verified by no mock expectations set)
}

Pass Criteria: Returns E_OK without side effects

TC-043-004: Unlock - System in Fault State

Requirement Coverage: [SWE-043] Fault Handling

Test Steps:

void test_UnlockDoor_FaultState(void) {
    // Setup: System in fault
    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_FAULT_TIMEOUT;

    // When: Unlock attempted
    Std_ReturnType result = SWC_DoorLock_UnlockDoor(DOOR_ID_FRONT_LEFT + 1);

    // Then: Operation rejected
    TEST_ASSERT_EQUAL(E_NOT_OK, result);
    TEST_ASSERT_EQUAL(DOOR_STATE_FAULT_TIMEOUT, doorData[DOOR_ID_FRONT_LEFT].state);
}

Pass Criteria: Rejected when in fault state

2.3 Unit: DoorLock_ProcessStateMachine()

TC-044-001: State Machine - Unlock Completion Detection

Requirement Coverage: [SWE-043] State Machine Logic

Test Steps:

void test_StateMachine_UnlockCompletion(void) {
    // Setup: Door in UNLOCKING state
    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_UNLOCKING;
    doorData[DOOR_ID_FRONT_LEFT].operationCount = 10;

    // Mock PWM stop call
    Rte_Call_DoorLockCtrl_R_IoControl_SetPwm_ExpectAndReturn(
        PWM_CH_MOTOR, 0, E_OK  // 0% duty = stop
    );

    // When: Position sensor indicates unlock complete
    uint16 unlockedPosition = 950;  // Above POSITION_THRESHOLD_UNLOCKED
    DoorLock_ProcessStateMachine(DOOR_ID_FRONT_LEFT, unlockedPosition);

    // Then: State transitions to UNLOCKED
    TEST_ASSERT_EQUAL(DOOR_STATE_UNLOCKED, doorData[DOOR_ID_FRONT_LEFT].state);
    TEST_ASSERT_EQUAL(11, doorData[DOOR_ID_FRONT_LEFT].operationCount);
    // Operation counter incremented
}

Pass Criteria:

• State transitions to UNLOCKED
• PWM stopped
• Operation counter incremented

TC-044-002: State Machine - Timeout Detection

Requirement Coverage: [SWE-043] Timeout Handling

Test Steps:

void test_StateMachine_TimeoutFault(void) {
    // Setup: Door unlocking, but timeout expires
    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_UNLOCKING;
    doorData[DOOR_ID_FRONT_LEFT].stateEntryTime_ms = 1000;
    doorData[DOOR_ID_FRONT_LEFT].operationTimeout = true;  // Timeout detected

    // Mock PWM stop
    Rte_Call_DoorLockCtrl_R_IoControl_SetPwm_ExpectAndReturn(PWM_CH_MOTOR, 0, E_OK);

    // Mock DEM event reporting
    Rte_Call_DoorLockCtrl_R_DiagMgr_SetEventStatus_ExpectAndReturn(
        DEM_EVENT_DOOR_LOCK_FAULT, DEM_EVENT_STATUS_FAILED, E_OK
    );

    // When: Timeout check is performed
    DoorLock_CheckTimeout(DOOR_ID_FRONT_LEFT);

    // Then: State transitions to FAULT
    TEST_ASSERT_EQUAL(DOOR_STATE_FAULT_TIMEOUT, doorData[DOOR_ID_FRONT_LEFT].state);
}

Pass Criteria:

• Fault state entered
• Diagnostic event reported

2.4 Unit: DoorLock_OnDoorCommand()

TC-045-001: CAN Command - Checksum Validation Pass

Requirement Coverage: [SWE-042] CAN Message Validation

Test Steps:

void test_OnDoorCommand_ValidChecksum(void) {
    DoorCommandType validCmd = {
        .command = CMD_UNLOCK,
        .targetDoorID = DOOR_ID_FRONT_LEFT + 1,
        .messageCounter = 5,
        .checksum = 0x3F  // Pre-calculated valid CRC-8
    };

    // Setup door in locked state, speed OK
    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_LOCKED;
    VehicleSpeedType speed = {.speed_kmh = 0.0f, .signalValid = true};

    // Mock expectations for successful unlock
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ExpectAnyArgsAndReturn(E_OK);
    Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed_ReturnThruPtr_data(&speed);
    Rte_Call_DoorLockCtrl_R_IoControl_SetGpio_ExpectAnyArgsAndReturn(E_OK);
    Rte_Call_DoorLockCtrl_R_IoControl_SetPwm_ExpectAnyArgsAndReturn(E_OK);
    Mock_GetSystemTime_ms_ExpectAndReturn(2000);

    // When: Valid command received
    DoorLock_OnDoorCommand(&validCmd);

    // Then: Command processed (unlock initiated)
    TEST_ASSERT_EQUAL(DOOR_STATE_UNLOCKING, doorData[DOOR_ID_FRONT_LEFT].state);
}

Pass Criteria: Valid command triggers unlock

TC-045-002: CAN Command - Checksum Validation Fail

Requirement Coverage: [SWE-042] CAN Security

Test Steps:

void test_OnDoorCommand_InvalidChecksum(void) {
    DoorCommandType invalidCmd = {
        .command = CMD_UNLOCK,
        .targetDoorID = DOOR_ID_FRONT_LEFT + 1,
        .messageCounter = 5,
        .checksum = 0xFF  // Incorrect checksum
    };

    doorData[DOOR_ID_FRONT_LEFT].state = DOOR_STATE_LOCKED;
    uint32 errorCountBefore = canChecksumErrorCount;

    // When: Invalid command received
    DoorLock_OnDoorCommand(&invalidCmd);

    // Then: Command rejected, error counted
    TEST_ASSERT_EQUAL(DOOR_STATE_LOCKED, doorData[DOOR_ID_FRONT_LEFT].state);
    TEST_ASSERT_EQUAL(errorCountBefore + 1, canChecksumErrorCount);
}

Pass Criteria: Invalid checksum rejected, error counted

Safety Relevance: ASIL-B (prevents corrupted commands)

3. Coverage Analysis

3.1 Coverage Requirements by ASIL

3.2 Per-Unit Coverage

Coverage Report: See coverage_html/index.html (generated by lcov)

4. Traceability Matrix

5. Test Execution

5.1 Test Execution Procedure

#!/bin/bash
# run_unit_tests.sh

# Clean previous results
rm -rf build_test coverage_html

# Configure for testing
cmake -B build_test \
      -DCMAKE_BUILD_TYPE=Debug \
      -DENABLE_COVERAGE=ON \
      -DENABLE_UNIT_TESTS=ON

# Build tests
cmake --build build_test --target all

# Run all unit tests
cd build_test
ctest --output-on-failure --verbose

# Generate coverage report
lcov --capture --directory . --output-file coverage.info
lcov --remove coverage.info '/usr/*' '*/tests/*' --output-file coverage_filtered.info
genhtml coverage_filtered.info --output-directory ../coverage_html

# Check coverage threshold
COVERAGE=$(lcov --summary coverage_filtered.info | grep lines | awk '{print $2}' | sed 's/%//')
echo "Coverage: $COVERAGE%"

if (( $(echo "$COVERAGE < 80" | bc -l) )); then
    echo "ERROR: Coverage $COVERAGE% below 80% threshold"
    exit 1
fi

echo "[PASS] All unit tests passed with $COVERAGE% coverage"

5.2 Continuous Integration

# .github/workflows/unit-tests.yml
unit-tests:
  name: Unit Tests (SWE.4)
  runs-on: ubuntu-latest

  steps:
    - uses: actions/checkout@v4

    - name: Install dependencies
      run: |
        sudo apt-get update
        sudo apt-get install -y lcov ruby
        gem install ceedling

    - name: Run unit tests
      run: |
        bash run_unit_tests.sh

    - name: Upload coverage to Codecov
      uses: codecov/codecov-action@v3
      with:
        files: ./build_test/coverage_filtered.info

    - name: Upload test report
      uses: actions/upload-artifact@v3
      with:
        name: unit-test-coverage
        path: coverage_html/

6. Approval

---

## Integration Test Specification Template (SWE.5)

### Complete Integration Test Spec

```markdown
---
title: "Software Integration Test Specification"
document_id: "ITS"
project: "{{PROJECT_NAME}}"
software_system: "{{SYSTEM_NAME}}"
version: "{{VERSION}}"
date: {{DATE}}
status: "Draft | Review | Approved"
asil_level: "ASIL-B"
aspice_process: "SWE.5 Software Integration Test"
---

# Software Integration Test Specification
## {{SOFTWARE_SYSTEM_NAME}}

## 1. Introduction

### 1.1 Purpose

This document specifies integration tests verifying interactions between
software components (SWCs) and BSW modules.

**ASPICE Compliance**: SWE.5 BP1-5

### 1.2 Scope

**Components Under Test**:
- DoorLockCtrl_SWC ↔ SpeedMonitor_SWC (inter-SWC communication)
- DoorLockCtrl_SWC ↔ COM module (CAN transmission)
- DoorLockCtrl_SWC ↔ IoHwAb (hardware abstraction)

**Test Level**: Software Integration (SWC-to-SWC and SWC-to-BSW)

**Not in Scope**: System integration with hardware (covered by SYS.4)

---

## 2. Integration Test Cases

### 2.1 SWC-to-SWC Integration

#### TC-INT-001: Door Unlock Triggered by Speed Monitor Auto-Lock Event

**Requirements Coverage**: [SWE-043], [SWE-044]

**Test Objective**:
Verify that SpeedMonitor_SWC correctly triggers auto-lock in DoorLockCtrl_SWC
when vehicle speed crosses threshold.

**Test Architecture**:

SpeedMonitor_SWC --[RTE: AutoLockTrigger]--> DoorLockCtrl_SWC

**Preconditions**:
- Both SWCs initialized
- Door in UNLOCKED state
- Vehicle speed starts at 0 km/h

**Test Steps**:
1. Set vehicle speed to 5.0 km/h (below threshold)
   - Expected: No auto-lock trigger
2. Increase speed to 12.0 km/h (above 10 km/h threshold)
   - Expected: SpeedMonitor sets AutoLockTrigger = true
3. DoorLockCtrl reads trigger via RTE
   - Expected: Initiates lock operation for all doors
4. Monitor door state
   - Expected: All doors transition to LOCKING state

**Expected Results**:
- Auto-lock triggered within 200ms of speed threshold crossing
- All 4 doors begin lock operation
- CAN status message broadcast: `DoorStatus_ECU.AutoLockActive = true`

**Pass Criteria**:
- Timing: Auto-lock starts within 200ms ± 20ms
- All doors: State == LOCKING
- CAN message sent

**Test Tool**: HIL simulator with CAN injection

---

### 2.2 SWC-to-BSW Integration

#### TC-INT-002: CAN Message Reception Path (COM → DoorLockCtrl)

**Requirements Coverage**: [SWE-042]

**Test Objective**:
Verify end-to-end CAN message flow from physical bus to application SWC.

**Test Architecture**:

CAN Bus (Hardware) → CAN Driver → CanIf → COM → RTE → DoorLockCtrl_SWC

**Test Steps**:
1. Inject CAN message `DoorCmd_BCM` (ID: 0x320) on physical CAN bus:

ID: 0x320 Data: [0x01, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3F] │ │ └── Checksum │ └── DoorID = 0x02 (Front Right) └── DoorUnlockReq = 0x01 (Unlock)

2. Monitor RTE buffer
- Expected: `DoorCmd` signal available in RTE within 10ms
3. Monitor DoorLockCtrl behavior
- Expected: `DoorLock_OnDoorCommand()` invoked
4. Monitor PWM output (GPIO observation)
- Expected: PWM activated for Front Right door

**Expected Results**:
- CAN→RTE latency: < 10ms
- Unlock operation initiated
- PWM signal measurable on oscilloscope

**Pass Criteria**:
- End-to-end latency < 20ms
- Correct door actuated (FR, not FL)

**Test Tool**: CANoe + HIL test bench

---

## 3. Test Execution Report Template

After test execution, document results:

```markdown
## Test Execution Report

**Test Session**: ITS-2025-12-17-001
**Date**: 2025-12-17
**Tester**: {{TESTER_NAME}}
**Environment**: HIL Test Bench #2

| Test Case ID | Result | Actual vs Expected | Deviations | Notes |
|--------------|--------|-------------------|------------|-------|
| TC-INT-001 | [PASS] PASS | Auto-lock at 185ms (expected <200ms) | None | - |
| TC-INT-002 | [PASS] PASS | Latency 8ms (expected <20ms) | None | - |
| TC-INT-003 | [FAIL] FAIL | Timeout at 1200ms | Exceeded 1000ms | Bug #42 |

**Overall Status**: 2 PASS, 1 FAIL

**Issues**:
- BUG-042: Timeout detection too slow (1200ms vs 1000ms spec)
- Assigned to: Developer X
- Severity: Medium
- Target fix: 2025-12-20

---

## Qualification Test Specification Template (SWE.6)

### Complete Qualification Test Spec

```markdown
---
title: "Software Qualification Test Specification"
document_id: "QTS"
project: "{{PROJECT_NAME}}"
version: "{{VERSION}}"
date: {{DATE}}
status: "Draft | Review | Approved"
aspice_process: "SWE.6 Software Qualification Test"
---

# Software Qualification Test Specification

## 1. Introduction

### 1.1 Purpose

Black-box testing of complete software system against software requirements.

**ASPICE Compliance**: SWE.6 BP1-5

### 1.2 Scope

**System Under Test**: Complete Door Lock ECU software (all SWCs + BSW)
**Test Environment**: Target hardware (STM32F407) + vehicle network simulator

---

## 2. Qualification Test Cases

### 2.1 Functional Qualification

#### TC-QUAL-001: Remote Unlock End-to-End Scenario

**Requirements Coverage**: [SWE-042], [SWE-043], [SYS-REQ-001]

**Test Objective**:
Verify complete remote unlock use case from user action to door movement.

**Test Setup**:
- Door Lock ECU flashed with release software
- Connected to CAN network simulator
- Door actuator connected (real hardware or mock load)
- Vehicle speed simulated at 0 km/h

**Test Procedure**:
1. Simulate user pressing unlock button on key fob
   - BCM broadcasts `DoorCmd_BCM` (Unlock, DoorID=All)
2. Observe ECU behavior:
   - CAN message received
   - All door PWM outputs activated
   - Position sensors monitored
3. Wait for unlock completion
4. Verify status message sent

**Expected Results**:
- All doors unlock within 500ms ± 50ms
- Status message `DoorStatus_ECU` indicates UNLOCKED
- No diagnostic trouble codes (DTCs) set

**Acceptance Criteria**:
- Unlock time: 450-550ms
- All 4 doors reach UNLOCKED position
- No faults

**Test Evidence**: Video recording + CAN trace log

---

#### TC-QUAL-002: Safety Interlock - No Unlock at High Speed

**Requirements Coverage**: [SWE-043], [SWE-045], [SYS-REQ-002]

**Test Setup**:
- Vehicle speed simulated at 30 km/h (above 5 km/h limit)
- Door in LOCKED state

**Test Procedure**:
1. Simulate unlock command via CAN
2. Observe ECU response

**Expected Results**:
- Unlock request REJECTED
- Door remains LOCKED
- No PWM activation
- Optional: Status message indicates rejection reason

**Acceptance Criteria**:
- Door position unchanged
- PWM duty cycle remains 0%

**Safety Relevance**: ASIL-B critical safety function

---

## 3. Performance Qualification

#### TC-QUAL-010: Response Time Under Load

**Requirements Coverage**: [SWE-060] Performance

**Test Objective**:
Verify ECU responds within timing constraints under full CAN bus load.

**Test Setup**:
- CAN bus loaded to 70% utilization (background traffic)
- Door commands injected at 100ms intervals

**Acceptance Criteria**:
- 95th percentile response time < 100ms
- No missed commands

---

## 4. Robustness Qualification

#### TC-QUAL-020: CAN Bus-Off Recovery

**Requirements Coverage**: [SWE-042] Fault Tolerance

**Test Procedure**:
1. Induce CAN bus-off condition (error frame injection)
2. Monitor ECU behavior
3. Restore bus
4. Verify ECU recovers and resumes operation

**Acceptance Criteria**:
- ECU re-initializes CAN within 500ms
- Normal operation resumes
- DTC stored (CAN bus-off event)

---

## 5. Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Test Lead | {{NAME}} | ______ | __________ |
| Software Architect | {{NAME}} | ______ | __________ |
| Quality Manager | {{NAME}} | ______ | __________ |

Summary

Test Specification Templates for ASPICE Compliance:

• Unit Tests (SWE.4): Function-level white-box testing with mocks
• Integration Tests (SWE.5): SWC-to-SWC and SWC-to-BSW interaction testing
• Qualification Tests (SWE.6): End-to-end black-box system testing
• Coverage Targets: 80% branch (QM), 100% MC/DC (ASIL-B+)
• Traceability: Every test traces to requirements

Key Features:

1. Structured Format: Given/When/Then test steps
2. Safety Emphasis: ASIL-level specific coverage requirements
3. Automation-Ready: CI/CD integration with quality gates
4. Bidirectional Traceability: Tests → Requirements → Code