You are on page 1of 39

A good test case is one that has a high probability of finding an as-yet undiscovered error

A Successful test is one that uncovers an as-yet undiscovered error

The ease with which a computer program can be tested .

Operability

the better it works , the more efficiently it can be tested


system is designed & implemented with quality it has few bugs No bugs block the execution of tests The product evolves in functional stages

Observability

what you see is what you test


Distinct output for each input System states and variables visible during execution Past system states and variables are visible Incorrect output is easily identified Internal errors are automatically detected and reported

Controllability

the better we can control the software ,

the more testing can be automated

Software & hardware states & variables can be controlled directly by the test engineer. Test can be conveniently specified automated and reproduced.

Decomposability

By controlling the scope of testing , isolate

problems and perform smarter retesting

The Software system is built from independent modules Software modules can be tested independently

Simplicity

the less there is to test ,

Functional simplicity e.g.: minimum necessary to meet requirements Structural simplicity e.g.: architecture is modularized to limit propagation of faults. Code simplicity e.g.: coding standard is adopted for ease of inspection

the more quickly we can test it

Stability

the fewer the changes ,

the fewer disruptions to testing

Changes are infrequent Changes are controlled Changes do not invalidate existing tests The software recovers well from failures

Understandability

the more information we have ,

the smarter we will test

Dependencies between internal, external and shared components well understood Changes to design are well communicated Technical documentation is instantly accessible, well-organized, specific and accurate

White-Box Testing

Knowing the internal workings of a product,

Black-Box Testing

tests are conducted to ensure that all gears mesh has been designed to perform , tests are conducted to demonstrate that each function is fully operational (note: this is still different from validation)

Knowing the specified function that a product

Uses the control structure of the procedural design to derive test cases Guarantees that all independent paths within a module have been exercised at least once Exercise all logical decisions on their true & false sides Execute all loops at their boundaries and within their operational bounds Exercises internal data structures to assure their validity

A Flow Graph created


represents the control flow of the program each node in the graph represents one or more procedural statements Any procedural design representation can be translated into a flow graph

Flow Graph 1 2 4 6 7a 7b 8 5 3

Cyclomatic Complexity
Software metric that provides a quantitative measure of the complexity of a program is the number of independent paths in the basis set of a program Upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.

Cyclomatic Complexity calculation


V (G) = E -N+ 2 = P+1 = No. of regions in the graph where E = no. of edges, N = no. of nodes, and P = no. of predicate nodes

For the previous example Independent paths


path 1 : 1-8 path 2 : 1 - 2 - 3 - 7b - 1 - 8 path 3 : 1 - 2 - 4 - 6 - 7a - 7b - 1 - 8 path 4 : 1- 2 - 4 - 5 - 7a - 7b - 1 - 8 Cyclomatic complexity = 11 - 9 + 2 = 3 + 1 = 4

Prepare test cases that will force execution of each independent path in the Basis Path set Each test case is executed and compared to expected results

Design or code as a foundation draw a corresponding flow graph. Determine cyclomatic complexity of resultant flow graph. Determine a basis set of linearly independent paths. Prepare test cases that will force execution of each path in basis set.

Attacks the control flow of the program Provides us with a logical complexity measure of a procedural design Use this measure as a guide for defining a Basis set of execution paths Test cases derived to exercise the Basis set are guaranteed to execute every statement in the program at least once

Exercises all the logical conditions in a module Types of possible errors


Boolean variable error Boolean Parenthesis error Boolean Operator error Arithmetic expression error

Branch Testing

the TRUE and FALSE branches of the condition and every simple condition in it are tested

Domain Testing

for every Boolean expression of n variables , all of 2n possible tests are required

Assume functions do not modify their arguments or global variables. Then define
DEF ( S ) = { X | Statement S contains a definition of X } USE ( S ) = { X | Statement S contains a use of X } Definition - Use chain ( DU chain )

Every DU chain to be covered at least once

[ X , S , S ] , where X DEF ( S ) and X USE ( S ) and the definition of X in S is live at S

Focus is on the validity of loop constructs Simple loop ( n is the max. no. of allowable passes )
Skip the loop entirely Only one pass through the loop Two passes m passes , where m < n n-1 , n , n+1 passes

Nested loop

Start at innermost loop Conduct simple loop test for this loop Move outwards one loop at a time

Concatenated loops
Multiple simple loop tests if independent Nested loop approach if dependent

Unstructured loops
Should be restructured into a combination of simple and nested loops

Focus is on the functional requirements of the software Uncovers errors such as


Incorrect or missing functions Interface errors Errors in data structures Performance errors Initialization and Termination errors

Unlike White Box Testing , this is performed at later stages of testing

Identify all objects modeled by the software Identify the relationships that connect these objects Create an Object-Relationship graph
node node weights links link weights

Example graph
menu select generates

new file
is represented as

generation < 1 sec allows editing of

Document window
Attributes :
start dimension Background color text color

contains

Document text

Add entry and exit nodes For an object A, values for all objects in the transitive closure of Z must be tested for their impact on Z Test the symmetry of all bi-directional links, e.g., undo Be sure all nodes have a reflexive link. Test it for each node. Test each relationship (the links).

Input domain divided into classes of data from which test cases are derived Goal is to design a single test case that uncovers classes of errors , thereby reducing the total number of test cases to be developed Each class represents a set of valid or invalid states for input conditions

Test case design is based on an evaluation of equivalence classes for an input condition
range specified , one valid and two invalid equivalence classes requires a specific value , one valid and two invalid equivalence classes specifies a member of a set , one valid and one invalid equivalence classes is boolean , one valid & one invalid equivalence class

Example

Automatic Banking

area code : input condition , boolean input condition , range [200,999] prefix : input condition , range >200, no

0s, < 1000

suffix : input condition , value -- 4 digits password : input condition , boolean input condition , value -

- 6 char str

command

: input condition , set

Greater number of errors tend to occur at the boundaries of the input domain Select test cases that exercise bounding values Input condition
max set

range , test cases are just below min and just above

The above guidelines are also applied to output conditions


example

, test cases are minimum and maximum values, if ordered

outputs that produce minimum and maximum values in the output range

GUI testing

It presents interesting challenges for software engineers, bcoz reusable components provided as part of GUI development environment & its been precise. Complexity is grown, difficulty in design and execution . Large no of permutations associated with GUI operations testing should be approached using automated tools.

Client Server

It represents a significant challenge for software testers. Performance issue associated with transaction processing, potential presence of no of different hardware platforms . Complexity of n/w communication need to service multiple clients. Application function tests Server tests Database tests Transaction tests Network communication tests.

White Box Testing


Black Box Testing - Functional requirements


Graph based testing Equivalence partitioning Boundary Value testing

control structure testing Condition testing Data flow testing Loop testing

You might also like