ISTQB CT-AuT flashcards

31 cards. Read the term and the definition here. The deck at the top of this page is optional.

ASPICE capability level 2

A managed process: the process is performed and planned, monitored, and adjusted; work products are controlled and reviewed. Level 2 requires process performance management and work product management, beyond merely achieving the outcomes at level 1.

ASPICE SYS.5 purpose

System qualification testing: verify that the integrated system satisfies the system requirements and is ready for delivery. Work products include the system qualification test strategy, test cases, test results, and bidirectional traceability to system requirements.

ASIL determination inputs

Severity (S0-S3), Exposure (E0-E4) and Controllability (C0-C3) are combined in the ISO 26262 risk graph. S3+E4+C3 yields ASIL D; low combinations yield ASIL A or QM, meaning no safety-specific measures are required.

ASIL decomposition rule

A safety requirement may be split across sufficiently independent redundant elements, e.g. ASIL D into C(D)+A(D) or B(D)+B(D). Independence must be shown by dependent failure analysis and freedom-from-interference evidence.

Functional safety concept

ISO 26262-3 work product that allocates safety goals to functional safety requirements and assigns them to architectural elements, including safe states, fault tolerant time intervals, and warning and degradation concepts.

AUTOSAR RTE role

The runtime environment sits between application software components and basic software. It implements the configured communication between components and to BSW services, and maps runnables to operating system tasks.

AUTOSAR Classic versus Adaptive

Classic is statically configured, hard real-time, signal-based, and targeted at deeply embedded ECUs. Adaptive uses POSIX, service-oriented SOME/IP communication, and dynamic software update on high-performance ECUs.

Verification versus validation

Verification asks whether the work product was built right, i.e. conforms to its specified requirements at each development phase. Validation asks whether the right product was built, i.e. safety goals are met in the vehicle context.

Hardware-in-the-loop definition

Testing with the real ECU connected to a real-time simulated plant, including sensor and actuator emulation and restbus simulation. It enables reproducible, automated testing of rare and dangerous operating conditions without a real vehicle.

Software-in-the-loop definition

The production C code is compiled for a host PC and executed against a simulated plant, without target hardware. It allows early code-level and interface testing and fast regression, but not real-time timing verification.

Model-in-the-loop definition

Controller and plant are both models executed on a PC, with no target code involved. MIL supports early validation of control algorithms and requirements before implementation exists, at the lowest fidelity of the XiL chain.

Restbus simulation purpose

Replaces missing ECUs on the bus by transmitting their cyclic frames with correct identifiers, timing, and payload. The device under test therefore sees a complete network and does not report timeouts or enter bus-off.

Closed-loop HIL testing

The ECU outputs drive the simulated plant, whose outputs feed back to the ECU. This is required to test control loops, closed-loop diagnostics, and interactions where stimulus depends on the previous response.

HIL real-time constraint

The simulator must complete each plant model step within its fixed cycle time, typically one millisecond or less. Overruns cause non-physical behavior and invalidate test results, so worst-case execution time must be measured.

Fault insertion unit

Hardware that switches, shorts, or opens ECU signal lines and injects electrical faults such as short-to-ground, short-to-battery, and open load, used to verify diagnostic reactions and safety mechanisms on HIL.

Back-to-back testing

Executing identical stimulus on two representations, for example model versus generated code or SIL versus HIL, and comparing outputs against a tolerance. Deviations reveal code generation, compiler, or integration defects.

Vehicle-in-the-loop testing

A real vehicle on a test track or roller bench is coupled to a simulated environment providing virtual traffic, V2X messages, and scenario participants. It preserves real vehicle dynamics and real sensor input.

MISRA deviation permit

A documented, reviewed justification for not complying with a required or advisory MISRA guideline in a specific location. Mandatory guidelines admit no deviation; the compliance summary records all deviations.

Cyclomatic complexity meaning

The number of linearly independent paths through a function, computed as edges minus nodes plus two on the control-flow graph. It sets the minimum number of tests for branch coverage and flags functions needing refactoring.

Data-flow anomaly types

Def-use analysis detects undefined-before-use (u before any d), unused definition (d with no later u), and dead code. These anomalies indicate coding defects that may not surface in dynamic testing.

Static analysis in ISO 26262

ISO 26262-6 requires static code analysis at all ASILs, with coding guideline checking and control-flow and data-flow analysis highly recommended at ASIL C and D. Results are evidence in the safety case.

Safety-oriented static analyses

ISO 26262-9 analyses performed without executing the item: freedom from interference, dependent failure analysis, and consistency review of FMEA and FTA results against the architecture and safety requirements.

Traceability review as static test

A desk check that every requirement maps to design, code, and test cases and back. Orphan requirements, untested requirements, and tests without requirements are reported as findings without executing anything.

Model static checks

Reviews and tool checks of models without simulation: unconnected ports, signal range and scaling mismatches, algebraic loops, unreachable states in statecharts, and naming convention violations in the modeling guidelines.

MC/DC coverage definition

Modified condition/decision coverage: every condition in a decision has been shown to independently affect the decision outcome. ISO 26262-6 highly recommends it at ASIL D and recommends it at ASIL C.

ISO 26262 branch coverage target

Branch coverage is highly recommended from ASIL B upward in ISO 26262-6, and recommended at ASIL A. It requires every decision outcome to be exercised at least once by the test suite.

Boundary value analysis

Test technique selecting values at and just outside the edges of equivalence classes, such as minimum, minimum minus one, maximum, maximum plus one. Signal saturation and off-by-one defects concentrate at these edges.

Requirements-based testing strength

ISO 26262-6 highly recommends requirements-based testing for all ASILs including QM-relevant safety requirements, making it the baseline dynamic technique from which structural coverage is added.

Fault injection for safety mechanisms

ISO 26262-4 requires demonstrating that safety mechanisms work by injecting faults into hardware and software and observing the specified reaction, such as safe state entry within the fault tolerant time interval.

Robustness testing stimuli

Out-of-range sensor values, missing or delayed bus frames, supply voltage dips and dropouts, electromagnetic disturbance, and watchdog expiry. These verify defined behavior outside normal operating conditions.

UDS diagnostic test scope

Dynamic tests of services such as session control (0x10), read DTC (0x19), security access (0x27), and write data (0x2E), plus verification that DTCs are set, stored, and healed correctly under induced faults.