Selenium-grid How to work

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

Selenium-grid How to workTags: selenium-grid2webdriverselenium22013-07-23 21:55 10815 People read Comments (2) favorite reports Classification:Selenium (+)

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Selenium-grid version

Selenium-grid is divided into version 1 and version 2, in fact its 2 versions are not the same as the Selenium version 1 and 2 should be published [that is, the release of Selenium-grid2 is a little later than selenium2]. Fortunately, however, the current SELENIUM-GRID2 is basically capable of supporting all the functions of selenium2.

Although the Selenium 1 and 2, but in fact the principle and basic working methods are the same. Just version 2 supports both SELENIUM1 and selenium2 two protocols, and is optimized for some small functionality and ease of use. For example: Specify the way to test the platform; The following selenium-grid are generic.

SELENIUM1 Working principle

In addition to using Selenium-core in SELENIUM1, automated testing requires the use of SELENIUM-RC as a proxy [both native and remote] in order to solve the same-origin problem The cause of the same origin problem is because SELENIUM1 is using JavaScript to drive test execution "browsers do not allow JS calls between different domains because of security issues, that is, non-homology is not callable , and the way to work in SELENIUM1 is to inject JS on the host page and execute the test operation by invoking JS, so we design to the homologous problem. " So there are 2 solutions in order to achieve the goal:

1. Using Selenium-core:

Selenium-core is a set of JS libraries, used to drive the browser operation of all the library files are here, the entire SELENIUM1 can be considered the core component is this Selenium-core , and the use of Selenium-core is in the test site program in the source code to the Selenium-core all JS library directly added to the page, so that the normal loading of the page will also be loaded selenium-core down, and is inherently homologous.
2. Using SELENIUM-RC:

RC is an HTTP agent that is injected between the browser and the Web program under test so that all requests and content received by the browser will be sent to the real Web application via RC;RC, and when the response content of the Web program is received, Instead of simply returning the content to the browser client, the content that contains selenium-core is injected into the response content before the response is sent to the browser, so that the browser can be deceived to think that the Selenium1 driver class library is also homologous.

SELENIUM2 Working principle

Selenium2 because of the use of webdriver, this technology is not by JS driver, but directly invoke the browser's original eco-interface driven. So there is no homologous problem, there is no need to use RC to execute the local script "of course, the disadvantage is not all browsers have to provide a good driver support, but JS is all browsers are common." So the local script is executed in selenium2 by invoking the local browser interface directly via the local webdriver driver. Local calls to local code are as follows:

[Java]View PlainCopy 

1. Import org.openqa.selenium.*;
2. Import org.openqa.selenium.firefox.*;
4. Webdriver WD = new Firefoxdriver ();
5. Wd.dosomething ()

But sometimes, and always only execute locally tested scripts, sometimes it may be necessary to invoke the remote environment locally to perform the test, "for example: because the test environment covers the cause" at this point, you need a similar RC in SELENIUM1 to undertake this task, That is the selenium-server in selenium2. Selenium-server supports the call command to receive remote scripts, and then operates the browser on its host to perform the task of testing remotely. Of course selenium-server in order to be compatible with SELENIUM1 scripts, it also supports SELNIUMRC supported features "that can receive SELENIUM1 call commands". The code that calls the remote machine to execute the test locally is this:

[Java]View PlainCopy  

1. Import org.openqa.selenium.*;
2. Import Org.openqa.selenium.remote.RemoteWebDriver;
3. Import org.openqa.selenium.remote.DesiredCapabilities;
5. Desiredcapabilities Iedesiredcap = Desiredcapabilities.internetexplorer ();
6. Webdriver WD = New Remotewebdriver ("Http://localhost:4444/wd/hub", Iedesiredcap);
7. Wd.dosomething ()

But before you run this code, start selenium-server; the Start command is:

[Java]View PlainCopy 

1. Java-jar Selenium-server-standalone-x.xx.x.jar

Call the selenium-server corresponding structure diagram:

Selenium-grid Working principle

To this end, there is no mention of Selenium-grid, because so far we have not been required to cover multiple platforms and browsers at the same time, and Selenium-grid in this case will reflect its role. Selenium-grid is a tool designed to help us with distributed testing, and its entire structure consists of a hub node and several broker nodes. The hub is used to manage registration and status information for each agent node, and to accept request calls from remote client code and then forward the requested command to the broker node for execution. The code to execute the test remotely using Selenium-grid is the same as calling Selenium-server directly [only when the environment starts differently, and you need to start a hub and at least one node]:

[Java]View PlainCopy 

1. Java-jar Selenium-server-standalone-x.xx.x.jar-role Hub
2. Java-jar selenium-server-standalone-x.xx.x.jar-role Node

Above is to start a hub and a node, if the same machine to start more than one node to pay attention to the port allocation problem, you can start multiple node:

[Java]View PlainCopy 

