Generating test case from user interface and mining requirements

University of Engineering and Technology, VNU
Faculty of Computer Science
Generating test case from user
interface and mining
requirements
Student: Nguyen Le Hoang
ID: 08020165
Supervisor: Truong Ninh Thuan

Contents
2
Acknowledgements
The special thank goes to my helpful supervisor, PhD Trương Ninh Thuận, lecturer at
Faculty of Information Technology, University of Engineering and Technology. The
supervision that he gave truly helps the progression during my research work. Also, the
support that he gave about progression of report and information which faculty provided
about submitting report assist me in planning the report completion.
My grateful thanks also go to lectures that taught enthusiastically during my research and
study at University of Engineering and Technology and brought me the basic knowledge
in Computer Science. Thus I could easily study in the research without hesitation.
Last but not least I would like to thank my friends and my family who gave a huge
contribution during my whole progress of research.
3
Abstract
In recent years, the development of computer hardware and software has more important
steps. The development of producing software has now become a real industry. As other
industries, the function of the software has been produced increasingly complex, and the
requirement of managing the quality of software has been concerned increasingly.
Therefore, software testing must be done regularly throughout the life cycle of software
development to ensure the quality of the software.
As we know Graphic User Interface (GUI) is one of the most popular ways for users to

interact with software system. At the end of the system testing phase, the tester continued
to test the functions of the software provided by GUI and the requirement of software.
GUI makes testing the software system more difficult because of the nature of GUI
control events, the undesirable events or the infinite domain input/output which
programmer unforeseen. Through the GUI, the tester can perform black box testing to
find the errors of the software. One of the most important reasons for software testing is
to design and create the effective test cases. The cost of software testing often accounts
for 40% of the development of a software project. Therefore, reducing costs for creating
Test Case (time, effort) is one of the most important problems in software
testing. Generating test cases automatically do not only help reducing costs in creating
Test Case, but also consistent the quality of test case. Therefore, we research the methods
of creating test case from the graphic user interface and the requirement of software to
support tester for testing software.
This research report includes 4 parts: generating test case from software requirements,
generating test case from GUI, applying the method of generating test case from GUI and
software requirements for specific examples, and support tool.
After researching and testing, in Conclusion, we give some comments and summarize on
automatically test case generation tool, and set out directions for further research.
4
Value Domain Modelling
Value Domain Modelling
Value Idenfy
Value Idenfy
Requirement
Requirement
GUI
GUI
Parameter Modelling
Parameter Modelling
Testcase Generator

Testcase Generator
Output Parameter Idenfy
Output Parameter Idenfy
Chapter 1
Overview of the approach
The figure below demonstrates how to generate test case from Graphic User Interface
(GUI) and requirement of a software program.
As you see, from GUI of the program, we will identify output parameters of the program
(such as for a dialog box of a Log in modules, we will have two parameters: username
and password of user). Besides, with the requirements of the program, we will also
identify output value of each parameter which we have when analyzing GUI (example
with Log in modules, the requirement of the system is that the length of the string which
user type is less than 20 characters).
After that, we will model parameters and values to parameter domain and value domain.
Since then, we will generate test cases. How to generate test case will be represented in
the detail method bellows.
5
Funcon requirements
Requirement Chart
Requirement Tesng
Speci'caon Tesng
Script Tesng
Chapter 2
Algorithm and Implementation
2.1 Generating test case from mining requirements
Software requirements play an important role in testing software. First, the requirements
provide information to check the input / output of the program correct or not. Second, the
requirements provide information to choose test case and assess the relevance of testing.
Testing based requirements take the information of testing from the requirements of
software. In software testing, the requirements-based testing has many advantages: it is

