meljun cortes jedi slides-6.2 software test case design methods

7/29/2019 MELJUN CORTES JEDI Slides-6.2 Software Test Case Design Methods

1/32

Software Engineering 1

Software Testing

Software Testing

Case DesignMethods

TOPIC TWO


2/32


Test Case Design

Approaches White-box Testing

Test the internal workings of a program

Black-box Testing

Test the system as a whole


3/32


White-box Testing

It is also known as glass-box testing.

It is a test case design technique that uses the internalcontrol structure of the software component as defined by

their methods to derive test cases. It has a goal of ensuring that internal operations perform

according to specifications.


4/32


White-box Testing

It ensures that no logical errors, incorrect assumptions andtypographical error have been missed.

It produces test cases that:

Ensure that all independent paths with the component have beentest at least once

Test all logical decisions on their true or false sides

Test all loops at their boundaries and within their operational bounds

Test internal data structures for their validity

Test paths within the components that are considered out of themainstreams.


5/32


White-box Testing

Techniques Basic Path Testing

Control Structure Testing


6/32


Basic Path Testing

It is white-box testing technique that enables the test casedesigner to derive a logical complexity measure based onthe procedural specification of a software component.

Abasis set

is identified to determine the measure ofexecution paths.


7/32


Using Basic Path Testing

1. Use a procedural specification as input in deriving the basicset of execution path.

2. Draw the flow graph.

3. Compute the complexity of the code.4. Determine the basic set of execution paths.

5. Document the test case based on the identified paths.

while (condition1) do


8/32


STEP 1: Use a procedural

specification of the code. The procedural specification can be the design code or thesource code itself.

while (condition1) dostatement1;statement2;do case var1

condition1:statement3

condition2:statement4;statement5;

condition3:if (condition2) then

statement6;else

statement7statement8

endifendcasestatement9;

endwhile

Text 1: Sample Design Code


9/32


STEP 2: Draw the flow graph.

The flow graph depicts the logical control flow of the code. Ituses nodes, edges and regions.

1while(condition1) do

2statement1;statement2

3do case var1

5condition2statement4statement5

4condition1statement3 6

condition3if (condition2) then

7statement6

8statement7statement8

9statement9

11


10/32


STEP 3: Compute the

complexity of the code. The cyclomatic complexity is used to determine thecomplexity of the code. It is a number that specifies theindependent paths in the code.

It is computed in three ways:

The number of regions

The number of predicate notes plus one, i.e, V(G)=P+1

The number of edges minus the notes plus 2, i.e., V(G)=E-N+2


11/32


STEP 3: Compute the

complexity of the code.1

while(condition1) do

2statement1;statement2

3do case var1

5condition2statement4statement5

4condition1statement3 6

condition3if (condition2) then

7statement6

8statement7statement8

9statement9

11

REGION 1

REGION 2REGION 3

REGION 4

REGION 5- Outsidewhere node 11 belongs

Node 3 is counted as2 predicates. It isequivalent to twonested ifstatements.

V(G)=R=5 regionsV(G)=P + 1 = 4+1 =5V(G)=E-N+2=13-10+2=5


12/32


STEP 4: Determine the basic

set of execution paths. The cyclomatic complexity is the number of the executionpath of the code.

Path 1: Node-1, Node-2, Node-3, Node-4, Node-9Path 2: Node-1, Node-2, Node-3, Node-5, Node-9

Path 3: Node-1, Node-2, Node-3, Node-6, Node-7, Node-9

Path 4: Node-1, Node-2, Node-3, Node-6, Node-8, Node-9

Path 5: Node-1, Node-11


13/32


STEP 5: Document the test

case. A test case is equivalent to one execution path.

TEST CASE 1- Path 1:

For Node-1, condition2 should evaluate to TRUE (Identifythe necessary values.)

For Node-3, evaluation of var1 should lead to Node-4(Identify value of var1)

Expected Results: should produce necessary result forNode-9.


14/32



It is a white-box testing technique that test three types ofcontrol.

Condition Testing

Looping Testing Data Flow Testing


15/32


Condition Testing

It is a test case design method that test the logicalconditions contained in a procedural specification.

It focuses on testing each condition in the program byproviding possible combination of values.

if ((result < 0) && (numberOfTest != 100))

T e s t C a s er e s u l t < 0n u m b e r O f T e s t ! = 1 0 0C o m p o u n d

1 T T T2 T F F

3 F T F


16/32


Looping Testing

It is a test case design method that focuses exclusively onthe validity of iterative constructs or repetition.

There are four classes of iteration.

Simple Iteration:

DO WHILE

Statement

ENDWHILE

Concatenated Iteration:

DOWHILE

Statement

ENDWHILE

