P. 1
WhiteBox Testing

WhiteBox Testing

|Views: 5|Likes:
Published by tmkiran

More info:

Categories:Types, School Work
Published by: tmkiran on Nov 29, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

07/21/2013

pdf

text

original

White Box Testing

Core QA Team 12th March 2008

Agenda 

What is White-Box Testing  Why we do White-Box Testing  Need of White-Box Testing  Skills required  Roles and Responsibilities of White-Box Tester  Where White-Box Testing is Used  The White-Box Testing process includes.  Black-Box Vs White-Box Testing

2
©Copyright Kenexa® 2004

What is White-Box Testing

‡

‡

‡

White box testing is a security testing method that can be used to validate whether code implementation follows intended design, to validate implemented security functionality, and to uncover exploitable vulnerabilities. White-box testing is testing that takes into account the internal mechanism of a system or component (IEEE, 1990). White-box testing is also known as structural testing, clear box testing, and glass box testing. The connotations of ³clear box´ and ³glass box´ appropriately indicate that you have full visibility of the internal workings of the software product, specifically, the logic and the structure of the code.

3
©Copyright Kenexa® 2004

Why we do White Testing

To Ensure:
‡ ‡ ‡

That all independent paths within a module have been exercised at least once. All logical decisions verified on their true and false values. All loops executed at their boundaries and within their operational bounds internal data structures validity.

4
©Copyright Kenexa® 2004

Need of White-Box Testing

To Discover Following Type of Bugs:
‡

‡ ‡

Logical error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program The design errors due to difference between logical flow of the program and the actual implementation Typographical errors and syntax checking

5
©Copyright Kenexa® 2004

Skills required

‡

We need to write test cases that ensure the complete coverage of the program logic. For this we need to know the program well i.e. We should know the specification and the code to be tested. Knowledge of programming languages and logic.

6
©Copyright Kenexa® 2004

Roles and Responsibilities of a White-Box Tester

- Exercise independent paths within a module or unit; - Exercise logical decisions on both their true and false side; - Execute loops at their boundaries and within their operational bounds; and - Exercise internal data structures to ensure their validity.

7
©Copyright Kenexa® 2004

Where White-Box Testing is used
‡

There are six basic types of testing: unit, integration, function/system, acceptance, regression, and beta. White-box testing is used for three of these six types: Unit testing: which is testing of individual hardware or software units or groups of related units . A unit is a software component that cannot be subdivided into other components . Software engineers write white-box test cases to examine whether the unit is coded correctly. Approximately 65% of all bugs can be caught in unit testing. Integration testing: which is testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. Test cases are written which explicitly examine the interfaces between the various units. These test cases can be black box test cases, whereby the tester understands that a test case requires multiple program units to interact. Alternatively, white-box test cases are written which explicitly exercise the interfaces that are known to the Tester.
8
©Copyright Kenexa® 2004

Where White-Box Testing is used

Regression testing : which is selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements . As with integration testing, regression testing can be done via black-box test cases, white-box test cases, or a combination of the two. White-box unit and integration test cases can be saved and rerun as part of regression testing.

9
©Copyright Kenexa® 2004

The White-Box testing process includes

-

Execution of each statement in a code component at least once Execution of each conditional branch in the code component Execution of paths with boundary and out-of-bounds input values Verification of the integrity of internal interfaces Verification of architecture integrity across a range of conditions Verification of Database design and structure Examples: 1.Loop Testing 2.Basic Path Testing

10
©Copyright Kenexa® 2004

Loop Testing

This is White-Box Testing technique and there are 4 different types of Loop Testing 1. Simple Loops 2. Concatenated Loops 3. Nested Loops 4. Unstructured Loops

11
©Copyright Kenexa® 2004

Basic Path Testing
‡ ‡ ‡

A Testing mechanism proposed by McCabe. Aim is to derive a logical complexity measure of a procedural design and use this as a guide for defining a basic set of execution paths. Test cases which exercise basic set will execute every statement at least once 1.Flow Graph Notation: It¶s a simple notation representing control flow 2.Derive Cyclomatic Complexity. 3.Determine the number of Individual paths 4.Deriving Test cases to exercise these paths

Steps in Basic Path Testing Includes.

12
©Copyright Kenexa® 2004

Basic Path Testing - Flow Graph Notation
Flow Graph Notation:
Notation for representing control flow

13
©Copyright Kenexa® 2004

Basic Path Testing - Flow Graph Notation

On a flow graph:
‡ ‡ ‡ ‡ ‡ ‡

Arrows called edges represent flow of control Circles called nodes represent one or more actions. Areas bounded by edges and nodes called regions. A predicate node is a node containing a condition Any procedural design can be translated into a flow graph. Note that compound Boolean expressions at tests generate at least two predicate node and additional arcs

14
©Copyright Kenexa® 2004

Basic Path Testing - Flow Graph Notation
‡ ‡

Any procedural design can be translated into a flow graph. Note that compound Boolean expressions at tests generate at least two predicate node and additional arcs

15
©Copyright Kenexa® 2004

Basic Path Testing - Cyclomatic Complexity

‡ ‡

‡

The cyclomatic complexity gives a quantitative measure of the logical complexity. This value gives the number of independent paths in the basis set, and an upper bound for the number of tests to ensure that each statement and both sides of every condition is executed at least once. An independent path is any path through a program that introduces at least one new set of processing statements (i.e., a new node) or a new condition (i.e., a new edge)

16
©Copyright Kenexa® 2004

Basic Path Testing - Cyclomatic Complexity

17
©Copyright Kenexa® 2004

Basic Path Testing - Cyclomatic Complexity
Example has:
‡

‡

‡

Cyclomatic Complexity of 4. Can be calculated as: ± Number of regions of flow graph. ± #Edges - #Nodes + #terminal vertices (usually 2) ± #Predicate Nodes + 1 Independent Paths: ± 1, 8 ± 1, 2, 3, 7b, 1, 8 ± 1, 2, 4, 5, 7a, 7b, 1, 8 ± 1, 2, 4, 6, 7a, 7b, 1, 8 Cyclomatic complexity provides upper bound for number of tests required to guarantee coverage of all program statements

18
©Copyright Kenexa® 2004

Basic Path Testing
Deriving Test cases:
‡ ‡ ‡ ‡

±

Deriving Test cases

Using the design or code, draw the corresponding flow graph. Determine the cyclomatic complexity of the flow graph. Determine a basis set of independent paths. Prepare test cases that will force execution of each path in the basis set.

Note: some paths may only be able to be executed as part of another test.
19
©Copyright Kenexa® 2004

Black Box Testing Vs White Box Testing

20
©Copyright Kenexa® 2004

Black Box Testing Vs White Box Testing-Test case design Black Box:
‡
‡ ‡ ‡

White Box:
‡
‡ ‡ ‡ ‡

Equivalence partitioning Boundary-value analysis Cause-effect graphing Error guessing

Statement coverage Decision coverage Condition coverage Decision/condition coverage Multiple-condition coverage

21
©Copyright Kenexa® 2004

References

http://www.stctek.com/faqs.htm http://www.geekinterview.com/question_details/35815 http://www.testinggeek.com/whitebox.asp http://www.cs.rit.edu/~afb/20012/cs4/slides/stl-04.html

22
©Copyright Kenexa® 2004

23
©Copyright Kenexa® 2004

www.kenexa.com

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->