Test Coverage Analysis

A reference manual for choosing, applying, and interpreting test-coverage analyses on an existing test suite.

This skill is a knowledge reference, not a procedure. It does not tell you when to write tests or which test types to design — that is the job of design-testing-strategy. It tells you, once tests exist, which mechanical signal best measures what those tests do (and do not) exercise, and how to read that signal honestly.

What Coverage Analysis Is

Test coverage analysis is the post-hoc measurement of how thoroughly a test suite exercises a software artifact along one or more axes. It answers the question "what did my tests actually touch?" — for some specific definition of "touch."

The word "coverage" is overloaded. It can mean any of:

• Structural / code coverage — which lines, statements, branches, conditions, or paths in the source code were executed (measured by instrumentation).
• Mutation coverage — what proportion of deliberately-injected source faults the test suite detects (measured by re-running the suite against mutated code).
• Requirements / feature coverage — which acceptance criteria, user stories, or specification clauses have at least one verifying test (measured by traceability).
• API / integration coverage — which endpoints, methods, status codes, contract interactions, and schema fields are exercised (measured by request/response inspection).
• Specification-domain coverage — equivalence classes, boundary values, parameter combinations, state transitions, error paths (measured by analyzing test inputs against a model).

Category correction: coverage is not a test type