How to optimize the execution speed of selenium webdriver

Table of contents

foreword

Asserting text in page_source is faster than asserting directly with the text attribute

The more specific the element, the faster it will get the text

Use variables to cache elements that don't change

Quickly enter large text in a text box

Use dynamic wait for dynamic/AJAX operations instead of fixed sleep

at last


foreword

Making automated test scripts work properly is only the first step in automated testing. Since automated scripts are frequently executed and updated, test scripts need

  • can be executed quickly
  • easy to maintain
  • easy to read

This article will provide some tips to make selenium automation scripts run faster.

  Python automated testing learning exchange group: a full set of automated testing interview resume learning materials to obtain Click the link to join the group chat [python automated testing exchange]: http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=DhOSZDNS -qzT5QKbFQMsfJ7DsrFfKpOF&authKey=eBt%2BF%2FBK81lVLcsLKaFqnvDAVA8IdNsGC7J0YV73w8V%2FJpdbby66r7vJ1rsPIifg&noverify=0&group_code=198408628

Asserting text in page_source is faster than asserting directly with the text attribute

We often need to assert that a certain part of the page contains some specific text, the output of the following statement is the same

driver.page_source 
driver.find_element(:tag_name => ‘body') .

However, for the second statement, selenium needs to analyze the structure of the page, and finally find the corresponding element and enter the result, which obviously takes time. If the page is relatively small, the difference between the two may not be large, but for large pages, the speed of the first statement is obviously faster.

When using page text:

expect(driver.find_element(:tag_name => "body").text).to include("platform- and language-neutral wire protocol")

When using page source:

expect(driver.page_source).to include("platform- and language-neutral wire protocol")

Let's take a look at the difference:

Method 1: Search whole document text took 0.823076 seconds 
Method 2: Search whole document HTML took 0.039573 seconds

Of course, the usage scenarios of the two are not the same, but we only focus on performance here, obviously the page source is faster.

The more specific the element, the faster it will get the text

As a rule of thumb, we can save execution time by narrowing down to more specific Web controls. The two assert statements below achieve largely the same functionality, but differ significantly in execution time.

expect(driver.find_element(:tag_name, “body”).text).to include(“language-neutral wire”)

The execution time of this statement is 0.93s

expect(driver.find_element(:id, “abstract”).text).to include(“language-neutral wire”)

This assertion only executes for 0.02s

Obviously, in addition to being faster in execution speed, the second assertion is also more precise and easier to understand.

  Python automated testing learning exchange group: a full set of automated testing interview resume learning materials to obtain Click the link to join the group chat [python automated testing exchange]: http://qm.qq.com/cgi-bin/qm/qr?_wv=1027&k=DhOSZDNS -qzT5QKbFQMsfJ7DsrFfKpOF&authKey=eBt%2BF%2FBK81lVLcsLKaFqnvDAVA8IdNsGC7J0YV73w8V%2FJpdbby66r7vJ1rsPIifg&noverify=0&group_code=198408628

 

Use variables to cache elements that don't change

I often see people write tests like the following to check multiple texts on a page.

driver.navigate.to(site_url + "/WebDriverStandard.html") expect(driver.find_element(:tag_name, "body").text).to include("Firefox") 
expect(driver.find_element(:tag_name, "body") ").text).to include("chrome") 
expect(driver.find_element(:tag_name, "body").text).to include("W3C")

Execution time 2.35s

The above three test statements are very inefficient, because each test statement calls driver.find_element(:tag_name, 'body').text, which can be time-consuming and laborious work when the web page is large.

Solution : Use a variable to store the text of the web page, which is a very common practice in programming.

the_page_text = driver.find_element(:tag_name, “body”).text expect(the_page_text).to include("Firefox") 
expect(the_page_text).to include("chrome") 
expect(the_page_text).to include("W3C" )

Execution speed 0.86s

No matter how many assertions (against the page text) we execute on that page, as long as the page text we're checking hasn't changed, we get constant execution time.

Quickly enter large text in a text box

We usually use send_keys to enter text in the text box. When you find that the text string to enter is large, such as thousands of characters, try to avoid using send_keys because it is not efficient. Below is an example:

long_str = “START” + ‘0’ * 1024 * 5 + “END” # just over 5K 
text_area_elem = driver.find_element(:id, “comments”) 
text_area_elem.send_keys(long_str)

Execution time 3.8s

In fact, the solution is very simple, use js to do it

driver.execute_script(“document.getElementById('comments').value = arguments[0];”, long_str)

Execution time 0.2s

Use dynamic wait for dynamic/AJAX operations instead of fixed sleep

For some pages that are separated from the front and back ends, since the page will not be refreshed between operations, we cannot rely on the page refresh waiting mechanism that comes with selenium, so we often need to wait for an element to appear or disappear. The following code demonstrates this process.

driver.find_element(:xpath,"//input[ @value ='Pay now']").click 
sleep 10 # seconds 
expect(driver.find_element(:id, "bn").text).to include("RN #")

In this way, no matter how smooth the page is, the above code needs to be executed for at least 10s. For one use case, 10s is acceptable, but if there is a fixed waiting time in most use cases, the entire test execution process will be very slow.

The solution is to use dynamic wait.

wait = Selenium::WebDriver::Wait.new(:timeout => 10) # seconds 
wait.until{ driver.find_element(:id, "bn").text.include?("RN#") }

at last

If the use cases are executed serially one after another, there is an upper limit to the space for optimizing the execution speed. A better solution is to execute multiple groups of use cases together, with more execution machines, and convert the serial into parallel. Such an optimization effect will be more obvious. In short, the time is too long, just find a way to stack machines.

Thanks to everyone who read my article carefully! ! !

I personally sorted out some technical materials I have compiled in my software testing career in the past few years, including: e-books, resume modules, various job templates, interview books, self-study projects, etc. Welcome everyone to click on the business card below to get it for free, don't miss it.

Guess you like

Origin blog.csdn.net/MXB_1220/article/details/131156933