The GUI testing process involves the following phases:
1,
Determine the [url = javascript:;] test [/url] target. In the first phase of GUI testing, you must first determine what to test, that is, determine which GUI events or event sequences to test.
2. Generate Test input. Gui test input can refer to the specification or structure of the software, which consists of the initial conditions and event sequence.
3,
Generate the expected output. Generates the expected results after each event is executed.
4,
Test execution and verification. In the initial conditions of test input, events in the event sequence are sequentially executed, and the expected output and actual output of each event are compared. If the two do not match, the current test fails.
5. Determine the test adequacy. After some or all tests are executed, analyze the execution status of all tests and determine whether the test meets the expected requirements.
6,
Regression testing. After the program changes, select some test cases for GUI changes or regenerate a new test case to re-test the changed parts.
For most GUI tests, the preceding six steps are required. Each step can be completed manually or automatically by means of tools. There are some independent [url = javascript:;] automated [/url] [url = javascript:;] technology [/url] or tools, for example, use the standardized Requirement Description to generate test cases, use the finite state machine model to generate test cases, use the recording/playback tool to record the event sequence, and use the object capture tool to generate the expected status, the script is used to automatically execute the test, the test data table is used to drive the automatic execution of the test, and some regression testing methods. Although these methods can automate a test process, the overall test efficiency is reduced because [url = javascript:;] other [/url] are not automated, it is difficult to reflect the advantages of [url = javascript:;] Automated Testing [/url. Even if we combine automated tools and technologies for all processes, we need to consider the [url = javascript:;] Learning [/url] Of all technologies and their compatibility issues. Therefore, it is difficult to effectively use these tools or technologies to solve specific test problems.
The existing testing and development environment and the testing frameworks of MI and [url = javascript:;] IBM [/url], although a variety of [url = javascript:;] test Technology [/url], but they have various problems. For example, the generation and maintenance of test cases in the framework cannot be automatically executed, which affects the test efficiency. The manual generation of Detection Points and verification points in the framework affects the test results; the script architecture in the framework affects the maintainability of the test. It can only perform a comprehensive test on a small-scale GUI and affect the universality of the test. Therefore, to establish a comprehensive and effective overall GUI testing framework, it must meet the requirements of the framework in terms of efficiency, compatibility, effectiveness, maintainability and universality.
1. Overall testing framework
As shown in the overall GUI testing framework 1 built by the author, it consists of eight components: gui-related models, test-related data, test script architecture, Test Case Generation, test execution and verification, test case maintenance, Test Coverage Evaluation, and core control engine. The GUI-related models fully describe the structure and functions of the GUI, which is the basis of other components. Test-related data and test script architecture control test resources and separate test design and test execution to support automatic test execution. Test Coverage Evaluation uses an event-based coverage evaluation standard, and uses GUI events and interactions between events to determine whether the test has reached the expected level.
The core control engine coordinates all parts of the framework to complete GUI testing activities. Before executing the test, it first reviews the correctness and integrity of the test data, and then generates some test cases. After adjustment of the Coverage Evaluation Section, determine the test case set. During the test execution, test execution and verification are run based on the test data and test case set. When a problem occurs, stop the current execution and call a new test case to continue the test. Before the regression test, when the tested procedure changes, the test case maintenance part re-maintains all test cases to fix invalid test cases.
Figure 1 Overall Test Framework
The test case generation part of the framework uses a coverage-based method to automatically generate test cases that can quickly meet the coverage criteria, and automatically generate the expected output while generating test cases. The framework application test data and test scripts are used to automate the test execution process. The author has applied a new method to comprehensively maintain the GUI test cases and automatically repair the invalid test cases due to Gui changes. These technologies meet the efficiency requirements of the overall framework.
The GUI-related models in the framework make the technologies used in the testing process compatible with each other, and fully describe the structure and functions of the GUI, it can effectively assist in the generation, maintenance, execution, verification, and Coverage Evaluation of test cases, and meet the compatibility requirements of the framework. At the same time, these GUI models are independent of the application platform and are easy to develop and use. They are also suitable for GUI programs of different sizes and meet universal requirements.
The Framework's test scripts and test-related data control the test resources, apply a complete data-driven script architecture, and use independent scripts to process all test types and test projects, the overhead of test script maintenance is canceled. In addition, use test data to drive test script execution, control the test execution process and actions, and transfer the maintenance [url = javascript:;] work [/url] of the test script to the data table, this satisfies the maintainability requirements of the entire framework.
Instead of the traditional manual generation of expected output states, the framework adopts a new result verification mechanism. When a test case is generated, the expected output is automatically generated based on the event type and environment, and the necessary information is obtained from the expected output and compared with the actual running result. In this way, the important States and key attributes missed by manual operations are solved, and the reliability requirements of the overall framework are met.
2. Gui Model
To meet the requirements of the overall testing framework, a unified GUI model is required to integrate multiple testing technologies. The model should not only fully and effectively describe the various features of the GUI, but also help implement the functions of the overall framework, assist in the generation and maintenance of test cases, test execution and verification, and test coverage evaluation. In addition, the model should be suitable for a wide range of applications and be easy to develop and use.
Gui objects include many types, such as Windows, drop-down menus, buttons, and scroll bars. Users can interact with the GUI by performing corresponding actions. Each object has many attributes, which change with the condition. A large GUI can be divided into many smaller parts, which are hierarchical. Different Mode windows belong to different layers. For example, when you execute some actions to open the mode window, the input focus will be transferred from the original window to the current mode window range. To summarize the features of the GUI, you can define the GUI as follows:
Definition 1: GUI is a hierarchical software system. Each layer contains multiple objects and each object corresponds to multiple attributes. Different attribute values make the GUI in different States. By receiving events generated by users and systems, the GUI status changes and responds graphically.
A gui is a software system that displays images. The property values of the objects contained in a GUI change with different conditions, and the GUI output also changes. The output produced by GUI changes can be seen as its state, that is, a set of objects and the attributes contained by these objects. The GUI status can be defined as a triple:
1. O = {O1, O2, O3 ,..., Om}
2. p (o) = {P1, P2, P3 ,... Pn}, P =
Property (object, value)
3. S = P (O1 )? P (O2 )? ...? P (OM)
Object set O = {O1, O2, O3 ,..., Om} refers to all objects contained in the GUI. The property set P (o) = {P1, P2, P3 ,... Pn} refers to object o? All attributes contained by O. Each attribute can be expressed as P = property (object, value ),
Property P is a Boolean value, indicating whether the property is true or false. Is the first parameter an object? O, indicates the object to which the property belongs; value indicates the property value. For example, the property P = color (Label, red) indicates that when the color of the Object Label is red, P = true; when the color of the object label is not red, P = false.
The GUI status can be described as a collection of information, including the GUI object type and object attributes. In Example 2 (a), an open dialog box for IE and some attributes of the "open" tag and "cancel" button are displayed. Figure 2 (B) shows the current state of the GUI, which consists of some objects and some attributes of the objects. The attributes of an object can be changed during GUI execution. In some States, the attribute values are true, while in other States, the attribute values may be false, the changes in attributes also change the GUI status. Attributes become meaningless under certain conditions. For example, when the window win exists, the property background-color (Win, red) makes sense. When the window win is closed, the property background-color (Win, red) it becomes meaningless.