Hello, you are using an old browser that's unsafe and no longer supported. Please consider updating your browser to a newer version, or downloading a modern browser.

Global Accelerated Learning • Est. 1999
Glossary Term Statement Coverage

Training Camp • Cybersecurity Glossary

What is Statement Coverage?

A white-box testing metric measuring the percentage of executable code statements run at least once. It is the weakest coverage criterion.

Glossary > Application & API Security > Statement Coverage

Statement Coverage — A white-box testing metric measuring the percentage of executable code statements run at least once

Understanding Statement Coverage

Statement coverage is a white-box software testing metric that measures the percentage of executable statements in a program exercised by at least one test case. Achieving 100% means every line of code ran during testing, but it is the weakest structural coverage criterion and proves only that code executed, not that its decision logic was correctly validated.

It is calculated as the number of statements executed divided by the total number of executable statements. Tools instrument the code to record which lines run. Because a single test path can satisfy many statements without exploring alternative branches, statement coverage misses untaken decision outcomes. Stronger criteria include decision (branch) coverage, condition coverage, and Modified Condition/Decision Coverage (MC/DC), the latter required by DO-178C for safety-critical avionics software. Statement coverage is referenced in ISO/IEC/IEEE 29119 and secure development frameworks as a baseline.

For security, relying on statement coverage alone is dangerous because vulnerabilities frequently hide in untested branches, error handlers, and boundary conditions that statement coverage does not force. An if-statement can reach 100% statement coverage while its false branch, where an authentication bypass or unchecked input path lives, is never exercised. Treating high statement coverage as proof of robustness creates a false sense of assurance and lets exploitable logic ship.

For example, consider code that grants access when a token is valid and logs an error otherwise. A test supplying only a valid token can execute every statement on the success path yet never test the rejection branch where an off-by-one check leaks access. A development team should therefore require 100% statement coverage only as a minimum, then add decision and condition coverage, and full path or MC/DC testing for security-critical components such as authentication, cryptographic, and input-validation modules to ensure every decision outcome is verified.

Learn More About Statement Coverage:

Ready to Get Certified?

Turn knowledge into credentials with our instructor-led cybersecurity boot camps.

View All Courses →