Structural testing
Structural testing, also known as white-box testing or structure-based testing, designs tests from the internal structure of the code: its logic, control flow and execution paths. Code coverage shows how much of that structure the tests have exercised.
Four coverage types
- Statement coverageTypical target 80-100%
- Branch coverageTypical target 70-90%
- Path coverageCritical paths
- Condition coverageTypical target 60-80%
What is structural testing?
Structural testing (also known as white-box testing) is based on the internal code structure, logic and implementation details of a system. Tests are designed by analyzing source code, control flows, data flows and execution paths.
It uses code coverage metrics to measure how adequate the tests are, and makes sure critical branches, loops and conditions are actually exercised.
Structural vs functional. Functional (black-box) testing checks behaviour against requirements without looking at the code. Structural testing looks inside. You need both.
Coverage techniques
Branch coverage is stronger than statement coverage, and path coverage is the most thorough and the most expensive. Condition coverage checks each part of a compound condition, and is usually combined with branch coverage. Pick the target per module, by risk.
| Coverage type | What it measures | Typical target |
|---|---|---|
| Statement coverage | The percentage of executable statements run at least once during testing. The most basic coverage metric. | 80-100% |
| Branch coverage | Whether every decision point (if-else, switch-case) has been tested with both true and false outcomes. Stronger than statement coverage. | 70-90% |
| Path coverage | All possible execution paths, including combinations of branches and loops. The most thorough, and it grows exponentially. | Critical paths |
| Condition coverage | Whether each boolean sub-expression in a condition has been evaluated both true and false. Catches logic errors in compound conditions. | 60-80% |
Structural testing process
Code analysis
Review the source code, draw control flow graphs, and map decision points, branches and execution paths.
Coverage target selection
Set coverage goals (statement, branch, path, condition) based on how critical and risky each part is.
Test case design
Create inputs that exercise specific paths, edge cases and boundary conditions.
Instrumentation and execution
Instrument the code with coverage tools, run the tests, and collect which lines, branches and paths were hit.
Gap analysis and iteration
Find untested sections, add tests for the gaps, and repeat until the targets are met.
Why structural testing matters
Complements functional testing
Black-box testing validates behaviour against requirements. White-box testing checks the internal logic and finds implementation errors.
- Catches logic errors functional tests miss
- Verifies error handling and edge cases
- Makes sure code paths are exercised
- Finds dead code and unreachable branches
Objective quality metrics
Coverage gives you numbers on how complete the tests are, and shows where more testing is needed.
- Measurable test adequacy
- Risk-based coverage targets
- Feedback in continuous integration
- Reporting for regulatory compliance
Have coverage numbers but do not trust them?
High coverage with weak assertions is common. We can look. Talk to us
Industry standard
ISTQB Foundation Level
Structural testing techniques are defined in the ISTQB Certified Tester Foundation Level syllabus, section 4.3 (white-box test techniques). We apply its standard coverage criteria on every project.
Related: component testing, where most structural tests are written, and static testing, which reviews code without running it.
How BetterQA does structural testing
We work in your repository with your coverage tools, set targets per module by risk, and report the gaps that matter, not just a single coverage percentage.
Engineers who test for a living
50+ QA engineers, working since 2018. People plan and run the structural testing and report what the results mean for your release.
Bugs you can act on
Every defect we find is written up in BugBoard, our own test management tool, or in your tracker, with steps to reproduce, the expected and actual result, and the environment.
A certified process
ISO 9001 for quality management and ISO 27001:2022 for information security. See our certifications.
How an engagement works
- €20-45 per hour
- First month is a trial
- First two weeks complimentary if you are not happy
- 30 days notice after that
Structural testing: common questions
What is structural testing?
A test design approach based on the internal structure of the code. Tests are derived from the logic, control flow and execution paths, and measured with code coverage.
What is structural testing also known as?
White-box testing, and in ISTQB terms structure-based testing. It is also called glass-box or clear-box testing.
What is the difference between statement and branch coverage?
Statement coverage counts executable statements that ran at least once. Branch coverage also requires every decision to be tested both true and false, so it is the stronger of the two.
Is 100% code coverage enough?
No. Coverage shows which code ran, not whether the tests checked the right result. It works best next to functional testing, with assertions that would fail if the code were wrong.
Who does structural testing?
Developers and testers with access to the source code, usually at the component and integration level, using coverage tools in the build pipeline.
Need white-box testing?
Show us your code and your current coverage report. We will tell you which gaps matter and close them with tests that check real behaviour.