Questions
How do we even know that a program that we wrote would behave in the exact way we programmed it to behave?
Doesn’t it depends on how well we’ve specified the behaviour itself?
But how do you define the expected behaviour in a rigid or strict way?
Even if we have defined our expected behaviour in a strict manner. How can we check whether our program functions in the same way or not?
These are some of the questions I hope to answer in this note. My objective is to understand it from the view point of firmware testing.
Â
Introduction
Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity.
Â
Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-ff between budget, time and quality.
Â
Model 1
Partition of the code that access the hardware, registers and interrupts into modules that are provided to the rest of the system. Test the driver modules using logic analyzers, oscilloscope, custom test rigs and whatever else that makes sense.
Â
And the rest of the code can be tested on your host system with small set of changes. And on the host system the hardware modules are stubbed out in a way that provides visibility into what the code under test is doing. We can then use mainstream unit testing approaches on this code.
Â
Note that the hardware drivers will create a significant overhead. So this still needs to be thought about. Maybe this is the cost of testing firmware 😕
Â
New Terms
New terms that I came across
TLM
Transaction Level Modelling (TLM) is an approach to modelling complex digital systems by using electronic design automation software.
TLM Language is a hardware description language, usually, written in C++ and based on SystemC library.
Â