ISTQB CT-AuT cheat sheet

Automotive SPICE (ASPICE) process reference model groups processes into VDA scope areas: ACQ, SPL, SYS, SWE, SUP, MAN, PIM, REU; capability levels run 0 (incomplete) to 5 (optimizing), with level 1 = performed, 2 = managed, 3 = established.

ASPICE process outcomes are the audit target: SYS.2 (system requirements analysis), SYS.3 (system architectural design), SYS.4 (system integration and integration test), SYS.5 (system qualification test) mirror SWE.1-SWE.6 for software; test coverage of requirements traceability is bidirectional (requirements to test cases and back).

ISO 26262 is a functional-safety standard for road vehicles, structured by ASIL A (lowest) to D (highest) determined from Severity (S0-S3), Exposure (E0-E4) and Controllability (C0-C3) via the risk graph; QM means quality management only, no safety-specific measures.

ISO 26262 part structure: Part 3 concept phase (item definition, HARA, functional safety concept), Part 4 system level, Part 5 hardware, Part 6 software, Part 7 production/operation, Part 8 supporting processes, Part 9 ASIL-oriented and safety-oriented analyses, Part 10 guidelines.

Verification versus validation under ISO 26262: verification confirms that the work product satisfies its specified requirements at each phase; validation at vehicle level confirms the safety goals are met in the intended context of use.

ASIL decomposition: an ASIL D safety requirement may be split into two independent requirements of ASIL B(D) and B(D), or D into C(D)+A(D), or D into D(D)+QM(D); the redundant elements must be sufficiently independent (freedom from interference, dependent failure analysis).

AUTOSAR Classic Platform uses a layered architecture: application software components (SWC) on the Virtual Function Bus, runtime environment (RTE), basic software (BSW) with services, ECU abstraction, microcontroller abstraction, and complex drivers; communication is configured, not hand-coded, via ARXML descriptions.

AUTOSAR Adaptive Platform targets high-performance ECUs with POSIX operating systems, service-oriented communication (SOME/IP), ara::com API, and dynamic update/OTA capability; Classic Platform targets hard real-time deeply embedded ECUs with static configuration.

Test relevance of the standards: ASPICE defines what test processes and work products must exist, ISO 26262 defines which test methods and coverage measures are required per ASIL, AUTOSAR defines the interfaces (RTE, service ports, diagnostic stack) at which integration tests are performed.

XiL is the umbrella term for model-in-the-loop (MIL), software-in-the-loop (SIL), hardware-in-the-loop (HIL), and vehicle-in-the-loop (VIL); each substitutes a different portion of the real system with a simulated or real component.

MIL: controller model and plant model both simulated on a PC, no target code, used for algorithm validation and early requirement checks; SIL: production C code compiled for the host PC, plant simulated, used for code-level and interface verification.

HIL: the real ECU runs against a real-time simulated plant (restbus simulation, sensor/actuator emulation, fault insertion unit); the simulator must meet hard real-time constraints of the plant model, typically 1 ms or faster step size.

VIL: a real vehicle on a test track or roller bench coupled to a simulated environment (virtual traffic, V2X, remaining scenario participants); used where full vehicle dynamics and real sensor input matter.

Fidelity trade-offs: model fidelity, sensor model accuracy (camera, radar, lidar), and bus simulation accuracy (CAN, FlexRay, Automotive Ethernet) determine which defects can be found; a model error becomes a systematic test escape.

Open-loop versus closed-loop testing: open-loop feeds predefined stimuli and checks outputs against expectations; closed-loop lets the ECU output influence the simulated plant, which is required to test control loops and diagnostics.

Restbus simulation replaces absent ECUs on the network by sending their cyclic messages with correct timing, cycle time, and signal content so the device under test does not enter a bus-off or timeout state.

Fault injection in XiL: short circuits, open loads, sensor signal out of range, CAN message loss, and corrupted checksums are injected via fault insertion units or bus manipulation to verify diagnostic reactions and safety mechanisms.

Back-to-back testing compares MIL/SIL outputs against HIL or vehicle outputs on identical stimulus traces; deviations beyond tolerance indicate model, code generation, or integration defects.

Static testing finds defects without executing code: reviews (informal, walkthrough, technical review, inspection) and static analysis (control-flow, data-flow, MISRA rule checking, metrics).

MISRA C:2012 defines mandatory, required, and advisory guidelines; deviations require a documented, justified deviation permit, and the compliance summary reports each guideline's status per module.

Control-flow analysis builds the control-flow graph and reports unreachable code, unconditional jumps, and excessive cyclomatic complexity; McCabe complexity above the project limit triggers refactoring or additional dynamic test effort.

Data-flow analysis tracks definitions and uses of variables (def-use pairs) to detect undefined-before-use, unused definitions, and dead variables; anomalies include d-u (defined, never used) and u-d (used before defined).

ISO 26262-6 requires static code analysis for all ASILs, with the recommendation strength increasing with ASIL; coding guideline checking and control/data-flow analysis are highly recommended at ASIL C and D.

AUTOSAR and interface checks in static review: verify RTE port interfaces, data type ranges and scaling, endianness, and runnable-to-task mapping consistency against the ARXML configuration.

Safety-oriented static analyses from ISO 26262-9: freedom from interference analysis, dependent failure analysis (DFA), and safety analysis (FMEA, FTA) results must be reviewed for consistency with the architecture.

Traceability review is a static technique: each requirement must map to design elements, code units, and test cases; orphan requirements and untested requirements are reported as findings.

Model static checks for model-based development: naming conventions, signal range consistency, unconnected ports, algebraic loops, and statechart dead states are detected without simulation.

ISO 26262-6 test method table by ASIL: requirements-based testing is highly recommended for all ASILs; boundary value analysis, equivalence partitioning, and error guessing increase in recommendation strength from ASIL A to D.

Structural coverage targets per ISO 26262-6: statement coverage highly recommended from ASIL B; branch coverage highly recommended from ASIL B; MC/DC highly recommended at ASIL D and recommended at C; function coverage is recommended at A and highly recommended at B and above.

Back-to-back testing of model versus code is highly recommended for ASIL C and D in ISO 26262-6; it detects code-generation and compiler defects that model-level tests cannot reveal.

Equivalence partitioning splits input ranges into classes expected to behave identically; boundary value analysis tests the edges of those classes, where off-by-one and saturation defects concentrate in signal processing code.

Fault injection testing verifies safety mechanisms and diagnostics; ISO 26262-4 requires demonstrating the effectiveness of safety mechanisms by injecting faults into hardware and software.

Robustness testing includes out-of-range sensor values, missing or delayed bus messages, voltage dips and dropouts, EMC disturbance, and watchdog triggering; results feed the safety validation argument.

Scenario-based and random testing: statistically oriented random input generation over defined operating ranges complements requirements-based tests and is used to estimate residual defect detection probability.

Regression test selection in automotive projects uses change impact analysis on requirements, models, and code to choose the smallest test set that covers affected behavior, since full HIL regression is time-expensive.

Diagnostic testing verifies UDS services (0x10 session control, 0x19 read DTC, 0x27 security access, 0x2E write data) and the correct DTC setting and healing behavior under induced faults.