1. Java-jar selenium-server-standalone-x.xx.x.jar-role node-port 5555
2. Java-jar selenium-server-standalone-x.xx.x.jar-role node-port 5556
3. Java-jar selenium-server-standalone-x.xx.x.jar-role node-port 5557

The basic structure of calling Selenium-grid is as follows:

The above is a common way to use Selenium-grid, only using its supported distributed execution function, that is, when you need to test cases more time, you can parallel to execute these use cases to shorten the overall test time; In addition, Selenium-grid supports a more friendly function , you can forward the use case to a test agent that matches the matching requirements based on the type of test that you launch in your use case. For example, if you specify the 3.6 version of FF on Liunux to be tested in your use case, then Selenium-grid automatically matches the proxy node with the FF3.6 that is registered as Linux, and if the match succeeds, forwards the test request and, if it fails, rejects the request. The code for the remote compatibility test using Selenium-grid is the same as above. The basic structure of its invocation is shown below:


Understand the basic structure of selenium-grid, and then look at the principle of selenium-grid communication. Let's say we have a scenario like this: [a test request client, a hub node, a Windows+ie agent, a linux+ff agent, a Mac+safari agent, a chrome proxy under any platform]. The distribution map is as follows:

The code for the test is as follows:

[Java]View PlainCopy  

2. Import org.openqa.selenium.*;
4. Import Org.openqa.selenium.remote.RemoteWebDriver;
6. Import org.openqa.selenium.remote.DesiredCapabilities;
10. test01: Matches only IE in Windows to execute this use case, the version is not limited; Multiple version matching success priority is unknown
12. Desiredcapabilities Adesiredcap = Desiredcapabilities ();
14. Adesiredcap.setbrowsername ("Internet Explorer")
16. Adesiredcap.setversion ("")
18. Adesiredcap.setplatform (Platform.windows)
20. Webdriver WD = new Remotewebdriver<span style="font-family:arial, Helvetica, Sans-serif;" > ("Http://localhost:4444/wd/hub", Adesiredcap);</span>
22. Wd.dosomething ()
26. TEST02: Only the browser that matches the version of Firefox under Linix is 22 to execute the use case;
28. Desiredcapabilities Adesiredcap = desiredcapabilities ("Firefox", "all", platform.linux);
30. Webdriver WD = New Remotewebdriver ("Http://localhost:4444/wd/hub", Adesiredcap);
32. Wd.dosomething ()
36. test03: Only match the Safari browser under Mac execution, version unlimited
38. Desiredcapabilities Adesiredcap = Desiredcapabilities.safari ();
40. Adesiredcap.setplatform (PLATFORM.MAC)
42. Webdriver WD = New Remotewebdriver ("Http://localhost:4444/wd/hub", Adesiredcap);
44. Wd.dosomething ()
48. test04: Match only Chrome browser, any platform, any version
50. Desiredcapabilities Adesiredcap = Desiredcapabilities.chrome ();
52. Adesiredcap.setplatform (Platform.any)
54. Webdriver WD = New Remotewebdriver ("Http://localhost:4444/wd/hub", Adesiredcap);
56. Wd.dosomething ()

So the entire test execution process is probably the case. First, we execute the test code on the test request machine, and the test start mode is remote call;
[Java]View PlainCopy  

1. Webdriver WD = New Remotewebdriver ("Http://localhost:4444/wd/hub", Adesiredcap);

The test script then connects to the hub node based on the startup parameters, where the connection information is [Java]View PlainCopy 

1. http://localhost:4444/wd/hub

After the connection to the hub is successful, a session message is registered on the hub, and the session message will be sent back to the hub to tell the hub that I have been here before and which agent node was previously assigned to perform the test.

When the hub accepts the initialization request, it matches all the agents according to the type of the request and determines whether there are rules-compliant proxies;

If the match fails, the initial request is rejected, and if the match is successful, the corresponding agent node is notified of the corresponding initialization operation, here is the start XX, and record the browser registration session, and finally sent back to the hub side;

After the hub receives the completed session information from the agent, the session is also recorded in the hub and returned to the test request side, [the session will save the matching agent information]

After the initialization request succeeds, the test request side continues to send the next Test command, where the command is:

[Java]View PlainCopy 

1. Wd.dosomething ()

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

When the hub receives the request command with the session, it will query the session information and know the corresponding agent in the session to forward the requested command to the agent;

After receiving the test command sent by the hub, the agent also queries its session information and operates the corresponding browser according to the session information to perform the test.

After the test is completed, the hub execution results are notified, and the hub is forwarded to the test request side to test the return information on the request side to determine the next execution process;

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

By the principle of selenium-grid, we know

It is not necessary to have a test script on the remote machine when performing remote operation through Selenium-grid, but the corresponding Webdriver program must be installed on the remote machine [can be placed directly in the directory of the environment variable], of course, you need to start the agent correctly. [Refer to: How to build Selenium-grid environment]

Top

1

Step

Selenium-grid How to work