Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 180 views

    White Box Testing

    Uploaded by

    dR_nech
    White box testing, also known as glass box testing, is a test case design method that uses the internal structure of a program to design test cases. It allows testers to derive test cases that exercise all independent paths within a module, ensure all logical decisions are tested with true and false values, and validate internal data structures. The key aspects of white box testing covered in the document include basis path testing, control flow graphs, cyclomatic complexity, independent paths, condition testing, and data flow testing.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd

    White Box Testing

    Uploaded by

    dR_nech
    180 views17 pages
    White box testing, also known as glass box testing, is a test case design method that uses the internal structure of a program to design test cases. It allows testers to derive test cases that exercise all independent paths within a module, ensure all logical decisions are tested with true and false values, and validate internal data structures. The key aspects of white box testing covered in the document include basis path testing, control flow graphs, cyclomatic complexity, independent paths, condition testing, and data flow testing.

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    White box testing, also known as glass box testing, is a test case design method that uses the internal structure of a program to design test cases. It allows testers to derive test cases that exercise all independent paths within a module, ensure all logical decisions are tested with true and false values, and validate internal data structures. The key aspects of white box testing covered in the document include basis path testing, control flow graphs, cyclomatic complexity, independent paths, condition testing, and data flow testing.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    180 views17 pages

    White Box Testing

    Uploaded by

    dR_nech
    White box testing, also known as glass box testing, is a test case design method that uses the internal structure of a program to design test cases. It allows testers to derive test cases that exercise all independent paths within a module, ensure all logical decisions are tested with true and false values, and validate internal data structures. The key aspects of white box testing covered in the document include basis path testing, control flow graphs, cyclomatic complexity, independent paths, condition testing, and data flow testing.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 17

    White Box Testing

    by :
    Oerip S. Santoso
    Introduction
    • White Box Testing or Glass Box Testing
    – Test case design method that uses the control structure of the procedural
    design to derive test cases
    • SW Engineer can derive test cases that
    – guarantee that all independent paths within a module have been exercised
    at least once
    – exercise all logical decisions on their true and false bounds
    – execute all loops at their boundaries and within their operational bounds
    – exercise internal data structures to assure their validity
    • Why not just validate the requirement ?
    – Logic errors and incorrect assumptions are inversely proportional to the
    probability that a program path will be executed
    – We often believe that a logical path is not likely to be executed when, in
    fact, it may be executed on a regular basis
    – Typographical errors are random

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 2


    Basis Path/Control Structure Testing
    • Proposed by Tom McCabe
    • The basis path method enables the test case designer to derive a
    logical complexity measure of a procedural design and use this
    measure as a guide for defining a basis set of execution paths
    • Flow Graph Notation: If

    While
    Sequence

    Case
    Repeat - Until

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 3


    Pseudo Code - Flow Chart
    • Procedure Sort • Flow Chart
    Procedure Sort
    1. do while not eof
    2. Read Record
    3. if record field 1 = 0 1
    4. then process record
    5. store in buffer;
    2
    6. increment counter
    7. else if record field 2 = 0
    8. then reset counter 3
    9. else process record
    4
    10. store in file 7
    11. endif
    9 5
    12. endif 8
    13. enddo
    10 6

    11

    12

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 4


    Flow Chart - Flow Graph
    • Flow Chart • Flow Graph
    1

    1
    2,3

    2
    7

    4 8 9,10 4,5,6
    7

    9 5
    8
    11
    10 6

    11 12
    12

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 5


    Compound Logic

    Predicate Node

    IF a or b
    b
    then procedure X
    else procedure Y
    y x x
    endif

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 6


    Cyclomatic Complexity ( V(G) )
    • Cyclomatic Complexity
    – software metric that provide a quantitative measure of the
    logical complexity of a program]

    V(G) = E - N + 2

    V(G) = 9 - 8 + 2
    =3

    • The number of regions of the flow graph


    correspond to the cyclomatic complexity.
    • V(G) = P + 1, where P is the number of
    predicate nodes

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 7


    Independent Path
    • An independent path is any path through the program that introduces
    at least one new set of processing statements or a new condition
    • An independent path must move along at least one edge that has not
    been traversed before the path is defined

    path 1: 1-13
    1
    path 2: 1-2-3-7-8-11-12-1-13
    2,3 path 3: 1-2-3-7-9-10-11-12-1-13

    7
    path 4: 1-2-3-4-5-6-12-1-13

    8 9,10 4,5,6 Is the path


    1-2-3-4-5-6-12-1-2-3-7-8-11-12-1-13
    11
    an independent path ?
    13
    12

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 8


    Deriving Test Cases
    • Draw a corresponding flowgraph using the design or
    code as a foundation
    • Determine the cyclomatic complexity of the resultant
    flow graph (V(g))
    • Determine a basis set of linearly independent paths
    • Prepare test cases that will force execution of each
    path in the basis set
    – if we have 6 independent paths, then we should have at
    least 6 test cases. For each test cases, we should define
    • the input conditions and
    • the expected result.

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 9


    Graph Matrices
    • Can automate derivation of flow graph and determination of a set of
    basis paths.
    • Software tools to do this can use a graph matrix.
    • Graph matrix:
    • is square with #sides equal to #nodes
    • Rows and columns correspond to the nodes
    • Entries correspond to the edges.
    • Can associate a number with each edge entry.
    • Use a value of 1 to calculate the cyclomatic complexity
    • For each row, sum column values and subtract 1.

    • Sum these totals and add 1.

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 10


    Some other interesting link weights:
    • Probability that a link (edge) will be executed
    • Processing time for traversal of a link
    • Memory required during traversal of a link

    • Resources required during traversal of a link

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 11


    Branch Testing
    • Branch testing is the simplest condition testing
    strategy
    • For a compound condition C, the true and false
    branches of C and every simple condition in C need
    to be executed at least once

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 12


    Condition Testing (1)
    • Condition Testing aims to exercise all logical conditions in a program
    module.
    • Can Define
    – Relational Expression (E1 op E2) : where E1 and E2 are arithmetic
    expression
    – Simple Condition: Boolean variable or relational expression, possibly
    preceded by a NOT operator
    – Compound condition: composed of two or more simple conditions, boolean
    operators and parentheses
    – Boolean Expression: condition without relational expression
    • Types of errors in a condition include the following
    – boolean operator error (existence of incorrect/missing/extra boolean
    operator)
    – boolean variable error
    – boolean parenthesis error
    – relational operator error
    – arithmetic expression error

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 13


    Condition Testing (2)
    • The condition testing method focuses on testing each condition in the
    program.
    • Advantage of condition testing strategies
    – measurement of test coverage of a condition is simple
    – the test coverage of conditions in a program provides guidance for the
    generation of additional tests for the program
    • Some condition testing strategies
    – Branch Testing
    – Domain Testing
    – Branch and Relational Operator Testing - uses condition constraints
    • Example 1: C1 = B1 & B2
    – Where B1, B2 are boolean conditions
    – condition constraint of form D1, D2 where D1 and D2 can be true (t) or
    false (f)
    – The branch and relational operator test requires the constraint set { (t,t),
    (f,t), (t,f) } to be covered by the execution of C1
    • coverage of the constraint set guarantees detection of relational operator errors

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 14


    Data Flow Testing
    • Data Flow testing method select test paths of a program according to
    the locations of definitions and uses of variables in the program
    • With Data flow testing
    – each statement in a program is assigned a unique statement number and it
    assumes that each function doesn’t modify its parameters or global
    variables
    • Defs( s ) = { x | statement S contains a definition of X }
    • Use( s ) = { x | statement S contains a use of X }
    • DU Chain (Definition - Use Chain) of variable X is of the form {X, S, S’},
    where S, S’ are statement numbers, X is in Defs(S) and Defs(S’).
    • Other possible chains are:
    – DD (Definition-Definition Chain) - Should be avoided !! Why ??
    – UU (Use-Use Chain) - common chain
    – UD (Use-Definition Chain) - common chain
    • One simple strategy is DU Testing Strategy.
    – The strategy requires that every DU chain be covered at least once.

    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 15


    Loop Testing
    • Loop is fundamental to many algorithms.
    • Loop can be defined as simple, concatenated, nested, and unstructured.

    Nested Loops
    Concatenated
    Simple Loops
    Loops

    Unstructured
    Loops
    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 16
    Loop Testing (2)
    • To test:
    • Simple Loops of size n:
    • Skip loop entirely
    • Only one pass through loop
    • Two passes through loop
    • m passes through loop where m<n.
    • (n-1), n, and (n+1) passes through the loop.
    • Nested Loops
    • Start with inner loop. Set all other loops to minimum values.
    • Conduct simple loop testing on inner loop.
    • Work outwards
    • Continue until all loops tested.
    • Concatenated Loops
    • If independent loops, use simple loop testing.
    • If dependent, treat as nested loops.
    • Unstructured loops
    • Don't test - redesign.
    12/2/03 Bayu Hendradjaya - http://www.if.itb.ac.id/~bayu 17

    You might also like