Functional Testing

Most embedded systems will require a similar degree of functional testing and will suffer some of the same problems associated with testing, documentation, consistency and so on.  It is assumed here that the obvious method of sudividing the problem into a number of individual modules has been used. Each module is designed and tested in some way separately before being integrated into a final system.

For test approaches, look at the IVM Top 10 Principles of Testing.

Integration is not a big-bang approach: such an idea is stupid for anything but the most trivial system. Design and testing follows the standard V test process, and integration of modules in the whole follows the V, with unit testing before the sub-integration, and compliance testing afterwards.

Here we are concerned primarily with module or unit testing. Compliance testing may be similar!

Test methods are covered in the IVM Test Method Index.

The follow diagram indicates a typical flowchart of such testing emanating from module specifications and any requisite software or coding standards. Note that the prototype software/hardware does NOT end up copied into the module, it may be rewritten or serve as an example, but nobody writing production level code that requires and degree of reliability would allow protoype/hacking code to enter a production module.

Functional Test Flowchart

© Mission Technologies Ltd 2004. Reproduced with the permission of IVM.