Coverage-Guided Execution

Updated 4 July 2026

Coverage-Guided Execution is a systematic approach that uses runtime feedback to steer test input mutation and explore previously untested execution paths.
It integrates diverse feedback signals—including structural, value-sensitive, semantic, and predictive metrics—to target unexplored control flows and latent behaviors.
Applied across domains from kernel fuzzing to deep-learning models, it improves coverage rates while reducing overhead and focusing on fault detection.

to=arxiv_search 凤凰大参考 ? to=arxiv_search 大发游戏官网大发官网天天中彩票中奖天天中彩票买JSON {"query":"coverage-guided execution fuzzing symbolic execution testing arXiv", "max_results": 10} to=arxiv_search Coverage-guided execution is an execution paradigm in which subsequent program runs are steered by coverage feedback gathered from prior runs. In the canonical software-testing loop, execution produces a coverage signal, the global covered set is updated, and later inputs or tests are selected, mutated, or synthesized to expand previously uncovered behavior; in deep learning, the same pattern is re-instantiated over activation structures, latent regions, or surprise buckets rather than explicit control-flow edges (Guo et al., 1 Jul 2025). Across contemporary systems, the feedback signal may be structural, value-sensitive, semantic, or predictive, but the unifying principle is that executions that increase coverage are retained, prioritized, or further refined.

1. Conceptual model

In classical coverage-guided fuzzing, execution is organized around a seed queue $Q$ , a global coverage set $Cov$ , and a set $F$ of crashing inputs. For each seed, the system mutates the input, executes the program under test, and keeps the child if its execution adds new coverage with respect to $Cov$ ; energy assignment then gives more mutations to seeds that can produce new coverage (Qian et al., 2022). This execute–measure–update–generate cycle is the basic operational meaning of coverage-guided execution.

A general formulation writes coverage as

$\text{Coverage}(T) = \frac{|C_{\text{covered}}(T)|}{|C|},$

where $C$ is the coverage domain and $C_{\text{covered}}(T)$ is the subset exercised by a test set $T$ (Guo et al., 1 Jul 2025). In conventional software, $C$ is commonly defined by statements, basic blocks, edges, or branches. In Python regression testing, CoverUp operationalizes the same principle at the level of generated pytest suites: it executes candidate tests under SlipCover, keeps tests that pass and improve line or branch coverage, and continues the same chat with updated coverage information or error output when coverage does not improve (Pizzorno et al., 2024).

This formulation is broader than fuzzing. Symbolic and concolic systems use coverage to select states or uncovered conditions; LLM-based testing systems use coverage to decide which code segments, target lines, or interaction paths should be addressed next; predictive systems replace real execution with a model that predicts coverage and then uses that prediction as the guidance signal. The common structure is feedback-directed exploration rather than any particular generation mechanism.

2. Coverage signals and what they measure

The original coverage signals are structural. GreyConE uses branch coverage as its primary evaluation metric and AFL-style branch-pair coverage as the fuzzing fitness signal for SystemC designs compiled to LLVM IR (Debnath et al., 2022). Ratel uses a collision-free, globally indexed basic-block coverage scheme for enterprise DBMSs, and adds synthetic dummy blocks on critical branches to recover finer discrimination while preserving one counter per real or synthetic basic block (Wang et al., 2021). Minimum Coverage Instrumentation formalizes block coverage as a truth assignment over CFG nodes and asks for a minimum-size subset of blocks whose observed coverage is sufficient to infer the rest of the profile (Chen et al., 2022).

A substantial line of work enriches the coverage signal beyond control flow. BOUNDARY FLOW extends Linux KCOV with structured tuples at function boundaries, recording at entry

$\langle PC, arg\_idx, arg\_size, ptr, offsets[] \rangle$

and at return

$Cov$ 0

so that two executions that traverse identical edges but differ in argument values or returned structures are no longer indistinguishable (Kim, 30 May 2026). In mutation-guided fuzzing, structural coverage is supplemented with mutation score,

$Cov$ 1

so that executions are rewarded not only for reaching new paths but also for killing mutants and thereby exposing fault-sensitive states (Qian et al., 2022). Vital replaces coverage-maximizing heuristics with vulnerability-oriented rewards based on type-unsafe pointers, using $Cov$ 2 and

$Cov$ 3

thereby redefining the guidance objective around vulnerability likelihood rather than raw structural novelty (Tu et al., 2024).

Coverage also becomes explicitly semantic in newer domains. FLARE defines intra-agent coverage as coverage over behavior IDs for each agent and inter-agent coverage as coverage over legal agent interaction paths in a multi-agent LLM system (Hui et al., 7 Apr 2026). The deep-learning survey organizes coverage criteria into neuron-wise, layer-wise, path-wise, black-box input/output-space, and surprise-adequacy families, reflecting the absence of explicit branches in neural models and the need to treat activations, latent regions, and novelty buckets as the units of exploration (Guo et al., 1 Jul 2025).

