TRACEABILITY TOOL: A WEB-BASED TOOL FOR TEST CASE GENERATION
BASED ON MODEL-BASED TESTING ALGORITHM
Vidhi .K. Shah
B.E., Dharmsinh Desai University, India, 2008
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
SOFTWARE ENGINEERING
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
SPRING
2012
© 2012
Vidhi Shah
ALL RIGHTS RESERVED
ii
TRACEABILITY TOOL: A WEB-BASED TOOL FOR TEST CASE GENERATION
BASED ON MODEL-BASED TESTING ALGORITHM
A Project
by
Vidhi Shah
Approved by:
__________________________________, Committee Chair
Ahmed Salem, Ph. D
__________________________________, Second Reader
Bob Buckley, MS
__________________________
Date
iii
Student: Vidhi Shah
I certify that this student has met the requirements for format contained in the University
format manual, and that this project is suitable for shelving in the Library and credit to be
awarded for the project.
______________________________, Graduate Coordinator
Nikrouz Faroughi, Ph. D
Department of Computer Science
iv
________________
Date
Abstract
of
TRACEABILITY TOOL: A WEB-BASED TOOL FOR TEST CASE GENERATION
BASED ON MODEL-BASED TESTING ALGORITHM
by
Vidhi Shah
The field of software testing is full of challenges. Software test engineers face numerous
challenges such as understanding the requirements, testing under time-constraints, and
designing an efficient set of test cases. The software is tested in order to make sure that
the system fulfills its purpose. Model-based testing has progressed leaps and bounds and
is regarded as the preferred means of testing. In the recent past, there has been a
remarkable increase in research and tools surrounding model-based testing.
Model-based testing is an effective method to generate an efficient suite of test cases. It
depends on three key technologies: the notation used for the data model, the test
generation algorithm, and the tool that generates supporting infrastructure for tests,
including expected outputs. Model-based testing makes testing easier, faster and more
economical. It is a valuable asset for test development teams.
v
The aim of this project is to implement a tool that allows the test engineers to design and
generate an efficient set of test cases. The tool itself is based on a pre-defined algorithm
designed by IBM.
________________________________, Committee Chair
Ahmed Salem, Ph. D
__________________________
Date
vi
DEDICATION
To my Parents
vii
ACKNOWLEDGEMENTS
While working on this project many people have helped me achieve my goal.
I would like to thank Dr. Ahmed Salem, for investing his invaluable time reviewing this
project. Without his support it would have been difficult for me to complete this project.
I would also like to thank Professor Bob Buckley for giving me his time and input as
second reader.
I would like to thank my Parents, for their undying love and support. Also I would like to
thank all my professors, who taught me. Without their assistance and guidance, my
Master’s degree would not have been completed successfully.
viii
TABLE OF CONTENTS
Pages
Dedication ......................................................................................................................... vii
Acknowledgements .......................................................................................................... viii
List of Tables ..................................................................................................................... xi
List of Figures ................................................................................................................... xii
Chapter
1 INTRODUCTION ..........................................................................................................1
2 BACKGROUND ............................................................................................................4
2.1 Need for the project ...........................................................................................5
2.2 Scope of the project ...........................................................................................5
3 TECHNOLOGY .............................................................................................................6
3.1 PHP ....................................................................................................................6
3.2 Java script...........................................................................................................6
3.3 My SQL .............................................................................................................7
3.4 Other Components .............................................................................................7
3.4.1 Dream weaver ...........................................................................................7
4 FUNDAMENTALS AND ALGORITHM .....................................................................8
4.1 Fundamentals ......................................................................................................8
4.1.1 Functional and Non-functional Requirements ..........................................8
4.1.2 Use-case Basics .........................................................................................9
4.1.3 Test case Basics ......................................................................................11
ix
4.1.4 Model-based Testing ...............................................................................12
4.1.5 Traceability .............................................................................................13
4.1.6 Pair-wise Testing ....................................................................................14
4.1.7 Boundary-value Analysis ........................................................................14
4.2 The Algorithm ..................................................................................................15
4.3 Example explaining the Algorithm ..................................................................16
4.3.1 Basic flow ...............................................................................................16
4.3.2 Alternate flow .........................................................................................17
4.3.3 Creating test cases from use-cases ..........................................................18
5 DESIGN AND IMPLEMENTATION .........................................................................30
5.1 Traceability Tool Database Design ..................................................................30
5.1.1 Data dictionary ........................................................................................31
5.2 Entity Relationship Model ...............................................................................36
5.3 Data Flow Diagram ..........................................................................................37
5.4 Sequence Diagram ...........................................................................................38
6 RESULTS .....................................................................................................................39
6.1 Traceability Tool User Interface .......................................................................39
6.2 Test cases .........................................................................................................43
7 CONCLUSION AND FUTURE WORK .....................................................................46
Appendix. Source Code .....................................................................................................47
Bibliography ......................................................................................................................60
x
LIST OF TABLES
Pages
Table 1: All possible scenarios ..........................................................................................20
Table 2: Options identified for variables ...........................................................................26
Table 3: Output test cases ..................................................................................................28
Table 4: Users ....................................................................................................................31
Table 5: Project ..................................................................................................................32
Table 6: Test cases .............................................................................................................33
Table 7: Variables ..............................................................................................................34
Table 8: Variable values ....................................................................................................35
xi
LIST OF FIGURES
Page
Figure 1: Requirements pyramid .........................................................................................9
Figure 2: Flow for model-based testing .............................................................................13
Figure 3: Traceability requirements pyramid ....................................................................14
Figure 4: Finding scenarios in use-case .............................................................................19
Figure 5: Entity relationship diagram ................................................................................36
Figure 6: Data flow diagram ..............................................................................................37
Figure 7: Sequence diagram...............................................................................................38
Figure 8: Login page interface ...........................................................................................39
Figure 9: Register new user interface ................................................................................39
Figure 10: Create a new project interface ..........................................................................40
Figure 11: Add test case interface ......................................................................................41
Figure 12: Add variables interface .....................................................................................41
Figure 13: Add variable values interface ...........................................................................42
Figure 14: Final output interface........................................................................................43
xii
1
Chapter 1
INTRODUCTION
Software testing plays a critical role in the software development life cycle. If an
insufficient number of tests are performed on the software, the software delivered will not
fulfill its purpose, and the quality of the software will not be satisfactory. While testing
software, the testers face several challenges:

