1. Design background
With the development of IT industry, the products become more and more complex, and the business and processes at the web end become more complicated. At present, UI testing is only for a single page, with a large amount of operations. In order to meet the needs of multi-page functions and processes and save man-hours, this UI automation testing program is designed. The aim is to provide interfaces that are integrated into the snail automated testing framework to facilitate the design of use cases.
The whole program is designed based on selenium. The program re-encapsulates the interface provided by selenium to meet the daily use case design. The re-encapsulated interface solves the problems of element loading, element location analysis and so on, which can make the use case design simpler.
The Selenium model was adopted. For one thing, this is an open source framework for users, who want to spy on one thing or two. Second, Selenium can be seamlessly accessed. This is a tool for testing Web applications, which supports multi-platform, multi-browser, multi-language to realize automated testing. Selenium2 encapsulates the native API of the browser into a WebDriver API, which can directly operate the elements in the browser page and even the browser itself (screen capture, window size, startup, shutdown, etc.), so it is just like the real user is operating.
Currently supported: Mac, Windows operating system, chrome, Firefox, IE browser.
2. Working principle
Add test cases in snail management background.
Snail management background test case execution calls the task execution interface and transmits the task id and JSON format string of test data to the program.
The program analyzes and processes the acquired data.
After launching the browser, selenium-webdriver binds the target browser to a specific port, and the launched browser acts as the server of webdriver.
The client (that is, the test script) sends an HTTP request to the server via ComandExecutor (communication protocol: The WebDriver Wire Protocol, in the body of the HTTP request, the JSON format string specified by the WebDriver Wire protocol will be used to tell Selenium what we want the browser to do next).
The server side needs to rely on the native browser component to convert the command of the Web Service into the call of the browser native to complete the operation.
Finally, the processing result and task id are returned to the snail through JSON string format, and the execution result of each use case can be viewed through the snail’s management background.
3. Introduction to the framework
3.1. Engineering Structure
According to the actual business process, the corresponding interface is called to realize the WEB-UI automatic test case. Case layer can call the interface between service layer and pageObject layer. pageObject is a package for each page element, and service is a package for a common business module function. For example, a test case that queries enterprise information needs to rely on login. This business function can directly call the interface in service. The creation of an enterprise query can call the interfaces in pageObject, and then according to the business process of the query, these interfaces are strung together in the test case to form a UI automation test case, the details of which will be illustrated in the following examples.
Such as enterprise inquiries. Before querying, you need to log into the management background. The login operation has been encapsulated in the business layer. You can directly call the interface of the service layer without paying attention to the details of this step. After logging in, you need to specify a path, find the corresponding space, and directly call the model layer interface. you don’t need to care about the details of this step. Next, create a query. All positioning methods for creating a query are also encapsulated in the business layer. This is the realization of an enterprise query and the most important link in use case design.
The whole project is based on selenium and is built in pageObject mode. The following is an introduction to several important modules in the project.
3.1.1 Driver-Interface Layer
Operations on all elements of a web page are defined and implemented in driver. Driver re-encapsulates the interface provided by selenium and provides the encapsulated interface to the outside. PageObject has implemented some common methods, such as assigning values to input boxes, etc. currently, there are few methods to encapsulate pageObject, and most functions can be implemented through selenium. The driver layer encapsulates the open source tool interface for the second time. in order to drive a browser, there is also an indispensable tool-browser driver. this driver is placed in the Referenced Libraries, and the version of the driver must match the version of the browser under test.
3.1.2 Model-Data Model
A method used to create a data model in order to separate test data from test cases. The specific test data is initialized. Elements that need test data in a business process can be defined in a model for easy management and code reading.
3.1.3 pageobject-business layer
PageObject mode, which uses the interface form to encapsulate the elements needed by each page, requires only two steps to implement encapsulation: 1. Determine the positioning method of the elements; 2. Call the corresponding operation interface in driver. Driver’s interface implementation includes certain fault tolerance capability, but it is not comprehensive. Some pages or components are unique. Simply calling driver’s interface cannot ensure the stability of test cases. At this time, it is necessary to add some fault tolerance algorithms to pageObject’s interface implementation to ensure the stability of use cases.
3.1.4 Service-Provides Business Functions
A business process often depends on the functions of other business modules. In order to facilitate the design of a test case and avoid duplication of wheel building, the service layer provides some common business functions, such as login and enterprise query. The relying party only needs to call at the service layer.
3.2. Functional Optimization
The secondary encapsulation of selenium also optimizes the interface. The original intention of the framework is to make the design of UI use cases as easy to design, easy to read and easy to maintain as possible.
3.2.1 Interface Optimization
Interfaces directly calling selenium often encounter some troublesome problems. For example, network problems make the page loading too slow and the elements that need to be operated are not shown yet. This situation will often report the error that cannot be found by the elements, resulting in the failure of use case execution. However, in fact, this error reporting is not a bug and its test result is invalid. In order to reduce the false alarm rate, the driver layer interface has designed the function of waiting for elements to be loaded. the key method used is cf. searchforelementvisiblepath (teststartsuite.wd, “//* [text () =’ operating platform login’ ]”, id, 200, 100L). Reference code:
Adding the judgment of loop search to the operation interfaces such as click and input can wait for the loading of an element to the maximum extent so as to improve the stability of test cases.
3.2.2 element positioning unified entrance
Testers who have come into contact with UI automation use case design will know clearly that they want to operate an element through selenium, of which the essential is the description of the element location. In common terms, it is necessary to inform the interface where to operate the element on the current page. There are many ways to locate an element, commonly used are id, name, css, xpath, etc. selenium also gives different interfaces for different locating methods, which is obviously not the best from the perspective of maintenance. The best approach is that the use case designer only focuses on the element location and the call of operation events, and which channel the events go through in implementation is best without perception and maintenance. This framework encapsulates a method for driver to call, and its main function is to parse the string describing the element and automatically determine whether it is id, css or xpath.
3.3. Element Location
UI automation use cases can be divided into two parts: 1. Locating elements; 2. Call the interface to operate the element. There are many ways to locate an element, including id, name, css, xpath. In actual design, which positioning method to choose will generally be considered more from the maintenance perspective, because the current server performance configuration and so on are excellent, so running a WEB-UI use case does not need to consider performance issues. In terms of maintenance cost, id and name will be preferred, followed by css and xpath.
We cannot guarantee that all elements of every web system can provide a unique id or name. of course, if we can reach cooperation with front-end development, this is a wonderful thing. In general, we all need to face the situation without id and name. At this time, we can use css styles, and most of the time css styles can meet our positioning requirements. Of course, we can only choose xpath and use the advantages of xpath when none of these are provided to us.
- Easy to get, mainstream browsers can easily get it through copy as long as they open “View”.
- All elements on the page can be described by xpath. Disadvantages, instability, and large-scale use will place a great burden on use case maintenance.
In general, xpath needs to be re-maintained as long as the front end makes a small adjustment on the page. In case of having to use xpath, in order to reduce the amount of maintenance in the future, xpath can be optimized to reduce the path length of xpath and improve stability. The following are the types that are most frequently used in practice:
1. locate the attribute text by itself, such as//input [@ value =’ xxxxx’]
2. Contains indicative characters, such as //input[contains(text(),’ indicative characters’)]
3. use content skillfully, such as//* [@ id =’ app-container’]
4. Common error reporting
Problems are often encountered in the use process, so it is convenient for debug to make a summary here.
1. Some page popup windows, sometimes cannot locate popup window elements. Theoretically, selenium can locate an element in a page, but sometimes pop-up windows appear, so it is necessary to relocate the pop-up windows. Resolution:
2. Some input boxes cannot be normally operated by the Input interface. In the process of practice, I met in the calendar control that all the elements are positioned correctly, but they cannot be operated normally. Solution: Determine whether the element is of select type, and then assign a value. Resolution code:
3. It was found that some interfaces of selenium could not work. At this time, the biggest possibility is the browser upgrade. Workaround: Download the lower version browser again.
4. Elements are not visible. There is an element that can be displayed normally on the page, but it is invisible to tools, because under normal circumstances, the visibility of an element needs to meet the following conditions: visibility! =hidden ; display! =none; opacity! =0; Height and width are both greater than 0; For input tags, there is no hidden attribute. For example, screenshots are read-only examples.
Solution: Call Interface
TestStartQuitwd.js.executeScript("var txtN = document.getElementsByName(\"timeRange\"); txtN.readOnly = false;");
5. Concluding remarks
UI automation is optimized on the basis of open source tools. There is still much room for improvement in the driver layer, data layer, business layer and use case layer. WEB-UI automation is not perfect, and further efforts are needed in the later period. Thank you for your support for the research.
Source:Yixin Institute of Technology
Author: Yan Bolian