Select Page

Browser Testing
with Device Cloud Proxy

Using Java and Selenium

Intro

With the Device Cloud Proxy we wanted to simplify the usage for Browser tests compared to using the Device Cloud API where adding some VM management and new dependency to the test code would have been needed.
While the Device Cloud API provides a lot of control over the setup and usage of VMs , many tests only need to utilize the browser.

By abstracting all VM management logic behind the widely known and used Selenium RemoteWebDriver API we are able to …

  • reduce the amount of necessary code changes to existing tests
  • remove the requirement to integrate the Device Cloud API library into your project
  • test on Device Cloud with all programming languages and frameworks supporting Selenium WebDriver.

    In case you are using an HTTP proxy to access the Internet, see also Using HTTP proxies

  • Setup Comparison

    Local Selenium Grid

    Imagine a local setup of Selenium with WebDriver running on localhost. The default port is 4444. In this scenario the communication between your test and the browser is only to the Selenium WebDriver itself. All commands go “through” the hub. This communication is done completely over HTTP.

    Device Cloud Selenium

    To remote control the cloud via Selenium it is necessary to hook our “Selenium-Proxy” in between. With this the WebDriver request a new environment is started explicitly. As in a local environment a hub is started (only one) and a machine for the browser test. This is “your” hub and it is not shared with other users.

    Before the Test

    Prerequisites

    1. You must have JDK 1.8 or higher installed.

    2. You need to download your Device Cloud certificate and have the corresponding password at hand.

    3. You need to have the latest version of the Device Cloud Selenium Proxy:
    Download tech-selenium-1.0.2-jar-with-dependencies.jar from our Artifactory

    Current versions of the Device Cloud Selenium Proxy use Selenium 3. If you want to use Selenium 2, you need to use proxy versions before 1.0.0, they use Selenium 2 by default.

    Certificates

    SSL client certificates are used to authenticate to Device Cloud. You need them to be able to execute automated tests.

    View all certificates

    Certificates can be accessed by the upper right menu in section “Device Cloud Settings – Certificates”.

    Nest_Device_Cloud_Certificates

    Create Certificate

    Only accounts with role “Company Admins” can create certificates!

    1. Click the button “Generate new certificate”
    2. You will be provided with

  • Certificate name
  • Validity date
  • Password
  • Token
  • File to download
  • nest_device_cloud_certificates_view

    Upon creation you will see that you will receive a password, we need this for later. Download the file and store this .jks file within your root project folder.

    Key

    Learn how to create a keystore file that manages your Device Cloud certificate.
    The first thing happening before any automated test run is a validity check of the provided SSL key. This key identifies each user and verifies that they are allowed to access the Device Cloud. The keystore file needs to contain the path to the SSL certificate and its corresponding password, both have to be specified inside this .ini-file. Therefore, open your favorite notepad editor. Fill in the keystore path (full name of your .jks file which you just downloaded) and password that you obtained from the Device Cloud Certificates page. Afterwards save the file to “example.ini” and also store this within your root project folder.

    See below example:

    [SSL]
    ; always set a proper keystore and password
    keystorePath=./someKey.jks
    keystorePassword=password

    During the Test

    Start the Device Cloud Selenium Proxy

    Now use the command line to navigate to the directory where you put the Selenium Proxy and configuration file into, and start the proxy using the following command:

    java -jar tech-selenium.jar tech_config.ini

    The Selenium Proxy should now be up and running. The proxy triggers the start-up of the so-called Hub machine in the Device Cloud. The Hub serves as communication endpoint for the proxy, you can see it in the running environments overview when you log in to the Nest:

    Nest_Device_Cloud_running_test_environments

    You cannot modify or shutdown the Hub manually, it is created and managed by the Selenium Proxy. Nevertheless you can use the proxy for debugging and logging purposes later.

    Integrate Device Cloud into Your Tests

    In general the Device Cloud Selenium Proxy behaves similar to an ordinary local Selenium server (no surprise since it is bundled in there). To run your tests in the Testbirds Device Cloud you just need to make sure that they are executed via Device Cloud Selenium Proxy. Usually you do that just be referencing it in your test case.

    Example: Selenium Test with JUnit

    import java.net.MalformedURLException;
    import java.net.URL;

    import org.junit.AfterClass;
    import org.junit.Assert;
    import org.junit.BeforeClass;
    import org.junit.Test;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.remote.DesiredCapabilities;
    import org.openqa.selenium.remote.RemoteWebDriver;

    public class SeleniumExample {
    private static WebDriver driver;

    @BeforeClass
    public static void beforeTest() throws MalformedURLException {
    DesiredCapabilities capabilities = DesiredCapabilities.firefox();
    driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), capabilities);
    }

    @Test
    public void testGoogle() {
    driver.get("http://www.google.com/");
    Assert.assertEquals(driver.getTitle(), "Google");
    }

    @AfterClass
    public static void afterTest() {
    driver.close();
    }
    }

    With Device Cloud Selenium Proxy you can configure the browser and operating system of the Virtual Machine (VM) your test is running on, you just have to set the respective proprietary capabilities.

    Configure capabilities and matching

    In an ordinary Selenium grid as well as in the Device Cloud, WebDrivers can be requested by specifying so-called DesiredCapabilities. By doing so, it is possible to define the system that should be used to execute your automated tests in any desired accuracy. The Device Cloud supports special proprietary and default Selenium capabilities.
    Please refer to our examples here:

    Support of Device Cloud Capabilities

    The Device Cloud specific capabilities can be used in addition to normal Selenium capabilities. The default Selenium capability browserName has, in contrast, to be set each time, it is mandatory for any test run.

    os capabilities

    tech_os:'{"family":"WIN", "version":"6.1 SP1", "arch":"X86"}'

    software capabilities

    tech_software: '[{"name":"firefox","version":"46","arch":""}]'
    tech_software: '[{"name":"internet-explorer","version":"11.0"},{"name":"adobe-flash-ie","version":"14.0"}]'

    Using iOS

    If you want to test on iOS you need to specify the tech os and set the Browser name to “Safari”. For example:

    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setBrowserName(MobileBrowserType.SAFARI);
    capabilities.setPlatform(Platform.MAC);
    capabilities.setCapability("tech_os", "{\"family\":\"IOS\", \"version\":\"10.1\", \"arch\":\"X86\"}");
    WebDriver driver = new RemoteWebDriver(capabilities);

    Support of Selenium Default Capabilities

    Java Selenium

    capas = DesiredCapabilities.firefox();
    capas.setVersion("46.0");
    tests.add(capas);

    A full list of the Selenium Default capabilities can be found here: W3.org Webdriver Capabilities

    Advanced capability usage

    With the Device Cloud proxy it is possible to define capabilities language independently.

    OS

    Specifies the operating system that should be installed.


    setCapability("tech_os", "{\"family\":\"\", \"version\":\"\", \"arch\":\"\"}");

    Software

    Specifies the software that should be installed.


    setCapability("tech_software", "[{\"name\":\"\", \"version\":\"\", \"arch\":\"\"},...]");

    tech_uuid

    Specifies the unique id of a VM. This is used to run a test on a VM that has already been started.

    setCapability("tech_uuid", uuid);

    tech_templates

    Templates represent a set of properties like the UI of a certain device.

    setCapability("tech_templates", "[\"

    Quick-Navigation

    Browser Testing

    Here you can find all infos related to Browser Testing in our Device Cloud.

    App Testing

    Here you can find all infos related to App Testing in our Device Cloud.

    Quicklinks:

    Using HTTP Proxies

    Known issues with automated test cases

    Generally we do not recommend running automated testcases through an HTTP proxy, as it increases the complexity of your test setup and it is often required to expose access credentials to build jobs for the proxy configuration.

    If your automated testcase needs to connect to Device Cloud through a proxy server, the Java runtime needs to be configured with the proxy settings, as described in this document in Section 2 (System properties). Our API also handles HTTP basic authentication with proxies using the properties http.proxyUser and https.proxyUser for the username and http.proxyPassword and https.proxyPassword for the password.

    Additionally, the following restrictions apply to the latest versions of the Device Cloud API and the Device Cloud Selenium Proxy:

    The API connection to TestChameleon™ does not yet support proxies. controller.testchameleon.com:443 must be available directly or provided in the local network. In case it needs to be provided on another IP and port using some kind of forwarding, the following extension to the ini file can help:

    Changing API connection to controller
    [Controller]
    host=10.0.0.1
    port=8080

    This would require the local IP 10.0.0.1 to provide port 8080 which directly forwards the TCP connection to controller.testchameleon.com:443.

    We are planning improved and automated proxy support for a future API release.

    Test Automation

    How To: Test Automation with Device Cloud
    Learn, how to execute automated browser tests with Jenkins and the Testbirds Device Cloud. The video covers getting familiar with the Device Cloud, starting a new browser test run using Jenkins, monitoring your test and executing parallel cross browser tests on different virtual machines.

    Discover more

    Manual Testing

    How To: Manual Testing with Device Cloud
    Learn how to execute manual testing with Testbirds Device Cloud. The video covers getting familiar with the Device Cloud, starting a new browser test and optimising your frontend development.

    Discover more

    DEVICE CLOUD

    Quality Assurance Testing 2.0
    Cross Browser tests, Mobile App & Desktop Application Testing made easy: Harness the power of virtual and real devices for your software development – perform fully automated or manual testing directly in your browser. Our Device Cloud provides you with all the testing methods for your cross device and cross browser testing.

    Discover more

    Landal GreenParks

    DEVICE CLOUD: Landal GreenParks uses device cloud to optimise the guest experience
    “Together with Testbirds, we are now researching the test automation possibilities, so we can efficiently verify that the front-end website information corresponds with that on our MDM system.”
    Remco Vink | Functional Application Manager @ Landal GreenParks

    Download Case Study

    Deutsche Telekom

    DEVICE CLOUD: Test Automation
    The cooperation with the developers of Testbirds is very uncomplicated and at a high professional level. All our requirements could be fulfilled without delays and without problems in the timeframe specified by us."
    Alexander Gunnar Kiefer | Technical Project Lead @ Deutsche Telekom

    Rebtel uses Device Cloud

    "Device testing is integral to our mobile QA process at Rebtel. We’ve tried many cloud device testing platforms and none can provide the functionality we need. The real devices - powered by Global real device network - promises to meet our needs and then some, with the globally distributed nature of the network representing real users much better than a single-location device-farm."
    Andy Kaminski | Head of Mobile @ Rebtel

    Webinar: Test Automation

    DEVICE CLOUD: Test Automation
    This webinar provides insights into the challenges and best practices of automated browser testing for websites and cross device testing for apps. Georg Hansbauer, Founder and Managing Director of Testbirds, shows how our SaaS solution TestChameleon™ can help. Content: • About Testbirds • Motivation for automated testing • Setup of an automated testing process • Real world example
    Georg Hansbauer | Founder and Managing Director @ Testbirds

    More Webinars

    Whitepaper: Test automation

    Test Automation of UI Tests using Selenium and Appium
    This whitepaper by Georg Hansbauer, Founder and Managing Director of Testbirds, shows how developers can reduce manual testing efforts with UI automation using Selenium and Appium. How QA Managers can integrate automated browser tests into their existing development cycles and what a corresponding testing infrastructure for cross browser testing could look like.
    Georg Hansbauer | Founder and Managing Director @ Testbirds

    More Whitepapers

    Whitepaper: Real Devices

    True Remote Software Testing on Real End-User Devices

    This whitepaper shows how software development teams can efficiently make use of Real Devices for cross device testing - powered by Global Real Device Network. Our Real Devices are use a worldwide network of end-user devices - for the execution of functional testing.
    Georg Hansbauer | Founder and Managing Director @ Testbirds

    More Whitepapers

    1und1-testbirds-crowdtesting  ACE Bug test app  ANWB Usability Test  Appitized Bugability  Arvato - Chatbot Testing  Assmann - End-to-End Bugability  Audi - UX-Study  Baur- Bugtesting  Bayernatlas - Bugfixing  Bittl - Bugability  bmw-logo-crowdtesting-testbirds  Braun - Bugability  CEBIT - Bug Testing  Celonis - Bugability  DATEV - Usability  Deutsche Bahn - Crowdtest  Deutsche Messe - Website testing  Deutsche Post - Bug Testing  Telekom - Test Automation  Die Welt - Website Testing  DM -Bug Testing  DHL - Bugability  Dr. Oetker - Bugtest  Elitepartner - App Testing  Evening Standard - Website Testing  Webshop Testing  App Testing  Bugability  End-to-End Testing  Immowelt - Website Testing  Interhyp - Remote Interviews  Comparison Study  User Experience Test  Training Academy  Bug Testing  Crowdtesting Exploratory Bugtest  Website Testing  Webshop Testing  Usability Study  Device Cloud - manual testing  Load Testing  Webshop Testing  Bugability  Website Testing  Bug Testing  Webshop Bug Testing  Bug testing  Crowdtesting  Bugability


    chatbot partner  Crossbrowser testing  testbirds partnership  Partnership  Mobile Testing partnership  crowdtesting qa partner   game testing partner   crowdtesting partner

    Subscribe to the Testbirds Whistler!

    Receive updates on our innovative testing services, webinars, brand-new Nest features!

    You have Successfully Subscribed!

    @ Contact