120 likes | 236 Views
Interleaving static and dynamic analyses to generate path tests for C functions. Nicky Williams, Bruno Marre, Patricia Mouy. Objective. automation of the test process for fast , rigorous , systematic testing of rapidly evolving software and a quantifiable increase in confidence
E N D
Interleaving static and dynamic analyses togenerate path tests for C functions Nicky Williams, Bruno Marre, Patricia Mouy
Objective • automation of the test process for fast, rigorous, systematic testing of rapidly evolving software and a quantifiable increase in confidence • test input generation must be automated and it is possible !
Others aim: make generation more automatic criteria: branch/user-defined coverage existing tests / spec. test-case => test objective in CFG staticdynamic symbolic executionexecute case => path predicate path covered constraint solving heuristical optimisation problems loops, alias number of executions complexity termination PathCrawler aim:fully automatic criteria:all-paths dynamic execute case path covered static => path predicate rest input domain constraint solving combines the advantages of static and dynamic approaches Structural test-case generation : a new approach
PathCrawler : path-test generator • Inputs :sourcecode and definition domain of program • Output : tests covering 100% feasible execution k-paths • An original approach : • instead of CFG, iteratively construct execution path tree • only analyse individual feasible (complete) paths with unrolled loops (can take aliases into account) • use the structure of covered paths to search efficiently for the next test-case using constraint logic programming • Application : imperative languages, sequential software • prototype for C • status: imprecision current treatment floats • cast, union,… not treated yet
PathCrawler : input domains D0 : program definition domain
PathCrawler : input domains D0 : program definition domain case1
test1 PathCrawler : input domains D0 : program definition domain case1 path1 D1
test1 PathCrawler : input domains D0 : program definition domain case1 path1 case2 D1
test1 test2 PathCrawler : input domains D0 : program definition domain D2 path2 case1 path1 case2 D1
test1 test2 PathCrawler : input domains D0 : program definition domain D2 path2 case1 path1 case2 D1 case3
Future directions • (PhD Patricia Mouy) making use of specifications to: • avoid combinatorial explosion due to function calls • automatically generate an oracle if user cannot supply it • structurally cover functional domains to detect missing paths • Combining path testing and static analysis to measure Worst Case Execution Time • Path testing of reactivesystems • Fault location from intersections of faulty paths • Partial proof