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.
Statement coverage tracks the executed program statements. The metric value of a program is the number of executed statements in it, divided by the total number of statements.
A block groups a sequence of statements and treats them like a single statement. In the C-family of languages curly braces ({ and }) are used for grouping.
A basic block is a statement block with no jump instructions in it. Given a single entry and a single exit point only Statement Coverage can be simplified by basing calculations on complete blocks.
Unlike Line Coverage this metric is robust against plain code formatting changes. After all, many programming languages allow for multiple statements in a single line. Splitting of lines should not influence the coverage value.
100% Statement Coverage implies 100% Line Coverage. But the opposite is not true: a line may contain multiple statements whereas a test may not succeed in executing all of them. The following example shows a line with two statements where the latter one is skipped if the variable done is true from the start.
while (!done) { readMoreData(); }
A plain count of executed statements does not take possible branching points and input conditions for branching decisions into consideration.
if (config->loggingEnabled())
log("Will start to process data");
startProcessing();
A single test will be able to execute all of the above three statements. Thus resulting in 100% coverage at this level. But is it complete? The case of loggingEnabled() returning a false boolean value requires a second test. To exercise the else branch that would become visible when transforming this code into a flow diagram.
ISO 26262 highly recommends Statement Coverage for ASIL A and B. ASIL C and D recommend it as well but the more strict Branch Coverage and Modified Condition/Decision Coverage are highly recommended instead.
EN 50128 recommends this metric for SIL 0.
IEC 61508 recommends this metric for SIL 1 and highly recommends it for SIL 2, 3 and 4.
Qt Group includes The Qt Company Oy and its global subsidiaries and affiliates.