2.1 BOUNDARY VALUE ANALYSIS This is a simple but popular functional testing technique. Here, we concentrate es input gals and design test cases with input values that are on or close to boundary values. oc fas, shown that such test cases have a higher probability of detecting a fault in the software. Suppose there is a program ‘Square’ which takes ‘x’ as an input and prints the square of ‘x’as output. The range of ‘x’ is from 1 to 100. One possibility is to give all values from 1 to 100 ‘one by one to the program and see the observed behaviour. We have to execute this program 100 times to check every input value. In boundary value analysis, we select values on or close to boundaries and all input values may have one of the following: (Minimum value (ii) Just above minimum value (iii) Maximum value (iy) Just below maximum value (¥) Nominal (Average) value These values are shown in Figure 2.2 for the program ‘Square’. x 12 50 99 100 Figure 22. Five values for input ‘x’ of ‘Square’ program These five values (1, 2, 50, 99 and 100) are selected on the basis of | boundary value analysis and give reasonable confidence about the correctness of the program. There is no need to select all 100 inputs and execute the program one by one for all 100 inputs. The number of inputs selected by this technique is 4n + 1 where ‘n’ is the number of inputs. One nominal value is selected which may represent all values which are neither close to boundary nor on the boundary. Test cases for ‘Square’ program are given in Table 7A Table 2.1. Test cases for the ‘Square’ program Test Case I a apectedoutpat 2 > 4 :: 50 Z f Bo 2500 —. 9801 400 100002.1.1 Robustness Testing This is the extension of boundary value analysis. Here, we also select invalid values and see the responses of the program. Invalid values are also important to check the behaviour of the program, Hence, two additional states are added i. just below minimum value (minimum value ~) and just above maximum value (maximum value *). We want to go beyond the legitimate domain of input values. This extended form of boundary value analysis is known as robustness testing. The inputs are shown graphically in Figure 2.6 and the test cases for the program ‘Addition’ are given in Table 2.7. There are four additional test cases which are outside the legitimate input domain. Thus, the total test cases in robustness testing are 6n + 1, where ‘n’ is the number of input values. All input values may have one of the following values: (i) Minimum value ii) Just above minimum value (iii) Just below minimum valuc (iv) Just above maximum value (v) Just below maximum value (vi) Maximum value (vii) Nominal (Average) value(0.500) (0.400) (0.300) ¥ (0200) (0.100) (400.0) ee a (20,0) (300.0) 0) (100.0) ——e Figure 2.6. Graphical representation of inputs Table 2.7. Robustness test cases for two input values x and y x y Expected Output ee a 99 300 Invalid Input 2 100 300 400 3 101 300 401 e 200 300 500 5. 299 300 599 » 300 300 600 E 304 300 Invalid Input B 200 199 Invalid input : 200 200 400 = 200 201 401 ql 200 399 599 2 200 nn cag ~ Invalid Input 2.1.2 Worst-Case Testing This isa special form of boundary value analysis where we don't consider the *single fu! assumption theory of reliability. Now, failures are also due to occurrence of more than o® fault simultaneously. The implication of this concept in boundary value analysis is that input values may have one of the following: (i) Minimum value (ii) Just above minimum valueFunctional Testing 45 (iii) Just below maximum value (iv) Maximum value (¥) Nominal (Average) value The restriction of one input value at any of the above mentioned values and other input values must be at nominal is not valid in worst-case testing. This will increase the number of test cases from 4n + I test cases to 5° test cases, where ‘n’ is the number of input values. The inputs for ‘Addition’ program are shown graphically in Figure 2.7. The program ‘Addition’ will have 5? = 25 test cases and these test cases are given in Table 2.8 (0, 500) (0, 400) + (0, 300) 4 ¥ (@, 200) 4 (0, 100) + 1 T T (0.0) —(100,0) (200.0) (30,0) (400,0) ——— Figure 2.7. Graphical representation of inputs Table 2.8. Worst test cases for the program ‘Addition’ Test Case x y 100 200 100 300 100 100 400 101 200 101 201 101 300 399 1 Bs 3, 4 5. 6. 7 8. 9. 10. aL 12. 13. 14. 101 101 200 200 200 200Functional Testing 63 2.2 EQUIVALENCE CLASS TESTING As we have discussed earlier, a large number of test cases are generated for any program. It is neither feasible nor desirable to execute all such test cases. We want to select a few test cases and still wish to achieve a reasonable level of coverage. Many test cases do not test any new thing and they just execute the same lines of source code again and again. We may divide input domain into various categories with some relationship and expect that every test case from a category exhibits the same behaviour. If categories are well selected, we may assume that if cone representative test case works correctly, others may also give the same results. This assumption allows us to select exactly one test case from each category and if there are four categories, four test cases may be selected. Each category is called an equivalence class and this type of testing is known as equivalence class testing, 2.2.1 Creation of Equivalence Classes The entire input domain can be divided into at least two equivalence classes: one containing all valid inputs and the other containing all invalid inputs. Each equivalence class can further be sub-divided into equivalence classes on which the program is required to behave differently The input domain equivalence classes for the program ‘Square’ which takes ‘x” as an input (range 1-100) and prints the square of *x’ (seen in Figure 2.2) are given as: @ { 1. 100 } (Any invalid input where x is greater than 100) Three test cases are generated covering every equivalence class and are given in Table 2.18. Table 2.18. Test cases for program ‘Square’ based on input domain Test Case Input x Expected Output 0 Invalid input 50 2500 101 Invalid input The following equivalence classes can be generated for program ‘Addition’ for input domain: 100 < x < 300 and 200 < y < 400 } (Both x and y are valid values) 100 < x < 300 and y < 200 } (x is valid and y is invalid) (iii) 1, = { 100: x $300 and y > 400 } (x is valid and y is invalid) (iv) 1,= { x < 100 and 200 < y < 400 } (x is invalid and y is valid) (¥)_ 1, = { x> 300 and 200 < y < 400 } (x is invalid and y is valid) (vi) 1,= {x < 100 and y < 200 } (Both inputs are invalid) 1, = {x < 100 and y > 400} (Both inputs are invalid) (vii i) 1, = {x > 300 and y < 200 } (Both inputs are invalid) (ix)_ I, = { x > 300 and y > 400 } (Both inputs are invalid)test cases are given in, is shown in Figure 2.9 and the (400, 0) (200, 0) (300, 0) Invalid input 300 Invalid input 300 Invalid input Invalid input Invalid input domain may be mutually exclusive (as shown in Figut regions (as shown in Figure 2.10 (b)). for the design of equivalence classes. Every cup! for Square’ program, the output domain equivalent2.3 DECISION TABLE BASED TESTING Decision tables are used in many engineering disciplines to represent complex logical relationships. An output may be dependent on many input conditions and decision tables give a pictorial view of various combinations of input conditions, There are four portions of the decision table and are shown in Table 2.30. The decision table provides a set of conditions and their corresponding actions, Table 2.30. Decision table Stubs Entries Four Portions 1. Condition Stubs Condition 2. Condition Entries 3. Action Stubs 4. Action Entries Action 2.3.1 Parts of the Decision Table The four parts of the decision table are given as: Condition Stubs: table. These conditi Action Stubs: All possible actions are listed in this lower left Portion of the decision table. Condition Entries: In the conditior of columns and each column table are known as inputs. All the conditions are represented in this upper left section of the decisio ions are used to determine a particular action or set of actions. n entries portion of the decision table, we have a numb represents a rule. Values entered in this upper right portion of thas some associated action o, 1s are KNOWN aS outputs” Lue: Pts an % Action Entries: Each entry in the action entries portion actions in this lower right portion of the table. These val dependent upon the functionality of the program. 2.3.2 Limited Entry and Extended Entry Decision Tables ete set of test cases Without yy ciated with a rule and eeneraten th yy Decision table testing technique is used to design a com! internal structure of the program. Every column is as case, A typical decision table is given in Table 2.31 In Table 2.31, input values are only True (T) or False (F), which are binary conditions » decision tables which use only binary conditions are known as limited entry decision wy The decision tables which use multiple conditions where a condition may have Possibilities instead of only ‘true’ and “false” are known as extended entry decision uy, {[COPE04). 2.3.3 ‘Do Not Care’ Conditions and Rule Count We consider the program for the classification of the triangle as explained in example 23% ‘decision table of the program is given in Table 2.32, where inputs are depicted using bia ‘Table 232. Decision table for triangle problem ca b? +027 8, fiinclude j void main() P { 4 float A,B,C; 4 elrscr(); 5. printf("Enter number 1:\n"); 6 scan{("0", BA); h printf("Enter number 2:\n*); 8 scanf("%f", 8B); 9. printf("Enter number 3:\n"); 0. scanf("%E", 8C); /*Check for greatest of three numbers*/ 1 if(A>B) { 2 if(A>C) { B printf ("The largest number is: &f\n",A); ts } 3 else { a. printf("The largest number is: %f\n",C); a } L i - gin 2 if(CB) { Bo printf(*The largest number is: *f\n",C); } (Contd.)LL CUCU 126 Software Testing (Contd ) 23. else { 2%, printf("The largest ramiber is: f\n"B): 3. } 26. } 2. getch(); 28. } Figure 3.11. Program to find the largest emong tree members i rm fa _———, D-O-O-O- OE164 Sorewere Tooting 3.8 IDENTIFICATION OF INDEPENDENT PATHS ‘ the num in If there are loops in a program. ber meet ein cram een and again. However as defined earlier. an independent path shoul have a eas: one fp aig axa is to be traversed. We should identify every independent path of Prog, or ‘special attention to these paths during testing. A few concepts of graph theo, ay Skee SSeS cy ws ety tadcponcnt peo te 3.5.1 Cyclomatic Complexity This concept involves using cyclomatic number of graph theory which has been Rede i is f independent paths thy & exty. This is nothing but the number 0 rah i eee IMCCATE] inne ths cme and ave ee metho yt ’ cyclomatic complexity. @) VG)=e-n+2P where V(G) = Cyclomatic complexity G: program graph n number of nodes ©: number of edges P: number of connected componcnts | } The program graph (G) is a directed graph with single entry node Connected graph is a program graph where all nodes are reachable fre node is also reachable from all nodes. Such a program graph will hay (P) value equal to one I there are pans of the program graph, the vah Pars ofthe program graph where one part may represen the main Pro} Sub-programs, and single exit node 4 | pm entry node, and ei | #€ connected componey | jue will be the numbers gram and other pars ay : Te are more than two outgoing ede iged in order to hav p © only two outgoing edges. If itis is not applicable, lexity: ion of fan dependent paths in of functional Program graph G. a Pathif VGj=1_ "St program graph G does nt afet Sal onthe ison sexo of G,Esvertalot raph Theory 148 jgerie Poem graph given in Figure 3.24, os ur of eptratie complet can be calculated as yw@-e-at2P ) aa 4 y_ @)= No. ofrepions ofthe graph 4 bp MY Hence, V(G) = 4 Thee regions (1, 2 and 3) are inside and 4" is the outside region of the graph (ii) VG)=+1 =3+1=4 There are three predicate nodes namely node a, node ¢ and node d. ‘These four independent paths are given as: Path! : ace Path2; ade Path 3: adce Weemmae tnt: be aph, another program graph given in Figure 3:25 wih tree pats ofthe Progam iiV(G)= e-n+2P° a = (447#8) — (446+7) + 2x3 ) ; = 19-17+6 =8 We calculate the cyclomatic complexity of each part of the V(G- Part I)= 4-4+2=2 VG- Part Il) = 7-6 +2=3 WG - Part Ill) = 8-7+2=3 Henes,V (GPa 1 G— Par IU G— Part tt) graph independently = V(G— Part l) + V(G— Pat Tl) + V (G — Part 111) a : : general, ects complexity of a program graph with P connected compone ore Leica cyclomatic complexities, To anders ‘a ns denote the P connected components of a graph, and & Bree Tee a tCI* connected component ofthe graph. Then,4,1 CONTROL FLOW TESTING This technique is very popular due to its simplicity and effectiveness. We identify paths of the program and write test cases to execute those paths. As we all know, path is a sequence of statements that begins at an entry and ends at an exit. As shown in chapter 1, there may be too many paths in a program and it may not be feasible to execute all of them. As the number of decisions increase in the program, the number of paths also increase accordingly. Every path covers a portion of the program. We define ‘coverage’ as a ‘percentage of source code that has been tested with respect to the total source code available for testing’. We may like to achieve a reasonable level of coverage using control flow testing. The most reasonable level may be to test every statement of a program at least once before the completion of testing. Hence, we may write test cases that ensure the execution of every statement. If we do so. we have some satisfaction about reasonable level of coverage. If we stop testing without achieving this level (every statement execution), we do unacceptable and intolerable activity which may lead to dangerous results in future. Testing techniques based on program coverage criterion may provide an insight about the effectiveness of test cases. Some of such techniques are discussed which are part of control flow testing.‘printi("x= %d y= %d",x,y); } 4.1. Source code with program graph ‘select inputs like: ee C=. all statements are executed and we have achieved 100% statement covemge “by only one test case. The total paths of this program graph are given as: @) 1-7, 10, 13-15 (ii) 1-7,10-15 (iii) 1-10, 13-15 (iv) 1-415 The cyclomatic complexity of this graph is: VG) = e-n+2P=16-15+2=3 V(G) = no. of regions = 3 VWG)= 1+1=2+1=3 Hence, independent paths are three and are given as: @ 1-7, 10, 13-15 (i) 1-7, 10-15 (iii) 1-10, 13-15 but will not execute all possible four P Only one test case may cover all statements not even cover all independent Paths (three in this case).out etal fle conto yi a= 700=8.0=9 te page me Path = 1-7, 10, 13-15 7 test cases out of four are sunt veg 8 0 BT 0% ay coven aan 0, ‘Tage but it does uaran jon overage i better than branch coverage ae However, branch coverage can be achieved wig a eRe consider the seventh statement of the Program gi ‘esting every condition at given in Fi asmoeneditions (2b) and (2>0) There are four poe e aaa @) Bothare true " fa) Fists true, second is false (i) Fistis false second is true (iy) Both are false la>band a> c then the statement manber7 willbe tu (Gm psig c) would not be tested and iaememt namie 7 wale an (tld four possbltes) Ifa > band a <<, stement mnber 7 wll eg pasty). Hence, we should write test cases forever =a Ty true and false condition Selected inpus saybe given as i) 4=9,b=8,c=7 (first possibility when both are true) {t) 4=9,b=8, c= 10 (second possibility ~ first is true, second is false) (it) 2= 7, b=8, = 9 (third and fourth possibilities first i false statement number is false) let, these three test cases out of four are sufficient to ensure the exesuion of every Sindtion of the program, 414 Path Coverage aes ‘overage criteria, we want to test every path of the program. There 7 be aa Lee ANY Pogram due to loops and feedback connections. It may not be possible ie zwe may be confident abou, 168. Software Testing Foo If we do 50. : ; executing all paths in many Poe erable, Mt Yeast all independent paths sho, t of if it is riven as: . ss of the P aoe ie has four paths a5 executed. The Pret E 13-15 (1-710, iy 1-7, 10-15 Gi) 1-10, 13-15 (iv) 1-15 ths increases confidence about the correctness of the Program, pal Execution of all these paths | Inputs for test cases are given as: 4-10, 13-15 4-45 impossible when we give in Some ible from the program graph, but become impossible aive inpuy rte 2S Hence, ae ‘combinations may be found to be impossible to create 3 Path testing guarantee statement coverage, branch coverage and condition coverage. However, i sil te all the paths, W many paths in an} gram and it may not be possible to execu pi fe sould de Ei le level of coverage. We should execute at leas should do enough testing to achieve a reasonal ; (minimum level all independent paths which are also referred to as basis paths to achive be found using any method of cyclomatic complexity reasonable coverage. These paths can : ‘We have to decide our own coverage level before starting control flow testing. As we go up (xatement coverage to path coverage) in the ladder, more resources and time may be required. Example 4.1: Consider the program for the determination of the division of a student. The program and its program graph are given in Figure 3.15 and 3.16 of chapter 3 respectively Derive test cases so that 100% path coverage is achieved. Solution: The test cases are given in Table 4.1. Table 4.1. Test cases S.No. _mark4 _mark2_ mark3 Expected output Paths = es a Invalid marks 4, 33, 34 ere a a 1-12, 15-19, 32, 33,34 85 6057 Second division 7" eee : , 15-17, 20, 23, 26-28, 32-34 80 70 75 First divisi 26-28,32-34 ee ision 1-12, 15-17, 20, 23, 26-28,32- 85 90 First division with 4. 17, 26, 29-34 1-12, 15-17, 20, 23, 26,4.2 DATA FLOW TESTING control flow testing, we find various Paths of a ‘a Bs se paths. We may like to execute every dihtement of the etion of testing. Consider the following program: and design test cases to execute Program at least once before the . #include . void main () { int a, b,c; a=b+c; . printf (“%d”, a); } What will be the output? The value of ‘a’ may be the previous value stored in the location assigned to variable ‘a’ or a garbage value. If we execute the program, we unexpected value (garbage value). The mistake is in the usage (reference) of this variable without first assigning a value to it. We may assume that all variables are automatically assigned to zero initially. This does not happen always. If we define at line number 4, “stati int a, b,c’, then all variables are given zero value initially. However, this is a language an compiler dependent feature and may not be generalized. a Pw RY © e174 Software Testing i nimi istakes. It has nothing to ¢. Data help us to minimize such mistakes. It has oe flow age Taba ‘on variables, their usage and their definition(s) (signe Program, The main points of concern are: ih (Statements where variables receive values (definition). (ii) Statements where these values are used (referenced). ge. In ine number so fy ‘ 4 ible us ing focuses on variable definition and variabl Data flow testing focuses 0 are used. The varia able : . ob and above program, variable ‘a’ is defined and variables “b’ an: ‘ derncd mae (referenced) throughout the program. Hence, this technique concen, how a variable is defined and used at different places of the program 5 og 4.2.1 Define/Reference Anomalies ‘Some of the define / reference anomalies are given as: (i) Avariable is defined but never used / referenced. (ii) A variable is used but never defined. (iii) A variable is defined twice before it is used. (iv) A variable is used before even first-definition. Wemay define a variable, ue a variable and redefine a variable. So, a variable must be ,. defined before any type ofits usage. Define / reference anomalies may be identifi hy. analysis of the program i.e analyzing program without executing it. This technique ioe Program graphs to understand the ‘define / use’ conditions of all variables. Some enn ‘used frequently in dataflow testing and such terms are discussed in the next subeess 4.22 Definitions A program is first converted into a program : graph. As we all know, every statement » Fizem's feplaced by a node and flow of control by an edge to prepare « pene ‘may be many paths in the program graph, - Program g @ eeneont node i ze rome och 1S a defining node for a variable v, if and only if, te Malue of the variable v is defined in the statement corresponding to that node. It's Fepresented as DEF (v, n) where 1 is ma : the ssiement in which vis defines. VtTAbIE anu nis the node correypunins graph A . sed inthe saen es fF Variable v, if and only if, the ae “v'ip the variable a Poncling to that node, It is represented nthe node Cortesponding to the statemest (0,0) isa predicate us, to node ‘ny a ay Mode (denoted as P-use), ifand only if (denoted as Caen ee statement otherwise USE (v.10) 54174 Software Testing ize such mistakes. It has nothing to Da testing may help us to minimize su e on flow pe It aes aeriables their usage and their definition(s) (2ssignmeny day program. The main points of concem are: ing (i) Statements where variabl. (ii) Statements where these val Data flow testing focuses on variable les receive values (definition). ues are used (referenced). definition and variable usage. In line numbe, sie bles ‘b’ and ‘c’ are uscd. Th oy above program, variable ‘2 is defined and varia Soy defined and used (referenced) throughout the program. Hence, this technique concen Hane varable is defined and used at different places of the program rates 4.2.1 Define/Reference Anomalies ‘Some of the define / reference anomalies are given as: (i) A variable is defined but never used / referenced. A variable is used but never defined. (iii) A variable is defined twice before it is used. (iv) A variable is used before even first-definition. We may define a variable, use a variable and redefine a variable. So, a variable must defined before any type of its usage. Define / reference anomalies may be identified by Y Stati analysis of the program ie, analyzing program without executing it. This technique use, == graphs to understand the “define / use" conditions of all variables. Some tem = frequently in data flow testing and such terms are discussed in the next sub-section 4.2.2 Definitions ‘i : F propa sft aa ane ap. As we all know, every statement of: ; y 2 Program a ue ie a by an edge to prepare a program gmp ll ofa i : graph is a defining node for a Variable , if and only if, he value of the variable v is defin. je. » ; 4s defined in the statement Corresponding to that node. It's |as DEF (v, n) where v i a? Is tl rf in which v is defined, he variable and n is the node corresponds © n graph is a usa, ; ie node for a vari ‘used in the statement cor variable v, “v’is the variable and ‘n’ aye if and only if, the value" Sponding to that node. It is represented ® inthe node corresponding to the siate™ ding to node ‘yj io (denoted as P-use), if and only ih (denoted as Cane SMe statement otherwise USE (.1%*Structural Testing 175 jy) Definition use Path (0 definition - pa) (denoted as du. jodes ‘m’ and ‘n’ where *m’ is . ae nope "0" (denoted as DEF (y, the intial node in he path but the Dene for variable “v’ (denoted as USE (1, n)) ‘n’is the final node in the path but usage node Definition clear path 2 ‘A definition clear path (denoted as de ‘ ia 8 de-path) for a varia i with initial and final nodes DEF (v, m) and Rasa pe sm seston aa path path isa defining node of variable “y’ )n) such that no other node in the ath) for a variable * ww) se du-paths and de-paths describe the flow of is where values are def across program statements from S] e-path fc ‘v' between initial node (DI USE (v, n)). A de-path for a variable “v’ will not Sean demutpcabe gen initial node (DEF (0, m)) and final node (USE (v, n). 7 Siistreipotel , n)). The du-paths that a ear paths are potential troublesome pa n)), paths that are not definition clear patl lesome paths. They shi e ides topmost POAT ¥y should be identified and tested on 4.2.3 identification of du and dc Paths sre various steps for the identification of du and de paths are given as Draw the program graph of the program. Find all variables of the program and prepare a table for define / use status of all variables using the following format: Varlable(s) Defined at node Gi) Generate all du-paths from define/use variable table of step (i) using the following format: ‘du-path(begin, end) (iv) Identify those du-paths which are not de-paths. 424 Testing Strategies Using du-Paths We want to generate test cases which trace every definition to each of its use and every use 'S ttced to each ofits definition, Some of the testing strategies wre given as: @) Test all du-paths All du-paths generated for all variables are tested. This is the strongest data flow testing) strategy covering all possible du-path:176 Software Testing ai) Gi) Y use of ble to Test all uses Find at least one path from every definition of every variable to ever, variable which can be reached by that definition. For every use of a variable, there is a path from the definition of that varia use of that variable. Test all definitions Find paths from every definition of every variable to at least one use of that variab| we may choose any strategy for testing. As we go from ‘test all du-paths’ (no, “test all definitions’ (no.(iii)), the number of paths are reduced. However, it test all du-paths (no. (i)) and give priority to those du-paths which are not ¢ clear paths. The first requires that each definition reaches all possible uses throu; possible du-paths, the second requires that each definition reaches all pos: and the third requires that each definition reaches at least one use.4.4 MUTATION TESTING to assess the effectiveness ofa test suite. We may have a id We neither have time nor resources to execute all of any testing technique and prepare a test suite, ices i ted test Suite? Is this test suite adequate for the pro, doy, m fail, there may be one of the following wa Itis a popular technique of test cases for any program. | may select a few test cases using assess the effectiveness of a select the test suite is not able to make the progral (i) The test suite is effective but hardly any errors are there in the program, How wil} ateg suite detect errors when they are not there? (ii) The test suite is not effective and could not find any errors. Although there ma; errors, they could not be detected due to poor selection of test suite. How will enon OTS be detected when the test suite is not effective? In both the cases, we are not able to find errors, but the reasons are different. In the § case, the program quality is good and the test suite is effective and in the second cas program quality is not that good and the test suite is also not that effective. When the test is not able to detect errors, how do we know whether the test suite is not effective program ee es 74 pee assessing the effectiveness and quality of a test suite is\e ee aa ee i bee us to assess the effectiveness of a test suite and maya enhance 4 lequate for a program. 4.4.1 Mutation and Mutants The process of changis changing a 5 ‘wo or very few changes in oe is known as mutation. This change may be Limited ‘4 change in a statement of the a a We prepare a copy of the program under testa gram. This changed version of the program is knownStructural Testing 213 mutant of the original program. The behaviour of the mutant may be different from the original n due to the introduction of a change. However, the original program and mutant are syntactically correct and should compile correctly, To mutate a program means to change @ |. We generally make only one or two changes in order to assess the effectiveness of the selected test suite. We may make many mutants of a program by making small changes in the program. Every mutant will have a different change in a program. Consider a program to find the largest amongst three numbers as given in Figure 3.11 and its two mutants are gi in Figure 4.7 and Figure 4.8. Every change of a program may give a different output as ‘compared to the original program. Many changes can be made in the program given in Figure 3.11 till it is syntactic correct. Mutant M, is obtained by replacing the operator ‘>’ of line number 1 by the operator *. Mutant M, is obtained by changing the operator ‘>’ of line number 20 to operator *< These changes are simple changes. Only one change has been made in the original program to ‘obtain mutant M, and mutant M,.