Zoomer: An Automated Web Application Change Localization Tool

Journal of Communication and Computer 9 (2012) 913-919 D DAVID PUBLISHING Zoomer: An Automated Web Application Change Localization Tool Wenhua Wang 1 and Yu Lei 2 1. Marin Software Company, San Francisco, California 76019, USA 2. Department Of Computer Science and Engineering, University of Texas at Arlington, Arlington, Texas76019, USA Received: December 20, 2011 / Accepted: January 16, 2012 / Published: August 30, 2012. Abstract: Rapid iterative and evolutionary web application development, typically 2-3 weeks in each iteration, poses a big challenge for web application testing. To ensure web application quality, we must perform adequate testing for the new features as well as regression testing in each iteration. This requires us to systematically identify/locate changes introduced in each new iteration. This paper presents an automated tool to systematically identify/locate new changes, which greatly facilitates web application testing in short release cycles. The empirical study results show that this tool can effectively identify/locate changes introduced into a web application. Key words: Change localization, web application testing. 1. Introduction SaaS (Software as a service) has become a popular business application delivery model [1-[2], shifting more and more software applications to the web. However, its rapid release cycles, typically 2-3 weeks, create a big challenge for web application quality assurance. Under high release pressure, developers can easily make mistakes during implementation. For example, a PHP web page developer adds a new field into a search form, which may cause the extra field to be inserted into a dynamically generated database query statement when this search form is submitted. In this case, if the front-end developer forgets to update the database schema at the back-end, a system failure, typically in a form of JDBC exception, would happen. With short release cycles, good documentation is Yu Lei, Ph.D., associate professor, research fields: automated software analysis, testing, and verification, and combinatorial testing. Corresponding author: Wenhua Wang, Ph.D., software engineer, research fields: automated software testing, and security testing. E-mail: wenhua.wang@mavs.uta.edu. luxury. Consequently, it is difficult for quality assurance engineers to systematically identify/locate changes based on existing documents. To efficiently test web applications, automated regression testing [3] has been introduced to re-test existing features. This helps to greatly reduce regression testing costs. Automated regression testing tools have been widely used in software industry, e.g., HtmlUnit [4] and Selenium [5]. However, automated regression testing tools were not developed to systematically identify and test changes introduced in a new iteration, where defects can be easily introduced. Therefore, adequate testing of newly introduced changes in each iteration can be a critical step to ensure web application quality. The problem of adequately testing new changes, i.e., new features and their impacts, can be divided into two sub-problems: (1) how to quickly and accurately identify/locate new changes; and (2) how to effectively generate and run tests for the new changes. The second sub-problem has been well studied [3, 6]. However, little work has been reported on the first sub-problem, this paper presents a black-box tool, named Zoomer,

914 Zoomer: An Automated Web Application Change Localization Tool that has been implemented to automatically identify newly introduced changes in a new iteration. Since web applications interact with users through web pages [7], i.e., users submit business requests in web pages, and web applications present processing results in response web pages, Zoomer focuses on identifying/locating changes in web pages, i.e., changes on HTML/XHTML elements [10-11]. For example, it identifies value changes of the onclick event property, shown in Figs. 1 and 2 In highly interactive web applications, many script functions are used to handle events associated with HTML elements, like extractnumber and blocknonnumbers Java script functions in Fig. 1. As a result, changing script functions could significantly impact web application functionality. Therefore, it is important to identify changes happened on HTML/XHMTL elements and test them. To the rest of this paper, we will refer to a HTML/XHTML element used in a web page as an element. Zoomer identifies/locates changes in a web application by comparing web pages and their HTML DOM trees. First, it retrieves web pages from a new iteration. Second, for each web page, Zoomer constructs its HTML DOM three representation with XPaths [12]. Third, Zoomer compares HTML DOM tree representations in the new iteration with saved HTML DOM tree representations in the previous iteration. This comparison work will capture changes introduced in the new iteration, e.g., element changes and element properties changes. For example, the Vote button in Fig. 3 has been put in a wrong location. By comparing with elements in Fig. 4, we can capture this change. As another example, by comparing properties in Figs. 1 and 2, we can see that the value of onclick has been changed from update to delete. It means, in the new iteration, the delete operation will be performed, if Vote button is clicked. Previously, clicking Vote button would lead to the update operation. Fig. 1 HTML/XHTML element example 1. Fig. 2 HTML/XHTML element example 2. Fig. 3 Web page example 2. Fig. 4 Web page example 1.

Zoomer: An Automated Web Application Change Localization Tool 915 The remainder of this paper is organized as follows. Section 2 introduces Zoomer s architecture, workflow and function features. Section 3 presents an empirical study. Section 4 discusses related work. Section 5 concludes this paper and discusses future work. 2. Overview of Zoomer Zoomer is implemented using Java. It analyzes the web pages in a web application to identify/locate new changes. To retrieve web pages from a web application, it integrates Tansuo [13], a tool to explore web pages in web applications. It also integrates HtmlUnit [4], a tool for constructing the HTML DOM tree representation for a web page. In the following, we will introduce its architecture, workflow and function features. 2.1 Architecture As shown in Fig. 5, Zoomer consists of six components: Driver, Tansuo, Parser, Repository, Comparator, and Presenter. (1) Driver: This component is the core of Zoomer. It is responsible for coordinating other components to identify/locate changes introduced in a new iteration. Driver decides which component should be used at each step, which will be discussed in Section 2.2. (2) Tansuo: This component is responsible for exploring the web pages in a web application. It works in a recursive process. For example, it retrieves the home page, by following the URL provided by a user. If there are links and forms in a web page, Tansuo will handle them, e.g., by clicking links or submitting forms, to reach more web pages. This process will be repeated until the whole web application has been explored. (3) Parser: This component is responsible for parsing web pages. Parser obtains the HTML DOM tree of a web page through the HtmlUnit library [4]. Then, it traverses the generated HTML DOM tree in a depth-first-search manner. When a new element is encountered, it constructs an XPath [12] for the new element and saves this new XPath for future comparison. For example, the XPath of the first/root element in a web page is /html. As another example, the Vote button, in Fig. 3, is represented with /html/body/table/tbody/tr[5]/td[1]/input. In addition, Parser can explore the property-value pairs of an element, which helps identify/locate element property changes. In a highly interactive web application, elements often have various associated behaviors, as shown in Figs. 1 and 2. When an event is triggered, its associated behavior, defined by an event property and its value, e.g., a Java script function name, will be performed. In reality, changes on those associated behaviors could dramatically impact the web application functionality. (4) Repository: This component is responsible for saving the elements and their properties. An element is Fig. 5 Zoomer s architecture.

916 Zoomer: An Automated Web Application Change Localization Tool identified by its web page URL and its XPath in the web page. Meanwhile, it also saves comparison results. All the information is saved in a set of files that will be accessed by Driver in the future. (5) Comparator: This component is responsible for comparing web pages and their elements in two iterations. Comparator receives elements and their property information from Driver and compares them to identify/locate the changes. In other words, for each element in the new iteration, Comparator checks whether it existed in the previous iteration. For each element in the previous iteration, Comparator also checks whether it still exists in the new iteration. Specifically, this comparison aims to answer the following nine questions: How many new web pages have been introduced and what are the new web pages? How many web pages have been removed from the new iteration and what are the removed web pages? How many existing web pages have been changed in the new iteration, and what are the changes? Note that the web page change is defined as its elements have been changed, removed, or new elements have been added; How many new elements have been introduced into a changed web page, and what are the new elements? How many elements have been removed from a changed web page, and what are the removed elements? How many elements have been changed and what are the changed elements? It is noted that an element change is defined as its element properties have been changed and removed or new element properties have been added; How many new properties have been introduced into a changed element, and what are the new properties? How many properties have been removed from a changed element, and what are the removed properties? How many property values have been changed in a changed element and what are the changed property values? (6) Presenter: This component is responsible for presenting comparison results to users. It uses JFreeChart [14] to generate pie charts that show change percentage of web pages, elements and element properties. Presenter also inserts links of changed web pages, elements, and properties into comparison result web pages, so that users can easily navigate to the changed web pages and elements that they are interested in. 2.2 Workflow Generally, Zoomer s workflow can be divided into three major steps, as follows: (1) Parsing pages/elements: There are five steps. Driver first calls Tansuo to explore a web application. It provides Tansuo with a starting URL. Second, Tansuo retrieves the web page identified by the URL from the web application. This web page is returned to Driver. Third, Driver calls Parser to process this web page. Parser returns to Driver all the elements XPaths and property-value pairs existing in the HTML DOM tree of this web page. Fourth, Driver saves the element information into Repository. Fifth, Driver calls Tansuo to continue exploring the web application. Tansuo follows links or form submissions in the current web page to reach more web pages. The last four steps are repeated until the entire web application has been explored and all the retrieved web pages have been processed; (2) Comparing pages/elements: Driver calls Comparator to check whether all the pages/elements that exist in the new iteration also exist in the previous iteration. It also checks whether all the pages/elements in the previous iteration exist in the new iteration. For the elements that exist in both iterations, Comparator checks whether they have property changes and what are these changes. The comparison results will be saved into Repository by Driver; (3) Presenting comparison results. Driver calls Presenter to present how many changes have been detected and what are these changes. Presenter gets

Zoomer: An Automated Web Application Change Localization Tool 917 comparison results and detailed element information from Repository by Driver. 2.3 Discussion To allow defining the scope of comparison, Zoomer provides the comparison filtering functionality, which helps users focus on what they are interested in. Users can define what pages/elements to be processed by defining including-/excluding-keywords. For example, defining table as an excluding-keyword will make Zoomer ignore all the tables during exploring a HTML DOM tree. As another example, if users define form as an including-keyword, only form elements would be processed. Zoomer depends on Tansuo [13] to retrieve web pages from a web application. To explore web pages behind web forms, Tansuo requires form input data from users. If users predefined form input data in XML files, Zoomer can work fully automatically. If users cannot predefine form input data, Zoomer will ask users to provide form input data on the fly, through Tansuo, when a new form is encountered. Zoomer does not perform static analysis on Java script source code. As a result, Zoomer cannot identify implementation changes made to Java script functions. But changes made on the usage of Java script functions, e.g. removing an associated Java script function from an element event property or adding a new associated Java script function, would be identified. Similarly, Zoomer cannot identify changes made to Flash action scripts either. But Zoomer can identify Flash object that are added, removed, or changed in a web page. 3. Empirical Study We have applied Zoomer to the Bookstore web application [15] to evaluate its effectiveness. The empirical results show that Zoomer successfully identified/located changes happened in the Bookstore web application. The Bookstore web application [15] is an online store, where users can browser and order books. An admin user can also perform maintenance work, e.g., creating a new user account. We obtained its original version from going to code website [15]. From this original version, Zoomer captured 67 web pages, 16,838 elements, and 9,059 properties. To get a new version of the Bookstore web application, we merged 13 revisions from UDEL [16] into the original Bookstore web application. Those 13 revisions distributes in nine JSP files, i.e., MyInfo.jsp, AdvSearch.jsp, BookDetail.jsp, Registration.jsp, Login.jsp, Default.jsp, Books.jsp, ShoppingCart.jsp, and Footer.jsp. As it is shown in Table 1, those 13 revisions impacted 55 web pages. We manually investigated why so many web pages have been impacted in the empirical study. The major reason is that Footer.jsp is included in many JSP files. Therefore, changes in Footer.jsp would be propagated to other JSP files too, which caused more than 82% web pages have been changed. At element level, 501 new elements have been introduced and 799 old elements have been removed. There are 700 elements whose properties have been changed. At property level, 350 new properties are introduced, and 477 old properties removed. Meanwhile, 132 property values have been changed. 4. Related Work WEBVIZOR [17] is the most related work. WEBVIZOR was developed to perform regression testing for web applications. It repeats existing tests, e.g., sending a sequence of HTTP requests to a web application, and compares the response web pages with existing golden web pages. Doing so can find errors in the new web pages. To reduce false positives, WEBVIZOR compares HTML tags, e.g., input field, or HTML contents, e.g., the text content of input Table 1 Changes in the new bookstore application. Level New Removed Changed Page 0 0 55 Element 501 799 700 Property 350 477 132

918 Zoomer: An Automated Web Application Change Localization Tool field. To some extent, both Zoomer and WEBVIZOR can be used to identify changes in a new iteration. But Zoomer is different from WEBVIZOR in three ways. First, Zoomer was developed to solve the first sub-problem discussed in Section 1, i.e., systematically identifying new features and their impact on other existing components. In contrast, WEBVIZOR was developed mainly addressing the second sub-problem discussed in Section 1, i.e., automated regression testing. Since regression tests do not cover new features, WEBVIZOR can miss many changes in a new iteration. Second, they work in different ways. WEBVIZOR requires users to provide sequences of HTTP requests before running automated testing. Unlike WEBVIZOR, Zoomer works automatically without requiring HTTP requests provided by users. Third, Zoomer can work for highly interactive web applications, e.g., Ajax web applications. In these web applications, web pages may be dynamically changed by Java script functions, when element property events are triggered. For example, when an image is clicked, the Java script function associated with its onclick property will be executed, which generates a new bubble to show the image description. Zoomer can systematically identify property events associated with elements and trigger them one by one, which enables Zoomer to capture dynamically generated elements in web pages. But WEBVIZOR cannot handle programming elements [17], e.g., Java script functions, and objects, e.g., Flash objects generated by Flash action scripts and CSS style properties. To the best of our knowledge, Zoomer is the first tool developed to identify/locate changes in highly interactive web applications. 5. Conclusions This paper presents a tool, named Zoomer, which can automatically identify/locate changes in web applications. The gathered changes can facilitate quality assurance of web applications, especially in short release cycles. We discussed Zoomer s architecture, workflow and functional features. We also presented an empirical study. The empirical results show that Zoomer can effectively identify/locate changes introduced in a new iteration. In the future, we plan to evaluate its performance in various web applications. Due to time constraints, we have only evaluated Zoomer on the Bookstore web application in this paper. Moreover, we plan to improve the user interface of Zoomer so that it is accessible to public users. References [1] C. Jutras, QAD on Demand Gives Manufacturers the Tools They Need to Become Global, Aberdeen Research Group, The Street. com Inc., 2011. [2] P. Laird, How Oracle, IBM, SAP, Microsoft, and Intuit are responding to the SaaS revolution, Laird On Demand, Blogspot, 2008. [3] V. Kettunen, J. Kasurinen, O. Taipale, K. Smolander, A study on agility and testing processes in software organizations, in: Proceedings of the 2010 International Symposium on Software Testing and Analysis, 2010, pp. 231-240. [4] HtmlUnit, DOI: http://htmlunit.sourceforge.net/ (last accessed June 2011). [5] Selenium, DOI: http://seleniumhq.org/ (last accessed June 2011). [6] R. Binder, Testing Object-Oriented Systems, Addison Wesley, 2000. [7] G.D. Lucca, A. Fasolino, F. Faralli, U.D. Carlini, Testing web applications, in: Proceedings of the 18th International Conference on Software Maintenance, 2002, pp. 310-319. [8] W. Wang, S. Sampath, Y. Lei, R. Kacker, An interaction-based test sequence generation approach for testing web applications, in: Proceedings of the 11th High Assurance Systems Engineering Symposium, 2008, pp. 209-218. [9] W. Wang, Y. Lei, S. Sampath, R. Kacker, J. Lawrence, A combinatorial approach to building navigation graphs for dynamic web applications, in: Proceedings of the 25th International Conference on Software Maintenance, 2009, pp. 211-220. [10] C. Musciano, B. Kennedy, HTML & XHTML: The Definitive Guide, 5th ed., O Reilly Media, 2002. [11] XHTML, DOI: http://www.w3.org/tr/xhtml1/#xhtml (last accessed June 2011). [12] XML Path Language, DOI: http://www.w3.org/ TR/xpath20/ (last accessed June 2011). [13] W. Wang, Y. Lei, A navigation graph builder for dynamic

Zoomer: An Automated Web Application Change Localization Tool 919 web applications, in: Proceedings of the International Conference on Computer Intelligence and Software Engineering, 2009, pp. 1-4. [14] JFree Chart, DOI: http://www.jfree.org/jfreechart/ (last accessed June 2011). [15] Open Source Web Applications with Source Code, DOI: http://www.gotocode.com (accessed July. 3, 2011). [16] S. Sprenkle, E. Gibson, S. Sampath, L. Pollock, Automated replay and failure detection for web applications, in: Proceedings of the 20th International Conference of Automated Software Engineering, 2005, pp. 253-262. [17] S. Sprenkle, H. Esquivel, B. Hazelwood, L. Pollock, WebVizOr: A Visualization Tool for Analyzing Test Results of Web Applications, Technical report, University of Delaware, 2007.