Suresofttech Test Coverage Measurement Tool

COVER is a test coverage measurement tool developed by Suresofttech. It analyzes test execution results as quantitative code coverage figures to confirm the sufficiency of software testing. Because it measures based on the results of actually executing the code, it is a form of dynamic analysis, and its role differs from static analysis, which inspects source code without executing it. From a single test run, COVER measures coverage indicators such as function, statement, line, branch, and MC/DC, and shows figures at the project, module, file, and function levels together with per-source-line execution status. COVER Enterprise Edition, the centrally managed form, supports up to 10 coverage types and C, C++, C#, and Java; COVER Standalone Edition, the locally independent form, supports up to 7 types and C, C++, and C#.

COVER Enterprise supports up to 10 types: function, statement, line, branch, function call, modified condition/decision (MC/DC), entry, exit, changed function, and changed line. COVER Standalone supports up to 7 of these, excluding entry, changed function, and changed line. From a single test run you can measure the multiple coverage indicators supported by your edition and measurement criteria. For C/C++ you can select a standard or guideline measurement criterion built into the product to measure and display only the mapped coverage; for other languages the COVER-Branch criterion applies by default. Entry coverage confirms whether a given function was called from every function that calls it, and changed function and changed line coverage confirm whether the parts modified, changed, or added since the previous configuration were executed. Definitions of each type are available in Code Coverage Measurement by Edition.

Coverage is used as the basis for judging test results and deciding what to do next. The most basic use is selecting what to test further: unexecuted statements and branches and unsatisfied condition combinations become the list of tests to add. Second is the test exit criterion. With a coverage target set, you decide when to stop testing by criterion rather than by negotiation, and you can operate it as a quality gate that blocks progress to the next stage when the criterion is not met. Third is certification and audit response. Safety standards require different coverage types per grade, and the measurement results become deliverables that demonstrate test sufficiency. Fourth is scoping regression tests: you check the coverage of the changed parts to narrow down what must be retested. Beyond these, coverage is also used to find dead code that can never execute so it can be cleaned up, and to prioritize reviews of modules where unverified areas are concentrated.

COVER Enterprise consists of agents, a server, and a web UI, and centrally accumulates and manages coverage for multiple users and projects. It supports C, C++, C#, and Java and up to 10 coverage types, and provides group aggregation, report scheduling, Open API integration, change coverage, and coverage copy. COVER Standalone is an independent product installed on a local PC and used without an internet connection; it supports C, C++, and C# and up to 7 coverage types, with strengths in quick guides for embedded development environments, debugger collection, and probe exclusion per file and function. The two editions can be used together, so target coverage measured in Standalone can be uploaded to Enterprise and merged into the company-wide view. For selection criteria, see the edition comparison.

You do not need to modify application source code or test code by hand, but per-language build configuration is required at initial adoption. For C/C++, the compiler invocation during the build is replaced with a wrapper matched to the toolchain — for the GCC family, csgcc, csg++, csld, and csar are used. Java in Enterprise uses the CLI, Maven, or Gradle methods, and C# in Enterprise designates the project as a measurement target in the COVER Toolbox. C# in Standalone specifies the original CSC to create a C# coverage builder, activates the project or solution with CoverCSharpEnabler, and then builds in Visual Studio. If the compiler and linker in your Makefile are parameterized, you can specify the wrapper in the build command without editing the Makefile itself. After configuration, you can keep your existing test methods, including UI testing, batch runs, and automation scripts.

Execution overhead is around 10%. The actual value may vary with target performance, language, the coverage types measured, and the instrumentation scope. For C/C++, you can select a standard or guideline measurement criterion built into the product and measure only the coverage you need, controlling the memory and execution time burden. In environments with limited target resources, you can reduce the instrumentation scope using the file and function inclusion settings in Enterprise or the file, function, and directory probe exclusion features in Standalone. For example, the IEC 61508 SIL 2 criterion displays only statement and function coverage, so its instrumentation burden is smaller than the SIL 4 criterion, which measures MC/DC as well. For performance-sensitive projects, we recommend measuring the overhead with your actual target and build configuration during the adoption review.

The coverage build that creates a module can take up to four times as long as an ordinary build. However, when a unique value comparison of the source identifies the configuration as identical to the previous one, probe insertion and compilation are skipped and the existing executable is reused (Registered Patent No. 10-1667262), so rebuilding the same configuration can take the same time as a build with your existing settings. This condition does not mean the same time is guaranteed for a new configuration or when build settings change. Coverage computation happens after module creation, so it does not occupy the build pipeline for long. When applying this in a CI environment, consider a setup that performs the initial coverage build once as a separate job. Actual build time varies with the language, the extent of configuration changes, and the build cache and environment, so it should be confirmed on your real project before adoption.

