Control Flow Coverage

Concept

Control Flow Coverage is a class of software testing and program-analysis metrics that measure the extent to which a program's control flow graph (CFG)—its nodes (basic blocks), edges (transitions), decisions, or full paths—has been exercised during execution. It underwrites testing adequacy in safety-critical certification (e.g., DO-178B MC/DC) and provides the feedback signal used by automated test-generation tools such as graybox fuzzers.

First seen 7/12/2026

Last seen 7/12/2026

Evidence 4 chunks

Wiki v1

WIKI

Definition

Control flow coverage is a structural testing/analysis criterion that quantifies how much of a program's control flow graph (CFG) has been exercised by a test suite or a single execution run. Depending on the granularity chosen, coverage can be measured over basic blocks, edges, decisions, conditions, or full execution paths.

Common Criteria

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

2 connections

Compiler Instrumentation ← implements 90% 2e

Compiler instrumentation implements control flow coverage monitoring by patching tracing calls into the program.

Hardware-Based Control Flow Tracing ← implements 100% 2e

Hardware-based control flow tracing implements coverage monitoring in hardware without runtime overhead.

LINKED ENTITIES

2 links

Compiler Instrumentation IMPLEMENTS Extracted graph relationship

Hardware-Based Control Flow Tracing IMPLEMENTS Extracted graph relationship

CITATIONS

8 sources

8 citations — click to expand

[1] Control flow coverage criteria such as MC/DC as defined by DO-178B are used by regulators to judge the adequacy of testing and by QA engineers to design tests when full path coverage is impossible. Annotating Control-Flow Graphs for Formalized Test Coverage Criteria

[2] Coverage criteria are often misunderstood because their definitions are written in natural language specification documents, and prior formal definitions in binary predicate logic are difficult to apply to real programs. Annotating Control-Flow Graphs for Formalized Test Coverage Criteria

[3] CFGs are the most common model for analyzing program logic in compilers but discard the explicit concept of a decision; annotating a CFG with decision information yields a Control-Flow Decision Graph (CFDG) usable to formally define common coverage criteria. Annotating Control-Flow Graphs for Formalized Test Coverage Criteria

[4] code-logic-bench measures reasoning correctness about program state spaces, control flow, coverage constraints, and edge cases, with ground truth defined via formal modeling and region decomposition. Imandra CodeLogician: Neuro-Symbolic Reasoning for Precise Analysis of Software Logic

[5] Graybox fuzzers collect CF information via a feedback loop at target runtime, typically implemented by instrumenting (patching) the target, which causes significant memory and runtime overheads and may alter program behavior. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing

[6] Basic block coverage records which basic blocks have been executed; CF edge coverage tracks the actually taken CF edges. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing

[7] Hardware-based CF monitoring can hash each CF edge's source and target program-counter addresses into a coverage map whose entries count edge occurrences, using a lightweight non-cryptographic hash to achieve high throughput and low hardware overhead. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing

[8] Effective hardware-accelerated control flow coverage tracking requires support for repeated partial design resets between fuzzing runs, including cache and branch-predictor resets and bus-handshake legalization (e.g., AXI wrappers). TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing