=Paper=
{{Paper
|id=None
|storemode=property
|title=A Test Case Generation Technique and Process
|pdfUrl=https://ceur-ws.org/Vol-646/EMDT2010paper2.pdf
|volume=Vol-646
}}
==A Test Case Generation Technique and Process==
https://ceur-ws.org/Vol-646/EMDT2010paper2.pdf
A TEST CASE GENERATION TECHNIQUE AND PROCESS
Nicha Kosindrdecha and Jirapun Daengdej
Autonomous System Research Laboratory
Faculty of Science and Technology
Assumption University, Thailand
p4919741@au.edu, jirapun@scitech.au.edu
ABSTRACT cases. Since Unified Modeling Language (UML) is the
most widely used language, many researchers are
It has been proven that the software testing phase is using UML diagrams such as state diagrams, use-case
one of the most critical and important phases in the diagrams and sequence diagrams to generate test cases
software development life cycle. In general, the and this has led to model-based test case generation
software testing phase takes around 40-70% of the techniques. In this paper, an approach with additional
effort, time, and cost. This area is well researched requirement prioritization step is proposed toward test
cases generation from requirements captured as use
over a long period of time. Unfortunately, while many
cases [23], [24], [33]. A use case is the specification of
researchers have found methods of reducing time and
interconnected sequences of actions that a system can
cost during the testing process, there are still a perform, interacting with actors of the system. Use
number of important related issues that need to be cases have become one of the favorite approaches for
researched. This paper introduces a new high level requirements capture. Test cases derived from use
test case generation process with a requirement cases can ensure compliance of an application with its
prioritization method to resolve the following functional requirements. However, one difficulty is
research problems: unable to identify suitable test that there are a large number of functional
cases with limited resources, lack of an ability to requirements and use cases. A second research
identify critical domain requirements in the test case challenge is to ensure that test cases are able to
generation process and ignore a number of generated preserve and identify critical domain requirements [5].
test cases. Also, this paper proposes a practical test Finally, a third problem is to minimize a number of
case generation technique derived from use case test cases while preserving an ability to reveal faults.
diagram. For example, there are a lot of functional requirements
in the large software development. Software test
Index Terms - test generation, testing and quality, engineers may not be able to design test cases to cover
test case generation, test generation technique and important requirements and generate a minimum set of
generate tests test cases. Therefore, test cases derived from large
requirements or use cases are not effective in the
practical large system. This paper presents an
1. INTRODUCTION approach with additional requirement prioritization
process for automated generation of abstract
Software testing is known as a key critical phase in the presentation of test purposes called test scenarios. This
software development life cycle, which account for a paper also introduces a new test case generation
large part of the development effort. A way of process to support and resolve the above research
reducing testing effort, while ensuring its challenges. We overcome the problem of large
effectiveness, is to generate test cases automatically numbers of requirements and use cases. This allows
from artifacts used in the early phases of software software testing engineer to prioritize critical
development. Many test case generation techniques requirements and reasonably design test cases for
have been proposed [2], [4], [10], [11], [12], [15], them. Also, this allows us to be able to identify a high
[21], [22], [42], [47], [50], mainly random, path- percentage of each test case’s critical domain
oriented, goal-oriented and model-based approaches. coverage.
Random techniques determine a set of test cases based
on assumptions concerning fault distribution. Path- The rest of the paper is organized as follow. Section 2
oriented techniques generally use control flow graph to discusses the comprehensive set of test case
identify paths to be covered and generate the generation techniques. Section 3 proposes the
appropriate test cases for those paths. Goal-oriented outstanding research challenges that motivated this
techniques identify test cases covering a selected goal study. Section 4 introduces a new test generation
such as a statement or branch, irrespective of the path process and technique. Section 5 describes an
taken. There are many researchers and practitioners experiment, measurement metrics and results. Section
who have been working in generating a set of test 6 provides the conclusion and research directions in
cases based on the specifications. Modeling languages
are used to get the specification and generate test
the test case generation field. The last section 3. RESEARCH CHALLENGES
represents all source references used in this paper.
This section discusses the details of research issues
2. LITERATURE REVIEW related to test case generation techniques and research
problems, which are motivated this study. Every test
Model-based techniques are popular and most case generation technique has weak and strong points,
researchers have proposed several techniques. One of as addressed in the literature survey. In general,
the reasons why those model-based techniques are referring to the literature review, the following lists
popular is that wrong interpretations of complex major outstanding research challenges. The first
software from non-formal specification can result in research problem is that existing test case generation
incorrect implementations leading to testing them for methods are lack of ability to identify domain specific
conformance to its specification standard [43]. A requirements. The study [5] shows that domain
major advantage of model-based V&V is that it can be specific requirements are some of the most critical
easily automated, saving time and resources. Other requirements required to be captured for
advantages are shifting the testing activities to an implementation and testing, such as constraints
earlier part of the software development process and requirements and database specific requirements.
generating test cases that are independent of any Existing approaches ignore an ability to address
particular implementation of the design [7]. The domain specific requirements. Consequently, software
model-based techniques are method to generate test testing engineers may ignore the critical functionality
cases from model diagrams like UML Use Case related to the critical domain specific requirements.
diagram [23], [24], [33], UML Sequence diagram [7] Thus, this paper introduces an approach to priority
and UML State diagram [5], [43], [22], [2], [21], [15], those specific requirements and generates an effective
[32], [4]. There are many researchers who investigated test case. The second problem is that existing test case
in generating test cases from those diagrams. The generation techniques aim to generate test cases which
following paragraphs show examples of model-based maximize cover for each scenario. Sometimes, they
test generation techniques that have been proposed for generate a huge number of test cases which are
a long time. impossible to execute given limited time and
resources. As a result, those unexecuted test cases are
Heumann [23] presented how using use cases to useless. The last problem is to unable to identify
generate test cases can help launch the testing process suitable test cases in case that there are limited
early in the development lifecycle and also help with resources (e.g. time, effort and cost). The study reveals
testing methodology. In a software development that existing techniques aim to maximum and generate
project, use cases define system software all possible test cases. This can lead to unable to select
requirements. Use case development begins early on, necessary test cases to be executed during software
so real use cases for key product functionality are testing activities, in case that there are limited
available in early iterations. According to the Rational resources.
Unified Process (RUP), a use case is used to describe
fully a sequence of actions performed by a system to
provide an observable result of value to a person or 4. PROPOSED METHOD
another system using the product under development."
Use cases tell the customer what to expect, the This section presents a new high-level process to
developer what to code, the technical writer what to generate a set of test cases introduced by using the
document, and the tester what to test. He proposed above comprehensive literature review and previous
three-step process to generate test cases from a fully works [43].
detailed use case: (a) for each use case, generate a full
set of use-case scenarios (b) for each scenario, identify
at least one test case and the conditions that will make
it execute and (c) for each test case, identify the data
values with which to test. Ryser [24] raised the
practical problems in software testing as follows: (1)
Lack in planning/time and cost pressure, (2) Lacking
test documentation, (3) Lacking tool support, (4)
Formal language/specific testing languages required,
(5) Lacking measures, measurements and data to
quantify testing and evaluate test quality and (6)
Insufficient test quality. They proposed their approach
to resolve the above problems. Their approach is to
derive test case from scenario / UML use case and
state diagram. In their work, the generation of test
cases is done in three processes: (a) preliminary test
case definition and test preparation during scenario
creation (b) test case generation from Statechart and
from dependency charts and (c) test set refinement by
application dependent strategies. Figure 1 A Proposed Process to Generate Test Cases
From the above figure, the left-hand side process security, operability and maintainability requirements.
is a general waterfall process. We propose to add two The following displays the classify requirement tree:
additional processes: (a) requirement prioritization
and (b) test case generation.
The requirement prioritization process aims to be
able to effectively handle with a large number of
requirements. The objective of this process is to
prioritize and organize requirements in an appropriate
way in order to effectively design and prepare test
cases [16], [25], [37]. There are two sub-processes:
(a) classify requirements and (b) prioritize
requirements.
The classify requirement process primarily
divides and classifies requirements into four groups
[30]: (a) “Must-Have” (b) “Should-Have” (c) “Could-
Have” and (d) “Wish”. The “Must-Have”
requirements are mandatory requirements that need to Figure 2 A Classify Requirement Tree
be implemented in the system. The “Should-Have”
requirements are requirements that should be From the above figure, we propose a ranking
implemented if there are available resources. The number for each requirement. This paper prioritizes
“Could-Have” requirements are additional “Must-Have” requirements as top three ranking and
requirements that are able to be implemented if there “Wish” requirements as last three ranking. The study
are adequate resources. The “Wish” requirements are [5] reveals that domain specific requirements should
“would like to have in the future” requirements that have higher priority than both of behavioral and non-
may be ignored if there are inadequate resources. This functional requirements.
paper introduces five factors to classify the above However, when the requirement is already
requirements, as follows: classified, the next process is to prioritize those
requirements. In the requirement prioritization
Table 1 Requirement Classification process, this paper proposes to use a cost-value
approach to weight and prioritize requirements. This
Group Time Cost People Scope Success paper also proposes to use the following formula:
Must have Y Y Y N Y P(Req) = (Cost * CP) (1)
Should Where:
have Y Y Y N N • P is a prioritization value.
Could have N N Y Y N • Req is a requirement required to be prioritized.
Wish N N N Y N • Cost is a total estimated cost of coding and
testing for each requirement.
From the above table, the following shortly • CP is an user-defined customer priority value.
describes a meaning of the above factors: This value is in the range between 1 and 10. 10 is
• Time – The requirement must be implemented in the highest priority and 1 is the lowest priority.
the current version or release of software. This value aims to allow customers to identify
• Cost – There is an available of budget or fund to how important of each requirement is from their
implement the requirement. perspective.
• People – There is an available of human To compute the above cost for coding and testing, this
resources to develop and test the requirement. paper proposes to apply the following formula:
• Scope – The requirement can be removed out of Cost= (ECode*CostCode)+(ETest*CostTest) (2)
the current version or release of software. Where:
• Success – The success of system development • Cost is a total estimated cost.
rely on the requirement. • ECode is an estimated effort of coding for each
In addition, this paper secondary divides those requirement. The unit is man-hours.
requirements into two groups: (a) functional and (b) • CostCode is a cost of coding that is charged to
non-functional. The functional requirements can be customers. This paper applies the cost-value
categorized into two groups: (a) domain specific approach to identify the cost of coding for each
requirements and (b) non- domain specific requirement group (e.g. “Must-Have”, “Should-
requirements. The domain specific requirements are Have”, “Could-Have” and “Wish”). The unit is
able to identify as database specific and constraints US dollar.
requirements. For example, database connection • ETest is an estimated effort of testing for each
specific requirements and requirements for an requirement. The unit is man-hours.
interface with other systems. The non-functional • CostTest is a cost of testing that is charged to
requirements can be vary, such as performance, customers. The approach to identify this value is
similar to CostCode’s approach. The unit is US information is called use case scenario in this
dollar. paper. The example fully dressed use cases of
In this paper, we assumed the following in order to ATM withdraw functionality can be found as
calculate CostCode and CostTest. Also, this paper follows:
assumes that a standard cost for both activities is $100
per man-hours. Table 2 Example Fully Dressed Use Case
• A value is 1.5 of (“Must-Have”, “Should-Have”) Use Use Summary Basic Event Alternativ Business
– this means that “Must-Have” requirements Case Id Case e Events Rules
have one and half times cost value than “Should- Name
Have” requirements. UC-001 Withd To allow 1. Insert 1. Select (a) Input
• A value is 3 of (“Must-Have”, “Could-Have”) – raw bank's Card Inquiry amount
customers 2. Input PIN 2. Select <=
this means that “Must-Have” requirements have
to 3. Select A/C Type Outstandi
three times cost value than “Could-Have” withdraw Withdraw 3. Check ng
requirements. money 4. Select Balance Balance
• A value is 2 of (“Should-Have”, “Could-Have”) from ATM A/C Type (b) Fee
– this means that “Should-Have” requirements machines 5. Input charge if
have two times cost value than “Could-Have” anywhere Balance using
requirements. in 6. Get different
• A value is approximately 3 of (“Could-Have”, Thailand. Money ATM
“Wish”) – this means that “Could-Have” 7. Get Card machines
requirements have three times cost value than UC-002 Trans To allow 1. Insert 1. Select Amount
fer users to Card Inquiry <=
“Wish” requirements.
transfer 2. Input PIN 2. Select 50,000
Therefore, the procedure of requirement money to 3. Select A/C Type baht
prioritization process can be shortly described below: other Transfer 3. Check
1. Provide estimated efforts of coding and testing banks in 4. Select Balance
for each requirement. Thailand bank
2. Assign cost value for each requirement group from all 5. Select
based on the previous requirement classification ATM "To"
(e.g. “Must-Have”, “Should-Have”, “Could- machines account
Have” and “Wish”). 6. Select
A/C Type
3. Calculate a total estimated cost for coding and
7. Input
testing, by using the formula (2). Amount
4. Define a customer priority for each requirement. 8. Get
5. Compute a priority value for each requirement by Receipt
using the formula (1). 9. Get Card
6. Prioritize requirements based on the higher
priority value. The above use cases can be extracted into the
Once the requirements are prioritized, the next following use case scenarios:
proposed step is to generate test scenario and prepare
test case. Table 3 Extracted Use Case Scenarios
This section presents an automated test scenario Scenario Id Summary Basic Scenario
generation derived from UML Use Case diagram. Our
Scenario-001 To allow bank's 1. Insert Card
approach is built based on Heumann’s algorithm [23].
customers to 2. Input PIN
The limitation of our approach is to ensure that all use withdraw money 3. Select Withdraw
cases are fully dressed. The fully dressed use case is a from ATM 4. Select A/C Type
use case with the comprehensive of information, as machines 5. Input Balance
follows: use case name, use case number, purpose, anywhere in 6. Get Money
summary, pre-condition, post-condition, actors, Thailand. 7. Get Card
stakeholders, basic events, alternative events, business Scenario-002 To allow bank's 1. Insert Card
rules, notes, version, author and date. customers to 2. Input PIN
The proposed method contains four steps, as withdraw money 3. Select Inquiry
follows: (a) extract use case diagram (b) generate test from ATM 4. Select A/C Type
scenario (c) prepare test data and prepare other test machines 5. Check Balance
anywhere in 6. Select Withdraw
elements. These steps can be shortly described as
Thailand. 7. Select A/C Type
follows: 8. Input Balance
1. The first step is to extract the following 9. Get Money
information from fully dressed use cases: (a) 10. Get Card
use case number (b) purpose (c) summary (d)
pre-condition (e) post-condition (f) basic
event and (g) alternative events. This
Scenario-003 To allow users to 1. Insert Card TS-004 To allow users 1. Insert Card
transfer money to 2. Input PIN to transfer 2. Input PIN
other banks in 3. Select Transfer money to other 3. Select Inquiry
Thailand from all 4. Select bank banks in 4. Select A/C Type
ATM machines 5. Select "To" account Thailand from 5. Check Balance
6. Select A/C Type all ATM 6. Select Transfer
7. Input Amount machines 7. Select bank
8. Get Receipt 8. Select "To" account
9. Get Card 9. Select A/C Type
10. Input Amount
Scenario-004 To allow users to 1. Insert Card 11. Get Receipt
transfer money to 2. Input PIN 12. Get Card
other banks in 3. Select Inquiry
Thailand from all 4. Select A/C Type
ATM machines 5. Check Balance 3. The next step is to prepare test data. This step
6. Select Transfer allows to manually prepare an input data for
7. Select bank each scenarios.
8. Select "To" account
The last step is to prepare other test elements, such
9. Select A/C Type
10. Input Amount as expected output, actual output and pass / fail status.
11. Get Receipt
12. Get Card 5. EVALUATION
The section describes the experiments design,
2. The second step is to automatically generate measurement metrics and results.
test scenarios from the previous use case
scenarios [23]. From the above table, we 5.1. Experiments Design
automatically generate the following test A comparative evaluation method has proposed in this
scenarios: experiment design. The high-level overview of this
experiment design can be found as follows:
Table 4 Generated Test Scenarios 1. Prepare Experiment Data. Before evaluating
Test Scenario Id Summary Basic Scenario the proposed methods and other methods,
preparing experiment data is required. In this
TS-001 To allow bank's 1. Insert Card step, 50 requirements and 50 use case scenarios
customers to 2. Input PIN are randomly generated.
withdraw 3. Select Withdraw 2. Generate Test Scenario and Test Case. A
money from 4. Select A/C Type comparative evaluation method has been made
ATM machines 5. Input Balance among the proposed test generation algorithm,
anywhere in 6. Get Money Heumann’s technique Jim [23], Ryser’s method
Thailand. 7. Get Card
[24], Nilawar’s algorithm [33] and the proposed
TS-002 To allow bank's 1. Insert Card method presented in the previous section.
customers to 2. Input PIN
3. Evaluate Results. In this step, the comparative
withdraw 3. Select Inquiry
money from 4. Select A/C Type generation methods are executed by using 50
ATM machines 5. Check Balance requirements and 50 use case scenarios. These
anywhere in 6. Select Withdraw methods are also executed for 10 times in order
Thailand. 7. Select A/C Type to find out the average percentage of critical
8. Input Balance domain requirement coverage, a size of test cases
9. Get Money and total generation time. In total, there are 500
10. Get Card requirements and 500 use case scenarios executed
TS-003 To allow users 1. Insert Card in this experiment.
to transfer 2. Input PIN The following tables present how to randomly
money to other 3. Select Transfer
generate data for requirements and use case scenarios
banks in 4. Select bank
Thailand from 5. Select "To" account respectively.
all ATM 6. Select A/C Type
machines 7. Input Amount Table 5 Generate Random Requirements
8. Get Receipt Attribute Approach
9. Get Card Requirement ID Randomly generated from the following
combination: Req + Sequence Number.
For example, Req1, Req2, Req3, …,
ReqN.
Type of Randomly selected from the following
Requirement values: Functional AND Non-
Functional. scenario and produce test case). Therefore, less
MoSCoW Randomly selected from the following time is desirable.
Criteria values: Must Have (M), Should Have It can be calculated using the following formula:
(S), Could Have (C) and Won’t Have Total = PTime + CTime + RTime (5)
(W)
Where:
Is it a critical Randomly selected from the following
• Total is the total amount of times consumed by
requirement values: True (Y) and False (N)
(Y/N)? running generation methods.
• PTime is the total amount of time consumed by
Table 6 Generate Random Use Case Scenario preparation before generating test cases.
Attribute Approach • CTime is the time to compile source code / binary
Use case ID Randomly generated from the code in order to execute the program.
following combination: uCase + • RTime is the total time to run the program under
Sequence Number. For example, this experiment.
uCase1, uCase2, …, uCasen.
Purpose Randomly generated from the 5.3. Results and Discussion
following combination: Pur + This section discusses an evaluation result of the
Sequence Number same as Use case above experiment. This section presents a graph that
ID. For example, Pur1, Pur2, …,
compares the above proposed method to other three
Purn.
Basic Scenario Randomly generated from the
existing test case generation techniques, based on the
following combination: uCase + following measurements: (a) size of test cases (b)
Sequence Number. For example, critical domain coverage and (c) total time. Those
basic1, basic2, …, basicn. three techniques are: (a) Heumman’s method (b)
Ryser’s work and (c) Nilawar’s approach. There are
5.2. Measurement Metrics two dimensions in the following graph: (a) horizontal
The section lists the measurement metrics used in the and (b) vertical axis. The horizontal represents three
experiment. This paper proposes to use three metrics, measurements whereas the vertical axis represents the
which are: (a) size of test cases (b) total time and (c) percentage value.
percentage of critical domain requirement coverage.
The following describe the measurement in details.
1. A Number of Test Cases: This is the total
number of generated test cases, expressed as a
percentage, as follows:
% Size = (# Size / # of Total Size)*100 (3)
Where:
• % Size is a percentage of the number of test
cases.
• # of Size is a number of test cases.
• # of Total Size is the maximum number of test
cases in the experiment, which is assigned 1,000.
2. A Domain Specific Requirement Coverage:
This is an indicator to identify the number of
requirements covered in the system, particularly
critical requirements, and critical domain
requirements [5]. Due to the fact that one of the
goals of software testing is to verify and validate
requirements covered by the system, this metric
is a must. Therefore, a high percentage of critical
requirement coverage is desirable. Figure 3 An Evaluation Result
It can be calculated using the following formula:
% CRC = (# of Critical / # of Total)*100 (4) The above graph shows that the above proposed
Where: method generates the smallest set of test cases. It is
• % CRC is the percentage of critical requirement calculated as 80.80% where as the other techniques is
coverage. computed over 97%. Those techniques generated a
• # of Critical is the number of critical bigger set of test cases, than a set generated by the
requirements covered. proposed method. The literature review reveals that
• # of Total is the total number of requirements. the smaller set of test cases is desirable. Also, the
3. Total Time: This is the total number of times the graph shows that the proposed method consumes the
generation methods are run in the experiment. least total time during a generation process,
This metric is related to the time used during the comparing to other techniques. It used only 30.20%,
testing development phase (e.g. design test which is slightly less than others. Finally, the graph
presents that the proposed method is the best [10] B.M. Subraya, S.V. Subrahmanya, “Object driven
techniques to coverage critical domains. Its performance testing in Web applications”, in: Proceedings
percentage is much greater than other techniques’ of the First Asia-Pacific Conference on Quality Software
percentage, over 30%. (APAQS'00), pp. 17-26, Hong Kong, China, 2000.
[11] Chien-Hung Liu, David C. Kung, Pei Hsia and Chih-
Tung Hsu, “Object-Based Data Flow Testing of Web
6. CONCLUSION Applications”, Proceedings of the First Asia-Pacific
Conference on Quality Software (APAQS'00), pp. 7-16,
This paper concentrates on resolving the following Hong Kong, China, 2000.
research problems: (a) an inefficient test case [12] C.H. Liu, D.C. Kung, P. Hsia, C.T. Hsu, “Structural
generation method with limited resources (b) a lack of testing of Web applications”, in: Proceedings of 11th
ability to identify and coverage the critical domain International Symposium on Software Reliability
requirements and (c) an ignorance of a size of test Engineering (ISSRE 2000), pp. 84-96, 2000.
[13] Davis, A., “The Art of Requirements Triage”, IEEE
cases. Furthermore, this paper proposes an effective
Computer 36, 3 p: 42-49, 2003.
test case generation process by adding additional [14] Davis, A., “Just Enough Requirements Management:
prioritization process. The new process aims to Where Software Development Meets Marketing”, New
improve the ability to: (a) generate test cases with York: Dorset House (ISBN 0-932633-64-1), 2005.
limited resources (b) include more critical domain [15] David C. Kung, Chien-Hung Liu and Pei Hsia, “An
specific requirements and (c) minimize a number of Object-Oriented Web Test Model for Testing Web
test cases. Also, this paper introduces an automated Applications”, In Proceedings of the First Asia-Pacific
test scenario generation technique to address critical Conference on Quality Software (APAQS’00), page 111,
domain specific requirements. This paper proposes to Los Alamitos, CA, 2000.
[16] Donald Firesmith, “Prioritizing Requirements”,
compare to other three test case generation
Journal of Object Technology, Vol.3, No8, 2004.
techniques, which are: Heummann’s work, Ryser’s [17] D. Harel, “On visual formalisms”, Communications of
method and Nilawar’s technique. As a result, this the ACM, vol. 31, no. 5, pp. 514-530, 1988.
study found that the proposed method is the most [18] D. Harel, “Statecharts: A Visual Formulation for
recommended method to generate the smallest size of Complex System”, Sci.Comput. Program. 8(3):232-274,
test cases with the maximum of critical domain 1987.
specific requirement coverage and the least time [19] Flippo Ricca and Paolo Tonella, “Analysis and Testing
consumed in the test case generation process. of Web Applications”, Proc. of the 23rd International
Conference on Software Engineering, Toronto, Ontario,
Canada. pp.25-34, 2001.
7. REFERENCES [20] Harel, D., “Statecharts: a visual formalism for complex
system”, Science of Computer Programming, v. 8, p. 231-
[1] Ahl, V., “An Experimental Comparison of Five 274, 1987.
Prioritization Methods”, Master's Thesis, School of [21] Hassan Reza, Kirk Ogaard and Amarnath Malge, “A
Engineering, Blekinge Institute of Technology, Ronneby, Model Based Testing Technique to Test Web Applications
Sweden, 2005. Using Statecharts”, Fifth International Conference on
[2] Alessandra Cavarra, Charles Crichton, Jim Davies, Alan Information Technology, 2008.
Hartman, Thierry Jeron and Laurent Mounier, “Using UML [22] Ibrahim K. El-Far and James A. Whittaker, “Model-
for Automatic Test Generation”, Oxford University based Software Testing”, 2001.
Computing Laboratory, Tools and Algorithms for the [23] Jim Heumann., “Generating Test Cases From Use
Construction and Analysis of Systems, TACAS'2000, 2000. Cases”, Rational Software, 2001.
[3] Amaral, “A.S.M.S. Test case generation of systems [24] Johannes Ryser and Martin Glinz, “SCENT: A Method
specified in Statecharts”, M.S. thesis – Laboratory of Employing Scenarios to Systematically Derive Test Cases
Computing and Applied Mathematics, INPE, Brazil, 2006. for System Test”, 2000.
[4] Annelises A. Andrews, Jeff Offutt and Roger T. [25] Karl E. Wiegers, “First Things First: Prioritizing
Alexander, “Testing Web Applications”, Software and Requirements”, Published in Software Development, 1999.
Systems Modeling, 2004. [26] Karlsson, J., “Software Requirements Prioritizing”,
[5] Avik Sinha, Ph.D and Dr. Carol S. Smidts, “Domain Proceedings of the Second International Conference on
Specific Test Case Generation Using Higher Ordered Typed Requirements Engineering (ICRE'96). Colorado Springs,
Languages fro Specification” Ph. D. Dissertation, 2005. CO, April 15-18, 1996. Los Alamitos, CA: IEEE Computer
[6] A. Bertolino, “Software Testing Research and Practice”, Society, p 110-116, 1996.
10th International Workshop on Abstract State Machines [27] Karlsson, J., “Towards a Strategy for Software
(ASM'2003), Taormina, Italy, 2003. Requirements Selection. Licentiate”, Thesis 513, Linköping
[7] A.Z. Javed, P.A. Strooper and G.N. Watson. University, 1995.
“Automated Generation of Test Cases Using Model-Driven [28] Karlsson, J. & Ryan, K., “A Cost-Value Approach for
Architecture”, Second International Workshop on Prioritizing Requirements”, IEEE Software
Automation of Software Test (AST’07), 2007. September/October, p67-75, 1997.
[8] Beck, K. & Andres, C., “Extreme Programming [29] Leffingwell, D. & Widrig, D., “Managing Software
Explained: Embrace Change”, 2nd ed. Boston, MA: Requirements: A Use Case Approach”, 2nd ed. Boston,
Addison-Wesley, 2004. MA: Addison-Wesley, 2003.
[9] Boehm, B. & Ross, R.. “Theory-W Software Project [30] Leslie M. Tierstein, “Managing a Designer / 2000
Management: Principles and Examples”, IEEE Transactions Project”, NYOUG Fall’97 Conference, 1997.
on Software Engineering 15, 4: 902-916, 1989.
[31] L. Brim, I. Cerna, P. Varekova, and B. Zimmerova, Submitted for publication. Technical Report ISE-TR-04-01,
“Component-interaction automata as a verification oriented www.ise.gmu.edu/techreps/, 2004.
component-based system specification”, In: Proceedings [50] Zhu, H., Hall, P., May, J., “Software Unit Test
(SAVCBS'05), pp. 31-38, Lisbon, Portugal, 2005. Coverage and Adequacy”, ACM Comp. Survey 29(4), pp
[32] Mahnaz Shams, Diwakar Krishnamurthy and Behrouz 366~427, 1997.
Far, “A Model-Based Approach for Testing the
Performance of Web Applications”, Proceedings of the
Third International Workshop on Software Quality
Assurance (SOQUA’06), 2006.
[33] Manish Nilawar and Dr. Sergiu Dascalu, “A UML-
Based Approach for Testing Web Applications”, Master of
Science with major in Computer Science, University of
Nevada, Reno, 2003.
[34] Moisiadis, F., “Prioritising Scenario Evolution”,
International Conference on Requirements Engineering
(ICRE 2000), 2000.
[35] Moisiadis, F., “A Requirements Prioritisation Tool”,
6th Australian Workshop on Requirements Engineering
(AWRE 2001). Sydney, Australia, 2001.
[36] M. Prasanna S.N. Sivanandam R.Venkatesan
R.Sundarrajan, “A Survey on Automatic Test Case
Generation”, Academic Open Internet Journal, 2005.
[37] Nancy R. Mead, “Requirements Prioritization
Introduction”, Software Engineering Institute, Carnegie
Mellon University, 2008.
[38] Park, J.; Port, D.; & Boehm B., “Supporting
Distributed Collaborative Prioritization for Win-Win
Requirements Capture and Negotiation 578-584”,
Proceedings of the International Third World Multi-
conference on Systemics, Cybernetics and Informatics
(SCI'99) Vol. 2. Orlando, FL, July 31-August 4, 1999.
Orlando, FL: International Institute of Informatics and
Systemic (IIIS), 1999.
[39] Rajib, “Software Test Metric”, QCON, 2006.
[40] Robert Nilsson, Jeff Offutt and Jonas Mellin, “Test
Case Generation for Mutation-based Testing of
Timeliness”, 2006.
[41] Saaty, T. L., “The Analytic Hierarchy Process”, New
York, NY: McGraw-Hill, 1980.
[42] Shengbo Chen, Huaikou Miao, Zhongsheng Qian,
“Automatic Generating Test Cases for Testing Web
Applications”, International Conference on Computational
Intelligence and Security Workshops, 2007.
[43] Valdivino Santiago, Ana Silvia Martins do Amaral,
N.L. Vijaykumar, Maria de Fatima, Mattiello-Francisco,
Eliane Martins and Odnei Cuesta Lopes, “A Practical
Approach for Automated Test Case Generation using
Statecharts”, 2006.
[44] Vijaykumar, N. L.; Carvalho, S. V.; Abdurahiman, V.,
“On proposing Statecharts to specify performance models”,
International Transactions in Operational Research, 9, 321-
336, 2002.
[45] Wiegers, K., “E. Software Requirements”, 2nd ed.
Redmond, WA: Microsoft Press, 2003.
[46] Xiaoping Jia, Hongming Liu and Lizhang Qin,
“Formal Structured Specification for Web Application
Testing”. Proc. of the 2003 Midwest Software Engineering
Conference (MSEC'03). Chicago, IL, USA. pp.88-97, 2003.
[47] Yang, J.T., Huang, J.L., Wang, F.J. and Chu, W.C.,
“Constructing an object-oriented architecture for Web
application testing”, Journal of Information Science and
Engineering 18, 59-84, 2002.
[48] Ye Wu and Jeff Offutt, “Modeling and Testing Web-
based Applications”, 2002.
[49] Ye Wu, Jeff Offutt and Xiaochen, “Modeling and
Testing of Dynamic Aspects of Web Applications,