simpler than other testing; besides it also increases the quality of software because the
development of testing phase along with the implement and design allows the use of
testing which standardize the quality of the requirements.
General progress is shown in the figure below, or simply here are the steps of the
process test case generated from software requirements.
Process test case generated from requirements includes the following steps:
Step 1: Develop the transition conditions. With a specification language, the transition
conditions are encoded directly in the specification (functional specification).With other
languages, the conditions may have a metabolic manipulation.
6
Step 2: Develop the specification graph. You can get directly from the graph specification
sheet specification.
Step 3: Develop the testing requirements. The testing requirements derived from the
transfer characteristics and are generated from the transition conditions in step 1.
Step 4: Develop the testing requirements of completeness. Build the truth tables for all
properties in the specification graph to build the partial expression trees. We can rely on
the partial expression trees or based directly on the test specification to edit the
properties.
Step 5: Develop testing state-transition pair. Identify all pairs of transition by: Listing all
the transitions in (M), all the output transitions (N), then create pairs of M * N
transition. The forward pair will be replaced by the graph properties from the
specification.
Step 6: Develop complete testing requirements. Determine the complete list of states by:
from specification chart, select the order of the state (this work performed by the
tester). Then, build the sequence of attributes.
Step 7: Build the testing specification. For each testing requirements generated prefix
value, the value of Test Case, confirm the conditions, release conditions, and the desired
result.
Step 8: Develop test scripts. Each test specification used to build a script.
2.2 Generating test case from GUI

Graphic User Interface (GUI) is one of the most popular ways for users to interact with
software system. At the end of the system testing phase, the tester continued to test the
functions of the software provided by GUI and the requirement of software. GUI makes
testing the software system more difficult because of the nature of GUI control events,
the undesirable events or the infinite domain input/output which programmer unforeseen.
Through the GUI, the tester can perform black box testing to find the errors of the
software. The problems is that how to create test case to test, find the error with the
highest performance and the minimal cost.
7
Nowadays, there are many methods of generating test case automatically, in which
combination testing methods can reduce the costs and increase the efficiency of testing
various software applications. We researched this method and apply to generating test
case automatically from GUI.
Combination testing
Combination testing is a combination of the used level parameter to generate one or more
test case. With each test case, the order of execution of the input should be identified by
the tester.
In this method, the tester first determines which parameters through the specification.
Since then, they designed using combination testing method to generate test case.
Combination testing method will be described in detail below
2.2.1 Parameter and level
P has n inputs with the corresponding values are X1, X2, …Xn. Each input is called a
parameter. Suppose that each parameter has any value as ci, 1 ≤ i ≤ n. For each value of
the parameter is called the level. | F | is the number of levels of the parameter F.
Set of values, with each parameter, called the set of parameters.
2.2.2 Combination parameters
Example 2.1:
Suppose that program P has two input variables are X and Y. In implementing P,
suppose X and Y get the corresponding value set: {a, b, c} and {d, e, f}. So we have 2
parameters and each parameter has three levels. So we have 3 * 3 = 9 combinations of

parameters: (a, d), (a, e), (a, f), (b, d), (b, e), (b, f), (c, d), (c, e), and (c, f).
In general, k parameter and each parameter can take the n value from the set value;
the number of possible combinations is n*k.
Assuming each parameter combination is a Test Case, with many programs, the test
case creation is huge. For example, if a program has 15 parameters, each parameter can
get 4 values, the total number of Test Case is 4 ^ 15 ~ 10 ^ 9. To perform a billion times t
testing is not practical for many software applications.
8
Example 2.2: User interface
GUI of a program has 3 menus: File, Edit and View as the figure
Parameter Domain Value
File New Open Save Close
Edit Select Undo Redo
View Hide Zoom in Zoom out Full screen
We have 4.3.4 = 48 combination.
2.2.3 Process to design test case
The steps to design combination testing:
Step 1: Model domain of input values. The model includes a set of parameters and
corresponding values (levels) of the parameter.
Step 2: This model is input to the design of combinatorial procedures. Combinatorial
design procedure allows creating combinatorial objects. Combinatorial object here is
simply an array parameter and the corresponding value of the parameter.
Step 3: Using the combinatorial object has been created to set up testing. A combinatorial
object is an array of parameter combinations. Each parameter can be combined to create
one or more Test Case; Test Case includes each value of the inputs and expected outputs.
However, all combinations are created is not feasible.
Here, step 2 and step 3 can be automated.
The combination of the level parameter is used to generate one or more Test Case. For
each Test Case, the order of execution of tester input should be identified.
2.3.4 Pairwise testing

