---

In brief

Knowing which tests touch which code lets you run the relevant ones first. On the desktop, tools like Teamscale made this standard practice - and it has been largely unavailable for embedded targets at integration level, because you could not measure coverage there without changing the build.

Coverage as a map, not as evidence

Coverage data has two quite different uses. As evidence, it supports a claim about test completeness, and its value depends on rigor. As a map, it answers an everyday engineering question: I changed these files - which tests care? Here rigor matters much less and freshness matters more - the map only works if measuring it is cheap enough to happen on every run.

What the measurement gives you

• No build variants. Passive trace analysis measures the optimized executable under test - the test-to-code map comes from the same runs as the tests themselves.
• Integration level included. The map covers the code paths that only exist in the linked, optimized system - not just what unit tests reach.
• A native Teamscale export. Line coverage flows into Teamscale for trend analysis and test-gap analysis; CSV serves your own pipeline.

The product in full · The technology in detail · Target support, answered per configuration