Software testing methodolgy with the control flow analysis

SOFTWARE TESTING METHODOLGY
WITH THE CONTROL FLOW ANALYSIS
WEN-CHANG PAI, CHI-MING
CHUNG, CHING-TANG HSIEH, CHUN-
CHIA WANG, AND YING-HONG WANG

PRESENTED BY:
REEMA QAISER KHAN
MS(SE)-2

• This paper provides a method for analyzing the control-flow
of a program.
• The authors define a number of command types and test
data generating rules based on the control-flow of the
program.
• An algorithm to scan program and analysis testing paths is
provided.
• This will allow testers to recover the program’s
design, understand the software structure, and assist
software maintenance.

AN OVERVIEW OF PROGRAM TESTING
• In a program P, we say a statement block B = (s1, s2, …, sn)
is a maximal subset of contiguous statements of P such that
statement si is the unique successor of si-1 and si-1 is the
unique predecessor of si, for all
i = 1, 2, …, n.
• A program graph G = {nodes, edges} contains a set of nodes
and edges

• A node without a predecessor is a start node.
• A node without a successor is an exit node.
• A complete path is a path whose initial node is the start
node of G and whose final node is an exit node of G.
• A well known logic coverage criterion is decision coverage
or branch coverage. Examples of branch or decision
statements are IF statements, WHILE statements, and
SWITCH statement.
• This criterion states that each branch direction must be
traversed at least once.

• In software testing technologies, boundary testing (or
boundary value analysis; BVA) is a good test case design. It
selects test data at the boundary of the input domain.
• Experience shows that test data selected with BVA have a
higher payoff than other data.
• More errors tend to occur at the boundaries of the input
domain.

AUTOMATICALLY GENERATING TEST
DATA
• The steps involved in the method are described in the
following:
1) Choosing Adequacy Testing Criteria:
The branch coverage criterion is adopted in this paper to
generate test data for testing a program.
2) Defining Command Types:
We define three typical statement types in a program:
(1) sequential commands, (2)conditional commands, and
(3) loop commands.
Each command type essentially corresponding to a block or
some blocks in a program. In this paper, we will generate
test data for each of the command types to enter every
branch of a program.

3) Scanning the Program and Generating Test Data:
The test data are generated from the input domain, which is
derived through boundary value analysis with the Branch
coverage criterion.
4) Analyzing Test Paths and Testing :
Finally, testers analyze the testing paths and test the
program with the results obtained in step 3.

TEST DATA GENERATING RULES
• Type 1. Sequential Command Set :

• The Sequential commands, such as
OPEN, READ, WRITE, and CLOSE statements, are usually
written in the form
• ‘C1; C2’,

Rule 4.1 :
The set S1, S2, …, Sn is a contiguous sequence of
statements of a program P, such that a corresponding block
B exists in P. A node N also exists in the program graph G.

• Type 2. Conditional Command Set :

• A conditional command, such as an If-Then-End
statement, If-Then-Else-End statement, Switch-Case-With-
Default statement, or Switch-Case-Without-Default
statement, has a number of subcommands, from which
exactly one is chosen to be executed. Conditional
commands typically have the form

• If CON1 then B1
Else if CON2 then B2
…
else if CONn then Bn
end if

Rule 4.2 :
Set S′ is a set of Switch statements of a program P, such
that a number of corresponding blocks B1, B2, …, Bk
exist in S′. A number of nodes S, N1, N2, …, Nk, and E
also exist in the program graph G.

• Type 3. Loop Command Set :
• Loop commands, such as For-loop statements, While-loop
statements, and Repeat- loop statements, have a number
of subcommands that are executed repeatedly until some
conditions are true. Loop commands typically have the
form

While CON do
B
End while
OR

Repeat
B
Until CON

Rule 4.3 :
Set S′ is a Loop statement s of a program P, such that a
corresponding block B exists in P. A number of nodes, S, N,
and E, also exist in the program graph G.

