When employing XLT Script Developer you usually resort to automated or manual scripting to drive your testing. Sometimes though you will face a very specific or complex task that can not be expressed that easy with the standard scripting capabilities of Script Developer. For these types of scenarios Script Developer provides the option to integrate a custom Java module. With custom modules you have the full power of your Java runtime and are able to achieve virtually any testing objective.
Did you ever have to create multiple versions of your test cases to accommodate small differences of your test objects? Looking for a trade-off between good testing practice and minimizing project complexity. The following blog post reflects on this challenge and introduces you to a potential solution: Conditional Expressions.
Xceptance introduced its test automation and load testing tool XLT 4.6 in February 2016 and with it we brought you conditionals. Today we want to shed some light on this new feature, the discussion that came along with it and why we finally decided to introduce it. This blog post will equip you with everything required to employ conditional expressions in your test scripts.
In computer programming, a condition or conditional expression performs an action depending on whether a given statement (the condition) evaluates to true or false. The programmer has the possibility to execute a part of the program only if certain circumstances are met. Now don’t worry, you do not need to become a full-fledged programmer to create your test cases with XLT Script Developer. But you should not skip on the possibilities this new feature is offering.
In testing typically you want your flow of execution to be linear, deterministic and transparent. The individual execution steps of your test case should be well-defined and yield the same results in a constant environment. If one execution step fails – e.g. an assertion does not check out – the whole test case always breaks and evaluates to failed. Run, rinse and repeat.
On the contrary often enough your real world test cases need to cater various scenarios. Think multi-region support of your page for example. Area specific content and functionality can quickly bring you into a catch-22 situation. Follow good practice in test case design, but deal with complexity and organizational nightmares in your test suite. Tiny differences in your test objects force you to keep multiple versions of your (already lengthy) test cases. Farewell maintainability! Continue reading Conditional Expressions in XLT→
Xceptance released version 4.3 of its load testing and test automation product Xceptance LoadTest. It features a wide range of improvements and new functionality.
As always, this update is free of charge for every user. You can use XLT freely for your daily automation work, regression testing, and performance validation. If you are an eligible Open Source project, you can get a full XLT license for your load and performance testing needs for free as well.
Enjoy more automation with less clicking. The new information panel summarizes the specifics of the currently selected item, so you do not need to open it anymore. Additionally, the new log panel lists all executed commands and their respective parameters.
If an element is styled with the CSS property text-transform, then the element’s text on the screen may have different character casing from what is defined in the page’s DOM tree. The WebDriver specification mandates to return the text as shown on the screen. Script Developer will now record text with the the character casing that appears on the screen and it will also take the CSS property text-transform into account when replaying text assertions.
The XLT load test reports have been improved by adding more charts and data details, such as overall statistics for all timers. Arrival rate charts have been added to visualize the load development over time and make sure the desired load factor was reached.
Charts can now optionally be configured to be logarithmic. A capping can be added to hide larger spikes, which usually make charts hard to read, without removing the important information altogether.
The new networking section summarizes all general network-related statistics and charts on a separate page.
The error and event page has been redesigned and includes a new error chart that contains separate graphs for all transactions/actions/requests so that the temporal distribution of transaction/action/request errors is displayed in one chart. A new error summary table groups all errors by their error message to help you see which types of errors occurred and how many of them.
Load and Performance Testing
The master controller features two new commands to validate the availability of agents and display their current configuration. A new command line option permits the skipping of result downloads when XLT is used as a load generator only.
A set of new commands is available in Script Developer and in the framework: commands such as assertAttribute, assertStyle, assertClass, assertEval, and their matching store and wait equivalents.
XLT can now send and receive IDs as part of the request to ease the correlation of server-side logs and test results. XLT may send a randomly generated alphanumeric ID as request header or extract such an ID from an arbitrary response header.
When dealing with different test environments, different load profiles, and/or different test data at the same time, managing different combinations of configuration settings can be challenging. The new property file include feature makes it easier now to predefine aspects and reuse them later in different configurations without copying and pasting.
When a test case reads a certain setting from the configuration, the framework uses a fallback strategy when doing the property look-up. This strategy performs an additional look-up step now, based on the transaction name (the short name to which the full class name is mapped). This additional step lets you parameterize different transactions differently, even if they are mapped to the same class and therefore share the same code.
The webdriver that will be used when executing functional tests can now be configured via properties. This allows greater flexibility and hardcoding is not necessary anymore.
When XLT executes XML script test cases with a WebDriver instance that is capable of taking screenshots, it can take a screenshot after each action, if desired.
A new look matches the overall styling of reports. Also, the navigation bar can now be resized, requests are color coded to visualize the content type, and the first page is displayed automatically. URLs are now active links, so you can click them easily.
XLT is shipped with an empty test suite project that can be used as a template for your own projects.
HtmlUnit has been upgraded to version 2.12.
WebDriver/Selenium has been upgraded to version 2.39.0.
EC2 admin console permits setting a tag name now.
Amazon Machine Images
The Amazon Machine Images (AMI) listed below are available for public use. Using these images is free of charge, but require that you own an Amazon Web Services (AWS) account. Please make sure that your EC2 security group permits communication on port tcp/8500. AMIs with Java 6 are no longer provided.
eu-west-1 : ami-ceae46b9
us-east-1 : ami-2510394c
us-west-1 : ami-e4ccfca1
us-west-2 : ami-9ebadeae
ap-southeast-2 : ami-617be45b
If you need XLT-AMIs in Tokyo, Singapore, or Sao Paulo, please let us know.
Purchase Licenses and Support Online
Licenses and support can be conveniently ordered through our XLT Self Service Center. You can instantly download licenses and purchase support right when it is needed. All your invoices and previous licenses (when purchased online) are accessible at any time.
We will notify you before your license or support runs out, so that you will never miss that again. This enables you to continue your daily automation and load testing work without interruption. Please note that we do not renew your contracts automatically, so no strings attached.
Visa and MasterCard are accepted. All credit card data is processed and secured by Wirecard.
Today’s article can be seen as a survey reflecting our thoughts on web test automation in general. It basically lists personal experiences that we were able to gain in customer projects or conclusions that we arrived at in recent discussions on this topic.
We received a lot of positive feedback on introducing our sample test automation suite for Demandware SiteGenesis. Have a look at the original post containing a video tutorial and all information you will need to get started.
It’s our intention to keep the test automation suite up-to-date, so it covers new and additional features of SiteGenesis. The latest update for version 13.3 of SiteGenesis contains the following improvements:
Support of the new multi-ship feature of SiteGenesis
Better independence of SiteGenesis product data
Stability improvements to make the test suite much more stable with reference to timing issues
Support for testing in Chrome and Firefox remotely without Script Developer
Introducing of ANT support for easier integration into build automation
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. 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→
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.
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.
By clicking Opt-Out, we will place a non-personalized cookie on your machine that indicates that you don‘t wish to be tracked.