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

This article introduces 7 things that you must know when using Selenium test. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Selenium is an open source toolset for automated testing of browsers for end-to-end testing of Web applications. Selenium mainly includes two tools: one is Selenium IDE, which is a plug-in running on Firefox, which can record and play back the user's behavior, and can also generate code for the recorded content and run on Selenium Remote Control. The second is the focus of this article, Selenium WebDriver (WebDriver for short), which is an open source project that allows users to write interoperable code that runs on a variety of mainstream browsers. Class libraries that support languages such as C # and Java have been launched. The W3C WebDriver specification is also developed on the basis of this open source project.

WebDriver is the most powerful tool for QA engineers to conduct UI testing. It provides rich API to access DOM, run JavaScript, simulate keyboard input, and so on. Programming with WebDriver can realize the full automation of UI testing, which provides great convenience for regression testing and even continuous integration process. However, writing tests in WebDriver takes a lot of time, and because of the diversity of browser behavior and the variability of UI, a lot of code maintenance work is required. Like the application code, writing test code also needs to follow good code specification and design. Poor code structure will quickly make the maintenance of test code become a bottomless pit, and finally be abandoned by the team helplessly.

At this year's OpenWest 2015 conference, Jared Yarn from Lucidchart gave a speech on Selenium WebDriver testing and then wrote an article to summarize the content of the speech. He first talked about the difficulties his team encountered when using WebDriver, when they maintained more than 300 test cases written by about 40 different developers (the team did not have full-time testers, and all the test code was written by developers) and produced about 70 errors per day, which did not improve much after the allocation of dedicated maintenance staff. To thoroughly improve the reliability, scalability, and maintainability of the test suite, Yarn refactored the entire test code structure with the entire team. After refactoring, the failure rate of miscalculation is reduced to less than 1%, and the time to write tests is greatly reduced.

Yarn attributes the success of this refactoring to the following seven points.

Create an Application User object

The first problem the team has to solve is that it takes too much effort to write tests, and to overcome this, they have designed some entity objects. The first thing to create is an Application User object that represents the back-end function of the website and provides the ability to prepare test scenarios or teardown before the test is completed through some auxiliary methods. The following is an example of using such an object:

Class EditorPerformanceTest extends LucidSpec {val user = new ChartUser override def beforeAll () {user.login () user.createDocument ()}... Override def afterAll () {user.finished ()}

Through the application of this object, all the preparatory work is simplified to two method calls (login and createDocument), while the logic in teardown is implemented by the finished method, so developers can focus on specific testing logic and focus on bug fixes or feature detection.

Create an Application Driver object

WebDriver's API is so rich that there are no fewer than 20 ways to locate a UI element alone, and this huge flexibility is daunting. There are countless ways to drag and drop, click, scroll, and enter. To simplify this, Yarn's team designed an Application Driver class to simplify some of the most common operations. It first inherits from the WebDriver class, references the Actions class in Selenium, and then adds methods to implement the most common user actions, such as clicking elements and executing scripts, and so on. The design of this class can be summarized in the following UML diagram.

The method of use is as follows:

Def dragAndDrop (cssFrom: String, cssTo: String) {val elem1 = getElementByCss (cssFrom) val elem2 = getElementByCss (cssTo) actions.dragAndDrop (elem1, elem2)} def contextClickByCss (css: String) actions.contextClick (getElementByCss (css))} access DOM objects through ID

During WebDriver testing, how to locate an DOM element is one of the most challenging tasks. Common methods include XPath, CSS paths, and various complex CSS selectors (similar to jQuery), but these methods fail after the element has moved or the CSS class name has been changed, and the code has to be modified. Therefore, Yarn recommends using the ID of the DOM element for positioning, which has the advantage of being independent of the location of the element and the style applied. Yarn's team then made UI changes to an important feature of the product, and because the ID on the page remained the same, the test code changed very little.

Page object mode

