 చక accepting the next practical session of embedded software testing today we will try to focus on exercise three that is on coverage testing tools for unit testing so we know that in embedded software testing we have the lifecycle such as we model where right from DETAIL DEZING DETAIL DEZING DETAIL DEZING SOFTLY midnight SOFTLY we need to DETAIL DEZING we have the implementation of the code that is also required so that is what we will try to do with the unit testing so what basically we do with the coverage testing tool is something like we start with the instrumented and non-instrumented execution so the focus is to cover all the top level requirements whether it is implemented or not implemented then we generate the report and see whether it is covering 100% or not so that is what the purpose of the unit testing we have so basically objective of software testing is to demonstrate the software satisfies the requirements so we will try to see how the tool is used the example tool that we pick up today is LDR unit it is a unit testing tool also followed by that we will try to see the structural coverage report analysis how it gets generated so so far in our theoretical session we have studied black box testing white box testing in terms of testing methods we know that three levels of system testing integration testing and unit testing that can be done so unit testing we will try to focus on plastic units we know that we have we have a stumps and drivers that we need to live with so we will try to touch base on that part so there are a bottom up approach top down approach so top down approach we are trying to test a higher level module with the help of stumps of the particular unit which is under interest for us to test it right so we have suppose f1, f2, f3, f4, f4.c files or the c files that are to be tested uniquely and we are trying to test as a complete unit so we will do first one under focus as f1.c f2, f3, f4, c that will be stubbed because f1c is of interest for us similarly what we are doing for f2 we are trying to do for f1 so likewise we are going to have the stumps created so likewise we have specific interfaces sometimes that also need to be addressed so those interfaces are also stubbed something like subsystems suppose so for the unit testing there is a dependency on these subsystems or the subunits or any interface units so we are going to have a stumps and the stumps will have basically the parameters that are required to pass on and the parameters or the return values or the variables that are required to return so with the help of that we will develop it and how it can be automated then also some tools will take up if that cannot be automated then in that case we have to do a manual verification of the same so basically for low level testing what we do is we look for HDD or low level design also called software design document at its low level not the high level because that will talk about all the lowest possible design algorithms some embedded systems will have a pseudo code so in generic and that will be implemented in the code so along with HDD we also need the code because we need instrument and non-instrument etc so basically we will try to cover all that portion equivalence boundary with all these ranges and all that with the provided specification and what we try to do is non-instrumented target object code we will try to execute on the target basically that we will see in another session where target based execution is taking care that also we will go through possible today and all the requirements functional test will be done with some limited values on the target or the simulated target where actually there is a dependency on target at this period so we cannot or it may be difficult instrument and robustness also we will do now and we will try to get the results similarly on the host side we have the instrumented native it is called as or instrumented host object code finally we have to compile the instrumented source code along with the target object code to create a target object code and we will be running that and we will be passing on all the values that will require for normal range robustness etc and all the requirements and robustness test will be compared the results along with the above one so combining these together combining both this we are going to come up with the coverage so that is what we do with the coverage analysis with the both instrumented and non-instrumented unit testing okay so in terms of DevOps and it be that is a aerospace standard is one of the stringent standards that has to be adopted basically this talks about structural coverage and analysis and objectives will be to ensure the structural coverage that is each source code branch is executed at least once that is we have source code with the branches and conditions right so every branch has to be in terms of statement or decision has to be executed on the target or on this application whatever the way you want so that execution drive will be done with the tool basically so we will have test cases created for the requirements basically because the requirements will tell about the values right so those values have to be driving these branches and decisions to have the coverage and robustness so D1 standard B requirement is that to ensure the statement decision modified condition decision coverage that we need to take care to identify the dead code also is one of the important objective statement coverage, decision coverage, modified MCDC it is called as that is the dependency of the different values at the input level as well as the output level have to be added that is what we do with the D1 standard B and also dead code needs to be isolated it should be removed basically analysis must be performed to assess the effect and the need of second time verification so we are going to remove the dead code and are we really requiring to execute we may require to do it because regression test is necessary in that case where the impacted test need to be re-verified or retested so some of the examples of robustness are something like divided by 0 that is also one of the robustness where how the code is going to behave for this situation and to verify the component behavior of overflow for a local data how it is going to behave or something like negative for spare root some impossible operation we will also try at any case software should have a proper path to have a known or determination determine the execution that is what we need to verify so that these things might not have been specified in the design document or low level design document but there should be a way to figure it out so basically we are testing the lowest level entity most independent unit within its boundaries we are going to have it so we need input at detail design as detail design and testing process is unit testing and the output will be the test report and the coverage report so which will tell how much is covered in that of branches and statements so basically we are trying to cover the functionality of the model and at the same time it is the robustness also will be verified so the best way to do this is using the code itself you do it so it is not just try to do the unit testing we help of the code with the only design so the main input for a tester to perform the unit test is the software design document and not the source code basically design document is the input for him based on that he has to try the value where he is going to try the value is the input as code so with the code as input the requirements are all tested and mismatch between detail design of code cannot be detected sometimes so unit testing we may have to take care of those situations so there are different tools like RTR to Quantica, Vectorcast, CTB, LDRA so we will try to go through the LDRA code how they use it because these are all available in the net actually I have downloaded and we can use it as a reference