Cross-platform software libraries and APIs
Qt Creator IDE and productivity tools
UI Design tool for UI composition
for Qt projects
Digital advertising for UI apps
Usage intelligence for embedded devices
GUI test automation
Code coverage analysis
Test results management and analysis
Software static code analysis
Software architecture verification
The latest version of Qt.
Make the most of Qt tools, with options for commercial licensing, subscriptions, or open-source.
Explore Qt features, the Framework essentials, modules, tools & add-ons.
The project offers PySide6 - the official Python bindings that enhance Python applications.
Qt empowers productivity across the entire product development lifecycle, from UI design and software development to quality assurance and deployment. Find the solution that best suits your needs.
Insight into the evolution and importance of user-centric trends and strategies.
Learn how to shorten development times, improve user experience, and deploy anywhere.
Tips on efficient development, software architecture, and boosting team happiness.
Get the latest resources, check out upcoming events, and see who’s innovating with Qt.
A wealth of Qt knowledge at your fingertips—discover your ideal learning resource or engage with the community.
Whether you're a beginner or a seasoned Qt pro, we have all the help and support you need to succeed.
Call coverage is the percentage of executed software function calls. It is a structural coverage metric that helps to judge the degree of testing at the architectual level.
The metric easily gets confused with Function Coverage. But whereas the latter is about execution of the function itself Call Coverage mandates that each call found in the code is executed at least once. 100% Function Coverage therefore does not imply 100% Call Coverage. The oppositive is not necessarily true either, though. See the Limitations below for details.
Subsection 10.4.5 of ISO 26262 part 6 recommends Call Coverage for ASIL A and B. For ASIL C and D even highly recommends it. Table 15 lists this metric as an alternative entry – see Interpretations of tables in section 4.2. Function Coverage is the other alternative with an equal recommendation level. See our discussion on Code Coverage Metrics Recommended by ISO 26262 for more details.
Call coverage provides a high-level overview of test coverage. As it is not concerned with the implementation details of the functions the coverage of the units by themselves needs to measured with metrics like Decision (or Branch) Coverage or even better Modified Condition/Decision Coverage (MC/DC).
When interpreting the metric too literally it would not able to detect unused functions: functions may have an implementation but not have any caller in the rest of the code. This not only impacts maintenance of the code. It may even be a sign of a programming error. Therefore watch out for your report not sticking to the number of calls only.
The number of tools supporting the metric is rather small. The number of customer requests simply is too low. However, do not despair when the vendor does not list it explictly! The much more fine-grained variants of Condition Coverage (like MC/DC) can come to rescue! Here’s why:
bool is_item_enabled(Item *item)
{
return item->enabled;
}
int get_item_rank(Item *item)
{
if (!item || !is_item_enabled(item))
return -1;
return item->rank;
}
Neither line, statement nor branch coverage guarantee an invocation of is_item_enabled(). Condition Coverage, however, requires an evaluation of both !item and !is_item_enabled(item). 100% MC/DC coverage (as an example) does therefore imply 100% Call Coverage.
Qt Group includes The Qt Company Oy and its global subsidiaries and affiliates.