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

nilawar@unr.edu

Sergiu Dascalu

Department of Computer Science

University of Nevada, Reno

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

dascalus@unr.edu

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, is described. 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.

1 Introduction

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 provided preliminary 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, whose potential 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 combo testing 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 testing part of the approach and presents details on its component techniques. Finally, Section 5 summarizes our contributions and presents the conclusions of the paper.

2 Web 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 manage its 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.

[pic]

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 on the fly. For events such as seminars and conferences Web 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 evaluating submissions. The look and feel of Web Records can be grasped from Fig. 2, which shows the main login screen.

3. UML-Based Modeling

1. Concepts

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

[pic] 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, a stereotype allows the modeller to define a new meaning for a modeling element while tagged values are pairs that can be associated with such an 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 model describes 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. Figure 3 depicts the composition of such a webcomp. Webcomps help in abstracting aspects of navigation as well as business logic representation.

[pic]

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. Figure 4 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.

[pic]

Fig. 4 The Webcomp Model

2. Use 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.

[pic]

Fig. 5 Use Case Diagram

In our proposed approach the use case diagram of the application is next expanded to derive the webcomps model. As shown in Fig. 5 three actors interact with the system 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. Elaboration 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 webcomps model 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.

[pic]

Fig. 6 Webcomps Navigation Map

The next modeling step after use cases and webcomps are 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 is later used during combo testing to thoroughly verify how the system implements its required functionality.

4 Testing

1. Combo 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 working according to the specification and the performance requirements are met. In addition, data collected during the testing process provides a good indication of software reliability and

[pic] 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 Specification document [10]. The approach involves use cases based testing and webcomps unit testing and treats the Web Records application itself as a black box.

4.2 Use Case Based Testing

4.2.1 Use 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 includes the 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 satisfy all its functional requirements.

4.2.2 Scenarios: Linking Use 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.3 Generating 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 the example 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 |

|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 columns indicating 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 means not applicable [14]. At this stage of 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 a complex subject of discussion, which exceeds the scope of this paper.

4.3 Webcomps Unit Testing

4.3.1 The Approach

The input to the webcomp is a formal specification in XML syntax, which specifies the functionality parameters, more precisely the input and the expected outputs of each test case. Based on this XML description the test cases are executed from within the webcomp. As the result of the execution, the generated output is written into a report file as a status code [15].

4.3.2 Test Specification

By formally specifying the web application’s intended functionality in test specification, tests can be performed by comparing actual functionality with the intended functionality. A test specification is a hierarchy of test suites and test cases, where a test suite is a specification that consists of one or more test suites. Each test suite contains a set of test cases for a specific function of the webcomp and each test case consists of a pair of request specification and response specification.

7 Request and Response Specification

The RequestSpec specification depicts a pattern of HTTP requests, which consists of the URLs of the requests, while the ResponseSpec specification describes the assertions on the HTTP response generated from the HTTP request in the same test step [10]. An example of a test specification dealing with requests from a web page with a given URL is also shown in [10]. If a valid match is found the URL and the response code Pass is written into the report file. If the next test case is found to be valid and the response page contains the literal string NSException a status code Fail is written into the report.

4.3.4 Implementation within a Webcomp

The test specification XML file is stored within the Resources folder of the project such that it is accessible from within any webcomp of the project [10]. Built into WebObjects are two HTTP methods used for reading HTTPRequest and parsing the HTTPResponse, specifically: takevaluesfromrequest(), whose effect is to synchronize all form values submitted from the browser with their corresponding Java instance variables in the server application, and appendtoresponse(), a method responsible for generating the response to the client (the response is generated in the form of WOResponse object, which is later converted to HTTPResponse to be shown in the browser by the WebObjects adapter). The input of Web Records is an XML file containing test specifications. Tests are implemented within each webcomp’s Java code, which uses the Java API for XML Processing (JAXP).

Conclusions