The purpose of the Pairwise algorithm is to reduce the amount of test case generated
based on the input parameters that can still detect the errors of the program or system.
The details of this algorithm will be presented in detail in the examples below.
Example 4.1:
9
Let's assume a simple program which we have only two checkboxes. A checkbox can be
in one of two states—checked or unchecked. Imagine that our defect depends upon
checkbox A being unchecked and checkbox B being checked. If we try all of the possible
settings in combination with one another, we'll find the defect. We'll set up a table, with a
row for each variable. Within each cell, we'll put one of the variable's possible states—set
or cleared. In the leftmost column, we'll put an index number so that we can refer to each
combination by number.
Combination Number Box A Box B
1 Checked Checked
2 Unchecked Checked
3 Checked Unchecked
4 Unchecked Unchecked
Combinations 1, 3, and 4 work all right; but Combination 2 exhibits the problem. We'd
require four tests to make sure that we had covered all of the combinations in which A
and B could be found. Two variables and two settings for each have four combinations.
Examples 4.2: Check airplane
A little more complex example: a black-box test of a dialog with three sets of radio
buttons on it, representing travel needs in North America. The first set of radio buttons
specifies a destination, by country; the second notes the choice of an aisle or window
seat; and the third affords the choice of coach, business, or economy class. When the user
makes her selections and presses "OK" to close the dialog, the application will take on a
different path of execution for each combination of given options in given states.
As usual, the simplest kind of problem to detect is one that is triggered by a single
variable in a single state. This is called a single-mode fault (Phadke1997). For example,
consider an application that contains a defect causes it to behave bizarrely when the

"destination" option is set to "Canada". Naturally, the way to find such a defect would be
to ensure that we run at least one test with "destination" set to "Canada".
Assume now that there is a defect that depends upon two conditions—for example, the
destination field being set to "Mexico" and the service class being set to "Business" at the
same time. This is known as a double-mode fault. It should be clear if we run at least one
10
test with "destination" set to "Mexico" and the "Class" field to "Business", we'll
encounter the defect.
For two radio buttons (each with three possible states) and one checkbox, there are 3 x 3
x 2, or 18 possible values to test. Here's a table that shows each possible combination:
Test Destination Class Seat Preference
1 Canada Coach Aisle
2 Mexico Coach Aisle
3 defect USA Coach Aisle
4 Canada Business Class Aisle
5 Mexico Business Class Aisle
6 USA Business Class Aisle
7 Canada First Class Aisle
8 Mexico First Class Aisle
9 USA First Class Aisle
10 Canada Coach Window
11 Mexico Coach Window
12 defect USA Coach Window
13 Canada Business Class Window
14 Mexico Business Class Window
15 USA Business Class Window
16 Canada First Class Window
17 Mexico First Class Window
18 USA First Class Window
The most difficult kind of problem to find by black-box testing is one in which several

variables are involved, and each must be in a specific, unique state to trigger the problem.
For example, when the country field is set to "USA", the seat choice to "aisle", and the
service class to "First", then and only then will the bug be triggered. This is known as
a triple-mode fault, or more generally as a multi-mode fault, which describes faults
associated with three or more parameters. For testers, finding this kind of problem
depends on one of two approaches: testing all combinations of variables and states in the
program; or some other technique combined with well, luck. The first option is flatly
impossible for anything but the most trivial program. The key to the second option is
optimizing the tests so to be as lucky as possible.
11
In 1997, researchers at Telcordia Technologies published a paper by Siddhartha Dalal.
The content of the paper suggest that "most field faults were caused by either incorrect
single values or by an interaction of pairs of values." If that's generally correct, we ought
to focus our testing on the risk of single-mode and double-mode faults. The Telcordia
paper suggests that we can get excellent coverage by choosing tests such that
1) Each state of each variable is tested
2) Each variable in each of its states is tested in a pair with every other variable in each of
its states. This is called pairwise testing or all-pairs testing.
Focusing on single- and double-mode faults reduces dramatically the number of
combinations that we have to run. If all of the pairs in a given combination exist in other
combinations, we can drop that combination. For example, consider combination 14: the
Mexico/Business pair also appears in combination 5, the Business/Window pair appears
in combination 13, and the Mexico/Window combination appears in combination 11. We
can drop combination 14 without leaving any of its pairs untested.
Number Destination Class Seat Preference
1 Canada Coach Aisle
3 defect USA Coach Aisle
5 Mexico Business Class Aisle
8 Mexico First Class Aisle
9 USA First Class Aisle