Yes, COVER Standalone is designed for embedded environments. It supports 20 C/C++ development environments including IAR Embedded Workbench, Keil uVision, Code Composer Studio, STM32CubeIDE, MPLAB X IDE, and Tasking VX-toolset, with a quick guide built in for each environment so you can follow the procedure even on first use. Coverage data from the actual target is collected through embedded debuggers such as Trace32, UDE, XDS, and iSystem, or over Ethernet (TCP·UDP). When target memory is limited, probe exclusion per file and function and selective measurement by grade are available, and environments not on the supported list can be discussed for support through porting.

Coverage for unchanged functions can be preserved, depending on the product settings and the configuration comparison conditions. COVER Enterprise provides changed function coverage and changed line coverage, which identify functions and lines modified, changed, or added against the previous configuration, giving you a basis for deciding the retest scope. Change coverage does not mean that testing only the changed code is sufficient; it must be applied together with impact analysis and the regression test policy of your project. When migrating an agent server or changing a project path, the coverage copy feature can be used for targets with the same measurement criteria and matching relative paths and source.

Yes, both COVER Enterprise and Standalone support modified condition/decision coverage (MC/DC). MC/DC is an indicator that confirms whether each condition making up a decision statement independently affects the decision result. In the C/C++ measurement criteria of COVER, MC/DC is mapped to DO-178B/C Software Level A, ISO 26262 unit level ASIL D, and IEC 61508 SIL 4, among others. In C/C++ source you can click a branch icon to review the MC/DC decision rationale as a truth table.

Yes, COVER can be used to produce structural coverage measurement materials required by safety-critical standards and guidelines. When you select a measurement criterion built into the product for C/C++, such as ISO 26262 or DO-178B/C, the coverage mapped to that grade is measured and displayed. Module measurement results in COVER Enterprise can be generated as reports in EXCEL, PDF, WORD, or PPT format. The in-product mapping is summarized in Measurement Criteria by Industry Standard and Guideline.

Yes, you can adjust the measurement scope with the feature that matches your edition. COVER Enterprise provides a coverage exclusion policy that specifies files and functions to exclude by regular expression or plain string, and for C/C++ modules the file and function inclusion settings let you choose which targets to instrument. COVER Standalone can exclude files, functions, or directories from probe insertion. The source code screen distinguishes lines excluded from measurement and dead code that can never execute with separate colors, so you can confirm the exclusion result directly on the code. That said, whether to exclude generated code should be decided only after confirming your project coverage policy and certification evidence requirements, and it is good practice to keep a separate record of what was excluded and why.

Yes, COVER Standalone is an independent tool used on a local PC without an internet connection, so it can be used on air-gapped and network-separated environments. It supports floating, node-locked, and dongle licenses; in environments where a network connection is impossible, a node-locked or dongle option that meets the issuing conditions can be considered. COVER Enterprise can be operated on an internal network without external internet, but a network connection between the agents and the COVER server is required; the default communication port is 9080 and it can be changed. In Enterprise, server issues and logs can be downloaded from the web, and in Standalone, analysis results and logs can be downloaded from the local problem reporting menu and sent to technical support.

Yes, COVER Enterprise can be integrated into build automation and CI environments to automate coverage measurement. In Docker-based container deployment environments, Java coverage is measured simply by adding one option, and MSA environments are measured with the dedicated cover-javalib-agent.jar, with the host name, IP, measurement path, and number of executed classes of connected agents visible in real time on the Java monitoring page. The Open API feeds coverage status per project and work area into your in-house quality management system on an API key basis, and all calls use HTTPS (TLS). Configuration management tool integration detects changes by comparing against the latest configuration in supported scenarios and computes change coverage. Other configuration management flows must be discussed for applicability before adoption.

The differences are the coverage types, target languages, embedded collection methods, and central management features. COVER Enterprise supports up to 10 coverage types including MC/DC, and Standalone up to 7. For C/C++, you can select standard and guideline measurement criteria built into the product, such as ISO 26262 and DO-178B/C. Depending on the edition, it also provides collection from real targets through embedded debuggers, adjustment of instrumentation targets, changed function and changed line coverage, group aggregation by organization and work area, report generation and scheduling, and Open API integration. These capabilities are separate from third-party tool certification or passing an audit. When comparing with free tools, review the supported compilers and targets, the coverage you need, how results are consolidated and reported, and the licensing and technical support conditions together.