How to Write Test Cases for Embedded Systems

To write an embedded-system test case, turn one requirement into a repeatable procedure with exact preconditions, test data, steps and a measurable expected result, linked to that requirement.

It must also cover hardware behaviour – sensor input, timing and faults – and specify the board revision, firmware version and measurement method. The 1996 Ariane 5 failure, costing over US$370 million, shows the risk of missing such tests.

Key Takeaways

• Make each test case specific, repeatable, measurable and traceable to one requirement.
• Test software logic and hardware behaviour, including timing, interfaces and faults.
• Use equivalence classes and boundary values for test data.
• Write expected results as numbers, signals or logs – not “works properly”.
• Record firmware version, hardware revision and evidence for every run.
• Maintain a traceability matrix and automate regression tests.

Kickstart Your Embedded Systems Career and Turn Your Tech Passion into High-Demand Skills!

What is a Test Case in Embedded Systems?

A test case in an embedded system’s part of a documented procedure that checks a specific thing that’s supposed to work in a product. This could be whether the firmware, the hardware or the whole product actually does what the people designing it said it was supposed to do.

The international test-documentation standard – ISO/IEC/IEEE 29119-3 – basically lists the key bits that a test case needs to have:

• an identifier
• what it is trying to achieve
• its priority
• where it came from (so people can track it back to the original requirement)
• what you need to have in place before you start (the preconditions)
• what you put in
• what you expect to see

As the same code can behave differently on different boards or under different conditions – embedded teams tend to also add a bit about the environment the test was run in, and some sort of evidence to prove it was actually done.

Why do Embedded Test Cases Matter?

They catch problems with the hardware-software combo early on, stop new updates from breaking things that already work, and provide the evidence that regulators and customers want to see.

In industries where safety is a concern, testing your product to make sure it meets all the requirements it’s supposed to meet is just a basic expectation. And the more risk there is, the more careful and detailed your testing needs to be.

What Types of Test Cases do Embedded Systems Need?

A complete suite covers normal behaviour, limits, faults, timing and communication, moving from unit tests on drivers to integration, system and regression testing.

Where you run your tests also matters – logic that doesn’t interact with the hardware can be tested on a host PC. But timing, drivers and other things that need to work with the hardware properly need to be tested on the actual board or a hardware simulator.

What Should an Embedded Test Case Template Include?

An embedded test case template should cover things like a unique identifier, where the requirement came from, what you need to do to set things up, what you put in, what you do, what you expect to see, and some sort of proof that you actually ran the test.

Having a consistent layout lets you pick up on problems when they happen and lets anyone else run the same test months down the line.

How do You Write Test Cases for Embedded Systems?

Follow these seven steps, using one requirement as the running example: “REQ-TEMP-003: When the measured temperature exceeds 60°C, the system shall activate the alarm within 200 ms.”

1. Break the requirement into testable conditions

Identify the trigger, threshold, timing limit, output and error handling. Here that gives four conditions: alarm on above 60°C, alarm off at or below 60°C, response within 200 ms, and a safe response to a missing sensor.

2. Choose test data using equivalence classes and boundaries

Values in one class should behave alike, so test one representative plus the edges of each class.

3. Define exact preconditions

Replace “set a high temperature” with “simulate a thermistor input of 61°C using a calibrated signal source, on board rev B, firmware v2.3.1”.

4. Write atomic steps

One action and one expected observation per step, so you know precisely where a failure occurred.

5. Make expected results measurable

“UART prints TEMP_ALERT: 61C and the alarm LED turns on within 200 ms” can be judged pass or fail; “system works properly” cannot.

6. Record results and evidence

Log the tester, date, firmware version, hardware configuration and captures such as serial logs, protocol traces or timing measurements.

7. Report defects, retest and run regression

Attach reproduction steps and logs to the defect, rerun the failed case after the fix, then rerun related tests to confirm nothing else broke.

Worked Example: Temperature Alarm Test Case

What are the Best Practices and Common Mistakes?

Tests should be written from the requirements, not the other way round. That way you are checking that the product actually does what it is supposed to do, not just confirming that the code happens to work in a certain way.

• Also, keep each test case focused on a single objective so that when it fails you can quickly figure out what went wrong.
• Test the boundaries of what the product is supposed to do – and what happens when things go wrong – not just the ‘happy path’ where everything works perfectly.
• If you can separate the logic that deals with the hardware from the rest of the logic then you can test the logic part on a host PC.
• At the early stages use mock-ups for parts of the hardware so you can start testing early. Then when you have real hardware – test the timing, drivers and communication side of things.
• For safety projects – measure how much of the code you’ve actually tested.
• And don’t be vague about what you found, don’t leave out the firmware version, don’t have tests that aren’t properly tracked, and don’t skip the regression tests.

Kickstart Your Embedded Systems Career and Turn Your Tech Passion into High-Demand Skills!

Which Tools Support Embedded Testing?

To get better at this, take a small project like a development board with a sensor and an actuator, write up the requirements, create some test cases that cover the boundaries and things that can go wrong, run them on a board and keep track of what you found so you can go back and see what worked and what didn’t.

Conclusion

Writing good embedded test cases is about taking each requirement and turning it into a clear, simple and repeatable check that the product does what it is supposed to do across all the different parts – the logic, the hardware interfaces, timing and all the different failure conditions.

If you stick to a consistent template, test the boundaries, keep track of what you found and automate the regression tests then you will have the evidence you need to show that the product works before it ships.