Discover TÜV-certified GoogleTest with Agentic AI for C/C++ testing!
Get the Details »
Jump to Section
Parasoft Blog
Code coverage shows what code executed, but it doesn't prove which requirements were actually verified. Read on to discover how to extend GoogleTest with requirements traceability using Parasoft C/C++test CT—so you can close the gap between passing tests and compliance evidence.
Jump to Section
In a previous post, we discussed how teams can achieve code coverage goals with TÜV-certified GoogleTest and C/C++test CT—a C/C++ software testing tool with certified GoogleTest support. You can collect structural code coverage from GoogleTest-based tests, analyze coverage gaps, and generate the evidence needed to demonstrate testing completeness.
But code coverage represents only one dimension of unit testing completeness.
In projects where compliance with functional safety standards is mandatory, teams must also demonstrate adequate verification of software requirements with test cases. They typically achieve this through requirements traceability reporting, which establishes documented relationships between requirements, tests, and test results.
Requirements traceability enables teams to answer several fundamental questions.
Without this information, a successful GoogleTest execution or a high code coverage percentage does not, by itself, demonstrate that the intended software behavior has been completely verified.
In this blog, we explain how Parasoft C/C++test CT extends the GoogleTest framework with requirements traceability reporting and enables test results to be correlated with requirements managed in an external requirements management system.
Structural code coverage and requirements coverage provide complementary views of unit testing completeness.
Code coverage reports demonstrate which parts of the implementation were exercised during testing. Depending on the applicable development process and safety integrity level, teams may need to collect metrics such as statement, branch, decision, condition, or MC/DC coverage.
Requirements traceability reports address a different question. Rather than showing which code constructs were executed, they show whether the specified software behavior has been verified.
For this reason, compliance-oriented projects typically use both forms of evidence:
Together, these reports provide a more complete view of verification status. Teams can identify gaps in requirements, tests, and implementation.
GoogleTest is widely used for unit testing C and C++ software. It provides a familiar framework for defining test cases, organizing test suites, executing tests, and generating XML test execution results.
By itself, however, the GoogleTest execution report primarily describes test structure and execution status. It identifies which tests were executed and whether they passed, failed, or were skipped, but it does not provide a complete compliance-oriented workflow for correlating those results with requirements stored in an enterprise requirements management system.
Teams often attempt to address this gap with spreadsheets, naming conventions, custom scripts, or manually maintained traceability matrices. While these approaches may work for small projects, they become difficult to maintain as the number of requirements, test cases, product variants, and test configurations increases.
Parasoft C/C++test CT extends the GoogleTest workflow with support for requirements traceability reporting. You can annotate test cases indicating their relation to requirements.
A single test case may be associated with one or more requirements. Similarly, multiple test cases may verify a single requirement when different inputs, operating modes, boundary conditions, or failure scenarios require evaluating.
These annotations create the initial link between the unit test’s implementation and the project requirements. The requirements traceability workflow consists of three primary stages.
Developers begin by associating GoogleTest test cases with the appropriate requirement identifiers.
The identifiers should correspond to requirements maintained in the project’s requirements management system.
Keeping the requirement references close to the test implementation makes the relationship visible during development and allows it to be managed through the same review and version-control processes as the test code.
Use GoogleTest to run the annotated tests and generate an XML execution report containing the test results.
C/C++test CT reads the XML report, which contains both the test execution results and the requirement annotations, and sends this information to Parasoft DTP, a reporting platform.
DTP connects to your RMS, imports the relevant requirement data, and generates the traceability report.
You can integrate this workflow into your local development process or, even better, a continuous integration pipeline.
DTP connects to the organization’s requirements management system, like Jama, Polarion, Codebeamer, or DOORS Next, and retrieves information about the referenced requirements.
DTP then correlates the requirement records with the unit testing results received from C/C++test CT.
This correlation combines information from two sources:
As a result, you can analyze verification status without duplicating the complete requirement definition inside the test source code or manually transferring test results into the requirements management system.
The requirements management system remains the authoritative source for requirement information, while DTP provides a consolidated view of the relationships between requirements and test evidence.
Once the information has been correlated, traceability reporting can highlight gaps that are difficult to detect from a standard GoogleTest report.
For example, the report may reveal the following types of requirements:
These findings support both day-to-day development and formal compliance activities.
Traceability reporting does not replace engineering judgment. Instead, it provides objective data that directs reviewers toward relationships requiring further analysis.
Requirements and test suites rarely remain static.
Requirements may be added, modified, decomposed, replaced, or removed. Test cases may be renamed, refactored, parameterized, or divided into smaller tests. Product variants may also require different subsets of requirements and tests.
Because C/C++test CT processes traceability information as part of the regular GoogleTest execution workflow, reports can be updated whenever the test suite runs. This reduces dependence on traceability matrices that are maintained separately from the source code and may quickly become outdated.
Continuous traceability also provides earlier feedback. Don’t wait for a formal audit or release milestone to discover missing relationships. Review requirements coverage throughout development.
This is particularly valuable in dynamic development environments, where implementation, requirements refinement, and test development frequently proceed in parallel.
Requirements traceability reporting becomes even more valuable when analyzed together with the code coverage capabilities discussed in the first part of this series.
Consider a requirement that is linked to a passing test. From a requirements perspective, the requirement appears to have been verified. However, structural coverage analysis may show that the associated test does not exercise all relevant branches or conditions in the implementation.
Conversely, a function may achieve complete structural coverage, while traceability analysis shows that no test has been explicitly associated with the requirement that defines the function’s expected behavior.
These two forms of evidence help teams investigate verification completeness from both directions.
This combined analysis supports a more systematic verification process and provides stronger evidence for reviews, assessments, and audits.
An important advantage of this approach is that teams can retain GoogleTest as their unit testing framework.
Developers do not need to abandon established test suites or adopt a separate proprietary test definition format solely to generate traceability reports. Instead, C/C++test CT adds the reporting and integration capabilities required for compliance-oriented development.
GoogleTest remains the framework used to define and execute unit tests. C/C++test CT processes the execution data and requirement annotations. Parasoft DTP integrates those results with information from the original requirements management system and provides the consolidated traceability view.
For safety-critical software, successful test execution and structural code coverage are necessary but not sufficient forms of verification evidence. Teams must also demonstrate that software requirements are linked to appropriate test cases and supported by current execution results.
C/C++test CT extends the GoogleTest framework with requirements traceability reporting.
By integrating traceability into the existing GoogleTest and CI workflow, teams:
Combined with structural code coverage reporting, this approach provides a more complete and scalable foundation for demonstrating unit testing completeness in safety-critical C and C++ projects.
See how your team can prove verification coverage using C/C++test CT integrated with the only TÜV-certified GoogleTest.
