Black box testing is usually performed by a third party or a quality assurance group who has an understanding of the external system behavioural requirements but lacks an in-depth understanding of the internal structure or operation of the code. An embedded software engineer on the other hand is much more likely to perform white box testing since they understand the structure and implementation of the software. In this type of testing, the engineer takes into account the software structure to ensure that every branch, every case and every line of code has been executed and verified through testing.
This can be quite a daunting task even for relatively small programs. Thankfully there is a simple way to understand and generate the number of test cases required to ensure proper test coverage and that is to use conditional complexity, also known as cyclomatic complexity (which is a great term to use in a conversation if you want to see people's eyes glaze over). Traditionally, conditional complexity metric testing is recommended during the implementation phase to ensure code quality. The idea is that every function in the program is analysed and provides a resultant complexity value. The higher the value, the more complex the function is which results in higher risk for bugs, difficulties in testing and during maintenance. Typical ranges can be found in Figure 1 below.
Figure 1 – Conditional Complexity Risk
What is really interesting....