Understanding Test Coverage: Techniques, Metrics, and Improvement Strategies

Test Coverage Overview

Test coverage is a crucial metric in software testing that indicates how much of the application code or requirements are exercised by test cases. Real‑world incidents, such as the 2008 Heathrow baggage‑handling failure, illustrate the risks of insufficient coverage.

Benefits of Test Coverage

Detect gaps between requirements, test cases, and bugs early at the code level.

Use coverage analysis to prevent missed bugs.

Support regression testing, test‑case prioritisation, suite expansion, and granularity.

Test Coverage Techniques

Statement Coverage

Ensures every executable statement is run at least once. Example path 1A-2C-3D-E-4G-5H covers all statements with a single test case.

Complex code often requires multiple paths to achieve full statement coverage.

Advantages

Can be applied directly to compiled code without source analysis.

Verifies that each requirement is exercised by the code.

Disadvantages

Only covers each statement’s condition, not logical operators (e.g., || and && ).

Cannot guarantee 100 % coverage because it is a basic metric.

Branch Coverage

Checks whether every possible branch (decision point) in the code has been executed. It measures the coverage of all edges in a control‑flow graph.

Example: path 1A-2C-3D-E-4G-5H covers edges A, C, D, E, G, H but misses B and F; an additional path 1A-2B-E-4F is needed to cover the remaining edges.

Advantages

Covers all conditional statements.

Ensures every branch has been tested.

Disadvantages

Ignores short‑circuit evaluation branches created by boolean operators.

Path Coverage

Involves enumerating every possible executable path through the program. Four example paths are listed, illustrating the exponential growth of paths with code complexity.

Advantages

Reduces redundant testing.

Provides high coverage by exercising all statements and branches.

Disadvantages

Testing every path is difficult and time‑consuming because the number of paths grows exponentially.

Many paths may be infeasible in real business scenarios.

Condition Coverage

Verifies that each boolean condition evaluates to both true and false at least once. Each condition therefore requires two test cases.

Advantages

Measures each condition independently.

Provides better sensitivity to control‑flow errors.

Disadvantages

Leads to an exponential relationship between decision points and test cases.

Multiple‑condition tests can cause test‑case duplication.

Boundary‑Value Coverage

Targets errors that occur at the edges of input domains. Typical examples include testing the minimum (100), just below minimum (99), maximum (999), and just above maximum (1000) for a three‑digit input field.

Advantages

Allows testers to replace large data sets with a few representative boundary values.

Easy to automate and verify consistency.

Disadvantages

Cannot test dependencies between multiple inputs.

Does not cover code containing boolean functions.

Test Coverage Metrics

Code‑Level Metrics

Execution coverage (also called "passed/executed") measures the percentage of total tests that have run successfully. While it gives a quick view of progress, it does not reflect test quality because passing tests may still hide bugs.

Functional Test Metrics

Requirement Coverage

Determines the extent to which test cases satisfy software requirements by dividing the number of covered requirements by the total number of requirements.

Test Scope

Links test cases to requirements, allowing impact analysis of test or requirement changes and providing finer granularity.

Test Case Quality

Assesses how well test cases exercise functional behaviour, including both forward and reverse scenarios.

Application‑Level Metrics

Defect Density

Measures the number of known defects relative to a software entity such as lines of code, modules, or features.

Test Scope

Identifies modules that need automation; high‑defect modules are candidates for retesting and automated test creation.

Test Coverage Matrix

A matrix for a login feature lists features, modules, case types, and example test cases (valid credentials, invalid username, invalid password, empty fields, and boundary‑length inputs).

Measuring Test Coverage

Coverage is often calculated as covered lines divided by total lines (e.g., 800 of 1000 lines = 80 %). Requirement‑based coverage focuses on traceability from test cases back to requirements, enabling visibility of coverage at any point in the project.

Improving Test Coverage

Remove Dead Code

Overall coverage can be increased by reducing the denominator (total code) through deletion of dead, debug, or leftover test code identified by coverage tools.

Remove Redundant Code

Eliminating duplicated code can raise coverage by 5‑10 % because fewer lines need to be exercised.

Increase Device Coverage

For mobile and web applications, testing on a wide range of devices, OS versions, and browsers (e.g., Chrome, Firefox, iOS, Android) expands the coverage surface. Analysts should track the most used devices and keep the test‑device library up‑to‑date.

Conclusion

Structured testing approaches that include comprehensive test‑coverage metrics are essential for assessing software quality and ensuring high‑level test completeness.