 the next session of embedded software testing , the series of unit 2 where we study about testing the types today we study about the state or event transition we continue on that and where we continue on the other techniques that we have, so before that we will see what we we have studied in session 15 we know that given a range something like a temperature from 3 to 8 we can have all the spaces the reaction we study about the boundary value analysis with an example of a temperature indicator indicating regent between 3 and 8 the different test cases so these are test cases for the temperature range about 5 test cases are there taking care of negative positive just below the boundary and above the boundary there is a nominal value also subjective to the requirements whatever we have. The state transition you know it is a purely based on the state based behavior mostly this is a state based machines or state machines are implemented in the embedded systems with the help of models so today we study about the model based testing also before that we will try to understand so what are the states that embedded systems can have and how we can test it so we took an example of a tape recorder where it can have states such as off on recording so three important things that we need to remember is state itself then there is a event based on that event actually will be taken care that means it is in the off state when the tape recorder is off once it is powered on the power on is an event the action of that is the tape recorder will be powered up and it will start the initialization and initializing the systems this is basically a fundamental embedded system nature you take any embedded systems we have a power up sequence after power up we have a installation after the installation there are applications that will be either initialized or triggered or depending on the type of application type of embedded systems that we have it could launch different applications then we studied about two zones in two regions basically which can switch between states such as this then we know that the events of the states transition can be tested with the help of behavior then the behavior can be classified into three types one is a simple behavior where the system always in exactly same way to a certain input independent of the system system so it will not worry about the systems background of the system it will just drive the value or drive to the action based on the input so that is what is the response for a certain input then there is a second type called continuous behavior where we have the current state of the system difference of the history of the system such as that it is not possible to identify separate states keep on changing we will not be knowing it is a continuous behavior of the system then we have a state based behavior where the systems enter into different states can be distinguished from other system states based on the system history so these are basically three types these are all leading to different functional behavior within the system all these functional behaviors are under the state machines so we need to cover all these behaviors while testing the state transitions all the entry and exit of each function different states it will be revolving within the between the states all these have to be covered so test cases we need to create reaching a each state and seeing the zero switching coverage in terms of transition then we have a chain of transition like n to n switching etc then state transition fault categories also be listed the fault categories can occur in the states about five states faults can be there then we have a gods then we have transitions about four transitions faults can be there then we have events for type missing event hidden paths and reaction takes place but an identified event is there then we have a synchronization issue where multiple regions or multiple subsystems are involved and there is no synchronization between these two so that also is a fault or a failure then we listed out all these fault category in the table and for coverage purpose use this table to highlight whether that faults have been covered or not so and we have also ticked the state transition technique sometimes may not be possible to do a automation or testing technique as I said in one of the class that those could be tested implicitly with the help of analysis or instruction so that is where categories coverage we have listed out the checklist and the state transition to prove and some of the techniques we may have to manually or during inspection some other techniques so that is why these are not checked here okay so this is supposed to be an exercise for the previous session please make a note of this exercise rate a state and transition test cases for the below so I think you have another session you have seen there is a requirement which I had given requirements specification for embedded instrument so you can see a different modes I used to take so now we can consider that modes as states so there are about five states in it operational maintenance download and fail so there is a diagram underneath this you can use this diagram and requirements which are shared again I will probably I will share it for that you need to write a state and transition test cases for the below you can write a simple test cases identifying the inputs and change in the transitioning of the states then write an expected output so that should be the exercise for this session and I guess some of the embedded system glossary we need to look at how much few highlighted here in terms of code coverage we know that code coverage how much code we have tested versus the complete code so which is nothing but the coverage how much have been powered or executed the next one is about the component a minimal software or hardware item for which a supplied specification is another that means a unit it could be a ECU or in aerospace it is called as CSU CSU whatever it is CSCI etc then there is a term called coverage the relationship between what is tested by the asset and what can be tested it is expressed as a percentage usually in terms of percentage the coverage is spoken debugging debugging all we know in terms of finding and removing the defects we use this is typically a developers set up that can be used by testers also defect it is something but a fault driver is a new term a skeletal or purpose specific implementation of a software model used to develop or test a component that is called by the driver that means it is a test driver it is called so where we provide the inputs and which will trigger the needed conditions and which can be used to provide the expected output also so that is where we use a driver also to call as a test driver then we have dynamic testing a process of evaluating a system based on its behavior doing the execution this we know we studied embedded software is the basic thing that everybody knows embedded system basically embedded software talks about system having controlling functionalities and all that without the hardware embedded system has both hardware as well software because software needs to work with the hardware then we know emulator what it is so it accept the inputs for the system and produces the outputs by the system so that is about the continuation of the last class so we will see the state or event transition today so as I said this exercise we need to do by developing a state and transition test cases for below requirement okay now state transition testing technique we will study so in response to input events the correct actions are taken and the system reaches the correct state so that we need to ensure that is what is about state transition testing we need to do it that means we will make sure that in our testing we will be providing the sufficient inputs so the correct actions are taken for those inputs and the system is expected to reach the correct state the technique is called state transition test technique STT as spoken by the book which I have referred in the one of the class the STT consists of the following steps there are five steps that state transition test technique has composed in the state or state event table that means we need to compose a state event table then composing the transition tree having all the transitions having all the state events table is provided and the third one is composing the test fit legal test cases so we are coming up with a legal test cases which will derive all the transition path then the first test fit illegal test cases which will take care of the negative cases something like test cases which are not going to happen really in the normal embedded system execution and the fifth one is the test fit gods as we know identifying the gods and scripts how we can do it so we need to know about state diagrams also so we will study about a state diagram in detail with a VCR example so before that we will just identify the STT STT we know that it is a state transition test technique so first step what we spoke is composing the state event table the state chart is the starting point for the composition of the state event table that means before we draw a state machine table or state to event table we need to identify the composition in terms of how the state chart is there so we will take an example of VCR so the state chart is the starting point for identifying this example so we need to see the composition of the state event table basically driven from this states first then the events so you can see the arrow marks as events and the states in the rectangular boxes so if a state event combination is legal then the resulting state of this combination will be incorporated in the table that means we are going to have a test cases for legal if it is a state event combination in addition the transition will be assigned a number so there is a unique number for that particular transition that is identified in the table you can see this table we will study this the first column of this table holds the initial state the other columns consist of the states that can be reached directly from the initial state one transition away from the initial state also so from the initial state what are the different states it can enter so that also needs to be entered next come the states that are two states away from the initial state that means from the initial state next to next state this also is there the third state we can say as an example until all the states are represented we are going to continue on the right hand side so state event combinations for transition to self this state is accepting state must also be included in this state that means it can come back also to the initial state you can see it is going for the standby state that is one of the initial state we can say using the state chart concerning the video cassette it is there in the previous figure the state event table is drawn as per this so you can see the rectangular boxes having the different states we have about 1, 2, 3, 4, 5 states so there are about 5 states you can see then identification then list out all the events that are responsible for moving to the states for example this is the starting point of the state which will go into a standby upon power up so in standby state it will continue till we have to see how many events are there to go to play one event is there and for going to the record one more event is there from any other event is there rewind yes here should be able to stand by and also there is one more last one is about faster so 4 states it can go to the events that we have one is the play and one is the record this is the moving forward similarly once we are going to play next we are going for the play from play it can come back if the event of stop button is done similarly from play we should be able to go to the rewind this here we can do a rewind and for the fast forward those buttons can be pressed so it should be that action for that event similarly directly from the play we can go to standby if the tape is ended so this is another condition interestingly they have put all the combinations that VCR can take so this is how it will be designed basically there are no more events let us say we are moving from standby to record so there is a my tape is in exist and not my tape is in end that means my tape is there without the tape it will not record first of all that condition is a god first it has to be satisfied then there is an event of record button so these two primary inputs if they are satisfied we can switch to the state where the record state is going to happen it will keep on recording till the stop button is pressed so only way to go to the standby is stop button of course there is a tape end because this one of the god is false so it will go for the standby so taking up another state let us see how play and fast forward can interchange between them so you can see there is no state from play to record because from play to record VCR has to be stopped first then we can go for the record similarly between play and fast forward we have an event called fast forward button pressed in a play condition and once the fast forward button is pressed again or the play so this will keep on happening for all these events we are going to draw a table you can see a nice table written here in table 11.4 of the book state event table with legal combinations these are all legal combinations indicated by a bullet and any other thing that we want to go through here okay so these are basically the state events that needs to be studied once we have the state chart we should be able to draw the table you can see from standby event button can be pressed so this uniquely numbered as one play can be pressed to fast forward can be done fourth is a record and similarly we have standby to rewind as a fifth and sixth one is fast forward seventh one is standby similarly for beginning eight as a standby so these columns are different states record play fast forward rewind similarly standby these five columns are states and these one two three four five six seven actions are there seven events are there for this event what is the state of this states two three four five these are different states and these are the events so events is event button play button fast forward record stop in tape beginning of the tape these are all the events for these events so what is the standard of each states how it is going to take action there are bullets of course that bullets are nothing but the illegal combinations so we spoke about legal and illegal or negative or positive whatever the way you want to term it about so the legal combinations are something like which won't have any action though event is valid of illegal event the action is ended with illegal event that means no action is taken or the system should not accept that as an event for example when the rewind is happening there is no point in rewind button so we cannot press the rewind button or we may press it but it will not take or it will not do any action for that of course we need to test illegal also that we need to highlight it or we need to do a table event table for that also and when the rewind is happening we cannot do a record similarly like this there are number of illegal combinations in stand by we cannot do a stop because it is already stopped and end tape will not happen because it is neither rewinding nor playing beginning of tape also will not happen similarly while recording is happening rewind cannot happen play cannot happen fast forward cannot happen record button itself cannot be pressed or there is no action for the record button of course it can go for a stand by and beginning of the tape it cannot go that is the illegal combination and you can see there are two stand by 17 so this is based on the events so this 17 this 18 is different because while record state is happening user has to press the stop button which will result in a stand by similarly record state is happening user has to press the end tape or sorry user will not press sorry the tape will end it also will enter into stand by similarly fast forward will result in stopping the button it will go for a stand by fast forward will go for a stand by the tape is ended so likewise we need to identify all the events for the state diagram based on the state chart so it is very important to understand the states and different events all these events have to be listed out here so you can see the number of errors these are all nothing about the events so there are about 18 stand by sorry 18 events that are possible with this state diagrams okay so that is the second step so what we spoke about is composing the state event table then we have seen the state events with illegal communication next one is transition tree so this is very important aspect also how the transitions are going to happen so why this is important is for a tester he needs to know whether he has covered all the paths different paths because this fast forward can happen from stand by to play to fast forward or the fast forward can happen stand by to rewind to fast forward like this path we should not just enough to do a stand by to rewind or rewind to fast forward we need to cover this path stand by to rewind to fast forward that is why we did not just enough to have the table the next step after the table is listed we need to have a transition tree so it is a very nice picture the way we can see the first initial point the basis for driving the transition tree because all the paths are going to be starting from stand by or for the paths that is on the right most most side is going to be taken care with the help of the left and four states so that is how we are going to list out the transition tree okay this tree is drawn basically by understanding the different points and the states that events will trigger so from stand by to we know that there are four states it can enter rewind play fast forward and record each substates of stand by it is rewind play fast forward record can enter into its substates it can go for a play it can go for a fast forward it can go for a stand by so this path how many paths are there now likewise we need to count all the paths like first path is this stand by to rewind first path is about stand by to rewind second is stand by to play so these four paths are there once we have these four paths which path is rewind to play so these are test path one so to record this test path one we need to have path one and path five done because stand by to rewind to play similarly the sixth path seven path eight path like this to continuous the test paths are different so each paths are legal combinations basically you can see about 14 paths are there so which will cover the complete visiting of this event so there is a note guarded so stand by to rewind is with the help of the conditions that we spoke about with that guard is there then that state will enter so others are possible terminal point that means it may not go beyond that so you see that fast forward is the last terminal point and the play is also a terminal point stand by is not a terminal because stand by again go to a different path so likewise we need to have a transition path defined okay the next after composing the transition table sorry the transition three we need to have the legal test cases right so the script we are going to derive for this legal test cases so how these are drawn is based on the then the guard that means guard also need to be taking care in terms of tape exists tape not at the beginning tape exists tape not at the beginning this one of the guard tape exists tape not at the beginning so all these are key inputs for the event to happen and for this individual test script we have a action so what is the action the expected action is start rewind the state where it will enter rewind state stop rewind as a result of that it will go to the next state as play and resulting state is play so the second test case play between stressed if it was in a rewind state it will stop then start the play it will go to the state play state similarly stop button is pressed the play that was the previous state it will stop it will go to the stand by then we have the rewind button so likewise we are going to insert all the legal scripts so we can have any combination this but that should be based on this path and the legal events all legal combinations that we have here similarly we are going to have a illegal combination also this continuation of legal combination there are about 14 legal combinations are listed again each one is again having its own sub events as you see test pass 14 so each 14 path can have another inter substates entering and exiting so all this have to be exercised with the help of legal test cases next one is the illegal test cases so illegal test cases we know what are those when the rewind is happening there is no point in the rewind similarly when the record is happening these 5 bulleted items like rewind cannot be done play button cannot be done pass forward cannot be pressed and record itself cannot be done so these are all illegal combinations for each of these illegal combinations we are going to identify uniquely with the ideas illegal 1 illegal 2 illegal 3 like this there are about 16 illegal events of the combinations that can be done so let us see how many are there in this about 3, 6, 9, well 16 illegal combinations are there so same thing is explained here setup is L 1.1 so what is that L 1.1 is what we have seen here rewind button at this step not at the beginning let me this is the chord and action is rewind so rewind state it is there now how to read the rewind state rewind button is pressed and when the rewind is happening what is the illegal action we are going to have we are going to press the rewind again that is what the illegal script and for such initial setup we do not need to mention any ID because that is the default state stop button or end tape beginning of the tape will not result in anything so that is a illegal test case of course we need to excite illegal code also so having this illegal we have the complete coverage of the state events so this is the 4th step that we are going to do so what are the first 4 steps that we have seen first we are going to have a state event program then we are going to have a transition tree then we are going to identify the legal scripts and we are going to identify the illegal scripts state event table is the one in the transition tree then the legal scripts and the illegal scripts these 4 steps are very important for drawing the state event of course the last one is being a script of gods we can do that it is not mandatory but it is depending on the conditions that is underneath that but mostly we have covered with the help of these legal and illegal scripts so we can skip that also so while doing this state transition in testing so there are certain challenges in terms of its practicality so what are those we are studying about that is hierarchical state charts that means the state charts can have a hierarchy in terms of main system and subsystems it may be little impractical to test all those combinations it could be top down or bottom up manner it may be difficult to do or achieve the testing hierarchical state charts so if the like in hierarchy details are not much laid out or details of the underlying levels are not known very well so it is more practical to use a top down approach because the details we do not know so we start with the top down manner because hierarchical way of doing this is what is been used like say we know in this hierarchy we have a standby to the next level if there is a complex system which has its own substrates under play fast forward and the details of that model is not clear or not known so then it is difficult to do the bottom up only this onwards so better to start with the initial or the top down approach that is what it means so the super states it is also called as super state so that is what it matters for us to test it so only the incoming and outgoing transition for super state is very important in that case to identify to cover as much but whereas in the bottom up approach the lowest level of hierarchy is tested fast but if the details are very much available it is easy to do that successfully higher level higher levels of the integration are tested until finally the complete system has been tested so in complex systems what will happen is top down approach may not be possible sometimes because we may not have the system completely and we have a clarity about low level details only so in that case the bottom up approach is suitable once we have the integration completely done hierarchy top down approach can be taken care next one is the extensiveness that means the coverage as I said we have different states we have a legal combination of these scripts that can be developed for the legal state entry and exit and we have also a legal state all these need to be covered in order to have a coverage it is very much extensive to have all these 14 sub 14 paths the complex systems it may be tricky to have a coverage some events it may be difficult to cover especially the path when you consider the state forward from stand by to play when play to stand by it is easier but from stand by to play and play to fast forward and fast forward as other sub states internally it may be little trickier or impractical to do that so in that case we have to do other methods to overcome this practical issue that is what it means so the extensiveness the extensiveness of the state based method can be modified by deciding to and what extent the dependencies between successive conditions are tested depends on the method so the transition can be tested individually in that case but it is also possible to test a combination of conditions when it is possible we should be doing that if it is not possible we should be testing it alone that means each transitions can be executed or done individually suppose we may not have provision suppose provision to test this path completely right from stand by to play to this so the best alternative is take the crate of this take the crate of this then take the crate of this first execute this then try to emulate as much because we know that play has entered try to execute this path we start with this we end with this so one execution form then we start with this end with this or it could be further next level so individually we can cover where there is a practical issue so that is what is the extensiveness the coverage perspective if there are challenges so we know that test path coverage is executed versus the total number of coverage end to one switch coverage or zero to end coverage all these are coverage percentage we are going to have it as a report next one is the fault detection the state based test design technique described here is based on the test depth level so minimum effort is required for state based behavior once we have this platform ready the entire system is based on this so we do not have to change it again if there are bugs fixed so we should be able to find the faults easily but sometimes what will happen is we may have to change once it is fixed right from the beginning that means to address a fault that could be in any of the deepest state we may have to excise the complete path so that is the challenge in terms of detecting the fault so fault categories all fault categories may be tricky challenging in terms of testing so in that case the individually the different states can be excised to find the fault and take the credit of the other states which are excised in addition to this we need to have a choices which will help us in isolating the fault based on the table what we have drawn in earlier slide then it is the feasibility that means whether before I decide the model state based testing we should have a feasibility whether I can practically achieve so that is one of the practical issues until we test it that means we may not be able to plan it appropriately we may have to revise our plan when we really do the testing so the testing of system state does not always turn out to be simple basically the behaviour of the system is hard to determine because the behaviour is concealed to an extent to a large extent the observation it could be different what we see outside then we can be when we start testing it the embedded systems having object oriented systems or UML type of implementation so where the data encapsulation may not move so it may be difficult to test such cases the cascade of transitions before the system reaches to a state that can be observed so we need to know the intricacies of those so that is where the feasibility in terms of understanding that and drawing the transition test mechanism sometimes it may be impossible to do it to distinguish between individual transitions and quotes at the lower level so in that case either we should be doing with inversion of inspection or work through so that is the best solution what I have observed where we have a practicality and feasibility so those are the practical issues for state transition testing which is very important to have a state transition testing because the embedded systems mostly live with state transitions there are practical challenges and issues for doing that state based testing so we need to overcome that with the help of all this mechanism and the best expertise what we can have in terms of system knowledge and the states that we can enter so there are that is about the state transition testing we will have the same exercise as what we have here state transitions testing for this embedded unit we should be able to do it is an exercise for the state transition testing what we need to do is we need to have these four steps done so let us try to do state event table transition to the script legal and legal we have to do it so that is the exercise for state transition testing there are other types of tests we will study in brief this is just to highlight in terms of what sort of tests are available main testing the idea is do not get normal inputs because we strictly go with the theory of testing by doing that we may miss a good value system fails for a normal range there is no point in having the testing technique taking great of that so we need to have an understanding and have a good test cases so that is what is called mainstream usage so that is called as mainstream usage testing so we will study about model based testing so we will have a small introduction session and we will study what are the normal testing and we know that model is a behavior of the system so what is model based system so we know the system is designed with the intent of what is its behavior what it is going to execute is that it requires to continue its operation smoothly as well as under some of the abnormal conditions so that is about model so those finite elements of the system are developed in terms of various models that system is going to have the system that is what is about model and model based design is based on that only so first we do a model based development the terminology is called so we have to develop models so models are developed with the help of matlab or simulink so this is from matworks and of course there are object-oriented C++ supports are also there such as visual C++ supports sometimes developing the models but mostly it is used or developed with the help of models skade is also another example so we have a model why because it is useful to analyze the system and it is useful to simulate if there is a problem or we have a bigger picture the model will have the help of models so mostly the embedded systems where the complexity is involved they go for model based the model will have hardware as well as software blocks like software interfaces such as UART SPI ACI or flash I2C all this will be part of the model so all those individual units are called as blocks and those blocks are depicted with the help of models so for model based design we will do block diagrams maybe we will have a few samples in the next sessions so the advantage with the tools that we have today is that we can generate the code not completely probably to an extent it will help the user to develop from the scratch so it automatically generates the code which can be deployed and verified on the embedded systems that means we have developed a model software blocks and some hardware blocks to atleast the framework with the help of the framework and some fine tuning with respect to the end target we should be able to have the end systems so that is where the advantage of the model development is useful so example is MATLAB and assembly and very long and VHDL for hardware so where we have a complex systems this model based development is very useful that is why they go for model based design and development okay so once we have the model based available or model based design is developed we should be able to test how we can test it so we can also do the testing of the model with the help of testing where we apply the same terminology as model based development here it is called model based testing so model based testing is a process of test generation from models of system under test so it means we develop the models which will help in doing the testing in terms of generating the test cases or testing it basically so there are numerous methods that are used in the MBT model based testing we study few of them in the next classes so the test cases are created automatically same as the development we have seen at the core generation is there similarly we have test cases generated automatically from the models of course there are disadvantages also for complex systems it is useful where we have time and schedule we have a chance to review with the automated test cases fine to meet and all but whereas the simpler systems where we have a few interfaces and few models are available it is better to go for manual or black box techniques what we have studied earlier so that is the advantage and disadvantage so basically broadly these classes are used for model based testing first is the model itself then test generation and test execution how these are all involved for model based testing so these are some of the examples we can have a once we have identified the model how we can verify at least we have a pretty many understanding of models in terms of whether it is rightly modeled or designed so it is sort of a very good advantage verification simulated using test based on high level requirement that means we can lay out the verification mechanism with the help of high level requirements only the test can be accomplished on PC instead of target systems we do not need a target system we need to have a knowledge of the target system with the help of that we can develop the model based testing on the computer only not on the targets okay so there are other taxonomy overview of the model based testing so we will study that model based testing and its intricacies in the next class okay to conclude we will revisit what we have studied we need to have so the four state transition technique steps we need to apply for the sample embedded unit having five modes of states or operations unit operational maintenance so we will study about model based testing and how it can be detailed in the next class . . . . . .