Automatic Test Case Generation using UML

Chapter 1

Introduction

IEEE definition of software testing is executing the program with intent of finding errors. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. Quality is not an absolute term; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behavior of the product against a specification. A common practice of software testing is performed by an independent group of testers after the functionality is developed before it is shipped to the customer. This practice often results in the testing phase being used as buffer to compensate for project delays, thereby compromising the time devoted to testing. Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes . Software testing process can produce several artifacts. The software testing document, which consists of event, action, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected result. This can be as pragmatic as 'for condition x your derived result is y', whereas other test cases described in more detail the input scenario and what results might be expected. It can occasionally be a series of steps (but often steps are contained in a separate test procedure that can be exercised against multiple test cases, as a matter of economy) but with one expected result or 1

Automatic Test Case Generation using UML

expected outcome. The optional fields are a test case ID, test step or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repository. In a database system, you may also be able to see past test results and who generated the results and the system configureuration used to generate those results. These past results would usually be stored in a separate table . Object-Oriented Testing Object-Oriented testing basically focus on classes and objects. These testing techniques focus on classes and objects. Features such as class inheritance and interfaces support polymorphism in which code manipulates objects without their exact class being known. Testers must ensure that the code works no matter what the exact class of such objects might be. Features that support data hiding complicate testing because operations must be added to a class interface by the developer just to support testing [1,3]. Categories of object oriented testing: Model testing Class testing instead of unit testing Class interaction testing instead of integration testing System and subsystem testing Acceptance testing Self-testing UML Design Based Testing 2

Automatic Test Case Generation using UML

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other nonsoftware systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is very important for developing object oriented software. The UML uses mostly graphical notations to express the design of software projects. Use of UML helps project teams communicate, explore potential designs, and validate the architectural design of the software. Testing generally divided into two kinds: Verification Validation So design based testing mainly focus on verification testing. The promising alternative for testing object-oriented software is use of UML based designs. UML based designs give detailed specifications of expected functionality. Why we need verification testing on the design? Because a good design leads to appropriate code, but a poor design of software results in poor coding. The poor software design may suggest inappropriate test cases, which further affects the end product. So appropriate and good quality design is essential for producing testable code [1]. UML diagrams may be used for generating test cases automatically. As use case diagram elaborate the static behavior of software, main focuses is on use case and Sequence diagram elaborate the dynamic behavior of software. In sequence diagram we focus on message calling between object and class with different relationships like calling message, calling return etc.

1.2 Origin of the Problem

3

Automatic Test Case Generation using UML

Testing is very important part of software development process. It takes half of the time of the software development. Testing is performed on the requirements, code and design with different methodologies. But still failure rate of the software project is about 80%. The reason for failure is because the testing performed on the code is not sufficient to detect various types of errors in the software. Generally practitioners consider code testing as most important. As the behavior of the executable code can be tested and practitioners consider only faults in code as software failure. So testing only code and ignoring all other artifacts may result in catastrophic type of failure. Design phase is very important part because whole coding part depends on this phase. But generally testing of software design is avoided or done partially. Because design is not executable part. So testing of a design becomes very cumbersome. To solve that generally unified modeling language (UML) is used. UML deals with object oriented design method. UML has different diagrams that specify all design behaviors like static and dynamic behavior. In present work UML design based automatic testing is proposed with following objectives: To explore existing design based testing techniques. To investigate UML based object oriented design testing. To develop a UML based automated design testing technique.

1.3 Contribution
Intelligent searching techniques have been developed in order to provide a solution to the issue of finding information relevant to the user needs, and the problem of information overload - when far too much information is returned from a search. We employ this technique to introduce an automatic tool which used to generate the test cases automatically according to the systems requirement. The tool uses two steps for generating test cases. First, the systems requirements are transformed into a Unified Modeling Language (UML) Use-case Diagram. Second, the test cases will be automatic generated according to the use cases respectively. In the workspace, the Toolbox is used in order to 4

Automatic Test Case Generation using UML

ease the drawing of the use-case diagram. As well as allowing a user to layout the requirements of the system via a use-case diagram in the provided workspace, a user also may type-in the properties for each of the use cases used. Once the usecase diagram has been finalized, it can be save for further used and modification. The engine of the tool will take the use cases from the use-case diagram and search the query string (keyword) used in the tools library. The searching engine uses both search keyword and additional information of the use-case diagram. This combination will result in improving data retrieval performance. Once the use case used matches the keyword inside the tools library, the engine will automatically generate its respective test cases according to its use case [1,4]. The tool is used to generate the test cases automatically according to the systems use cases. These test cases are important to be used in analyzing and validating the requirements of the system.

1.5 Functionality And Applicability

Automatic Test Case Generation using Use Case Diagram is a purely research project which introduces a new methodology for generation of test cases in design phase. 1) It will accept a use case diagram from the user . 2) It will accept an event flow from the user related to the use case. 3) By correlating the use case and the event flow software can generate test cases. Summary

Automatic Test Case Generation using UML

