A UML-Based Approach for Testing Web Applications

A UML-BASED APPROACH FOR TESTING WEB APPLICATIONS

Manish Nilawar

Research and Educational Planning Center

University of Nevada, Reno

1664 N. Virginia St, Reno, NV, 89557, USA

Sergiu Dascalu

Department of Computer Science

University of Nevada, Reno

1664 N. Virginia St, Reno, NV, 89557, USA

Abstract:Web applications have evolved from small web site add-ons to large multi-tiered applications. Currently, they have an impressive number of users distributed all over the world and are becoming progressively more complex as well as business critical. Systematically modeling and testing web applications can help manage their growing complexity. In this paper, an approach for engineering web applications with UML is proposed and a key part of the approach, testing these applications using a strategy denoted combo testing, isdescribed. Combo testing involves the use of a new modeling construct, web application compound, and allows thorough verification of functional requirements of web applications via two types of testing: use case-based testing and web compounds unit testing.

Keywords: web applications, UML extensions, software modeling, web application compounds, combo testing.

1Introduction

Although there are a number of differences between web applications and traditional software some of the testing strategies for traditional software applications can nevertheless be adapted [1]. Until recently, many of the web testing approaches have concentrated on the client-side validation and other static aspects of the web application such as server-side validation using Javascript tools and HTML validators. Research into functionality testing of web applications is of recent trend [2]. For instance, Ricca and Tonella [3] have proposed a model for laying out analysis and testing strategies for web applications. Their strategy is primary built around static webpage analysis and some preliminary dynamic analysis. As more and more information processing is being performed dynamically using web applications, the focus needs to be shifted on the dynamic behavioral aspects of the applications. Lee and Offutt [4] have described a mutation based testing approach for XML-based web applications. The key idea behind their approach is consistency of data exchange among different components via XML. However, functionality checking of the web application is not covered in their work. Conallen [5] has suggested comprehensive modeling strategies using UML extensions [6] and established a mapping between standard modeling constructs and the artifacts of a web application. Yet, other than some basic web page analysis, testing was not included in this work. Liu et al. [7] have developed a model to represent web sites as graphs and providedpreliminary definitions for developing graph-based tests in terms of web page traversals. However, they do not take into consideration dynamic behavioral aspects based on server-side code.

Thus, it can be seen that testing web applications is a topic of recent date. In particular, UML-based approaches for testing such applications are still in their early stages and significant work seems to be left for researchers and developers. The primary motivation for our research has been to work in this rather uncharted area of UML-based web testing approaches, whosepotential benefit for practical application is remarkably high.

The proposed approach employs UML for modeling and testing web applications. In particular, testing has received a special focus. The modeling steps proposed have been adapted from the software engineering methodological guidelines presented in [5]. For the purpose of modeling, we have introduced the concept of web application compound(in short, webcomp). For testing, we suggest a systematic allocation of use cases to webcomps. We also propose a combotesting approach, which involves two components: use-case driven testing and webcomps unit testing. An illustration of this approach is provided using an application entitled Web Records, whose initial prototype is currently operational.

The remainder of the paper is organized as follows. Section 2 provides a closer look at the architecture and functions of Web Records. Section 3 discusses the proposed UML-based modeling approach. Section 4 concentrates on the combo testingpart of the approach and presents detailson its component techniques. Finally, Section 5 summarizes our contributions and presents the conclusions of the paper.

2Web Records: Architecture and Functions

To illustrate the proposed approach we have developed a web application denoted Web Records. Web Records is a database-driven web application that helps an organization manageits data gathering and manipulation for events such as conferences, seminars, or training workshops. The application is well supported on all browsers that conform to HTML 3.2. The Web Server uses Common Gateway Interface (CGI) and the http adaptor connects the application to the Internet by acting as an intermediary between the application instances and the web server. The Web Records program responds to the requests with dynamically generated Web pages. Figure 1 depicts the overall architecture of Web Records.

Fig. 1 Web Records Architecture

Web Records is an online event management software that addresses various needs of an organization hosting the event. Administrators, participants, and reviewers need only a web browser to utilize the application, regardless of the platform they use. The application allows users to register with the organization and sign up for any events hosted by the organization. Unregistered users can view and browse through the available events but access to all other information is restricted to registered users.Administrators can log in to the system to check the status of participation for each event. Detailed statistics regarding the attendance of participants such as region-wise analysis are also available. Reports showing the list of participants for each event can be generated onthe fly. For events such as seminars and conferencesWeb Records can accept submissions from participants in Word or PDF format through a simple and easy to use web interface. The submissions are stored in a database and retrieved when queried for. The reviewers can also login to the same system and get access for viewing and evaluatingsubmissions.The look and feel of Web Records can be grasped from Fig. 2, which shows the main login screen.

3UML-Based Modeling

3.1Concepts