Requirements may not be properly communicated;

Developers may not accurately convey what the build encompasses;

At the time of effort estimation, the testing team may not be involved, yet the
testing team is normally asked to perform the tests within a particular timeframe.
If overlooked, these challenges will undoubtedly have an adverse effect on the
overall quality and functionality of the software. The goal is to minimize the risk of being
heavily impacted by these potential problems and to do so in an efficient manner.
Model-based testing is a new and evolving technique for generating a suite of test
cases from requirements. Testers using this approach concentrate on a data model and
generation infrastructure instead of handcrafting individual tests. Model-based testing
results in many benefits like low cost, shorter schedules and enhanced communication
between developers and testers.
There are different types of testing techniques, including control flow testing, data
flow testing, branch testing, path testing, loop testing, and boundary-value analysis.
2
Model-based testing has advantages over these other techniques; it can be introduced in
the initial phases of software development, saves time, enables testers to perform
systematic testing, and provides a quick response to evolving requirements. Testing
techniques like control flow testing, data flow testing, path testing and loop testing can be
implemented only after the coding of the software is completed. In contrast, model-based
testing delivers early feedback on the software, facilitating timely delivery. Bugs can be
fixed at a lower cost and it is also excellent for testing non-deterministic systems.
While performing model-based testing, test cases are executed in parallel with the
generation. This facilitates the production of efficient test cases with the use of finite
state machines and Markov chains, two of the most popular techniques in model-based
testing for modeling user behavior [1]. Finite state machines can ensure that the
generated test cases give maximum coverage. When a Markov chain model is used, a
random process generates test cases and provides analytical formulas to determine
expected values that are useful in test planning.
In software testing, “test cases” are a set of conditions or variables under which a
tester will determine whether an application or software system is working correctly or
not [2]. A good test case has a high probability of finding an error. The test cases are
useful in making sure that the system fulfills its purpose. As complete testing of the
software is not possible, it is very important to create test cases that give maximum
coverage.
3
The primary objective of this project is to design and implement a tool that takes
requirements as input and gives a set of possible test cases as output. Such a tool will help
the test development team to compare the expected outputs with the actual outputs,
resulting in a better quality of software.
The need for the tool, scope of the project and other related research is discussed
in Chapter 2. The technology used for building the tool is discussed in Chapter 3. Chapter
4 gives a basic idea of functional and non-functional requirements, use-cases, test cases,
model-based testing, traceability, pair-wise testing, and boundary-value analysis along
with the algorithm and an example explaining the algorithm. This is followed by an
explanation of the database design with a data dictionary, entity relationship diagram,
data flow diagram, and the sequence diagram in Chapter 5. A sample demonstration of
the tool interface and test cases are discussed in Chapter 6. A summary of the learning
experience from this project and the scope for future enhancements are discussed in
Chapter 7. Source-code and a bibliography will follow.
4
Chapter 2
BACKGROUND
Model-based testing is a technique that has been thoroughly explored, and an enormous
amount of research has been done in this area. There are a lot of tools supporting the
concept of model-based testing. Some of the research and existing tools are: "Use-Case
Management With Rational Rose And Rational Requisite Pro”, which provides an idea of
how use-cases can be organized and which test cases are affected by a change in usecases [3]; “Model-based testing in practice”, which measures the efficacy of this new
approach [4]; and MaTeLo, which is a test software following the Model-Driven
Engineering approach. Therefore MaTeLo is a Model-Based Testing solution. It
basically uses Markov Chains to describe the test model of the system under tests
implemented for “Black Box Testing” [5]. In addition to this, Microsoft has also come up
with its own Model-based testing tool named “Spec Explorer”, which is a software
development tool for advanced model-based specification and conformance testing [6].
“Spec Explorer” extends Microsoft Visual Studio for creating models of software
behavior, analyzes those models with graphical visualization, checks the validity of those
models, and generates test cases from the models [7].
The tool that will be discussed in this report is mainly based on the algorithm
developed by IBM under the name, “Traceability from use-cases to test cases”.
Moreover, IBM has a tool named “IBM Rational Requisite Pro”, which is a requirements
management tool based on the same algorithm and very useful; however it costs a lot
5
to obtain a standard user license. This tool is an attempt to minimize the challenges of
software testing.
2.1 Need for the project
The market for requirements management tools is highly saturated, but new tools
are constantly being introduced, resulting in cutthroat competition. Testing the software
is very important in order to verify that it fulfills its purpose. This tool is easy to use, free
and is based on a pre-defined algorithm by IBM. Its main purpose is to help test
development teams by facilitating early bug detection at a low cost, thereby resulting in a
better quality of software and facilitating a timely delivery. It can also be very useful for
reverse engineering, that is, backtracking from a test case to its corresponding
requirements. As a future work, we can add a functionality that will minimize the number
of test cases by combining those test cases using pair-wise testing and boundary value
analysis, while still giving us 100% test coverage.
2.2 Scope of the project
The scope of the project is to achieve the following objectives:

To be able to successfully add project name, author name and test case name;

To be able to add all the variables and their values to the database;

To get all possible test cases based on the variables and the variable values entered;

