 నవకివందిందిసి ఇరుతిందింది చినంద౿ందింది అందిందిందింది. సిఇమటిచి. అందారూది ఓపదికికిల౾ సిరరతింది v. అంది . and we study more about selecting regression test, test maintenance, regression test build process, what are the steps that are involved for regression testing build process, test strategy and we will try to recap the session of the unit for all the sessions. Before that we just do a quick walkthrough of what we have understood in our earlier session, we understood about integration test environment, like it could be host based processor or emulator or it is a actual target, so we have different sort of integration software unit level, software integration level, software to hardware level and hardware to software level, so likewise we have integration test environment defined and also there is another aspect of integration test is a system integration test which involves system level where we actually use the real target as well as the rest of the embedded systems surrounding that also will be a real one, I mean in terms of pre production one where we use actual models or prototype models of the other embedded systems which are required, for example if any input is need to be triggered, we are going to trigger with a actual function generator or whatever it is, we will not use the stubs or any drivers for driving the values, so that is where system integration will take care and next to that is the actual system test which is on the production mode and also it is a acceptance test where we deliver the finalized product to the customer with a sampled acceptance as per the specification that is required, so that is a typical V&V aspects for the or in the industry they follow basically. Now also we studied about integration form use case perspective like we have a user perspective understanding the embedded system and lot of scenarios will be drawn, please scenario can have multiple or a single test cases for each test cases as usual we will have a test case procedures scripts and execution philosophy and basically the observed behaviors of the system will be perceived from the user's perspective that is where the use cases are going to be used, so if you have a models or architecture written such a way that it can be tested from the use case perspective it is good to have integration done from the use case perspective, so what we do is we first describe the users or the actors and describe the scenario and for each of the scenario we will write the test cases, so it is called as gold driven now use cases and generating the test cases form use cases basically there are lot of tools are available first we develop the use cases with the help of tools such as UML unified modeling language basically it is a modeling language where we predict and model the embedded systems in terms of various diagrams but for developing the test cases we represent use case diagrams we will try to understand few examples of use case diagrams today though it is not part of the scope but I will just try to explain one or two steps and typically the use cases so we will have a name of the user or the tester or the actor it is called as and the description of what the use case is going to do or the what the user is going to interact how it is going to interact next one is the flow of events what are the flow of events that user can do and any requirements that is getting addressed any special requirements that is getting addressed and three conditions for doing that flow similarly post conditions after that scenario is being completed so likewise we are going to have use cases and accordingly we are going to generate test cases you can see an example here figure what we have seen it is a basic flow of events and alternate flows you can see in red mark the events as a use case here there is a difference this is grounded grounded in the sense it is going to end there end of use case they mark this way but typically the flow basic flows around that the alternate flows will be drawn like alternate flows one two three four depends on the type of system that we use for each of these flows we are going to have one or two test cases you can see example one or two one to five test cases are written the test cases can also have multiple flows involved because we need to achieve to reach the path that is why we need to generate so basic steps for generating a test case involved for each use case generate a full set of use case scenarios for each scenario identify at least one test case and the conditions that will make it execute and for the test case identify the data values that is the objects or the inputs that are going to be used with which we are going to test it the data values can also be a condition with which we are going to vary and trigger and the data values also I will have an expected output as well as the actual output that is going to be provided when we are going to that is going to be output when we execute the test case then after the use case example we had studied about regression testing regression testing can be divided as retesting and regression testing retesting is testing again and again regression testing is retesting on a previously developed program with the fixes to make sure that the faults that were there before are cleared this time so that is where regression testing is important so basically we use the same test suite the requirements will be same only thing is the code which had earlier bugs have been fixed and we have a new option of the build on which we are going to re-execute it is where regression testing is also it is called as a logistic strategy for maintenance testing we will try to understand what is maintenance testing in code section so the changes that are there in the systems are to be tested with the help of regression test suite but the chance of that along with the fixed test suite there could be an impact on the other tests also which could be failing now which were passing earlier so we need to be choosing the regression testing scenarios such a way that the analysis and the impact of the the fixes that are updated on the existing build needs to be written so the changes can be of three types it is on the impacted component itself specific changes or specific line or a small system small subsystem etc or a complete test retest of the function we may have to do it to make sure that regression is taken care also the third type is the coherence or the interaction of the change the components with the adjacent components of the surrounding models where the impact is there so all these three areas we need to take care regression testing test strategy definitely depending on the number of changes and the kind of changes so we need to evaluate what are the risks that are going to be evaluated and how we are going to plan and progress the tracking of the embedded systems for regression testing and sometimes we may have to take it as a new way of doing the test as if the code is being newly developed so test strategy is to change identify the or determine the changes determine the relative importance of the changes and regression selecting quality characteristics determining the relative importance of the quality statistics determining the relative importance for each change of the quality characteristics combination and establishing the test techniques which have to be used for regression testing areas are regression fixing the fault regression can be for added functionality regression can be on the same build the same requirement same specification but it is on a forwarded platform or a new platform regression can be due to new configuration or after the customization of the software software has not changed but it is configured for a different values with a different customized situation regression and delivery planning that also need to be planned regression testing automation is also one of the important where we are going to develop regression test suits under configuration control so automation can be developed over a period so that every time we do not have to re-execute certain bundle of test manually so we can automate those batches as a automated script execution so that regression can goes smoothly and it is going to be an interdental development and there is a regression test matrix the relative importance of changes on the regression the changes could be due to change requests that are occurred during the fixes or new features whatever this the changes could be due to defects that are identified during the testing and the importance could be 30 to 40 percent 10 to 30 percent based on the type of system that we have so that is how the relative importance of regression they will be working out the basic problems of regression testing maintenance test suit and cost of re-testing if the feature X is changed how many test cases we have to execute for that feature or impacted X because the revised X could impact on the other areas as well and what test cases I need to remove should be added all these have to be taken care so we may have a test suit or the test bench or with the batch files but in that batch files all may not be needed because we are wasting unwanted things we need to choose so that is the maintenance so it is going to cost some effort and cost of re-testing often proportional to product size not change size so basically what sort of a change we have and what is the total size of the product so that drives the cost of re-testing so basically it requires a manual effort for doing the regression at times why because changes are too much and we cannot afford to have the same sort of a automation sometimes the changes are very minimal so entire bunch in don't need to re-execute we may have to choose or tailor the existing automation aspects so that is what we have studied about the regression testing and the areas and the types of them today's session we will try to understand in continuation of the previous one use case diagram example I will just brief it so this is a typical use case diagram you can see this diagram is drawn for an elevator system you see use case have a actor and this elevator is a function block so there are different scenarios you can see they are all in all shape process car calls move stop the car open close the door indicate moving direction process all calls indicate car position trigger emergency brake so all these are different scenarios that are used and this can call for different test cases so that is how we are going to have use case with the scenarios actors and the function box and each of the scenarios need to be explained appropriately so that test cases can be drawn easily you can see another example not sure if it is clear there is a operator or the user so this is basically a operation of audio you can see user can do a designing audio or the recording audio this basic functions he is going to act and this vision audio can further have different operations or use cases or scenarios something like power on play pass adjust volume stop similarly the record audio can also have this stop etc so these scenarios for each of the same goes after seeing this is easy to draw test cases right so it is important to have such models having the use cases drawn so that the entire architecture for this operation block for example can be tested with the help of test cases so it is easy to test right so probably we will try to develop a test case as an assignment for this particular use case in the one of the session in the future lab so that is how use case diagrams are be useful and be used for integration testing okay so basically the main contents of the use case diagrams are use cases itself that is completing with the scenarios then the actors you can see it can have multiple actors also because multiple users or users means does not mean that a actual end user it can be any function block which is calling sub function or if there is an input or the triggering condition which can call for these flows so that is how the actors are defined and the third one being the dependency generalization and association relationship how it is going to be associated with the diagram so these three aspects or the contents will be there in the use case diagram with the help of this the test cases will be drawn okay so coming to the regression testing regression test cases selecting and prioritizing the tradition test is also one of the important point in the regression testing so the question is should we rerun the whole regression test if so in what order the order is also very important because we have different test cases flown in different manner so and the ease of use that time referred and conclusion and the problem areas all this matter in terms of realizing the test we cannot afford to have a high complex testing to start with why because we will be spending that in the beginning only too much of a time and later stages it is very difficult to pick up the small ones so we need to have a balance of both the complexity as well as the simpler ones in order to make it a good order of regression tests so for this question answer could be something like maybe you do not care if you can rerun everything automatically or lunch break do it that means you have a confidence that that entire bunch can be rerun without any issues without any stoppage for pick time something like 2 to 3 hours then better to go for it for the entire regression suit or the bundle but sometimes it is not true we may have to take care like we have to break up the existing test suit into such a test suit that it is going to map and realize the regression areas where we have issues earlier and that is got resolved in the current execution and accordingly we need to prioritize the different side types of regression test suits and test scenarios so prioritization matters when a very large test suit cannot be executed every day so we cannot have every day operation in terms of test suit execution as a batch in regression testing so we need to prioritize what is the priority functionality a b c d so of course they are there and we have for each function four test suits for a b c d then we need to prioritize depending on the type of regression that means a a can have a high complexity that functionality is very key and important and we need to prioritize that as a higher one whereas other functionalities like smaller functions or a routine functions which does not require much attention can be having a low regression testing priority selection matters when test cases are expensive to execute that means if it is going to occupy a special equipment or licenses or special tools is going to cost more time then selection is also very important it is not just enough to have prioritization only prioritization and selection both matters for regression test cases because again there is a cost involved effort in all these sort of a issues complexity and dependency all these matters in terms of regression testing execution test cases are extensive to execute because they require special equipment or long run times or cannot be fully automated so this has been referred in the one of the more of present make a language book so nicely as I told that selection and prioritization of regression test cases are important okay so another aspect of integration testing or the maintenance for or regression testing is called test case maintenance sorry there is a test case maintenance is another aspect which has to be maintained for a period suppose the product is for two years and 50 percent of time is dedicated for testing definitely we need to have a an allocation and dedication of this aspect called test case maintenance where test cases need to be maintained because there is a chance that these test cases have to be revisited upon updation of the software changes in the requirement or customer confidence or multiple platforms etc so all this can be taken care with the help of test case maintenance activity so some maintenance is inevitable if feature x has changed test cases for feature x will be updated so it is not just enough to have a regression test analyzed and used is also important to have an understanding of what got modified or added or changed and accordingly we need to modify or alter the test case we do not need to have a test case started from the scratch because already we have a framework the preconditions and all that elements available we just so accordingly we are going to maintain it in terms of updating it some maintenance should be avoided example trivial changes to user interface or file format should not invalidate large example there is a document there is a small letter like I did some change test case maintenance of course is a big team but in general I say if the name of the signal is mentioned wrongly but test cases were okay so there is no point in doing such maintenance so you can just document and record it somehow or make a note and when we actually look into that any other impacted changes we can take up this as well so that this can be prioritized and updated when we are going to do it so some sort of a maintenance we can avoid for the heck of doing maintenance we should not be doing it there is a meaning of that this should be modular that means any dependency we should try to avoid as much so that that can be independently executed generating the concrete test cases from test case specifications for the concrete test cases we need to have it is also called as a golden test case so important word they use in the software testing if you have this this is the minimum minimal test case which is used as a golden test so that this works always so if there is something stuck something got issues and we do not know where to go do it so what we do is we will pick up this golden test rule or test case we will try to pass it on and execute so that this is fine there is some other issue specific to whatever we are trying to address in the other test case so this will isolate the problems that we have so that concrete test cases are very important in maintaining the test so or test cases that is where a test case maintenance is important the next one is regression testing build process how are we going to have the build process done for the regression testing you know what is build build is basically compilation linking and development of the software similarly we have the build process for the test equipment also or the test scenarios or test scripts also again they are going to a compilation and logically grouping them and keeping it in a proper place and making sure that license and all these are part of the build process and the bullets bullet points because the same is baseline inputs in terms of complete build and executable ones of code EOC that is called as that base should be available because without which you cannot do a regression test right so baseline inputs is one of the important input no change in requirements updated software that means the build has changed we have no change in test plan in testing it is still same but we are going to do a regression on the updated inputs such as EOC executable lines of code on the build the binary then the last part will be delta review and updates of the incremental updates so we need to review what got changed what is updated and we are going to do a regression test accordingly so these are some of the build process we are going to have for the regression testing so we start with the baseline input and we are going to analyze the changes and we are going to execute the software with this baseline input the baseline inputs will be provided through a configuration control basically configuration control will be done through various tools such as previous dimensions svm git product tools are there we will study that in the next unit test management or configuration one example you can see a diagram here that is been put for regression testing the build process you can see a repository of old binary and new binary will be added to the analysis binary change analysis this basically a process block where basically analysis of what was there before old binary and what is the change that is done on the new binary here means the executable code or the object that is going to be tested against and we are going to do a coverage analysis of the changes that are there so that what are the impacted areas that is being covered and how are you going to test it and for coverage analysis definitely use the old coverage old binary coverage or the old whatever we have executed earlier with our earlier test suite so that will be an important then we are going to prioritize the test suits or the regression test which we are going to start and prioritized list of test cases we are going to come up with list of impacted blocks not covered by existing tests that means what are the impacted blocks which are not covered with the existing tests that also will come out as an output of the test prioritization activity so this will be a typical test building process of the regression testing okay so having understood all the solution test case maintenance selection and prioritization of the regression test the one question is that if only its environment is changed we know that the environment could have been changed for the new thing is maintenance test is answer is yes why because migration from one platform to another testing another one testing should repeat the operational test with the new environment we do not need to execute everything or we do not need to maintain the testing or the regression testing only thing that we need to take care is the operational test which are very much coupled with the target platform or the platform changes with the new environment that needs to be considered and taken care so that is where regression testing strategy should adhere to okay so with that we end the session of this lecture and we will try to recap this unit of regression and the integration testing so what are the topics we studied so we studied about integration testing definition and types of integration we understood we also went through system integration hardware software integration software integration etc integration basic steps what are the integration steps that are involved types of integration big bang bottom up top down high disadvantages and disadvantages we studied and we also knew about where we are going to use the test drivers where we are going to have test steps we can combine both of them based on the complexity and the test strategy that we are going to have and also integration considerations we studied what are the steps that we are going to configure in terms of hardware software environment emulators etc integration test strategies and comparison we did with a table like in terms of usability and availability etc integration test strategies how are going to have integration test strategy derived it could be bottom up top down mix in terms of hybrid test strategy in terms of OSS operating systems or scheduler centric we can use a centralized approach also we can have a protocol or network sort of a testing with the help of layered integration testing approach we can have a database application embedded application testing can be done with the help of client server integration test approach we can have a collaboration mechanism where different subsystems are going to collaborate while doing the integration testing then also we understood about integration test environment where how the environment in terms of emulation formulation the actual target or host based testing are defined and used and also we understood about integration from use case perspective use case diagram example we went under we went through and also we understood how test cases can be drawn from the use cases and use case scenarios and also we understood about generating the test cases from use cases the various steps that are involved for developing the test cases or different use cases and the same others and in the end we have studied about regression testing test strategy and importance of automation and the last one being the maintenance test maintenance and regression test build process so all this we studied in the unit 4 okay in the next session we will start the unit 5 which is nothing nothing test management and defect management so that will be the last unit of the embedded software testing after that we are going to have practical sessions hands-on questions and Q&A sessions for the embedded software testing with that I will control this unit 4