SFTWRE TOOLS & METH
SFTWRE TOOLS & METH CSE 121
Popular in Course
verified elite notetaker
verified elite notetaker
verified elite notetaker
verified elite notetaker
verified elite notetaker
Popular in Computer Science and Engineering
This 16 page Class Notes was uploaded by Raphael Maggio on Saturday September 12, 2015. The Class Notes belongs to CSE 121 at University of California - Irvine taught by M. Rousseau in Fall. Since its upload, it has received 21 views. For similar materials see /class/201933/cse-121-university-of-california-irvine in Computer Science and Engineering at University of California - Irvine.
Reviews for SFTWRE TOOLS & METH
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 09/12/15
INF 111 CSE 121 Software Tools and Methods I m I J Lecture Notes for Fall Quarter 2007 Michele Rousseau Set 10 Announcements 0 Checkmate 0 Quiz 1 Will be returned on Wed 0 Quiz 2 Next Monday 102907 rum m 2 Previous Lecture 0 Testing Static Analysis nCode Walkthroughs 1 Inspections rum m 3 Today s Lecture 0 More on Testing 0 Static Analysis u Formal Verification o CoverageBased Testing Tunic in 6 Veri cation amp Validation revisited 0 Verification Are we building the product right Boehm The Software should conform to its speci cation 0 testing reviews walkthroughs inspections internal consistency consistency with previous step 0 Validation Are we building the right product The software should do what the user really requires ascertaining software meets customer s intent Tupi in Quality Assurance 5 Problems 1 Eliciting the Customer s Intent 0 Getting the Specs to meet the real needs 2 GA is inherently difficult 0 Systems can be complex making QA difficult to perform nAir Traf c Control 9 stringent performance a Medical Diagnosis System 9 Complex processing Tunic in a Quality Assurance 5 Problems 3 Management Aspects Who does what testing Are developers involved o How are bugs handled a What is the reward structure 4 QA Team vs Developers o O gt F lt m o 5 539 m fau ts age of com petition Viewed by Developers as Cumbersome de n let melust co 5 Can t test exhaustively Tupi in How QA would like the world to be ormal specs r llC lTl in la a Correctnessepiesewing transformatlorl I Code iii 9N ll Correctnessepiesewing transformatlorl l ill life i39ilformal di li39l Informal specifications Compilation by commercial compller imachine code l I Commerclal rmware E ll commerclal hardware Tupi in Unit Tests o Developer tests the code just produced ee s to ensure that the code functions property before reieasmg it to the other deveiopers o Benefits Knows the code oest Has easy access to the code o Drawbacks Bias n i trust my code n i aiways Write correct code thd spots o Possible Solutions utside es ers Waikthroughsinspections Tunic m Formal Veri cation 0 Techniques for proving consistency between two software descriptions I to prove consistency of specification o to prove correctness of implementation Correctness i Correct with respect to the speci cation rum m M Veri cation with Formal Specs User Neeee intunnzlly vainate mns39stency nemeen teens and requiremens heuwemems speemeamn inmrmzllyvelity mns39stency nemeen mun znnmtnnnzllequ znzy39zepmperies requirements NOTE may he mul ple levels at speci tz nn zn zppmplizteveli cz nn zlznystage znzy39ze loperies ntmn uelnten zoes ven consl n nenzen 5 2a znzy39ze mperies otmnnu es velitycnnsistenw nemeen speci tz n mm znnimplementa nn Testing with Formal Specifications UserNeeds system tsgnvh ven39ycnrlslstzlEY hemenlml emenhinn Indlnlmll Muninmens i imagine now a li39yconsis 1 mm a may newnimummm an em 39nn quotammo Sneci cldnn 2 3397quot quotEi23939im Forml Module Sneci cldons Swtem Software inpienenfam Topic in Formal Veri cation Validation i o Some shortcomings I does not snow otnef qualllleS n Perfurmace usability etc May not scale u only infonnai tecnniques fofvaiioating against userneeds suoiectto assumptions of proofsys efn only as good as fonnai specification Notthiai Meoious Not always cost effective o Generally used on a part of the system 2 Example Mathematically Based Verification Topic in Mathematically Based Veri cation 0 Must have formal specifications Notation must be consistent with mathematical veri cation techniques 0 The programming lang must have formal seman ics o This is an intensive process but Can verify correctness 0 Generally a Not cost effective for large systems Topic in Tools for Mathematical Veri cation 0 Can it be automated v Theorem provers nAssist in developing proofs v Usually work with a subset of the program A Not completely automated rum in we Testing Techniques So 0 We need to find a systematic approach to selecting of test cases that will lead to 39 accurate 0 acceptably thorough 0 repeatable identification of errors faults and failures rum in 17 Practical Issues 0 Purpose of testing w Fault detection A High assurance of reliability Performancestressload 1 Regression testing of new versions 0 Conflicting considerations 0 safety liability risk customer satisfaction resources schedule market windows an share 0 Test Selection is a sampling T technique m u choose a finite setf Fundamental Testing Questions 0 Test Criteria What should we test 0 Test Oracle Is the test correct 0 Test Adequacy How much is enough 0 Test Process Is our testing effective Tuplc m 15 GS I1 6113 0 Testing must select a subset of test cases that are likely to reveal failures 0 Test Criteria provide the guidelines rules strategy by which test cases are selected actual test data conditions on test data requirements on test data o Equivalence partitioning is the typical approach a a test ofany value in agiven class is equivalent to a test ofany othervalue In that class ifa test case in a class reveals a failure then any other test case in that class should reveal the failure Tmspme approaches limit conclusions to some chosen2n c ass of errors andor failures Test Oracles oWhere does expected output come from A test oracle is a mechanism for deciding whethera test case execution failed or succeeded oCritical to testing oDifficult to create systematically oTypically done with a lot of guesswork Typically relies on humans great dependence on the intuition of testers oFormal specifications make it possible to T quot i tomate oracles 2 What Does an Oracle Do 0 Your test shows cos05 08775825619 0 You have to decide whether this answer is correct oYou need an oracle 1 Draw a triangle and measure the sides Look up cosine of 05 in a book 0 Compute the value using Taylor series expanswn 0 Check the answer with your desk T 39 39caltulator est Ade a uac Tells you when to stop testing 0 CoverageBased Testing Coverage metrics n wnen sumclent percentage ortne program structure nas peen exerclsed o FaultBased Testing Empirical assurance n wnen fallurestest curve flatten out 0 Error seeding n percentage of seeded faults found ls proportlonal to tne percentage of real faults found 0 ErrorBased Testin faults found in common are representative oftotal population offaults rum lEI 23 Equivalence Partitioning CoverageBased Testing 0 Flow Graphs 0 Control Flow 1 Partial order of Statement Execution a Data Flow 1 Flow of values from De nition to Variables Tuplc la n A Sample Program to Test 1 function P return INTEGER is 2 begin 3 XY lNTEGER 4 READOQREADW 5 while x gt 10 100 6 710 7 exit when X 10 8 end loop 9 if y lt 20 and then x mod 20then 10 Y Y 20 1 else 12 Y Y 720 II39 13 14 leturn Z X Y 15 READgtlt READY 11 else while x gt 10 any 12 v vizo x x 7 1o 39 exit when x 10 14 md lnnp 15 and F AllStatements Coverage 0 Select test cases such that every node in the graph is visited A Also called node coverage a Guarantees that every statement in the source once code is executed at least 0 Selects minimal number of test cases mo o 1m 9 rum 1 V AllStatements Coverage of P I Example allstatementsadeqllate es x 20 Y 10 ltZI3I4I5I5I715110114gt x 20 Y 30 ltZI3I4I5I5I715112114gt AllBranches Coverage 0 Select test cases such that every branch in the graph is visited a Guarantees that every branch in the source code is executed at least once 0 More thorough than AllStatements coverage v More likely to reveal logical errors Tum m AllBranches Coverage of P a ltZI3I4I55751014gt x 15 y 30 ltZI3I4I5I5I7I5I9IIZII4gt 10 AllEdges Coverage I 0 Select test cases such that every edge in the graph is visited nTakes complex statements into consideration treats them as separate nodes 0 More thorough than AllBranches coverage 7 o More likely to reveal logical errors rum m 31 AllEdges Coverage of P Example alledgesadequale test set x 20 Y 1 ltZ345575a5b1014gt x 5 y 3a ltZ345531214gt x 21 y 10 ltZI3I L7I5I7I55I7I5I93p9bllzll4gt AllPaths Coverage 0 Path coverage 0 Select test cases such that every path in the graph is visited l i 0 Loops are a problem n 0 1 average max iterations 0 Most thorough but is it feasible rum m 33 AllPaths Coverage of P Example allpaths adeqllate test set x 35 Y 10 P s Control and Data Flow Graph Subsumption of Criteria 0 C1 subsumes CZ if any C1adequate test T is also C2adequate A But some T1 satisfying C1 may detect 1 l i fewerfaults than some T2 satisfying 02 Tunic 1U 35 12 NF111 CSE 121 Discussion Session Week 10 Fall 2007 Instructor Michele Rousseau TA Rosalva Gallardo Agenda I Assignment 2 I Use Cases I Assignment 3 I Bonus Points I Questions ie State Diagram I Final Review Assignment 2 Use Case Diagram
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'