To get an expected True or False result for each test case.
6
Chapter 3
TECHNOLOGY
In this chapter there is a brief description of the languages, relational databases and other
supporting tools used in building the tool.
3.1 PHP
PHP was originally created by Rasmus Lerdorf in 1995 [8]. It is a server side
HTML embedded scripting language. It was originally designed for web development to
produce dynamic web pages. It is a free software initially known as “Personal Home
Page” but now know as “PHP: Hypertext Preprocessor” [8]. Object oriented was
introduced in PHP 3 and later versions [8]. As PHP is open source it allows developers to
write extensions in C language to add more functionality for their convenience.
3.2 Java script
Java Script is not same as programming language Java and was first developed in
September 1995 by Brendan Eich under the name Mocha that was renamed as Live Script
and then Java Script [9]. It resembles a lot of the structured programming syntax from C
and many names and naming conventions from Java. Hence it is an amalgam of Java and
C. It is a prototype based scripting language that is dynamic, weakly typed and has first
class functions [9]. It supports object-oriented, imperative and functional programming
styles [9].
7
3.3 My SQL
My SQL is world’s most popular open source database software. My SQL is a
lightweight database server which is fast, stable, easy to install and easy to use [10]. It is
a relational database management system that runs as a server providing multi-user
access to a number of databases [10]. My SQL is written in C and C++. Its SQL parser is
written in yacc. It works on many different platforms.
3.4 Other Components
This section describes other supporting tool called Dream Weaver used to
assemble/write/edit the code that made the job easier.
3.4.1 Dream weaver
Adobe Dream weaver is a proprietary web development application supporting
several server-side scripting languages and technologies such as CSS, Java script, C#, etc
is an outstanding visual HTML and code editor [11]. It is written in C++ language and
works for both Microsoft Windows and Mac Operating System. It is a paid application
and costs about $299 for full version [11].
8
Chapter 4
FUNDAMENTALS AND ALGORITHM
4.1 Fundamentals
This section contains the fundamental details of functional and non-functional
requirements, use-cases and test cases, model-based testing, traceability, pair-wise testing
and boundary-value analysis.
4.1.1 Functional and Non-functional Requirements
For any given system we need to start from the requirement. Requirements are the
constraints, needs, demands, necessities or parameters that must be satisfied in a specific
time frame [12]. There are two types of requirements:
1) Functional requirements
2) Non-functional requirements
Functional Requirements are tangible specifications that a system should be able to
perform. Functional requirements can be any high-level abstract statement to a detailed
formal specification of the system. On the contrary, Non-Functional requirement are
intangible specifications of the system like security, performance, etc of the system. Here
we will deal with only functional requirements of the system, which will help us in
deriving a use-case and a test case for the system. Figure 1 shows the requirements
pyramid.
9
Figure 1: Requirements pyramid [13]
As the figure shows the need of the stakeholders are at the top and as we move towards
the base the needs are boiled down to features which further comes down to use-cases
and supplementary specifications. Use-cases describe the functional requirements
whereas supplementary specification describes the non-functional requirements. As we
traverse the level of detail increases. Say for example we have a need that says that “
Data should be persistent” which when comes to feature will be “ System should use
relational database” which further down will be “System should use Oracle 10i
database”[13].
4.1.2 Use-case Basics
Use-Cases are the pictorial representation of the system showing the interactions between
the system and the actor, where actor can be an external system or a human. They are
derived from the requirements and help us to visualize how the system should work.
10
The general format of a use case is:

Brief description of the use-case scenario.

Flow of events for each use-case.
o
Basic flow is the flow when everything goes right. Also known as the happy
path.
o
Alternative flow is the flow when exceptions are generated in the normal
flow.

Special requirements for each use-case [13].

Pre-conditions are input conditions required for that particular use-case.

Post-conditions are the expected output or results for that particular use-case.

Context diagram [13].

Activity diagram
The basic flow contains the most popular sequence of actions, the steps that happen
when everything goes correctly. Alternative flows represent variations of the flow,
including less usual cases and error conditions. A context diagram is a part of a use case
diagram showing the relationships of this particular use case to actors and other use
cases. An activity diagram is a flow chart that explains the use case. The context
diagram and the activity diagram are not necessary, but help you visualize the use case
and its position in the project [13].
11
4.1.3 Test case Basics
We evaluate test cases to check how far the system fulfills its purpose. A Test
case contains:

Test Case ID – a test case must be uniquely identified by an ID, called test case ID

Requirement – Test case should be linked to the requirement, which it is testing.
This is need for requirement traceability which ensures that all the scenarios in the
Requirements Specification have been covered by at least one test case [14]

Priority of a test case states how important it is.

Test Case Name

Designer Name [14]

Environment details of the test environment include the platform, which it was tested
for, and other technical details.

Objective – briefly states the scenario that the test case is testing.

Pre – Test conditions – This are the conditions that needs to be satisfied before
executing the test. [14]

Design Steps – Steps that the tester needs to execute

Expected Results – explains the system output or behavior when a step is executed.

Actual Results – Recorded by tester for each step during test execution –
mentioning his/her observation.

Post Conditions
12
4.1.4 Model-based Testing
Model-based testing is a new and effective way of generating test cases from
requirements. Model-based testing is an approach in which the test cases are generated on
the basis of the data models derived from the requirements. It is different from static test
automation in which test cases are recorded, instead is more like description of an
applications behavior to compare the actual outcomes and the expected outcomes. Modelbased testing has a lot of benefits including detailed understanding of the system
behavior, early bug detection, low cost, shorter schedule, better quality and so on.
Model–based testing begins with requirements and a data model is built from those
requirements. The data model is typically used to generate test cases. Basic activities of
model-based testing are as follows:
1) Build the model [1]
2) Generate expected inputs [1]
3) Generate expected outputs [1]
4) Run tests [1]
5) Compare actual outputs with expected outputs [1]
The flow can be represented diagrammatically as shown in Figure 2:
13
Figure 2: Flow for model-based testing [1]
4.1.5 Traceability
Traceability is a technique, which helps in the reverse engineering, which is from the test
case we can go back to the requirement it is related to. Figure 3 shows how requirements
can be traced.
14
Figure 3: Traceability requirements pyramid [13]
As figure shows each need gives rise to two, three or more features and each feature has
couple of use-cases as well as supplementary specifications. And from the use-cases we
have scenarios, which help us in deriving test cases.
4.1.6 Pair-wise Testing
Pair-wise testing is a combinatorial software testing method that, for each pair of input
parameters to a system, tests all possible discrete combinations of those parameters [15].
For future enhancement of this tool we can use the concept of pair-wise testing to
minimize the number of test cases.
4.1.7 Boundary-value Analysis
Boundary value analysis is a software testing technique in which tests are designed to
include representatives of boundary values. Values on the minimum and maximum edges
of an equivalence partition are tested. The values could be either input or output ranges of
15
a software component. Since these boundaries are common locations for errors that result
in software faults they are frequently exercised in test cases [16].
4.2 The Algorithm
This algorithm is already pre-defined by IBM [13]. The algorithm used illustrates how to
derive a set of test cases from given use-case. The algorithm constitutes of the following
steps:

From a given requirement we derive a use-case.

Each use-case will have a basic flow and an alternate flow.

From that basic and alternate flow we generate set of scenarios by considering all
possible combinations of basic and alternate flow.

For each scenario, identify at least one test case and the conditions that will make
it "execute."

Identify variables for each use-case step. Say for example we have a login usecase, in which variables will be username and password.

Identify significantly different options for each variable. For username we can
have different options like the number of minimum characters allowed, number of
maximum characters allowed. For password we can have options like it should
have one special character, uppercase and lowercase letters.

Combine options to be tested into test cases.
16
The following section shows the detailed explanation of an algorithm using an example
of online bookstore system.
4.3 Example explaining the Algorithm
4.3.1 Basic flow
The Basic flow of the system would contain following steps:
1. B1 User enters web site address in the browser.
System displays login page.
2. B2 User enters an email address and a password.
System confirms correct login, presents main page, and prompts for a search
string.
3. B3 User enters search string – partial name of a book.
System returns all books matching search criteria.
4. B4 User selects a book.
System presents detailed information about a book.
5. B5 User adds the book to a shopping cart.
Shopping cart contents is presented to the user.
6. B6 User selects "proceed to checkout" option.
System asks for confirmation of a shipping address.
7. B7 User confirms shipping address.
System presents shipping options.
8. B8 User selects shipping option.
17
Systems ask which credit card will be used.
9. B9 User confirms credit card that is stored in the system.
System asks for final confirmation to place an order.
10. B10 User places the order.
System returns a confirmation number.
4.3.2 Alternate flow
The Alternate flow will be as follows:
A1
Unregistered user
If the user is unregistered it will display an error message and direct back to the login
screen where user will be asked if he/she wants to register (step 1 basic flow).
A2
Invalid password
If the user name and password don’t match that is if the password is incorrect again it
will display error message and direct back to the login screen (step 1 basic flow).
A3
No books matching search criteria were found
If there are no books matching the search criteria it will display the message “no books
matching your search” and will give user the blank search box to enter another search
(step 3 basic flow).
A4
Decline a book
18
If user declines a book matching the search criteria it will direct back to the new search
(step 3 basic flow).
A5
Continue shopping after storing a book in the shopping cart
If user is willing to search for new books after storing selected books in the
shopping cart it will direct back to the search box (step 3 basic flow).
A6
Enter a new address
If user is willing to add new address for shipping it will direct the user to a new
page where all the address details needs to be entered (step 7 basic flow).
A7
Enter a new credit card
If user is not willing to use the same credit card stored in the system user will be
directed to a new page where all the credit card details needs to be entered (step 9 basic
flow).
A8
Cancel order
If user cancels the order user will be directed to the shopping cart (step 5 basic flow).
4.3.3 Creating test cases from use-cases
Now generating test cases from the use cases is a 3-step process.
1. For each use case, generate a full set of use-case scenarios.
19
2. For each scenario, identify at least one test case and the conditions that will make it
"execute."
3. Combine options to be tested into test cases.
Step One: A Scenario is an occurrence of a use-case. It describes one specific path
through the flow of the events. We can find scenarios by drawing graph as shown in
Figure 4 where B represents the basic flow and A1, A2, A3, A4 represents the alternate
flows.
Figure 4: Finding scenarios in a use-case [13]
There is one scenario for the Basic flow and one scenario per each alternate flow plus one
scenario for the combinations of alternate flow. All the scenarios to be considered are
shown in Table 1 below:
20
Table 1: All possible scenarios [13]
Scenario Name
Starting Flow
Alternate Flow
Scenario 1- Successful
Basic Flow
Scenario 2- Unregistered User
Basic Flow
Alternate Flow 1
Scenario 3- Invalid Password
Basic Flow
Alternate Flow 2
Scenario 4- No books matching
Basic Flow
Alternate Flow 3
Scenario 5- Decline a book
Basic Flow
Alternate Flow 4
Scenario 6- Continue shopping
Basic Flow
Alternate Flow 5
Scenario 7- New address
Basic Flow
Alternate Flow 6
Scenario 8- New credit card
Basic Flow
Alternate Flow 7
Scenario 9- Cancel order
Basic Flow
Alternate Flow 8
Scenario 10
Basic Flow
Alternate Flow 1
Alternate Flow 2
21
Scenario Name
Starting Flow
Alternate Flow
Scenario 11
Basic Flow
Alternate Flow 2
Alternate Flow 3
Scenario 12
Basic Flow
Alternate Flow 3
Alternate Flow 4
Scenario 13
Basic Flow
Alternate Flow 4
Alternate Flow 5
Scenario 14
Basic Flow
Alternate Flow 5
Alternate Flow 6
Scenario 15
Basic Flow
Alternate Flow 6
Alternate Flow 7
Scenario 16
Basic Flow
Alternate Flow 7
Alternate Flow 8
22
Step Two: For each scenario, identify at least one test case and the conditions that will
make it "execute." [13]. This step has two sub-steps.
Step A: Identify variables for each use-case step for that we need to identify all input
variables in all of the steps in the given scenario [13]. For example, if in some step the
user enters a user ID and password, there are two variables. One variable is the user ID,
and the second variable is the password. The variable can also be a selection that the user
can make (for instance, Save changes or Cancel). Here are all of the variables from the
online bookstore example:
1) Web address (string)
2) Email address, password (string)
3) Search string (string)
4) Select a book (string)
5) No variable
6) No variable
7) No variable
8) Shipping options (four options 5,3,2,overnight)
9) No variable
10) No variable
23
All the variables for the Alternate flow are considered in the Basic flow.
Step B: Identify significantly different options for each variable.
Options are "significantly different" if they may trigger different system behavior. For
example, if we select a user id, which is supposed to be from 6 to 10 characters long, the
following entries are significantly different:

