Design for test
Mon Jan 21, 2019 · 280 words

Embedded systems are by definition one part of a larger device. The purpose of the software is not to stand alone but function within another device. When testing, this cannot be ignored.

Differences from hardware

The phrase “design for test” is typically applied to hardware, and to some extent this topic is a logical extension from the hardware to the software.

When looking at hardware from a software (testing) point-of-view, there are some crticial differences:

So how do we test embedded systems?

Despite the above points, we still want and need to do the following:

So, we can:

Outside-in testing

Testing is expensive. Hardware must pass acceptance tests. Therefore start off having automated acceptance tests. These can evolve into more general end-to-end system tests. Only when you have exhausted your suppply of end-to-end tests should you move inwards to do more focussed module and unit tests.

The thinking here is that the end-to-end tests will test everything else by implication, not with the same degree of repeatability or control, but the functionality will be tested.

At the end of the day, the product is what matters.

back · Articles · Who am I? ·