Perform static analysis, unit testing, and code coverage to develop high-quality C and C++ code that is robust, safe, secure, and compliant with industry standards.
Structural code coverage is the identification of code that has been executed and logged for the purpose of determining if the system has been adequately tested.
Code coverage expresses the degree to which the application’s source code is exercised by all testing practices, including unit testing, manual testing, automated functional testing, and the like. It also:
As a result, application coverage provides extremely powerful insight into risk. In most organizations, unit testing is the primary vehicle for driving coverage. And while unit testing is a valuable testing practice that also enables several process-oriented benefits, it is also expensive in terms of the expertise and time to create, manage, and maintain the tests.
Code coverage can be leveraged as part of the continuous integration (CI) process, as well as part of the developer desktop workflow. You can also perform advanced analytics on the source code and identify which unit tests need to be rerun based on code changes the developer has performed.
These code coverage tools are especially useful in industries for embedded development of safety- and security-critical applications where software systems cannot fail, or lives will be lost.
The thoroughness of the coverage in safety-critical systems depends on the application safety integrity level (SIL or ASIL) metric used in various industries and the development assurance level (DAL) commonly used in avionics. Thoroughness refers to the structural elements in code. These are typically broken down to the code statement, branch, modified condition decisions and with Parasoft, you can also drill down to a much finer level of coverage granularity, such as the object code or assembly language.
Code coverage is often identified or measured through code instrumentation. This is done by adorning the source code with additional tracking code to determine while it runs whether each statement, branch, and/or modified condition decision (MC/CD) path has been executed.
It’s important to know that code instrumentation causes code bloat. The increase in code size isn’t usually a concern. For embedded targets with memory constraints, the increase may impact the ability to load the code onto your target hardware for testing.
Code coverage percentage goals can be subjective in some cases. In other cases, they’re mandatory. When building applications that are safety-critical where failure may cause death, regulatory and industry standards require 100% structural code coverage.
For applications that aren’t safety-critical, code coverage tends to be left to the development organization to decide. The common comfort level for these types of circumstances is achieving a goal of 80% code coverage.
Collect coverage from unit testing, system testing, manual testing, as well as all other test execution methods used. Parasoft C/C++test supports a range of coverage metrics (Branch, Statement, MC/DC, etc.), which teams can use in native and cross application development.Request Demo
Collect and monitor code coverage during manual or automated functional testing performed on your Java application. Users can send coverage data and test results to merge and correlate for analysis, which provides insights about how well the application is tested and your test quality.Start Free Trial
Obtaining the amount of code exercised during testing is a powerful metric in order to understand the level of risk remaining in the application. Here are some best practices to follow.
Parasoft code coverage within the IDE and DTP dashboard reporting and analytics solutions.
To get started in collecting code coverage, become familiar with your coverage requirement needs. Maybe your industry and type of application don’t require any coverage metrics to be obtained, but you want to ensure or improve code quality, so 75% might be your initial goal.
If your industry requires compliance to a functional standard like DO-178C for avionics or ISO 26262 and ISO 21434 for automotive or IEC 62304 for medical, then determine if you need to obtain 100% code coverage or another percentage of code coverage is recommended. Also, know what structural code coverage type you need to satisfy. It could be the function, line, statement, block, call, path, decision, simple condition, MC/DC, object/assembly, or a combination of these.
One of the easiest ways to obtain code coverage is during implementation when engineers are creating unit test cases to test their code. With solutions like Parasoft C/C++test and Jtest,
Be aware that instrumenting the code can cause code bloat and if you are testing on target hardware you may need to do partial instrumentation. Instrumented code may also alter the performance of the execution, so you may want to become acquainted with various optimization features available to you.
Collecting and reporting your code coverage metrics is crucial. There are several methods based on if your application is running on an embedded target, or a fully resourced system or server.
Ultimately, you’ll obtain or merge coverage data to get your full code coverage metrics. Coverage reports can be generated from your IDE, and they can be exported to Parasoft’s reporting and analytics dashboard DTP. In DTP, users can visually inspect the high-risk areas, understand what should be addressed next, and produce compliance and audit reports.
Parasoft’s solution for code coverage provides critical feedback about the completeness and thoroughness of the testing process, by correlating tests and structural code coverage results. You can use these results or metrics for assessing unit, integration, and system-level testing completeness through our support of all important types of code coverage (function, call, line, statement, block, path, decision, simple condition, and MC/DC), including object/assembly coverage.
Coverage results are available directly in the IDE, with convenient views and highlights in the source code editor, as well as in the form of static HTML or pdf reports, and dynamic reports through Parasoft’s centralized reporting dashboard.
Users can monitor applications executed natively on the desktop, cross-platform using simulators, or on real embedded hardware. C/C++test’s coverage module is optimized to minimize the impact on the execution performance and test binary footprint, which makes it suitable for use with high-end, server-based applications, as well as very limited systems based on 16-bit microcontrollers.
When connected with Parasoft’s Process Intelligence Engine, users benefit from test impact analysis. For each and every test performed, including manual, system-level, or UI-based, tests are recorded for not just test/fail and results but also their coverage impact on the codebase.
Each additional test is overlaid on this existing information, creating a complete picture of test success and coverage. As code is changed, the impact is clearly visible on the underlying record, highlighting coverage tests that now fail or code that is now untested. Raising this information in various degrees of detail allows developers and testers to quickly identify what needs to be altered/fixed for the next test run.
With Parasoft, teams can concentrate on code coverage for the areas of active development, instead of the entire codebase, which can be especially problematic when working with legacy codebases. Rather than solely trying to achieve a coverage number for the entire codebase, Parasoft helps you pinpoint the parts of the code that are changing.
Parasoft’s reporting dashboard correlates the data from C/C++test with observed changes in the codebase to focus the development team on achieving higher levels of code coverage for those specific, modified parts of the codebase. With Parasoft, you can minimize the impact of changes by efficiently managing the change itself.
Structural code coverage is the identification of code that has been executed and logged for the purpose of determining if the system has been adequately tested. Code coverage expresses the degree to which the application’s source code is exercised by all testing practices.
Code coverage should be determined by your coverage requirement needs or goals. Do you need to satisfy a safety functional standard (DO-178C for avionics or ISO 26262 for automotive, or IEC 62304 for medical) that mandates or recommends 100% coverage? Or maybe you just want to improve your code quality, so 60% might be your initial goal.
We recommend a minimum of 60% code coverage, which should be easy to obtain. This will give you some comfort but knowing that 40% of the code was not tested may give you some sleepless nights. Some recommend 70-80% but the best way to determine if you need to increase your coverage percentage is based on the number of defects that have been identified.
Yes, obtaining 100% code coverage is possible. You can achieve this through the aggregation of various testing methods and through observation of code execution using your debugger, but for lines of code that require very specific circumstances to execute, such as defensive code, it may take weeks, months, years, or you may never reach that event.
Knowing that your tests have not left out any untested code is your signal. However, your code coverage analysis goals should be based on any compliance requirement or your organization’s goal to improve code quality.
Absolutely! Parasoft’s test automation solutions have built integration into Azure pipelines and with other tools like GitHub, GitLab, Jira, and others that automate your continuous integration and continuous delivery workflow.