The current standard for modeling software-intensive systems is the Unified Modeling Language (UML) [6]. Inorder to utilize a single modeling notation for an entiresystem that includes web-specific components and

Fig. 2 Web Records: Main Page

traditional middle-tier components, UML needs to be extended.In this paper, we introduce an extension to the UML that makes use of its formal extension mechanisms [6, 8]. The extension has been designed such that web-specific components can be integrated with the remainder of the system's model. Also, it is meant to exhibit a level of abstraction and detail suitable for application designers and implementers. In UML, astereotype allows the modeller to define a new meaning for a modeling element while tagged values are <tag, value pairs that can be associated with suchan element. Web pages, whether scripted or compiled, map one-to-one to components in UML, which are replaceable physical parts of the system. The implementation view of the modeldescribes the com-ponents of the system along with their relationships [8].

The Web Records project has adopted UML modeling techniques for analysis and design. The notion of web application compound(or webcomp) introduced in this paper has been used for modeling the project. Figure3 depicts the composition of such a webcomp.Webcomps help in abstracting aspects of navigation as well as business logic representation.

Fig. 3 Composition of a Typical Webcomp

A webcomp represents a logical grouping of parts of a web application that together provide a given functionality. These may include client side HTML code as well as server side code like Java, ASP, and so forth. Packages in UML also involve similar grouping of smaller subsystems, but webcomps are specifically composed of the same types of elements with similar structure, for example of pairs HTML client-side code and Java server-side code. As shown in [5], stereotypes can be used to represent connections between webcomps through hyperlinks, requests to server code, and so forth. Tagged values can be used to represent parameters passed across these webcomps. Figure4 shows an example of how a web application can be modeled using the concept of webcomps. If the user clicks on the hyperlink “Forgot Password,” the user’s email ID is passed as a tagged value between the Main webcomp and Forgot Password webcomp and the hyperlink has been abstracted using the link stereotype.

Fig. 4The Webcomp Model

3.2Use Case Modeling

According to [9], on the basis of design the Web Records application can be classified as a thin web client, where standard facilities of the Web browser are being exploited for user interaction but all the business logic is being executed on the server. The use case diagram shown in Fig. 5 depicts the functionality of Web Records.

Fig. 5 Use Case Diagram

In our proposed approach the use case diagram of the application isnext expanded to derive the webcompsmodel. As shown in Fig. 5 three actors interact with thesystem to perform the required functions. More details on the use cases derived on the basis of the functional requirements of the application can be found in [10].

3.3Elaboration of Web Compounds

Webcomps take the modeling of the application to a level of abstraction that comes closer to implementation. The main purpose is to focus on the underlying conceptual characteristics associated with the development approach without worrying about how the representations look like [11]. The webcompsmodel also addresses other key elements of web applications, namely the interactions [2]. This can be shown using a map such as the one in Fig. 6.

Fig. 6 Webcomps Navigation Map

The next modeling step after use cases and webcompsare elaborated is to establish a mapping between these two. By applying a systematic process, each use case can be mapped to one or more webcomps that will implement the functionality of the use case. This mapping, shown in Fig. 7, is important because it islater used during combo testing to thoroughly verify how the system implements its required functionality.

4Testing

4.1Combo Solution for Testing

The most natural way of verifying a system is to operate it in some representative situations and verify whether it behaves as expected [12]. Testing is a process of executing a program with the intent of finding an error. If conducted successfully, the testing also demonstrates that the software functions are workingaccording to thespecification and the performance requirements are met. In addition, data collected during the testing process provides a good indication of software reliability and

Fig. 7 Mapping Use Cases to Webcomps

some indication of the software quality as a whole.To be more precise, we concentrate on verification testing,i.e. on proving that Web Records has the required functionality based on its Software Requirements Specificationdocument [10]. The approach involves use cases based testing and webcomps unit testing and treats the Web Records application itself as a black box.

4.2Use Case Based Testing

4.2.1Use Cases Towards Testing

A use case is a top-level category of system functionality, such as Login, Register for Event, etc. A use case has a graphical representation and a text description. The diagram specifies all the actors (outside of the system) involved in the function, as well as an indication of how the use case is initiated. The collection of use case diagrams provides a ‘context’ diagram of system interfaces. Each use case includesthe list of events initiated by an actor and specifies the interaction that takes place between an actor and the system. In a use case the system is viewed as opaque, where only the inputs, outputs, and functionality matter [13].Use cases can be used to construct the scenarios that ensure the required functionality can be supported as well as to discover the objects that models the system in a way that allows it to satisfyall its functional requirements.

4.2.2 Scenarios: LinkingUse Cases and Test Cases

