 next session of embedded software testing is a unit 4 series of lecture series today is lecture 2 we will study and discuss more on embedded software testing software integration and we will try to see the test strategy and its benefits and comparison of different strategies then top down bottom up advantages disadvantages integration testing other types also will discuss and before that I just would like to have a recap and add some more points to what we had discussed in the last session that was integration we know that three levels of testing we can do component integration and system so basically we do individual components and those are under test when we do the unit testing next one is the integration testing where we combine logically different components based on the complexity or the feature wise or the functionality of those components then we will interact with the other similar logical or interactive groups to make sure that those are getting integrated and the behavior is verified the last type will be the system testing where as a black box everything will be tested so basically what we do we define the test objective for integration test which what qualifies the system we want to verify then device the test cases program the test is equal to test and analyze the results will follow for testing then we had gone through integration testing definition the process of aggregating different components to create larger components so that larger components can be tested together with similar larger components integration testing done to show that even though components were individually satisfactory a combination is incorrect and inconsistent a combination is very important is not just enough to test at a component or individual level so we also had gone through definition of what is integration so basically we it is not enough to have unit testing alone to get a stable or functional correct system so many defects are related to the integration of modules if the requirements are not formulated for everyone has to make their own interpretation of those requirements basically so this is not a problem as long as these interpretations are not related to interactions with other modules but incorrect interaction between modules is often caused by these interpretations it is the problem actually so what is the best instrument to detect that is the help of integration test so basically integration strategy is addition about how different modules are integrated into complete system integration covers both hardware and software as I said in terms of hardware it is called as hardware or software integration and it is called as software integration it is basically the different software modules and their interactions will be verified and system integration system hardware integration system software integration rather terms of embedded system integration are defined the task of creating a properly functioning system form its constant components the components could be hardware, firmware, software whereas in system hardware integration are the components wired together correctly that means especially the hardware components are tied properly within the system and those components are tested against their behavior and the last part is system software integration where typically it assumes hardware integration is largely done there are no issues with the hardware but before we deliver or accept the product software modules will be verified with the hardware how it is behaving and all that that is what we do with the system software integration so integration steps basically we need to create list of all software components identify the grouping and dependencies between each of them list of the strategy to perform these categories of integration the list could be based on the aspects like functionality performance, system integration or interaction, databases the kind of database that we use and what interface especially from the signal perspective how it is derived then the control of the various program elements then safety and security aspects and conformity okay so basically the goals of software integration is to expose faults in the interfaces and the interaction between integrated components to find collaboration and interoperability problems and isolate the causes to reveal interface and cooperation problems as well as conflicts between integrated parts so the faults could be in terms of interface such as the formats of the memory or define which is not compatible whereas it is working individually but when you interface with the external memory or any file handling that could be the issue similarly the data exchanges are not properly there type casting is the issue when it interacts with the subsystems all this sort of a interface issues and coordination or cooperation problems within the modules will be revealed and we have types of integration as big bang integration bottom up integration top down integration I mean is how the approach to the integration is been done sometimes component integration test is also called as integration test that is considering the small integration test so system integration test is also called integration test in the large system where the external systems are more involved so it depends on the complexity of the system so in big bang it is a simple testing type all modules are integrated and the system is tested as a whole basically so completely the system not the end system but the system which is enough to test it that way it is going to be banged from the testability perspective the main advantage is that no subs or drivers as we have seen are required for this so with this strategy it is the problem is too difficult is difficult to find the causes of defects and the integration can only start if all the modules are available and flake it is not like a step-wise product mapping so basically it is coupling with the entire system similarly we have seen after all components are testing done we will test the entire system with all its components where it is advantage the next type of integration testing is the bottom up integration testing this strategy is useful for many of the systems it starts with the low level modules with the least number of dependencies that mean basically it uses the drivers test drivers it is called the integration can start very early in the developing process that means you do not have to wait for all the modules to be completed and then when the modules are done we can write the test drivers and start the integration test for the completed one and implementally we can close all the modules basically advantage is that you need to have the detection of interface problems and these problems can be isolated very easily this advantage is that may have to deal with many test drivers and we have to use it for carrying out different strategy and it is a tedious one and we also had gone through a bottom up integration testing example where higher level module A and lower level module B and C are good so basically we develop a test drivers for B and C so we test B and C individually then we test A such that it calls B so if any error we know that there is a problem is in A or in the interface between A and B similarly we test A and we develop the driver such that it calls the C and if there is a error there has to be in A or there could be between A and C okay now next type of integration testing is top down integration testing in this strategy the control structure of the system takes the lead basically the control structure is developed in a top down sequence and this offers the ability to integrate the modules top down starting with the high level control module at every new level the connected modules at the corresponding level are integrated and tested as we go down the connected modules will be tested one by one the role of there could be some non-existing modules also that those can be replaced with the stubs here we use term called stop and drivers we use it at bottom up and test stubs we use it in top down so advantage is that look and feel of the entire system can be achieved that means user has an idea of what are the top level modules how it is architected and how it is getting flow down into individual modules that is the advantage of taking up top down integration this one is that impact on low level modules may lead to changes in top level modules so we do not know what is the impact and we may have to wait for all the modules we cannot do a progressive thing until otherwise the top level module is done so that some if any one or two low level modules are not done so we need a number of stubs for every integration stuff so we also had gone through an example of top down integration where a bc3 modules a at higher level b and c are low level so a will test it individually with the help of stubs for b and c test a such that it calls b stop for c and if there is an error we know that there is a problem in a b or in the interface between a and b similarly while we are testing c we stop b so that all together we focus on c and if there is a problem the problem has to be in c or the interface between a and c so the advantage and disadvantage of integration testing top down and bottom up or we will detail out in today's session we also know that test drivers are not in grade or only simple ones are required as advantage because the higher level components that have been tested serve as main part of the test environments so we do not have to have test drivers we already have a top level module these seven days that low level components not integrated must be replaced by stubs because we are not done it or it is not integrated or so this can be expensive because we need to develop the stubs bottom up advantages that no stubs are required but the seven days that high level components must be simulated by test drivers so user will not have will not have any idea about how the top-level models look like how we can approach the integration testing that is the disadvantage and also the importance of why we need to plan the integration so basically successful integration will be enabled with a critical status such as objectives responsibilities and resource planning so that we know at what stage what are the type of integration we are going to do and how the cohesiveness is going to be achieved so basically the product lifecycle or the product lifecycle outcome is purely based on the integration so the customer asks track or progress of development he will similarly ask the progress of integration the first question you will ask is are you able to integrate and test it the models that we have developed how is it going on how is what is the performance of integration testing whether you are able to integrate all the components whether you are able to interact with the hardware of the actual system how is hardware software integration going on how is software models interactions behavior is going or progressing so all the sort of other things is an outcome of the integration testing so definitely there is a need of plan for the same because it has a lot of stakeholders including resources time personnel which are going to be identified for planning that integration similarly integration considerations that we need to have is that we need to have an understanding of architecture system decomposition architecture considerations could be open or closed architecture or integrated or modular architecture likewise depending on the type of system that we are going to do definitely there is a architecture or high level design that needs to be considered for integration and also we need to have an understanding on the interfaces all the interfaces are associated for types of one logs or discrete that are getting involved all this will be part of the interfaces the signals the next one is the hardware considerations in terms of hardware limitation so it could be anything so we need to have a idea of the hardware how it is built because without the hardware we cannot be able to test many of the software models because tightly coupled with the hardware the last one being the software consideration we know about the software models have to be very cohesive so that they can be tested appropriately on the hardware some examples I will try to provide interfaces that you are care about what sort of a used the interfaces could be memory, port such as RS32 or CAN or SKY etc. SPY also is another example next we have a timer next you have a power interface it is also very important where some of the power of requirements have to be catered such as within so and so time the booting procedure has to be completed and system should be up in certain time so there we will look into some of the features or any interrupts based on the power that also need to be considered for interfaces of course we have unlock interfaces, discrete interfaces this could be any switches, signals, LEDs all this will be discrete interface then motor interfaces it will be best less motor or stepper motor whatever it is again this depends on what sort of a drive we have it could be through any of the port or it could be a parallel bus or it could be an unlock interface but basically the end target is the motor so how we are going to interface with it actually so very important for us to understand if the system is a motor based closed loop control system definitely we need to have a fit that mechanism understanding by the system system of course we have DC AC motor interfaces set types of interface okay so hardware related interface so we know that the hardware input output need to be cohesively used in the system integration test so that is also very important software interfaces in terms of like any algorithms, checksums, computations all this will be multiple all the further all these things will have a multiple components involved so definitely we need to consider the software aspects of the integration that is very important okay so the last part which we had studied the last session is that integration test strategy ad hoc strategy is to integrate the components in order which they are ready so there is not a good idea basically but you can do it you can afford to do it in the beginning of the program as a component has passed the component test check if it fits with another already tested component and or if it fits into partially integrate subsystem we need to see whether the component when it is ready where it can fit whether it can be tested first we need to identify the components it is associated integrated subsystem or associated component where it is going to fit then accordingly the associated one also need to be addressed to make sure that both are integrated properly we need to write steps to help the integration step is a skeletal or special purpose implementation of the software component used to develop or test component that calls or is otherwise depend on it actually it replaces a called components that is why it is subuse and the other way form of a stub where we have seen in the top down is drivers where the high level components are going to drive the low level things sorry in the bottom up a strategy okay so that was about the previous session now we will go through the integration test strategy in detail we know that steps and drivers are needed for integration test so it is nothing wrong in having both actually it is again subjective where we have to take a call it depends on the complexity of the embedded software system elements we can have both bottom up as well as top down approach so it is again dependent for larger systems where we have millions of code definitely we need to divide the entire system into several subsystems those each several subsystems can be addressed in different strategies in terms of integration but all that have to be planned appropriately either it could be bottom up or it could be top down or some subsystems so we don't need to have a integration at the top them on top down or bottom up we can go for the big bang integration where the entire model entire group of models can be tested all together so that strategy also we can adopt that is again subjective okay so we have gone through that various types of integration test strategies so we will try to compare these based on the book years 1779 so the table basically lists out different types of integration strategy we will not focus on sandwich and modified on this type of embedded integration testing so these are another type but they are rarely used or it is not required to be understood at this point okay so you can see the features that are listed in the left side of the table and on the right hand side we have a different type of types of integration strategies bottom up top down what if I top down big bang so basically it identifies integration when it should be done so bottom up early top down modified top down early big bang at a later stage because all models have to be completed time to basic working program very late bottom up early early early late so here to have it a matured working program so bottom up will be at a later stage whereas in top down early stage we can identify the understanding of the working system component drivers needed yes for top down we need sorry for bottom up we need not for the top down modified top down also can have test drivers our component drivers is also called a big bang definitely request drivers stop seated we know that it's needed only for top down approach not the bottom up so what parallelism in beginning the ratio is something like medium bottom up top down is low modified top down is medium and a big bang it is very high so that means parallelism need to be worked out ability to test particular parts what is the difficulty so bottom up it is easier and in top down it is very hard and modified top down it is easy and big bang it is easy ability to part plan and control sequences is easier in bottom up because we have a control on the smallest of the components in the entire system and very difficult for top down we don't know the exact sequence until we go through each of them big bang it is easier so these are some of the metrics they have compared for integration strategies what if I top down is something like a mix of both top down and big bang so they adopt in some of the medium size mix size complex integrated systems that is where they use it okay so that is about strategies of different integration types now we will try to go through top down advantages and disadvantages is basically from book called Stuart Anderson material got from the web which basically list out advantages and disadvantages such as in top down if major defects are more likely at the top level model top down is beneficial that means we have more issues in the top level then is going to be advantages getting input output functions in early can is test rating that means as long as we have developed the more important functions in the earlier stage the top down approach will be beneficial without the integration strategy of top down so early demonstration of the main functionality can be helpful in highlighting requirements issues and in boosting the more that means as I said you have more clarity and idea of what the system is behind and your understanding will be better as we progress on the integration testing of this type top down approach because you start with the main functionality or we top level models now let us look into the disadvantages of top down is too much effort for stubs you know that top down request stubs because low level modules are not ready or not enough to test then we may have to leave it the test stubs for the low level low level what else and also another problem is while developing the stub if it is more complex it can inject the medicinal issues or introduce the loss disadvantage different stubs can be difficult if some code is there to be written so we are unclear about what exactly is going to be but we are having the knowledge of that functionality based on that they would do the stub but sometimes it is difficult to develop a stub where the code is there to be written it may be impossible accurately to reproduce test conditions if there are failures suppose we started top down testing and we found out that the issue is a system it is very difficult to figure out or isolate where we test issues there and how to reproduce it so some of the issues like intermittent issues are very difficult so that the disadvantage with top down testing some observations may be impossible so we cannot observe some of the minor elements of the top-down testing modules encourages the idea that test and development can overlap that means top-down testing have a close relationship with the development aspects so basically it encourages the idea that test and development can overlap encourages differing full testing of module because low-level modules are not complete so we are living only with the high-level module and basically we may not be completing the entire integrity because it is partially done partially passing some of them low-level modules are explored such things are difficult with the top-down integration testing the next one being the bottom-up testing so what we do here is we know that test drivers are needed for the bottom-up testing and advantages are such that helpful if errors are likely deep down the dependency structure so if the system implementer they think that it is more complex at the deeper level especially on the device drivers or the hardware interfaces then it is better to take up this activity it is going to be advantageous the bottom-up testing test conditions are easier to create basically because lowest of the modules we need to understand and create the test conditions observation of test results is reasonably easy it is the effort in creating sub-modules we do not have to spend too much time creating the steps the servant is that need to create driver modules but arguably this is easier than creating sub-code and tools like some GNU is what he has offered there is not both about that but basically driver modules we need to create so we need to have an understanding of that that is the servant so but it is easier than creating the stuff because we can see the code and we can try the values what we need to develop the driver the entire system is subjected to the smallest amount of test means we are focusing only on the smallest part of the entire system because the top modules are included in the test at the final stage we are not addressing at the high level incrementally we are testing one by one on the bottom most low-level modules and as we grow into the high level we are going to test at the high level test so those are the advantages and disadvantages bottom-up and top-down integration testing and the test-advice now there are other methods of integration testing also just to touch base what are those okay the first one being these are all basically referred from sources how they have followed in terms of defining them or creating because every industry is typically different than in general actually they will adopt based on the need and complexity the skills and the compartments rules so many aspects are there all this need to be considered as a for the model rights based on that they will decide and they will define the name for that type of a integration testing strategy okay next type of integration testing is a hybrid testing it is also called as a combination type combination integration testing so it is clear that judicious combination of stubs and drivers can be used to integrate in low-level approach as I said it may not be purely possible to use stubs only with the entire integration or it may not be feasible to use drivers along for the entire integration aspect sometimes may have to mix up both based on the complexity and that type of the kind of system that we are trying to test it so we need to do a judicial approach of combination of this so we need to take care of this based on the type of system that we use so that is called hybrid test strategy which uses both as a for some groups of a modules we may want to take a non-interate non-interative approach and just consider testing them all at once this means we choose a bigger brand for some of the groups of the models we may not be able to take up for the iterative like bottom-up and we can take separately as a one-shot testing when we are doing the other dependent models those kind of the things also can be done depending on the type of models that we have so this comes under the hybrid test strategy so using this approach there are range of potential criteria for designing how to group those models so basically hybrid test strategy deals with groups as I said grouping is a very important aspect in integration testing your grouping is based on the each of functionality requirements performance etc so so there are different criteria that we need to follow for grouping the various modules so what are those one is a criticality decide on groups of modules that provide the most critical functionality and choose to integrate those those first that means we identify critical groups which are very important to test very which are very important part of the entire embedded system first you address that first you group it then rest of them will form that is one of the deciding factor then the cost this is also equally important look collections of modules with few dependencies on code lower in dependency lab and choose to integrate there first the goal here is to reduce the cost of creating stuff code that means sometimes what will happen is we cannot be doing stuffs all the time you got is going to add a cost so we will take a generalization based on how much cost for the development of stuffs so if it is going to be too much then we need to collect such modules which can have many less dependencies on lower part of the code so that the stub we do not have to have much so that the cost is appropriately taken care so these two are very important here cost means not the rupee or dollars is basically the effort of course at the end of the day all it matters is the money but we look for the efforts how much effort is going to take and complexity or criticality these are some of the important deciding factors for identifying the test strategy but bottom up and top down they have their own advantages and disadvantages where you have a system having complexity its my solution such as closed loop and more interfaces and dark systems I would say moderate to large these kind of systems I suggest to have hybrid test strategy where it makes us of both test hubs and drivers test hubs and drivers means top down as well as bottom up so both being followed coverage and all are the second aspects once we have that integration then with a satisfactory test coverage and test report for each of the modules automatically coverage part and wherever the gaps are there when we can fit into any of the test strategy such as any testing system testing all can be taken so basically we need to address the entire system from this aspect so that is where hybrid test strategy comes into picture but before I build we need to understand what is bottom up and top down so that we have an appropriate mix of test drivers and subs so that is where is important so there are other types of integration we look centralized integration this type of integration is used when central part of the system is necessary for the rest of the system to function that means without the central part nothing works that is hot of the system for example a ys or a kernel so definitely we need to first address the the kernel or the opening system first that is centralized and surrounding the centralized part there are subsystems which can be tested subsequently the central part is necessary to run test on it is too difficult to substitute this part with a stop right so we cannot replace a way is with another way is has to be there or a way is only for testing so that is the central part of the program of the entire software system the architecture of the system is such that the central part of the system is developed first and made ready for production that means this kind of systems what they do is first they develop the kernel or the scheduler of the OS and surrounding that they will incrementally develop subsystems so that is how the architecture will be laid out first so after that the new models or the subsystems are used to upgrade the system or to add completely the updated functionality or the new functionality so that is how centralized integration is going to be done but here also again centralized systems so we will have subsystems those subsystems we can adopt either top-down or bottom-up or hydric whatever it is depends on the how large the system is or how complex the system is so it is very important so there are other types of integration testing we will discuss one or two lines for this layer integration this strategy is used for systems with a layered architecture where we have application and libraries where the systems are there so this type of integration testing they use it so in this interfacing only happens to be in the layer directly underneath the below and the above so go and talk about the complete bottom-up or top-down sort of a thing but each layer is tested in isolation using the top-down or bottom-up or big-bang strategy the next step is the integration of the layer according to a top-down or bottom-up order the devotees and disadvantages are the same as top-down and bottom-up or strategy the integration and isolation of the interface is much easier and therefore discover discovery of the causes of detects defects is also easier because we have addressed the layers so based on the layers different other layers are going to be integrated next type is the client-server integration the strategy is used for client-server architecture where we know that database in the server and the client where we have this strategy will be more appropriate the client is integrated either top-down bottom-up or big-bang and the server is substituted by the sub and driver we can use the stubborn drivers for the server the same approach is used for testing server itself the top-down bottom-up and the sub and drivers are developed for the client finally server and the clients are integrated collaboration integration basically a collaboration is a collection of objects which work together to achieve a common purpose for instance realization of a use case will study what is use case and test cases period of use cases the later stages the system supports many of collaborations because it has to realize many use cases many objects belong to more than one collaboration because we have lot of collaborations based on use cases and the scenarios so basically the collaboration is a focus here so choice of the collaboration will become the necessity in terms of covering the complete system so that is how collaboration integration is done so basically they use for object-oriented systems or object-based systems and which basically covers the components and interfaces where the collaboration is more this also has advantages and disadvantages similar to top-down and bottom-up where interfaces are not here dependencies are more likewise something like a big bang sort of a thing because most of the components are collaborated together and only when the collaboration is complete so integration testing will start something like a big bang we can call it this collaboration type of testing but it doesn't require a full sort of full-fledged integration testing only few tests are enough actually for the end-to-end functionality and the overlap of the collaboration features so this is a very subjective again to choose what sort of an integration testing we need to have so we have studied a bottom-up top-down big bang this list out of the type of integration testing on the start list that we have a couple of scenes so top-down bottom-up what is the other one big bang next one is a hybrid centralized layer but it's above for you are very important most of them are used additionally we can use integration so likewise many types but these are the main type of integration types that can be looked into next up so once you have identified the integration testing types all the strategies of the integration testing next step is to identify the environment on the integration models how we are going to have so basically for integration testing environment it's mix of a component unit level and a system testing it's both it takes care right so definitely we need to have an environment which supports both unit level sort of environment and system level definitely so we will have a need of a test driver and stops we can use the reuse the test drivers that were used earlier for component testing that's why we told that mix of component testing because for doing the unit level testing we definitely develop some test drivers those test drivers can be reused for integration testing so additional tools like the monitors may be required to read and log the data traffic between components and all that basically why we are interested is to interface between these components and while doing the intervals definitely we need to monitor how the data is getting interacted so to understand the flow of the data we need to have testing environment identifying different tools such as monitors so integration test environment for the software unit and the system integration or software integration test a test bed is created that is comparable to the test environment for the simulation model that means we are going to have a test bed it's basically called as a test bed which will have an environment which is going to be used for unit level test as well as the integration test identifying all the interfaces and the hardware modules and all the necessary inputs which can be compared with the simulation of the test environment in the prototype stage test object is an executable version of a software unit or a set of integrated software that is developed on basis of the design or generated from the simulation model so that development could be based on the model or could be based on the code so we can develop the prototype sorry we can develop the integrated software based on the code types that have been developed software for the test environment and that the specific execution or executable version of the software unit will be used by the integrated software units so that integrated software units are basically develop the base on the basis of the design or the architecture of the embedded system that is how the test environment or the test bed is going to be formed for the integration so the first step is to compile the software for execution this is basically a build process for the integration test environment so first step is to compile the software for execution on the host computer the environment has to has no instructions sorry no restrictions on resources or performance and powerful tools are commercially available so basically we need to compile on the host first because we have developed the code in the host we need to compile it based on the standards this makes development and testing a lot easier than in the target environment we are sure that we cannot afford to have on the scratch from the target only first host level we will get the components by compiling and collecting all the information installing tool and all that so this kind of testing is also known as host target testing first we are going to develop the host based environment and try to test as much at the host then we will try to target on the target system the goal of the test on this host compiled the software which and integrated software will verify their behavior according to the technical design and the validation of the simulation model used in the previous stage so this incrementally that is going to be validated based on the simulated environment that is done first and the second step is software unit or software integration is to compile the software for execution on the target processor of the embedded system so we are so far done on the host target based environment I think we have studied in detail simulator emulator and all that similar to that same strategy but here the focus is on the interface integration of the different models so second step is basically we are going to develop for the target and before actual execution of this software on the target hardware the compiled version can be executed into an emulator of the target process we know that there are emulators and with the emulator we know we can see the code behavior and the functionality cloud and all this at the target system before actually we execute this emulator may run on the development system or on another host computer so the chance of that the emulator can also be used on the same type of portable systems so goal of this test is to verify that the software will execute correctly on the target processor basically the software will if compiled on the host should work same way as it has been tested on the host on the target system so that is where it is very important to have this environment identified and used okay so so there is a table here based on the book simulation level for the software unit and software integration that is basically this basically identifying based on the test bed that should basically offer the stimulus for doing the test so we have embedded software and what sort of a processor and what can be tested on the system and the plant what sort of a simulation we have the software unit software integration software integration so first it will be tested on the host as an experimental basis and the processor we are not going to use the target processor we are going to use the host processor such as x86 because most of the personal computers will have x86 based architecture but the tools will support for the compatibility on the target system so rest of the embedded systems are simulated apart from the experimented host the second type of is testing the unit or the integration is on the target the actual environment or the target environment here we use the emulator and rest of them can be simulated so this is how the test environment can be brought up so but both the situations the test bed must or should give a stimulus for the input of the objects and provide additional features to monitor the behavior of the test object and to record signals basically to validate the signals and all that they should support this environment and basically this can be done with the help of break points storing reading memory manipulating the variables debug steps and call trace call stack all this can be high using time machines performance analyzers all this can be used they should be supported in the test environment so continuation of was integration to say normal in the hardware software integration test the test object is a hardware part means the integrated software is loaded the software is incorporated in the hardware in memory basically a flash or a score the piece of hardware can be an experimental configuration for instance a hardware circuit board containing several components so hardware is the focus here hardware software integration the goal of the hardware software integration test is to verify the correct execution of the embedded software on the target processor in cooperation with the surrounding hardware so that's what is the elaboration of what we have to find hardware software integration because the behavior of the hardware is an essential part of this test it is often referred to as hardware in low higl so there are different types of in loop situations software in loops simulation in loop hardware in loop so basically these are all integration that are going to be used so that is where it's necessary to identify the test environment for those hardware where we need to have an integration continuation of integration test in normal the test environment for the hardware software integration test we have to interface with the hardware depending on the test object and its degree of completeness the following possibilities exist basically it offers input stimuli with signal generators output monitoring with the oscilloscope for the logic analyzer combined with the data storage devices in circuit test equipment to monitor system behavior on points other than the outputs so these are some of the environment dependent tools that can be used then simulation of the environment of the test object in a real-time simulator so what we do is basically we have a test hooks or interfaces from the target systems with the help of those hooks these tools will be plugged and logic analyzers oscilloscopes or signal generators that can act as an input or output to conduct the test that is what the meaning of the test environment here integration test environment yeah so in integration test environment basically we identify all the stimulated inputs and will focus on the captured output and the tools that are used that are going to be used for capturing the output so that the end-to-end path is verified so that is the focus of integration test environment basically so we will continue the test integration and integration environment in the next session and we will try to elaborate more on the integration environment and generating test cases from use cases example of use cases and how we can generate and we will also try to understand regression testing etc in the next class