 మార్సారాలిలెతారినిన౯ంసి మోమార్మాయార్. మార్మార్మారినారిలార్నుకి. నిసారిమార్మా. and testing methods and test selection criteria and previous sessions we studied about equivalence partyally and in the last class we studied about boundary value analysis and equivalence partition and both and today we will discuss and study about state or event transition. We know in the states how it is going to behave and different events within the system, మంతర్చికి, మిఉప్టాల మిధినూటాసి చిమి. మికుచానిసి మిటా. సిమాసికి నంద౿ సంద౿. and other side of the valid equivalence class in valid equivalence class and also we have studied about after we choose a good test case out of for this equivalence classes within that group we will start the boundary for each of that equivalence class valid or invalid just above that equivalence class and above the equivalence below the equivalence class in terms of the values and basic idea is to reduce the number of test cases for the requirements where in the behavior is same it could be valid or invalid and also we studied an example boundary value analysis for M minus M 99 to plus 99 we had seen other is minus 10 minus 9 minus 1 0 1 then we had 9 10 28 99 and that means the boundary value we see just above the boundary and below the boundary upper lower like this we have to define it so same thing is explained in the the next slides in terms of minimum just above minimum nominal or average or the middle one also it can be called as intermediate and we have a maximum and just above the maximum so these are all will be covered in terms of equivalence classes. While doing the equivalence classes we have to be careful identifying the tests especially for the problems like next date problem where we see we cannot afford to give April with a month of 31 which is not realistic and we should have an knowledge of the requirement as well similarly the triangle problem also we are going to identify whether it is a triangle or non-triangle non-triangle inputs of no use so we need to be defining what type of input based on the definition of the requirement such as triangle or types of triangles so that was what about the boundary value analysis and equivalence partition we had an exercise that exercise so that it will be more clear for you so what we had exercise for boundary value analysis is that the temperature indicator example the refrigerator has two signals so two indicators are red and green the optimal temperature in the refrigerator is three and eight degrees that is between three and eight it shows as green whereas if it is below three and above eight it will indicate as red the temperature range can be divided into three intervals we know that from infinity to infinity means here any number on the lower side till three three degrees but not including three degrees it is less till then we have to include and from three including three till eight including eight similarly not from eight but just above eight eight point one or whatever it is till the other infinity values such as 100 200 300 whatever the capability of that particular temperature sensor so for this example when using the boundary value analysis there should be one test case for each boundary in every equivalence class so there are about five test cases identified for equivalence classes for this example the first one being the test case over a negative infinity even minus two point it will help to create and furthermore not very likely to occur that means the temperature need not be minus two seventy three the chances are very less so we could give something like fifty seventy max so next one is a test case one be here we have the problem of close enough to the boundary since being on the boundary is outside this interval is five added digits a good estimate so basic thing is can we have a three digit or four digit or sub two specification we should have an answer in the specific or if we do not have we should have a knowledge of such sensor system where the sensor is capable of so and so ranges those requirements says I will take care of one three and eight we should have a knowledge of the underneath sensor of the hardware which is capable of taking a max both the sides that is why it is case one a one b go then we have test cases two a and two b the second set of four test cases both boundaries are inside the interval so these values are the ones to choose that means there is a interval above eight you can see so one of that similarly we have the other one also above three sorry below three k it could be anything till minus ten twenty depending on the capability of that sensor then we have test case three a same discussions as one b on the other side and test case three b same as one a on the other side that is on the last side so that is how we can have a for this example okay now the last test selection criteria or technique that we will discuss today is about state or event transition so what is a state let us briefly understand the about a state many embedded systems or parts of embedded systems or basically being developed with the help of state based behavior that is something different modes which we can also call it as where the embedded system will move from one to other one that means it has a predefined set of actions or executions for such mode or such event so based on the criteria that it impacts or we based on the criteria that it exits from that particular state it has a number of behavior that it has to behave so basically many of the embedded systems are partly the pieces of the embedded systems can be implemented with the help of state based behavior so state based embedded systems or state machines is also called as is being implemented in many of the embedded systems that we can see especially the complex systems in industries such as telecom or a mobile any GPS or GSM system it take the automotive for example we have engine control systems where engine control has many features or functionalities given based on the different states similarly we have a aerospace products or avianics subsystems having a state based or state driven applications in designing these systems state based modeling so basically great machines or state based embedded systems so they developed with the help of modeling because modeling is an important concept in developing such states we have a state diagram from all that maybe we can have a small session on what is a state based modeling for the development purpose similarly we can understand the state model based testing I think we are going to study that model based testing in one of the class so models are composed during this process serve as a basis for the test design that means all these models are the basis of designing these systems having state based behavior so the testing is called model based the purpose of the state based test design technique is to verify the relationships between events actions activities states and state transitions transition is something like the entry and exit of different states from one state to other state the moment is called transition or the entry exit from one state to entry to other state is called a transition so upon occurrence of certain conditions those conditions are called events based on those conditions or events the transition will occur the events could be some actions sorry the as a result of event the actions need to be taken care as a result of action some activities are going to be happening or executed so that is how state transition will happen by using this technique one can control if the system state based behavior meets the specification set words set for this system what it means is with the help of this technique we know that how the system is entering and exiting from state based behavior and testing this we know that how we are going to meet the specification set for the system testing different conditions or different events of state transitions will help us know whether it is transiting or not whether it is doing a entry to the next state and whether it is exiting from the previous state etc all this can be known with this technique called state transition testing and state based the behavior usually are represented using tables or activity charts or state charts so just to name them I will put those so that we need to be aware of this as a embedded software tester so basically state based systems are represented with the help of tables state charts you will study little on this how they are tables also will be there like there are few elements which are part of this tables this table is also called as look of table using function pointer in C I would say this is basically implemented is a very critical aspect in the embedded systems where we have complex mechanism in terms of different states numerous events triggered based on numerous signals are occurring that means we have suppose one state this is under state let us say and we have a state change between these two and of course we need to define a state entry also how the state can be how this state can be exited so let us say state one is a state two two states are there these two like this we can have multiple states in a made system suppose state one needs to be entered so there are certain events that needs to be even let us say or e2 e3 systems under the satisfaction of one of the events or all the events could result in entering into the state one suppose let us define the state one as initialization so upon power up there are certain conditions power up is one condition the system will enter into any state once the state is complete that means there are different activities the action is two activities such as initialization of hardware software etc so this state will be complete so once the state is complete that means the conditions that are to be or the actions that are to be concluded or completed within the state are done so that means we are good for going for next state that means exit criteria is satisfied that means we have a entry criteria and state two is satisfied here it is entry here it is exit so we know that state two is entered this could be a main application similarly we can have a next state next state like this with the help of state diagrams and this case state can go to state also based on the reset or some events that will result in switching between the states so that is what the definition of state this state diagram this basically state diagram this diagrams are basically represented with the help of text I think I will explain with the example how tables will look like the table will basically define the states and events state charts also will define complete a state machine entry exit all the values and everything and we have a lookup table identifying the functions which are the functions which are responsible for entering into different states these are implementation aspects that are part of the embrace of the systems so it is very important to know the state transition mechanism in order to test it in order to test it so how we are going to test it mostly with the help of a model based equation because state machines or the state transitions systems are basically based on modeling we study about the model based testing for next class or next sessions so that is about state transition you can see an example of states these again from the book embedded software testing by Bart Rokman and Rottenboom so here he has depicted a state machine a state chart basically it is of a tape recorder let us try to understand from the sake of understanding the states and the state chart okay so there are three states you can see the grade one off on recording simple so tape recorder can be in off state tape recorder can be on state tape recorder can enter into recording state right okay how the off state will enter so there is a small dark arrow you can see that is from the switch off switch off to switch on probably we can say so we have a switching mechanism which will help in terms of going to the first state so that is why this is called a state and tape recorder can go into on state with the help of some operation or some action it is nothing but an event event power on initialize system that means once you power on with this power on switch when you connect to the course of play and make switch from off to on it will enter right so the event is event power on so action is initialize system so three things are important state event and action with this this state is defined or switching to the next state is different next is on what is going to happen within on or what are the events or actions that are going to taking place within this state that is nothing but on state you can see a circular arrow transitioning to self is an important term when on it can be there in on only because user has not done any operation here just powered on so it is waiting for the user to operate further either could be play or as you can see the next state recording or anything till then it is going to be in this event so that event could be called as event reset or initialize system again that means in on it is just waiting for the reset event to happen or it is waiting for the initialization any further initialization for the next to occur the next to that is recording so upon user presses the recording button what will happen is it will enter into recording state the event is called start recording on the action is start record so there is a God the term is called God so what it does is from on to recording the God will be triggered it is called God transition and of course from recording we can again go back to we can go back to on state by stopping it right so we can have another event called stop recording and a God could be the next one similarly from recording to off we can go but there are tape recorders we see we should must we should first do a stop then go for off so likewise the different states are entered so three terms are very important on the state event action so that is about an example of states how the state transition is going to happen here we can see three is about the state so what we have seen there are different events right so those events are explained in the next table okay so let us do a small understanding of this so there are two levels of explaining the flow between a and b you can see upper side is a lower side is b a simpler term we will try to understand so what is told is that synchronization between orthogonal with storage of event information that means two orthogonal events are going to occur with different states and how they will be taken care is what is being explained so there is a state 1 a state 2 a state 3 a in the first orthogonal section and it will enter into the next or the one with the help of state 2 b state 3 b state 1 b and for switching between these states there are different events that is to occur so state 1 a is been entered with the help of over on an event 1 will go to state 2 a and from state 2 a event 2 can happen it come back to state 1 similarly state 1 a to state 3 a directly we can go the event is 3 similarly from 3 a we can fall back to state 2 a with the help of event 4 then also there is a second orthogonal region the event 3 can also trigger to the next one which will result in state 2 b state 3 b state 1 b etc state 1 b can be directly entered with the help of this so there is a synchronization mechanism that is detected here with the help of over 1 round so let us not go in detail about this but what we have to understand from this is that different states are responsible for taking into the inputs from different events and going to the next state it is called switching and three terms are state event action these three to remember for embedded software testing okay now the behavior of the system can be classified as a three types the state transitioning behavior is divided into three types simple behavior the system always responds in the exact same way to a certain input independent of system history that means it won't care what has happened in the past but it will behave the same way all the time for certain input the second type of behavior is continuous behavior the current state of the system depends on history in such a way that it is not possible to identify a separate state that means based on the history it will decide whether it will switch or it will not switch so basically it is not possible to separate state it is a continuous behavior the third one is state-based behavior where the current state of the system is dependent on the systems history and can clearly be distinguished from other system states that means we know where the system is lying in this sort of a behavior that means the current state of the system is very much dependent on the systems history but it is possible to identify a distinguishing state from the other state where it is so these are state-based behavior the second one is a continuous behavior where we don't know or we are not able to identify the states specific states for that particular input it is again depending on the history simpler behavior we have a clear input and it is very much independent it will behave all the same all the time same thing that is what it means okay so now let's move on to the next thing functional behavior in the state machine so basically we need to understand what are the functionalities it is going to execute so what we understood from this is that there are different actions based on different events all these are all part of the functions one of the other way that the particular piece of software is going to behave those functions are something like procedures or different subsystems which are driving the embedded system to switch between the different states so all these functional behavior we need to test it and cover all the states that the software enter and exit that means the coverage is very important for a particular state as per the specification so we need to create test cases as per these three steps reaching each state how to reach the state using every transition that from the default to switching that means every transition we are going to cover with the base to the next state with the different transitions similarly the next one is for each possible chain of transition means n to switch coverage that means maximum of possible transitions in the complete path of that we are going to have it so we are going to create test cases accordingly so state based state machine based testing it is called is a quite useful model based black box testing technique since any type of functionality that can be represented as a finite state machine can be tested using this technique so finite state machine and all beyond this class but you can study that in embedded system basics where we have different state machines defined and its behaviors are detailed so state machine based testing will help and identifying the issues with those implementation of state transition so some more details the first step what we do when using the state machine testing is construct the model itself that means we are going to construct the model how the model is going to be behaving so we are going to with the help of our test we are going to trigger some of the inputs so that the model is constructed sometimes state machines are used by designers and constructors as implementation tool and as I said the models are used or developed so in those cases the state machine can of course be used directly we can directly use the state machines otherwise the state machine model has to be constructed based on the requirements by testers that means as I said model based testing where we develop the model first then we define the states or based on the requirements depends on the simplicity of the complexity of the requirement or the underneath we are going to develop the state machines so what will happen is during the construction of the state machine faults can be there so the key properties with a state machine is that all input types can occur regardless of the state of the machine implemented model based design or it could be implemented directly on the requirements the requirements should be so good and clean that it is implemented directly from the requirements so same way we can test it if the models are available we are going to attack the models to test it if the requirements are there to implement we will function the function it is that is underneath the requirements in our testing different states that are responsible for state machines okay so there are other detail like the model model based testing and all probably we will study that in detail model based testing class so basically we need to the strategy is to elaborate or focus on the transitions so very important thing you need to understand the concept of transitioning and as I said in the earlier slide transitioning will happen with the help of event and event will result action so all these are part of the state n I would say n so it is very important from different states from zero to state n and from the state n to state m a b whatever it is all are based on the transitioning so we need to have a strategy test on the transitioning between the states so zero to switch coverage requires one test case because we know about the one transition and for each possible transition we have a one to switch for one possible transition is there so likewise we have for n to one consecutive transitions n to switch coverage requirement is there so that is how state transitioning testing is taken care where transitioning has to be understood very well okay now having understood the different behavior and the states we need to categorize the faults so what are the fault categories that are there for incorrect state behavior we know that states can mislead to different errors or faults and how we can categorize those faults the state based embedded system behavior the first is that the state chart do or does not represent a correct translation of the system's function specification that means it is not actually presenting the functional transition the state based test design technique is not capable of revealing these types of faults because the state chart pencils are used as the basis of the test so we will not be able to identify the faults simply because our tests are based on this state based function specification if there is a problem with that specification of the switching and all that we will not be able to find the problem the second cause is that the state charts are syntactically incorrect or inconsistent that means these faults can be revealed by static testing so these are some of the issues that we can come across while doing the embedded software testing using state transition so this type of faults we could reveal while doing the testing itself or the strategy needs to be reworked or alternates we need to find out after finding these faults so second will happen because syntax errors are there are syntactically not implemented or it is not consistently behaving the implementation is wrong so these faults can be revealed by static testing so static testing testing anyway we study in detail so we have analysis or inspection methods with the help of that there are additional aiding tools just replace or any other tools with the help of that we can reveal these kind of a syntactically or inconsistent issues like each of input output is mentioned in the events those kind of a problems are found out with the help of that static testing if the faults found this way are corrected then the state chart constitutes the basis for dynamic testing using the state based testing technique so after the static testing this will be used for doing the state based testing the third cause is the transition sorry the transition from state charts to code that means how the code is implemented from the state chart that is implemented exactly what is required for transition that is where the fault category lies it is becoming increasingly common that this translation is performed automatically that means we have a generator code generator from the models such as ITCEN and all that model based design they do they have a auto code feature wherein they generate the code from the model itself with the help of that they integrate and execute the code but it is not hundred percent the code that is developed from the model using the auto code still we need to fine-tune it to make it exactly what is the code generated this way and exact the representation of state charts the use of the state sets as the purpose design in this case therefore not useful and the application of the state based design technique is super close however if coding based coding based on state charts is applied without the use of the general code then the state based test design technique should be used it means auto code generator we are not you then we should be stick to testing with the state based testing technique what we have seen with the help of positioning and state based testing technique the next we will study in detail about the faults different faults can occur for doing the state charts and the software having implemented the state techniques state transition techniques states can have issues states without incoming transitions that means without any input specification and all implementation fault that means states are happening without any transition second type of faults can occur missing initial states that means the input is not there all parts in a state chart must be defined in the case of a transition to a super state in which the resulting substrate is not indicated the super state must contain a initial state that means where we have we do not have a resulting substrate there should be a initial state at least to switch off if the initial state is not indicated state in which the transition terminates cannot be predicted we do not know where it is going to be terminated the states specification or implementation fault specification could be wrong or the implementation could be wrong so this is one of the faults missing initial state third one is third one is an additional state that means an extra state something like the system turns out to have more states than it is represented in a statement which is something like a gender state or a gender state so it is again a problem with the implementation the implementer has added more states unnecessarily so that those path cannot be covered or that is a fault the fourth one is a missing state that means one state is missing if supposed to be if it supposed to have four states but instead that three states are represented with the help of the code then that is a fault the state that is shown on the state chart but it is not present in the system the other one is states are there but one particular state is corrupted a transition takes place to a non valid state or the state itself is not existing but the code is that it is going to go somewhere but it may crash or it may do a unpredictable behavior very difficult to test sometimes so it is a implementation issue basically so we have two specification or implementation issue where we do not have a incoming state or some of the initial states are missed and implementation wise we have a redundant states the functions both we have a missing states where there is no state at all and the states are there but it is corrupted so that system will not be here properly or it may crash so this is some of the faults that can occur for the state charts the second category is sees on gods so gods so we should point to a transition and not to a state so gods are something like what I said in the earlier thing it is a event where continuously that is happening in terms of one example you can say my type is switching to easy that means this present so it is a guarded transition so what are the faults that we can have in the guarded or the gods so God must point to a transition not to a state always God should be identifying transition what transitions are used as a transitions so transitions must have an accepting and present in the state conflicting the transition should not be there and even triggers a change from one substrate to another substrate and at the same time it triggers a transition out of the super state that means the main state itself is not able to achieve is a conflict between different transitions it may happen to the that state or the state while happening that it will be out of the main state itself so this results in the fact that a certain substrate is more longer we can reach that means it will never a go to that substrate because in a complex systems we have seen many main states and many substrates so without coming to the main states it is not possible to go for a substrates so I will try to draw a simplistic way possible here so there is a main state two main states are there and there are small substrates but into this main state suppose and we have a transition between these we know transition between these two we know and transitions from this we know this we know this is the major the main state is called super state and these are substrates and we should have a mechanism to switch to this substrate through this main state similarly the other way also so it cannot be conflicting for state transition between the substrates to main state substrates should always be predictable such a way that the state transition is smoother that is what the meaning of the reachable substrates should be reachable that is what the meaning means so confliction should not be there for state transitions okay next one is missing or incorrect transitions that means as I told in the previous states itself the states are not there but transition is happening sorry there is the states are there but the transitions are not proper or it is missing the resulting state is a neither a correct or not correct in terms of switching there transitioning so other one is the missing or incorrect actions so we know that different actions are there due to which the transition will occur so there has to be action that could be missing or actions are improper so incorrect actions are performed as a result of executing a transition specification issue implementation issue all this could be because of specification also or it is a implementation problem also so transitioning and states these two are very much important in terms of testing the embedded systems where states are implemented so fourth one the last one is and of course we have a this one is we will quickly go through that also events so we have we know that events due to which the states will transit we have a missing event the faults could be there in this event an event is ignored that means the events are not happening specification and or implementation fault then there is a hidden path that means events are happening but we do not know the reason why that event is happening a reaction to a defined event takes place although this reaction is not defined in the state chart that means sneak path it is also called as a sneak path so implementation path fault purely so some events are happening but there is no reason for that so not due to some actions or something like that that events are happening that is nothing but a hidden path event the third one is the reaction takes place to an unidentified event that means the reaction is happening but there is no event it is also known as a trap door that means it is the implementation fault so reaction is there due to something but there is no event as such this is the fourth type of faults that can be there in the state-1 embedded system the last one is missing in years this typically talk about synchronization in an R7 operation a synchronization substrate in one orthogonal region without a connection to an event in other order but means we have a two spear two spears having different state switching but there is a there is no proper synchronization two regions the wrong implementation of the synchronization sort of state can lead to rarely or not at all reachable states no synchronization at all or to a barely detectable table deviation from the required system so this is basically talking about the synchronization between say subsystems where both the subsystems let's take a two subsystems both subsystems have implemented the state machines so in this case so the events that are happening between these subsystems and switching between these subsystems or interaction between these two subsystems are purely based on the synchronization so the synchronization has to be intact in order to work it properly so this is what is the fault could occur in the basically in this region of the synchronization and we will try to have a small table state transition fault categories coverage how this is defined this is the last slide so coverage of the fault categories we will define the different faults 1.1 0.1 0.3 so there is a checklist state transition technique we can apply or not so based on this this fault categories this different fault categories are all what we have discussed here 4.1 0.2 0.3 then 3.1 3.4 2.1 gods states have 1 1 to 5 likewise we have different faults so we have a checklist checklist till the sense whether it is a ticked or it is wrong something like that we are going to have it while defining the state transition technique very important so that the coverage is so that is what the meaning of this we can have this this this has not covered in our embedded software testing so we know that this checklist with the help of this we have the state transition technique is happening so this fault category can be tested by both a checklist and the test design technique it means we are going to have a coverage for all the 2.4 can be covered with the help of test design technique and with the help of checklist also category 4.3 is not covered by the test design technique error guessing is in this space one available option error guessing the technical will probably touch base so error guessing is something like we identify an error or a fault by guessing what could be the problem so this will happen during the dynamic execution only because the tester will have an understanding of the system how it is executed only when he is doing some other tests he will guess some errors while doing some other tests so 4.3 is what type of thing is a reaction takes place to an undefined so we know that as per the specification we have tested but what will happen during the test is that some reaction is happening but there is no event defined for that so it is also called so that is what the category is about so this can be done with the help of error guessing or analysis or instruction impact so this will help in terms of coverage of state transition is the elaboration of this so we will continue the state transition with some x y's and other testing mechanisms and methods in the next class so that is the conclusion