I. Design background

With the development of IT industry, products become more and more complex, and the business and process of Web end become more complicated. At present, UI test is only for a single page, and the operation is large. In order to meet the needs of multi-page functions and processes and save time, this UI automatic test program is designed. Designed to provide an interface for integration into the Snail automated testing framework to facilitate use case design.

The whole program is designed based on Selenium. The interface provided by Selenium is re-encapsulated to meet the needs of daily use case design. The re-encapsulated interface solves the problems of element loading, element positioning and analysis, which makes use case design more simple.

The Selenium model was adopted. One, it’s an open source framework for users to look into. Second, Selenium is seamlessly accessible. Selenium2 encapsulates the browser’s native API into WebDriver API, and can directly operate the elements in the browser page, even the browser itself (screenshot, window size, startup, etc.). Shut it down or something), so it’s like a real user is doing it.

Currently supported: Mac, Windows, Chrome, Firefox, and Internet Explorer.

Two, the working principle

  • Add test cases in the snail admin background.
  • Snail management background test case execution call task execution interface, transfer task ID and test data JSON format string to the program.
  • Program according to the data obtained, parsing and processing.
  • After the browser is started, Selenium-WebDriver binds the target browser to a specific port, and the browser that is started acts as the Server for WebDriver.
  • The client (the test script) sends HTTP requests to the server using ComandExecutor (communication protocol: The WebDriver Wire Protocol, in The body of The HTTP Request, tells Selenium what we want The browser to do next, as a JSON-formatted string specified by The WebDriver Wire Protocol.
  • The Server side needs to rely on the native browser components and convert the command of Web Service into the call of the browser native to complete the operation.
  • Finally, the processing results and task ID are returned to the snail in JSON string format, and the results of each use case can be viewed through the snail’s management background.

Iii. Framework introduction

3.1 Engineering Structure

According to the actual business process to invoke the corresponding interface to achieve web-UI automated test cases. Case layer can call the interface of Service layer and pageObject layer, pageObject is a wrapper for each page element, And Service is a wrapper for a common business module function. For example, a test case to query enterprise information relies on login, and the business function can directly invoke the interface in the Service. The creation of an enterprise query invokes the interfaces in pageObject and then, following the business flow of the query, string these interfaces together in a test case to form a UI automated test case, as illustrated in the following examples.

Such as enterprise query. Before query, need to log in the management background, login operation has been encapsulated in the business layer, directly call the interface of the Service layer, do not need to care about the details of this step; Once logged in, specify a path, find the corresponding space, and call the interface of the Model layer directly, regardless of the details of this step; Then it is to create the query, all the positioning methods to create the query are encapsulated in the business layer, which is the implementation of an enterprise query, is the most important link in the use case design.

The whole project is based on Selenium and adopts pageObject mode. Several important modules in the project are introduced below.

3.1.1 Driver – Interface layer

Operations on all elements of a Web page are defined and implemented in the driver. The Driver encapsulates the interfaces provided by Selenium and provides encapsulated interfaces externally. PageObject implements some public methods, such as assigning values to input boxes. Currently, pageObject encapsulates few methods, and most functions can be implemented through Selenium. The driver layer is a secondary encapsulation of the open source tool interface. To drive a browser, there is also an essential tool — the browser driver. This driver is located in Referenced Libraries, and the version of the driver must match the version of the browser under test.

3.1.2 Model — Data model

Creating a data model A method of separating test data from test cases, specifically test data initialization. Elements of a business process that require test data can be defined in a model for easy management and code reading.

3.1.3 pageObject – Business layer

PageObject mode uses interface form to encapsulate the elements needed for each page. There are only two steps to achieve encapsulation:

  • Determine the positioning of elements;
  • Invoke the corresponding operation interface in the driver.

The interface implementation of Driver contains a certain fault-tolerant capability, but it is not comprehensive. Some pages or components are unique, and simply calling the interface of driver cannot guarantee the stability of test cases. In this case, it is necessary to add some fault-tolerant algorithms into the interface implementation of pageObject to ensure the stability of use cases.

3.1.4 service – Provides service functions

A business process often relies on other business module functions. To facilitate the design of a test case and to avoid duplication of wheels, the Service layer provides some common business functions, such as login, enterprise query, and so on. The dependent party only needs to call at the Service layer.

3.2 Function Optimization

The secondary encapsulation of Selenium has also optimized the interface. The original intention of the framework is to make the DESIGN of UI use cases as easy to design, read, and maintain as possible.

3.2.1 Interface Optimization

Interfaces that directly call Selenium often encounter headaches. For example, a network problem causes the page to load too slowly, and the elements that need to be operated on are not displayed. In this case, an error is often reported that the elements cannot be found, causing the use case to fail. The test results are invalid. To reduce false positives, the driver layer interface is designed to wait for elements to load. The key methods used are: Cf. SearchForElementVisibleXpath (TestStartQuitwd. Wd, “/ / * [text () = ‘operating platform login’]”, id, 200, 100 l). Reference code:

Adding circular lookup judgments to action interfaces such as Click and input maximizes waiting for an element to load and improves test case stability.

3.2.2 Unified entry for element positioning

Testers who have worked with UI automation use-case design will know that an essential part of selenium’s ability to manipulate an element is a description of its location, which, in general, tells the interface where to manipulate an element on the current page. There are many ways to locate an element, such as ID, name, CSS, xpath, etc. Selenium also provides different interfaces corresponding to different locating methods, which is obviously not the best from the perspective of maintenance. The best practice is for the use case designer to focus only on element positioning and manipulation of the invocation of events, and which channel the events take in the implementation is best sensorless and maintenance-free. The framework encapsulates a method called by the driver that parses a string describing an element to automatically determine whether it is an ID, CSS, or xpath.

3.3 Element Positioning

UI automation use cases can actually be divided into two parts: positioning elements; Call the interface to manipulate the element. There are many ways to locate an element, including ID, name, CSS, and xpath. In the actual design, which positioning method to choose will generally be considered more in the perspective of maintenance, because the current server performance configuration is very good, so running a Web-UI use case can not consider the performance problem. In terms of maintenance cost, ID and name will be preferred, followed by CSS and xpath.

There is no guarantee that every element of a Web system will provide a unique ID or name, but it would be nice to work with front-end development. In general, we have to deal with the absence of the id and name attributes. At this point we can use CSS styles, many times CSS styles can meet our positioning needs. Of course, in cases where none of this is provided, xpath is the only choice, and the advantages of using xpath are:

  • Easy to obtain, mainstream browsers as long as open “View” can be easily obtained by copy;
  • Elements on a page can be described using xpath; Disadvantages, instability, and heavy use can place a significant burden on use case maintenance.

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

  • Rely on their own attribute text positioning, such as //input[@value= ‘XXXXX’]
  • Contains indicative characters, such as //input[contains(text(), ‘indicative character’)]
  • Clever use of content such as //*[@id= ‘app-container’]

Four, common errors

Problems often occur during use. This section provides a summary to facilitate debugging.

  • Some pages popover, sometimes popover elements cannot be located. Selenium is theoretically possible to locate an element in a page, but sometimes a popover occurs, which requires relocating the popover. Solutions:

  • Some input fields do not operate properly by the input interface. In practice in the calendar control encountered, element positioning and everything is correct, but it is not the normal operation. Solution: Determine if the element is of type SELECT and assign it later. Solution code:

3. It is found that some interfaces of Selenium do not work, which is most likely due to the browser upgrade. Solution: Re-download the earlier version of the browser.

4. The element is not visible. There is an element that appears normally on the page but is not visible to the tool because, in general, an element must be visible under the following conditions: Visibility! =hidden ; display! =none; opacity! = 0; Both height and width are greater than 0; For the input tag, there is no hidden attribute. The screenshot is a read-only instance.

Solution: call interface TestStartQuitwd. Js. ExecuteScript (” var txtN = document. The getElementsByName (” timeRange “); txtN[0].readOnly = false;” );

V. Concluding remarks

UI automation is based on the optimization of open source tools, and there is a lot of room for improvement at the driver, data, business, and use case levels. Web-ui automation is not yet perfect and needs further work in the future. Thank you for supporting the research all the time.

Author: Yan Bolian

Source: Creditease Institute of Technology