Web applications need a different approach for both modeling and testing. The approach presented in this paper is focused on functionality testing of web applications, which involves the dynamic behavioral aspects of the application more than the static webpage content. The testing method is tightly bound to the requirements, thereby concentrating on immediate benchmarks rather than getting distracted by add-on features. In summary, the approach suggested here encompasses the following:

• Proposal of the webcomp element for UML-based specification of testing web applications. This new modeling element relies on the adapted use of standard UML extension mechanisms. Based on this modeling element and on traditional website navigation maps a webcomp model for the application was also proposed.

• Elaboration and mapping of use cases to webcomps.

• Adaptation of a four step process for generating test cases based on use cases. To the process described in [14] a mechanism to prioritize the use cases before generating test case matrices has been added and several guidelines for creating scenarios have been suggested.

• Combo approach for testing consisting of use-case driven testing and webcomp unit testing covering thoroughly the functionality of the application.

At this time, we are aware that many improvements for the proposed approach are possible. In particular, use cases have their limitations, which need to be carefully addressed [16]. Also, there is room for expanding the types of tests included in the combo strategy and there is certainly a need for further exercising the approach on more complex web applications. Additional directions of further work are indicated in [10]. Nevertheless, we believe that the suggested UML-based modeling and testing methodology provides a practical and efficient solution for developing reliable web applications.

References

|[ 1] |H. Zhu, P. Hall, and J. May, “Software unit test coverage and |

| |adequacy”, ACM Computing Surveys, pp. 366-427, December 1997. |

|[ 2] |Y. Wu and J. Offutt, “Modeling and testing web based |

| |applications”, GMU ISE-TR-02-08, 2002. |

|[ 3] |F. Ricca and P. Tonella, “Analysis and testing of web |

| |applications”, Procs. of the 23rd Intl. Conf. on Software Eng.|

| |(ICSE 2001), pp. 25-34, 2001. |

|[ 4] |S. Lee and J. Offutt, “Generating test cases for XML-based web |

| |applications”, Procs. of the 12th International Symposium on |

| |Software Reliability Engineering, pp. 200-209, 2001. |

|[ 5] |J. Conallen, Building Web Applications with UML, Second Edition,|

| |Addisson Wesley, 2002. |

|[ 6] |OMG’s UML Resource Page, accessed November 23, 2003, |

| |. |

|[ 7] |C. Liu, D. Kung, P. Hsia and C. Hsu, “Structure testing of web |

| |applications”, Procs. of the11th Annual Intl. Symposium on |

| |Software Reliability Engineering, pp. 84-96, 2000. |

|[ 8] |J. Arlow and I. Neustadt, UML and the Unified Process: Practical|

| |Object-Oriented Analysis and Design, Addison-Wesley, 2002. |

|[9] |F. Ricca and P. Tonella, “Testing processes of web |

| |appplications,” Annals of Software Engineering, vol. 14, no. |

| |1-4, pp. 93-114, 2002. |

|[10] |M. Nilawar, “A UML-based approach for testing web applications,”|

| |M.Sc. in Computer Science Professional Paper, University of |

| |Nevada, Reno July 2003 (Advisor: S. Dascalu). Available at |

| | |

|[11] |C. Atkinson, C. Bunse, H. Grob and T. Kuhne, “Towards a general |

| |component model for web-based applications,” Annals of Software |

| |Engineering, vol. 13, no. 1-4, pp. 35-69, 2002. |

|[12] |C. Ghezzi, M. Jazayeri and D. Mandrioli, Fundamentals of |

| |Software Engineering, 2nd Edition, Prentice Hall, New Jersey, |

| |2003. |

|[13] |M. Fowler, UML Distilled, Addison Wesley,1997. |

|[14] |J. Heumann, “Generating test cases from use cases”, The Rational|

| |Edge, Rational Software, 2001. |

|[15] |E. Hieatt and R. Mee, “Going faster: testing the web |

| |application,” IEEE Software, 19(2), 2002. |

|[16] |B. Berger, “The dangers of use cases employed as test cases”, |

| |accessed November 23, 2003 at: |

| | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download