11 Mexico Coach Window
13 Canada Business Class Window
15 USA Business Class Window
16 Canada First Class Window
This table makes sure that Canada is tested at least once with each of Coach, Business
Class, and First Class, and with the checkbox in the Aisle state and the Window state.
Similarly, every option is tested with every other option. We capture the double-mode
fault exposed in combination number 3; we need not test combination 12. Using pairwise
testing, we reduce 18 test cases to 9 test cases. The easiest thing to do is to select lines,
starting at the bottom of the table, and if all of the pairs for the line are duplicated
somewhere higher up in the table, we can remove the line.
12
Line 18 contains USA, First Class, and Window.
• the USA-First Class pair appears in line 9
• the First Class-Window pair appears in lines 16 and 17
• the USA-Window pair appears in line 12 and line 15
So we can drop line 18.
Line 17 contains Mexico, First Class, and Window
• the Mexico-First Class pair appears in line 8
• the First-Class Window pair appears in line 16
• the Mexico-Window pair appears in lines 14 and 11
We can drop line 17 too.
Line 16 contains Canada, First Class, and Window
• Canada-First Class appears in line 7
• Canada-Window appears in line 13
• First-Class-Window doesn't appear elsewhere in the table.
We must keep line 16 to preserve the First Class-Window pair.
This is an approach when the main table is very small, but a selection set with a trivial
number of options increases complexity. As we add variables or values, three things
happen. First, the size of the all-combinations table expands exponentially. Second, the

effort associated with sifting out the duplicated pairs becomes enormous. On the third
point, there is some good news: the all-pairs selection cuts the number of required
combinations much more dramatically than in our example above. Assume a program
that has 75 binary options; the table of all possible combinations of states would extend
to 2^75 entries or 37,778,931,862,957,161,709,568. Telcordia's paper notes that 75
parameters of two states each can be pair-checked with only 28 combinations.
13
So all-pairs testing is a very powerful technique for reducing the number of tests to be
run, but there are two problems to consider.
• The first problem is that if the defect in are example requires three variables to be just
so (Destination=Canada, Class=Business, and Seat Preference=Aisle), our smaller
table won't trigger the defect.
• The second problem is that an all-pairs table takes a significant time to construct and
to check for anything but a small number of variables and more possible states for
each variable. If you want to test for more than pairs triples, or n-tuples the problem
quickly becomes intractable for a human test planner.
Examples 4.3: Print
Imagine a table that contains combinations of display settings, operating systems, and
printers. One column represents display resolution (800 x 600 or Low; 1024 x 768, or
Medium; and 1600 x 1200, High); a second column represents operating systems
(Windows XP, Windows 7, and Linux); and a third column represents printer types
(PostScript, LaserJet, and Bubble Jet). We'd need a table with 3 x 3 x 3 rows—27 rows—
to represent all of the possible combinations; here are the first five rows in such a table:
Combination
Number
Display
Resolution
Operating System Printer
1 Low Win XP PostScript
2 Low Win XP LaserJet

