CoDIT'13
Dynamic Reverse Engineering of GUI Models for Testing
Pekka Aho and Tomi Räty
Nadja Menz
VTT Technical Research Centre of Finland Oulu, Finland
[email protected] and
[email protected]
Fraunhofer FOKUS Berlin, Germany
[email protected]
Abstract — A significant challenge in application of modelbased testing (MBT) is that manually designing the test models requires considerable amount of effort and deep expertise in formal modeling. Reverse engineering can be used to automate parts of the modeling process but in applications with a graphical user interface (GUI), the dynamic behavior of the GUI is difficult to extract with static reverse engineering. Therefore we propose to use dynamic reverse engineering for automatically generating GUI models suitable for MBT. In this paper we compare various approaches for automated GUI modeling including an empirical tool study, propose a GUI component classification suitable for GUI automation, and present some examples of GUI automation strategies for efficient modeling of GUI applications. GUI automation; GUI modeling; model generation; modelbased GUI testing; MBT; MBGT
I.
INTRODUCTION
Due to the iterative software development processes, the requirements, design and implementation of graphical user interface (GUI) software change often, making GUI testing a challenging field for test automation. The maintenance effort required for updating the test suites because of the constant changes in the GUI decreases the benefits gained from test automation. Furthermore, the evaluation of the user experience in itself is difficult to automate. Manual testing and the use of capture/replay (CR) tools are to this day the most popular GUI testing approaches [1]. Nevertheless, while CR tools are an easy and straightforward first step towards more effective use of the testing recourses, a large number of test cases have to be manually updated after changes in the GUI. A number of research results have shown that modelbased testing (MBT) reduces the maintenance costs compared to the CR tools [2]. Traditionally in MBT, an abstract test model is created manually based on the requirements of the system under test (SUT), and then a MBT tool is used to generate tests based on the model and execute the tests to verify if the SUT implements the requirements correctly [3]. Due to the iterative processes used in the GUI development, the manual effort in designing and maintaining the models for model-based GUI testing (MBGT) negates a significant part of the increased efficiency gained from using test automation. Manually designing the test models requires also deep expertise in formal methods and good documentation of the system that is not always available [4].
978-1-4673-5549-0/13/$31.00 ©2013 IEEE
One way to automate the modeling effort is to use reverse engineering. Approaches for static source code analysis are already available in many software engineering tools, but the dynamic behavior of the GUI is difficult to extract with static reverse engineering. Dynamic reverse engineering is better suited for extracting the physical structure and behavior of the GUI, but it is more difficult to automate [4]. Dynamic reverse engineering does not require the source code of the system but it requires a way to programmatically observe, analyze and interact with the GUI shown to the user. The reverse engineering tool has to be able to control and interact with the GUI application to monitor and model the behavior of dynamically changing GUIs, e.g., when the visibility of a GUI component depends on the state of another component. Usually some input from the user, e.g., a test engineer, is required to generate models covering all the states of the GUI application because generating meaningful input for the text fields of the GUI is extremely challenging. For example, it is very improbable to find matching username and password for a login screen with random generation algorithms if the user has not provided any predefined set of test data. To reach every state of the GUI, valid combinations of values for the input fields of the GUI have to be provided by the user. Therefore an easy and practical way for the user to add valid test data and input values into the generated model is required [5]. We propose to reduce the required manual effort and expertise in creating the models for MBGT by using dynamic reverse engineering to automate a significant part of the modeling process. In this paper we compare various approaches for automated GUI modeling and present the results of an empirical tool study, propose a GUI component classification suitable for GUI automation and present some examples of GUI automation strategies for efficient modeling of GUI applications. II.
BACKGROUND AND RELATED WORK
Traditionally the models for automated testing have to be crafted manually from the specifications of the SUT [06_Katara]. There are several approaches aiming to reduce the time needed for designing the test models by automating some parts of the modeling process, such as creating the initial models through reverse engineering. Chickofsky [6] defines reverse engineering as the process of analyzing a subject system to identify the systems’ components, their relationships and to create representations of the system in
441
CoDIT'13
another form or at a higher level of abstraction. Reverse engineering approaches can be roughly divided into two categories: 1) static and 2) dynamic approaches. In static approaches the source code or other static representation of the system is analyzed without executing the system. In dynamic approaches the system is executed and its external behavior is analyzed [4]. The rest of this chapter presents the related work divided to static approaches in section A, dynamic approaches in section B, and the two most related dynamic reverse engineering approaches are presented in more detail in section C. A. Static Reverse Engineering of GUI Models Approaches for static source code analysis are already available in many software engineering tools [7]. Static approaches are well-suited for extracting information about the internal structure of the system and dependencies among structural elements [4], but require access to the source code of the system. The dynamic nature of object-oriented programs makes it very difficult to understand the behavior by just examining the source code [8]. However there are some approaches for static analysis of GUI software. Silva [9] presents an approach and GUISurfer tool for reverse engineering source code of GUI applications written in Java or Haskell, and creating finite state machine (FSM) models representing the behavior of the GUI. First an Abstract Syntax Tree (AST) is created by parsing the source code. Then code slicing is used to extract the GUI related parts of the code and a FSM model of the GUI is automatically created. Although the generated GUI models are not used for automated testing, the goal is that these models might be used to reason about the quality of the system. Another static approach for GUI analysis is presented by Staiger [10]. Their analysis tool is integrated into Bauhaus tool suite [11] which contains tools and techniques for recovering and visualizing program’s architecture. Staiger focuses on programs written in C or C++ which use a GUI library, e.g. the GIMP Toolkit (GTK+) or Qt cross-platform application framework. They analyze the source code to extract GUI-related parts of the program and provide models on higher level of abstraction to support maintenance tasks such as re-documenting the GUI, migrating to a GUI builder, GUI testing, architecture recovery for the GUI, and program comprehension in general. Unfortunately neither of the mentioned static approaches was able to generate models suitable for model-based GUI testing. B. Dynamic Reverse Engineering of GUI Models Reverse engineering the behavior of an object-oriented system is more difficult than understanding its structure. Therefore, executing the system and monitoring external behavior is used for dynamic reverse engineering [12]. Besides de-compilation techniques, dynamic approaches are the only option when the source code is not available. The dynamic approaches are better suited for extracting the behavior of GUI applications but more difficult to automate [4].
978-1-4673-5549-0/13/$31.00 ©2013 IEEE
Observation-based modeling [3] is a dynamic reverse engineering approach related to testing. It supports observation and testing of the system, analysis of different types of executions used as a basis for observations, and finally combines the different viewpoints to provide automated tool support to generate an initial test model that is suitable for model-based testing purposes. This generated model is then refined and verified against the specifications [3]. However, it has not been used to model GUI applications. Automated execution of a GUI application requires GUI automation. GUI automation means simulating an end-user by automated control and interaction through the GUI of an application. GUI automation is commonly used in automated GUI testing with predefined set of commands and means to verify if the expected GUI state was reached. GUI automation can be used also in dynamic reverse engineering, but instead of predefined set of commands, the interactions are selected from the set of available GUI components that are reverse engineered from the GUI, and instead of verifying if a specific GUI state was reached, the behavior of the GUI is observed and a model or another representation of GUI is generated. There are several approaches using dynamic reverse engineering for automating the modeling process for model-based GUI testing (MBGT). Samir [13] proposes a dynamic approach called GUI reverse engineering aspect (GUIRE). AspectJ is used for monitoring and recording GUI during runtime to generate models for migrating legacy Java GUI applications to web applications. The approach has not been used for testing. Grilo [4] introduces REGUI tool and a semi-automated approach to generate Spec# models from Windows GUI applications. The approach addresses the problem related to the lack of valid input values but the user has to guide the tool during the creation of the model, and the generated model has to be completed manually. On average only 50% of the Spec# model is created automatically. C. GUI Ripping and GUITAM The two dynamic reverse engineering approaches that are most related to our research are 1) Memon’s GUI Ripping approach and GUITAR toolset, and 2) Miao’s GUI Test Automation Model (GUITAM). 1) GUI Ripping and GUITAR toolset Memon et al have extensively published their research results on GUI Ripping [14, 15, 16, 18], a technique for dynamically reverse engineering models of GUI applications for test automation purposes. Memon’s team implemented GUITAR software [17], a model-based system for automated GUI testing, to execute and observe Java GUI applications to generate models for MBGT. The first step in GUI Ripping process is to use GUI Ripper tool (a part of GUITAR toolset) for extracting the structure of the GUI into an XML-based model called GUI forest. Each node of the GUI forest represents a window and encapsulates all the widgets, properties and values in that window [14]. The GUI Ripper launches the application under testing (AUT) and tries to execute each executable widget (a widget that belongs to AbstractButton class
442
CoDIT'13
family) of each window to invoke and analyze all the windows of the GUI [14]. The second step in GUITAR tool chain is to use gui2efg model converter to convert the structural GUI forest into another XML-based model called event flow graph (EFG) [17]. In EFG, each node represents an event, and all events that can be executed immediately after this event are connected with directed edges from it. The fact that the nodes of EFG are events (GUI actions) can be problematic if the data values of the GUI may have an effect on the results of executing a GUI action. In some cases there could be an unlimited number of nodes for executing a single button. The third step is to use the EFG as an input for a test case generator with a selected graph traversal algorithm for creating test sequences fulfilling a given event coverage criteria, such as covering all events or all edges. The generated test sequences can be executed with the Replayer tool of the GUITAR toolset [17]. Xie [18] proposes a more compact GUI model called event interaction graph (EIG) that can be automatically transformed from an EFG. EIG includes only systeminteraction events and with the smaller set of events it better suits rapid testing, such as smoke regression testing. An example of the differences between EFG and EIG can be seen in Figure 1.
Figure 1. An example of a GUI and it’s EFG and EIG.
Unfortunately GUITAR is not able to model dynamically changing GUIs, for example when the visibility of a GUI component depends on the state of another component. With such GUI applications, parts of the GUI are missing from the generated models and test cases [19]. A better coverage of the application under modeling is possible with trial and error and using application specific manual configurations, but more advanced GUI automation is required to monitor and model the behavior of dynamically changing GUIs. 2) GUITAM Miao [19] proposes a finite-state machine (FSM) –based GUI Test Automation Model (GUITAM). In GUITAM, a state of the GUI is modeled as a set of opened windows, GUI objects (widgets) of each window, properties of each object, and values of the properties. Events or GUI actions performed on the GUI may lead to state transitions and a transition in GUITAM is modeled with the starting state, the event or GUI action performed, and the resulting state. To reduce the amount of states into computationally feasible
978-1-4673-5549-0/13/$31.00 ©2013 IEEE
level, not all different property values are considered for distinguishing different states of GUITAM [19]. Miao [19] shortly describes a set of tools to automatically construct the GUITAM for a given AUT. The toolset is used to perform events or GUI actions on the GUI of given AUT, check and compare the GUI states, and generate GUITAM based on the behavior of the GUI. Test cases can be automatically generated by traversing the states of the GUITAM model [19]. Unfortunately the concrete syntax and structure of the created models and detailed description of the toolset is not published. Yang [20] proposes parameterized GUI state model (PGUISM) which is basically a manually parameterized version of GUITAM. To reduce the number of state transitions, only the events or GUI actions that lead to a state transition are included. Parameters are used to describe the context of the states [20]. III.
GUI DRIVING
In previous work [21], we presented our GUI driving approach and the GUI Driver tool for dynamically reverse engineering Java GUI applications for MBGT. GUI Driver simulates an end user by automatically executing and interacting with Java GUI applications, and observes the GUI application during runtime to automatically create models representing the states and the behavior of the GUI application. During the automated modeling process, GUI Driver executes each GUI action at least once, trying to reach all the possible GUI states of the application under testing (AUT). It also randomly adds textual or numerical input to the input fields of the GUI. The generated models include a structural model of each GUI state and one FSM-based internal GUI model describing the behavior of the GUI application as transitions between the GUI states. The structural model is a hierarchical tree structure of all of the objects of the focused GUI window including the relevant properties of the objects and values of the properties. The FSM-based GUI model extracts the GUI actions that can be selected in each state, and keeps track of already executed GUI actions and the state transitions following the executed GUI actions. All the generated models are saved into XML files. The FSM-based GUI model can be automatically transformed into other state-based model formats, such as GraphML [22] that can be used to generate test sequences with an open source MBT tool GraphWalker [23]. Then the generated test sequences can be executed with GUI Driver to test if the expected states in GUI application are reached with the given set of GUI actions. In [5] we proposed an iterative process of using GUI Driver for automated modeling and manually adding valid test data. When GUI Driver does not find any more new GUI states, it asks the user to provide valid input into a GUI state with at least one textual input field. The user provides the input straight into the input fields of the GUI application and the GUI Driver tool continues automated modeling when the user is ready. The input provided by the user is saved into the FMS-based GUI model and used in the automatic execution to find new GUI states. Using an iterative process of
443
CoDIT'13
automated modeling and manually providing valid input into the GUI, all states of the GUI application can be included in the generated models and all states of the GUI can be covered with the test cases generated from the models. We define a GUI state based on the visible GUI components, structure and properties of the active or focused GUI window or dialog. The most important factor in defining a GUI state is the available GUI actions (or widgets or events). For example, a window with a text field and okbutton would be modeled as the same GUI state regardless if the text field is empty or has text in it. On the other hand, there would be two different GUI states if the button would be disabled when the text field is empty and enabled when the text field has text in it. Formally, GUITAR, GUI Driver and GUITAM model a window in the same way. At a particular time t a window Wt is modeled in terms of: • all the GUI objects or widgets O that the window Wt contains: O ={ O1, O2, …, On }, • all the properties P of widget Oi : P ={ Pi1, Pi2, …, Pim }, i=1, 2, …, n; • the value V of property Pij : V ={ V11, V12, …, V21, V22, …, Vnm }, i=1, 2, …, n; j=1, 2, …, m; GUITAM and GUI Driver model a state of the GUI in a very similar way, the difference being that GUI Driver considers only the window that is active or focused in that particular state of the GUI and GUITAM models all opened windows of the GUI. More detailed comparison would require the concrete syntax and structure of GUITAM. Although the definition of a window in GUI forest model [14] is almost identical to GUITAM and GUI Driver, the GUI Ripper of GUITAR toolset is used to capture only one state for each window, and EFG captures the flow of the GUI events, not the state of the GUI. GUI Driver reduces the amount of GUI states by considering only a selected set of different property values for distinguishing different states, the same way as in GUITAM. For example the data values of the input fields of the GUI are not considered when GUI Driver distinguishes different states, but instead they are taken into account in state transitions and saved into the model as part of an executed GUI action. That way pushing the same login button of a login window with two different combinations of username and password would be modeled as two different GUI actions, although the GUI object or widget is the same. Compared to the GUITAR toolset, GUI Driver interacts more with the GUI, using advanced GUI automation techniques to address the challenge with dynamically changing GUIs. GUI Driver does not only push all the available the buttons and menus, as GUITAR, but also interacts with other kinds of GUI widgets, such as lists, check boxes and radio buttons, and generates textual or
978-1-4673-5549-0/13/$31.00 ©2013 IEEE
numerical input for the text fields and text areas of the GUI application. In most of the dynamic GUI reverse engineering approaches for testing, such as the mentioned GUITAR, GUITAM and our GUI driving approach, the test oracle is based on observed behavior of the GUI application. Using this kind of test oracle, changes in the GUI and inconsistent behavior can be detected, but validation and verification against the specifications is challenging. Compared to the other related approaches, a major advantage of the GUI Driver tool is an easy and practical way for the user to provide valid input directly to the input fields of the GUI application, and the data from the user is automatically saved into the generated models. In traditional MBT the test data is included in the manually created models but manually editing generated models is usually very difficult and requires deep understanding on the created models. IV.
EMPIRICAL TOOL STUDY
To make a practical comparison on automated modeling capabilities of the GUI Driver tool and the GUI Ripper of the GUITAR toolset, we used both tools to model various open source Java GUI applications, including TerpOffice calculator TerpCalc 4.0 [24] and BuddyTalk [25] instant messaging application. Since the generated models were intended for test case generation, the main criteria for the comparison included how comprehensive the generated models were, for example the number of windows of the modeled GUI application the tools found and modeled. If parts of the GUI application are missing from the generated models, they would be missing also from the test cases generated from the models. In modeling of TerpCalc 4.0, GUI Ripper had to be manually configured to ignore “Exit” from “File”-menu. Otherwise it was the first GUI action (or event) to be executed, and the GUI ripping process ended right away with only one window found. When configured properly, GUI Ripper executes all the buttons and menus of the TerpCalc application and finds 6 windows (windows A-F in Figure 2) in less than a minute. However, it fails to find “Show graph window” (window G in Figure 2) and the “Save graph window” (window H in Figure 2) because it executes the GUI actions always in the same order without any random input and it does not select any items from a list widget. GUI Driver spends more time in the modeling because it executes more GUI actions than GUI Ripper. GUI Driver finds all the 8 windows shown in Figure 2, as it automatically selects list items from the GUI during the modeling. No application specific modeling configurations are needed because GUI Driver is able to handle System.exit() when selecting “Exit” from “File”-menu and restart the AUT automatically.
444
CoDIT'13
Figure 2. Windows of TerpCalc 4.0.
BuddyTalk was a more challenging application for GUI automation because it used org.jdesktop.swingx.JXBusyLabel for indicating that user should wait until the login process was finished. BuddyTalk also uses labels that can be clicked to reach another state of the application in similar way as buttons are usually used. For example clicking the “About” label in the lower right corner of the Login window or the Buddy list window (windows A and C in Figure 3) opens the About window (window B in Figure 3). BuddyTalk would have been also a good example of an application that requires valid username and password from the user if it did not provide valid hardcoded username and password for testing the application.
Figure 3. Windows of BuddyTalk.
GUI Ripper does not handle busy labels, so it had to be configured to wait about 8 seconds between each GUI action it executes. Otherwise it could not model the window that opens after a valid login. Such a long waiting time between every executed GUI action significantly increases the time required for modeling the application. BuddyTalk was very
978-1-4673-5549-0/13/$31.00 ©2013 IEEE
challenging application for GUI Ripper because a significant part of the functionality and new windows are launched by selecting items from lists and clicking on “About” label opens more windows. Therefore GUI Ripper could open and model only 2 (windows A and C in Figure 3) out of 8 windows. GUI Driver on the other hand waits until the busy label indicates that the application is ready and then continues the modeling. Therefore GUI Driver does not require increased waiting time to model BuddyTalk. The current version of GUI Driver does not always find all 8 windows of BuddyTalk. There is a 25% chance to find “Custom status window” (window D in Figure 3) as the window is shown only by selecting “Custom”, one of the four items of a combo box widget in window C in Figure 3. Iterating all items of combo boxes and other GUI options during the modeling was added to the roadmap of GUI Driver development. However, even without any input from the user the current version of GUI Driver finds at least 7 out of 8 windows of BuddyTalk application every time. This empirical comparison of the modeling capabilities of GUITAR and GUI Driver tools shows the benefits of versatile GUI automation techniques, as implemented by the latter, in generating more comprehensive models of GUI applications. V.
CLASSIFICATION OF GUI COMPONENTS
To implement the level of GUI automation that is required for dynamic reverse engineering of GUI applications, the analyzed GUI widgets have to be classified. The classification enables a different kind of handling for different types of widgets and using more advanced strategies in choosing in which order the enabled GUI widgets should be selected for interaction. Wang [26, 27] introduces two different classification examples for abstracting GUI widgets to create platform-independent user interface specifications. Because neither of them was wellsuited for dynamic GUI reverse engineering, a new GUI widget classification was required. We divided GUI widgets into four groups: 1) GUI controls, 2) GUI options, 3) GUI inputs, and 4) GUI infos. GUI controls are widgets that the user selects or presses and a state transition, i.e., a change of GUI state is usually expected. For example buttons and menus belong to GUI controls. In some applications the user has to double-click a control to activate the corresponding action, and usually selecting a menu opens a list of menu items and another selection is required from the user to trigger the action from a menu item. GUI options are widgets that are used to make a selection from a list of choices, such as a group of radio buttons, a list of items, a combo box or a pop-up box, or simply an on/off switch, such as a check box. Usually selecting an option does not trigger a change of GUI state. However, sometimes the selection of an item on a list enables a button or changes the values of other widgets shown on the GUI. In case of BuddyTalk, introduced in chapter 4, selecting list items and a specific item of a combo box changed the GUI state by showing a new window of the GUI application.
445
CoDIT'13
GUI inputs are widgets that allow the user to provide input in a relatively free manner. For example a text field or text area allows the user to enter any textual input and only the length of the input is limited. Of course the format of the input may be otherwise limited and usually the user is informed about the correct syntax or format with a label near to the input widget. The input could be also other than text, such as a drawing on a canvas. Also a map that the user can zoom and move around is categorized as a GUI input. GUI infos are widgets that the user usually cannot modify, select or otherwise interact with, such as labels and pictures. Labels are commonly used next to text fields or other input widgets to inform the user of the purpose or format of the input. Therefore a change in GUI infos often indicates a change of the GUI state. However, there are GUI applications using labels that can be clicked in a similar way as buttons to change the state of the GUI, such as the BuddyTalk application. The classification and example widgets are presented in Table I. TABLE I.
CLASSIFICATION OF GUI WIDGETS
in some GUI applications pressing buttons with empty data fields results in error messages informing the user to provide input first, and pressing the same buttons after providing the input triggers the intended functionality. By keeping track of the GUI actions that have already been selected and the resulting state transitions and other effects of executing the actions, it is possible to create more advanced selection strategies. An easy one is to prioritize actions that have not been selected yet or have been selected only once. If all actions of the current GUI state have been executed, based on the results of executed actions it is possible to select an action that leads to another GUI state with actions that have not been executed yet. Sometimes more than one action and traversing through another GUI state is required to reach a GUI state with new actions. Usually, when no other strategies can be applied, a good choice is the simple random selection. The downside is that occasionally random selection ends up in a never ending loop. For that reason a mechanism for detecting and dealing with loops in the GUI automation is useful. VII. CONCLUSIONS AND DISCUSSION
Classification
Example widgets
GUI controls
Button, menu item
GUI options
Radio button, check box, list, tree, combo box, popup box
GUI inputs
Text field, text area, password field, canvas
GUI infos
Label, picture
VI.
STRATEGIES FOR SIMULATING USER INTERACTIONS
In addition to GUI automation and analyzing functionalities, strategies for selecting one of the available GUI actions (widgets) are required for efficient dynamic reverse engineering. To allow the use of the strategy on various different kinds of GUI applications, an abstract classification of the GUI actions (widgets) should be used in creating more advanced strategies. A classification suitable for dynamic reverse engineering of Java GUI applications was presented in Chapter 5. The simplest strategy for interaction is selecting each of the available GUI components in the order they are analyzed or observed. This is the strategy used in GUI Ripper of the GUITAR toolset. Unfortunately the simplest is not the most efficient in this case, as was shown in Chapter 4. Another simple strategy for interaction is randomly selecting one of the available GUI components until all the GUI actions have been executed at least once. With enough time it is probable that all available GUI actions will be executed. However, there are various ways to add more intelligence and efficiency to the selection strategy. In dynamic reverse engineering, a good goal for a strategy is to try to reduce the time required for modeling by finding all or as many different GUI states with as few GUI actions as possible. An example of a more intelligent strategy is choosing GUI controls first without changing the data values, then again after changing one data value at a time. For example,
978-1-4673-5549-0/13/$31.00 ©2013 IEEE
This paper extended our previous work by comparing our GUI driving approach to the most related research and presenting the results of an empirical tool study making a practical comparison of the modeling capabilities of the GUI Ripper of GUITAR toolset and our GUI Driver tool. The empirical study showed that compared to the GUITAR toolset, GUI Driver achieved a better automated modeling coverage due to the more advanced GUI automation strategies and more comprehensive support for interacting with different kinds of GUI components. When the generated model covers all parts of the GUI application, also the test cases generated from the model can reach all parts of the GUI application. Also, some new ideas for further development of GUI Driver arose during the study. In order to use more advanced GUI automation strategies, a suitable GUI component classification was required. Since a suitable existing classification could not be found, we proposed a new one, specifically designed for GUI automation. We also presented some requirements and examples of GUI automation strategies suitable for efficient dynamic reverse engineering. An approach for generating meaningful input for the input fields of the GUI would open new possibilities for more advanced GUI automation strategies. An interesting area for further research would be the use of static source code analysis for searching meaningful input for dynamic GUI reverse engineering. REFERENCES [1] [2]
[3]
K. Li and M. Wu, "Effective GUI test automation: developing an automated GUI testing tool", SYBEX Inc., Alameda, CA, 2004. M. Utting and B. Legeard, "Practical model-based testing: a tools approach", Morgan Kaufmann Publishers Inc, San Francisco, CA, USA, 2006. T. Kanstrén, "A framework for observation-based modelling in model-based testing", VTT Publications 727, Espoo, Finland, 2010.
446
CoDIT'13
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11] [12]
[13]
[14]
[15]
A. M. P. Grilo, A. C. R. Paiva, and J. P. Faria, "Reverse engineering of GUI models for testing", 5th Iberian Conference on Information Systems and Technologies (CISTI), Santiago de Compostela, Spain, 2010. P. Aho, N. Menz, and T. Räty, "Enhancing generated Java GUI models with valid test data", 2011 IEEE Conference on Open Systems (ICOS 2011), 25-28 September 2011, Langawi, Malaysia. E. J. Chikofsky and J. H. Cross II, "Reverse engineering and design recovery: a taxonomy," IEEE Software, vol.7, no.1, pp. 13-17, Jan 1990. R. Kollmann, P. Selonen, E. Stroulia, T. Systä, and A. Zündorf, ”A study on the current state of the art in tool-supported UML-based static reverse engineering”, Proceedings of the 9th Working Conference on Reverse Engineering (WCRE'02), IEEE Computer Society Washington, DC, USA, 2002. T. Systä, “Static and dynamic reverse engineering techniques for Java software systems”, Acta Electronica Universitatis Tamperensis 30, Tampere, Finland, 2000. J. C. Silva, C. C. Silva, R. D. Gonçalo, J. Saraiva, and J. C. Campos, "The GUISurfer tool: towards a language independent approach to reverse engineering GUI code", Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing systems, Berlin, 2010, Germany, pp. 181-186. S. Staiger, “Reverse engineering of graphical user interfaces using static analyses”, 14th Working Conference on Reverse Engineering, Vancouver, BC, Canada, 29-31 October 2007. Project Bauhaus web pages, http://www.bauhaus-stuttgart.de/bauhaus (accessed 29 of Nov 2012) L.C. Briand, Y. Labiche, and J. Leduc, “Towards the reverse engineering of UML sequence diagrams for distributed, multithreaded Java software”, Technical Report, Carleton University (SCE-04-04), September, 2004. H. Samir, A. Kamel, "Automated reverse engineering of Java graphical user interfaces for web migration", ITI 5th International Conference on Information and Communications Technology (ICICT), Cairo, Egypt, December 2007. A. M. Memon, I. Banerjee, and A. Nagarajan, “GUI ripping: reverse engineering of graphical user interfaces for testing”, Proceedings of the 10th Working Conference on Reverse Engineering (WCRE '03). IEEE Computer Society, Washington, DC, USA. A. M. Memon and Q. Xie, “Studying the fault-detection effectiveness of GUI test cases for rapidly evolving software”, IEEE Trans. Software Engineering, vol. 31, no. 10 (October 2005), 884-896.
978-1-4673-5549-0/13/$31.00 ©2013 IEEE
[16] A. M. Memon, "An event-flow model of GUI-based applications for testing", Software Testing, Verification & Reliability, Volume 17, Issue 3 (September 2007), pp. 137 - 157. [17] The web pages of the GUITAR toolset, http://guitar.sourceforge.net (accessed 29 of Nov 2012) [18] Q. Xie and A. M. Memon,”Rapid crash testing for continuously evolving GUI-based software applications”, Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM '05), IEEE Computer Society, Washington, DC, USA, 473-482. [19] Y. Miao and X. Yang, "An FSM based GUI test automation model", 11th International Conference on Control, Automation, Robotics and Vision (ICARCV 2010), Singapore, 7-10th December 2010. [20] X. Yang, Y. Miao, and Y. Zhang, “Model-driven GUI automation for efficient information exchange between heterogeneous electronic medical record systems”, 19th International Conference on Information System Development (ISD), 25-27 August 2010, Prague, Czech Republic. [21] P. Aho, N. Menz, T. Räty, and I. Schieferdecker, "Automated Java GUI modeling for model-based testing purposes", 8th International Conference on Information Technology : New Generations (ITNG 2011), 11-13 April 2011, Las Vegas, Nevada, USA. [22] The web pages of the GraphML file format, http://graphml.graphdrawing.org/ (accessed 29 of Nov 2012) [23] The web pages of GraphWalker open source model-based testing tool, http://graphwalker.org/ (accessed 29 of Nov 2012) [24] The web pages of TerpOffice calculator TerpCalc 4.0, http://www.cs.umd.edu/~atif/TerpOfficeWeb/TerpOfficeV4.0/TerpCa lc (accessed 29 of Nov 2012) [25] The web pages of BuddyTalk instant messaging application, http://sourceforge.net/projects/buddytalk (accessed 29 of Nov 2012) [26] L. J. Wang, A. S. M. Sajeev, and L. Inchaiwong, "A formal specification of interaction widgets hierarchy framework", Proceedings of the 3rd International Conference on Information Technology: New Generations, IEEE Computer Society Washington, DC, USA, 2006, pp.658-664. [27] L. J. Wang and A. S. M. Sajeev, "Abstract interface specification languages for device-independent interface design: classification, analysis and challenges", 1st International Symposium on Pervasive Computing and Applications, 3-5 August 2006, Urumchi, Xinjiang, China.
447
