My question is following:
Assuming I have developed some embedded controller(board) which has some tens of digital inputs and outputs. It has embedded firmware, which performs some logical functions. I have an automatic test stand which allows functional testing of production boards. It can simulate pretty any input signal combination and read, what controller provides on it's outputs. It can also, for example, switch on and off or swing power supply voltage to check correct operation in different conditions.
Now the point – are there any common methodologies of generating test vectors which would allow 100% testing coverage of my HW and at the best with minimum amount of tests? E.g. I want my controller to be 100% tested.
Currently all boards are tested manualy, but this is time-consuming and I'm sure I don't get 100% coverage.
Best Answer
I don't believe there is any one correct way to approach testing, the required test coverage ultimately depends on the criticality of the product.
When I sit down to create a new test jig for our workshop, the first thing I do is go through the schematic and identify each functional block of the circuit, write down the inputs and outputs (these could be digital or analogue) of the functional block then identify the pass/fail criteria, then I look for things that might cause false passes. e.g. If this component fails or is out of tolerance, will my test detect it? This might mean doing frequency response testing if it's an analogue circuit.
When we design our products, we design with testing in mind and ensure we include sufficient test points to be able to test at multiple points of a circuit with a bed of nails and not just the end point, which we will test again at final level testing.
We will usually have test firmware that we can communicate with and independently control the IO for our board level testing so that we can prove the hardware. Then the final product software is loaded on for final level testing.
I imagine your test hardware has some number of Digital IO and some number of analogue IO.
With software, I don't believe this needs to be 100% tested on each and every board, in my opinion the appropriate place for 100% testing of firmware is at the type testing stage of the product. The software should be revalidated for each modification to the code, but if your configuration management systems are adequate, then the same code will be loaded each time, and you already know it works, the rest is hardware testing.