Abstract. Graphical User Interfaces (GUIs) are composed of virtual objects, widgets, which respond to events triggered by user actions. Therefore, test inputs for GUIs are event sequences that mimic user interaction. The nature of these sequences and the values for certain widgets, such as textboxes, causes a two-dimensional combinatorial explosion. In this paper we present Barad, a GUI testing framework that uniformly addresses event-flow and data-flow in GUI applications generating tests in the form of event sequences and data inputs. Barad tackles the two-dimensional combinatorial explosion by pruning regions of the event and data input space. For event sequence generation we consider only events with registered event listeners, thus pruning regions of the event input space. We introduce symbolic widgets which allow us to obtain an executable symbolic version of the GUI. By symbolically executing the chain of listeners registered for the events in a generated event sequence we obtain data inputs, thus pruning regions in the data input space. Barad generates fewer tests and improves branch and statement coverage compared to traditional GUI testing techniques.

Abstract. Alloy is a declarative modeling language based on first-order logic with sets and relations. Alloy problems are analyzed fully automatically by the Alloy Analyzer. The analyzer translates a problem for given bounds to a propositional formula for which it searches a satisfying assignment via an off-the-shelf propositional satisfiability (SAT) solver. Hence, the performed analysis is a bounded exhaustive search and increasing the bounds leads to a combinatorial explosion. We increase the efficiency of the Alloy Analyzer by performing incremental analysis via domain specific solvers. We introduce annotations that define data types, operations on these data types, and bindings from data types to domain specific solvers. This meta-data is utilized to automatically partition a problem into sub-problems and opportunistically solve independent sub-problems in parallel using dedicated constraint solvers. We integrate dedicated Integer and String constraint solvers into Alloy's SAT based backend. Experimental results show that using dedicated solvers and exploiting independent sub-problems provide better efficiency and scalability; for the chosen subjects, our technique enables up to an order of magnitude speed-up.

While Graphical User Interfaces (GUIs)

Alloy is a declarative modelling language based on first-order logic with sets and relations. Alloy formulas are checked for satisfiability by the fully automatic Alloy Analyzer. The analyzer, given an Alloy formula and a scope, i.e. a bound on the universe of discourse, searches for an instance i.e. a valuation to the sets and relations in the formula, such that it evaluates to true. The analyzer translates the Alloy problem to a propositional formula for which it searches a satisfying assignment via an offthe-shelf propositional satisfiability (SAT) solver. The SAT solver performs an exhaustive search and increasing the scope leads to the combinatorial explosion problem.We envision annotations, a meta-data facility used in imperative languages, as a means of augmenting Alloy models to enable more efficient analysis by specifying the priority, i.e. order of solving, of a given constraint and the slover to be used. This additional information would enable using the solutions to a particular constraint as partial solutions to the next in case constraint priority is specified and using a specific solver for reasoning about a given constraint in case a constraint solver is specified.

A Graphical User Interface (GUI) consists of virtual objects (widgets) that are more intuitive to use, for example buttons, edit boxes, etc. While GUIs have become ubiquitous, testing them remains largely adhoc. In contrast with console applications where there is only one point of interaction (the command line), GUIs provide multiple points each of which might have different states. This structure makes GUI testing especially challenging because of its large input space. Key Challenges in GUI Testing.A classic challenge in GUI testing is how to select a feasible number of event sequences, given the combinatorial explosion due to arbitrary event interleavings. To illustrate, consider testing a GUI with five buttons, where any sequence of button clicks is a valid GUI input. Exhaustive testing requires trying all 120 possible combinations because in the internal logic of the GUI, triggering of one event before another may cause execution of different code segments.An orthogonal challenge is how to select values for data widgets, i.e., GUI widgets that are used for user input, such as textboxes, edit-boxes and combo-boxes, and can have an extremely large space of possible inputs. To illustrate, consider testing a GUI with one textbox that takes a ten character string as input. Exhaustive testing requires 26 10 possible input strings (assuming we limit each character to be from the English alphabet in lower-case).Traditional GUI Testing Automation of GUI testing has traditionally focused on minimizing the event sequences. Data widgets have either been abstracted away by not considering GUI behaviors dependent on data values, or populated by values generated at random, or selected from a manually constructed set consisting of a small number of values [2]. As a consequence, data dependent behaviors are inadequately tested. For example, consider generating a string value that is necessary for satisfying an if-condition. Random selection is unlikely to generate the desired value. Manual selection requires a tedious code inspection and does not scale. A specification-based (black-box) approach may find this "special" value, however it would require detailed specifications, which are often not feasible to write. Symbolic Execution for GUI TestingWe envision a novel GUI testing approach based on symbolic execution [1]. Our goal is to generate values for data widgets and address data-flow as well as event-flow of a GUI application. By symbolically executing the underlying GUI code a test suite that maximizes code coverage while minimizing the number of tests needed to systematically check the GUI could be obtained. During symbolic execution all reachable paths of the program are explored and (for decidable constraints) infeasible paths are detected. For each feasible path an event sequence could be generated as a test.To illustrate the potential benefit of using symbolic execution, we used random generation to obtain values for the text input widgets of a small GUI application that we developed. The widgets take String as w...