The page object pattern (Page Object Pattern), which is a key factor in testing code maintainability, is very simple in itself, indicating that each page should know how to perform all the actions in the page. For example, the login page knows how to submit the user's authentication information, how to click the "forgot password link" and so on. If you move these functions to a common place, you can reuse this part of the functionality in all tests. The following code represents the functionality of a document page:

Object DocsList extends RetryHelper with MainMenu with Page {val actionsPanel = new ActionsPanel val fileBrowser = new FileBrowser val fileTree = new FileTreeval sharingPanel = new SharingPanel val invitationPanel = new InvitationPanel

There are so many operations on this page that Yarn breaks it down into smaller classes, each of which represents the functionality of a block on the page. They each contain methods for actions that can be performed in this area, as shown in the following code:

Def clickCreateDocument (implicit user: LucidUser) {doWithRetry () {user.clickElement ("new-document-button")} def selectDocument (fileNum: Int=0) (implicit user: LucidUser) {doWithRetry () {user.driver.getElements (docIconCss) (fileNum). Click ()}} def numberOfDocsEquals (numberOfDocs: Int) (implicit user: LucidUser): Boolean = {predicateWithRetry (WebUser.longWaitTime * 5, WebUser.waitTime) {numberOfDocuments = = numberOfDocs}} behavior retry

The worst problem in WebDriver testing is misjudgment, which makes it difficult to automate the build process. For Yarn's team, this problem is also the number one enemy they face. In order to overcome this, they added the function of retry to the test, which greatly improved the test results. Here is the code for this retry method:

/ * Try and take an action until it returns a value or we timeout * @ param maxWaitMillis the maximum amount of time to keep trying for in milliseconds * @ param pollIntervalMillis the amount of time to wait between retries in milliseconds * @ param callback a function that gets a value * @ tparam A the type of the callback * @ return whatever the callback returns, or throws an exception * / @ annotation.tailrec private def retry [A] (maxWaitMillis: Long PollIntervalMillis: Long (callback: = > A): a = {val start = System.currentTimeMillis Try {callback} match {case Success (value) = > value case Failure (thrown) = > {val timeForTest = System.currentTimeMillis-start val maxTimeToSleep = Math.min (maxWaitMillis-pollIntervalMillis, pollIntervalMillis) val timeLeftToSleep = maxTimeToSleep-timeForTest if (maxTimeToSleep 0) {Thread.sleep (timeLeftToSleep)} retry (maxWaitMillis-pollIntervalMillis, pollIntervalMillis) (callback)}

The function of this code is to execute the actual behavior passed in through a simple recursive algorithm until the behavior succeeds or the run times out. The following is a simple example of using this method:

Def numberOfChildren (implicit user: LucidUser): Int = {getWithRetry () {user.driver.getCssElement (visibleCss). Children.size}} Test set retry

The final improvement made by Yarn's team is to retry the configuration test suite, which caches failed tests and rerun those failed tests. As long as there is a success in a subsequent retry, the test will be considered passed. Otherwise, you will continue to retry until the maximum number of retries is reached. Yarn's approach is to try to distinguish between behaviors that rely on third-party functionality, and it seems pointless to write very robust code for the integration of these features, so you can put them in a retryable test set. For them, the purpose of retry is not to fix problems in the test code, but to eliminate the impact of misjudgment in the test report.

Create fun

The development of Selenium can easily be exhausting, and many tests fail for no reason. Getting these tests to get the right results is tedious work, and repetitive boilerplate code is uninteresting. The work became interesting after Yarn's team built a reliable, maintainable, and scalable framework. A variety of interesting ideas emerge one after another. One developer realized the function of drawing canvas screenshots and uploading them to the Amazon S3 service, and then added a screenshot comparison tool to achieve image comparison testing. Other impressive tests include integration with single sign-on features such as Google Drive, Yahoo and Google. The whole testing work began to become lively, which gave a great impetus for the team to achieve the goal of refactoring.

On the use of Selenium testing need to know which 7 things are shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.