(c)2007MauroPezzèMichalYoung解析.pptVIP

Code-based Regression Test Selection Observation: A test case can’t find a fault in code it doesn’t execute In a large system, many parts of the code are untouched by many test cases So: Only execute test cases that execute changed or new code (c) 2007 Mauro Pezzè Michal Young Ch 22, slide * Control-flow and Data-flow Regression Test Selection Same basic idea as code-based selection Re-run test cases only if they include changed elements Elements may be modified control flow nodes and edges, or definition-use (DU) pairs in data flow To automate selection: Tools record elements touched by each test case Stored in database of regression test cases Tools note changes in program Check test-case database for overlap (c) 2007 Mauro Pezzè Michal Young Ch 22, slide * Specification-based Regression Test Selection Like code-based and structural regression test case selection Pick test cases that test new and changed functionality Difference: No guarantee of independence A test case that isn’t “for” changed or added feature X might find a bug in feature X anyway Typical approach: Specification-based prioritization Execute all test cases, but start with those that related to changed and added features (c) 2007 Mauro Pezzè Michal Young Ch 22, slide * Prioritized Rotating Selection Basic idea: Execute all test cases, eventually Execute some sooner than others Possible priority schemes: Round robin: Priority to least-recently-run test cases Track record: Priority to test cases that have detected faults before They probably execute code with a high fault density Structural: Priority for executing elements that have not been recently executed Can be coarse-grained: Features, methods, files, ... (c) 2007 Mauro Pezzè Michal Young Ch 22, slide * (c) 2007 Mauro Pezzè Michal Young Ch 22, slide * Summary System testing is verification System consistent with specification? Especially for global properties (performance, reliability) Acceptance testing is validation Incl