3 Low Win XP Bubble Jet
4 Low Win 7 PostScript
5 Low Win 7 LaserJet
Writing all those options out takes time; let's use shorthand. All we need is a legend or
mapping to associate each variable with a letter of the alphabet: Low=A, Medium=B,
High=C; Win XP=A, Win 7=B, Linux=C; PostScript=A, LaserJet=B, Bubble Jet=C.
Again, this is only the first five rows in the table.
Combination
Number
Display
Resolution
Operating System Printer
1 A Â A
2 A A B
14
3 A A C
4 A B A
5 A B B
Note that the meaning of the letter depends on the column it's in. In fact, the table can
mean whatever we like; we can construct very general table using letters, instead of
specific values or levels. When it comes time to test something, we can associate new
meanings with each column and with each letter. Again, the first five lines:
Combination Number Variable 1 Variable 2 Variable 3
1 A Â A
2 A A B
3 A A C
4 A B A
5 A B B
While we can replace the letters with specific values, a particular benefit of this approach
is that we can broaden the power of combination testing by replacing the letters with

specific classes of values. One risk associated with free-form text fields is that they might
not be checked properly for length; the program could accept more data than expected,
copy that data to a location (or "buffer") in memory, and thereby overwrite memory
beyond the expected end of the buffer. Another risk is that the field might accept an
empty or null value even though some data is required. So instead of associating specific
text strings with the levels in column 3, we could instead map A to "no data", B to "data
from 1 to 20 characters", and C to "data from 21 to 65,336 characters". By doing this, we
can test for risks broader than those associated with specific enumerated values.
For example, suppose that we are testing an insurance application. Assume that Variable
1 represents a tri-state checkbox (unchecked = A = no children, checked = B = dependent
children, and greyed out = C = adult children). Next assume that Variable 2 represents a
set of radio buttons (labeled single, married, or divorced). Finally assume that Variable 3
represents a free-form text field of up to 20 characters for the spouse's first name.
Suppose further the text field is properly range checked to make sure that it's 20
characters or fewer. However, suppose that a bug exists wherein the application produces
a garbled record when the spouse's name is empty, but only when the "married" radio
15
button is selected. By using classes of data (null, valid, excessive) in Column 3, pairwise
testing can help us find the bug
With example 4.3, we can reduce 27 test cases to 9 test cases to save time and cost. Here
is the table of 9 test cases with each color represented each value of parameter: print,
resolution and OS.
A B C
2 Red Red Green
4 Red Green Red
9 Red Blue Blue
12 Blue Red Blue
14 Blue Green Green
16 Blue Blue Red
19 Green Red Red

24 Green Green Blue
26 Green Blue Green
Pairwise is a balanced design because each value has the same number of times. It
can have multiple combinations to accommodate all pairs.
Here's an example using pairwise algorithm with input parameters with only two values.
There is the detail algorithm to reduce the number of test case.
Examples 4.4
A Java applet ChemFun allows its user to create an in-memory database of chemical
elements and search for an element. The applet has 5 input factors, each with exactly two
possible values.
Factor Name Level Note
1 Operation Create, Show Two buttons
2 Name Empty, Non-Empty Data field, string expected
3 Symbol Empty, Non-Empty Data field, string expected
4 Atomic number Invalid, Valid Data field, data typed > 0
5 Properties Empty, Non-Empty Data field, string expected
Input: n=5 factors
Output: A set of factor combinations such that all pairs of input values are covered.
16
Step 1: Compute the smallest integer k such that n ≤ |S
2k-1
|.
S
2k-1
: Set of all binary strings of length 2k-1, k>0, containing k 1’s.
For k=3 we have S
5
= 10 and for k=2, S
3
= 3.

Hence, given that n=5 in our case, the desired integer is k=3.
Step 2: Select any subset of n strings from S
2k-1
.
We have, k=3 and there are the following strings in the set S
5
. After then, we select first
five of the 10 strings in S
5
.
1 2 3 4 5
1 0 0 1 1 1
2 0 1 1 1 0
3 1 1 1 0 0
4 1 0 1 1 0
5 0 1 0 0 1
6 1 1 1 1 0
7 1 0 0 0 1
8 0 1 0 1 1
9 1 1 0 0 1
10 1 0 0 1 1
Step 3: Append 0's to the end of each selected string. This will increase the size of each
string from 2k-1 to 2k.
17
1 2 3 4 5
1 0 0 1 1 1
2 0 1 1 1 0
3 1 1 1 0 0
4 1 0 1 1 0
5 0 1 0 0 1