DOWHILE

Statement

ENDWHILE

Nested Iteration:

DO WHILE

Statement

DO WHILE

Statement

ENDWHILE

ENDWHILE

Unstructured Iteration:

DOWHILE

Statement

:Label1

DOWHILE

Statement

:Label2

IF

GOTOLabel1

ENDIF

GOTOLabel2

ENDWHILE

ENDWHILE


17/32


Looping Testing

For Simple Iteration, the test cases can be derived from thefollowing possible execution of the iteration or repetition.

Skip the loop entirely.

Only one pass through the loop.

Two passes through the loop.

m passes through the loop where m < n

n 1, n, n + 1 passes through the loop


18/32


Looping Testing

For Nested Iterations, the test cases can be derived fromthe following possible execution of the iteration or repetition.

Start with the innermost loop.

Conduct simple loop tests for the innermost loop while holding theouter loop at their minimum iteration parameter values. Add othertest for out-of-range or excluded values.

Work outward, conducting tests for the next loop, but keeping allother outer loops at minimum values and other nested loops totypical values.

Continue until all loops have been tested.


19/32


Looping Testing

For Concatenated Iteration, the test cases can be derivedfrom the following possible execution of the iteration orrepetition

If loops are independent, the test for simple loops can be used.

If loops are dependent, the test for nested loops can be used.

For Unstructured Iteration, no test cases can be derivedsince it would be best to redesign the loop since it is not agood iteration or repetition constructs.


20/32


Black-box Testing

It is a test design technique that focuses on the testing thefunctional aspects of the software whether it complies withfunctional requirements.

It defines a set of test cases that finds errors in externaldatabase access, performance errors, and errors ininitialization and termination.


21/32


Black-box Testing

Techniques Graph-based Testing Equivalence Testing

Boundary Value Testing


22/32


Graph-based Testing

It is a black-box testing technique that uses objects that aremodeled in software and the relationships among theseobjects.


23/32


Use Graph-based Testing

Create a graph of software objects and identifyrelationships.

Traverse the graph to define test cases.

STEP 1 C t h f


24/32


STEP 1: Create a graph ofsoftware objects and identify

relationships. The collaboration diagrams can be a good source.


25/32


STEP 2: Traverse the graph

to define test cases. Test Case 1: FindAthleteUIobject sends a request to retrieve a list of athlete

based on a search criteria. The request is sent to theFindAthleteRecord.

The FindAthleteRecord sends a message to the DBAthlete toprocess the search criteria.

The DBAthlete request the database server to execute the SELECT-statement. It populates the PCLAthlete object with the athleteinformation. It returns a reference to the PCLAthlete to theAthleteListUI.

The AthleteListUI lists the names of the athletes.


26/32


Graph-based Testing

Guidelines Identify the start and stop points of the graph. There shouldbe an entry and exit nodes.

Name nodes and specify their properties.

Establish their relationship through the use of edges.Specify the properties.

Derive test cases and ensure that there is node and edgecoverage.


27/32


Equivalence Testing

It is a black-box testing technique that uses the input domainof the program or software.

It divides the input into sets of data from which test casescan be derived

It uses of equivalence classes which are sets of valid andinvalid states that an input may be in.


28/32


Equivalence Testing

Guidelines Input Condition is specified as a range of value. The testcase is one valid input, and two invalid equivalence classes.

Input Condition requires a specific value. The test case isone valid, and two invalid equivalence classes.

Input condition specifies a member of a set. The test caseis one valid and one invalid.

Input condition is Boolean. The test case is one valid, andone invalid.


29/32


Sample Equivalence Testing

Consider an example of text message code.

Derived Equivalence Set

Service Server Number

(Number of the Serverproviding the service.)

Service Code

(A unique service code thattells the service providerwhat service is asked.)

Mobile Number

(The mobile number wherethe information is sent.)

765 234 09198764531

Service Server Number

(specific value)

input condition 1: correct value

input condition 2: incorrect value

Service Code

(specific value)


input condition 2: incorrect valueMobile Number

(specfic value)


input condition 2: missing number

input condition 3: length not correct


30/32



It is a black-box testing technique that uses boundaries ofthe input domain to derive test cases.

Most error occurs at the boundary of the valid input values.


31/32



Guidelines If input condition specifies range bounded by n and m, the testcases that can be derived:

use values n and m

just above n and m

just below n and m

If input condition specifies number of values, the test casesthat can be derived:

use the minimum

use the maximum

just above and below minimum

just above and below maximum.


32/32


Summary

Two Approaches to Testing White-box Testing

Basic Path Testing


Black-box Testing

Graph-based Testing

Equivalence Testing


meljun cortes jedi slides-6.2 software test case design methods

Documents