Module tests are typically dynamic white-box tests. This requires the execution of the software or parts of the software. The software can be executed in the target system, an emulator, simulator or any other suitable test environment. Within the range of dynamic tests the state of the art distinguishes between structural and functional tests. The structural dynamic tests are also called "module tests" or "unit tests". A module test is performed with the knowledge of the module internals in mind. I.e. especially the branches and paths in functions and modules.

The focus of the tests is:

Set up of regression tests. This means the test environment once set up for a function can be re-used to check its performance e.g. after maintenance.
Coverage of the relevant state of the art test methods like equivalence class building, boundary value analysis and condition coverage.
Easy generation of test cases for all possible combination of inputs to a function, e.g. to check a function for overflows, underflows or divisions by zero.

To perform the module tests you need a test bench. There are quite a number of professional systems available which either do testing in a PC environment or in the target hardware. Generally you can say that everything needing a target hardware is a headache. The target hardware might not be your exact target system, but an evaluation board. However if this is the case there is not much benefit, because the integration into the target system will be never complete and valid. The better approach would be to keep hardware related parts of the program in a dedicated HW abstraction layer. This part has to be then tested in a special environment (e.g. the emulator). All the rest of the software is standard C and could be also tested on a PC based environment. We are doing our tests in a Perl script environment. It is easy to use and the best thing about it is that it is easily available to everybody and it does not cost a cent.

ITPub博客

SWT-04: Module Tests

最新文章