1 2 3 4 5 6
1 0 0 1 1 1 0
2 0 1 1 1 0 0
3 1 1 1 0 0 0
4 1 0 1 1 0 0
5 0 1 0 0 1 0
1 2 3 4 5
1 0 0 1 1 1
2 0 1 1 1 0
3 1 1 1 0 0
4 1 0 1 1 0
5 0 1 0 0 1
Step 4: Each combination is of the kind (X
1
, X
2
,…, X
n
), where the value of each variable
is selected depending on whether the bit in row i, 1 ≤ i ≤ n, is 0 or 1. Replace the 0’s and
1’s with the corresponding values of each factor.
1 2 3 4 5 6
1 Create Create Show Show Show Create
2 Empty Non-empty Non-empty Non-empty Empty Empty
3 Non-empty Non-empty Non-empty Empty Empty Empty
4 Valid Invalid Valid Valid Invalid Invalid
5 Empty Non-empty Non-empty Empty Non-empty Empty
T = { t1 :< Button = Create, Name = “”, Symbol =”C”, Atomic =6, Properties = “”>
t2 :< Button = Create, Name = “Carbon”, Symbol =”C”, Atomic = -6, Properties = “Non-
metal”>

t3 :< Button = Show, Name = “Hydrogen”, Symbol =”C”, Atomic = 1, Properties =
“Non-metal”>
t4 :< Button = Show, Name = “”, Symbol =”C”, Atomic = 6, Properties = “”>
t5 :< Button = Show, Name = “”, Symbol =””, Atomic = -6, Properties = “Non-metal”>
t6 :< Button = Create, Name = “”, Symbol =””, Atomic = -6, Properties = “”>}
The total number of combinations is 2
5
= 32. Requiring only pairwise coverage reduces
the tests to 6.
18
1 2 3 4 5 6
1 0 0 1 1 1 0
2 0 1 1 1 0 0
3 1 1 1 0 0 0
4 1 0 1 1 0 0
5 0 1 0 0 1 0
Chapter 3
Applying the method for specific examples
3.1 Testing Login form
Login dialog for an application: The purpose of this dialog box to authenticate users and
allow users to log or block users logged into the system. Suppose that there are
management and user and password processing components for each user. We have the
GUI of the software as follows:
From GUI of the program, we can see that test case set which we will generate includes 3
parameters: username, password and button
Besides, the software requirements of this dialog are:
• A text box allows you to type user name: allows the user to enter registered user
name. Each user corresponds to a string has the limit length: 20
characters. If users click the OK button, the program will check the entered
password or not; and if the password entered is correct, users can log in to the system.

• A text box allows you to type password: allows the user to enter password. Password
is a string with the length limit: 20 characters. If the user has given a valid user
name and if the user clicks OK, the program will compare the entered password with
the stored password, and the application will start. If not, users will be blocked.
19
Therefore, we have 3 parameters: User Name, Password, and Button. For the values of
each parameter as follows:
• User Name: [Username <= 20 character, Username > 20 character, Empty]
• Password: [Password Correct, Incorrect Password, Empty]
• Button: [OK, Cancel]
Comments:
Theoretically, a textbox with a limit of 20 characters can have the hundreds of thousands
possibility. By adding application logic, only 3 have reduced the possibility for a textbox.
We have the following description:
Parameter Values Examples
1 User Name Username < =20 character
Username >20 character
Empty
John
Alexandra Joseph
2 Password Correct Password
Incorrect Password
Empty
123456
45678
3 Button - OK
- Cancel
The total number of combinations is 3*3*2= 18. Requiring only pairwise coverage
reduces the tests to 9.
3.2 Testing Find Student form

