Dynamic code coverage
Code coverage report
Many developers employ code coverage tools but handle requirements coverage in an ad hoc fashion. This often parallels their system design approach, which often follows informal methodologies, if any. At the other end of the spectrum are developers delivering DO-178B certified applications where process and artifacts are as important as the implementation.
I’ve written about the need for code analysis and other tools to improve the software development process before (see “CGM And Static Code Analysis Provide Safer Applications” at www.electronicdesign.com). The cost to fix a bug grows exponentially over the development process.
Compared to trying to fix things in the field, even when the issue doesn’t cause an additional major liability, it’s always better to find problems during the requirements phase, at design time, or even when the application is coded.
From a developer’s perspective, many tools are easy to understand and use, and they have easily identifiable advantages. For example, static analysis tools like Grammatech’s Code Sonar (see “GrammaTech Code Sonar” at www.electronicdesign.com) and Klocwork’s Insight (see “Klocwork Source Code Analysis”) ensure that developers are following the rules when they’re writing source code.
There are many well established standards such as MISRA C and C++. Most of the MISRA rules can be implemented using static analysis tools, but some rules require manual checking by another developer. There also are many other rule-based standards such as Netrino’s Embedded C Coding Standard, which was developed by practicing embedded developers for embedded developers.
Another useful tool tracks code coverage. This is a runtime technology that typically requires instrumented code, though it is possible to track execution using hardware trace facilities as well as virtual memory access. Most approaches incur execution overhead, but hardware trace does not. Code coverage testing is usually matched with unit or application testing software since developers need to know what code has actually been run successfully.
Code Coverage Just The Start
As noted earlier, meeting design requirements is critical, but testing whether software meets the design requirements can be a challenge. Tools like IBM’s Rational Doors or UML-based design tools help with the creation, management, and traceability of requirements. These tools are often used for projects other than software applications.
LDRA’s TBmanager is another tool in this realm that targets embedded development. It includes LDRA Testbed for static and dynamic analysis engine and coding standards, TBrun for unit testing, and TBreq for requirements traceability.
The tool utilizes static and dynamic code analysis, providing developers feedback like the flow graph that highlights conditions that must be met to provide code coverage during testing (Fig. 1). Of course, the tool provides extensive code coverage reports (Fig. 2) as well.
The static analysis support also makes it easier for LDRA to automatically generate test vectors. I like how LDRA’s tools link requirements, testing, and source code together, making it easy for developers to navigate between these artifacts.
So you aren’t using tools to improve your application development process? Get some soon, or let me know why you aren’t.
