Automated memory profiling, performance profiling, runtime tracing, and code coverage analysis - no less important in the embedded world than elsewhere in software. So why is it done less often? Why is it so much harder to find solutions for the embedded market? It is because embedded software development involves special restrictions that make these functions more difficult to achieve, particularly when speaking of target-based execution:
strong real-time timing constraints
low memory footprints
multiple RTOS/chip vendors
limited host-target connectivity
complicated test harness creation for target-hosted execution
etc.
IBM Rational Test RealTime has been built expressly with the embedded developer in mind, so all of the above complications have been overcome. Nothing stands between you and the use of a full complement of runtime analysis features in both your native and target environment.
So use them! It should be automatic - part of all your regression testing efforts (discussed in greater detail in the Tutorial conclusion). As you have seen, these functions are only a mouse-click away so there is absolutely no drain on your time.
You may be concerned about the instrumentation - "But I don't want my final product to be an instrumented application. Doesn't it have to be if I'm testing instrumented code?" No, it does not have to be:
Using the code coverage feature, generate a series of tests that cover 100% of your code
Instrument that code for full runtime analysis
Uncover and address all reliability errors as you test (e.g. memory leaks, overly slow functions, improper function flow, untested code)
Now uninstrument your code - that is, simply shut off all runtime analysis features and rebuild your application
Run your regression suite of tests once more, this time looking only for functional errors
No errors? Time to ship
Make it part of your development process, just another step before you check in code for the night. IBM Rational Test RealTime simplifies runtime analysis to such an extent that there is no longer a reason not to do it.
Test RealTime users may now proceed to the next lesson: Automated Component Testing with Test RealTime.