Skip to content
STIMSMITH

Code Coverage

Concept

Code coverage is a testing metric that quantifies which program elements, such as statements or branches, execute during tests. It is used to assess test-suite quality, guide test optimization and generation, drive coverage-guided fuzzers such as AFL and libFuzzer, and support verification workflows such as instruction-set-simulator fuzzing, where it may be complemented by functional coverage.

First seen 5/27/2026
Last seen 6/8/2026
Evidence 19 chunks
Wiki v6

WIKI

Code Coverage

Code coverage is a software-testing metric for quantifying the extent to which program elements—such as statements or branches—are executed during testing. Computing it can be expensive because it requires building and executing the code, typically with instrumentation overhead, and because coverage for a snippet depends on the whole program context. [definition-and-cost]

Role in software testing

READ FULL ARTICLE →

NEIGHBORHOOD

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

explore full graph →

RELATIONSHIPS

12 connections
The paper uses code coverage as a guiding metric in the fuzzing approach.
Code coverage is measured alongside functional coverage.
Coverage-guided Fuzzing ← uses 100% 3e
Coverage-guided fuzzing is guided by code coverage to maximize test effectiveness.
Branch Coverage ← part of 90% 2e
Branch coverage is a form of code coverage collected by libFuzzer.
AFL ← uses 98% 2e
AFL uses code coverage as its primary feedback metric
Coverage-based Greybox Fuzzing ← uses 98% 2e
CGF uses code coverage as feedback to guide input generation
Input Instruction Distillation ← uses 95% 1e
Input instruction distillation constructs shorter inputs that maintain original coverage.
INSTILLER ← evaluates 97% 1e
Instiller measures code coverage as a key evaluation metric, achieving 29.4% more coverage than DiFuzzRTL.
Coverage-Guided Fuzzing ← uses 100% 1e
Coverage-guided fuzzing uses code coverage to guide test generation.
libFuzzer ← uses 100% 1e
libFuzzer uses code coverage to guide input generation.
CI/CD Infrastructure ← uses 96% 1e
The CI/CD infrastructure collects code coverage metrics from simulations.
Functional Coverage compares with → 95% 1e
Functional coverage complements code coverage for more thorough verification.

CITATIONS

11 sources
11 citations — click to expand
[1] definition-and-cost: Code coverage measures executed program elements such as statements or branches, and calculating it requires building and executing code with instrumentation overhead and whole-program context. Predicting Code Coverage without Execution
[2] testing-and-cctg: Code coverage is used as a test-suite quality metric, for white-box test optimization such as prioritization and selection, and in CCTG to guide constraint-solver-based test generation. Code Coverage Aware Test Generation Using Constraint Solver
[3] greybox-fuzzing: AFL and libFuzzer-style greybox fuzzers use code coverage over basic blocks, edges, or lines as feedback; coverage-increasing inputs are interesting; CGF maximizes coverage while DGF targets specified code regions. Coverage-guided fuzzing background source
[4] cgf-loop: Coverage-based greybox fuzzing loops over seed scheduling, energy assignment, mutation, execution, and observation handling; interesting seeds are added to the seed corpus and crashing seeds to a crash set; AFL assigns more energy to seeds exercising a new path. Coverage-guided fuzzing background source
[5] libfuzzer: libFuzzer is LLVM-based, uses Clang instrumentation to report coverage, creates bytestream inputs to maximize code coverage, and performs in-process fuzzing through interface functions. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[6] iss-overview: The ISS paper proposes coverage-guided fuzzing for ISS verification, adds functional coverage and a custom mutation procedure, implements the approach on top of libFuzzer, and evaluates it on three RISC-V ISSs. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[7] iss-workflow: In the ISS workflow, the instrumented ISS under test traces execution feedback; the fuzzer updates structural and functional coverage metrics and adds a testcase when coverage increases. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[8] branch-functional-coverage: Branch coverage is collected by libFuzzer and mapped to unique features; the authors extend libFuzzer for functional coverage without interfering with branch coverage; reported coverage is measured on the instrumented ISS under test. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[9] functional-coverage-comparison: Functional coverage complements code coverage in ISS verification and is intended to improve thoroughness for operand-value and instruction-structure-dependent behavior. Verifying Instruction Set Simulators using Coverage-guided Fuzzing
[10] rtl-instiller: Instiller uses input instruction distillation to maintain original coverage with shorter inputs and reports 29.4% increased coverage, 79.3% shorter inputs than DiFuzzRTL, 17.0% more mismatches, and 6.7% average speed increase. Instiller: Towards Efficient and Realistic RTL Fuzzing
[11] llm-prediction: Code Coverage Prediction is proposed as an LLM benchmark using COVERAGEEVAL from HumanEval executions, evaluating GPT-4, GPT-3.5-Turbo, BARD, and Claude, and arguing coverage is valuable as a metric and pre-training data source. Predicting Code Coverage without Execution