Assume that we need to test GUI modules for searching of a student in the high school
student management software. The interface of this module is as shown below figure.
20
Analyzing GUI of the program: we have 5 parameters: student ID, name, school year,
semester and button.
Analyzing the requirement of the program:
• Student ID: teacher will enter his/her student ID to search. A student ID includes an 8-
digit integer number. When we enter into the box, three cases are: valid
data (student ID includes 8 digits in the database) or invalid (enter an incorrect 8-
digit or enter the 8 letters number is not in the database) or blank.
• Name: teacher enters the name of the students. The name is a string with the length:
less than 20 characters. When students enter the name, these cases are: valid (enter the
correct students with their names in the database), invalid (enter more than
20 characters, enter the name is not in the database) or blank.
• School year: the user selects the drop-down list: 2009-2010, 2010-2011 and 2011-
2012
• Semester: I or II
Here is a detail table of parameter and value
TT Parameter Value Example
1 Student ID Valid
Invalid
Empty
08020165
-1, #,
21
2 Name Valid
Invalid
Empty
3 School year 2009-2010
2010-2011

2011-2012
4 Semester I
II
5 Button Find
Exit
Detail
The total number of combinations is 2*2*3*2*3 = 72.
22
Chapter 4
Support tool
In the software development company, most of the work of testers is done manually by
hand. One of the important works in the testing process is the creation of test case. To
solve this problem, we will build a tool from the method of generating test case from GUI
and requirement that were introduced in previous chapters.
4.1 Design features
4.1.1 Design Overview
Automatic test case generation tools will open a file that contains the values of the
component interface in a project of a program for analyzing the components input, and
then will model the parameters and the value domain of the parameters (or equivalence
classes), the expected result is shown Boolean, conditions are seen as the logical
expression using the parameters predefined domain and link them with the values
expected results. In addition, Null is a condition for determining the undesirable
combination to reduce the number of test results.
Test case generated file can be saved with the application of MS Excel, XML Based on
model testing; the tool will do the hardest work of tester. The tool will generate all
possible combinations of the parameters and its value domain. After generating test case,
the tool will apply the provisions of the linked model, the expected results with the
combination to remove the unwanted combination.
In order to reduce test case, first of all, good testers need to open the interface file of a
project, the program will automatically search for the interface elements and then will

automatically generate the parameters and the value of the parameter, and is to appear on
the screen test. After receiving the parameters and values of each parameter, testers will
check to see which one suit parameters or not to update, add or remove parameters to
appropriate for the requirements of the program. To describe a test case should have
expected results. This result we can see in the specification of the software. In addition,
the tester also enter additional conditions, to rely on this condition can eliminate
redundant Test Case.
23
4.1.2 Class graph
Specific purpose of the class (Class) as follows:
1. Class Parameter: Indicates that the information of a parameter includes:
• Name of parameter.
• The value of that parameter (stored in an IDictionary here so have the advantage
of searching)
• The sample value of that parameter (Save with a IDictionary)
2. Class Result: Indicates the information of the result, including:
• Name of the result
• Detailed description of results
• Model results
3. Class SingleCondition: For the information of a single condition. In a condition of the
program will have a single or multiple conditions, including the properties:
• Two argument of the single conditions
• Combination of two operators (enum type)
4. Class Condition: Indicates the information of the condition, including the properties:
• Name of the condition
• The formula of this condition
• The name of the selected results to show the results of this condition
• A Boolean variable that is selected or not conditions
5. Class Test Case: For a Test Case information includes:
• Code Test Case

• The parameter name
• Name Results
In addition, we use global GlobalVar Class: save the global variables used for the entire
program, including:
IDictionary parameters: save all the parameters of the program
IDictionary results: save all the program's results
IDictionary formula: Save all of the conditions of the program
Data Table Test Case: Save the resulting information arising after Test Case
Save file path: to know the path to save the program file
4.2 Implementation
Program language: C#.
24
Programming tool: Visual Studio 2010
Here is the interface of the program
4.2.1 Interface form
This form allows us to enter an interface file of a project program.
• When users press the Open, a dialog box will appear to scan for interface file in the
computer.
• After the user press Analyze, the interface components of the program will appear in
the next table.
• Finally, the user press Save, this program automatically models these components
to these parameters and these values of the parameters and only if the user to open the
Parameters tab, they will appear in the table.
4.2.2 Parameter form
This form allows you to type all the parameters appear on the GUI.
Users enter the parameter name, and then click Add:
Check the name of the parameter existing in Dictionary or not:
• Report if the parameter already exist.
25