 we need four so it is a new session series it is on software integration and the embedded software integration aspects of embedded software testing we know we need to have a software integration basically there are two things so that we need to be understanding embedded software integration as such is an activity of the embedded software life cycle and it should be considered as an activity from both developers as well as testers perspective that means to say that we are going to have integration definitely integration is the integral part of the embedded software development life cycle meanwhile we are going to test as an integrated unit how it is going to be so the second aspect in terms of integration testing we are going to focus so audience should not get confused with the software integration from developers perspective as well as the testers perspective so it should be separate entity developers have they have their own life cycle aspects in terms of integrating the various models basically here we focus on testing part of embedded software integration that is what we will try to focus on understand okay so to recap on some of the levels of testing just in order to understand what is embedded software integration we will see the three levels of three layers of software testing we know that there are about for example 12 components in an embedded software unit how they are going to be tested at different levels we know that component and unit level we are going to test it individually with the help of stubs or any other drivers or any other methods that is all a part of the unit testing where the individual units are under the focus and those units are closed with their objects data parameters and all that and on the higher side I am coming to the bottom part of the type of a levels of testing system level where all these 12 units are the components of the embedded software systems is completely put together and tested externally you can see the arrow mark outside the complete box you can consider M1 to M2 as a complete unit as a system and this system is being verified externally with external triggers or events or signal feeds and fault injections likewise so this system level the first one being component level the one that we are trying to focus in this series of session is on integration where there are different modular boxes which will be integrated to make it your system so we start with this component we have tested it the components are fine or the units are okay then these units basically grouped into the logical units so these logical units one logical two we have a logical unit three it can have multiple modules or single module whatever the way how it can be logically grouped so logical grouping is again based on the various aspects as I said in earlier sessions like its functionality complexity and any performance related any closed loop control system related all these feature files depending on the type of system that we have we are going to have the various logically divided units into different groups so that is what we do so here here we example we have one two three four units and one M1 as a one here the logically we cannot separate this M1 which separately put so this is what we do in integration where logical units are integrated so may be different types of integration testing software like bottom of top down big bang and all we will study that one more and the primary intention is to see that these modules when it is getting integrated how they what is the interactions what are the inputs and outputs that is getting handled by these logical groups is what is getting tested in the integration software testing that is the main focus of the embedded software integration process okay so now we will go in deep into integration testing the embedded software integration testing so we will try to understand the definitions scope objectives then we have considerations strategies we will take up the examples in the series of sessions of integration testing okay integration is the process of aggregating components to create larger components as I said we have different components we are going to aggregate them like M1 M2 M3 M4 or individual components we are going to aggregate as one logical group so we are going to aggregate those components so that will become a larger component we can call it as a component or a group group component whatever it is so there are five groups here in this example and we are going to integrate that that is what integration does so while integrating there are different types of testing aspects we are going to create test suite with the help of test environment and get the values for that group and try to get the output that is what the process of integration is going to take care integration testing done to show that even though components were individually satisfactory the combination is incorrect or inconsistent so testers goal is to make sure that it is fine and testers goal is also make sure that there are errors there are issues with certain types of inputs when they are combined each other so it is not just enough to satisfy individual component like M1 M2 M6 they may work individually fine but when they integrate each other what is the behavior of that so that is what we are going to the tester is going to test it so the objective is to make sure that the combination of these individual components are satisfactorily working or if there are issues that has to be brought out and the inconsistency incorrectness all this will be one of the errors or the failures that it could occur while doing the integration testing okay going with definitions that various people industry and web resources that we have just try to understand an integration strategy is a decision about how the different models are integrated with a component system the objective of integration testing integration testing in the small according to on the B standard 79251 is to find bugs related to interfaces between models as they are integrated together that means the objective is to find bugs related to interfaces between model as they are integrated together that means we do not have to integrate everything together we can do a progressive integration in terms of first you integrate the objective group 1 2 then 2 3 3 4 4 5 etc then incrementally add it and see the behavior how it is going to behave that is what we do with the modules as and when they are integrated each other the integration course both hardware and software as I said in one of the earlier sessions there are two aspects of integration software question which we understand so we have hardware involved software involved hardware is involved for what from a software perspective there are interfaces right interfaces could be using any of the hardware part like it could be a memory it could be a communication device or it could be a any signals all these are hardware parts so there is a driver also called device driver involved so there are of these interfaces we are going to interface with the hardware so that is what we do with the hardware integration software what we do we have calculations of the data algorithms on the complex features then we have a program flow plan in plan out I will not go in deep but you know that software modules difference different software modules can be integrated together it could be app like the data usage transformation into different low-level or high-level aspects like just to depict what we have is a three-layer actually let us draw simple mention the first player is talking about the app application second one is middle one middle layer you can also call it as a wrapper or you can also call it as a driver level etc the third one will be the actual hardware so we have a scope for integration into aspects what are those one is between these two this and this this and this other one is between this and this so the one between this and this as well as this and another application so we know that applications can be multiple right between application to application or application to another subsystem in case of any sub-process or partition the apps or autos components likewise you may have so all this will be called software software integration whereas the other part where you use the hardware and software involved such as application to drivers here application could be a middle layer or wrappers which will interact with the driver so this is called hardware software integration please remember that two aspects of software integration software software integration hardware software integration both have to be considered and taken care while doing the integration testing some industries what they do is they may not have the segregation of hardware software and software software they might have a purely software software they take care of the small device device drivers interfaces signals and all this between the software itself they do not have that configuration they can call it as a in general integration software or software integration but also the industry we have like aerospace or we have hardware to software integration software to software integration both are very important so integration covers both the aspects that is what this means integration covers both hardware and software the next one the integration strategy depends on availability of the integration parts that means if any subsystem library or apps third parties are software as a memory or any signal equipment etc so that availability is very important for doing the integration because we need to integrate them also as part of the complete embedded system the next one is the size of the system that means what is the size that system has how it can be broken up further include different integrated or modular elements so that is all driven based on the size your size means not the lines of code please remember as I said in my earlier class that size is not the LOC or lines of code it is the structure and the complexity of the system that is underneath the test of the integration software testing so that also matters in terms of working out the integration strategy the next one being the weather it is a new system or an existing system with added change so we know that the system is working stable and qualified and we want to enhance it or you want to modify it or we want to add some features so that information is also important in terms of integration so that the strategy can be one then the features of the functionality that is also important so what are the various features that needs to be tested like features could be extremely triggered or all these matters so basically a system knowledge is very much important in terms of hardware software integration or software integration is a very key element of the embedded software testing the integration testing the last one being the architecture you know that architecture basically has all the modeler and different blocks and cases use cases and sequences and classes and all that information so that is also very important in identifying the integration test testing strategy okay so we will move to next so from the web but I have collected some of the important embedded software integration definitions system integration the other aspect of the integration so we have studied about software hardware integration software it can also be called as the embedded system next one is the embedded software integration software the third being the system integration where all the individual complete components like external memory internal memory external signals on field related inputs in terms of firmware hardware so all this will be put together as a complete black box and tested that is called system integration it is also can be called as system testing but basically they define system integration that is third level of integration before that software integration and hardware integration complete system integration the task of creating a properly functioning system from its constant components so what are those constant components one is hardware other is firmware other is software so all these are constant components of the system integration the next one being the system hardware integration are the components wired together correctly that means whether here wired means not the we are going to check the harder part as such in terms of any wiring soldering that is not the purpose once that is fine we are going to make it validated make it sure that we are able to interact with those wired components that is all hardware or plug-ability aspects whether you are able to interact read and write through the memory and read and write to the memory or the external communication with a specified border rate and specified speed all these aspects are important just wiring may not be sufficient it has to be done appropriately such that we are able to do the interactions in a intended way what specification or the requirement talks about so that is what the system hardware integration does the next definition is system software integration is typically assumes hardware integration is largely complete is the above part is almost done the initial step before acceptance testing and deployment so this is the last step they say but during the software integration is also one of the type we do for putting all together the build the compiled software piece into the completed hardware so that is what we do with the system software integration so we have hardware hardware hardware software hardware software and complete system so these three levels of integration testing we will do it the next thing of the integration so basic of the integration what are the things that we are going to take care of this primarily what I am trying to put here is integration itself is an activity this can be taken credit from the testers perspective as well as developers perspective definitely developers will have to follow some of these strategies or elements of the integration like you need to take care of software software software hardware involvement but its focus will be from the developers point of view whereas testing testers perspective is from unit perspective in terms of integration and how they are integrated and how we can make it fail or what are the injection in terms of error or faults that we can try so that the maximum performance will be done so integration testing basic steps are as per below create a list of all software components as I said we live with different components in the earlier example slide I have put about 12 components so what are the software components that we have the next step is identify the grouping and dependent between each of them so once we identify different components identify the grouping aspects like how these individual components are coupled each other and what is the dependency of each of them because a one functionality or couple of functionality or functionalities cannot be implemented definitely we have to break it down into individual software components so we need to identify what is the dependency and the intricacies in terms of the grouping between each of them that is another aspect that we need to identify then in the next example I think what we are going to do list out the strategy to perform these categories of integration that means we have identified the grouping and the dependencies how we are going to test this grouping how we are going to test these dependencies between each of the couple that is what the strategy the strategy will bring out all the aspects of integration like hardware software software and system software or the system integration to perform these categories of integration so basically the list should identify the category of integration such as well let me the category of different categories of testing strategy so what are those functionality performance system or structural integration we have a database we have interfaces we have control security or safety conformity so these are some of the steps that are to be taken care so I will just try to draw a small table here so what we do with this is we will try to identify the various list various integration aspects first provide the list of all software components they want to identify grouping aspects they want to identify strategy then may be in another column we can have category so these four things are first identify in a typical integration test strategy tool or a sheet I would say this is basically a identifier which identifies these aspects what are the steps that are involved for integral so first we are going to create a list of software components so this will list right I am just trying to draw an example of how we can restore the steps so first thing is you create a list of component like we did there M1 M2 M3 we have M2 right in the earlier slide so we are going to group together so maybe we can group M1 M2 M3 M4 as one group then M3 M4 M5 M6 like this so we are going to identify group with that name group 1 group 2 likewise we have group N so how we are going to group perform the grouping is basically identifying the similarities of different software functions is how they can be grouped and the dependencies that each group or the software functionality is that it has is one of the identifier with the help of that these two columns are next for each of this group what kind of a strategy I can have what kind of integration strategy I can have whether this can be done with the functionality in terms of externally injecting some values and this can be done with the help of any tools in terms of memory or in terms of speed or communication aspects this can be tested with a large database and any database modifications of different types of database that we can use all the strategy will be part of this third column called strategy and this strategy strategy will have its own type of test environment type of testing aspects like strategy 1 strategy 2 3 4 etc we have strategy N so for each of the strategy what kind of a category we can make like whether it is depending on the hardware software any tool likewise we can have a list like what kind of a category this category has a sub system dependency then any database or database automation we need then we need any interface or signal specific inputs for this strategy all this will be listed so with the help of this we are going to conduct the integration so these are some of the main basic steps of the integration testing okay the list should identify the category of integration such as functionality performance so system of structural integration database interfaces control security or safety conformity etc conformity is something like whether the integrated part can be come confirmed with the values of whatever the intended inputs similarly safe security and safety aspects something like if the requirement says within this limit this has to behave it has to behave and upon certain security threat they should lock those kind of a requirements can be there that also needs to be taken case taken care while doing the categories of integration so each category will have its own sort of inputs conditions and expected results against that we need to write the test cases and draw out the integration test procedures and execution that is what it means okay so we have seen the definition of integration we have seen the integration basic steps software integration will send what is our goal basically to expose faults in the interfaces and the interaction between integrated components that means it is not just enough to find out the faults but also to see the interfaces are properly behaving and interfaces are properly giving in terms of speed performance any issues in terms of a full load not possible or it is collapsing after some time durability all the suspects will be exposed that is one of the integration objective next one is to find the collaboration and interoperability problems and isolate the causes that means interoperability operations we are going to have along with the external systems also system how it can interoperate with those systems is what we are going to find out while doing the integration testing also see the collaboration of different components as we have studied in the earlier slide the next one is to reveal interface and cooperation problems as well as conflicts between integrated parts so it is very important to identify the intention of the different integration parts why because those parts are basically developed by different people and if he has a different perspective in terms of requirements understanding and he would have implemented wrongly or he would have objected those modules wrongly so all these conflicts in terms of requirements would come come out easily when doing the interface and cooperation testing in terms of software integration why I am telling this is because we cannot point out the fault in terms of integration as well integration alone but it could be a problem in terms of specification or design also so all this will be directly or indirectly identified if any flaws are there the requirements or the specification or the customer inputs those conflicts will all will be brought out while doing the software integration so these are some of the software integration goals and objectives okay so now testing types we have seen the levels like hardware software software software and system software integration how we can achieve those and what are the types that we have and we can pick up any of this or both of this or all of this depending on the complexity of the embedded software system but all of this have their own advantages and disadvantages the first one is the big bang integration the next one is a bottom-up integration and the last one is the top-down integration so we know that we have different modules and the components how we can integrate like what aspects of integration we can take care whether we can start with the lower level or we start with the higher modules or we can directly attack the entire bundle so all this will decide in terms of the integration testing type definition so based on that we can categorize the testing types as big bang integration bottom-up integration and top-down integration we try to study each of them in brief big bang integration the strategy can only be successful if a large part of the system is stable and only a few modules are added the system is rather small or if the modules are tightly coupled and it is too difficult to integrate the different modules stepwise so big bang integration basically this is not used very heavily I would say in the industry but in the industry where we have difficulties in terms of integrating that individual modules or if it is the individual modules are tightly coupled or it is too small to test it integration level what we do is we will go with the big bang integration where we will put together those modules and the small modules which are apart from the main modules together and we will try to integrate we will bang it in terms of feeding the values on the field or on the simulation of whatever the testing element that we have that is why this strategy will be applicable for those kind of systems so the last part of the system is stable I mean we know that the system is working we do not want to break it but some features or some modules are added or some components have been taken out or modified so what we will do we will verify that data interface or that aspects which are being added or modified only so we take with the big bang integration strategy for those basically and the system is too small as I said we cannot disintegrate and difficult to test it the modules are tightly coupled so that we cannot make it apart and it is too difficult to integrate the different modules stepwise you start with the module 2 3 4 then 5 6 7 like that so it must happen that 2 3 4 we can disintegrate whereas 5 6 we cannot we have to test 5 6 as together when it is integrated the higher level with 2 3 4 or any other modules those kind of a situation what we do we will test it as a whole that is called big bang integration the next type of software integration testing is bottom-up integration here what we do is okay so there are few words for big bang integration after all components are unit testing we may test the entire system with all its components in action that is what the integration testing does may be impossible to figure out where to fault occur unless faults are accompanied by component specific error messages that means here with this meaning is we may have to take the credit of components so what will happen is component testing we have some errors right so component testing where we have issues or faults or if any pass fail situation is there so we will also consider that while doing the big bang testing because we are not sure if we face some issues or faults as we have not disintegrated completely so but still we see some issues or faults are occurring so what we do we will focus on the individual components and we try to attack the complete target in terms of big bang integration that is what we do with the big bang integration there is a meaning so the next type of software integration testing is the bottom-up integration in this so what we do is basically we take up the low-level or the low-most models we start with that and where the minimum dependency there is dependency with other components are there we start with that and we will do it one by one step by step and we do the higher-up basically this is very useful in the systems because it could be anywhere and it is easier to identify when you start with the lower-most part so that the higher-level models are easier to integrate at later stage that is what the usefulness of the bottom-up integration starts with low-level models with the least number of components using drivers drivers not the higher-level drivers the drivers for the models itself test drivers that is called here we have a stubbed caller which calls for the intended low-level model and the expected results are expected with that drivers and the report will be generated during the test drivers the report will be generated during the test drivers the report will be generated with the help of printf or whatever this but see it is the same as the component testing how do how we do with the instrumentation but it is then at functionality integration level basically because the intention is to integrate on the lower-level models to the higher-level that is the idea the integration can start very early in the development process why this statement is produced the development process we will be done with implementation of the lower-level layers and still the complete integration is not done so without the development team is done with the complete integration of the entire system it may be difficult for us to do the top-down integration aspect so this can be started as well as the lower-level model so that is a good thing about bottom-up integration and also it will lead to an early detection of interface problems and these problems can be isolated easily so before we attack the complete system as an entity complete entirety it is better to start with the lower models identify the interface issues and the integration issues so that the higher-level issues are less but the disadvantage is that many drivers have to be used in carrying out the strategy and it is tedious you can understand this why because we are attacking from the bottom most layer of the embedded software system where we target lower-level models and there are numerous lower-level models and each models will have their own dependencies and identifying that working with strategy testing each one of them is definitely a time-consuming and that is the disadvantage of bottom-up integration if there is a scope money and resources are available I would suggest to follow this type of integration in a system where it is not very complex it is more modular complex and this model moderately bigger not very big medium sort of embedded system this strategy can be used as per re-experience so this is referred basically from embedded software testing book by bark bark brokman and Edwin, we will take an example how bottom-up testing is done this is basically from the web source see you take there are two level or two layered architect architecture design is there and a is the higher-level component b and c are at lower level how are you going to integrate with the help of bottom-up integration test okay the first step is test bc individually we are going to test it that means first we are going to verify b but we are going to verify c so with the help of drivers that means drivers means test drivers for example driver c we call the c function with parameters and data whatever it is that is intended for calling the c and once individually we are done with this most it is done with the level of component level the next step is test a such that it calls b so we are going to test it a to make sure that it has to call b so that we know that the interface between a and b are verified similarly test a such that it calls so that the interface between a and c are so if an error occurs we know the problem is in a because we already tested b right in the first step or in the interface between a and b so the error could be at a or a and we know that we do not have issue with a b because only we have tested with individually at a lower level and now we are trying to test a and we are going to call with the test driver such that a is going to call b and a is going to call c and if we find out an error or a fault we are sure that there is no problem with b but there is a interaction problem either a is calling wrongly b or b is not getting called properly or there could be error within the a so that is how we bring out the issues in integrating a and b similarly once we are done with a and b we are going to call a testing such that any interface between a and c are tested along with any issues in the a side so this is how we take care of integration testing from bottom of aspect so the problem is we are going to test it after b and c are done by a that is what an 80 point about this bottom up testing next we take up the integration testing top down approach what we do with the top down approach it is exactly the opposite way of doing the bottom up so what we do we start with the top most elements higher level and reach the lower level so it has its own advantage and it has its own disadvantage what are those we will try to control structure is developed in a top down sequence so the inter structure of the flow or the sequences that is being used in the embedded soccer system is being developed and those will be used for top down integration sequence testing so at every new level the connected modules at the corresponding level are integrated tested that means we start with one level at a higher up and as we progress we are going to connect the next level next level next level elements or the modules one by one and we are going to test it we are going to integrate and test it non-existent modules is input with steps so if there are as I said in earlier that slide we have seen the complete models would not have been developed so but still we have the higher level models but those models sub level models we can stop it and we can test it stopping is also useful when we are not able to provide a different negative values for the higher level values so that the system can be modified very tested for the different types of instrumentation advantage is that an early look and feel of the entire system can be achieved this is what the very important aspect of embedded software testing integration to understand the system how it behaves based on the knowledge that we have or the complexity that we understand the best way to test it is just completely put the box under the various conditions tested from an independent view how it is going to behave as per the expected system behavior so then pick up the individual modules individual functionality and try to understand where it is going to reach where it is going to take up the lower in modules so that we have an understanding of the system we have a look and feel of the entire system but that is the great advantage of top level top-down integration testing this is typically important where we have a larger or very complex embedded software system so but too huge or too large complex system they basically then they can divide also to conduct both levels of integration testing they can either do both of them the bottom-up as well as top-down like in that case what would they do is they segregate the different pieces of the software accordingly so that is how they take care in a larger complex systems but both of them have to be done meticulously it is an advantage is that impact on lower level modules may lead to changes in top level modules and number of steps needed to test every integration stuff so here also stubbing is important why because some of the unimplemented modules or some of the modules needs to develop with the help of the steps so those steps will have to be developed more and there is a disadvantage and it may impact the low-level modules because low-level modules would not have taken care so that could lead in terms of changes in the top-level modules so that is a disadvantage so basically we use the stubs in top-down integration and use the drivers in bottom-up testing example testing integration so we will take up an example the same example where we have three main modules ABC with an example how it is going to be tested integrated integration tested with the top-down approach okay the first step is test A individually use stubs as I said for B and C that means definitely we need stubs because A needs to call in one of the executable that it has executable line that it has so we are not going to be or we do not have B so we are going to have a small stub which is similar to actual B and similar to actual C so first we will test A individually whether with this stub it is fine or not with the help of B and C stubs then we are going to test A so that it calls to stub for C so this is very important because A is going to work along with B and C and it can call B or it can call C each one has to be tested with actual B and the other one is stub when we are testing C the B is stub that is the third step test A such that it calls C the first time it calls B sub second time it calls C the first time we want to have the same stub for C the second time we are going to have the same stub for B so that we know that the working behaviour or the actual expected output is same in all this that is what the approach so if an error occurs we know that the problem is in B or in the interface between A and B so we know that while doing the integration testing definitely there could be an interface issue or the issue is definitely with the stubbed part because we have stubbed it and A is getting called and we are getting the error so if an error occurs we know that the problem is in B or in the interface between A and B similarly that the third step is test here such that it calls C with stubbing B and if there is a error we know that the problem is in C or in the interface between A and C in terms of calling mechanism or whatever it calls so this is how all the errors of A B C and A to B A to C will be brought up so that is what we do or we will bring out the top down integration issue this is exactly the other way of doing here here what we do we start with B and C and we will identify the interface issues either in A or in the interface with the help of B and C here we use the drivers drivers are at the A level because that is going to drive B and C so in top down it is the other way we are going to do with with the help of stubs in B and C. Stubs are used to simulate the activity of components that are not currently tested and disadvantage is that you may require many steps that is what is going to happen in top down integration testing this is an example okay so overall integration testing of top down and bottom up advantages and disadvantages we missed about top down advantage is that the drivers are not needed or only the simple ones are required because the high level components that have been tested serve as main part of the environment the disadvantage is that low level components must be replaced by stubs this can be costly because there is a definitely effort and cost involved for developing the stubs by the team and team has to have a knowledge of the B and C for developing the stubs and the bottom up advantage is that no stubs are needed because we are going to drive it in visual modules but disadvantage is that high level components must be simulated by test drivers so in bottom up we need drivers top down we need stubs so it is up to the test strategy team or the test plan team or the test manager or the test lead to decide what sort of a strategy is going to work for the particular embedded software testing it again depends on the various factors as I said the complexity functionality performance subsystem top down integration databases what sort of a database it has whether we have a confidence that it will work or we need to test for each of the data with the help of all that boundary value analysis partition equivalence etc and control how the control flow is there for the entire embedded systems what are the security aspects or the safety aspects all this need to be considered for deciding the bottom up or the top down integration we can have both as well does not matter or does not impact in terms of standards or any compliance both can be taken care okay so we need to plan accordingly for a indefinite so what is the importance of planning the integration is that by enabling successful integration with critical factors such as objectives responsibilities and source planning so basically it will enable we will have an impact on the outcome of the project or product lifecycle because without integration we do not know what is going to behave in the field or with the customer so definitely it is very important and it has an impact on the total outcome of the product of the life cycle so this is one of the critical part of the product or project lifecycle of the embedded software time resources and personal are identified for planning that are enable that enable successful integration so as part of the planning of the integration testing based on advantages types of the integration testing the time resources planning the personal planning or the tools all this will be identified so without having the integration we cannot identify this so we need to have a planning for the integration and conducting the integration that is where the importance of the planning integration so integration considerations what are the aspects that we need to consider for integration system decomposition how the system is decomposed basically this is drawn from the design or the architecture it could be higher level architecture or low level design then we need to have a architectural consideration is in terms of open or closed that means the architectural elements can be open or be closed in terms of the downwards layers and integrated or modular that means the modularity is required or the integrated parts as a whole is required all these considerations we need to take care for doing the integration testing and the interfaces how the system is going to interface externally internally or the subsystems or the partitions applications etc then we need to understand hardware considerations we need to know what sort of hardware is used whether it is a real target or evaluation board all this will have to be considered and tools of course that tools can be having a hardware dependency or hardware simulation likewise we need to have this very much important particularly in a bigger systems where we have a automatic testing equipment it is so hardware consideration is one of the important element of the integration testing HSIT it is called as hardware software integration testing software considerations where we need to consider software components such as algorithms there could be a check sums or it could be a stringent computations all these have to be considered so that is where we do the planning of the integration software testing okay so we will continue in the next class in terms of integration test strategy and other aspects of the software integration testing