Embedded software testing

1. Embedded software testing Parengė: Kęstutis Dragūnas

2. Differences between embedded software and application testing: • Embedded software must run reliably without crashing for long periods of time. • Embedded software is often used in applications in which human lives are at stake. • Embedded systems are often so cost-sensitive that the software has little or no margin for inefficiencies of any kind. • Embedded software must often compensate for problems with the embedded hardware. • Real-world events are usually asynchronous and nondeterministic, making simulation tests difficult and unreliable. • Your company can be sued if your code fails.

3. Embedded software differs from application testing in four major ways • First, because real-time and concurrency are hard to get right, a lot of testing focuses on real-time behavior. • Second, because most embedded systems are resource-constrained real-time systems, more performance and capacity testing are required. Third, you can use some real-time trace tools to measure how well the tests are covering the code. • Fourth, you’ll probably test to a higher level of reliability than if you were testing application software.

4. DimensionsofIntegration • Hardware • Software • Real-time

5. Real-TimeFailureModes • At a minimum, the test suite should generate both typical and worst case real-time situations. • In every real-time system, certain combinations of events (call them critical sequences) cause the greatest delay from an event trigger to the event response. • For some real-time tasks, the notion of deadline is more important than latency.

6. Real-TimeFailureModes • Another category of failures is created when the system is forced to run at, or near, full capacity for extended periods. • Thorough testing of real-time behavior often requires that the embedded system be attached to a custom hardware/simulation environment.

7. MeasuringTestCoverage • software-based • emulators and integrated device electronics (IDE)

8. SoftwareInstrumentation Without RTOS • Possibly not supported • high-intrusion With RTOS • less intrusive • Memory limits

9. Measuring More than Statement Execution • if (condition is true) { < then do these statements >; } < code following elseless if > • if (A | | B) {< then do these statements >;}

10. HardwareInstrumentation • EmulationMemory • LogicAnalyzers • SoftwarePerformanceAnalyzers

11. Performance Testing • Contents of the instruction and data caches at the time the function is entered • RTOS task loading • Interrupts and other exceptions • Data-processing requirements in the function

12. Summary • Maintenanceand Testing • The end of the product development cycle is where testing usually occurs. It would be better to test in a progressive manner, rather than waiting until the end, but, for practical reasons, some testing must wait. • Testability should be a key requirement in every project. With modern SoC designs, testability is becoming a primary criterion in the processor-selection process. • Finally, testing isn’t enough. You must have some means to measure the effectiveness of your tests.