A scenario is an instance of a use case, or a complete "path" through the use case [2]. End users of the completed system can go down many paths as they execute the functionality specified in the use case.Each use case has a primary scenario and multiple secondary scenarios. The primary scenario’s flow of events should cover what "normally" happens when the use case is performed. The secondary scenarios’ flows of events cover behavior of an exceptional character or variations of the normal behavior. Thus, a significant amount of detail goes into fully specifying a use case. The precondition specifies the required state of the system prior to the start of the use case. This can be used for a similar purpose in the test case. The postcondition is the state of the system after the actor interaction. This can be used for test pass/fail criteria during testing. Due to space limitations, for details on Web Records use cases and scenarios the reader is referred again to [10].

4.2.3Generating Test Cases

A test case is a set of test inputs, execution conditions, and expected results developed for a particular objective: for example, to exercise a particular program path or verify compliance with a specific requirement. The purpose of a test case is to identify and communicate conditions that will be implemented in the test. Test cases are necessary to verify successful and acceptable implementation of the product requirements (use cases).The four-step process for generating test cases described below has been adapted from [14]. To this process we have added an initial step, which involves the development of a prioritization scheme. Also, we suggest some additional guidelines for generating scenarios.

Step 1: Prioritizing Use Cases based on Requirements Traceability Matrix

Many web applications are developed under severe time-to-market pressure. Development periods may range from one to three months for the majority of such applications with relatively small team of developers. In such situations, correctly addressing the user’s priorities can be very important. Regardless of the rigorousness of the design process, one thing holds true: the frequency with which each function of the system is used will reflect the relative importance of the specific system features. The familiar use-case model of system requirements can play a part in computing the requirements traceability matrix, thus guiding the selection of test cases for the system. We suggest a prioritization scheme as shown in Table I where the requirements traceability matrix of Web Records indicates the relative importance of each use case of the system. Each requirement is assigned a priority weight Pw. For the sake of simplicity we use here a simple scheme of high priority (Pw=2) or low priority (Pw=1) for each requirement. The score for each use case is calculated by summing up all of its priority weights. The use case with the greatest score has the highest priority, and so forth. Thus, in theexample shown UC2 has the highest priority (score=10). More sophisticated rules can be set for determining use case priorities in complex systems.Essentially, it is left to the developers to decide on the number of levels of priority that need to be used in a given application.

Table I: Requirements Traceability Matrix (partial)

Pw / UC1 / UC2 / UC3 / UC4 / UC5 / UC6 / UC7
R1 / 2 / X / X
R2 / 2 / X
R3 / 2 / X
R4 / 2 / X / X
R5 / 2 / X
R6 / 1 / X / X
R7 / 1 / X / X
R8 / 1 / X
R9 / 1 / X / X / X
R10 / 1 / X
SCORE / 5 / 10 / 2 / 3 / 1 / 1 / 1

Step 2: Generate Use Case Scenarios

For each use case starting from higher to lower priority, it is next necessary to generate a tentatively sufficient set of scenarios. Having a detailed description of each scenario such as the input variables involved, the preconditions and the postconditions of the scenario can be very helpful in the later stages of test case generation [14]. Table II shows the tentatively sufficient set of scenarios for the Register for Event use case. In the proposed approach each use case must be illustrated with the primary scenario and at least one secondary scenario. However, more secondary scenarios are recommended formore comprehensive modeling and testing.

TableII: Scenario Set for “Register for Event”

Scenario ID / Scenario Name
Scenario 1 / SuccessfulRegistration
Scenario 2 / UserNotFound
Scenario 3 / InvalidInformation
Scenario 4 / UserQuits
Scenario 5 / SystemUnavailable
Scenario 6 / RegistrationClosed
Scenario 7 / DuplicateRegistration

Step 3: Identify Test Cases

After the tentatively sufficient set of scenarios for the use case has been created, the next step is to identify the test cases. Analyzing the use case and its scenarios can do this. The preconditions and flow of events for each scenario can be exploited to identify the input variables and the constraints that bring the system to a specific state represented by the postconditions. A matrix format is useful in clearly documenting the test cases for each scenario. A test case matrix for the Register for Event use case (available in [10]) includes a header row with the first column indicating the Test case ID, the next column containing a Scenario description, and the following columnsindicating a series of input variables and constraints. The last column shows the expected result of each test case. This test case matrix represents a framework for testing without involving specific data values. In fact, generic values are used, specifically V, which indicates valid, I which stands for invalid, and N/A which meansnot applicable [14].At this stageof the testing process the matrix provides a good way to document the conditions that are being tested.

Step 4: Identify Data Values

Once all test cases have been identified they should be completed, reviewed, and validated to ensure thoroughness of the testing and to identify redundant or missing test cases. When this is completed,the next step is to plug in real data values for each of the Vs and Is in the matrix created in Step 3. This can be done using a variety of test data as shown in [10], where the matrix structure described in the previous step is also visible. Generating test data is in itself acomplex subject of discussion, which exceeds the scope of this paper.