Selenium grid principle

Reprinted: http://blog.csdn.net/five3/article/details/9428655

Selenium-grid version

Selenium-grid is divided into version 1 and Version 2, in fact, its two versions are not the opposite of selenium versions 1 and 2 [that is, the release of selenium-grid2 is a little later than selenium2]. Fortunately, the current selenium-grid2 basically supports all the features of selenium2.

Although selenium is divided into 1 and 2, the principle and basic working method are the same. Only version 2 supports both selenium1 and selenium2 protocols, and is optimized for some small functions and ease of use. For example, the test platform method is specified. Selenium-grid, which is not described below, is common.

How selenium1 works

In selenium1, apart from selenium-core, selenium-RC must be used as a proxy for automated testing [both local and remote], in order to solve the same-source problem; the cause of the same-origin issue is that selenium1 uses JavaScript to drive the test execution. [the browser does not allow JS calls between different domains due to security issues, that is, non-same-origin requests cannot be called; in selenium1, JavaScript is injected into the host page and the test operation is executed by calling Js. Therefore, the same source problem is designed ]. Therefore, there are two solutions to achieve the goal:

1. Use selenium-core:

Selenium-core is a set of JS libraries. All the library files used to drive browser operations are here. selenium1 can regard the core component as selenium-core; selenium-core is used to add all JS libraries in selenium-core to the page in the source code of the program to be tested, in this way, when the page is normally loaded, selenium-core will also be loaded, and naturally it will be the same source. 2. Use selenium-RC:

RC is an HTTP Proxy program used to inject data between the browser and the tested web program. In this way, all requests and received content of the browser will pass RC; RC will send the browser request to the real web program, but when receiving the response content of the web program, it does not return the original content to the browser client, instead, the content containing selenium-core is injected into the response content, and then the response content is sent to the browser. In this way, the browser can think that the driver class library of selenium1 is the same source through spoofing.

How selenium2 works

Because of the WebDriver used in selenium2, this technology is not driven by JS, but directly called the browser's original ecological interface driver. So there is no same source problem, so RC is not required to execute local scripts. [Of course, not all browsers provide good driver support, but Javascript is common to all browsers ]. Therefore, the method for executing local scripts in selenium2 is to call the local browser interface through the local WebDriver driver. The local code called locally is as follows:

 

import org.openqa.selenium.*;import org.openqa.selenium.firefox.*;WebDriver wd = new FirefoxDriver();wd.doSomething()

 

 

However, sometimes you only execute the local test script, and sometimes you may need to call a remote environment locally to execute the test. For example: test Environment coverage: A rc similar to selenium1 is required to perform this task, that is, selenium-server in selenium2. Selenium-server supports Receiving call commands from remote scripts, and then operating the browser on its host machine to remotely execute the test task. Of course, in order to be compatible with the selenium1 script, selenium-server also supports the functions supported by selniumrc [that is, it can receive the call command of selenium1 ]. The code for locally calling a remote machine to execute the test is as follows:

 

import org.openqa.selenium.*;import org.openqa.selenium.remote.RemoteWebDriver;import org.openqa.selenium.remote.DesiredCapabilities;DesiredCapabilities ieDesiredcap = DesiredCapabilities.internetExplorer();WebDriver wd = new RemoteDriver("http://localhost:4444/wd/hub", ieDesiredcap);wd.doSomething()

 

However, before running this code, start selenium-server. The startup command is:

 

java -jar selenium-server-standalone-x.xx.x.jar

 

Call the structure chart corresponding to selenium-Server:

How selenium-grid works

Selenium-grid has not been mentioned so far, because so far we have no need to cover multiple platforms and browsers at the same time, in this case, selenium-grid will reflect its role. Selenium-grid is a tool designed to help us conduct distributed tests. Its entire structure is composed of a hub node and Several proxy nodes. The Hub is used to manage the registration and status information of each proxy node, and receives the call request from the remote client code, and then forwards the request command to the proxy node for execution. The code for Using selenium-grid to remotely execute the test is the same as that for directly calling selenium-server [only the environment startup method is different. You need to start one hub and at least one node at the same time]:

 

java -jar selenium-server-standalone-x.xx.x.jar -role hubjava -jar selenium-server-standalone-x.xx.x.jar -role node

The above is to start a hub and a node. If multiple nodes are to be started on the same machine, pay attention to the port allocation problem. You can start multiple nodes as follows:

 

