Tag Archives: webdriver

Automation, Java, Testing, XLT

Web Drivers in XLT: Basic Access Authentication

Today’s article of our WebDrivers series deals with HTTP authentication – a topic that, at first sight, seems to be very specific and of minor relevance. However, in the world of software testing it’s way more important than you’d think.

HTTP Authentification IE
HTTP Authentication IE
Often you will have an additional testing instance of a website to be tested. These instances are protected from abuse which is why they require credentials before you can access them. See below for an example in Internet Explorer:

This browser dialog appears just once. If you’ve entered the right credentials, you can access the related website as often as you like without further authentication – as long as you don’t reopen the browser. The latter is a critical issue for automated WebDriver testing.
Continue reading Web Drivers in XLT: Basic Access Authentication →

Automation, Testing, XLT

WebDrivers in XLT: Test Case Design that Compensates for Inconsistencies across WebDrivers

Still remember the first post of our article series? It talked about how you can run XLT test cases in different browsers. If you’ve done so already, you might have noticed that the behavior of test cases developed in Script Developer sometimes differs depending on the WebDriver you’ve chosen. This article is meant to help you resolve such issues.

First of all, what’s the reason for these inconsistencies? Web browsers differ in their characteristics, such as site representation or functionality, due to their varying support of web technologies like CSS or HTML. You probably know that there is much more we could list, but the major point is pretty obvious already: using WebDrivers for test case execution calls real browser instances. Logically, you’re faced with the same differences as in real web browsers. It’s impossible to achieve a completely consistent web browser behavior; yet you can design your test case as outlined below to at least reduce the differences.

Time: Enlarging time properties can prevent timing problems with dynamically loaded content, like iframes or page content added with JavaScript. Script Developer lets you set an ‘Implicit Wait Timeout’. It allows to specify how long the test should wait for a command to fail while trying to find elements.

Continue reading WebDrivers in XLT: Test Case Design that Compensates for Inconsistencies across WebDrivers →

Automation, XLT

WebDrivers in XLT: How to Run Test Cases in Multiple Browsers

2 Comments

Update: Before you continue reading, here is a new version of this test suite and article: Multi-Browser-Suite for Test Automation. It makes things a lot easier.

Have you heard of XLT Script Developer yet? If you have, you’ll probably agree that it’s a convenient tool to record and run automated test cases. However, with it being a Firefox plugin, you’re basically bound to run your test cases in Firefox. Wouldn’t it be nice to reuse Script Developer test cases in multiple browsers? You can actually do so by taking advantage of the WebDriver API that is part of the XLT framework.

If you don’t know much about WebDrivers, you should continue reading this article – the first one of a little article series on WebDrivers that hopefully gives you a good introduction to the topic.
Continue reading WebDrivers in XLT: How to Run Test Cases in Multiple Browsers →

Automation, Java, Testing, XLT

Handle authentication during WebDriver testing

2 Comments

Sometimes authentication is necessary before a test case can be executed. While HtmlUnit based tests can easily enter and confirm authentication requests, most browser based tests, cannot workaround the dialog. This is a browser security measure to prevent automated data capture and/or data entering. WebDriver for Firefox delivers a solution for that problem, but IE and Chrome rely on a manual interaction with the browser before the test automation can run.

The following steps describe a solution for the authentication problem and how to run a script test case as WebDriver based test. The key to this solution is the usage of Sikuli, an image based testing tool that directly interacts with the screen to find the right elements by using the screen.
Continue reading Handle authentication during WebDriver testing →

Software, Software Development, XLT

Lasttesten mit Webdriver und Ruby

Zur Zeit arbeiten wir intensiv an unseren nächsten Xceptance LoadTest Version.  Sie wird einige interessante Neuerungen mitbringen, die man bisher auf dem Markt noch nicht so gesehen hat:

  • Als Scriptsprache steht jetzt neben Java auch Ruby zur Verfügung. Wer also die schnelle agile Entwicklung mit Ruby mag, der kann jetzt nahtlos auch in Ruby Regressions- und Lasttests erstellen.
  • Google hat sich die Mühe gemacht und eine einheitliche API zur Programmierung von Webregressiontests ins Leben gerufen – Google Webdriver. XLT spricht jetzt Webdriver. Damit lassen sich schnell Webtests schreiben und, im Gegensatz zu den anderen Tools, auch als Lasttest ausführen. Wir denken, dass damit die Einführung von XLT deutlich schneller geht und sich damit noch besser für Projekte mit Rapid-Prototyping-Charakter eignet.
  • Zwei Lasttest-Läufe lassen sich jetzt innerhalb von Sekunden vergleichen und das Ergebnis zeigt schnell und deutlich, wo die Änderungen liegen.
  • Wer sich mehr für die langfristige Entwicklung der Performance interessiert ist, dem wird der neue Trendreport eine grosse Hilfe sein. Eine beliebige Menge von Testläufen lässt sich zueinander in Relation setzen und man kann daraus einfach die Entwicklung des Performancetrends ablesen.

Wir freuen uns schon auf die Fertigstellung von XLT 3.3. Zu den einzelnen Neuigkeiten wird es demnächst mehr Blogeinträge geben.