This chapter includes introduction, problems faced in last phase testing, contribution for problem given by project and in short features and applications of this project. Outline of each chapter is also given in short.

~~

Chapter 2

Background Information and Literature Review

The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing Object Oriented software and the software development process. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, and load balancing and fault tolerance.[2] 6

Automatic Test Case Generation using UML

2.2 History of UML

Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design [19]. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language. By the mid-1990s, new iterations of these methods began to appear and these methods began to incorporate each others techniques, and a few clearly prominent methods emerged [1]. The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method. As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace,allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well [5]. The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in June and October of 1996. During 1996, the UML authors invited and received feedback from the general community. They incorporated this feedback, 7

Automatic Test Case Generation using UML

but it was clear that additional focused attention was still required. While Rational was bringing UML together, efforts were being made on achieving the broader goal of an industry standard modeling language. In early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory) and Richard Soley (then Chief Technology Officer of OMG) decided to push harder to achieve standardization in the methods marketplace. In June 1995, an OMG- hosted meeting of all major methodologists (or their representatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of the OMG process.[3] During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response. Rational established the UML Partners consortium with Digital several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to the UML 1.0 definition included: Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. This collaboration produced UML 1.0, a modeling language that was well defined, expressive, powerful, and generally applicable. This was submitted to the OMG in January 1997 as an initial RFP response. In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the MG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the OMG for their consideration and adopted in the fall of 1997[4]. The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems [19]. The UML represents a collection of best engineering practices that have proven successful in the modeling of 8

Automatic Test Case Generation using UML

large and complex systems. The UML is a very important part of developing Object Oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

2.3 Goals of UML

The primary goals in the design of the UML were: Provide users with a ready-to-use, expressive visual modeling language so they provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the OO tools market.

2.4 Need of UML

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, and load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.[6]

2.5 Types of UML Diagrams

Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include[4]:

Automatic Test Case Generation using UML

Use Case Diagram displays the relationship among actors and use cases Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. Sequence Diagram displays the time sequence of the objects participating This consists of the vertical dimension (time) and horizontal

in the interaction.

dimension (different objects). Collaboration Diagram displays an interaction organized around the

objects and their links to one another. Numbers are used to show the sequence of messages State Diagram Displays the sequences of states that an object of an

interaction goes through during its life in response to received stimuli, together with its responses and actions. Activity Diagram displays a special state diagram where most of the

states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing. Component Diagram displays the high level packaged structure of the

code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time. Deployment Diagram displays the configuration of run-time processing

elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units. Proposed work mainly focuses on use case diagram and sequence diagram 2.5.1 Use Case Diagram A use case diagram is a type of behavioral diagram defined by and created from a Usecase analysis. Its purpose is to present a graphical overview of the functionality provided

10

Automatic Test Case Generation using UML

by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted[2]. 2.5.1.1 Diagram building blocks Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case. Actor Generalization One popular relationship between Actors is Generalization/Specialization. This is useful in defining overlapping roles between actors. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general actor.

11

Automatic Test Case Generation using UML

Figure 1: an example of Use Case Diagram

Use Case Relationships Three relationships among use cases are used in often practice. Include In one form of interaction, a given use case may include another. "Include is a Directed Relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case" The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from multiple use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label "include". This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no parameters or return values. To 12

Automatic Test Case Generation using UML

specify the location in a flow of events in which the base use case includes the behavior of another, you simply write include followed by the name of use case you want to include, as in the following flow for track order. Extend In another form of interaction, a given use case (the extension) may extend another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label "extend". Notes or constraints may be associated with this relationship to illustrate the conditions under which this behavior will be executed. Modelers use the extend relationship to indicate use cases that are "optional" to the base use case. Depending on the modeler's approach "optional" may mean "potentially not executed with the base use case" or it may mean "not required to achieve the base use case goal". Generalization In the third form of relationship among use cases, a generalization/specialization relationship exists. A given use case may have common behaviors, requirements, constraints, and assumptions with a more general use case. In this case, describe them once, and deal with it in the same way, describing any differences in the specialized cases. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general use case (following the standard generalization notation). 2.5.1.2 Advantages For writing functional requirements Use Cases help you discover functional requirements. Use Cases allow you to capture the users need by focusing on a task that the user needs to do. Use Cases help you define the right functionalities. As you centre on the users need, the Use cases help ensures that the correct system is developed by capturing the requirements from the user's point of view.

13

Automatic Test Case Generation using UML

Use Cases are easy to read. Because you first describe a main success scenario and only after all the extensions, the reader is not immediately lost but can focus on a simple scenario first. Use Cases are easy to read by the customer. Use Cases are written from the user perspective, like a user manual. Use Cases gives an immediate feedback to the customer. Use cases are popular largely because they tell coherent stories about how the system will behave in use. The users of the system get to see just what this new system will be. They get to react early, to fine-tune or reject the stories ("You mean well have to do what?"). Use Cases modeling is cheap. There is no need for an expensive computer-aided software engineering (CASE) tool. The UML diagram only needed is a Use Case diagram. The UML sequence diagram for exchange between the user and the system can be drawn at the beginning but the final document will contain simple text with numbered actions: 1. The User does that2. The System does that 3. The user does that Use Cases help you find the boundary of the system. What is in are the Use Cases and what is out are the Actors (actors in Use Cases methodology are not only human users but also external systems, devices, software components) If we use a use Case template with Use-Goal, Scope, Level, Stakeholders and interests, Preconditions, Success Guarantee, Minimal Guarantees, Main Success Scenario, extensions conditions, extensions handling, business rules, GUI then: Use Cases help you organize the text of your functional document. Customers and developers find them way because you group in each Use Case the Scenario, extensions handling and business rules. Use Cases help you find all the exceptions and alternatives. As the main success scenario is a sequence of simple steps, you can go through each step and check what else the user could do or what in the system can goes wrong.

14

Automatic Test Case Generation using UML

Use Cases help oblige you to write all extensions handling. With the template you are obliged to list all extensions conditions and then to document what to do when they occur. Without it, many error conditions stay undetected until some programmer discovers them while in the middle of typing a code fragment. That is very late to be discovering new functions and business rules. The business experts usually are gone, time is pressing, and so the programmers type whatever they think up at the moment, instead of researching the desired behavior. Use Cases help you discover requirements for all stakeholders. If you write a paragraph with the stakeholders and their interest in the Use Case, you dont only write requirements for the primary actor but also for other interested parties. Use Cases help you check the completeness of your document. If you write a paragraph with the stakeholders and their interests in the Use Case, you can check that their interests are fulfilled by the different scenario and by the business rules. Use Cases help you organize your project. You can assign each Use Case a complexity, a priority, a cost, timing, and a status. Use Cases help you define iterations. As the Use Cases must give a business value to the user (at least the User-Goal ones), you can define each iteration as a group of Use Cases. The customer will know the added value of each iteration. Use Cases help you define your test cases. Actually each scenario and extension condition can be mapped to one test scenario. Test scenarios are grouped by Use cases. Use Cases help you in the Change Management. When a change is asked you can select which Use Cases will be impacted and the resulting changes in your code. Use Cases are popular. 2.5.2 Sequence Diagram Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass [19]. The diagrams are read left to right and descending. The example below shows an object of class 1 start the behavior by sending a message to an object of class 2. Messages pass between the different objects until the 15

Automatic Test Case Generation using UML

object of class 1 receives the final message.

Figure 2.1: Sequence Diagram

Below is a slightly more complex example. The light blue vertical rectangles the objects activation while the green vertical dashed lines represent the life of the object. The green vertical rectangles represent when a particular object has control. The represents when the object is destroyed. This diagram also shows conditions for messages to be sent to other object. The condition is listed between brackets next to the message. For example, a[condition] has to be met before the object of class 2 can send a message () to the object of class 3.[3].

Figure 2.2: Message Sequence (a)

The next diagram shows the beginning of a sequence diagram for placing an order. The object an Order Entry Window is created and sends a message to an Order object to prepare the order. Notice the names of the objects are followed by a colon. The names of the classes the objects belong to do not have to be listed. However the colon is required to denote that it is the name of an object following the object Name: className-naming 16

Automatic Test Case Generation using UML

system. Next the Order object checks to see if the item is in stock and if the [In Stock] condition is met it sends a message to create a new Delivery Item object.

Figure 2.3: Message Sequence (b)

The next diagrams add another conditional message to the Order object. If the item is [Out of Stock] it sends a message back to the Order Entry Window object stating that the object is out of stack.

Figure 2.4: Message Sequence (c)

This simple diagram shows the sequence that messages are passed between objects to complete a use case for ordering an item. 2.5.2.1 Advantages Help you discover architectural, interface and logic problems early

17

Automatic Test Case Generation using UML

Because they allow you to flesh out details before having to implement anything, sequence diagrams are useful tools to find architectural, interface and logic problems early on in the design process. You can validate your architecture, interfaces, state machine and logic by seeing how the system architecture would handle different basic scenarios and special cases[7]. This is particularly true for systems involving the interaction of components that are being implemented in parallel by different teams. In the cell phone example, each task would typically be implemented by a separate team. Having a set of sequence diagrams describing how the interfaces are actually used and what messages/actions are expected at different times gives each team a consistent and robust implementation plan. You can also document how special cases should be handled across the entire system. The very act of creating the sequence diagrams and making them work with your architecture is valuable because it forces you to think about details such as interfaces, states, message order, and assignment of responsibilities, timers/timeouts and special/error cases ahead of time. Collaboration tool Sequence diagrams are valuable collaboration tools during design meetings because they allow you to discuss the design in concrete terms. You can see the interactions between entities, various proposed state transitions and alternate courses/special cases on paper as you discuss the design. Documentation Sequence diagrams can be used to document the dynamic view of the system design at various levels of abstraction, which is often difficult to extract from static diagrams or even the complete source code. The diagrams can abstract much of the implementation detail and provide a high level view of system behavior.

2.6 Testing overview

2.6.1 Black Box Testing Black box is testing without knowledge of the internal workings of the item being tested [20]. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not 18

Automatic Test Case Generation using UML

how the program actually arrives at those outputs. It is because of this that black box testing can be considered testing with respect to the specifications; no other knowledge of the program is necessary. For this reason, the tester and the programmer can be independent of one another, avoiding programmer bias toward his own work. For this testing, test groups are often used, "Test groups are sometimes called professional idiots.. people who are good at designing incorrect data. Also, do to the nature of black box testing; the test planning can begin as soon as the specifications are written. The opposite of this would be where test data are derived from direct examination of the code to be tested. For glass box testing, the test cases cannot be determined until the code has actually been written. Both of these testing techniques have advantages and disadvantages, but when combined, they help to ensure thorough testing of the product. 2.6.1.1 Advantages of Black Box Testing More effective on larger units of code than glass box testing. Tester needs no knowledge of implementation, including specific programming languages. Tester and programmer are independent of each other. Tests are done from a user's point of view. Will help to expose any ambiguities or inconsistencies in the specifications. Test cases can be designed as soon as the specifications are complete. 2.6.1.2 Disadvantages of Black Box Testing Only a small number of possible inputs can actually be tested, to test every Without clear and concise specifications, test cases are hard to design. There may be unnecessary repetition of test inputs if the tester is not informed of May leave many program paths untested. Cannot be directed toward specific segments of code which may be very Most testing related research has been directed toward glass box testing 19 complex (and therefore more error prone) test cases the programmer has already tried.

possible input stream would take nearly forever.

Automatic Test Case Generation using UML

2.6.2 White Box Testing White box testing is very different in nature from black box testing [21]. Purpose of white box testing is to make sure that Functionality is proper Information on the code coverage White box Testing is primarily development of team jobs, but now test engineers have also started helping development team in this effort by contributing in writing unit test cases, generating data for unit test cases etc. White box testing can be performed at various levels starting from unit to system testing. Only distinction between black box and white box is the system knowledge, in white box testing you execute or select your test cases based on the code/architectural knowledge of system under test. Even if you are executing integration or system test, but using data in such a way that one particular code path is exercised, it should fall under white box testing. There are different types of coverage that can be targeted in white box testing Statement coverage Function coverage Decision coverage Decision and Statement coverage

2.7 Literature review

A literature review is a body of text that aims to review the critical points of current knowledge on a particular topic. Literature work regarding Use case diagram and sequence diagram mention below. There are several discussions on how using usecases may help testing process to be done early in the development lifecycle. Jacobson et al. (4) explained tests can be derived from use cases in three types: First, tests of the expected flow of event; second, tests of unusual flow of events; and third, test of any requirements attached to a use case. Unfortunately,

20

Automatic Test Case Generation using UML

Jacobson et al. (4) did not discuss on how to choose test cases and how to know when you are done. Binder (8), Heumann (6) and Wood et al. (3) derive test cases directly from requirements in natural language. Wood et al. (3) state that the most integral part of use case for generating test cases is the Event Flow (basic flow and alternate flow). The next step is creating the scenario based on the Event Flow before it can be used to generate the test cases. However, automating the testing operation can reduce the cost and improve the reliability and effectiveness of software testing. Gutierez et al. (5) and Nebut et al. (2) have showed how testing operation can be automated. Nebut et al. (2) study an approach for automating the generation of system test scenarios from use cases in the context of object oriented embedded software and taking into account traceability problems between highlevel views and concrete test case execution. In this paper, we are going to use use-case diagrams to automatically generate test cases. These test cases will become a checked list for software engineers in order to validate the systems requirement at the early software development stages Summary This chapter has given the details of the Unified Modeling Language, as well as work done by the different researchers in the same concept

~~

21

Automatic Test Case Generation using UML

Chapter 3

Existing System with Limitation and Problem Formulation

This chapter describes the gap in the existing work and problem formulation. The gap in existing work shows, what are the limitation in the existing work and which technique they are used. In problem formulation, we give appropriate solution to solve the existing problem and suggest the novel work.[2,3,8]

3.1 Gaps in Existing System

In UML Use case Diagram Based Testing Using Verification testing performed with the help of design review and it tells about how to verify design. It has syntax testing, domain expert testing and traceability testing. It does not deal with automated testing. It does not have any test case generation technique.

3.2 Problem Formulation

Generally testing is performed on coding part, which contain statements, loops, classes and functions. This type of testing cannot fix problems because if we change the executable statements of software then number of test cases also change, because we check logical part of software and plan the test case. Like if a program has two loops then its test cases are to test the functionality of only these two loops, if we add another loop then total loops are three and its test cases will also increase. That means increase in statements leads to rise in complexity, which will affect the test plan and test case structures. Same in object oriented programming methodology, it contains classes and functions. We want to change class scope that means public, private, protected or we want to add new class that is inherited from or dependant upon other classes then it is very difficult task to find which module is affected 22

Automatic Test Case Generation using UML

by this change and what is the affect on other modules. It is very difficult to identify test cases required to fix this problem and also to know whether these test cases are optimal or not. One solution is we use code review to fix that problem but its not efficient because each programmer has own style of coding, so coding review is difficult task. Another alternative is to perform dynamic testing that means run software and check behavior of software. But these procedures again indirectly focus on coding review for finding errors or change effect. Coding review is not much efficient method, which is used in structured and object oriented approach. So we proposed a novel solution that is design based testing. In software development life cycle design part first than coding or implementation part. Testing problem should be applied on design rather than coding because a software design is converted into code. So if problem occur in design, code will be error full. To perform design based testing, we can use Unified Modeling Language (UML). UML has different design diagrams that are used to specify the software behavior i.e. static and dynamic. UML diagram methodology is applied on object-oriented approach, not on structured approach. Many researchers and practitioners are working on UML based testing. UML based testing is independent of code; it specifies general behavior of software. This type of design easily deployed on any languages like C++, java etc. We can perform all testing techniques on UML design. UML deals with different diagrams like class, sequence, activity, state chart, component diagram, object, collaboration diagram. All these diagrams used for testing. With help of design we can produce test cases from UML diagrams. All diagram related with each other, they can be combined them and testing can be perform. But they are some limitations like: UML is a graphical view of software. If an automated testing is performed on UML design, it is difficult. Automated testing means automatically generate test cases from design.

23

Automatic Test Case Generation using UML

How to combine two UML diagram and perform testing i.e. how we can pass the information from one UML diagram to another UML diagram for efficient. So these limitations can be resolved with help of proposed system. In the proposed system, testing is performed with the help of only one diagram i.e. Use case diagram. With the help of this diagram we can find out optimal solution and perform better testing than previous approach.

Summary
This chapter has given the limitation of existing system and problem formulation.

~~
Chapter 4

Proposed System
4.1 Introduction
The proposed system focuses on the Use case diagram and Sequence Diagram. Various types of information are extracted from these diagrams to generate test cases.

4.2 Use Case Diagram

A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. What does this mean? An actor is a user playing a role with respect to the system. Actors are generally people although other computer systems may be actors. A scenario is a sequence of steps that describe the interactions between an actor and the system. The use case model consists of the collection of all actors and all use cases. Use cases help us[9] capture the system's functional requirements from the users' perspective actively involve users in the requirements-gathering process provide the basis for identifying major classes and their relationships serve as the foundation for developing system test cases 24

Automatic Test Case Generation using UML

4.2.1 UML Use Case Diagram Related Work

UML Use Case diagram related work discuss below [3]: We will use three independent approaches to test our diagrams:

Syntax "Does the diagram follow the rules?

Domain Expert "Is the diagram correct?" "What else is there that is not described in this diagram?" traceability A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. What does this mean? An actor is a user playing a role with respect to the system. Actors are generally people although other computer systems may be actors. A scenario is a sequence of steps that describe the interactions between an actor and the system. The use case model consists of the collection of all actors and all use cases. Use cases help us capture the system's functional requirements from the users' perspective actively involve users in the requirements-gathering process provide the basis for identifying major classes and their relationships serve as the foundation for developing system test cases Syntax Testing When performing syntax testing, we are verifying that the use case description contains correct and proper information. We ask three kinds of questions: Is it complete? Is it correct? Is it consistent? Complete: 1. Are all use case definition fields filled in? Do we really know what the words mean?

25

Automatic Test Case Generation using UML

2. Are all of the steps required to implement the use case included? 3. Are all of the ways that things could go right identified and handled properly? Have all combinations been considered? 4. Are all of the ways that things could go wrong identified and handled properly? Have all combinations been considered? Correct: 1. Is the use case name the primary actor's goal expressed as an active verb phrase? 2. Is the use case described at the appropriate black box/white box level? 3. Are the preconditions mandatory? Can they be guaranteed by the system? 4. Does the failed end condition protect the interests of all the stakeholders? 5. Does the success end condition satisfy the interests of all the stakeholders? 6. Does the main success scenario run from the trigger to the delivery of the success end condition? 7. Is the sequence of action steps correct? 8. Is each step stated in the present tense with an active verb as a goal that moves the process forward? 9. Is it clear where and why alternate scenarios depart from the main scenario? 10. Are design decisions (GUI, Database,) omitted from the use case? 11. Are the use case "generalization," "include," and "extend" relationships used to their fullest extent but used correctly? Consistent: 1. Can the system actually deliver the specified goals? Domain Expert Testing After checking the syntax of the use cases we proceed to the second type of testing domain expert testing. Here we have two options: find a domain expert or attempt to become one. (The second approach is always more difficult than the first, and the first can be very hard.) Again, we ask three kinds of questions: Is it complete? Is it correct? Is it consistent? Complete: 1. Are all actors identified? Can you identify a specific person who will play the role of each actor? 26

Automatic Test Case Generation using UML

2. Is this everything that needs to be developed? 3. Are all external system trigger conditions handled? 4. Have all the words that suggest incompleteness ("some," "etc.") been removed? Correct: 1. Is this what you really want? Is this all you really want? Is this more than you really want? Consistent: 1. When we build this system according to these use cases, will you be able to determine that we have succeeded? 2. Can the system described actually be built?

Traceability Testing Finally, after having our domain expert scour the use cases, we proceed to the third type of testingtraceability testing. We want to make certain that we can trace from the functional requirements to the use cases and from the use cases back to the requirements. Again, we turn to our three kinds of questions: Is it complete? Is it correct? Is it consistent? Complete: 1. Do the use cases form a story that unfolds from highest to lowest levels? 2. Is there a context-setting, highest-level use case at the outermost design scope for each primary actor? Correct: 1. Are all the system's functional requirements reflected in the use cases? 2. Are all the information sources listed? Consistent: 1. Do the use cases define all the functionality within the scope of the system and nothing outside the scope? 2. Can we trace each use case back to its requirement(s)? 3. Can we trace each use case forward to its class, sequence, and state-transition diagrams? 27

Automatic Test Case Generation using UML

4.3 Sequence Diagram

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.

4.3.1 UML Sequence Diagram Related Work

A sequence diagram describes how groups of objects collaborate in accomplishing some system behavior. This collaboration is implemented as a series of messages between objects. Typically, a sequence diagram describes the detailed implementation of a single use case (or one variation of a single use case). Sequence diagrams are not useful for showing the behavior within an object[3,10] Syntax Testing When performing syntax testing, we are verifying that the sequence diagram contains correct and proper information. We ask three kinds of questions: Is it complete? Is it correct? Is it consistent? Complete: 1. Does each object required for the interaction appear on the diagram? Correct: 1. Have all objects not required in the interaction been removed from the diagram? 2. Does each objects lifeline begin and end at the proper time? 3. Is each objects activation described properly? 4. If the objects lifetime terminates, is it indicated with an X? 5. Is each message well named with a strong verb? 6. Are proper parameters included for each message? 7. Are conditional branches drawn properly? Consistent: 28

Automatic Test Case Generation using UML

1. Do conditionals cover all of the cases? 2. Have any overlaps of conditionals been removed? Domain Expert Testing After checking the syntax of the sequence diagrams, we proceed to the second type of testingdomain expert testing. Again, we have two options: find a domain expert or attempt to become one. (The second approach is always more difficult than the first, and the first can be very hard.) Continuing, we ask two kinds of questions: Is it complete? Is it correct? Complete: 1. Are all the ways that things could go right identified and handled properly? 2. Are all the ways that things could go wrong identified and handled properly? 3. Does the main success scenario run from the trigger to the delivery of the success end condition? Correct: 1. Does the sequence diagram show each step that must be executed to implement the function? 2. Can each step actually be implemented? Traceability Testing Finally, after having our domain expert scour the sequence diagrams, we proceed to the third type of testingtraceability testing. We want to make certain that we can trace from the use cases to the sequence diagrams and from the sequence diagrams back to the use cases. Again, we turn to one question: Is it consistent? Consistent: 1. Is each use case represented by at least one sequence diagram? 2. Does each actor appear on at least one sequence diagram?

4.4 Brief Overview about System

In UML specification, requirements analysis and design are usually done using diagrams One particular diagram (a use-case diagram) is used to specify requirements the system. In a use-case diagram, two important factors are used to describe the requirements of a system. They are actors and use cases. Actors are external entities that interact with the 29

Automatic Test Case Generation using UML

system and use cases are the behavior (or the functionalities) of a system The use cases are used to define the requirements of the system. These use cases represent the functionalities of the system. Most often, each use case is then converted into a function representing the task of the system. Therefore, we can convert from each of the use case into one test case or many test cases. The relationship of the conversion is either one to one or one to many. However, if we have many use cases, then we will have many test cases. Therefore, an automatic tool would be more wisely used in order to generate test cases from use cases of any system. In most cases, use cases are developed based on the user perspective since the user is going to use the system. In order to make sure that the system does the requirements as it supposed to do, the test cases are designed according to the tester perspective. These test cases are basically designed to test the input and output of a system. Most often, the input, key-in by the user, will be accepted by the system. The system then processes the input and produces the required output according to its specification. An example of online bookstore system is discussed below. The requirements of the system include the capability to make an order, cancel the order and check the status of his/her order. These three requirements are then transformed into a use-case diagram as shown in figure 3.

Figure 3: A Use Case Diagram for an Online Bookstore System

Figure shows a simple use-case diagram for an online bookstore system where only a registered user (customer) is allowed to place an order for available items on this web. 30

Automatic Test Case Generation using UML

These registered users are also able to cancel the order that they make at the previous session. On the other hand, they may also check their orders status. Most often, use cases represent the functional requirements of a system. If the requirements are gathered correctly, then a good use-case diagram can be formed. In UML, sequence diagrams are usually used to manually record the behavior of a system by viewing the interaction between the system and its environment (5). These sequence diagrams describe in details activities for use cases. Therefore, the sequence diagrams can be used to help in generating the correct test cases. Based on 1, a use case diagram can be used to generate test cases of that particular system. But before test cases can be generated, the flow of events for each use cases must be defined first. As an example of one particular use case, Place an Order, the expected flow of events and its exceptions are shown in table1[15]
Table 1: Event Flow for Placing an Order

Place An Order Event Flow

1. User enters web site address in the browser. 2. User enters an email address and a password. Exception1: email address and a password is not valid. Log event Use case ends 3. User enters search string- partial name of a book. Exception 2: No books matching search criteria were found Log event Use case ends 4. User selects a book Exception 3: Decline a book Log event Use case ends 5. User adds the book to a shopping cart 6. User selects Proceed to checkout option. Exception 4: Continue shopping after storing a book in the shopping cart Log event Use case ends 7. User confirms shipping address Exception 5 : Enter a new address 31

Automatic Test Case Generation using UML

Log event Use case ends 8. User selects shipping option 9. User confirms credit card that is stored in the system Exception 6 : Enter a new credit card Log event Use case ends 10. User places the order. Exception 7 : Cancel order Log event Use case ends

From Table1, sequence diagrams are formed to record scenarios of the test cases. Based on Table and test scenarios in sequence diagrams, we have derived the following test cases as shown in Table 2.
Table 2: Test Cases for placing an Order

Place An Order Test Case

Test Condition 1: Basic flow of event- valid account/data is entered. An email address and a password Matching search string were found Selects a book and add the book to a shopping cart Confirms shipping address and shipping option Confirms credit card Places the order Test Condition 2: Email address and a password is invalid Enter wrong combination of an email address and a Password Enter unavailable of email address or password Verify event is logged Test Condition 3: No books matching search criteria were found An email address and a password Enter search string which is not spelled correctly Verify event is logged Test Condition 4: 32

Automatic Test Case Generation using UML

Decline a book An email address and a password Matching search string was found Enter a new search string Verify event is logged Test Condition 5: Continue shopping after storing a book in the shopping cart An email address and a password Matching search string were found Selects the book Leave the book and select another book Verify event is logged

Table 2: Test Cases for placing an Order

Test Condition 6: Enter a new address An email address and a password Matching search string were found Selects a book and add the book to a shopping cart Make a correction on the shipping address Change the shipping address Verify event is logged Test Condition 7: Enter a new credit card An email address and a password Matching search string were found Selects a book and add the book to a shopping cart Confirms shipping address and shipping option Enter invalid credit card number Change credit card number Verify event is logged Test Condition 8: Cancel order An email address and a password Matching search string were found Selects a book and add the book to a shopping cart Confirms shipping address and shipping option Confirms credit card Click on cancel order button 33

Automatic Test Case Generation using UML

Sign out of the account without place an order Verify event is logged

4.5 Flow Chart

34

Automatic Test Case Generation using UML

Start

Input Use Case Diagram

Input Event Flow for Use Case Diagram

Generate a Test case related to Use Case Diagram

End

Figure 4: A flow chart for the proposed system

Summary
This chapter has given the introduction of proposed system and also explaining example of online bookstore system.

~~

Chapter 5

System Design
35

Automatic Test Case Generation using UML

5.1 Introduction
5.1.1 Purpose For effective design following fundamental concepts are strongly considered in the design of this project. Abstractiondata, procedure, control abstraction Refinementelaboration of detail for all abstractions Modularitycompartmentalization of data and function (optimum modularity is preferred) Architectureoverall structure of the software Procedurethe algorithms that achieve function Hidingcontrolled interfaces This chapter focuses on data flow diagram for Automatic Test Case Generation using Use Case Diagram. The purpose of this design document is to provide comprehensive architectural overview of the system, Design considerations, and UML diagrams [16]

Figure 5: DFD 0 Level

5.1.2 UML Diagrams The Unified Modeling Language (UML) is a general purpose visual modeling language that is used to specify, visualize, construct and document the artifacts of software system. We have delineated the following UML diagrams related to our project. 36

Automatic Test Case Generation using UML

5.1.2.1 Use Case Diagram Use case diagram shows the behavior of system. It shows the dynamic view of the system.

Used Case Generator

Event Flow generator

Event Flow Serializer

Test Case Generator

Figure 6: Use case diagram for Proposed System

5.1.2.2 Class Diagram

GenerateUsedCase -template: string -actor: string -relation: string +GetActor () +GetTemplate () +DrawUsedCase ()

GenerateEventFlow -eventid: int -template: string -event: string -exception: string +BrowseUsedCase () +GetEventFlow () +StoretoDB ()

37

Automatic Test Case Generation using UML

GenerateTestCase -eventid: int -testCaseid: string -description: string -expectedres: string +GetEventFlow () +GetTestCase () +LoadMetadata ()

Figure 7: Class diagram for Proposed System

5.1.2.3 State Chart Diagram

Get Actors Get Template 38

Automatic Test Case Generation using UML

Get Relation Draw Used Case

Figure 8: State Chart diagram for use case module

Get Used Case Image

Select Template

Specify Event ID Specify Event Flow Exception Save Event Flow

Figure 9: State Chart diagram for Event Flow Module

Retrieve Event Flow from DB Load Metadata Informatio n 39

Automatic Test Case Generation using UML

Process Exception Data Generate Test Case

Figure 10: State Chart diagram for Test Case Generation module

5.1.2.4 Sequence Diagram End Get Template Add Relation Draw Used Case

ActorStore () TemplateStore () RelationGen ()

SaveUsedCase ()

Figure 11.Sequence Diagram for Use Case Module

Browse Used Case

Generate Event Id

Get Exception Log

Save Event Flow

BrowseUsedCase ()

GenerateEventId ()

StoreExceptionLog ()

40

Automatic Test Case Generation using UML

InsertDB () UsedCaseNotFound

Figure 12: Sequence Diagram for Event Flow Module

Get Event Id

Initiate Test case Engine

Generate Test Case

RetrieveEnventFlow ()

LoadTestCaseEngine ()

GenerateSavetestCase () No Meta Data Match Found

Figure 13.Sequence Diagram for Test Case Generation Module

~~

41

Automatic Test Case Generation using UML

Chapter 8

Benefits

8.1 Benefits of this approach

Test cases are derived in a more automatic way Avoids duplicate testing Better test coverage Easier monitoring of testing progress Easier work load balancing between testers Easier regression testing Decreases project time by moving some tasks from Construction to Elaboration Contributes to early discovery of missing requirements

~~
Chapter 9

Conclusion and Future Scope

42

Automatic Test Case Generation using UML

9.1 Conclusion
GenTCase is a tool that is able to generate the test cases automatically according to the systems requirements. The test cases can be used as a checklist for a programmer to validate that the system meets its requirements. The purpose of GenTCase is to reduce the cost of testing the system. However, GenTCase has its limitations where the use cases used are only for functional requirements of a system

9.2 Future Scope

The tool is unable to capture the non-functional requirements of a system. Therefore, the non-functional requirements need to be captured and tested outside of the tool. We can design a similar tool with the help of Class Diagram, State Chart diagram, Activity Diagram separately.

~~

References

43

Automatic Test Case Generation using UML

[1]

Gurpreet Singh and Rajesh Kumar Bhatia UML Design Based TestingACM/IEEE 11th International Conference on Model-Driven Engg. Languages and Systems (Formerly UML), Toulouse, France, 28 Sep-2 Oct.2008 Gurpreet Singh and Rajesh Kumar Bhatia UML Design Based TestingInternational Symposium on Computer Science and Its Application, Australia,14 -16 Oct.2008. Gurpreet Singh, Rajesh Kumar Bhatiya, UML Designed Based Testing, Thapar University, Patiala, June 2008 A. Bertolino and F. Basanieri, "A practical approach to UML-based derivation of integration tests", Proceedings of the 4th International Software Quality Week Europe and International Internet Quality Week Europe, Brussels, Belgium, 2000,QWE.

[2]

[3] [4]

[5] [6]

B. J.

Korel Offutt

and and

J.

Rilling, A.

"Dynamic

program

slicing tests

methods", from UML

Intonations and Software Technology, 40:647 659, 1998. Abdurazik, "Generating specifications", Proceedings of the 2nd International Conference on UML, Lecture Notes in Computer Science, volume 1723, pages 416 429, Fort Collins, TX, 1999. Springer-Verlag GmbH.

[7]

B.Jeng and E. J. Weyuker, "A simplified domain-testing strategy", ACM Transactions on Software software Engineering test data and Methodology IEEE (TOSEM), 3(3), 1994.

[8] [9]

B.

Korel,

"Automated

generation",

Transactions on Software Engineering, 16(8): 870 - 879, 1990. Clay E. Williams Software Testing and the UML Center for Software engineering, IBM T. J. Watson Research Center. [10] Poston, R. Automated test from object models. CACM 37,9 (Sept. 1994), 48-58.

[11]

Perry, D. and Kaiser, G. adequate testing and object-oriented programming. JOOP (Jan./Feb. 1990), 13-19.

44

Automatic Test Case Generation using UML

[12]

C. Nebut, F. Fleurey and Y.L. Traon, Automatic Test Generation: A Use Case Driven Approach, IEEE TRANSACTION ON SOFTWARE ENGINEERING Vol.32, No. (2003)

[13]

D. Wood and J. Reis (1999). Use Case Derived Test Cases, Software Quality Engineering for Software Testing Analysis and Review (STAREAST99)Online.http://www.stickyminds.com/

Books
[1] The Unified Modeling Language User Guide 2nd Edition Ebook by Grady booch and James rambaugh

~~

45

Automatic Test Case Generation using UML

46