Shulou(Shulou.com)06/01 Report--

I. Design Background

With the development of IT industry, products are becoming more and more complex, web-side business and processes are more complicated, and UI testing is only for a single page at present, with a large amount of operation. In order to meet the requirements of multi-page functionality and flow and save time, this UI automation test program was designed. Designed to provide interfaces that integrate into the snail automation test framework to facilitate use case design.

The whole program is based on selenium. The program encapsulates the interface provided by selenium twice to meet the daily use case design. The interface after secondary encapsulation solves the problems of element loading, element positioning and analysis, which can make the use case design more simple.

The Selenium model is used. One reason is that this is an open source framework for users, and they want to pry one or two; the second reason is that Selenium can be seamlessly accessed. This is a tool for Web application testing, support multi-platform, multi-browser, multi-language to achieve automated testing, Selenium2 native browser API package into WebDriver API, you can directly operate the browser page elements, and even operate the browser itself (screenshot, window size, start, close, etc.), so it is like a real user in the operation.

Currently supported: Mac, Windows operating system, chrome, Firefox, IE browser.

Second, the working principle in the snail management background to add test cases. Snail management background test case execution calls the task execution interface, transmitting 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 webdriver server. The client (that is, the test script) sends an HTTP request to the server side via ComandExecutor (communication protocol: The WebDriver Wire Protocol, in the body of the HTTP request, will tell Selenium in the JSON format string specified by the WebDriver Wire protocol, what we want the browser to do next). The Server side needs to rely on native browser components to convert Web Service commands into browser native calls to complete the operation. Finally, the processing result and task ID are returned to the snail in the format of JSON string, and the execution result of each case can be viewed through the snail management background. III. Introduction to framework 3.1 Engineering structure

According to the actual business process call corresponding interface to implement WEB-UI automation test cases. The case layer can call the interfaces of the service layer and pageObject layer. PageObject is an encapsulation of each page element, and service is an encapsulation of a common business module function. For example, a test case for querying enterprise information needs to rely on login, and this business function can directly call the interface in service. The creation of enterprise query can call the interface in pageObject, and then string these interfaces in the test case according to the business process of query to form a UI automation test case. The details will be illustrated later.

Such as business inquiries. Before querying, you need to log in to the management background. The login operation has been encapsulated to the business layer, and the interface of the service layer is directly called. You don't need to care about the details of this step. After logging in, you need to specify a path, find the corresponding space, and directly call the interface of the model layer. You don't need to care about the details of this step. Then you create a query. All the positioning methods for creating a query are also encapsulated to the business layer. This is the implementation of an enterprise query, and it is also the most important link in use case design.

The whole project is based on selenium and 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 the driver interface. The driver encapsulates the interface provided by selenium twice, and provides the encapsulated interface to the outside world. pageObject implements some common methods, such as assigning values to input boxes. At present, there are not many methods encapsulated by pageObject, and most functions can be implemented through selenium. The driver layer encapsulates the open source tool interface twice. If you want to drive a browser, there is also an essential tool-browser driver. This driver is placed in Referenced Libraries. The version of the driver must match the version of the browser under test.

3.1.2 Model -Data model

A method of creating a data model to separate test data from test cases. Specific test data initialization. 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, using the interface form to encapsulate the elements needed for each page, as long as two steps to achieve encapsulation:

Determine how elements are positioned; invoke the corresponding operation interface in the driver.

The interface implementation of driver includes some fault tolerance capability, but it is not comprehensive. Some pages or components are unique. Simply calling the interface of driver cannot guarantee the stability of test cases. In this case, some fault tolerance algorithms need to be added to the interface implementation of pageObject to ensure the stability of test cases.

3.1.4 service -providing service 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. Dependants only need to call at the service level.

3.2 function optimization

Selenium is repackaged and interfaces are optimized. The framework is intended to make UI use case designs as easy to design, read, and maintain as possible.

3.2.1 Interface optimization

