Software Engineering (phần 12) doc

4l@ t H A p T : R 4* * Im plem en'olion Phase for execution-based and nonexecution-based testing, a tally is kept of the number ' of faults detected. In contrast, when Cleanroom is used, tçtesting faults'' are counted from the time of compilation. Fault counting then continues through execution-based testing. In other words, when traditional development techniques are used, faults de- tected informally by the programmer do not count toward the testing fault rate. When Cleanroom is used, faults detected during the inspections and other nonexecution- based testing procedures that precede compilation are recorded, but they do not count toward the testing fault rate. ' A report on 1 7 Cleanroom products appears in gLinger, l 9941. For example, Cleanroom was used to develop the 350,000-line Ericsson Telecom 0532 operating system. The product was developed in l 8 months by a team of 70. The testing fault rate was only l .0 faults per KLOC. Another product was the prototype automated documentation system described previously', the testing fault rate was 0.0 faults per , KLOC for the l 820-line program. The 1 7 products together total nearly l million lines of code. The weighted average testing fault rate was 2.3 faults per KLOC, which Linger describes as a remarkable quality achievement. That praise certainly is no exaggeration. 1+ 12 poTzNTIAt pRoekzM s H:N TzsTlxo , I (>BJZ<TS One of the many reasons put forward for using the object-oriented paradigm is that it reduces the need for testing. Reuse via inheritance is a major strength of the paradigm; once a class has been tested, the argument goes, there is no need to retest it. Further- more, new methods defined within a subclass of such a tested class have to be tested, but inherited methods need no further testing. ln fact. both claims are only partially true. In addition, the testing of objeets poses . certain problems that are specihc to object orientation. These issues are discussedhere. To begin, it is necessary to clarify an issue regarding the testing of classes and of objects. As explained in Section 7.7. a class is an abstract data type that supports inheritance, and an object is an instance of a class. That is, a class has no concrete realization, whereas an object is a physical pieee of code exeeuting within a specifk environment. Therefore, it is impossible to perform execution-based testing on aclass', only nonexecution-based testing, such as an inspection, can be done. ; : Information hiding and the fact that many methods consist of relatively few lines : ! of code can have a significant impact on testing. First consider a product developed using the structured paradigm . Nowadays. such a product generally consists of mod- ules of roughly 50 executable instructions. The interface between a module and the ' rest of the product is the argument Iist. Arguments are of two kinds, input arguments supplied to the module when it is invoked and output arguments returned by the m odule when it returns control to the calling module. Testing a module consists of Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. ' I 4*.:2 POTENTIAL PROBLEMS W HEN TESTING OBJECTS **3 i supplying values to the input arguments and invoking the module and then comparing , the values of the output arguments to the predicted results of the test. j ln contrast, a ûitypical'' object contains perhaps 30 methods, many of which are i! relatively small, frequentlyjust two or three executable statements gWilde, Matthews. ! and Huitt, 19931. These methods do not return a value to the caller but rather change i the state of the object. That is, these methods modify attributes (state variables) ofthe j object. The difhculty here is that. to test that the change of state has been performed ji lcorrectly, it is necessary to send additional messages to the object. For example, ! Iconsider the bank account object described in Section l .6. The effect of method j . deposit is to increase the value of state variable account balance. Howevers as a I II iconsequence of information hiding , the only way to test whether a particular deposit ( , action has been executed correctly is to invoke method determine balance both before j and after invoking method deposit and see how the bank balance changes. I 12 tThe situation is worse if the object does not include methods that can be invokedto j' , determine the values of all the state variables. One alternative is to include additional l j'' hods for this pu . rpose then use conditional compilation to ensure that they are 1 , I,1met unavailable except for testing purposes (in C++, this is achieved using #ifdeh. The : test plan (Section 9.6) should stipulate that the value ofevery state variable should be accessible during testing. To satisfy this requirement, additional methods that return 1I . the values of the state values may have to be added to the relevant classes during the è . ' . design phase. As a result, it will be possible to test the etfect of invoking a specitic i r ' E ) ' method of an object by querying the value of the applicable state variable. :2 . Surprisingly enough, an inherited method still may have to be tested. That is, ! even if a method has been adequately tested, the same method may require thorough E testing when inherited, unchanged, by a subclass. To see this Iatter point. consider : ! !th e class hierarchy shown in Figure l4. l2. Two methods are dehned in the base class ! RoodedTree, displayNodecontents and printRoutine, where method displcyNode- i ! Confents uses method printRoutine. Next consider the subclass BinoryTree. This subclass inherits method printRou- I tine from its base class RoofedTree. In addition. a new method, displayNodecon- j tents, is defined that overrides the method detined in RooiedTree. This new method 1g displayNodecontents uses Root- 1: ;still uses printRoutine. In Java notation, Binarylkee. - 1 . edTree.printRoutine. g Now consider the subclass BoloncedBinoryTree. This subclass inherits method ' 1 displayNodecontents from its superclass BinoryTree. However, a new method print- lj; Routine is defined that overrides the one defined in RootedTree. When displayNode- : Contents uses printRoutinewithin the context of BclontedBinoryTree, the scope rules of C++ andlavaspecify that the local version ofprintRoutine is to be used. ln Java no- tation. when method BinaryTree.displayNodecontents is invoked within the lexical scope of BolontedBinoryTree, it uses method BalancedBincryTree.printRoutine. Therefore, the actual code (method printRoutine) executed when displayNode- l k ' Contents is invoked within instantiations of BinoryTree is different from what is : : I executed when displayNodecontents is invoked within instantiations of Bclcnced- BinoryTree. This holds notwithstanding that the method displayNodecontents itself i is inherited. unchanged. by BoluncedBinoryTree from BincryTree. Therefore, even j i I ' : i : Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. 4*Q t H A p T E R 1* * Im plem endofion Phose closs RootedTree l void displayNodecontents (Node a); void printRoutine (Node b); // // lnethod displayNodecontents uxex ,r,c?/?(?J printRoutine // l closs BinoryTree extends RooledTree l void disployNodecontents (Node a); // // method displayNodecontents dtljined ?'?? tllix t /l.s'x ttses // nlethtld printRoutine itlllei.itcdh-onl closs Roo/dTree // lJ ' closs BolcncedBinoryTree extends BinoryTree . ( , void printRoutine (Node Ia); . E // : . // method displayNodecontents lillherited . ti-onl BinaryTree) uxex this . , // 10(.(11 T,c,o./t?r7 f!/' printRoutine Ik.?'?/?/?? closs BoloncedBincryTree // l Flgure IG IQ Java implementotion of tree hierarchy. : if method displayNodecontents has been thoroughly tested within a BinoryTree object, the method has to be retested from scratch when reused within a Boloncei- ' ' BinoryTree environment. To make matters even more complex, there are theoretical reasons why it needs to be retested with different test cases (Perry and Kaiser, 19901. It must be pointed out im mediately that these com plications are not a reason to abandon the object-oriented paradigm. First, they arise only through the interaction ' ' of methods (displayNodecontents and prinfRoutine in the example). Second. it is possible to determine when this retestinu is needed îl-larrold, M cGrecor. and Fitz- l . - *-' . - *-'' ' , . patrick, l 9921. Suppose an instantiation ot a class has been thoroughly tested. Any 7 ' new or redefined m ethods of a subclass then need to be tested, together with methods flagged for retesting because of their interaction with other methods. In short, then, . ' the claim that use of the object-oriented paradigm reduces the need for testing Iargely is true. Some management implications of module testing now are considered. Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. 1*.4* W HEN To REWRITE RATHIR THAN DEBUG A M ODULE **3 I*.la ANA/EM ENT A :PKtTS O F opuk: 1 TESTIN* 1 l' r L ' J . 1 An important decision that must be made during the development of every module T : j' d On testing that module. As with so jl 'is how much time, and theretore money. to spen ' j . many other economic issues in software engineering, cost-beneht analysis (Section . . j: j5 . 2) can play a useful role. For example, the decision as to whether the cost of cor- jl t ' i ds the benetit of the assurance that a specihc product satishes 1rectness prov ng excee . 1 .i ts specifications can be decided on the basis of cost-benefit analysis. Cost-beneht Ij analysis also can be used to compare the cost of running additional test cases against 1 j ' the cost of failure of the delivered product caused by inadequate testing. 1 j 'There is another approach for determining whether testing of a specific module j! ; . should continue or it is Iikely that virtually al1 the faults have been removed. The tech- ! niques of reliability analysis can be used to provide statistical estimates of how many IE 1, Ifaults remain . A variety of different techniques have been proposed for determining l statistical estimates of the number of remaining faults. The basic idea underlying ; ) ' : 1 . these techniques is the following. Suppose that a module is tested for l week. On j Monday, 23 faults are found, and 7 more on Tuesday. On Wednesday, five more faults $ I are found. two on Thursday, and none on Friday. Because the rate of fault detection I 9 decreases steadily from 23 faults per day to none, it seems likely that most faults have ' t ; been found, and testing that module could be halted. Determining the probability that 1 there are no more faults in the code requires a level of mathematical statistics beyond ' j that required for readers of this book. Details therefore are not given here; the reader : who is interested in reliability analysis should consult (Grady, 19921. ! . ' i ( t ( l ' t! 1*.1* HKN To R Ew RIT: THER THAN D 'BUG 3 : : h A M opuk: 'tit 14 When a member of the SQA group detects a failure (erroneous output), as stated 1 : : I :pre viously, the module must be returned to the original programmer for debugging, j that is, detection of the fault and correction of the code. On some occasions, it is j1: . . preferable forthe module to be thrown away and redesigned and recoded from scratch, ieither by the original programmer or by another . possibly more senior, member of the development team. To see why this may be necessary. consider Figure l 4. l 3. , The graph shows the counterintuitive concept that the probability of the existence of ,'. more faults in a module is proportional to the number of faults already found in that module (M yers, 19791. To see why this should be so, consider two modules, m l and @l ! m2. Suppose that both modules are approximately the same length and both have I . ' . . been tested for the same number of hours. Suppose further that only 2 taults were . - i ' detected in m 1 , but 48 faults were detected in m2. It is likely that more faults remain to be rooted out of m2 than out of ml . Furthermore, additional testing and debugging ! l ' j Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. *** t H A p T E * '* * Im plem enloelon Phose 1 . Probability of existence of additional faults ' 0 Number of faults already found t Flguee l*.la Groph showing that probability that faults still are to be found is proportional to number of faults already . defected. E t ' ' j . ' of m2 is likely to be a lencthv process. and the suspicion that m2 is still not perfect ' ' '' *-'' œ' *. ' * 2 . will remain. In both the short run and the long run, it is pre ferable to discard m2, ' ' redesign it, and recode it. i The distribution of faults in modules certainly is not unitbrm . Myers cites the j example ot faults tound by users in 05/370 îMyers, l 9791. It was tound that 47 percent ) of the faults were associated with only 4 percent of the modules. An earlier study by Endres regarding internal tests of DOS/VS (Release 28) at IBM Laboratories, Böblingen, Germany, showed similar nonuniformity gEndres, 19751. Of the total of 5l2 faults detected in 202 modules, only I fault was detected in each of l 12 of the modules. On the other hand, some modules were found to have 14, 15. l9, and 28 faults, respectively. Endres points out that the latter three m odules were three of the Iargest modules in the product, each comprising over 3000 lines of DOS macro assem bler language. And the module with 14 faults was a relatively sm all module previously known to be very unstable. This type of module is a prime candidate for being discarded and recoded. The way for management to cope with this sort of situation is to predetermine the maximum number of faults permitted during development of a given module; when that maximum is reached the module must be thrown away, then redesigned . and recoded, preferably by an experienced software protkssional. This m axim um will ; vary from application area to application area and from module to module. Aher all, I the m axim um perm itted num ber of faults detected in a module that reads a record from i a database and ehecks the validity of the pa14 number should be far smaller than the ( ' . : number of faults in a complex module from a tank weapons control system that must ! coordinate data from a variety ofsensors and direct the aim ofthe main gun toward the intended target. One way to decide on the maximum fault figure for a specific module is to examine fault data on similar modules that have required corrective maintenance. But whatever estim ation technique is used, management must enstlre that the m odule is scrapped if that figure is exceeded (but see the Just in Case You W anted to Know box on page 465). Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. ' y , Ilaê AIR Gou- ET CASE 5TuDY: BmcK-Box TEST CASES **5 : ! ' j Jus' lN G sz You W ANU P To Kwow I The discussion regarding the maximum permitted num- of faults detected afterthe product has been delivered to Iber Of faults detected during development of a module the client should be zero for al1 modules of all products . j j isely that: the maximum number permitted That is. it should be the aim of every software engineer : imeans prec : during development. The maximum permitted number to deliver fault-free code to the client. ! ! I I' 5 L j1 1 1 1 - ! j . 'i1 ë 1 : ' ' i 1 2 l 1*.15 CA SK T@@t: F@ R THE IM PKEM ENTATI@N lj; k PHM K l l g : 'CASE tools for the implementation phase were discussed in some detail in Section : lI 5.6. For reasons of space. that material is not repeated here. I t i . ! ' 1*.1* A 1R G OURM KT ZA:E STUPY: B. AtK-B@X ' TZST tAses ë E i Figtlre 14. 14 contains sample black-box test cases for the Air Gourmet product', the ; l lete Set aPPCaFS ill Appendix J. The test cases are of two types: those based i 1 ,COmP ( on equivalence classes and boundary value analysis and those based on functional . testing. Turning initially to equivalence classes and boundary value analysis, the tirst E f hve test cases are chosen from equivalence classes to check that a firstName , 1set o I of a passenger consists of between l and 15 characters. The fifth equivalence class t : ; 'retlects that the requirements do not state what should happen if a name consists of l more than 15 characters. The same set of equivalence classes are equally applicable l ' to the IastName of a passenger. l . I ' When test cases show up shortcomings in the specifications, it is necessary to go 1 back and modify the specilications. ln the Air Gourmet product, the specitications iI should state that an error message should be printed if the user attempts to enter a I ' 1name longer than l 5 characters . Because the modihcations needed to correct the faults : in the specihcations revealed by the black-box test cases are straightforward, they are I i itted here. l !Om . : The second set of four equivalence classes are used to check that a reservotionlD : ists of exactly six alphabetic characters. Similar equivalence classes are used to ! 1cons 1 select test cases to check other statements in the specifications; the full set appears in I E ' Appendix J. ' : Turning now to functional testing, 2 1 functions derived from the specihcation l I .' document are Iisted in Figure l 4 . I 4. l 1: ! ' ! Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. i E quivalence classes and boundary value analysis Equivalence classes for firstNome and lustName: ' I . < l character Error . 2. t character Aeceptable ' 3. Between 1 and 15 characters Atrceptable 7 4, 1 5 characters Acceptable 5 15 characters Llnspecified . > Equivalence classes for reservationlD: 1 . < 6 characters Error . 2. > 6 characters Error . 3. 6 characters (not all alphabetic) Error ' 4. 6 characters (all alphabetic) Acceplable Functional Analysis Making a reservation: 1 . Make a reservation where the reservation ID already exists. 2. M ake a reservation where the seat number for a particular flight already is reserved. ' . 3. M ake a reservation where the passenger ID already exists in the database. ! 4. M ake a reservation where the passenger ID does not already exist in the database. i ' ' ( . '2 checking in a passenger: ' ;J . 5. Check in a passenger whose reservation ID cannot be found in the database. ' : 6. Check in a passenger whose reservation ID can be found in the database. . ' 1 . ( JS canning the special meals list: ' ' 7. Scan the special meals list for a flight date and flight number that do not exist in the database. .i 1 8. Sean the special meals list for a flight date and Qight number that do exist in the dalabase. ' . 2 Scanning a postcard: ' . ë 9. Scan a returned postcard where 1he reservation ID cannot be found in the database. ) .l0 . Scan a returned postcard where the reservation ID can be found in the database. Displaying reports: l 1 . For each report, attempt to display the report where the start date (e.g MAR/l(FI995) is later than the end date (e.g., MAR/I 0/l 990). ' I 2. For the caterer and onboard reports, attem pt to display a report tbr a flight date and flight number that do not exist in the database. 13. Display the 24-hour caterer list. ' t4. Display the oaboard meals list. l 5. Display the not-loaded report when there are no passengers that have meals not loaded more than once. . l6. Display the not-loaded report when several passengers have meals not loaded rflore than once t tr this also when some of the reservations occur on the same date) ( y . l 7. Display the report on poor-quality meals when no passengers in the database have Ioaded meals . with a perceived quality less than 5. ' l 8. Display the report ()n poor-quality meals when several passengers in the database have Ioaded , meals with a perceived qualily less than 5. ' : l 9 . Display the report on percentages. i ' 20. Display the report on Iow-sodium meals when there are no low-sodium meals in the database. . 2 1 . Display the report on Iow-sodium meals when several Iow-sodium meals are in the database . ' Flgure 18 1* Sample black-box test cases for the Air Gourmet product. 466 .: Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. 7 l CHAPTER REVIEW *@7 7 It is important to be aware that these test cases could have been developed as ; 1 soon as the specifications were complete because. as shown in this section, black-box ( test cases can be used to highlight faults in the specifications. A major component of ( ' every test plan should be a stipulation that black-box test cases be drawn up as soon 1! ' as possible (Section 9.6). lt a contract has been signed for the project as a whole. then i ! , this will be as soon as the specification document has been approved. Otherwise, the j ; he product is signed once the client has agreed to the duration l @contract forcompleting t l and cost estimates , that is. at the end of the specitication phase. The black-box test j 1, cases then can be drawn up, for use by the SQA group during the implementation and Il intecration ohase. l i %-'''' * ) ' 7 l : ! ' I 1 l I<1F CHAtLEN/E: @F THK IMPLEMKNTATI@N l) 1: I ' PHASE i ' I I iParadoxically , a major challenge of the implementation phase has to be met in the phases that precede the implementation phase. As explained in Chapter 8. code reuse ' is an effective way of reducing software development cost and delivery time. However. 2 it is hard to achieve code reuse if it is attempted as late as the implementation phase. ' 1q 2 !For example , suppose that the decision is made to implement a product in lan- . g guage L. Now, after half the modules have been implemented and tested, management ; ' . : deeides to utilize package P for the graphical user interfaces of the software product. , No matter how powertul the routines of F may be, if they are written in a language ) that is hard to inlerface with L then they cannot be reused in the software product. j'' Even if language interoperability is not an issue, there is little point in trying to ( I reuse an existing module unless the item to be reused hts the design exactly. M ore , lwork may be needed to modify the existing module than to create a new module from j scratch. , I(!M odule reuse therefore has to be built into a software product from the very ' ''g beginning. Reuse has to be a user requirement as well as a constraint of the specitica- 11 tion document. The sottware project management plan (Section 9.4) must incorporate l : Jreusc . Also. the design document m ust state which nlodules are to be implemented j and which are to be reused. '' So, as stated at the beginning of this section, even though module reuse is an l ! important challenge of the implementation phase, module reuse has to be incorporated ji nto the requirements, specification, and design phases. l i ; I I l l ' iQHAPTZR RzvlEw i ' . . 1 This chapter presents various issues relating to the implementation of a product by : a team. These include choice of programming language (Section l 4. l ). The issue of ! ! j 'L 1 ' ) I l Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. **@ t H A @ T E R 14 @ Im plemenlo'ion Phose fourth-generation Ianguages is discussed in some detail in Section 14.2. Good pro- ' gramming practice is described in Section 1 4.3, and the need for practical coding . f standards is presented in Section l 4.4. Then, comments are made regarding reuse of . modules (Section 1 4.5). Test cases mustbe selected systematically (Section 14.6). Var- ious black-box, glass-box, and nonexecution-based testing techniques are described (Sections 14.7, 14.8, and 14.9, respectively) and then compared (Section 14. 10). The Cleanroom technique is described in Section 14. 1 l . Testing objects is discussed in . Section l4. l 2, followed by a discussion of the managerial implications of module testing (Section l4. 1 3). Another problem is when to rewrite rather than debug a mod- ' ' ule (Section l4. l 4). CASE tools for the implementation phase are mentioned next (Seetion l 4. l 5). ln Section l 4. l 6 black-box test cases for the Air Gourmet Case Study are discussed. The chapter concludes with an analysis of the challenges of the . implementation phase (Section I 4. l 7). . 14. FoR FupTHzp R:AplNok A wide-ranging source of intbrmation on 4GLs is l Martin, 19851. The attitudes of 43 ' organizations regarding 4GLS are reptlrted in gGuimaraes, l 9851. (Klepper and Bock, 14' I 9951 describes how McDonnell Douglas obtained higher productivity with 4GLs 14. l I than with 3GLs. 14 .' ! . i Excellent books on good programming practice inelude (Kernighan and Plauger, ' q ' : g 1974. and Mcconnell. 19931. 4. i * -Y' 4Probably the most important early work on execution - based testing is (Myers, . . 14,1 979 1 . A comprehensive source ot intormation on testing in general is lBeizers 19901. 14,Functional testing is described in gldowden , I 9871., structural techniques are compared in Lclarke. Podgurski, Richardson, and Zeil, l 9891. Black-box testing is described in detail in (Beizer, l 9951. The design of black-box test cases is presented in (Yamaura, 1*, l 998 1. The relationship between the various coverage measures of structural testing and software quality is discussed in gl-lorgan, London. and Lyu, 19941. A fonnal approach to glass-box testing is described in jstocks and Carrington, l 9961. 14. Cleanroom is described in (Linger, l 9941. The use of Cleanroom during the main- tenance phase is presented in ësherer, Kouchakdjian. and Arnold, 1 9961. A criticism #.1 of Cleanroom is given in I Beizer, I 9971. A good introduction to software reliability is IM usa and Everett, l 9901. In addi- t tion, the prtlceedings of the annual International Sym posium on Software Reliability . a. 1 . . -'+* ' . Engineering contain a wide variety ot articles on sottware reliability. Reliability also l *.1 i is discussed in articles in the May l 995 issue of IEEE Software and the November 1 996 issue of IEEE Ct?r/?rl//c?: X*1 The proceedings ofthe International Symposia on Software Testing and Analysis *.1 ' cover a particularly broad range of testing issues. *.1 A survey ()f different approaches to the testing of (lbjects can be found in y'Turner, l 9941. Two important papers on the subject are lperry and Kaiser, 1990, and Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. q E PROBLEMS *ê@ i Harrold, M cGregor, and Fitzpatrick, 1 9921. gBeizer. 19951. mentioned previously, 1 ' also covcrs black-testing of object-oriented software. The September l 994 issue of the Communications of the ACM contains a number of articles on testing object- oriented software. ' With regard to the metrics for the implementation phase, Mccabe's cyclomatic : i lexity was first presented in tMccabe, 19761. Extensions of the metric to the !i. Ccomp j design phase appear in gMccabe and Butler, 19891. Articles questioning the validity l )I ' $ ' of software science and cyclomatic complexity include gshepperd, 1988b., Weyuker, 1: 1 ' j : :1988b. , and Shepperd and Ince, 19941. M etrics for managing code inspections are j described in (Barnard and Price. 19941. l! ' I ( . ' j - g J . .:f I .jI . PR@BLKM S 'i I I . ! l 14.1 Your instructor has asked you to implement the Broadlands Area Children's Hospital : . !product (Appendix A) . W hich Ianguage would yOu choose for im plem enting the f ' iproduct and why? Of the various languages available to you , list their beneits and ;i their costs. Do not attempt to attach dollar values to your answers. ! I : j14.2 Repeat Problem 14 . 1 for the elevator problem (Section l l .6. 1). 1 . ( 114 . 3 Repeat Problem 14. 1 for the automated library circulation system (Problem 8.7). . 14.4 Repeat Problem l 4. 1 for the product that determines whether a bank statement is 2 correct (Problem 8.8). : . y k . . j14.5 Repeat Problem 14. 1 for the automated teller machine (Problem 8.9). 2 ! 14.6 Add prologue comments to a module you recently wrote. ' 14.7 How do coding standards for a one-person software production company differ from ' ! I .j' - !those in organizations with 300 software professionals : l '!14 . 8 How do coding standards for a software company that develops and maintains soft- I . h j .ware for intensive-care units difter from those in an organization that develops and , j . maintains accounting products? 1 , 14.9 Set up black-box test cases for Naur's text-processing problem (Section 6.5.2). For 1 each test case, state what is being tested and the expected outcome of that test case. ly J 14.1Q Using your solution to Problem 6. 15 (or code distributed by your instructor), set up ë statement coverage test cases. For each test case, state what is being tested and the i I expected Outcome Of that test case. E 14.1 1 Repeat Problem l4. 10 for branch coverage. j 14.12 Repeat Problem l4. 10 for all-dehnition-use-path coverage. jE 14.13 Repeat Problem 14. 10 tor path coverage. ; 14.14 Repeat Problem l4. l 0 for linear code sequences. 1 ' j 14 1 5 Draw a oowchart of your solution to Problem 6. l 5 (or code distributed by your lj instructor). Determine its cyclomatic complexity. lf you are unable to determine the ' number of branches, consider the Eowchart as a directed graph. Determine the number : ' ; . i ' ( i Please purchase Image To PDF Converter on http://www.verypdf.com/ to remove this message, thank you. [...]... s y ' Q qu t ytse de oel etd : 7 B t u i e ti on ot p mplmenai d omon itgrt n(e t 1 12) ne ai S ci 5., o on F liolt auts oi on g t tal r s bl moduesar oenil eua e y l e Mci de inf l sow u lt or sg aut h p ae s ad qu ey tse e atl e td ;' $' I ;j ' 1 : ' E 1 : S dwih i eme tto an an c mpl na in d itgrt n(e t n1 12) ne ai S ci 5 o o F liolt out s a i on - Majrdei f l sow u e l o sgn aui h p ar s y... rino ted sg d c me be t , n rga r o e be t I h eso f h e in o u n tt u e b po rmme l obe tols n ame sg t o jc 02 p sigfu ai s d y rga r , jc on e ds sa e o be t asn o r a gum en s bu t ve son oft de i doc r t , t he r i he s gn ument i us by pr amm e 2 saes aton ed ogr r tt k ' cl ryt onl t eear ea l hal y hr gume saepasedt o2 pr em lket sc aiewh n nt r s o A obl i hi an rs e j ; l I rg t n i e i pe... mp o e l QA r u h r t e s h s i l o n u e h t h e t s k n peror t r f med ho oughl r or t mana roft eSQA gr ps dha rs ny Theef e,he ge l n ou houl ve e po ' a ch ange i made t onl one copy of t desgn doc e ,wihouti br i al s o y he i um nt t nt m ng l t mem be soft de opm en gr Bo h p o r mme sk o t a t e a ei te he r he vel t oup t r g a r n w h th y r n h ' s biiy f a 1a pe s ofi e aton t tng.He... t 1 ; j i j f l tpo ental ules t i On eteSQA g o p a s r sma a e n t t h p o u t a h n l a y hn c h r u s u e n g me t ha t e r d c c n a de n ti g t a epanc tse sc t ow a i,tepr t(ha i,tecodepl alt doc he cc t e e tr an hr t t h oduc t t s h us l he umenaton)i han t t clentor zai f ac eptnc t tng t i s ded o he i gani ton or c a e esi ' : l kI ' ; ' '( , l ë 15 5 A ttKPT ANt: TESTI N/ The pur e ofa... c be tb sd on e t s cha e ps ai an i or tonhi ngcanbea ev e iy u s nca ulton d nf mai di chi ed asl How woul you d i pl m e pol phim a dynam i bi ng' m e nt ymor s nd c ndi ? 51 ( s St Towha exenti t docume ai oft c oft i e t i 3 Ca e udy) t t s he ntton he ode he mplmenaton ofSe i 1 1 i de e? M a an ne s a y addii cton 5 3 na quat ke y ce s r tons l i l: jh : , ! t ' 1 1 il jl ; j '' j' l j j ,... e e a e t ee mai r onst m a ng c ngest a pr ct r r hr n eas br ki ha o odu : l The fr tr as i t corec f uls whet er s ecii aton f uls desgn f t , is e on s o r t a t, h p fc i a t , i auls c ng f t ,document ton f uls ora ot rl s tff t.Thi i tr e odi auls a i a t , ny he ype ) auls s s em d c r tv l nt or ec i e nai enanc Sur i i yenough, sudy 0t69or ni atonss w e e prsngl at - ga z i ho d t tmait... nges a s m us be c ke Experie i t tn t ef e i a lo t hec d ts n es i g her or s n a tonalpr r st f m a nt nanc Fi l i i es entalt tt mai t nc ddii e equi ie or i e e naly, t s s i ha he n ena e pr amm erdoc e eve y cha The pr ce ng dicus i r a e t corec i e ogr um nt r nge e di s son el t s o r tv m a nt ce rt tt k, he m a nt na pr am merprmarl m us be as b i enan Fo ha as t i e nce ogr i iy t uper ;... s h et h t a e on Th r i a oh rraonwh fut usal aen tf e i daey l amo t ee s n te e s y a ls u l r o i d mme itl.t l s y x al ysi ch ert mak anumberofchan ,t tt al,c wa s eap o e ges es hem l hangete doc nh ume tton,a d i t lt ne veri t n t pe f m ea cha s r ey t ti, ai n nsal he w son ha o ror ch nge epaatl, es t d c me ti, i t lt ne v s on.t en r pea t e ie c e f t ne c o u n t nsal he w er i h e... chan why i efec he nges n ri ara ald s rpton t s ged, t wa c a g d b wh n wh n mu t ea d dt tepolg ec mme t o a y s h n e y om a d e s b d e o h r o u o ns f n cha d modul I ne s a y d i ors ii ton document al o a e c nge e f ce s r , es gn pec fca i s s r hange A d s m ia s tofs e i t l i lr e t ps s olowed when pe t m i perec i e ora i m a nt nce; r or ng f tv daptve i ena t e onI r ldif enc i . successful. There are two : main types of software, commercial off-the-shelf software (Section 2. l ), and custom software. The aim when developing COTS software is to ensure that the product is '. a one-person software production company differ from ' ! I .j' - !those in organizations with 300 software professionals : l '!14 . 8 How do coding standards for a software company. introduction to software reliability is IM usa and Everett, l 9901. In addi- t tion, the prtlceedings of the annual International Sym posium on Software Reliability . a. 1 . . -'+* ' . Engineering