java -jar selenium-server-standalone-x.xx.x.jar -role node -port 5555java -jar selenium-server-standalone-x.xx.x.jar -role node -port 5556java -jar selenium-server-standalone-x.xx.x.jar -role node -port 5557

 

The basic structure of the call to selenium-grid is as follows: The above is a common method using selenium-grid and only uses the distributed execution function supported by selenium-grid, that is, when you need many test cases at the same time, you can execute these cases in parallel to shorten the total test time. In addition, selenium-grid also supports a more friendly function, that is, you can forward the test case to the testing agent that meets the matching requirements based on the type of the test started in your case. For example, if you specify version 3.6 of liunux to be tested, selenium-grid will automatically match the proxy node with the registration information of Linux and installed with ff3.6, if the match succeeds, the test request is forwarded. If the match fails, the request is rejected. The code for the remote Compatibility Test Using selenium-grid is the same as above. The basic structure of its call is as follows:
After learning about the basic structure of selenium-grid, let's take a look at the principles of selenium-grid communication. Assume that we have the following scenario: [One test request client, one hub node, One Windows + IE proxy, one Linux + FF proxy, One Mac + safari proxy, and one chrome proxy on any platform]. The distribution chart is as follows:

The test code is as follows:

 

Import Org. openqa. selenium. *; import Org. openqa. selenium. remote. remotewebdriver; import Org. openqa. selenium. remote. desiredcapabilities; // test01: This test case is executed only by matching IE in Windows. The version is not limited. If multiple versions match successfully, the priority is unknown. desiredcapabilities (); adesiredcap. setbrowsername ("Internet Explorer") adesiredcap. setversion ("") adesiredcap. setplatform (platform. windows) WebDriver WD = new remotedriver ("http: // localhost: 4444/WD/hub", adesiredcap); WD. dosomething () // test02: Only applicable to browsers whose firefox version is 22 in linix. desiredcapabilities adesiredcap = desiredcapabilities ("Firefox", "22", platform. linux); WebDriver WD = new remotedriver ("http: // localhost: 4444/WD/hub", adesiredcap); WD. dosomething () // test03: only matches the Safari browser on the Mac. The version is not limited to desiredcapabilities adesiredcap = desiredcapabilities. safari (); adesiredcap. setplatform (platform. mac) WebDriver WD = new remotedriver ("http: // localhost: 4444/WD/hub", adesiredcap); WD. dosomething () // test04: only matches the Chrome browser, any platform, any version of desiredcapabilities adesiredcap = desiredcapabilities. chrome (); adesiredcap. setplatform (platform. any) WebDriver WD = new remotedriver ("http: // localhost: 4444/WD/hub", adesiredcap); WD. dosomething ()

 

The entire test execution process is like this. First, run the test code on the test request machine. In the code, the test start method is remote call;

 

WebDriver wd = new RemoteDriver("http://localhost:4444/wd/hub", aDesiredcap);

In this case, the test script connects to the Hub node according to the startup parameters. The connection information here is

 

http://localhost:4444/wd/hub

After the connection to the hub is successful, a session information will be registered on the hub. [This session information will be included in the subsequent communication with the hub, telling the hub that I have been there before, which proxy node has been assigned for testing?]

When receiving the initialization request, the hub matches all the proxies based on the request type and determines whether there are any proxies that comply with the rules;

If the match fails, the initial request is rejected. If the match succeeds, the corresponding proxy node is notified to perform the initialization operation. Here, XX is started and the browser registration session is recorded, finally, send it back to the Hub;

After receiving the complete session information initiated by the proxy, the hub must record the session and return it to the test requester. [The session will save the matched Proxy Information]

After the initialization request is successful, the test requester will continue to send the following test command:

 

wd.doSomething()

 

This command will also be sent to the hub, with session information;

When the hub receives a request command with a session, It queries the session information. After knowing the corresponding proxy in the session, it forwards the request command to the proxy;

After receiving the test Command sent by the hub, the agent queries the session information and operates the corresponding Browser Based on the session information to perform the test;

After the test is completed, the hub will be notified of the execution result, and the hub will then send it to the test request end. The test request end determines the next execution process based on the returned information;

After the test, notify the hub to close the browser process and clear the corresponding session information.

The principles of selenium-grid are available.

When performing remote operations through selenium-grid, there is no need for a test script on the remote machine; however, the corresponding WebDriver program must be installed on the remote machine [You can directly put it in the environment variable Directory]. Of course, you must correctly start the agent program.

Selenium grid principle