 White-Box Testing White-Box Testing  White-Box Testing White-Box Testing  Control flow graph (CFG) Control flow graph (CFG)  Flow Graph Notation.

  • Published on
    16-Jan-2016

  • View
    216

  • Download
    0

Embed Size (px)

Transcript

  • White-Box TestingWhite-Box TestingControl flow graph (CFG)Flow Graph NotationData Flow TestingMutation TestingAdvantages Of White Box TestingDisadvantages of white box testing

  • Uses the control structure part of component-level design to derive the test casesThese test casesGuarantee that all independent paths within a module have been exercised at least onceExercise all logical decisions on their true and false sidesExecute all loops at their boundaries and within their operational boundsExercise internal data structures to ensure their validity

    Bugs lurk in corners and congregate at boundariesBACK

  • There exist several popular white-box testing methodologies:control flow graph:Statement coverageBranch coveragePath coverageData flow based testing:Loop testingNested Loops Concatenated Loops Unstructured Loopsmutation testing:BACK

  • A control flow graph (CFG) describes: the sequence in which different instructions of a program get executed. the way control flows through the program.

  • Number all the statements of a program. Numbered statements: represent nodes of the control flow graph.An edge from one node to another node exists: if execution of the statement representing the first node can result in transfer of control to the other node.

  • int f1(int x,int y){ while (x != y){ if (x>y) then x=x-y; else y=y-x; } return x; }

  • 123456

  • Statement coverage methodology:design test cases so thatevery statement in a program is executed at least once. The principal idea: unless a statement is executed, we have no way of knowing if an error exists in that statement

  • Based on the observation:an error in a program can not be discoveredunless the part of the program containing the error is executed. Observing that a statement behaves properly for one input value:no guarantee that it will behave correctly for all input values

  • int f1(int x, int y){ 1 while (x != y){2 if (x>y) then 3 x=x-y;4 else y=y-x;5 }6 return x; }

    NOTE:- By choosing the test set {(x=3,y=3),(x=4,y=3), (x=3,y=4)}all statements are executed at least once.

  • Test cases are designed such that:different branch conditionsgiven true and false values in turn. Similar to code coverage, but strongerTest every branch in all possible directionsIf statementstest both positive and negative directionsSwitch statementstest every branchIf no default case, test a value that doesn't match any caseLoop statementstest for both 0 and > 0 iterations

  • White-box testing technique proposed by Tom McCabeEnables the test case designer to derive a logical complexity measure of a procedural designUses this measure as a guide for defining a basis set of execution pathsTest cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing

  • A circle in a graph represents a node, which stands for a sequence of one or more procedural statementsA node containing a simple conditional expression is referred to as a predicate nodeEach compound condition in a conditional expression containing one or more Boolean operators (e.g., and, or) is represented by a separate predicate nodeA predicate node has two edges leading out from it (True and False)An edge, or a link, is a an arrow representing flow of control in a specific directionAn edge must start and terminate at a nodeAn edge does not intersect or cross over another edgeAreas bounded by a set of edges and nodes are called regions

  • *12 034567891011 1 2 3 4 6 7 8 5 91011R1R2R3R4FLOW GRAPH 0

  • Defined as a path through the program from the start node until the end node that introduces at least one new set of processing statementsMust move along at least one edge that has not been traversed before by a previous pathBasis set for flow graph on previous slidePath 1: 0-1-11Path 2: 0-1-2-3-4-5-10-1-11Path 3: 0-1-2-3-6-8-9-10-1-11Path 4: 0-1-2-3-6-7-9-10-1-11The number of paths in the basis set is determined by the cyclomatic complexity

  • Provides a quantitative measure of the logical complexity of a programDefines the number of independent paths in the basis set and the number of tests that must be conducted to ensure all statements have been executed at least onceCan be computed three waysThe number of regionsV(G) = EN+2, where E is the number of edges and N is the number of nodes in graph GV(G) = P+1,where P is the number of predicate nodesResults in the following equations for the example flow graphNumber of regions = 4V(G) = 14 edges 12 nodes + 2 = 4V(G) = 3 predicate nodes + 1 = 4

  • Using the design or code as a foundation, draw a corresponding flow graphDetermine the cyclomatic complexity of the resultant flow graphDetermine a basis set of linearly independent pathsPrepare test cases that will force execution of each path in the basis set

  • 1 int functionY(void) 2 { 3 int x = 0; 4 int y = 19; 5 A: x++; 6 if (x > 999) 7 goto D; 8 if (x % 11 == 0) 9 goto B;10 else goto A;

    11 B: if (x % y == 0) 12 goto C;13 else goto A;

    14 C: printf("%d\n", x);15 goto A;

    16 D: printf("End of list\n");17 return 0;18 }34567161789111214151310BACK

  • The techniques discussed so far have all been based on "control flow"we can also design test cases based on "data flow(how data flows through the code)Some statements "define" a variables value (variable definition)Variable declarations with initial valuesAssignmentsIncoming parameter valuesSome statements "use" variables value (variable use)Expressions on right side of assignmentBoolean condition expressions

  • A white-box testing technique that focuses exclusively on the validity of loop constructsFour different classes of loops existSimple loopsNested loopsConcatenated loopsUnstructured loopsTesting occurs by varying the loop boundary valuesExamples: for (i = 0; i < MAX_INDEX; i++) while (currentTemp >= MINIMUM_TEMPERATURE)

  • Skip the loop entirelyOnly one pass through the loopTwo passes through the loopm passes through the loop, where m < nn 1, n, n + 1 passes through the loopn is the maximum number of allowable passes through the loop

  • Start at the innermost loop; set all other loops to minimum valuesConduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values; add other tests for out-of-range or excluded valuesWork outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to typical valuesContinue until all loops have been tested

  • For independent loops, Concatenated Loops means combination of more than one loopIn concatenated loops , testing depends upon interdependence among loopsIf loops are not interdependence, then they should be tested in the someway as nested loops

  • Redesign the code to reflect the use of structured programming practicesDepending on the resultant design, apply testing for simple loops, nested loops, or concatenated loops BACK

  • The software is first tested:using an initial testing method based on white-box strategies.After the initial testing is complete,mutation testing is taken up.The idea behind mutation testing: make a few arbitrary small changes to a program at a time.

  • Each time the program is changed, it is called a mutated program the change is called a mutant. A mutated program:tested against the full test suite of the program. If there exists at least one test case in the test suite for which:a mutant gives an incorrect result, then the mutant is said to be dead.

  • If a mutant remains alive: even after all test cases have been exhausted, the test suite is enhanced to kill the mutant. The process of generation and killing of mutants: can be automated by predefining a set of primitive changes that can be applied to the program. The primitive changes can be:altering an arithmetic operator, changing the value of a constant, changing a data type, etc.

    BACK

  • Testing can be commenced at an earlier stage. One need not wait for the GUI to be available.Testing is more thorough, with the possibility of covering most paths.

    BACK

  • Developers often test with the intent to prove that the code works rather than proving that it doesn't workDevelopers tend to skip the more sophisticated types of white box tests (e.g., condition testing, data flow testing, loop testing, etc.), relying mostly on code coverageAnd developers also tend to overestimate the level of code coverageWhite box testing focuses on testing the code that's there. If something is missing, white box testing might not help you.There are many kinds of errors that white box testing won't findTiming and concurrency bugsVolume and load limitationsEfficiency problemsUsability problems

    BACK

  • BACK TO INDEX

    ******

Recommended

View more >