3. Guidance mechanisms and search strategies

Greybox fuzzing remains the canonical mechanism. In GreyConE, a test case is interesting if it covers a previously uncovered branch-pair or yields a new hit-count pattern on already-covered branch-pairs; fuzzing is then interleaved with concolic execution, which targets uncovered conditions in the execution tree until a productivity threshold is reached (Debnath et al., 2022). Wildfire reconfigures the search space compositionally: isolated functions are fuzzed directly, crash-triggering tuples are summarized, and targeted symbolic execution then searches callers using distance to summarized vulnerable functions as the guidance criterion (Ognawala et al., 2019). SPsCGF combines CBMC-generated initial seeds with coverage-guided fuzzing for control models, and its seed-selection procedure explicitly prioritizes half-flipped conditions and MC/DC obligations rather than only raw branch novelty (Yang, 2022).

A separate strand addresses the cost of coverage collection itself. UnTracer introduces coverage-guided tracing: an oracle binary encodes the current frontier of coverage with interrupts, so only coverage-increasing testcases are sent to a full tracer; non-coverage-increasing testcases execute initially at native speed (Nagy et al., 2018). HeXcite generalizes this idea from basic-block coverage to the edge-coverage and hit-count metrics used by most contemporary fuzzers through jump mistargeting for critical edges and bucketed unrolling for loop-count buckets (Nagy et al., 2022). In both cases, the guidance signal controls not just which inputs are retained but also which executions pay the overhead of tracing.

LLM-based systems adopt the same feedback structure but substitute prompt engineering and execution traces for mutational heuristics. TestWeaver chooses a specific uncovered target line, computes a backward slice, generates a test, and if the target remains uncovered, selects a closest existing test by control-flow proximity, annotates the slice with execution in-line comments of the form # (k) [var](https://www.emergentmind.com/topics/emel-var) = value, and re-prompts the model with this execution-aware context (Le et al., 2 Aug 2025). Treefix iteratively generates a tree of prefixes: undefinedness guidance proposes initial setup code, error guidance repairs prefixes that fail, and coverage guidance marks uncovered lines and asks the LLM for prefixes that execute them, returning a subset that maximizes cumulative executed lines (Souza et al., 21 Jan 2025). Cerberus moves further by making the loop predictive and execution-free: a Test Case Generator proposes inputs, a Predictive Executor estimates coverage and runtime errors, and a two-phase loop first targets coverage increase plus error discovery and then shifts to error-only prompting once coverage reaches 100% or plateaus (Dhulipala et al., 24 Dec 2025).

4. Domain-specific instantiations

Domain	Coverage notion	Representative work
Linux kernel	Edge coverage augmented with per-task boundary data flow	BOUNDARY FLOW (Kim, 30 May 2026)
Python regression testing	Line and branch coverage with iterative prompt feedback	CoverUp (Pizzorno et al., 2024), TestWeaver (Le et al., 2 Aug 2025)
SystemC and control models	Branch-pair, branch, condition/decision, and MC/DC coverage	GreyConE (Debnath et al., 2022), SPsCGF (Yang, 2022)
Enterprise DBMSs	Global collision-free basic-block coverage across binaries and processes	Ratel (Wang et al., 2021)
LLM-based multi-agent systems	Inter-agent path coverage and intra-agent behavior coverage	FLARE (Hui et al., 7 Apr 2026)
Deep models and incomplete snippets	Neuron/latent/surprise coverage; executed-line or predicted coverage for snippets	Survey (Guo et al., 1 Jul 2025), Treefix (Souza et al., 21 Jan 2025), Cerberus (Dhulipala et al., 24 Dec 2025)

The domain spread is itself significant. Kernel fuzzing emphasizes argument values and state transitions; hardware-design testing emphasizes branches, branch-pairs, and MC/DC; DBMS fuzzing emphasizes precise, system-wide coverage across multiple binaries; MAS testing emphasizes behavior and interaction paths; deep-learning testing replaces CFG structure with activation and manifold coverage; learning-guided execution for incomplete snippets measures how many lines can be executed once missing context is synthesized (Kim, 30 May 2026). This suggests that coverage-guided execution is no longer tied to a single notion of structural reachability, but has become a domain-specific method for defining, observing, and exploiting “previously unexplored behavior.”

5. Instrumentation, inference, and systems engineering

A large part of the field concerns how to collect coverage with minimal perturbation. Minimum Coverage Instrumentation gives a graph-theoretic solution for block coverage: a valid scheme is a pair $Cov$ 4, where $Cov$ 5 is the set of instrumented blocks and $Cov$ 6 reconstructs the full coverage profile from the partial profile on $Cov$ 7; the paper characterizes ambiguous nodes, forward and backward inferability, and constructs an optimal inference scheme in $Cov$ 8 time using dominator information (Chen et al., 2022). The result is directly relevant to coverage-guided execution because it lowers instrumentation overhead while preserving complete feedback.

