【文章內(nèi)容簡介】 models of GUI test profiles. The relationship between test profiles and fault detection are studied in Section IV. Conclusions and future work are given in Section V. II. GUI TEST CASE CHARACTERIZATION In this section, first we will introduce the definition of GUI test case. Then the characteristics of GUI test cases will be discussed. A. GUI Test Cases The basic inputs to a GUI application are events. User operations trigger events and the GUI application responses to these events. An event contains the following information: the type of action (., a mouse click), the GUI object on which the action is performed (., a button), and the parameters of the action (., on the point of (10,16)). Usually, an event can only be accepted at certain states of the GUI application under test, for example, the states at which the corresponding GUI object is visible and enable. The “state” of the GUI application is important for the executions of events. Following the definition in [9], we represented the state of a GUI as a set of GUI objects and a set of properties of these objects. In this paper, we define a handler as all the pieces of code that are possible to be executed when the correspond ing event is input. Commonly, a handler includes a responding function 261 and the functions/procedures that are called by the responding function. Note that many event handlers are implemented in certain prepiled foundation libraries (., the MFC of Mic rosoft Visual C++, JDK of Java, and the VCL of C++ Builder). In this paper, we only study the code specially implemented for the AUT. The handlers in prepiled foundation libraries are not concerned. In brief, if an event is responded by the code in prepiled libraries, or is not responded by any code at all, we say that the event does not call any event handler. Dmax are defined based on the length of the shortest path between two events on the eventflow graphs (EFGs) and the integration tree (IT) [10] of the AUT (referring to [10] for the definition of EFG and IT). Note that when two events are contained in different EFGs, the shortest path between them is the shortest path on a global EFG whic h is the binatio n2 of all EFGs and the IT of the AUT. Let d(ei,ej) denote the le ngth of the shortest path between two events ei and ej. Given a test case t = ?S0, e1。e2?！?。 en?, A GUI test case can be defined in many forms, such as a Dmax ??max {d (ei , e j )} . 1?i? j?n piece of test script [5][6], an event [2], or an event sequence [2][7] [8]. In this paper, we follow the definition in [8] that a GUI test case is a “l(fā)egal event sequence” with the state in which the event sequence is executed. That is, a GUI test case can be denoted as ?S0, e1。e2?！?。 en?, where event e1 can be accepted by the application in S0, and event ei can be accepted right after event ei1 is executed (for i = 2,3,…, n). Commonly, S0 can be any state in which the GUI object with respect to e1 is enable and visible. B. GUI Test Case Characteristics A GUI test case contains an event sequence. By analyzing the event sequence, we can get many characteristics of the test case. Table 1 shows some of them. Table 1 GUI Test Case Characteristics Characteristic Description L The length of a GUI test case NH The number of handler calls of a GUI test case PR The proportion of reachability events in a GUI test case Dmax The maximum length of the shortest path between two events in a GUI test case N(w) The number of times that a GUI test case operates on window w The length of a test case (denoted as L) is the le ngth of the event sequence contained in the test case. It is the “granularity” property of a GUI test case (the amount of input given by the test case, referring to [11]). L has been shown significantly affecting the fault detection in testing [11][12]. For example, the L of a GUI test case ?S0, e1。e2?！?en? is n. The number of event handler calls, denoted as NH, is the times of the test case calling event handlers. This characteristic neglects the events that do not call any event handler in the source code. Obviously, NH ? L. PR is the proportion of reachability events to all events in a This characteristic describes how “deep” a test case can reach in the GUIs of the AUT. The GUIs of an AUT consist of a set of windows. For each window w, N(w) studies how many times a test case will operate on the objects contained in w. Many other characteristics can be obtained from GUI test cases, for example, the number of events covered by a test case, the proportion of events that performs on the main window, etc. In this paper, we only study the characteristics in Table 1 for demonstration. III. GUI TEST PROFILE MODELING Test profile (or operational profiles) can be modeled in many forms. In [3], several software operational profile models based on equivalence class division of the input domain are introduced. These models can also be used as GUI test profile models. However, how to divide the input domain into equivalence classes is not concerned. In GUI testing, the test cases provide rich information, such as the characteristics presented in Section II. The information can be used as equivalence relations for dividing the input domain. With these equivalence relations, in the process of testing, we can adjust the GUI test profile to achie ve certain objectives, such as detecting more faults, or covering more code.