Test coverage is a measure of how much of a program’s code its tests actually run. It is part of the test-measurement material in the IEEE Computer Society’s SWEBOK, which treats coverage among the measures used to judge a testing effort. The basic idea is simple: run the test suite while recording which parts of the code were touched, then report the fraction that was reached.
Coverage comes in several flavors of increasing strictness. Line (or statement) coverage asks whether each line was executed at least once. Branch coverage asks whether each decision was taken both ways, true and false. Path coverage asks whether each distinct route through the code was followed. A test set can score high on lines while still missing branches or paths.
Coverage is most valuable as a way to find code that no test reaches at all. A function with zero coverage is definitely untested; that is a concrete, actionable gap worth closing.
High coverage, however, does not mean the software is correct. A test can execute a line without checking that the line did the right thing, so even one hundred percent coverage leaves room for defects. This echoes Dijkstra’s warning that testing “can be used very effectively to show the presence of bugs but never to show their absence.” Coverage measures how much was exercised, not whether the results were verified.