TEST PATH ANALYSIS ALGORITHM
• The algorithm analyzes the path to search for the command
types and the apply rules 4.1 to 4.3 accordingly.
• We can transform each statement of a program to its
corresponding flow. The paths are analyzed and test data
are generated after the program has been completely
scanned.

• Algorithm PATH_ANALYSIS
• begin
• get PROGRAM
• set START_NODE
• set NEW_NODE
• move POINTER to NEW_NODE
• while not END_OF_PROGRAM
• read next INSTRUCTION
• search INSTRUCTION_TABLE
• switch (INSTRUCTION)
• case “Switch Statement Set”
• set NEW_NODE (or NODES) /* according to the rule 4.2 */
• move POINTER to NEW_NODE /* according to the rule 4.2 */
• case “Loop Statement Set”
• set NEW_NODE (or NODES) /* according to the rule 4.3 */
• move POINTER to NEW_NODE /* according to the rule 4.3 */
• case “Sequence Statement Set” /* according to the rule 4.1 */
• skip
• end {switch}
• end {while}
• set END_NODE
• end {PATH_ANALYSIS}

TEST CASES USING BOUNDARY VALUE
ANALYSIS
• We have three loop commands, and one conditional
command.
• Test Cases for the first Loop Command
(WHILE LOP=“F”) using boundary value analysis:
1- Test Case with test data of character F, to check input
domain LOP=“F”.
2- Test Case with test data can be any character except F, to
check input domain LOP<>“F” e.g. LOP=“A”,LOP=“B”, etc.

• Test Cases for the Second Loop Command
(WHILE ANS<> “Y” and ANS<> “y”) using boundary value
analysis:
1- Test Case with test data can be any character except “Y” or
“y”, to check input domain ANS<> “Y” and ANS<> “y”, e.g.
ANS=“A” or ANS=“a”, ANS=“B”or ANS=“b”, etc.
2- Test Case with test data “Y” and “y” , to check input domain
ANS=“Y” or ANS=“y”.

• Test Cases for the Third Loop Command
(WHILE ANS<> “Y” and ANS<> “y”) using boundary value
analysis:

• Test Cases for the First Conditional Command
(IF ANS<> “Y” and ANS<> “y”) using boundary value
analysis:

Software testing methodolgy with the control flow analysis

• From Table 1, we have the following testing paths:
• <S, 1, 2, 13, E>
• <S, 1, 2, 3, 4, 5, 4, 6, 7, 8, 7, 9, 10, 11, 12, 2, 13, E>
• <S, 1, 2, 3, 4, 5, 4, 6, 7, 8, 7, 9, 10, 12, 2, 13, E>
• <S, 1, 2, 3, 4, 6, 7, 8, 7, 9, 10, 11, 12, 2, 13, E>
• <S, 1, 2, 3, 4, 6, 7, 8, 7, 9, 10, 12, 2, 13, E>
• <S, 1, 2, 3, 4, 5, 4, 6, 7, 9, 10, 11, 12, 2, 13, E>
• <S, 1, 2, 3, 4, 5, 4, 6, 7, 9, 10, 12, 2, 13, E>
• <S, 1, 2, 3, 4, 6, 7, 9, 10, 11, 12, 2, 13, E>
• <S, 1, 2, 3, 4, 6, 7, 9, 10, 12, 2, 13, E>

CONCLUSION
• The researchers have defined a number of command
types flows and given some test data generation rules.
These have been derived based on a branch coverage
testing path selection criterion and boundary value
analysis. We have also provided an algorithm and used
an example to illustrate the methodology and show
that it is practicable.
• The proposed methodology allows maintainers to
recover a program’s structure and conduct software
maintenance. The method proposed in this paper can
help testers recognize and test programs more
efficiently.

REFERENCE
• http://www.iis.sinica.edu.tw/page/jise/2005/
200511_07.pdf

Software testing methodolgy with the control flow analysis

More Related Content

Similar to Software testing methodolgy with the control flow analysis (20)

More from RQK Khan (16)

Recently uploaded (20)

Software testing methodolgy with the control flow analysis