Alex -- because it is too short, and we expect an error message to appear

Alexandria -- because it is a valid user id

Alexandrian -- because it is too long, and we expect the system to prevent us from
entering a user id that long [13]
However, "Alexandria" and "John Gordon" are not significantly different, because they
are both valid user ids that should cause the system to react in the same way.
The following guidelines describe some specific cases.
An option can be considered significantly different:
1. If it triggers different flow of the process (usually an alternative flow)
Example
o
Entering invalid password will trigger Alternative Flow 2 [13]
2. If it triggers different error message
Example
o
If email is too long, the message is "Email should have no more than 50
characters"
24
o
If email does not contain @ sign, the message is: "Invalid email address"
[13]
3. If it causes different appearance of the user interface
Example
o
If Method of Payment is a credit card, fields to enter credit card number,
expiration date and cardholder name are shown [13]
4. If it causes different selection to be available in the drop-downs
Example
The customer registration screen may contain drop-downs "Country" and
"State/Province". The drop-down "State/Province" is populated based on the
country selected: for the US it contains all the states, for Canada all the provinces,
and for other countries it is grayed-out. This creates three different options:
o
US
o
Canada
o
Any other country [13]
5. If it is an input to some business rule
Example
Assuming there is a rule "If the order is placed after 6pm, and user select
Overnight Shipment, the message should inform that the book will arrive after
tomorrow", we may have two separate options:
o
Overnight Shipment, order placed before 6pm
o
Overnight Shipment, order placed before 6pm [13]
25
6. If it is a border condition
Example: Since password should have at least 6 characters we should test:
o
Password with 5 characters
o
Password with 6 characters [13]
7. If it changes something vs. using the default
Example: On the credit card payment screen the cardholder’s name is populated
with the name of a person placing the order. This creates two separate options:
o
Keep default cardholder's name
o
Change cardholder's name to a different one [13]
8. If the entry format is not clearly defined and may be differently interpreted by the
user
Example: different people write Phone numbers differently:
o
Using brackets (973) 123 4567
o
Using dashes 973-123-4567
o
Plain number with spaces 973 123 4567 [13]
9. If regular cases differ in different countries
Example: Credit card expiration date format may be different in the USA and in
Europe
If we are testing numbers, we may consider the following options:

Regular number, reasonable from the application point of view

Zero

Negative number
26

A number with two decimals

The biggest number that can be entered (99999999999999 - as many nines as can
fit) [13]
Table 2 shows options that were identified for variables in the basic flow of the online
bookstore example:
Table 2: Options identified for variables [13]
Step
Variable
Options to be tested
B1
Website
Actual
URL
B2
Email
Regular
Blank
Min
Max char
One
Very
Invalid
char
(50)
more
Long
(no
then max
(257)
@sign)
(1)
(51)
B2
Password
Regular
Blank
Short
Min char
Max char One
(5)
(6)
(10)
Very
more
Long
then
(257)
max
(11)
27
B3
Search
Regular
Blank
String
Min
Max char
more
char
(300)
then
(1)
B4
Selection
First
B5
Action
Add to
Selection
cart
Action
Check-
Selection
out
Shipping
Confirm
Address
address
Shipping
5days
B6
B7
B8
method
B9
B10
Payment
Confirm
method
card
Action
Place an
Selection
order
max(301)
Last
3days
2days
Overnight
28
Step Three: Combine options to be tested into test cases [13].
Table 3 below shows some of the test cases with the expected result for the test case.
Table 3: Output test cases [13]
Step Number Variable
TC1
TC2
TC3
TC4
B1
Website
Actual URL
Actual URL
Actual URL
Actual URL
B2
Email
Regular
Min char (1)
Max char
Regular
(50)
B2
Password
Regular
Min char (6)
Max char
Min char (6)
(10)
B3
Search
Regular
Min char (1)
String
B4
B5
Selection
Action
Selection
Max char
Regular
(300)
First
Last
First
Last
selection
selection
selection
selection
Add to cart
Add to cart
Add to cart
Add to cart
29
Step
Variable
TC1
TC2
TC3
TC4
Action
Proceed to
Proceed to
Proceed to
Proceed to
Selection
checkout
checkout
checkout
checkout
Shipping
Confirm the
Confirm the
Confirm the
Confirm the
address
address
address
address
address
Shipping
5 days
3 days
2 days
Overnight
Payment
Confirm the
Confirm the
Confirm the
Confirm the
method
credit card
credit card
credit card
credit card
Action
Place an
Place an
Place an
Place an
selection
order
order
order
order
Number
B6
B7
B8
method
B9
B10
30
Chapter 5
DESIGN AND IMPLEMENTATION
This tool takes use-case variables as input for the system and gives test cases as output
with test case result being true/false. All the variables that we give as input to the system
will also take values that are acceptable as well as not acceptable for that particular
variable and henceforth give us the final output. The tool is written with PHP and Java
script as backend and MYSQL database. The following sections describe the design and
implementation details for the tool.
5.1 Traceability Tool Database Design
This tool uses a MySQL database to store all the information related to the
variables. The user needs to feed MySQL server details such as username and password
for logging into the system. There are five relational database tables, namely USERS,
PROJECT, TESTCASES, VARIABLES and VARIABLEVALUES used in this system.
All these tables are created while installation. These values are also inserted into the
respective tables while installation.

The USERS table stores the login details of the users who are allowed to access
the Traceability tool database.

PROJECT table is used for storing information of the name of the project and the
author for that project.
31

TESTCASES table is used to store the name of the test cases created for each
project. There can be multiple test cases.

VARIABLE table stores all the variables for that particular test case. There can
be multiple variables for one test case.