Systems that must observe large or distributed software stacks introduce additional engineering constraints. Ratel uses bijective block mapping to eliminate bitmap collisions, and an inter-binary coverage linker to unify counters across DBMS server, client, and auxiliary processes; because enterprise DBMSs are multi-process and may span multiple hosts, the feedback signal must be complete and global rather than process-local (Wang et al., 2021). BOUNDARY FLOW extends LLVM SanitizerCoverage with -fsanitize-coverage=dataflow-args and -fsanitize-coverage=dataflow-ret, decomposes composite types through DWARF metadata, and exports a separate /sys/kernel/debug/kcov_dataflow device backed by lock-free per-task ring buffers, thereby preserving KCOV’s existing trace-pc pipeline while adding value-sensitive observations (Kim, 30 May 2026).

Execution-enabling systems instrument at different granularity. LExecutor wraps variable reads, attribute reads, and calls with runtime hooks _n_, _a_, and _c_, invoking a neural model only when normal execution would fail and then concretizing one of a fixed set of abstract value classes into a Python object (Souza et al., 2023). Treefix instruments snippets by inserting a call to a special function \_l\_ after every line so that a line is considered covered only if the entire line executes without crashing (Souza et al., 21 Jan 2025). These designs show that coverage-guided execution is as much about the mechanics of observability and recovery as about the search policy built on top of it.

6. Effectiveness, limitations, and open questions

Representative results show that the paradigm can be highly effective but also that its benefits depend on the fidelity of the coverage signal. CoverUp improves median per-module line+branch coverage on the CM suite from 55.1% to 77.9% and obtains nearly half of its successful tests only after at least one coverage or error feedback round (Pizzorno et al., 2024). UnTracer’s average overhead falls below 1% after only an hour of fuzzing and approaches 0% overhead after 24 hours, whereas always tracing every testcase with AFL-Clang, AFL-QEMU, or AFL-Dyninst incurs 36%, 612%, and 518% overhead, respectively (Nagy et al., 2018). HeXcite preserves edge coverage and hit counts while remaining near the speed of block-only CGT and outperforming QEMU, Dyninst, RetroWrite, and AFL-Clang by 2–24x on average (Nagy et al., 2022). FLARE reaches 96.9% inter-agent coverage and 91.1% intra-agent coverage and uncovers 56 previously unknown failures unique to MAS (Hui et al., 7 Apr 2026). Treefix raises executed-line coverage on incomplete Python snippets to 84% and 82% on its two datasets, while Cerberus attains a Precision of 0.72, Recall of 0.56, and F1 of 0.63 for complete Java snippets through execution-free predictive coverage guidance (Souza et al., 21 Jan 2025, Dhulipala et al., 24 Dec 2025).

At the same time, multiple lines of work challenge the assumption that “more coverage” is sufficient. Mutation-guided fuzzing argues explicitly that structural coverage is only weakly correlated with fault detection, because two inputs can execute the same path while differing in whether they reveal the bug (Qian et al., 2022). BOUNDARY FLOW characterizes edge coverage as context-blind in kernels, since two executions can hit identical edges while differing in argument values or return structures that have radically different security implications, and it also notes dependence on debug information, exclusion of interrupt context, and possible ring-buffer drops under heavy workloads (Kim, 30 May 2026). The deep-learning survey reports open challenges around the correlation between structural coverage and testing objectives, generalizability across architectures and tasks, and the need for standardized evaluation and tool support (Guo et al., 1 Jul 2025). GreyConE notes fixed-time interleaving and lack of explicit concurrency modeling as limitations, while FLARE depends on framework-specific domain knowledge and LLM-generated specifications that can themselves be imperfect (Debnath et al., 2022, Hui et al., 7 Apr 2026).

These tensions define the current frontier. One direction is composite guidance: BOUNDARY FLOW explicitly proposes combining edge coverage, comparison logging, and boundary data flow into a unified fitness function, while mutation-guided fuzzing, vulnerability-oriented symbolic execution, semantic MAS coverage, and surprise-based DL coverage each contribute alternative signals for what should count as “interesting” behavior (Kim, 30 May 2026, Qian et al., 2022, Tu et al., 2024, Hui et al., 7 Apr 2026, Guo et al., 1 Jul 2025). This suggests that the mature form of coverage-guided execution is not a single metric but a family of feedback-driven exploration strategies in which the choice of coverage domain is itself aligned with the analysis objective: control-flow novelty for throughput-oriented fuzzing, data-flow sensitivity for stateful kernels, MC/DC for control logic, behavioral paths for agent systems, and predictive or execution-enabling proxies when direct execution is unavailable.