The interface that directly calls selenium often encounters some headaches, such as network problems that make the page loading too slow, and the elements that need to be operated have not been displayed. In this case, errors that cannot be found are often reported, resulting in failure of the use case execution. However, this error is not a bug, and the test result is invalid. In order to reduce the false positive rate, the driver layer interface is designed to wait for the element to load. The key method used is cf. searchForementVisibleXpath (TestStartQuitwd.wd, "//*[text()='Operation Platform Login']", id, 200, 100L). Reference Code:

Adding loop search judgment to click, input and other operation interfaces can wait for the loading of an element to the maximum extent, thus improving the stability of test cases.

3.2.2 Element positioning unified entry

Testers who have been exposed to UI automation use case design will be clear that if you want to operate an element through selenium, the essential thing is to describe the element positioning, which is 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., corresponding to different positioning methods selenium also gives different interfaces in processing, which is obviously not the best from the maintenance point of view. The best practice is for use case designers to focus on element location and manipulation of event invocation, and which channel the event takes in implementation is preferably insensitive and maintenance-free. This framework encapsulates a method for driver to call, the main function is to parse the string describing the element and automatically determine whether it is id, css or xpath.

3.3 element positioning

UI automation use cases can actually be divided into two parts: locating the element; and invoking the interface to manipulate the element. There are many ways to locate an element, such as id, name, css, xpath. Which positioning method is selected in the actual design will generally be considered more from the maintenance point of view, because the current server performance configuration is very good, so running a WEB-UI use case can not consider performance issues. In terms of maintenance costs, id, name, css, and xpath are preferred.

We can't guarantee that every element of a web system will have a unique id or name, but it would be nice to work with front-end developers. In general, we need to deal with cases where there are no id and name attributes. At this point we can use css style, a lot of times css style is able to meet our positioning needs. Of course, in the case that none of these are provided to us, we can only choose xpath. Advantages of using xpath:

Easy to get, mainstream browsers can easily get through copy as long as they open "View"; elements on the page can be described by xpath; disadvantages, unstable, heavy use will cause a great burden on use case maintenance.

xpath generally requires a small adjustment on the page by the front end, and the use case must be re-maintained. In the case where xpath has to be used, in order to reduce the amount of maintenance in the future, some optimization can be made to xpath, and the path length of xpath can be reduced to improve stability. Here are some of the most commonly used types in practice:

Rely on its own attribute text positioning, such as//input[@value ='XXXX '] contains indicative characters, such as//input[contains(text(),' indicative characters')] clever use of content, such as//*[@id ='app-container']

Problems are often encountered during use. Here is a summary for debugging.

Some pages pop-up, sometimes not located pop-up elements. Theoretically, selenium can locate an element in a page, but sometimes pop-ups appear, and you need to reposition pop-ups. Solution:

Some input boxes cannot be properly operated by the input interface. In practice, I have encountered in calendar control, element positioning is correct, but it cannot be operated normally. Solution: Determine if the element is of type select, and then assign the value. Resolution Code:

3. It is found that some interfaces of selenium cannot work. At this time, the biggest possibility is that the browser has been upgraded. Workaround: Redownload the older version of the browser.

4. Elements are invisible. There is an element that can be displayed normally on the page, but it is invisible to tools, because in general, the element visibility needs to meet the following conditions: visibility!= hidden ; display!= none; opacity!= 0; height, width are both greater than 0; for input tags, there is no hidden attribute. For example, screenshots are read-only instances.

Solution: Call the interface TestStartQuitwd.js.executeScript("var txtN = document.getElementsByName("timeRange"); txtN[0].readOnly = false;");

V. Concluding remarks

UI automation is optimized on the basis of open source tools, and there is still a lot of room for improvement in driver layer, data layer, business layer and use case layer solutions. WEB-UI automation is not perfect, and efforts need to be continued in the later stage. Thank you for supporting my research partners.

Author: Yan Bolian

Source: Yixin Institute of Technology

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.