| Resumo: |
Graphical User Interface (GUI) testing is the process of testing a software application with a graphical front-end to guarantee that it meets its specification. Given the myriad of possible (human-computer) interactions in such a user interface, GUI software testing is a rather expensive and cumbersome phase of the whole software development cycle. For instance, a form containing n interface controls requires a factorial number (n!) of test cases to test all possible combinations.
In GUI software testing, a good test suite must not only cover all functionality of the system but also ensure that the GUI itself is fully exercised. Creating such a test suite is overly difficult because the software tester has to deal with (i) the domain size as well as (ii) the action sequences. This is called the test case explosion problem. To illustrate the importance of this problem consider, as an example, the fact that even a very small program, such as Microsoft WordPad, has 325 possible GUI operations. Action sequencing is also a problem because some functionality of the system may require a specific sequence of GUI events.
Given these GUI's idiosyncrasies, manually generating a comprehensive suite of test cases is extremely difficult (not to say insurmountable). Hence, these issues have driven the GUI testing problem domain towards (semi/full) automation.
GUIs represent the primary conduit through which a user "perceives" the system and contributes to the users' decision of using such system. This area has been actively studied by giving particular focus on what is defined as "usability", and several pattern languages exist to describe the reusable elements of user-computer interaction. Most of today GUIs are built around these patterns, and thus their behaviour is expected to vary only slightly.
The notion of patterns was introduced in the field of civil architecture: "each pattern describes a problem which occurs over and over  |
Resumo
Graphical User Interface (GUI) testing is the process of testing a software application with a graphical front-end to guarantee that it meets its specification. Given the myriad of possible (human-computer) interactions in such a user interface, GUI software testing is a rather expensive and cumbersome phase of the whole software development cycle. For instance, a form containing n interface controls requires a factorial number (n!) of test cases to test all possible combinations.
In GUI software testing, a good test suite must not only cover all functionality of the system but also ensure that the GUI itself is fully exercised. Creating such a test suite is overly difficult because the software tester has to deal with (i) the domain size as well as (ii) the action sequences. This is called the test case explosion problem. To illustrate the importance of this problem consider, as an example, the fact that even a very small program, such as Microsoft WordPad, has 325 possible GUI operations. Action sequencing is also a problem because some functionality of the system may require a specific sequence of GUI events.
Given these GUI's idiosyncrasies, manually generating a comprehensive suite of test cases is extremely difficult (not to say insurmountable). Hence, these issues have driven the GUI testing problem domain towards (semi/full) automation.
GUIs represent the primary conduit through which a user "perceives" the system and contributes to the users' decision of using such system. This area has been actively studied by giving particular focus on what is defined as "usability", and several pattern languages exist to describe the reusable elements of user-computer interaction. Most of today GUIs are built around these patterns, and thus their behaviour is expected to vary only slightly.
The notion of patterns was introduced in the field of civil architecture: "each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". The above definition works perfectly for software as well. In addition, patterns can be applied to selectively address specific challenges and problems with recurrent nature. Thus, patterns are useful and express instances of good design practices while embodying high-level principles and strategies.
The authentication form is an example of a GUI recurrent behaviour (pattern). In visual terms, the user always expects to see two text boxes, one for the login and another for the password, and a submit/login button. When the end-user enters data and submits the form, the GUI can offer common outcomes: (i) display a message inside of the page; (ii) display a message outside of the page; (iii) disable a button; (iv) leave the page; and (v) remain in the page. Generically, to test an authentication form it will be useful to test the behaviour for a valid username and password, a valid username and invalid password, blank username, blank password.
Since the answers to these test cases may vary slightly among different GUIs, it is useful to give the tester the possibility to configure the specific behaviour of the GUI under test in order to reuse the same testing approach in different GUIs. This will contribute to increase testing reuse and diminish the GUI testing effort.
|