Category Archives: Software

Our Top 6 Software Testing Trends 2013

Happy New Year to everybody! Time to think about 2013 and the work ahead of us.

The ecommerce market is growing and becoming more competitive every day. This means, the customer experience is going to play an even bigger role in 2013. Online shops are expected to be stylish and beautifully designed – but customers are getting more demanding in terms of performance and usability on multiple devices.

The following topics are our point of view on the most important issue that will keep us busy in 2013.
Continue reading Our Top 6 Software Testing Trends 2013

Discontinued support of JRuby

The upcoming Xceptance LoadTest 4.2 will discontinue the direct support of JRuby as a programming language for writing test cases. This will not change the way Java and JRuby interact and therefore you can still use all Java components and integrate them into your JRuby-based test suite. You can also still write test cases in Ruby and use XLT-APIs.

You can read about this feature, in case you are not sure whether or not you will be affected by this change: XLT 3.3.0 JRuby support release note.

Version 4.2 of Xceptance LoadTest will not continue the JRuby package anymore (jruby.jar). The test execution scripts for JRuby-based tests and all demo test cases will be removed as well.

If you have any questions regarding this change, please do not hesitate to contact our support team directly.

XLT 4.1.8 Update Release

XLT 4.1.8 has been released. It contains a couple of improvements and bug fixes. You can get the latest version here: https://lab.xceptance.de/releases/xlt/4.1.8/.

These are the two most important changes.

Optimized scanning CSS rules

XLT simulates the download behavior of a browser as close as possible. With com.xceptance.xlt.css.download.images set to onDemand, XLT carefully considers the download of image resources referred to in CSS files. It checks all CSS rules if they apply to all elements in the DOM tree and, if so, extracts the resource information for later download. This process was previously very expensive and ran for up to several seconds when a page was complex and a lot of CSS rules had to be matched. This has been optimized heavily.

Configurable retry behavior for keep-alive connections

If persistent connections (keep-alive) are enabled, test cases might failed sporadically with an exception such as:
java.lang.RuntimeException: org.apache.http.NoHttpResponseException: The target server failed to respond

This exception occurs only when the request was sent while the connection was about to be closed on the server side at the same time.

The underlying HttpClient retries requests if the connection was closed by the server. However, by default it retries only idempotent operations such as GET and HEAD, but not POST and PUT. In order to avoid these connection errors, the user can now configure whether non-idempotent operations are to be retried as well. Common browsers seem to use the same behavior and most certainly assume that the server did not start to process the request when it closes the connection immediately without responding with a proper HTTP status code.

A new boolean property com.xceptance.xlt.http.retry.nonIdempotentRequests in config/default.properties controls whether or not operations such as PUT and POST are retried in case of certain networking problems. Note that idempotent operations are always retried.

XLT 4.0.5 is out

We just released Xceptance LoadTest 4.0.5. It is a minor update and recommended for everyone. But you might have special interests if you use the Script Developer heavily.

Besides a few defect fixes, release 4.0.5 delivers four great improvements to speed up test case creation and maintenance with Script Developer and make your work more productive.

  • The XLT Script Developer runs on Firefox 4 and 3 now.
  • Test variables are now resolved recursively, so you can use variables within resolved content.
  • There is no need to open modules anymore if you want to edit a line or two of it. Also enabling/disabling of module code can be done easily from the main test case. This saves time and aids script maintenance.
  • During script debugging and script execution, you can now evaluate assertions instantly to see whether or not your verification expression will match.

The full set of release notes can be viewed directly in the release area. You will also find documentation and the download link there. As usual, th

Availability of new XLT 4.0 EC2 Images

There are new public Amazon EC2 images (AMI) available each running 4 agentcontrollers of XLT 4.0.0.r6019 on ports 8500 to 8503. Feel free to use them for your load testing purposes.

  • EU-West: ami-9b5064ef
  • US-East: ami-5647b63f
  • US-West: ami-539dcd16

The usage of the images is free or charge but you have to pay your AWS usage costs of course. Please keep in mind that you need a valid license to run a load test with more than 5 virtual users.

Reasons for a Test Environment

People asked for a rough guide for running load tests against their live site and whether this is a good idea at all.

Well, let me first say that test environments exist for exactly that purpose. So if you already have something live, of course you used it before going live for load testing, and now you cannot run another test there… yes, you need a test environment. This is well spent money for several reasons:

  • Created data will not pollute your installation aka log entries, analytics data, orders in the database, created users, and so on.
  • You do not have to take your live site down for testing.
  • Problems during testing will not leave your live site down or take it down.
  • Your hosting company or IT department might charge for all test traffic against the live site as it would have been real traffic (revenue share, bandwidth utilization), so having your own testing realm makes expenses more predictable.
  • You can easily change code and retest when changes are necessary. You can profile, you can debug.
  • You do not risk problems with traffic going to live systems, such as payment due to configuration or testing errors. If you already had items from test orders piling up in your office, you know what I mean.

So, get yourself a test environment. Spend the money and enjoy the freedom to measure, debug, and tune.

P.S. Of course, there are situations, where you cannot replicate a live environment or you cannot find application problems in a test setup due to totally different timing behavior… Well, this indicates only that your live environment is already screwed.

Google wendet sich vom IE6 ab

Google hat sich entschieden, Problemen bei der Entwicklung von Webapplikationen aus dem Weg zu gehen und kündigt die Unterstützung des Internet Explorer 6 auf. Auch der Support vom Firefox 2 läuft aus, aber den nutzen ja die wenigsten Leute, weil das Update auf Version 3 einfach ist. Zudem war der FF2 nicht schlecht bei der Einhaltung von Webstandards und dürfte locker dem IE7 das Wasser reichen können.

Das ist ein gutes Signal, denn wenn der Marktführer es vormacht, dann werden viele Leute und Firmen nachziehen.

Many other companies have already stopped supporting older browsers like Internet Explorer 6.0 as well as browsers that are not supported by their own manufacturers. We’re also going to begin phasing out our support, starting with Google Docs and Google Sites. As a result you may find that from March 1 key functionality within these products — as well as new Docs and Sites features — won’t work properly in older browsers.

Mehr dazu im Google Enterprise Blog.

Einige aktuelle Zahlen zur Nutzung verschiedener Webbrowser finden sich bei Bivingsreport.