VARIABLE VALUES table takes values for each variable that we entered in the
VARIABLE table.
5.1.1 Data dictionary
Data dictionary describes the collection of databases. The data dictionary consists of
tables created in the database by systems generated command files, tailored for each
supported back-end DBMS. Command files contain SQL Statements for CREATE
TABLE, CREATE UNIQUE INDEX, ALTER TABLE, etc using the specific statement
required by that type of database [17].
The Users table stores the login details of the users where each user is given a specific
user_id in the database (only for reference) and when user registers is asked for
username, password, email, mobile no, address, city, zip which is stored in the database
in the Users table.
Table 4: Users
Column Name
Data Type
Description
User_id
INTEGER (auto increment)
Primary Key
32
User_name
VARCHAR
User’s name
Column Name
Data Type
Description
User_password
VARCHAR
User’s Password
User_email
VARCHAR
User’s Email ID
User_mobile_no
INTEGER
User’s Mobile No
Address
VARCHAR
User’s Address
City
VARCHAR
User’s City
Zip
INTEGER
User’s Zipcode No
The Project table stores the project details where each project is given a specific
project_id in the database (only for reference) and the project name, author of the project,
project date and time are stored in the Project table.
Table 5: Project
Column Name
Data Type
Description
proj_id
INTEGER (auto increment)
Primary Key
proj _name
VARCHAR
Project Name
33
proj _author
VARCHAR
Author Name
Column Name
Data Type
Description
proj _created_by
INTEGER
User id who creates the
project – Foreign key for
users table
Proj_created_date
TIMESTAMP
Project Creation Date
The Test cases table stores the details of the test cases where test cases are associated to
respective projects.
Table 6: Test cases
Column Name
Data Type
Description
Tc_id
INTEGER (auto increment)
Primary Key – Test Case id
Tc _name
VARCHAR
Test Case Name
prj _id
INTEGER
Project id. Foreign key for
project table.
Tc_created_by
INTEGER
User id who creates the test
case – Foreign key for users
34
table
Column Name
Data Type
Description
Tc_created_date
TIMESTAMP
Project Creation Date
The Variables table stores all the information related to the variables where each variable
is given a specific vid in the database (only for reference), variable name and the test case
to which the variable is related.
Table 7: Variables
Column Name
Data Type
Description
vid
INTEGER (auto increment)
Primary Key – Variable id
vname
VARCHAR
Variable Name
Userid
INTEGER
Id of User who creates
variables. Foreign key for
USERS table.
V_test_case_id
INTEGER
Test case id for which
variables created. Foreign
key for Test Cases table.
35
The Variable values table stores the information related to the valid and invalid variable
values determined by is compulsory field.
Table 8: Variable values
Column Name
Data Type
Description
Vv_id
INTEGER (auto increment)
Primary Key – Variable
Values id
Vv_var_id
VARCHAR
Variable ID. Foreign key
for variable table.
Vv_user_id
INTEGER
Id of User who creates
variables. Foreign key for
USERS table.
Vv_value
VARCHAR
Value of Variable
Is_compulasry
FLAG
It is used to set transition
valid/invalid.
36
5.2 Entity Relationship Model
An entity-relationship (ER) diagram is a specialized graphic that illustrates the
relationships between entities in a database [18]. Figure 5 below it shows how each user
can create multiple projects, and one project can have multiple test cases, and one test
case can have multiple variables, and one variable can have multiple variable values.
Figure 5 Entity Relationship Diagram [19]
37
5.3 Data Flow Diagram
Figure 6 here shows the flow of the tool beginning from when user logs into the tool, is
directed to the page where he can add project name and author name which then leads to
adding the project name and test case name ultimately leading to adding the variables
identified for each use-case and the values that are acceptable for those variables which
gives us final output in the form of test cases under the selected project. All of the data
can be edited/deleted as per the users requirements.
Figure 6 Data flow diagram [19]
38
5.4 Sequence Diagram
Figure 7 shows how each object of the system interacts with other objects in the form of a
sequence diagram, objects and their lifelines.
Figure 7 Sequence diagram [19]
39
Chapter 6
RESULTS
6.1 Traceability Tool User Interface
The tool provides web interface to add use-case variables and convert them to appropriate
test cases. Following are the screen shots of the web interfaces used in the system.
Figure 8 Login page interface
Figure 9 Register new user interface
40
Figure 10 shows the interface to create a new project and assign an author name to
respective project.
Figure 10 Create a new project interface
Figure 11 shows the screen that is used to add test case. For that we need to select the
project we want to add the test case for. Just as shown in the figure the project selected is
ATM_Withdrawl and the test cases added is Withdraw.
41
Figure 11 Add test case interface
Figure 12 shows add variables to a test case. It allows adding new variables for the
selected test case. It displays all the variables added for that specific test case and also
allows to edit and delete already added variables.
Figure 12 Add variables interface
42
Figure 13 shows add variable values screen, which will allow the user to add valid as
well as invalid values to each variable. Also the user can specify if the value is
compulsory or not for that specific variable. As shown in the figure it is compulsory for a
PIN to be in numbers.
.
Figure 13 Add variable values interface
Figure 14 shows the Final Output screen where all test cases will be displayed along with
the Don’t Care conditions and Ture/False result for each test case.
43
Figure 14 Final output interface
6.2 Test cases
For the testing purpose an interface is designed. In this interface we need to select
the project and the test case, which we are intending to see the test cases for. This
interface is the final output and will provide us with all possible test cases along with the
result True/False. For example in the ATM_Withdrawl system we have four variables
that are: PIN, ACCOUNT, AMOUNT, RECEIPT. For all these variables we have values,
which are valid and invalid. Based on those values we have following test cases as the
Final Output.
44
Case 1:
Input: PIN: numbers [0-9]
ACCOUNT: checking’s/savings
AMOUNT: greater then zero
RECEIPT: yes/no
Output: True
Case 2:
Input: PIN: numbers [0-9]
ACCOUNT: checking’s/savings
AMOUNT: less then amount available
RECEIPT: yes/no
Output: True
Case 3:
Input: PIN: characters
ACCOUNT: don’t care
AMOUNT: don’t care
RECEIPT: don’t care
Output: False
45
Case 4:
Input: PIN: characters
ACCOUNT: don’t care
AMOUNT: don’t care
RECEIPT: don’t care
Output: False
46
Chapter 7
CONCLUSION AND FUTURE WORK
Model-based testing has been proved to be a boon to the test development team. It
can be done using any of the UML diagrams just as this was done using the use-case
diagrams. “Traceability tool” was successfully developed to convert the use-cases to the
test cases along with the expected results for those test cases. Although the tool served its
purpose it can still be enhanced in the future to achieve the following goals.

