ye testing is an important discipline, and consumes significant, amount of effort. A strategy is required to carry out testing activities systematically and effectively. Thus, strates provides a framework or set of activities, which are essential for the success of ject. This may include planning, designing of test cases, execution of program with test interpretation of the outcome and finally collection and management of data. Aswe all know, software testing is the process of testing the software product. Effective se testing will contribute to the delivery of higher quality software products, more satisfied Jover maintenance costs, more accurate, and reliable results. However, ineffective testing kad to the opposite results; low quality products, unhappy users, increased maintenance ss unreliable and inaccurate results. Hence, software testing is necessary and important of software development process. It is a very expensive process and consumes one- to one-half of the cost of a typical development project. It is partly intuitive but largely matic. Good testing involves much more than just running the program a few times to see aber it works. Thorough analysis of a program helps us to test more systematically and effectively. testing is a specialised discipline requiring unique skills. Software testing should not intuitive as for as possible and we must learn how to do it systematically. Naive managers ly think that any developer can test software. Some may feel that if we can program, “we can test. What is great in it [TAMR03]? This may not be the right way of thinking. Software is everywhere. However, it is written by people-so it is not perfect. We have “Many software failures like Intel Pentium Floating Point Division bug of 1994, NASA. “Polar Lander of 1999, Patriot Missile Defense system of 1991, Y2K Problem ete. (PATTO1]. *Y People understand many definitions of testing. Few of them are given below: 1. Testing is the process of demonstrating that errors are not present. i - The purpose of testing is to show that a program performs its intended functions correetly. 5. Testing is the process of establishing confide: Posed to do. nee that a program does what it is sup- 365sible to test the eofvare fra pay rn e released by its c raheoasile Peng ere oer ead ey rate Feo ee reat nt’ tthe point hence that it was totaly erro coos significantly outweigh the nt ‘rit is considered thatthe costa , lence, when to release the soft- is describe almost the OPPOSite of whay, ‘These definitions are neers Fyne moment, consider that when wey be viewed as. Forgetting the 1m. Adding value means rain,” ar, we want to 244 S08 72% ability of the Program means Finding hy progr: ; or reliability ofthe program. tnepgram to show that it WOTkS; rather we pee 's errors and then test the prov esti P ie askel 188 VOT important dei, a ‘ha errors. Hence, we should rm ‘ rth the aasurnpton that the rogram Gore appropriate definition is; = gnould do the Testing? the errors as sith the intent of fin m levelopers in¢ sanyo ater « enetingaprogram with Ue intent f Finding em, ng eaute the BevIOPES to nd errs fn hist i sting i te Pro wnally goal oriented. Thus, establishing the proper». Meveloper 0 point out errors from own creations, Bene [Bios ee per Pelpal effet I our gale to demonstrate that a Program, haere pe civ won he states Ten isaesthtat neverratpers elaine is logical iI; that is , we will tend to select th A rep no bugs tocatch. Ifonly we could really eoncene a ming, ‘we shall subconsciously steer towards this goals 108 ing vould wn de d rate, ifeveryone used structured program to fail, On the other hand, i * fop-down design, decision tables, if prograne ae Ihave a Tow probability of causing the Prot ane fou ply cee er bullets, then there weld be nob ee 0 goes the myth, There are bugs, the pia because we are bad at what we do; and if we are bad ati, we should feel pally so herefore, testing and test design amount to an admission of falure, which inctils & Mose of guilt. And the tedium of testing is just punishment for our errors. Punishment Alig For being human? Guilt for what? For not achieving ichuman perfection? For not ing between what another developer thinks and what he says? For not being bie For not solving human communication problems that have been kicked around by xs and theologians for 40 centuries?” ont i program has errors, our inputs selection will have a higher pray aoe ae reed approach will ad more value tothe program than te Than leating cannot show the absence of errors, it can only show that errors aye (DAHL72}, “According to most appropriate definition, there isa fundamental entity “eros sey within the software under test”. This cannot be the aim of software designers. They muy designed the software with the aim of producing it with zero errors. Therefore, whel ef software engineering activities is to design methods and tools to elimi Software testing is becoming increasingly important in the earlier part of the totmni] Many organisations have made a distinction between development and testing phase by cycle, aiming to discover errors before they are deeply embedded within systems. issipizg different people responsible for each phase. This has an additional advantage. Faced hoped that one-day software engineering will become refined to the degree that softwar pitt opportunity of testing someone else's software, out professional pride will demand {ng will be fully integrated within each phase of software life eycle. After all, engineenicfteachieve success. Success in testing is finding errors. We will therefore strive to reveal ing bridges do not need to test their products to destruction to predict the breaking ysiftmrs present in the software, In other words, our ego would have been hamessed to the their constructs, For the moment, n software, this isthe only practical method opr 8 PREe, in very positive way, ina way, which would be sirtull impossible, were we Tn software testing we are facing a major dilemma, On the one hand we wish aletf%89%r own software [NORMB9]. Therefore, most ofthe times, testing persons are difer- the software product that has zero aa while ‘on the other hand we must remain freee," developinent persons for the overall benefit of the systems. Developers provide guide- belief that any software product under testing certainly has errors, which need tobe during testing, however, whole responsibility is owned by testing persons 8.1.2 Why should we Test? Although software testing is itself an expensive activity, yet launching of software Mf ce : pecially 8 hye here human safety is involved. No one would think of ‘allowing automatic pilot sok 2 nS are 2% x 28. If only one second is reaui han two and size is also more test all combinations. Practically, inputs are more Ti cas are possible. ea W@have also not considered invalid inputs a oa alt esting i just not psi alin gram path ean ocd et dimension is to execute all possible paths 1m termination. Two paths lower is orn topo 4, the lowers the cost of their removal The most danas) Bry q™URh the code from the start fe PO sesame statements vered during the testing process and therefore #8! Yo ge RTA executes different statemen's 9 OOF as exlaned tis problem tis oRten difficult to estimate the c0st® ied] Haeinpte 6 O7der- A. program may have a pp and few IF statements as shown coulivd 84, "Pe example (MYER79] where be 0 In most systems, however, it is the x ing fone eg ntms: however, it is the cost factor, which plays a major role. AGriving force and the limiting factor as well. In the software ie aia is ‘earlier theminutés are required to test one ‘The number of paths in the exam” ‘number of paths through the loop fom BeBe cee ates Eo “of Fig, 8.1. are 10" or 100 trillions, 1, very path vat keto highlight is that complete oF eXRAU Ve ey ‘The point which we not possible. Exhaustive testing rea and we may have to settle for somet in the program and res every statement . Sour atjective it not possible pet eobiaton ob exerted test ce, Soo ss et te Fa. 8: Cott ow raph VERO] Section? Section It ___ Weimay like to test those areas where probability of getting a faut is oxime (Before execution) (Aer exrentin) critical and sensitive areas are not eaay to identify. Organizations should devel stm] | aveaton Hit and policies for choosing effective testing techniques rather than leaving this ! : Judgements of the development team, Po Pre condition: (If any) Revolt ‘A strategy should develop test cases forthe testing of small portion of program Tapats: eal, any poe rent Option Aevelop tes eats fr conplterystom ora parteuse Pee =a ay te bern Post conditions: | _ Any sugrestion: ___} "82 SOME TERMINOLOGIES (aan ‘Some terminologies are confusing and used int books I ate: of Electronica and Electrical Engrocssy reg aterehangeably in Jiterature and | Pee xximately one billion years . A good synonym is mistake, ‘This may be "Bam, thre ae een gest rr indenting these mistakes “bugs”, Errors propogate ‘elopers make mistakes while rement errr may be magnitind during donee 6th with higher may Tend t one or more faut. Iis mee preteen ae ale Miation of an error, where representation isthe mode af expression, such as narrative gow diagrams, ER diagrams, source ede ete. Defect ‘g00d synonym for fault. If a vce cae, we call ita bug, ym for fa a alure occurs when a fault executes, Iie the output. Hence failure is dynamic. The id may ead to many failures. A par Hag on how it has been exercised. departure ofthe output of program from rogram has to execute for a failure to icular fault may cause different failures, |,test, Test Case and Test Suite sed Test case terms are used interchangeably. In practice, both are same and are treated Test case describes an input description and an expected output description. ae of two types: pre conditions (circumstances that hold prior to tet case execution) actual inputs that are identified by some testing methods. Expected outputs are also of sje post conditions and actual outputs. Every testcase will have an identification. During testing, we set necessary preconditions, give required inputs to program, and av the observed output with expected output to know the outcome of a test case. If ced and observed outputs are different, then, there is a failure and it must be recorded iyinorder to identify the cause of failure. If both are same, then, there is no failure and Pa behaved in the expected manner. A good tet ease hasa high probability of finding an Te testcase desigmer’s main objective is to identity good test cases. The template for a test case is given in Fig. 8.2 ig. 02: Test cas oveTet capnarevalate and actu east aoa 2220556 Thay a) developed, reviewed, used, managed, and S#°°- nave a teat suite of a ‘The set of test cases is called a test su We may have a test suite of efTectivelgood test case®. Hence any combination ey nay have a lst rarer eee ee tats are conducted in a centlle many gene : . Alpha testing maybe are when onal esting pen a ee 8.2.3 Verification and Validation eat oui tests are conducted by the customersiend users at their siee Wen ony led by the developer. Customers are erm oceiving such failure reports, devela Ve product for final release, ‘of the companies are following this practice firstly, they c eter few months Many potest cstmers wil ar ae ete at of es about the product. Some may encounter with failure situations and may report to pany. Hence, company gets the feedback of many potential customers. The best part is ihe reputation of the company is not at stake even if many failure situations are pected to report failures, if any, to the qehsidon of th hee whch are sig al tein, bra trem valid ee "pers modify the code and fix the bug and Seoul Yin ayn iene ‘Verification: As per IEEE/ANSI, “it isthe process of evaluating a system nent to determine whether the products ofa given development phase satisty the caag Fimposed ot the start ofthat phase”. Hence verification activities are applied to carly had SDLC such as requirements, design, planning etc. We check or review the documents ated after the completion of every phase in order to ensure that what comes out of hag fn what we expected to get Validation: As per IEEE/ANS, “itis the process of evaluating a system or comp during or at the end of development process to determine whether it satisfies the sug requirements.” Therefore, validation requires actual execution of the program and is also ‘as computer based testing. We experience failures and identify the causes of the failure Hence, testing includes both verification and validation. ‘Testing = Verification + Validation. Both are important and complementary to each other. Varification minimises the and their impact in the early phases of development. If we find more errors before (ue ta verification of the program), validation may be comparatively easy. Unfors testing is primarily validation oriented, 8.2.4 Alpha, Beta and Acceptance Testing os hich involves only observation of the output for certain input values ‘There is = to analyse the code, which produces the output. We ignore the internal structure o Ttis not possible to predict the every usage of the software bs ro 3 the customer. Custone*®™ ide Thar a oettg as ack box testing in which contents ith strange inputs, combination of inputs and so many ather things. Some out! “PS poe i uetional testing i les ert i nderstod completely in ny clear from the developer's perspective, but customer may not understand and fos Puts and outputs as shown in Fig. 83. Here, we are interested in functionality a rc aperate more effectively with black eternal structure of the code. Many tie We a se leowleige, FO example, most people successfully opera sessed earlier, complete testing is not at all posible Thus, we may like to reduce this eness as much as possible. Probably the poorest methodology is random input test- rmndom input testing, some subset of all input values are selected randomly. In terms ibility of detecting errors, a randomly selected collection of test cases has litle chance sm optimal, or close to optimal, subset. What we are looking for isa set of thought that allow us to sclect a set of data more intelligently. One way to examine this issue is to explore a strategy where testing is based on the salty of the program and is known as funetional testing. Thus, functional testing refers Acceptance testing ouput domain Input domain upatast Input test ‘3 ata sn: Blak om st This term is used when the software is devel . tte conducted to enable the customer to validate oat Fei customer. A srt od alidate all requirement 5 ‘user/eustomer and may rang ments, These tests 8 feats Accptanes tectng = te cea adhoc tests to well planned system will be fixed and better quality software wil fe Sarge mate "The diseo™ customer. Fig.ses or techniques that can be used to dos il are rarely the res s at that failures Ane result ofthe simuttan sorcessful in detecting errors. te, cous jary value analysis testcase, jr nominal values are obtain var their nominal values and letting that vannnet © ‘There are a number of (ccurrence of two (or m which have been found to be very ce of two (or more) holding the values ofall but 2.3.1 Boundary Value Analysis « Eaperience shows tha test cases that are cose to boundary conditions have a high ractecting an error. Here boundary condition means, an input value may be on the just below the boundary (upper side) or just above the boundary (lower side) gy hhave an input variable x with a range from 1-100. The boundary values are 1, 2, an ‘Consider a program with two input variables x and y. These input variables ha, 4 fied boundaries 1 ‘program for the determination of the nature of rots ofa et Fee of positive integers (sy o, 8c) and values maybe es nn aan es czysd ‘tput may have one of the following words: erent 200). Tes Hence both the inputs x and, are bounded by two intervals [a,b] and c,d] resp (Not & quadratic equation; Real roots; Imaginary roots; For input x, we may design test cases with values a and b, just above a and also just ban a the boundary value test cases. eee Similarly for input, we may have values c andd, just above c and also just below d. Then ‘cases will have more chances to detect an error [JORGSS]. The input domain for our is shown in Fig. 84. Any point within the inner rectangle is a legitimat asssb equation will be of type: at +br+e=0 roeoman (ee Roots are real if (62 — dac) > 0 ‘ Boots are imaginary if (6? — 4ac) <0 t 4 nts are equal if (b? ~ ac) f Equation is not quadratic if @ ir The boundary value test cases are: Test case | a 2 = Eipeced apa pag tn mH fe a Be ae] ti Fi 4 pu corn program navn wo input vribles e. G eo a Be trum joe a ea of boundary valu analysis sto use input variable values att 3 50 30 30 _ | tmainary Roots “tahoe minimum, a nominal valu, just below their maximum, and at i a % ay 30 | Tmaginary Rats ° ‘assumption of reliability theory known as “single fault” #3 t om mo 30 Imaginary Roots a a 7 Go| maginary Rent : - : zo | masinary Roots Go] manny Rots 8 50 oe | 8 ee ia ual ° 30 ce ee 10 30 o | 7 50 [Real Roots n o o tains Roots 0 50 50} mana Rote 8 50 wo |Example 82 jou date. snp 8 te doy, Consider a program for determining the 2 =a year with the values in the range ~ Especed 1 month $12 Tsosceles 1edays31 - 2 Taonees 5 2025 f 50 50 se re Previous date or invalid input date, Design the fs _| 0 Equator Le Wee Co Ly * Taosaes Easton : on 3 Ee Terai dle program aks date asap and chs fr waliy vai ey | 50 1 0 ae the previous date as its output. 50 2 0 Toone ‘Ase know, with single ft assumption theory, dn +1 tes eases canbe design gi] [7 which are equal to 13, The boundary valu test eases are: je 0 0 a Tse Tecan [Month Day Yeor Expected output 2 50 100 30 Nota tangle 1 ¢ 5 1900 14 June, 1800 1 50 30 Tuscan 2 6 15 1901 14 June, 1901 | 2 50 0 Taccees 3 6 6 1062 14 June, 1862 | 99 30 50 Teceees ‘ s 15 2024 14 June, 2024 3 100 20 0 Nota tangle s 6 6 2026 14 June, 2005 6 6 1 1962 31 May, 1062 ad 7 = sting but the extension of boundary valve analysis, Here, we would ike fo ee, what s 2 aes ce) when the extreme values are exceeded with a value slightly greater than the maxi- 8 6 ® 1962 29 June, 1962 tod avalue slightly less than minimum. It means, we want to go outside the legitimate 2 6 aL 1962, Tnvalid date Te inut domain, This type of testing is guite common i i Se se rm of boundary value analysis sealed robustness testin 10 1 7 aa Ti Jenuany 106] fathtlended form of boundary value analy 2 6 1962 14 Febronry, 1952 7 a 1 1962 14 November, 1982 2 2 + fi om «0 an yw ang (10, 201 #800 Fla. 86: Robustness test cases for mo varabetside the legitimate jn ‘There ar our ain test eles WT ren the number ong 3 variable i There are four non eoingare6¥* ‘input a put cases total numberof test So, 13 test cases are: | pS] 200, 99, 200, 100), (200, 101), (200, 200), (200, 290), (200, 309), eee bees Ea ae oe 200) (100, 200), (101, 200) (288, 200 (800, 200, 30 = nee , 1 2 SI Told pat Worst-case testing r £0 | Sot quadratic uation ; 5 ability and may lke to 1 00 Itwe reject “single faut” assumption theory of relibiity and may lke to see what hy ies | Rea Iw oe ig at sami en en tre coats wane es] ES] a» 7 os when ore he one tte more thorough inthe sense that boundary value yy ett] | *—— Tnaginay rt fre a proper subset of worst case test cases. It requires more effort. Worst case te es = LJ] 50. Imaginary roots ae er hies ponerates 5 test eases a opposed 10 An +1 test case for nest] | 100 ia oe sane syns Our ove variable example will have 6 = 25 test cases and are gel], a a inary rte Table 8.1, my 4 a 50 | tovalid input ‘hole 4: Wort case est hp ar Wo vata nar 3 50 =1 50 | ova input 30 ° 50__| Imaginary rte Tetease Tuts Test cove Taputs $ tnacnary munter_ [oe z umber 10 G z 0 | trainer eos = 7 z 100 100 “4 200 2 a i ad 0_| tsaginary rots 3 oa a a aaa = 2 50 10 50 | Equal rs 2 ia aoa 6 ooo 5 a 50 101 50 | Tova input 4 i aa 7 aaa = u 20 0 =a | taal input 5 100 700 a oe om] | Le 80 30 o | Realrots 5 tot 100 7 7) a 16 50 50 1 _| Real rats 7 101 101 20 a 0 30 30 3 asian roe D uu 200 2 300 100 50. 50 100 _|_tmaginary roots 2 D ior r a a ai mn a cor | eva inp 10 rated in 7 ; E 300 23 300 200 We Worst teat cane total teat cases are 6 Hence, 125 test cases will be generat d 2 “0 a 2 300 29 Hist cases.‘The worst test cases are given below: 2 200) 101 2 00 300 [Ree] oe Expected output a 200 — r , i | Net ade 5 oo ° oe : So nati ° ee ; S| ee gun Example 8.4 : ° ae fe une Consider the program forthe determination of so e : 9} J wat aiete __] nature of roots of a quadratic My MMe |e | tL ‘Contd lained in Example 8.1, Des om le 81: Design the Robust tet, ‘cases and worst test cases for thit pea i Wa — —— a= 1 5 ° Not quadratic aa me 5; 5 8 o Not quadratic a of ; Rares 4 et unt = 10 s Not quadratic — ot alot i Net ona a f{_o_}_= —— Ralro s 7 0 qu - Real roots: * Net eda af 6 =a Reale Net dati 75 5 0 = Real rots Net una 16 o 9 : Real recta Net ued 7 0 9 s Real roots yi | eo 1 Net qundaie me 21 Net queda fae 2a __& et unate = tot Net aati —— taeda E o Not Imaginary Ht Net quad Toate ape Na ud Tans 25 o Not quadratic Real roots wa 2 lot Tea [4 o Tasinny 1 23 1 o Imaginary Imaginary = [4 0 Ieee Tea = [+f Tnasinary al a io sear Teal ts at [imine | 2 4 1 Imaginary Imaginary 33 Tinasieary | Z 1 Imaginary Imaginary % a + : Imaginary Imaginary 1 + Imaginary ‘Real root 2 1 “ | Rest eos__— (Contd).50. r 100 a | imagine fe. se" | 3007 | = veces | ~e—Leseee imaginary fm | = so : 100 | op 0 moeney, 5 nary Teal rote ual rsa 0 5 ; aa Real roots iaginary Equal roots ° Tmaginary = Tmaginar o Imaginary 2 F = ° Imaginary = ee 1 Real roota 99 o Equal roots 1 = 9 ° Imaginary 7 — 38 Q Tmaginary fi — % ° Imaginary 7 —— 8 ° Imaginary a tateas 8 i Real roots 30 eal cts By r Imaginary 70 inssiaay 99 3 Imaginary 50. Imaginary * 1 Imaginary 50 Teasinary 99 1 Imaginary © Real ots Ral ta 99 50 Real Roots 99 Toasinay * 20 Real roote %0 a = Toaginary 50 Imaginary Tmaginary so 50 Imaginary 99 I "Real roots O 50 Imaginary ee eat te [oe Teal ret [ee | 9 yo | 8 Real roots 100} 00 ~ Imaginary = = Imaginary rots {100 | 100 imaginary _ os [0] , Jnoginary eae Jendar as explained in 99 9 wus date ina cal Tmagina the of previo _ 9 100 een Ag Pram for the determination of PEN progra Real roots "sign the robust and worst testsas oF °f e si 383 & Month Dey, Year are desi, 2 Expected Se enannetestemies vacate, eS below: ra 3 ag | 2 oar 1 January, 2024 oe Bspected output 7 a was 1 Janay, a5 . . 1699 Invalid date (ouside ran r 15 Foo A aun, 100 : ‘ = 7000 14 une, 1900 i , a wou 1 Janary, 1901 5 5 © 7901 14 June, 1907 Sas a 14 January, 1962 j 5 : 7 7962 14 Tune, 1962 i 5 is = sn, 224 a ¢ 6 2024 14 June, 2026 i : a a 24 Sey, 8 6 6 15 2025 114 June, 2025, w : 30 = = = a 7 ee Tn i omg i: 30 | ee] a é 0 1962 Tnvalid date E 7 0 aa aaa > 5 7 1962 + 1 30 2025 29 January, 085 7 é 2 1962 f ri a 1900 30 January, 100 a é 30 1962 4 1 aL 1s01 30 January, 1201 2 é a 1962 a 1 aL 1962 30 January, 1982 2 6 2 1962 Tavali date i 1 a1 2024 30 January, 024 M oO 15 1962 Invalid date 5 1 aL 2025 30 January, 2025, 6 T i 1962 14 January, 1862 # 2 r 1900 1 danny, 100 16 2 15 1962 14 February, 1962 Zt 2 1 1901 31 January, 1901 Ww uu 15 1962 ‘14 November, 1962 2 2 1 1962 31 January, 1962 18 12 6 1962 ‘14 December, 1962 a 2 1 2024 ‘31 January, 2024 18 18 5 1962, Tnvalid date = 2 1 2025 31 January, 2085 : + a 2 2 1900 1 February, 1900 setow ‘Worst test cases are 6" and n is 3. Hence 125 test cases are generated and af? 2 ; ; = = Febroary, 1901 ine February 1982 [- teatense | atenth [bey] Year Expected output > fl 2024 1 Febrary, 2024 ; 2 1 1900, ‘1 December, 1899) s 2 A 2025 1 February, = Sa cs Ls \ sat irene Lr 5 1 t 2025 TH December, 2024 ee ee 6 1 2 ira a Oe ee ee = a 1801 Tena, 1901 or a ot So ae ee (Contd erSofware em [Beta oa 2 ® 1062 Tava date a 2 2 2028 Thali date 5 2 aoa Invalid date 6 2 a 1900 Invalid date a 2 a 1901 Trvalid date 8 z al 1962 Tavalid date ® 2 a 2024 Tnvalid date 30 2 a 2025 Tavalid date a é i 1900 31 May, 1000 2 € 1 1901 31 May, 1901 a 6 1 1962 31 May, 1962 # 6 1 2024 31 May, 2026 5 6 1 2025 31 May, 2095 6 6 2 1900 1 June, 1900 Cl 6 2 1901 1 June, 1901 8 6 2 1962 Tune, 1962 oy é 2 2004 Tune, 2024 0 6 2 | 2008 1 hune, 2025 = fs 36 1900) 14 June, 1990 - ie 15 1901 M4 June, 1901 ° 6 1 1962 1 June, 1962 = = ae 2028 14 June, 2024 . a 2025; 14 June, 2025 ¢ oD 30 [1800 29 Jun, 1900 a s o 1801 29 Jane, 1901 “ fe 30 1962 29 June, 1952 7 ; + 2024 29 June, 2024 fi i so 2028 29 June, 202 fF 7 a 1800 Tavalid date e ¢ a 3901 Tavalid date fa + 3 982 Invalid date | i s at 2024 Invalid date = if = 2025 Tava date 1800 31 October, 1900 Ey noe 1962 31 October, 1962 jth [Day | ya — - Pe 7 1 [agg 2 Oa 2028 | ft |e 999 te 28 | [| aco ees sor) a |e 1962 1 November, 1901 4 Be 3 2024 1 November, 1962 fee g a nm 2 i 5 i ra a 4 November, 1900 @ rT ny = Nove 101 5 14 November, 1962 @ n 15 2024 16 November, 2024 fi m — 1H November, 2095 a a fa Ea te 2 a = aay 29 November, 1901 4 f + a 29 November, 1962 eZ u 0 2024 29 November, 2024 s a 30 2025; 29 November, 205 * un Ls 1000, Invalid date ; x a 1801 inal date 5 Be 3 1962 Tavald date am u 31 2004 Tova ate 7 a an 2025 Tavalid date ie a 1 1800 3 Novenber, 1800 = 12 1 1901 30 November, 1901 a 12 1 1962 "30 November, 1962 ie 12 1 2024 ‘30 Novernber, 2024 . 12 1 2025 "30 Novernber, 2025 aa 2 1900, 1 December, 1900, i 1 2 1901 ‘1 December, 1901 i 7 1962 1 December, 1962 . fe - 2024 ‘1 December, 2024 ly —12 fet 288 pe | ee ee te es 9 a it 2 « | ‘Gon ——Sotware a est ene aro 125 and SF ven baloy; oa Expected output ae y “Test case | Month = sass) 14 December, 2025 z 2 z us ee j—z000 | 29 December, 1900, : i is 2 30 $5 Decent ioe 1 ; Bs ee ee = 7 30 2025; 29 December, 2025 ; c i 100 123 12 3 1962, '30 December, 1962 i 1 2 50 124 12 a 2026 30 December, 2024 = 1 2 % 125 12 31 2005 30 December, 2025 i 1 2 100 1 50) 1 Example 86 1 Consider the triangle problem as given in Example 8.3. Generate robust and worst test cag 2 1 50 2 for this problem. a 7 i aa Solution a ; fa 5 Robust tat cases are: 2 : a a Test case = y z Espected output 6 1 9 1 1 0 80 ° Tnvalid input 1 1 99 2 2 50 50 1 Those no 1 99 30 7 0 50, 2 Tsoaceles is 1 9 ” . Q 80 50 Equilateral a 1 99 100 u = 50 99 Toscelen a 1 ja fi S E} 50 100 Not a triangle a 1 100 2 Nota tranale 7 Ey 50 101 Tnvalid input m 1 100 50. ‘Not a triangle 8 es ° 50 Tnvalid input a 1 00 9 ‘Nota triangle A = 1 50 Tsosceles ee 1 100 100 Teoscees eS 50 Trosceles ~ 2 7 1 Nota trianale a 50 9 50 Tsosceles 2 3 fi 2 Teoseles ‘eh £0 Tnvalid input 2 aa Nota trianale ae ° 50 a 2 1 ie a Invalid inpot spo Nota trance a : = a au 7 3 Toosceles 17 ~ 0 7 cai x i ; asian 18 100) 30 2 soaceles es soxassage 19 101 ee + 80 | Tavatid input | 2 (Contd).[se - — Ea] 368 oa oS 5 5 Bepeted apap | | | a Tascam z y i Nota triangle [os | oe a 3 fa 1 wet A tangle 0 100 Ai Not a triangle 5 i 50 2 fot triangle a 7 ~ Note triangle z 2 = 7m Tsosceles A S 2 2 Nota tangle a 0 Not a triangle Fe Selene 39 2 50 100 100 | ; I 100 ‘Nota triangle 4 Teves 90 1 Z : a ; in 1 Not a tangle 7 1 Not gl fal A 9 2 Not a triangle Tt we 7 2 [Nota triangle fa 5 9. 50. [Not a triangle 8 ss 50 [Not a triangle “ a 99 99 Tsosceles 9 99 e 99 Tsoseeles 6 2 99 100 Sealene o 99 1 100 Nota triangle 6 2 100 1 Not a triangle a 99 2 1 Not a triangle a 2 100 2 Not a triangle a 99 2 2 Nota tase 48 a 100 50 ‘Not a triangle 8 99 2 50 Not a triangle ry 2 100 39 Sexlene i 99 2 8 Tose 0 2 100 0 Taoscelen 5 99 2 100 Salene su 0 1 1 Not a triangle 6 °8 20 A Not tinge 2 ry r 2 Not a triangle a 99 50 2 Not triangle 8 0 1 30 Teeecsies 99 50 30 Tose 34 50 1 29 Not a triangle n 29 30 0 tases 55. 50. 1 100 Not a triangle % 99 50 100 Sealene 56 0 2 F Nota triangle 1 e 0 1 Toss oT 50, 2 2 Not a triangle 2 99 99 2 Teosceles 58 50 2 50 Tsosceles oy 99 99 50 Isosceles 59 50 2 9 Not a triangle 4 38 ry 99 | __Eauilateral i 50 2 100 Not a triangle 85 is a 100 Teosceles (at 50 50 1 Teosceles % aa 0 1 ‘Not a triangle = sa. 60. 2 Taoscclen S | Ssaleee s 8 50 0 % = ioe Sf seas | aa a ry 2 Equilateral ST 9 [100 [| — es 50 50 100 Heseociet i yy] 22 | 100 | [tects 6. 50 99 1 ma ; ‘ae 5 toy —22_|_100 +" Jota triangle ol 0 9 ; taint ig —}—100_ | Nota rine «8 50 r = Not a trang iy — | 100 | Note rin 69 50 ry = peceelese Ree Nota triangle Soe Tooocleas g [100]‘Sofware Ena poth valid and invalid in 381 7, both v' 'put domains, = sx Expected outpar — ‘are shown, ae 2 TI Tssociaa inva input i . 7 2 Not a triangle |p ua 128 . 70 Not a triangle — | Scalene i 109 100, 2 99 e —— a 7 a 300 Tsosceles Coad a 200 wo TNot a triangle seit Fate eg 12 100 50 2 Not a triangle den is to choose at least one element from each equivalen valent ee eT Bet ceri havoc sa oe ue 100 50 99 Scalene postr te caSS- we doth ee mould ot expect to lean much om et cases such a 7 0 700 Teosceles vo, 40) and ( ete ae = oe may be treated a2 redundant test cases. = Heston ct ave equivalent classes for invalid inputs. Tis is oRten wf opts 1 [Baise We sin Puhould et ferent peso invalid inp in rd et uses 8 ol nal — for a program that is supposed to accept any number between 1 and 99, there are 50 Sealene Fat ur equivalence classes from input side. The classes are: ne 100. %0 20 Thosceles i Any number between 1 and 99 is valid input. 120 100 99 100 Isosceles i Any number less than 1. This include 0 and all negative numbers. ab 100. 100 1 Isosceles (i Any number greater than 99. 122 100 100 2 Taosceles 123, 100 100 50 Isosceles ‘Most of the time, equivalence class testing defines classes of the input domain. However, 124 100 100 99 Isosceles ‘classes should also be defined for output domain. Hence, we should design equiva- 125 100 100 100 Teast classes based on input and output domains. 87 i Eqialnce ies Test ie the program for the determination of nature of roots of a quadratic equation a6 ao smatbed pat domain ofa program is partitioned into a finite number of equtaex] tin Example 8,1. Identify the equivalence cass testcaseS for output and input domains. clases such that one can reasonably astume, but not be absolutely sure, that he presentative value ofeach class is equivalent to atest of one in equi ne eee ee ss valent to a test of any other value. That i, fone Output domain equivalence class test ‘cases can be identified as foll na class detects an error, all ather test cases inthe class would be expected to find i ifa=0) error. Conversely, if a test case did not detect an error, 0 other 0, = (: Not a quadratic equation Bhat ce + Real roots if @?~ 4ae)> 0! cases in the class would find an error. Two quired in implementing this 0, = : Imaginary roots rf error. Two steps are required lementing this Naeee o ~ a 1. The equivalence classes are identi " von ad : zqual roots if “ts — = aulvaence class are identified by taking each input conditi ‘| °, ns a qual roots if ( a 1, = (ea, bye >: i ‘and shown For example, if an input condition {one valid equivalence elaa [1 <0 Te number item <1 and {item > 999} “a uivalence classes identified in the Pres 1es can be derived from above Fe ‘of test cas ee Expected output i 50 range of values rom 1-98, we dot and two invalid equivalence danse 2. Generate the tes eases us Ge cases using the ey3a Bu based on input domain. ‘We may have another set of test cases I= (a:a=0) I= la:a<0} 1=la: 1505100) 1,=|(a:0 > 100) I, = (6:06 5100) T= (6:5 <0) T= (b:b > 100) I,= le:0 Se 100) I,=le:e<0} Ip le:e > 1001 In these classes, our basic assumption is single fault theory. Hence one value is ‘extreme and other values are nominal values. Input domain test cases are: 7 Gay have another se of Lat case which are ‘ 1, = tmonth: 1 12) Pe Iy= lday: 1531) 1,=(day:D< 1} I,= (day: D> 31) 1, = (year: 1900 s¥ < 2025) < 1900} 1 = (year: Y > 2025) Test ease 2 z e aa ; seen z = 30 80 Tavalid input To D ¥ Bipeaed op 2 @ 3 0 Tmaginary roots 1 6 15 162 | dune, 1862 7 ToL o 30 Tavald Fepat 2 = 5 1962 | Invalid inpat e a 50 50 Imaginary roots 3 13 15 1962, Invalid input 6 0 = 30 Tavalid input ‘ 6 6 1962 [1 dane, 1982 7 30 Tor 0 Tavalid input $ 6 = 1962 | oval input - 2 50 50) Tmaginary roots 6 6 a 1962 Tnvalid input 8 GS 50 = Tavalid input a 6 ry 1962, Mune, 1962 = a) 101 Tavalld input ’ 6 15 1609 | Invalid input ale out of range) input aloe ov of anes) nominal ne cae § and 8 are redundant teat cases If we choose any value okt 8S g 6 15 2026 | Invalid input va mina lundant test cases. Hence total test cases are 10+ 4= M4 a9 _ = (cD, M, Y >: Previous dat ial 0, = (: Invalid dateif any eed inputs) any input makes the date invalid) t entity the equivalence elas fy h* triangle problem specified in example 83. Hdentis tand input domain. ee domain equivalence classes are: '1= (: Equilateral triangle Ove te, 2: Imes nae with ee 2 {ex y, 2 >: Scalene triangle with sides" ste '*, y, 2 >: Not a triangle with sides ™7+derived from input domain are = y zo Expected ouput —~ =o Seay 7 oo Equllateral ajo ft a 0 Teoscelen | __ 80 . 50. Sealene ae. | °°. | wt 100 50 Not a triangle f pe ao 50 30 classes are: B F 50 50 steel) 50 50 y= bex> 100) is : a $0 e125 100) + 60 60 a bey< ll 4 50 30 Ig=b:y> 100) Fi 50 6 I=: 15y 100) 7s 60 50 L <1 1 100 99 T,= lz:2> 100) 5 100 50. I= t:1525 100) 6 100 30 2 Nota tranaie ‘Some input domain test cases can be obtained using the relationship amongst, y anis}_!7 50 100 30 Nota thang Ageless yz oxy eed 8 50 100 25 Nota tranzie Iyelex,y2>:2=y,2¢2) 9 50 50 100 Not a age Tye lcx,y,2>:2=2,2¢y) x 25 50 100 Not a triangle Ty=lex,y2>;y =2,2 49) Iynlexy,2>:2¢y,2¢2,y #2] hich a number of combinations of tables are useful for describing situations in w! Tye lexy,2>:¢=y +21 ee taken under varying sets of conditions. Devson tables have ben se a oS Iyg=ex,y,2>:2>y 42) alse complex logical relationships since carly 1960, We would Me 0 ot 0 A 1, Icx.y2 Dy e242] sat be applied to the testing and how tester may adept the pr Iyslexy2>:y>242) of the basic terms are shown in table 82 Jon ule rs Ty=lexiyerizex ey) leks eee Inslenneneszeyl : ] Bie efnamely, Conditions stub, Action gy. sis ,¢2 and ¢, aFe all tTUC, Actions g 9 {a false, actions a, and a Occur. The joc Timited entry decision tables. 1 cong sting tables are called Extended Entry 1g, ‘There are four portions of ade entries and Action entries. When con: ‘When conditions c, and c, are true and és, in which all entries are binary are lowed to have several values, the res Test case design ‘ interpret condition a np identi with decision tables, we interpret and 7 deny est ae ith deco Ne gta elec lee npg tg ions of the item being tested, The refers jor functional processing portions of i es Teer voted os test cases Because the decision table can mechanically be forced tobe a nave cot of tet eases. There are several techniques har ecision tables that are more useful to testers. One helpful style is to add an action 1 ‘when a rue is logically impossible [JORG9S). si ‘Consider the decision table shown n table 8.3, we see examples of dont care eng, impossible rule usage. | ‘able 83: Deion al fr wang probe 8.10 or oa problem specified in example 8.3, Identify the testcase using the decision functional test cases; three to fil triangle property, three impossible cases; gt equilateral, scalene triangle cases, and three sgt oa nonce ede the ‘Table 8.5: Test cas0s of tangle problem using dain tbe etm tare sides ofa langle? | ¥ (mee T= z a eieey? = ¥ N 7 ¢ T 2 Nota wang eqieez? =| N ¥y 7% 1 4 2 [Nota triangle =|¥|N{ eT NY IN| ¥ 3 1 2 4 Not a triangle e 4 5 5 5 Eguilateral x fz 2 2 o Texposile x x [x a 2 z 2 Impossible e 7 2 2 3 Tsoseles x | x x | 3 2 7 z Tixpossibe Ifthe integers x,y and z do not constitute a triangle, we do not even care about pst 9 2 3 2 Iaoeclea ‘equalities, we may also choose conditions, but this will inerease the size ofthe decison ual» a 5 a 2 Teoaceles shown in table 8.4. Here, old condition (cy: x,y, z are sides of a triangle?) has been expan A 5 ‘Sealene get a more detailed view of the three inequalities of the triangle property. If any one ot 3 4 fails, the three integers do not constitute sides ofa triangle. 811 . “Table 8.4: Modied decision abe mec Poeram for the determination of Previous date, Is input is til of dy, month ‘Conditions with the values in the range euixeys2? Filtirit{r|r}r| |e 1s month $12 severe? [=F [a [rt }rpapaprye 1s day <31 eiecxey? |=[—[F [tyr T 1900 s year s 2025 eases us sy? =|=|-Tr ha out “Previous date’ and “Tavalid date. Design the test oa z Thre abe puts are “Previous sare etter ate ~ | S1=l=|t TF Prepay Fag Setar 308 | Solution a taelcg asiete! [ss [oe [ar] as] ‘The input domain can be divided into following y al Ta Dat at [a Ty Mf month has 30 days) 8], Tao, |b, [by Ty: month has 31 days except March, AUUst and Janugy, Welee De beet el 1, = (M,: month is March) T= IM, month is August ' ¥ [Xe xe I= (My month is January} Kiva | g= (M,: month is February] ae itt I= (Dyday=1) a [| I,=(D,:2s—|__ February 1 Ferny, 1964 a) 1962, 29 May, 1962 3 1964 2 aa May: a 1964 [gp etry [1S eran, 198 20 May ry a 30 May. PT Fetruary 8 | a etre, 1958 1962 30 May, 1982 Ce — (Contd. re eefthe character in column leinema ee 5 ino ; igs not a digit, message y is issueq, Message x is j Ifthe char- eb 28 rae a ; a February 30 1962 Tmpossibie dinate in colin Tis fe February 31 1964 Impossible ‘aracter in column 2 is a digit aoe Impossible are lh a a update ‘made “message x is issued (One weaknes of toundary value analysis and equivalence partitioning is that thee g explore combinations of input circumstances. These consider only single input cong Hionoves combinations of inputs may result in interesting situations. These situation bbe tested. If we consider all valid combinations of equivalence classes, then we will hae, ‘number of test cases, many of which will nt be useful for revealing any new errors. Forays ifthere aren” different input conditions, such that any combination of the input condtang valid, we will have 2* test cases (JALO96]. Cause effect graphing [ELME73] is a technique that aids in selecting, in a sysana way, high yield set of tet cases. thas a beneficial effet in pointing out incomplete ambiguit the specifications, The following process is used to derive test cases [MYERI| 1. The causes and effects in the specifications are identified. A cause i a distin ap condition or an equivalence clas of input conditions. An effect is an oulpt ede or a system transformation (a lingering effect that an input has on the state eft program or system), For instance, ifa transaction to a program eauses a master tobe updated, the alteration tothe maser ile isa system transformation; acne message would be an output condition. Causes and effects are identified by ra the specification word by word and underlining words or phrases that describe case and effets. Each cause and effect is assigned a unique number 2. The semantic content of the specification is analyzed and transformed into Boos sraph linking the causes and effects, This isthe cause effect graph 8. The graph is annotated with constraints describing combinations of causes as : Cue that are impossible because of syntactic or environmental consi : By methodically tracing state conditions in the graph, the graph is convertedit# . limited entry decision table. Each column inthe tale represents a test 5 5. The columns in the decision table are converted into teat canes ‘The basic notation for the graph is shown in Fig. 8.8. ‘Think of each node as hay Sores eee et entity funtion states that fe, is 2,¢, 8 ee is Ole, eis eth ie ¢yi8 1,¢;i8 1; else ¢, 180. The AND faye oes“18 1. The OR function states that fh ee Gemessage 7 is issue echelon anh is shown in Fig. 89. on pure oe je it does not contain an impos- peifiation. i inp a en er bah ace .es—it is impossible fo “ble because of 8 waott Prograins, certain combinations of aus pee 10 i sed. The E ‘The AN nction states that if both c, and c, are 1,¢ 8 ntal ams oe aD at D funeti ifbothe, and cp are 1,1 Senta con sin teeeciey ns ie ° Myers: tvertemcy Tea have any numberof inputs Mates that it mast always be rue hat st 0826 fant mt civone of imenlumn 1 must bean Act. The harass 0 ith the following example, “Me secu The Teonstrant tae yi tates hat me moo “aeannot be 0 simultaneously). Thegle problem specified in the t states that, fore, tobe 1,¢, must be 1 (i, example 83, Dra am Ww the cause-effect graph and nde, must be 1. The R constraint iti fore, tobe 1 and cto be 0). ide x is less than sum of sides y and side y is less than sum of sides x and ¢ side zis less than sum of sides x and y side x is equal to side y side x is equal to side z side y is equal to side z Not a triangle + Sealene triangle + Isosceles triangle Equilateral triangle ¢ + Impossible stage “Thecause effect graph is shown in Fig. 8.13 and decision table is shown in table 86, The lass for this problem are available in Table 8.5. (One and ony one Fig. 810: Constraint symbols ‘There is frequently a need for a constraint among effects. i states that effect eis effets oral tobe O. eee or int in Pi 4 Table 86: Decision ale aii ovifeoasfea | aspera] af ata [a [aa xPotatilat itt ttt cian cnet ip ena] ee | | || xslexa al aa [eva [nail | art |oa|xom no) a xfPxixfrfryefoiritiele xtxixirfe fet feist 7 {1 }2 : 5 i Tp T agi :revealed, then further inspection by h ceded by the specications and ence poset Mfanctional testing. This can be regarded as an error since it is dovicton pasion OY ot may find those errors, which have buen mised by functional testing Yt to look in to the program, examine the code and watch it as it runs. This Ge and is about testing a running program: therfore iti ealled dynamic iaing It we want to test the program without running it; meaning thereby eam- ef reviewing it then iti called static white box testing Hee, static white box testing is the process of carefully and methodically reviewing fmaredesign, architecture, or code for bugs without exeeutingt. It is somtimes refered sctural analysis (PATTON). {Path Testing Jestings the name given to a group of test techniques based on judiciously selecting a set ths through the program. Ifthe set of paths is properly chosen then it means that we sired some measure of test thoroughness For exanpi oe zohan fey source statement is executed at least once. It is most aplicable to new 5 esting or unit testing. It requires complete knowledge ofthe rognissinss sand hy developers to unit test their own code. The effectiveness of path testing MAR the size ofthe software under test increases. It is rarely, if ere exten For the developer, it is the basic test technique {(BEIZ901 Fi. 0.13: Cause etc graph of wang problem Cause-effect graphing is a systematic method of generating test cases representing ax binations of conditions. The alternative would be an adhoc selection of combinations, bats oing oo it is likely that one would overlook many of the interesting test cases identitiedby te cause effect graph. Although, it does produce a set of useful test cases, it normally doesnt produce all of the useful test cases that might be identified. 8.3.5 Special Value Testing Itis probably the most widely practiced form of functional testing. It is the most intuitive J ‘the least uniform type of testing. Special value testing occurs when a tester uses his ot domain knowledge, experience with similar programs and information about “Soft sp" | This type of testing involves: the program. deve test cases. We may call this an adhoc teting. Lgmeratng a set of paths that wil ever every branch inte PUTT a Now gidioe are used other than {oan “ett engineering judgement” 8 a1 1 2foding a set of teat cases that will execute every pa peation (ce sep special value testing is heavily Pecans : 4 Jee. “ dependent on: ties of the testing persons. uit t¥0 steps are not necessarily executed in *GH=MA canbe automated through the static analysis ofthe program complementary approach to functional testing is np flow. sing a graphical ropes te to examine the inlet] struc of net caled structural/white box testing IF [The poy 22 Program can be analysed Sh al tbe Po Borah is a dimeted raph is ote Jar responding 2088 ment, and edges represe! wt fae pode isan edge rom nod to node/ ithe #10 reaping 2 Pe SP *ited immediately after the statement resentation known as ow ntire statements OF™ a yeaa be generated fom the code of any problem. The bac, ‘graph can easily of flow graph are given in Fig. 8.14. (Sequence) (thher-ise) (We loop) (Repeat loop) Fig 8.14: The basic construct ofthe ow graph ‘We consider a program that generates the previous date, if date is given as an (for details refer Example 8.2) which is given in Fig. 8.18. Here line numbers are statemenn fragments of statement. It is a matter of choice to make fragment as a separate nade a include fragments in other portion of a statement. Our first step is to prepare a flow graph from the code. The flow graph of previous ‘program (given in Fig. 8.15) is generated and is given in Fig. 8.16. Such a flow graph hel, to understand the flow of control from source to destination. We want to find paths fem control flow and may like to execute every path during testing. /* Program to generate the previous date given a date, assunes dey validity of the current date entered. */ Hinclude include 2 int maint) int day, month, year, validoate = 0; ‘date Entry*/ Printé(‘Enter the day value: + scant(*ta", day); printf (*Enter the month valu Scant (*¥d", tsonth) ; print (-Enter the year value: scant (*a+ year); sCneck Date Valiaity +) 10 AE (year >= 1900 ue n Af (month month or 9 46 year = 2 ke day cs 31) | validDate = 1; ) else ( validpate = se (yearta rval=1; if ((yeartl rval Af (rval valiabat. ) else if (day validvate d else ( validbate = 07 else if (month >= 1 && month <= 12) && (day >= 1 64 day <= 30)) ( validbate = 1) else ( valiapate = 0; ‘Prev Date calculation*/ At (waliapace) ( if (day == 1) 4 4€ (month == 1) ( year. day=31; month=12; ) else if (month == 3) ¢ (Contd).82 3 se 55 56 7 se 59 6 a a 8 6 6 66 o 6 o 70 n n B ” % %6 n 7 ~ 0 a 2 2 a as a6 Sint rVale0s Af (yearté == 0) ( gval=lz Gf ({yearti00)=20 && (year ¥ 400) t=0) ( wvaleds , d else ( Print £(-The entered date ( td-Rd-d ) ig invalid’ day. north. ¥**" ) getcne (07 return 1; Drintf(*The next date is: td-td-td",day,nonth, yest): la. 818: Program lr provous datea ae th testing, Th ‘As we know, flow eration is the first step of path testing. The second stop i, ‘DD path graph: ‘mete tow ‘graph. The DD path graph is ia 7 decision to, dein ty traph, Here, we cncentrate only on decision nodes. The nodes of Now graph, why WP sequence are combined into a single node. | ing ence, DD Path graph ie a directed graph in which nodes are Sequences ofa, and edges represent control flow between nodes. | a In order to understand the congept correctly, we consider the previous date go flow graph as given in Fig. 8.16. The nodes meet w node, say n, due to sequential low, pyc it afnnde 9, Hence flow eraphof Fig apc if true goto 52 else goto 8, node with one input edge and one output edge Tee p There isa sequential flow from node 1108 10 ™ Decision node, if true goto 13 else goto 44, Ta Decision node, if true goto 54 else goto 59. i D7 Deston nde, true goto 12 elie goto 19. fa Tatermediate node 2 m Desson node itrue goto 13 else goto 15 f a Decision node if true oto 8 ae pt 13,14 My ‘Sequential nodes and are combined to form new node ny ‘57 Ts ‘Sequential nodes 15, 16,17 ™e ‘Sequential nodes, B os “Two edges from nodes 67 and 65 are terminated here a my ‘Edges from node 14 and 17 are terminated here. a Typ Decision node, if true goto 60 else goto 63. Two edges from Ld me Decision node, if true goto 20 else goto 37. nodes 58 and 53 are terminated. = ny Intermediate node with one input edge and one ouput el | Freee Nyy ‘Sequential nodes S Te ‘Decision node, if true goto node 22 else, goto node 27 pas 06 ag ‘Sequential nodes = fu Intermediate node i “Two edges from node 62 and 66 are terminated here <= om a st Tae ale 4 ce ale | at Decision ini 3 69 ele gto 72. = Tue a Re ae = “ Pete fn ok ad Sermons || faq| Senet le el] deceit tt Pode 26 and 21 are terminated Bere M**] PRG 1 neg | Four edges fromanies 0.0 eo Se Sr aa an Dein nlite plo Saeed PR ee : ms Seana das Bane | termesinte wade] a 34,35 5 5 rental noes ae 33, 4 ‘Sequential nodes Ree Es ram de Band 4 ar rina pee te | Tro sten ten ow 7m scental odes with est i! Sequetont path is any path through the DD pat, «van ip Figs 37> ing statements OF New conditions, Ther PH that introduces ‘Tho DD path graph is given in Fig: 8 = ‘edge that has not been emery vet indey at pth = he previous date problem andits DD pathergh fate ne. Matha are found and are given in Fig. ig Fe peieeeeenie. a te {Independent paths of previous date poblag vhs — gy Pea os Mer Mase baa yy sh ay a Mes as hy fi oo: Pa ha a hay T | Mina ar Mor Mov ro» Many 15 BED is Pay Mae Masser Bay Rey D | Pay May Mar Mor ro» Bas» "rer "aor afl" WT my Mas Mg gy Poy yoy Ps an sy I Ma Mae Bay Paes a Pa Per Mesa Pas a W | nya, iggy Mygy Pag Maar Mass Bue Mase Pad Baa Rs Pa a Pa Ra a a i a Pay ay My Magy Maggs Mags Mags Magy Magy Baye Maye Py Par Mae Mar Paw Mer Mas we Pe Te Ta Ra aNe aS: ie Pas My Mgy Mays Mas Mag Mass May a May May Maya Ma Maw Ras ae Mar Me RE shy Tg as Mga hg Pag May Ma iy May Ma a a Ma Mas a mi ig, 8.10: Indopendert ps ot eves IEP | (pit interesting to use independent paths inorder to ent {iy *tatement in the program has been executed a ese nee wy branch has been exercised for tru and fst Cars path graph of a given * re high tools that generate jety of programming ‘The DD path graph is used to find indepen The jer fr Wi aoe pendent path tent one daring pat ans PD Wear interested wo ss" A Tp ake sure that the reli ar pam testing itis reasonable to mal "Beyond that, we should go fora standarda termination of the nature of roots of quadrats. Consider the program fr the de re aoe ingen et an Yb nag er gd The output may hav eof he lng ha iver i Fig roots; Imaginary roots; Equal roots) * nk (Not a quadratic equation; Draw the flow graph and DD, graph. Hinclude #inelude 1 int main() ance 3 int_a,bye,valiatnput 4 double Dy 5 printé(*Enter the ‘a’ value: 13 6 scant (ra, bad: 7 printé (renter the 8 ecant(*8a" 4b): 9 1 1 pathraph. Also find independent paths fm print£(*Enter the ‘c* scant (*4d", £6) HE (la oe 0) & (a <= 100) 66 (D >= 0) £6 Ub <= 100) 44, (eve eae <= 1001) 4 32 valiatepue «2: no tao t Mu vaniainpue ery we ) 17 Af WwaLtateputest) ( 18 ae bbe tare; 2 kaso ¢ 20 Print£(*The roots are equal andvare ri =/r2 = Wf\s"s =b/t2* (float) al) Bea 2 eee asa) y Fa Desert (a u Printf(*The roots are real and are r1 = sf and 12° * Src so (eI/2e a), Lobedy ta" al) 36 ase zn Donets 28 Printf(*The roots are ij yo Fe tee aa aenaNY aod are oo ua ext 29 y + TBI (2.0%a) ,D,-b/(2.0%alr 3 4 ig, a1ater Posram few om" b1 else Af WwattatapueDD Path graph is given below : | Bes is aig] —————— |" Sequential nodes | ‘Three edges are combined Sequential nodes with ext node” (ii) ABGOPRS (iv) ABCDEFGOPRS (ci) ABGHIKLNRS au, ‘program given in Fig. 8.20 for the classification ofa triangle. It input isa triple of integers (s4y, a, 6 c) from the interval [1,100]. The output may be [Sealene, Issceles, ‘Not a triangle). Draw the flow graph and DD path graph. Also find the independent paths from the DD ah “fiscluge | finclude | int main) int a,b,c,validtnput=0; Printé(*Enter thé side ‘a’ value: ‘I: scant (*4d", ka): Print£(sEnter the side ‘b valve: *) A scant (*4a", gb) ; B Print£(*Enter the eide ‘c value:‘): a Beant (*¥d" 6c); = 100) 46 (© > 0) a HE Ca > 0) 66 (a <= 100) ce (D> 0) 66 (b <= 200) ku (© <= 100)) ¢ e) > al = Sesuentl nodes SE ( (a+b) > cy ak (fe va) > b) se Lids o) > all 16 F ‘Two edges are combined here valianput = 13 iT ¢ ‘Two edges are combined and decison node ) 18 # Intermediate node 19 1 Decision node ae validinpur = -1; 20,21 J Sequential node 7 22 K Decision node | TE (waliainputest) ( 23, 24, 25 L ‘Sequential nodes TE (ascb) 66 (b==c)) ( tateral’)? 26, 27,28, 29 M Sequential nodes Prince tsrhe) (pede) d nies! (Contd. else if ( (a == by 1) b=23 printt(ethe triangle is isosceles’) 2 ) 2 else ( e 26 prineé(*The trinagle is sealene*); 2 ) 2 23 else if (valiainput += 0) ( 30 printtteme values do net constitute a Triangle); pan) 32 else ¢ 33.” printf (+The inputs belong to invalid range"); Mo} ‘ 35 getchet)s 36 return 1s 37) ‘Fig, 820: Code of angle classiteatin problem Flow graph of trinagle problem is: fxtrase PO 820: Prozam tow graph table for DD path graph ig, a path graph Penang _nodes Remarks [Seen acgs | | Decitien ade | Decision nede Sequential nodes ‘Two edges are joined here Sequential nodes Decision nodes plus joining of wo ges Decision node Sequential nodes Decision node Sequential nodes Sequential nodes ‘Three edges are combined here Decision node ‘Sequential nodes ‘Sequential nodes ‘Three edges are combined here + > wlofvlo|zfzle|m|=|~|=lofs|m|o Sequential nodes with ext node )path graph is given in Fig. 8.20(6).E eo mm es Fig. 021 that the sequence of an arbitrary number of nodes aba tic complexity conforms to our intuitive non of of eyclomatic complexity are stated below paths Independent paths are: (i) ABFGNPQR : (iti) ABCEGNPQR (io) cae (v) ABFGHIMQR: (wi) ABI (oii) ABFGHJLMQR ‘may have number of paths, Although it is possible to define a set of algebraic expressions that gveage total number of possible paths through a program, however, using total number of paths ha been found to be impractical. Because ofthis, the complexity measure is defined in terngyg independent paths—that when taken in combination will generate every possible pay [MCCA76]. An independent path is any path through the program that introduces atleast ne ew set of processing statements or a new conditi Secrest MCCA 3 ESTO RSET, Given a program we will associate with it a directed graph that has unique entry and ‘exit nodes. Each node in the graph corresponds to a block of code in the program wher th flow is sequential and the arcs correspond to branches taken in the program. This graph classically known as flow graph and tis assumed that each node can be reached by the esty node and each node can reach the exit node. For example, a flow graph shown in Fig. 821 wit entry node ‘a’ and exit node ‘The value of cyclomatic complesity can be calculated as VG)=9-6+2=5 Here ¢=9,n=6andP=1 ‘There will be five independent paths for the flow graph illustrated in Fig. 8.21. path: acf path2 : abef path3 : adef path: abeacf or abeabes path : abebef lependent paths in graph 6. ting and deleting functional statements to G does not affect VG). Ghas only one path if znd only if V(G) = 1. pand exit reachable from all nodes. This definition would result in all ow graphs lyone connected component. One could, however, imagine a main program M and subroutines A and B having a flow graph shown in Fig. 522. oe Fig. 822aR Let us denote the total graph al P= 3, we calculate complexity at VIM UAUB)=e-"+2P 219-13 42*3 =6 | canto used calculate the complexity collection ofprag, i 7 . 4 particularly a hierarchical nest of subroutines. Notice that VIM UA V B) = VINO + VIA) + VOB) = 6. In general the complex y collection C of flow graph with K connected components is equal to the summation gt Complenities. To ace this let C, 1 sis K denote the k distinct connected component, ang fand n, be the number of edges and nodes in the ith-connected component. Then 4 . Vic)ee-n+2p= Ye- Ym +2K a ot ove with 3 conected SPOREDIE ARM Ay ny ehei=d ‘= number of regions 5 ‘This method with P+ 1 Since the calculation V = ¢~n + 2P can be quite tedious for a developer, an eft ty been made to simplify the complexity calculations. Two alternate methods are available fy the complexit ei ante aE ToT Oe ow gay EL a RSET, (decision) nodes plus one (MILL72]. a ‘Where II is the number of predicate nodes contained in the flow graph G. ‘The only restriction is that every predicate node should have two outgoing edges it, one for “true” condition and another for “false” condition. If there are more than two outgoing edges, tlie structure is required to be changed in order to have only two outgoing edges. Ifitis not vate cm is formula (11 + 1) is not aie ___ These results have been used in an operational environment by advising develope limit their software modules by cyclomatic complexity instead of physical size. The partis ‘upper bound that has been used for cyclomatic complexity is 10, which seems like reasons, but not magical. Upper limit when it exceeds 10, developers have to either recogni modularise sub-functions or redo the software. The intentions are to keep size of memageetis and alow & fe testing all independent paths, There are situations in shh limit seems unreasonable: e4, when a | r of independent cases fallow # function like awitch or cae statement, =" "UMDEY of independent cases fo Example 8.15 Consider a flow graph in the Fi sity Cans ider ae S77Ph siven in the Fig. 823 and calculate the eyclomatie comple Fig. 8.23: INCCATEL 816 Find cyclomatic the previous date program with DD path graph 8.17. Find cy siven in Fi 18 () = Number of regions = 18.ma : ‘eau Fig. 8.24 (c) the (5, 6) ents ‘erg ontop 18 Thin alae eit ih and diy Ja res, then the entry in ay isa rs review le, it is clear that we a tra peeps esi efor vehecking the validity of date” and another for spe” hay separate modal thee en funetins are independent and shouldbe ploy srodules, If we do 0, cyclomatic complexity will be reduced to’ 10 and 8 74.) odes a enc, thn eto ges same idea about the structane og Pea modularity of the program. Example 8.17 _ ‘Consider the quadratic equation problem given in Example 8.13 with its DD path ‘the cyclomatic complexity: FAD. Solution Number of nodes = 19 . ‘Number of edges = 24 (VG)=e-n+2P =24-19+2=7 (i) WG) =N1+ 1264127 ii) VG) = Number of regions Hence cyclomatic complexity is 7 meaning thereby, seven independent pat Before plexity ning thereby, Pendent paths in hep Example 8.18 Consider the classification of triangle problem given in Exam ind the ¢ complexity. moter le 5:14 Find the oom Solution ‘Number of edges = 23 Number of nodes = 18, - VG) =e—n+2P =23-18+2=7 Gi) VG) =1141=641=7 (iii) VIG) = Number of regions = 7 nami Qelomatc complexity is 7. Hence, there are seven independent path ss ts never graphs are used for testing, we are interested to find independent paths. The it is to trace all links of the graph at least once. Path i ae i graph a ’ath tracing is not an easy task and is Tainan Sze raph creates, itbecomes dificult todo path racing mama Jo red 80 for fo a data structure Seu ting tool. To develop such a tool, a data stru A is ef = A graph ae mato with one row and one column for ever we d in the low graph: See crthe Bumber of rows and colurans) is equal 8 Te at inFig, 824.” 2PH- Some examples of graphs and associated matrices (BEIZ90)* In the graph matrix, there is a rode and any other node. A connees ° in ana: Flow crops and of lace to put every possible direct connection YS ne Connection from node ito node j does not imply #<™ goosemeta, Teomplexity and two/three link. na he Pe de to, tation of a flow graph. It cnet phan nt te nn, a aoe e ating useful information required during tesling: “i moet weg se ving tr kmh ah wg df rng ‘ ‘connection (¢) is obtained by replacing are impossible paths, Our east efnition clear paths [vera Dees 118, 18, 20,24, a and if not posible then, at eat at {hind be to generate toe fi $ 11,18, 20,2428 Math that are st en é a al | M1, 18 [= #4 , © 19, 22, 23, 27 given in Fig. 8.20 for the 18 22, classifica c of i ona é ory 24, 28 (cay a,b, fom the interval (19) ers APE Topi age D aa 3-51 Isosceles, Equilateral, Not triangle, tnvatig; noted = 3, 7 ” * invalid inputs), Validinpat paths and identify those du-pa ‘Step IV: The du-paths are identified and are named by their beginning ang eae ee ‘path that are definition dean, nodes using Fig 81900) _p3: The program flow graph is given in Fig. 820 a) Path (beginning, end) perigieon wre, b, © validinput. ariables used in the Variable poi [DD path graph is given in Fig. 820.6). Th cya comple 2 611 Pg, there are 7 independent paths, plexity ofthe graph & 3 te yep IE: Definc/use nodes for all variables are giv 6,20 Yes a: [ivariaote ee es ae = | 10,11, 19, 22 ox Yes 18 ES Yes ® 10,11, 19,22 b 8s ‘Yes c 10, 11, 19,22 818 ca | Validinput | 18,29 8,20 Yes yg . 8, 24 ‘Yes 8 IV: The du-paths are identified and are named by their beginning and ending 8,28 Yes aking Fig. 8.20 (a), . 10,11 Yes 7 Path (beginning, end) | Definition 10,18 Yes aot dear? a 18,19 Yes 510 es 18, 22 Yes: - ‘Yes 18, 23 Yes pu ‘Yes 18,27 Yes 5,19 fe D 23, 34 Yes oe a 25,28 Path not possible ° 7.10 xe 2724 Path not possible au a 21,28 Yes 119 a Valtinpat a7 20 >——_ | 2 Yd 3a 0 < 9,10 Yes 2 7 no 911 Yes a 8 i no i 9,19 Yes wit Yes . S| M431 £5 ee ee |epy which a test suite is evaluated : specific set of (scored) va ma I ne eaualen. Tae eNotes ew oF oeotal mumber of mutants aber ofa Pee aa inthe pe the tote MMS created. The sore acres ne 24 eauvalent gals Mis simply ‘Ssvocited with atest suite T en # killed Font e # total — # equivalent “100% “equation allows us to determine the lieth! tha , fis sa wll catch real faults based on how wen i kale ean ; ed Mot penalize a test suteifit wefan ne? ‘mutants Noe that pore ee tra test suite A with 100 test avert sera So ge e or had a score of 49%, Although A has abetter mutatin acon estate Bit ‘Mutation testing isa fault based technique that is similar to fault seeding, except that, tions to program statements are made inorder to determine properties about test cases ef basically a fault simulation technique. In this ue, multiple copies of a progran 42 sade, and each copy i altered; this altered copy j@giled a mutant. Mutants are exceed ig test data to determine whether the test data af@eapable of detecting the change between original program and the mutated programdAsnutant that is detected by a testcase stern “killed” and the goal of mutation p 8 to find a set of test cases that are able groups of mutant programs (FRI. ‘Mutants are produced by ‘matical rule that changes | ing mutant operators, An operator is essentially a grax expression to another expression. The new expression shalé be syntactically legal aggiffing to the language. If one or more mutant operators are eld toall expressions in a program, the result is a large set of mutants, all of which mus be kil bby the test cases oF shown to be equivalent to the original expression. ‘When we mutate cade there needs to be a way of measuring the degree to which be ‘code has been modified. For example ifthe original expression is x + 1 and the mutant fr tit expression is x + 2, that is a lesser change to the original code than a mutant such as (€2, where both the operand and the operator are changed. We may have a ranking scheme, tf itdiscussed so far in this chapter are direetly applicable to nit testing. System testing a first order mutant a single change to an expression, a second order mutant is a mutts fend better than int ‘but both need elarifation, The bottom up ap- ef in integration testing, but bol sam erat mutant, andso on High order mutants becomes intractable and thus i PS" fy Ws some insight: test the individual units and then integrate thee nt so only low order mutants are used. ie system is tested. System testing is something thatthe cstomer understands ne dfculty asscited with whether mutants will be killed is the problem of et brders on customer acceptance testing. General em sine ct the location; if mutant is not executed, it cannot be killed, Special test cases are tobe Iagtt™¥*tural. This is mostly due to the absence ofa structural basis fort et to reach a mutant. For example, suppose, we have the code - 'Taditional view, integration testing is what's Iftoer isnot unit ests Read eb a sting Most othe ural discussanom iteration ie SON OT If(@ > B) and(b =) then thon Are integrated: top-down, bottom-up, oF the bi bang\ "er fmake mutants; my, my, my : integration is the least well understood [JORG 8) ‘Those that ion is the least well unde DEUT &2 ‘To execute this, input domain must contain a value such that a is greateF than teeny loca several eae are ‘under consid: saphass during testing is to examine and modify the source code. There are thre levels ie, individual module to the entire software system. At one end, we attempt to test inall possible ways so as to detect any errors. From there, we combine to form aggre {andules and test their detailed structure and functions. At the end, we may ignore the structure of the software and concentrate on how it responds tothe typical kindof ms that will be requiested by the user. These Outofthe three traditional levels of testing, unit testing is best understood. ted during testing may fall into as ‘equals e, Ifinput domain does not conta, risk He Rediate is hat they e738 ce cersted ; does not contain such a. ants made at 89 Attention are usually of a nature’ rsneed to shouldbe considered equivalent tothe eign ane eo Penang cannot vontinee atl they arom: SU! pede. ingeea dead a iginal program, because the statement "1°", MT 8 te which it ‘ove code that cannot be reached during execution) Ifwe make the ust * complete but ean be ignored during the BEET he equnsy mith WH Y ‘Temoving an error is proportional tots =to renace modes that * sstnag for dammy SUDPFORTAM USE the guna PALE to (ealtgg ion, prints verification of entry, go ye'® dle intr?) SM Module tbe code, called scaffolding (Pras gr 89 do minimal rin the delivered product as showe eit ort rare of it. There a ‘ tomer is Fe ero occurs, and the degree to which the OMIT of correcting them at the may, cr oe ane oe 8 my be held until some future release da ied request & change. ror usualy no- reproducible, or Wich insulin factual overhead is relatively 7. FEB aos vo testing bt Finally, there are errors, wile ngoing consideration until they become wri ‘ested with simple overhead syne Tnately, many Net and atabs toeralaat them They a regeqvent problem with concurrent sofbware, "May it ware. In Ym Nomreproductbe errors ares feat Hl the integration tex step (where stfnertathe sealing automate te aes things, allows us tO OWN a single unitinieoare Atesthamesa tam environment by providing a : : ropriate in ing the res ofthe for the unit. A third and rather ineetne ec eet parameter, tnd allow incremental addition of modules toa paral mteserog nt i sting and jon testing will also provide sufficient coverage of the mages rin that fe usually inadequate but nevertheless iis ten eee » box testing approaches are normally used for un in the literature, {n parallel for multiple modules it testing and the steps can be les cannot ch cats, complete tenting conte 3ed). A second Fig, 828: Levels of testing Number of other activities are also carried out alongwith testing. These include ‘documentation, product modification, and discussions with the customer to schedule preparation of installation and training material ete. When the product has finally ben leased by the quality assurance group at the end of testing, we want to move immediate the installation portion of product delivery. 854 Unit Testing Unit testing is the process of taking a module and running it in isolation from the rest i ‘software product by using prepared test cases and comparing the actual results with ‘ula predicted by the specifications and design of the module. One purpose of testing is™ (and remove) as many errors in the software as practical. ‘There are number of reat! ‘support of unit testing than testing the entire product [JONE 90]. 1. The ize ofa single module is smal an le is sr nough that we locate an error 2. The module is small ey mah in some demos exhaustive fashion, that we can attempt to test it in som ‘3. Confusing int . se enfuig interactions of mul errs in widely diferent pot of alfelding required testing & progam int (me) is correctly pendent sodule is core cprerface between modules is Stree cPi8 Bives little chance to determine that ee er ecite tacet fad for this reason integration testing must PTT oy sides as to PE, Pie testing is the interface: whether parameters Pe ron e interface: wet There, '8e8, meaning and utilization (CO! eth aig ate ‘Several classical integration strategie hier Top down-integration proceeds down the ted with ion, How 3 ¥ ‘module without anything to call it, to testing a module in isolation. : be called by it o, possibly, to output interme vetitlbasisn atin at eal a ing one module —_——ttesting, we move a pte reat a module as ani," fom sructar ‘which trvales become lange ™P&netrable mecha a ‘and toward fune- ed modules become larger and large fr performing a font ins, and must be satis We lose our abil on Bl en ey baa nate . we teat the paduc ay cane te proc ema ace appropriate outputs, without concern fr theme Yen tat specified in functidnal tests we can and should continue teh ee te sae ramusual conditions (NONE 90). n attempting ta erie te taba represent Browsre system, We may not be abletajumpfeom suse eee om smal ts eile maintaining the principe of adng ve tofunctiona teats cue fe design stage and to se them asthe bass for fumtinal ee fime a new module i added as part of integration testing th eatware cham flow paths are established, new UO may cecur, and new control loge nvoeed may cause problems with functions that previously worked aiessy and thus it eliminates the noed fy, etiom and bas 20 need of tu, 47 My tno omewher inthe mage, ~ Ally fraet of testing, the system level is closet to everyday experience. We test many ‘aused car before we buy it, an on-line cable network service before we subscribe, and Mz Acommon pattern in these familiar forms is that we evaluate a product in terms of ur ‘not with respect to a specification or a standard, Consequeatly, goals otto find but fo demonstrate performance. Because of this we tend to approach system testing [rfunctional standpoint rather than from astructuralone. Since is sointutivey familiar, im testing in practice tends to be less formal than it might be, and is compounded by the testing interval that usually remains before a delivery deadline (JORG 95) _ Aswe know, software is one component of a large computer based system, Ultimately, is incorporated with other system components (e., new hardware, information), and [2 teres of special tests are to be conducted. Many times, software products are designed on a variety of hardware configurations, The software should actually be tested on ferent hardware actups, although the fll range of memory, peso, operating Peripheral possibilities may be too large for complete testing. There are many ____ When the lack disappears, the concern is no longer significant, But there #72 [8 0fspecitcations, ad we should be aware of those as we perform system testing. For incl tat shea Eide integration First if we are going to overlap module tetine there ay be a specified level of performance required ofthe software This may integration n we that not all modules will be ready for integration" y se various toads and operating conditions. It may eer crea lules will be ready for integra! oman t83ement of response time under various loa ‘Setwene reliability should also be Integration st ww the li is a ‘minimum and average up-time Integration should follow the lines of first putting together those subsystems thet * It cin jae and eft ede great concer. This prnisation might dictate top-down integration if onto] ant % with apecfiations, These epec- thocustomerIoansions ea sone oF complex part of software. This can occur, fr instr failures should also be recorded and comparsd Whe ting, we can try the machine interface and performane era earl in the testing phase. In another site) Sitka ld represent customer's wants and needs, an mance might be of special interest, and then bot ig e Tequirements and specifications really do coincide om-up integration we stand better chance of °° ar [9 The Sbenik gives some guidelines for choosing test int than testing its integration. It has also been said that oP" 9 ett a that testing the system's capabilities Is 008 ake for whereas Soe hat things aya wil work out well whereas bottom-uP i! Sancvich integration Fig, 8.30: The cterent integration approaches ‘There has been a lot of discussion about which one of the three; viz top-down, bettan or sandwich integration is best. Most of this concern is driven by the need to mix moll testing into integration, because of a lack of test harnesses, uring system testing [PETS aa eis tht are cnet Sa adel wh Formaiiey Merely annoying need not word Ee ‘The ealabity ofthe reporE Teport, but probably cannot deal withand te 9 oe Comer inrtnn a = cas afin ta al es ean, aren va a wee CASE ree enik’s second rule is that Ne the software to the kind of yen Foetal customers are tts cust thep a ei re a agg Fe oi erg + ete Thin cn be i ja the operational profile. eT may be pl the software, The process is cared out soa company and are sentative of actual use os en onware engineers may exhibit blind spots thar ‘with this kindof testing. Infact, notice exotie problems; while the ‘ore problems that user would Sot immedi OG heen modification of an existing product, we jn respective Premises across the globe The peg ast Customers test the Thins fe are ting a eaconae beri thatthe user a et fei nowt any contol of developers Th J ate conducted a abilities rather than new oD¢s. ha te a : : ; etic loprs receive the failure rey dares cof the software, and woud not be paralysed if these were not righ Bue and may modify the code, whereever necessary With this vategs the ene eek of many potential customers without iny ‘ 1 users entire oper sty could do jut that-paralyse the user's entire operation, Ta P Ia the ch fonetionality tance testing is popular with customised rationale for Petschenik's testing priorities is that exhaustive testing of sine incomplete withthe kind ofshort update cycle imposed on many rye ig Me sofware a5 per expectations. These tests seat as dependability is more important to the user than the total correctness, the ‘at 2 amatic series of tests. The duration of this wBhuny fection also weigh much more heavily than total functionality, poet athe. The identified buys wil bef ota 7 ‘by introducing a new release of the prod, should avoid disrupting current usage by int ct that, ‘fe IBEE has developed a standard (IEEE std. 10581999) entitled “IEEE guide for not support current fanct ioe of \d validation” to provide yer teting, we shoul evaluate a numberof attributes of thes verification and validation” to provide specifc guidance about plansing and During sy ing, the tasks required by the standard so thatthe customer may write an efetioe are vital tothe user and are listed in Fig. 831. These represent the operational eo 5 Fequired by the product and may be part ofthe software specifications [JONE 90], IEEE 95). Validation testing improves the quality ofsoware product in terms of fonctional bites and quality attributes. The quality attributes may vary from project to project. rolving the reputation ofthe company, ‘software, Here, customer is available ‘may range from adhoe tests to well type of validation testing may be few ixed and improved software will be delivered to S ni tary rea Usable Ts the product convenient, clear, and predictable? Ke ntrbutes serve the customer's need fora software product that is eapable of meetingits Serure In eset etve ata revricted to thove with etheriatin? | with adequate performance with no unexpected side effets. Some ofthe — raracy, completeness, consistency, correctness, efiiency, maintainability, portability, Compatible Ra the product wor Comectly in conjunction with existing dats ot. Vestn, testability, usability etc. Some customers may focus on such attributes during =a ain esting. A systematic plan may result into good quality product and happy customers. Dependable Do adequate safeguards against failure and methods for recovery ela in the product? Documented ‘Are manuals complete, correct and understandable? vdsussed earlier, the goal of testing is to identify errors (bugs) in the program. The process Vssng generates symptoms, and a program’ failure isa clear symptom ofthe presence af fer. After getting a symptom, we begin to investigate the cause and place of that error. itenttication of place, we examine that portion to identify the eause ofthe problem. This Atnbutes of stare to bé tested uring system tstng _ 86 VALIDATION TESTING — fis called debugging. [trefers to test the software as a complete product. This should be done aller unit anit? pre ; ting errors, It ean start once a should be done after debugging is the activity of locating and correcting Tine (ating Here, we want to test the software with the perspective of the eustomers208™ Hevhas been detsety ny eatin tatae to correcting ‘ n detected. Unfortunately, going rom the dtc te a ce va st meinen af the customers. We may 1008" titi, Tesponsible, is far from trivial. Itis one ofthe least understood activities in softw : yale pelea ih SS decane Pent and is practiced with the least amount of discipline. Ii often approached wit Te may not be o PSteve ana tle planning {GHBZ 94). AY not appriciate it. In order to avoid oF ii! crptanes eactvelvement of customer is required during validetion testi, Alt ng are nothing but the various ways of involving customers dui"jence several techniques for debugging ahase ar applied in atrial ad error manner. Debugging 8 noLAn Sosy Prvcess. Thins pga hese are arid cater an cofevare technology. Error removal requires yaaa ‘even odmit the ity of errors in the code we have created and requires an open tg Free ranting tocoe what the software actually does rather than it should do, Commoyy 4 human aspect of debugging, Shneiderman (SHNE 80), states: ee “It ie one of the most frustrating parts of programming. It has elements of solving or brain teasers, coupled with the recognition that we have made amie’ Heightened anxiety and the unwill y of errors, incre task difficulty. Fortunately, there i bug is ultimately corrected”. However, Pressman 1. “The symptom and the cause may be ‘may appear in one part of a pi other part, Highly coupled progra 2. The symptom may disappear (temporarily) when another error is corrected 8. The symptom may actually be caused by nonerrors (e.g. round-off inaccuracies 4. The symptom may be caused by a human error that is not easily traced 5. The symptom may be a result of timing problems rather than processing probes, 6. It may be difficult to accurately reproduce input conditions (e.g. real time appt tion in which input ordering is indeterminate). 1. The eymptom may be intermittent. This is particularly common in embedded a tems that couple hardware with software inextricably. 8. The aymptom may be due to causes that are distributed across a number es ‘running on different processors", ally remote. That is, the syn le the cause may actually be locates jtructures may complicate this situation, ‘A number of popular techniques are given in table 8.8. . In general, none ofthese techniques should be used without a thorough prior nal toms the error resulting in a hypothesis concerning the cause of the errors. For inst if two modules behave properly when operated separately, and a failure occurs when integrated, their interface should be checked for consistency. 8.7.2 Debugging Approaches In heart of debugging process isn ‘ est Rear of atbuauine proces i nt the debugging tol, but the underlying #PP°™ Title 8: A contain cine Features ‘A printout of all registers ‘and relevant memory ocations is‘obtained and studied, All dumps should be well documen- ted and retained for possible use on sub- sequent problems. Essentially siiffar to core dumps, except the printout contains only certain ‘memory and register contents and printing is conditional on some event ‘occurring. Typical conditioning events are entry, ext, or use of (1) a particular ‘subroutine, statement, macro, or database; (2) communication with a terminal, or other peripheral; (3) the value ofa variable or expression; and dom) in certain real-time systems. A special | fare entered inthe source printer, di (4) timed actuations (periodic or ran ot various dey 70 ena instant of time area tained fr study ror hypothesis, problem with trace programs is that the conditions Tanguage and any changes require a recompilation ‘The standard print state- ment in the language be- ing used is sprinkled throughout the program to output values of key variables. A program which runs concurrently with the rogram under test and provides commands te (1) examine memory and registers; (2) stop exes tion of the program at ® particular point: (@) search for references (@ particular constent® les, registers 1. This isa simple way to test whether a partic: larvariable changes, as it should after 2 par ticular event. 2, sequence of print Statements portrays the dynamics of ¥3 able changes 1. Terminalorient time program 2. Considerable exiiity dynamics steal toexamine operation. erdevel language of 2 High rue some CPU ime, significant LO time, and much without an error theory or debursng plan) 3. Hexadecimal sum: bers are cumbersome {interpret and itis diel to deterie the addres ef sure Iungange variables 1. They arecumbersome! to use on large pro grams If used indiserim rately they ean pro- duce copious data to be analysed, moch of which are superfiu- Generally works on a machine language program. versions must with interpreters 43, More commonly used fon microcomputers than lange computers.Software Eng, and error. The debugger too ‘One obvious techniques is that of trial in the code the underiyins *® th, ‘error symptoms, reaches & snap judge a Sere gt Ga rains ddebuges meee io be, and jumps into and roam around in ve slow and wasteful approach, Mgueg from the standard pit of tools. Obviously, this iaie The accond epproach, called backtracking, is to examine the error symptom ., — " ctracks in the program flow of contro} wher they are fist notin, One then backt ly, this process brackets the locats, Teoria the poeram Bebeeqeent, careful study of the ‘bounded segment of the code. Beneraly feveas the cause. Another obvious variation of backtracking it forward tracking, when? ne, print statements reer means to examine asucession of intermediate results wee mine at what point the result first become wrong. If we assume that we know the corey values of the variables at several key points within a program, we can adopt a binary sean typeof strategy. A et of inputs are injected near the middle ofthe program and the utp’ examined. I the output is cores the eror is in the first haf of the program: and ifeutperg wrong, the error isin the second haf ofthe program. This process is repeated as many times it is feasible to bracket the erroneous portion of the code for final analysis [SHOO 87), ‘Thethird approach ould be to insert watch points (output statements) at the appropeae place in the program. We can use a software to insert watch points in a program witice ‘modifhing the program manually. Ths eliminates many practical problems involved with aiding adhoe-debugging statements to the program manually. For example, in the manual modes, ve have to be sure that after finding and fixing the error, we remove any debugging statements we have inserted. oS Poin, tion of The fourth approach is more general and called induction and deduction (MYER 79} ‘The inductive approach comes from the formulation of a single working hypothesis based ce the data, on the analysis of existing data, and on especially collected data to prove or disprove the working hypothesis. A description of the steps follows; a flowchart of their applicative sequence is shown in Fig, 8.3 #heess of deduction begins by enumerat Janey mistake made when debugging a program is step is the enumeration of all thats knee reams about the problem. The first what it did incorrectly die ay kon about what the program aid correctly, ‘Additional val ithe Symptoms that led one to believe that an error "exist. al valuable clues are povided by mechan toe "that do not cause the symptoms to ap lar, but different, test cases _ 2 Organize the data: Remembering that inductor ” _ from the specific to the general the moyen ac mis that one is progressing palance in his margin account”) 4. Devise a hypothesis: The next steps are to study the relationships among the clues and devise, using the patterns that might be visible in the structure of the clues, one ‘or more hypotheses about the cause of the error. Ifone eannot devise a theory more ‘data is necessary, possibly obtained by devising and executing additional test cases. If multiple theories seem possible the most probable one is selected first. 4:Prove the hypothesis: A major mistake at this point, given the pressures under hich debugging is usually performed, is skipping this step by jumping to conclusions and attempting to fix the problem, However, itis vital to prove the reasonableness of _ the hypothesis before proceeding. A failure to do this often results in the fixing of ‘only a symptom of the problem, or only a portion of the problem. The hypothesis is __ proved by comparing it to the original clues or data, making sure that this hypothe completely explains the existence ofthe clues Ifit doesnot either the hypothesis is invalid, or the hypothesis is incomplete, or multiple errors are present. ‘approach I causes or hypotheses, which seem possible. it until a single one remains for validation. A appears in Fig. 8.33 (MYER79]. The first stops to develop a list ot be complef#Pxplanations; they and analy the available data, one by one, particular causes are rul m of the steps follows; a flowch 1.Enumerate the possible causs Fall conceivable causes of the Are merely theories through whi 2. Use the data to eliminate ssl cous caret Ptyis ge he data, Particularly by looking for contradictions, owe gttemy Fann ‘possible ceusea,Ifall are eliminated, additonal data are needed (e@y devising "Additional test cass) to devise ew thers more ene posible cate remains, man probable cause the prime hyptests sles st 4. Refine the remaining hypothesis: Te posblecauset this point might be cor “ ileal tobe pectic enough topinpint the ror. Hence the nex one Use the available chues to refine the theo (a “erorinbandling the lst ransaction in the fey ee something more specific fe the last tra - Verlaid with the end-ofile indicator»mest file/data generators, used to Test harnesses, used to simplify ‘mest archiving systems, - — ‘This vital step is identical omer ding ; esis: Py test operations Prove the remaining ‘Ned 'o Provide documentation about programs. Testing Tools wate analyser operates from a precomputed database of descriptive information derived Ube source text of the program. The idea oa stati coalyses nto pone alertions hich jdaims about the analysed programs that can be demonstrated by systematic examination chose rel | there is a close relation to code inspectors, but static analysers are stron ical inde FACES, DAVE, KVP, PL chcost compe LINT en PBs sd on 9]. All of these systems are language dependent in the sense that they apply to a par- language, and also often toa particular system. Many applications using static analys- find 0.1-0.2% NCSS (Non-comment source statements) deficiency reports. Some of these real, and others are spurious in the sense that these are false warnings that are later ‘after interpretation, These are language dependent and require high initial tool in- Fig, 8.3: The deductive debugging process [MYER7S} 8.7.3 Debugging Tools Bach ofthe debugging approaches can be supplemented with debugging tools, We ean wide variety of debugging compilers, dynamic debugging aids, automatic testcase penn ‘memory dumps and erossréference maps. However, tools are not substitute for care ation based on a complete software design document and clear source code. ve tool for checking and diagmosties. Ofcourse, it checks enly of runtime errors. Compiler should give proper and detailed ne debugging process. Compiler can give all printed alongwith the listing. The attributes iave been picked up by the compiler scan sud \dards in a uniform way for many programs. messages. also possible to build code through an interactive environ 8.8 TESTING TOOLS [ss minimum conditions on the prog ‘One way to improve the quality and qui possible for the tester. This means that possible, ‘The two broad categories of software test id dyna 1 ware testing tools are: static and dyn: ensues flleanly into oe category or the other, but there are some exceptions cvaluation systems and mutation analysis systems (which actually run interpreti¥! ‘ve different types oftols available and some are listed below [VICK 84] iaicat iescas hich examine programs systematically and automat ii » who they * rmnimur quality roach Programs automaticaly to make S87? id) Standards whizh impose si Go) Conaean snroeers, which impose simple rules on the developer rage analysers, which measure the a (©) Output comparators racy estar the extent of coverage i foe ‘determine whether the output in a Pros™ ‘of testing is to make the process as pss Is should be as concise, powerful and oe tool is like a code inspector, et that a full-blown static analyser look at single statements. led, the standards enforced tend to be cosmetic the readability of the programs. It * fgram is an indirect indicator ofits quality. sop thatthe ils are generally simpler. The main dstne- oe ae .s at whole programs, whereas a standard enforcer rikesr] toot are used to catch bags indir trou tine ofthe program shat git Saul that is used (mostly in COBOL environments, but nyo example is a program generator OT parts of each source module, Use of such » ‘in others as well) to produce the Prea ake, which in itself enbances the readgb,, af smethéd ensures that all programs programs. oe Eee programming Preprocess0rs that prod Corepeslegregs ae stings typically have automatic ing vt tive print output. Such augmented jindexing features, and in some eases much more: 8.8.2 Dynamic Testing Tools Dynamic testing tools seek to support that accomplish these functions, afew int implementation. ofa single invocation of the test object and all of the execution A test consists Wil the test object returns control to the point where the invoca so smapengptaretancentigentemael eg Fe the dynamic testing process. Besides individuay tegrated systems group the functions under « °% in form these functions: t the test object reads when called ting inputs when a stub is called, values that the test object produces (iv) Test coverage measurement: determin ture of the program, () Test planning: helping the tester to plan tests so they are both efficient and al effective at forcing discovery of defects. Coverage analyzers (execution verifers) A coverage analyser or execution verifier (or automated testing analyser, or automated vert cation system, etc) is the most common and important tool for testing. It is often relay simple, On ofthe commen trates for testing nvlves declaring minimum evel of en granary expresed a percentage ofthe lemental segments that are exercise nee luring the testing process This is called Cl coverage, where CI denotes the minimum ll testing coverage so that every logically separate part of the program has been exetestt least once during the set of tests. Unit testing usually requires at least 85-90 of C1 oo let ‘Most often, CI is measured by planting subroutine calls-called software probe** 1c kind of runt Pithe high degree of interaction each segment ofthe program. The ttt ai ray est object is then executed and som tystem is used to calle the data, which are then reported to the user in Rix SP, [ee of overage analysis cn be inearporated nto most quality assurance situations let ‘more ‘when there is too little space or when non real-ti ion is inea Output comparators ‘Output comparators are used in dynam i wen mani testing snglemdule and mule ge (system level) varieties to check that Gystem lev ties toch Predicted and actual outputs are equivalent. 7 alt Jone during regresion testing. The tpial output compare tvetem objective ine Was made, sf is normally required to test one module or to testa Set of modules tu fe mime rules Ty PB that meet a particular objective normally to execute previously unexercised segment list hamess system is one that is bound (Ge i 1g between two files; the old ang and the ni few output from a program. Typical for the better mi systems minicomputers often h met Wve an output comparator, someti [ae comparator, builtin, erator creates a file of information th a ion that is used as th Se ee as the program and does so based an ven hy the user andor from data descriptions tina COBOL) program's data fe ection, forex sty this isa COBOL-orented idea in which the file of test Pie simulate transaction inputs in a data base mat ie cen data base management situation. This ata generation problem isa difficult one, and at least forthe present is one for which solution exists, On the other hand, there isa practical need for methods to generate a generation is that it requires generation ong a chosen path, and the reality is that: Je ermal Wn Bags Tnpractce, the techniques of variational test data generation are often quite ef ym an existing path that comes nefiethe ‘One of the practical difficultiesith test tf inequalities that represent sh condit {Paths are too long and prifisce very data are derived (rather than created) fr dsogment for which test data are tobe found. This soften very easy todo, appa ty iat in the process. Automatically generating tegbdata programs’ structures tend to ass ively impossible, but good R and D work is now being done on the problem. kei andesite) rod the tt sound tt pas and tpt and) odin a peters tch ted, Clowes a ernst maker 6m ry eae tt hares 5, mc fther kinds of analysis support. and that (1) permits easy for online measurement “tive in practical use. Modern ito be the focal point for installing many aysters a tem is to keep track of eres of tests and toact as the basis for aright oni te Atypical design wolves establishing ba reece, ce Tal re 7 enting whi eae ficapplication-specific basis. piteetdaes for cue na tenes Boal of,450 B Software Engingg 8.8.3 Characteristics of Modern Tools The characteristics of modern software testing tools differ somewhat from previous syste, Modern tools are modular and highly adaptable to different environments. They also tend make use of the facilities provided by most operating systems rather than provide those es bilities internally. Case tools that support DFD, ERD, and structure chart diagramming, offer mini data dictionary support, are available in the market. Project and Instaplan Management like MS Project, a configuration management tool like PVCS, and testing tool like Visual Te and flow graph generator, commercially software design tools like object modelling technig (OMT) and CTT development environment are also available in the market. REFERENCES ] NN ate lala RNs ee (BEIZZ90} Beizer B., “Software Testing Techniques”, Van Nostrand Reinhold, New York, 1994 0, (BERT94) Bertolino A. and Marre M., “Automatic Generation of Path Covers Based on the ce Flow Analysis of Computer Programs", IEEE Trans on Software Engineering, Vol. 9 No. 2, Dec. 1994. | (BIEM94) Bieman J.M. and Off L.M., “Measuring Functional Cohesion”, IEEE Trans. On Sof, ware Engineering, Vol. SE-20, No. 8, pp. 644-657, Aug. 1994. | [COLL88} Collofello J.S., “Introduction to Software Verification and Validation", SEI-CM-13, 1.1, Software Engineering Institute, Pittsburgh, P.A., USA. (DAHL72) Dahl 0:J., Dijkstra E. W. and Hoare C.A.R.,, “Structure Programming”, Academic Press y New York, 1972, -[DEUTS2] Deutsch MS., “Software Verificatior Der rentice-Hall, Englewood Cliffs (ELME73] Elmendorf W.R., “Cause-Effect Graphs in Functiblal Testing”, Poughkeepsie, NY IBM System Development Division TR-00, 2487, | [FRIE95} Friedman M.A. and Voas Jeffrey M., “Software lohn Wiley and Sons, 5. | [GHEZ94] Ghezzi C. et al., “Fundamentals of Software Engineering”, Pégtice-Hall, 1994. (EEE93) TEEE Std. 1059-1993, “IEEE Guide for Software Verification and Validation Plans’, IEEE Standards Board, 1993. (JALO96} Jalote P., “An Integrated Approach to Software Engineering”, Narosa, Delhi, 1996. (JONE90] Jones G.W., “Software Engineering”, John Wiley and Sons, 1990, (JORG95] Jorgensen P.C., “Software Testing: A Craftsman's Approach”, CRC Press, USA. 1 {MCCA76} McCabe T.J., “A Complexity Metric”, IEEE Transactions on Sol ftware Engineering, Sl 2,4, 308-320, December, 1976, (MILL 72} Mills H.D.. “Mathematical Foundations for Structured Programming”, Federal SY Division, IBM Corp, Gaithershurg, MD, FSC 72-6012, 1972, (MILL77) Miller E. F., “Tutorial: Program Testing Techni Y 77, IEEE Comput Society, 1977. ‘chniques", COMPSAC’ (MILL79} Miller E.F. and Howden W.E., “Software Testing and Validation Techniques", IEE Computer Society, 1980, ft fing and Validation Techniqt he, i cea 7 RM89]_——-Norman Parrington and Mare Roper, “Unde, : ore ohn Wil ak : and Sons, 1989. per, “Understanding Software Testing”, Jo! (PATTO1] Patton R., “Software Testing", Techmedia, 2001,