 నిర్న్నిన్ నినిల్నంవాడిల్దరా. Today we will see the exercises regarding test cases and scenarios from a set of requirements which we had studied about the requirements in the master class and try to study that with requirements and the corresponding test cases. So we had also gone through the example SRS it is called embedded unit instrument. We will just try to recap that then we have a test review checklist this is based on high level testing so there is a sample here this typically being done as a completion step in auto typical rate of the embedded software testing high level testing that is been done on the set of requirements. So this checklist will talk about the rules and whether rules are followed and whether that embedded software testing can be taken for in next level like this it will be used so that is how the rules are being used. So once so these two exercises are done we will try to continue the exercise in terms of identifying and establish traceability matrix for the developed test scenarios from the set of embedded unit instrument requirements. So you know the traceability, traceability basically is required to see and report that from the requirements to test cases how the coverage is there how we are able to trace different requirements to test cases similarly test cases to requirements so two are different basically I mean though we call it as a traceability so both are required because the coverage aspect is different so the test cases requirements is called as upward traceability and requirements to test cases are called as downward traceability okay. Now let us try to recap the requirements so as far as one talks about the embedded unit instrument operating in the five operational modes such as the unit operational mode and then here you can see different modes of operations so how they can enter and exit so this is a parallel mode of operation is fail which can go from any of this unit operational mode at any point of time based on the different conditions so those conditions are nothing but the modes of operations typically SRS 2 onwards we have modes of operation requirements I think we had gone through this SRS 2 regarding modes of operation SRS 3 as well with any to mode SRS 4 over operation mode 5 over maintenance mode and the 6 again maintenance mode so likewise we have different modes of operation SRS 2 to SRS 5 6 other similarly we have performance requirements in terms of SRS 7 to 11 here we know that the booting type requirements and the workload performance of the processor or the CPU how much it should be and also along with the timing and the workload we have the memory related performance requirements such as flash memory RAM memory stack memory so how are we going to verify those let us try to go with some few example test cases so that there is a framework on which the entire testing can be taken up further in terms of test scenarios as well as the telequation similarly we have a communication requirements in terms of how the instrument unit can communicate with the external world it is through can messages we know that because the first requirement talks about the different messages it is receiving and based on different messages different modes of operation so there is a watchdog requirements you know that watchdog should be pulsed less than 500 milliseconds so this are some of the requirements for which test cases have developed so let us try to understand the test cases in one of the session we tried about how a test spec or the test cases should be existing so we need to have the requirement document test plan we assume that test plan is available and test spec which is nothing but the test cases scenarios corresponding to requirements then we are going to group it then we are going to press it these are some of the specific activities that we do for developing the test cases and in the test specification we are going to have a strategy in terms of how we can do it then practical steps which are nothing but the test procedure this how we do so these are some of the things that we need to do we know we have gone through a example of template how it should look like one of the theoretical class so let us try to understand the test case perspective how it can be developed yeah so we have about three levels of four levels of requirements in terms of modes of operation performance requirements communication requirements and watchdog requirements so we know the templates how we are going to use it the first section should talk about the test case identification for each of the requirements you can see as each requirements we need to first identify this case I guess we have gone through this template how it should look like like it should identify with the test ID it should be unique for each test case and what is the input for that particular test case so what is the condition that for this input which should exhibit then what is the expected result that we are going to have similarly for each of the requirement like we are going to take up SRS 2 SRS 3 SRS 4 likewise we are going to have for each of the requirement so that is how we develop test cases and the grouping is based on different functionalities like first few cases we will concentrate on the modes of operation next one more performance requirements and next grouping is based on the timing and next group could be based on the watchdog likewise you can group it but before grouping first of all we need to have is the test cases individually identified for each of the requirements is very important and basically we can adjust like what test case can go into what and what can be from the or if it duplicate or redundant any aspects that we can do first the first and foremost thing is develop the test cases for each of the requirements once we are done with all that then we are going to have a grouping once the grouping is done and we know that for each group there is a set of conditions that need to be existing before we start the practical step or the test procedures so what are those conditions they are called as pre-conditions so pre-condition for example I have put for one of the test case we can have a test group one which is nothing but relating modes of operation so what are the things that we need we need to power on the unit and set the below values below values could be something like what are the inputs or the unit should be hooked so what are those one could be can message adapter should be up similarly any interconnected interface delivery subunits should be powered okay so what will we need some discreet we could need should be up likewise we are going to have the pre-conditions so the pre-condition can be unique or different based on the type of group that we are using so for modes of operation we can message should be coming because without that we cannot test the modes of operation because similarly we need to apply power a voltage of 5.0 so like this we are going to have it and some of the requirements we may not be able to do dynamically or when the target is running so those list for static analysis where we need to do it static execution is by seeing the code so like performance requirements some of like memory map those things you don't need to execute on the target so those cases we are going to list it out here telling that that group of that specific scenarios can be tested statically or static analysis based on that similarly the template talks about the scenario functional or operational requirements next to test cases scenarios categorized and non functional requirements etc that is basically whatever the user or business based functionality means the instrument should be doing some function like we should rotate the motor that is the actual requirement so the non functional requirements such as you should power up within 5 seconds something of those test cases they are not this is related or user related that is all performance or supporting sort of a requirement so likewise we are going to have the appendices updated for the test case that is one section that we have and the first sections what we have seen is test cases identification for each requirement so this is what we are going to do so for example we will study a few requirements and few test cases per se okay so as far as to we know that what it talks about it talks about the modes of operation like we know that the instrument shall set the mode to failure mode in the following cases there is a power logic so one of these conditions one of these three conditions if it occurs it is going to enter into failure mode that is what the thing so here what is the input contents of this having the inputs so let us try to understand one contact or one condition when mode is in metastore so mode is a input and received message is an input so what is the output fail mode that means again mode set to fail mode condition is what this itself is the condition so first condition second condition third condition one of these condition exits it is going to enter into failure mode okay let us try to draw an example cases first test case let us try to define so we know that mode is an input received message is an input why because scan message is a dependency right so message is one input mode is another input if those two these two are inputs we are going to apply some conditions for that input and we are going to get the experience so what will happen if mode is in maintenance mode correct if this input is satisfied and when we get a receive message zero once we are enough do not worry about what is it CRL message just assume that because we are focusing or our emphasis is to test this portion not the actual data that may be a robustness in terms of different message other than zero once around what will happen that may be we can define later but we will start with a normal case saying that we have fed the two inputs maintenance mode and the message with zero and serial CRL mode directly as per the requirement we should go to fail mode so this we have tested here and in the next case you can see we have to test with the CRL message zero to CRL in that case also it will go to fail mode similarly the third condition when the mode is in init mode if the status is in error state that is during initialization if any error occurs it will go for failure mode so these are state forward test cases that we have seen for this requirement similarly if more conditions are there we are going to apply as per that okay the state to define now this is our logic so that means any of these conditions or multiple of these conditions occurs so we have something like a or b or c equal to b b means it is a failure mode so we are going to have a true table sort of a thing where either a can be set to true or b can be set to true c can be set to true in that condition this will go to fail and next one a b set to true a c set to true a b c set to true in this condition also it is going to go for failure so likewise we are going to have this is called that ncdc or the modified condition decision logic because based on the condition different decisions are there here when a a becomes true the condition will be fail when b is true condition will be fail c is true condition will be similarly a and b both are true condition will be fail right both are true fail both are true fail similarly a b c last case which becomes to true to be fail next we have what else left everything will have right everything we have written so in these kind of things it is good to have something like a true table we can define that way it will be easier actually maybe I will try to have one more column added so a b c and the output is what we are trying to set for different values so we know that combinations of a b c we will try to set zero zero sorry one zero zero output will be fail similarly zero one zero output will be fail this becomes zero this becomes zero c next condition zero one one typical true table we are going to have it for all the combinations the more over we may not need because we know the result of this why we need why we may not need is the independence we need to prove I will try to explain that okay here you can see the multiple two table combinations right c is true output will be false and b is true output will be false similarly both are true will become false and now we are going to set a as one and we are going to vary it here this is going to be still true the last condition is zero zero zero it will become true that means true means there is a failure or not a failure here in this case there is a failure right okay one more condition is all should be one should become failure yes means basically failure so for each of this we need to develop the test cases adding the inputs accordingly okay now we have tested about is normal cases of with a true table modified condition next within each of this we can identify other test case or other group of test cases such as okay I will try to draw that only okay so input is more maintenance more and receive message is zero one CRLF right that we have already tested this will become failure okay next condition within this test case input mode is not of maintenance mode that is not we do not know what mode it is so it will become no fail correct because we are not all there in that actually the next one input is in maintenance mode but the received message is not zero one CRLF it is something else x x x whatever it is so this also will become no fail so like this the combination that we need to have that is very important once this is done then we are done with the complete test cases and we are going to apply it okay the next thing that we need to take care is the independency very important term you can see in the above case abc is set here it has occurred false now we have proven only the b has changed from zero to one whereas the remaining things are constant let also we need to prove right because remaining thing is not constant here we have seen b has changed along with c also we do not know because of what the failure would have occurred so better to have the independency such as setting it back to zero so that we are proving the independency with this because of this only the failure has occurred and not because of this or the combination of this so that is how independently we are going to prove similarly for other cases also like we have a zero zero zero no fail and since this has toggled these two bits because of this they are getting the fail so that is how the effect of the inputs we need to tackle it appropriately so that independently this is one of the important thing that they look for when we are going to write the test cases so that is how we are going to have for different sort of combinations and inputs for that particular requirement okay next one next one is SRS 3 this talks about what when the mode is unit mode and the status is no error state that means no error when the unit is in the when the mode is in unit mode the instrument shall set into operational mode so two inputs mode and status unit mode no error it will be operational mode mode received message mode and received message so this is not a right test case maintenance mode okay let us not write to this we will try to put a simpler one mode status non-init mode okay let us put it more simpler it is in unit mode status is error so what it will become it should not be not of operational mode that is for sure because the requirement says it should be there in operational mode only when so by going through the operational mode requirements this is clear for us probably by seeing if it is not of operational mode what is the mode we are going to take care let us try to go through the requirement again we will come to know requirement is yes it is going to go for the failure mode because if it is going to be no error state then it will be operational otherwise it is going to go for failure mode that is what it says right okay so nothing but it is nothing more fail mode so likewise we are going to add this case while looking at the requirement so for three we have done okay four is regarding maintenance status status alive messages and six is about the next set of messages zero four likewise we are going to add it I can see particular SRS and for that test cases we are going to add one more thing you would have noticed is interface requirements tested so what will happen is some of the signals that are having a dependency for particular requirements suppose for this function requirements for the signal dependency is there some discrete and that we need to list and by listing that we are also trying to test that particular interface requirements so that also we need to cover it as an input that may not be a full-fledged functional requirements but there is a dependent interface requirements okay the next one is performance requirements let us try to understand what performance requirement talks about the entire process of booting up till operational mode shall not take more than one second that means upon power up we should not take more than one second to become operational mode so how we are going to do there is a two input that means we need to measure right measure the time that is what it says between boot up till off mode okay this is something like a assertive test case where we do not have a negative or where what is it called up we are expecting something with some actions here action is the thing but between boot up boot up how it is going to happen upon power up that is an input input is power up and mode and condition is power up entire process of or boot up boot up how it happens with a power up button power on we can say the action is called as power on or boot up so output is time difference between operational mode entry from power on time so something some instrument called tautiloscope okay with tautiloscope we need two tapping parts or we do not need two tapping parts or depending on what sort of a process we suppose power up has a pin number 20 where you can see the glitch of the signal pulsing at a certain level by words if it is we can observe that with one pin captured there and operational mode if it is tied up with a led something say led 2 it will have a port something like a GPIO port or whatever it is so these two we can see it so that we can see the reference as one with a power up pin other one as in the led port when it is going to become operational mode so the difference we can find out with the help of this so that will become a test case in terms of measurement so input is power up so we need to give a pulse to or pulse or reset to pin 20 booting the processor measure using tautiloscope what will happen is expected result is less than one second that is what is the right so that is how we are going to measure it with the force of play and try to validate the test case okay okay next type of requirements we have communication requirements okay here you can see two requirements are there instrument shall communicate through can messages with outside interface the instrument shall communicate its alive status at one second at least one second that means two things are there we can combine this requirements to have multiple places under one group saying that proving this also can prove that it is communicating and it is also communicating at which status that one second so it is just a validation of this basically there is no verification like there is no input that we can tweak or we can modify so what sort of a test cases we can have test case one will have observe the output can message check whether you can message are received at every one second next one check whether the can message belongs to alive status these are the important steps to validate this requirements right okay next negative type or when the instrument is powered this is going to happen so switch off ui what will happen is no messages are observed no message should be observed outside so this is proving that instrument will communicate only when it is powered off outside the box and the rate at which the can messages are coming how we can verify the rate is based on the timestamp because every can message will have a timestamp a logger outside in the host with that logger we can see a difference between message to minus message one there should be one seconds of course it may not be exactly one second it could be something like 980 seconds it depends again to one zero zero here tolerance of plus or minus 20 is there you can see it can fall anything between 980 to one zero two zero so it depends on type of system tolerance also will be there so you may not get exactly so they will specify in the requirement accordingly saying that for this tolerance it should work so that way we need to verify the such requirements any timing requirements or any one log or any of the outputs that has a tolerance we can verify that so this is how communication requirements can be tested with the test cases this way the last one being the watchdog requirements so there are two requirements here the instrument shall configure the interval what about generate a reset to microcontroller with a threshold duration of five minutes what it means is it has a configuration saying that when it is up and operational it should be configured for find a millisecond such that the watchdog will be satisfied with a pulse of less than five milliseconds so it is the next requirement if it is not the watchdog is going to reset it because it is configured for find a millisecond right okay so here cases we need to verify in the sense that first one is verify the configuration of the watchdog this is theoretically or by seeing the code or by seeing the registers we can validate dynamically we can validate such a way that we can capture the pulse of the watchdog usually watchdog is a circuitry where it has a counter and that counter is configured for 500 and there is a decrement counter the 500 becomes 499, 498, 494, when it becomes 0 it is going to it is going to reset or pulse the reset pin of the processor such that the processor gets reset how are you going to emulate this somehow you make sure that you reconfigure the watchdog or you make it hang the program that is there in the this thing or capture the pulse so what is responsible for pulsing the watchdog so that should be less than five milliseconds so that is what the second requirement talks about at least once in every five milliseconds or less it should be there so one is configuration other one is whether it is pulsing properly or not we are going to verify this is how we can verify the watchdog sort of a requirement okay so likewise we are going to have the test cases defined with test ID inputs conditions expected results and appendices we have studied now having seen all these let us try to understand the review checklist we have done the testing of high level requirements whatever I have demonstrated so far is writing the test cases and the requirements and how procedures can be written on this is what we have understood now having done this we need to understand the checklist usually this will be a getting criteria for the test plan or test cases to make sure that the rules of the particular verification of the test cases are adhering to the requirement or as per the need that is what we are going to do okay okay so these are an example template generally they use it it is again specific to the organization or specific process that is being followed in the type of embedded let us try to go through this and try to fill out the checklist on what we have done so far okay first one are templates followed during the development of test cases this we had a document this template which we have followed right yes are the valid equivalence classes and it is applied to all inputs of high level requirements yes we have seen the equivalence classes in terms of the complete truth table and all and set of inputs we have considered are limits values used for exposed remove here there is no exposed signal but can used so there is a limit in terms of the single flux here the values coming from there we have used for inputs structured in a table are bounds and one intermediate value of the table equivalence class there is no structured input table so this is not applicable we generally see the functional analysis used for the logic equations yes are particular test cases created for time related functions and state transitions yes but we have them only for the time related there is no transitions we have is one the questioner test case created for each external inputs yes we have the negative or the different values of kind of inputs that we try to put it like robustness so that is what is there is identification format of test cases we have seen that every test case has its own unique ideal is each high level requirement covered by at least one test case and we will correct one it is very important correct one is also so this based on the review we need to fill this whether correctly with the yes we are done for each of the requirements for each one test case you reach test case created covered by scenario and by the correct one this the test cases like we have our test case for each requirement and that requirement of multiple scenarios and the correct scenarios we have identified are values of inputs and outputs defined for each test case is each scenario qualified as normal is probably we are not done this needs to be done based on the validation of test cases this will be taken care since we are not completely valid if we review and all that once we have that we can define these things that is what in this justification we should be able to report it saying that we know what is my action for this whether it is correct or not is it cost test coverage or not it is commercialized itself I think we do not have that so there is a two section one is guideline other one is rules rules are mandated to be followed as yes there is no solid test case and also called as deviation of the result which the report will not be accepted by the designated authority or after a customer as we have seen guidelines is a description of these scenarios here and there somewhat it is I will say more if you can add no description are the expected results defined for each test scenario or it is bench specification defined for each test case what we have done is we have come to broken and identified the test bench or the setup that we required the preconditions defined for each test case yes we have seen that it exists so this is how we are going to fill the test case checklist it is called deviation of test cases it is objective description and there is a saying that is in the following so that is what we have to do or set the develop test case from the requirements so that is how checklist will be filled this ability this will continue in the next practical session in terms of upward test ability as I said from test cases to requirements is called as upward test ability or downward test ability which is required to test cases