The tool generates test cases only for the variables derived from the use-cases
entered into the system. This means that the tool works for the projects with very
well defined requirements. This shortcoming needs to be addressed and the tool
can be made more dynamic, making it able to work for the system with more
generic requirements.

The tool generates a set of all possible test cases, which can be further refined in
the future to be a minimum number of test cases to be tested to achieve maximum
test coverage. This can be achieved using the Boundary value analysis and pairwise testing logic to the current algorithm.

Moreover the tool can be also extended to support other UML diagrams like
sequence diagrams, class diagrams, etc and not just use-cases.
This tool makes manual as well as automated testing easier resulting in early bug
detection and missing requirements. Adding test case generations by different models like
Marcov chains model, event flow model, etc as and when required, can make new
additions to this tool.
47
APPENDIX
Source Code
Index.php
<?php
error_reporting(0);
session_start();
include_once 'oesdb.php';
/***************************** Step 1 : Case 1 ****************************/
//redirect to registration page
if(isset($_REQUEST['register']))
{
//header('Location: register.php');
?>
<script language="javascript">
window.location="register.php";
</script>
<?php
}
else if($_REQUEST['stdsubmit'])
{
/***************************** Step 1 : Case 2 ****************************/
//Perform Authentication
48
$result=executeQuery("select * from users where
user_name='".htmlspecialchars($_REQUEST['name'],ENT_QUOTES)."' and
user_password=ENCODE('".htmlspecialchars($_REQUEST['password'],ENT_QUOTES)."','oespass')");
if(mysql_num_rows($result)==1)
{
$r=mysql_fetch_array($result);
//if(strcmp(htmlspecialchars_decode($r['std'],ENT_QUOTES),(htmlspecialchars($_REQUEST['password'],
ENT_QUOTES)))==0)
//{
$_SESSION['stdname']=htmlspecialchars_decode($r['user_name'],ENT_QUOTES);
$_SESSION['stdid']=$r['user_id'];
unset($_GLOBALS['message']);
//header('Location: getvariables.php');
?>
<script language="javascript">
window.location="createproject.php";
</script>
<?php
}
else
{
$_GLOBALS['message']="Check Your user name and Password.";
}
closedb();
49
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>Traceability Tool</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet" type="text/css" href="oes.css"/>
</head>
<body>
<?php
if($_GLOBALS['message'])
{
echo "<div class=\"message\">".$_GLOBALS['message']."</div>";
}
?>
<div id="container">
<div class="header">
<h3 class="headtext"> &nbsp;Traceability Tool</h3>
</div>
<form id="stdloginform" action="index.php" method="post">
<div class="menubar">
50
<ul id="menu">
<?php if(isset($_SESSION['stdname'])){
//header('Location: getvariables.php');
?>
<script language="javascript">
window.location="createproject.php";
</script>
<?php
}
else{
/***************************** Step 2 ****************************/
?>
<!-- <li><input type="submit" value="Register" name="register" class="subbtn" title="Register"/></li>-->
<li><div class="aclass"><a href="register.php" title="Click here to Register">Register</a></div></li>
<?php } ?>
</ul>
</div>
<div class="page">
<table cellpadding="30" cellspacing="10">
<tr>
<td>User Name</td>
<td><input type="text" tabindex="1" name="name" value="" size="16" /></td>
51
</tr>
<tr>
<td>Password</td>
<td><input type="password" tabindex="2" name="password" value="" size="16" /></td>
</tr>
<tr>
<td colspan="2">
&nbsp;&nbsp;&nbsp;&nbsp;<input type="submit" tabindex="3" value="Log In" name="stdsubmit"
class="formbutton" />
</td><td></td>
</tr>
</table>
</div>
</form>
<?php include 'footer.html';?>
</div>
</body>
</html>
Create Project.php
<?php
include 'header.php';
if(isset($_REQUEST["btnsubmit"]))
{
52
if($_REQUEST["btnsubmit"]=="Submit")
{
$str="";
if($_REQUEST["txtProj"]!="" && $_REQUEST["txtAuthor"]!="")
{
$str = "insert into project (`proj_created_by`,`proj_name`,`proj_author`) values ('".$_SESSION['stdid']."',
'".$_REQUEST["txtProj"]."','".$_REQUEST["txtAuthor"]."')";
executeQuery($str);
$flag=1;
}
}
else if($_REQUEST["btnsubmit"]=="Update")
{
$str="";
if($_REQUEST["txtProj"]!="" && $_REQUEST["txtAuthor"]!="")
{
$str = "update project set
`proj_name`='".$_REQUEST["txtProj"]."',`proj_author`='".$_REQUEST["txtAuthor"]."'
where `proj_id`='".$_REQUEST["prjid"]."'
and `proj_created_by`='".$_SESSION["stdid"]."'";
executeQuery($str);
$flag=2;
}
53
}
}
$txtProj="";
$txtAuthor="";
if($_REQUEST["q"]=="edit" && isset($_REQUEST["prjid"]))
{
$qry1=executeQuery("select * from project where proj_id='".$_REQUEST['prjid']."'");
$res1=mysql_fetch_assoc($qry1);
$txtProj=$res1["proj_name"];
$txtAuthor=$res1["proj_author"];
}
/*
?>
<script type="text/javascript" language="javascript">
function show_confirm()
{
alert("okkk");
var r=confirm("Do you really want to delete this project???");
if (r==true)
{
alert("okkk");
<?php
*/
54
if($_REQUEST["q"]=="delete" && isset($_REQUEST["prjid"]))
{
$qry1=executeQuery("delete from project where proj_id='".$_REQUEST['prjid']."'");
$res1=mysql_fetch_assoc($qry1);
$flag=3;
}
/*
?>
}
return false;
window.location="createproject.php";
/*else
{
alert("okkk");
}
</script>
*/?>
<html>
<head>
<title>Create New Project</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet" type="text/css" href="oes.css"/>
</head>
55
<body >
<?php
if($_GLOBALS['message']) {
echo "<div class=\"message\">".$_GLOBALS['message']."</div>";
die;
}
?>
<div id="container">
<div class="page">
<h2 style="text-align:center;color:#0000ff;">Add New Project</h2>
<?php
if($flag==1)
{
echo "<font color='red'><b>Record Successfully Created</b></font>";
}
else if($flag==2)
{
echo "<font color='red'><b>Record Successfully Updated</b></font>";
}
else if($flag==3)
{
echo "<font color='red'><b>Record Successfully Deleted</b></font>";
}
56
if($flag!=0)
{
echo "<meta http-equiv='refresh' content='1;url=createproject.php'>";
}
?>
<form name="createproject" id="createproject" method="post" action="createproject.php"
onSubmit="return validateform('createproject');">
<table cellpadding="20" cellspacing="20" style="text-align:center;" width="100%" >
<tr>
<td align="right"><b>Enter Project Name:</b></td>
<td>
<input type="text" name="txtProj" value="<?php if ($txtProj!="") {echo $txtProj;}?>"
onKeyUp="isalphanum(this)"
size="70">
</td>
</tr>
<tr>
<td align="right"><b>Enter Author Name:</b></td>
<td>
<input type="text" name="txtAuthor" value="<?php if ($txtAuthor!="") {echo $txtAuthor;}?>"
onKeyUp="isalphanum(this)"
size="70">
</td>
</tr>
57
<tr>
<td style="text-align:right;"></td>
<td>
<?php if ($txtProj=="" && $txtAuthor=="")
{
echo "<input type='submit' name='btnsubmit' value='Submit' class='formbutton' />";
}
else
{
echo "<input type='submit' name='btnsubmit' value='Update' class='formbutton' />";
echo "<input type='hidden' name='prjid' value='$_REQUEST[prjid]' />";
}
?>
&nbsp; &nbsp; &nbsp;
<input type="reset" name="reset" value="Reset" class="formbutton"/></td>
</tr>
</table>
<table align="center" style="text-align:center;border:1px solid #000000;" width="95%" >
<tr>
<td><b>No.</b></td>
<td><b>Project Name</b></td>
<td><b>Author Name</b></td>
<td><b>Edit</b></td>
58
<td><b>Delete</b></td>
</tr>
<tr><td colspan="5"><hr></td></tr>
<?php
$qry=executeQuery("select * from project where proj_created_by='".$_SESSION['stdid']."'");
$count=mysql_num_rows($qry);
if($count>0)
{
$i=1;
while($res=mysql_fetch_assoc($qry))
{
?>
<tr>
<td><?php echo $i;?></td>
<td><?php echo $res["proj_name"];?></td>
<td><?php echo $res["proj_author"];?></td>
<td><a href="createproject.php?q=edit&prjid=<?php echo $res["proj_id"];?>">Edit</a></td>
<td><a href="createproject.php?q=delete&prjid=<?php echo $res["proj_id"];?>">Delete</a></td>
</tr>
<tr><td colspan="5"><hr></td></tr>
<?php
$i++;
}
59
}
?>
</table>
<br><br>
</form>
</div>
<?php include 'footer.html';?>
</div>
</body>
</html>
60
BIBLIOGRAPHY
[1]
Software acquisition gold practice, model-based testing,
http://goldpractice.thedacs.com/practices/mbt/
[2]
Test case, Wikipedia free encyclopedia,
http://en.wikipedia.org/wiki/Test_case
[3]
Use-Case Management with Rational Rose and rational Requisite Pro,
www.ibm.com/developerworks/rational/.../1164_UseCaseMgt.pdf
[4]
Model-based testing in practice,
www.research.telcordia.com/papers/lott/1999-icse.pdf
[5]
MaTelo: the model-based testing concept by all4tec,
http://www.all4tec.net/index.php/All4tec/matelo-concept.html
[6]
Model-based testing with Spec Explorer,
http://research.microsoft.com/en-us/projects/specexplorer/
[7]
Spec Explorer,
http://msdn.microsoft.com/en-us/library/ee620411.aspx
61
[8]
PHP - Wikipedia, the free encyclopedia,
http://en.wikipedia.org/wiki/PHP/
[9]
Java script, Wikipedia free encyclopedia,
http://en.wikipedia.org/wiki/JavaScript
[10]
MySQL, Wikipedia free encyclopedia,
http://en.wikipedia.org/wiki/MySQL
[11]
Dream weaver, Wikipedia free encyclopedia,
http://en.wikipedia.org/wiki/Adobe_Dreamweaver
[12]
What is requirement? definition and meaning
http://www.businessdictionary.com/definition/requirements.html
[13]
Traceability from use-cases to test cases,
http://www.ibm.com/developerworks/rational/library/04/r-3217/
[14]
Basics of writing test cases-quality testing,
http://www.qualitytesting.info/forum/topics/basics-of-writing-test-cases
[15]
All-pairs testing, Wikipedia free encyclopedia,
http://en.wikipedia.org/wiki/All-pairs_testing
[16]
Boundary-value analysis, Wikipedia free encyclopedia,
http://en.wikipedia.org/wiki/Boundary-value_analysis
62
[17]
Data dictionary - Wikipedia, the free encyclopedia,
http://en.wikipedia.org/wiki/Data_dictionary
[18]
Entity relationship diagram,
http://databases.about.com/cs/specificprodutcs/g/er.htm/
[19]
Online diagram software and flowchart software,
www.gliffy.com/