 So, in order to have the unit testing used in to have the test tool basically, so what are the inputs that we need, so one is that we need a test script, other one is the implementation of the source code, so what is the output that we can expect from the test tool, the unit test tool test report, it will generate the report and automation if we have with the tool we use coverage report also to give how much percentage and all that, basically this is an optional we can do it manually also, but test tool requires this test script and source code, test script is something like the inputs that are required and the value it writes and the test tool takes that and automates and generate the reports that is how it is getting used, the scripts are basically derived from the plan, so it consists of a testers inputs as the parameters and expected results of all the there in the script, the script is processed by the tool and converted into a driver basically, driving the source basically, so in tool like RTRT the name it is called as a PTU the driver name, similarly LDRA is its own format, test report is the results of the test execution, whether it is passed or failed, coverage report is the how much of total source code have been covered by all the test cases, that is what it has actually, okay, so we will try to understand the tool what it does and go through some videos in terms of demonstration, so that understand what it is, okay, so first we will go through the automated field testing generation and management, okay, so we will try to understand the tool called LDRA unit, basically this is the tool from LDRA and the version 9.4.1, so basically we use this for new testing and the source code we will try to understand what it does, so this is the window where we have LDRA unit explorer, so we will try to explore the mobile testing aspects of this LDRA unit, so there is a C code selected with this LDRA, here we have got a file called cache register .c, so we want to do some unit testing for this cache register .c, so C file, so you can see the file contents, it explores basically, you can see there are number of functions like add product, count products, end session, etc., you can see it here, any function you want to set alone like add products, so you can see the parameters it has, the variables that it uses and whatever the function it calls is all listed here in this LDRA unit tool, it explores basically, all this individual functions of this cache register file, you can see the structure passed as a parameter and it is calling the testers show, testers show and S printer, three functions it is calling basically, so let us start to see how sequence is created, these two, we need to select the sequence and we can call it as a unit test add product something like this, you can add as a sequence and we are trying to do a code coverage for that particular function with this sequence, we have to select that code coverage option, and test environment something like setup about steps, it should create right, because it has a number of functions, if you want to call directly the functions it is available, you can use it and if you do not want you can create the steps for those callers, so we can select that automatically create the steps with that option and user variables can be global, if it is missing we can create it, generate it and different types of test scenarios we can call it here, first option is allowing the compiler to compile the code as a normal one, or the next one is create test for a subset of code in the source form, the specific usage because we are interested please this only, we can do this or isolate fully all the code, we can do this second option just to create that particular single source file, so that with this option is selected, so once you select the procedures it will show that particular procedure and we can see the procedure name and the functions and other details we can stay okay and we can continue, so it does a specific analysis of this option, here what is going to happen is you can see the option here, the variable view and the calls view with this option and any steps that it has to open it will show here, this step testers show, number of calls is 2, it is a managed step, so here we go to the function and we will right click and create test case for that particular function now and it is doing a instrumentation with this and you can see it is about to create test case based on the interface whatever it is displaying below, so here test case generation it could be standard single test case or repetitions like multiple times we are going to execute with different things, the last one is reported here, iterations because sometimes what will happen is we want to see the consistency, we can have it something like a robustness sorry regression, so in that case we can have repetitions, iterations etc., or some ranges we can have it simulated by applying a right value, so we just try to go with the single test case, the you will continue with that, here you can see the input output view, so there are 2 inputs for this function, there is a structure, there is a value I am saying 32-bit structure and output is expected as I am saying 32-bit, so we can click this value input and enter it, we will enter at 0, then the next one we can enter it as 42 and the output we can expected put as 42, it is an example, now we will try to run as this one, we can see the generated test case and the result, we can see here the value for storage that means the function is going to use this and the pass field is based on the expected value versus actual value, so the harness is generated with this and it has executed and showing the result, so say okay, then we can generate again if you want with multiple inputs like 42 if you want change it to 50 based on your functions or the inputs for the functions, of course the input for the functions is based on the specification of the requirement, so that we will get the appropriate coverage where multiple statements within the function is being triggered and we can see here the coverage, statement coverage, the branch decision coverage, the current one is 6%, combined in CDP, current is 6% for branch of decision for that particular file, entire file and that function you can see statement for a 61% it has hit and the branch has a 60%, we can try it a second time, second time again it should say as it was there, so it is a regression, you can see that is a regression pass or fail shows and there is no change in the percentage there, so the values are same, it has passed and the coverage, we will try to look in particular with the, there is a flow graph of the coverage of that particular function, this is interesting, we will see, you can look at the flow graph, see this here, this flow graph basically is saying that executed 2 times, this block executed 2 times, all segments are covered in this block, there are 6 blocks and it is taking the this path after this 4th and 6th, so basically there are 4 blocks that it could be execute appropriately and 2 blocks 3 and 5 are not executed, that is showing in the red, on the right hand side you can see that red marked one which is not executed because it is part of the else portion and it is not executed, so it has passed this one, the portion that is not executed it is showing in the red one, these statements it not executed because the value that we have given is not enough to execute this, 5th block is the last one, tester show, basket full something like that, so this is useful to see the flow graph with the coverage. So and generate the test cases, more cases, so you can see it is adding 2, 3, 4, 5, 4, 4 cases automatically and it will add up all that test cases and generate the, now with that let us see what it has generated, you can see these additional 4 cases automatically it has generated showing the percentage with these 4 cases all together use that 100% for that particular function and for the particular 3, 4 you can see the values it has automatically used based on the inputs that it takes, so you can see in the 4th case and find the address passed for the structure, first input, the second input is a global variable having the values 50 and the result you can see is that statement coverage is 100% and 100% branch it has covered, so quick overview of this you can see that is the area unit thing, still we are not covered 100% of the entire file, C file because we are focused only on the particular function of the file, so that is how the LDRA is being used, further information we can look into LDRA.com and there is a evaluation version probably you can download and experiment more embedded software testing the aspects, so that is about the LDRA how automatic unit test generation is done with the help of which we can see the percentage and automatic unit test generation it does, next type of LDRA unit it is called coverage which also gives the complete coverage of the source code and the structural power analysis, so this is the viewpoint for the embedded software industry such as automotive and aerospace, let us try to understand that also, let us try to play a demo video for that the LDRA cover and try to understand, this is called a LDRA test bed with a tool suit it is integrated together, so the code coverage we will try to understand, so here you can see an example of a project for a keyless 32 it is an ARM based target board, here we will try to simulate because we do not have a target board actually connected to this tool and with that we will try to have the coverage executed, so it is an ARM CPU based C file, so it is called as a TB vision LDRA, the files that are in the project displayed here 9.c, base.c simple files are there, so we will execute the code on the target, here we do not have a target we can use the simulator, we use it instead of the target because to do that replacement of the target, so there is a button we have to press that it is going to compile base and add the instrument the source code for the target code and it is going to build, so there is a compiler it has been built it is called KL compiler, you can see for the LDRA test bed it is integrated, you can see it is running for that particular place 32 simulator, what it is trying to do is as soon as the simulator is triggered it is trying to stream the message onto the simulator continuously and captures the uploaded value, we can stop at some stage we can halt with this option and we can upload the result with this button, the uploaded execution history can be see here you can see it will be process of that and we can have a look at what coverage it has generated, we can see the test manager report for this, so you see there is a report for the same, we can see the code review different types of reviews it does, what we have done here is a test verification the dynamic report and you can see and a file that we have tried to execute main.cd and dice.cd and it is showing the coverage of statements, branches, etc, which we have chosen as the option, you see the percentage where it is 100% is showing in the green whereas others are shown as red because the coverage is not 100%. Let us try to go inside the particular file such as main.cd, we can see the main.cd report in particular showing the result in red because the coverage is not attained, whatever the obtained value is not having 100% coverage because it is 84%, the ambition is 67, MCDC is 25%. That is why it is not due to complain, why it is not complaint, let us try to understand, we can scroll down and see, the main.cd has several functions, several procedures such as integrated task key, display value, etc and main itself, two type of tests like statement and branch or issues because 100% coverage is there whereas the inbuilt, integrated task key library or the function has only 79% and the coverage that we obtained is for this particular integer to ASCII is statement is 79, branch is 58%. And you can see that particular function ASCII to integer and you can see the last two three runs, current run, previous run and the combined how many times it has run with our simulator and it will show the calls, number of calls, what are the statements that are being called and how many decisions it has able to drive together with every line of the code it is showing. So you can see the stars which are not at all, it is showing us 0 times because the values that it requires has not attained them. So some of the lines we have executed more than the earlier ones like 300 plus times it has executed, some of them executed 140 times likewise okay, so that is how we can see the report. So one more approach is also there, we can delete all the results, we can change the instrumentation technique with other option, this analysis we can delete and generate instrumented programs automatically with this we can configure instrument the code, we can compress the execution, we can compress into a structure, we can start the analysis of this selected instrumentation, let us see and again we can say run on the target, this instrumented code it is simply captured all the iterations and the structure is going to populate all the analysis, now we can upload the execution history, we can analyze the code it has built already okay, let us halt the current execution for that instrumented code and we will see what is the result of this, now we will analyze in the files, let us select a project, we will do test manager report and see what is the report shows, now we can see main.c, how many times we have executed integer to ask, heavily enough code how many times, now you can see here one time executed these lines, lines of code here with instrumentation, we have not executed this again because we want to have a coverage, we can see the code overview with that option, you can see there is several overview, we know that entire project has showing as failed because it is short by 40% in terms of the statement and the brand decision is 68 and if you are not able to cover with instrumented or non-instrumented then that 40% or 32% of brand decision we need to do manually or some way of doing it with other approaches, that is what we need to do for the LDRA, okay so basically what we need to do is for coverage testing, we need to have a source, we need to have a script and the appropriate selection should be LDRA tool and execute it and we need to establish the coverage tool, then structural coverage analysis for the entire project like this and generate the different metrics of statement, decision coverage and report the entire set is what we have done, the earlier demo we have a stubbed function and create the testing tool, the help of LDRA unit test tool, okay so with that we will end today's session on the practical thing about the next practical session we will take up the next one and demonstrate the next practical demonstration, okay.