Category Archives: XLT

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.

XLT

Die neuen Reports in XLT 3.2

XLT 3.2.1 Beispiel ReportWir hatten ja noch einige Informationen zu XLT 3.2 versprochen. Heute gibt es einen Blick auf die neuen Reports, die nach einem Lasttest automatisch erzeugt werden.

Die Reports werden mittels XSLT aus XML-Daten erzeugt und sind pures XHTML 1.1 und CSS 2.1. Damit können sie leicht den eigenen Bedürfnissen angepasst werden. Auch die Größe der Diagramme ist veränderbar.

Man kann auch verschiedene Reports mit unterschiedlichen Inhalt gleichzeitig rendern lassen und so verschiedene Zielgruppen ansprechen. So zum Beispiel einen sehr detailierten für den Tester und einen Zusammenfassung für das Manager-Meeting am nächsten Morgen :)

Der komplette Report findet sich hier…

Performance, Software Development, XLT

Vergleich von Lasttest-Ergebnissen

Übersicht über die Unterschiede in der Request-LaufzeitDie kommende Version von XLT (3.3) wird ein schönes neues Feature mitbringen: Die Möglichkeit des Vergleichs von Lasttest-Ergebnissen und die dazu gehörige Visualisierung. Hier nur ein kleiner Ausschnitt aus einem Report. So oder so ähnlich wird es dann aussehen.

Wie gewohnt, wird auch der Vergleich von Lasttest-Ergebnissen nur mit offenen Datenformaten arbeiten. Außerdem wird der Vergleich basierend auf den bereits existierenden Reports erstellt. Damit kann man schnell und einfach zwei Reports vergleichen und sich ein Bild von den Fortschritten oder aktuellen Problemen machen.

Alle Kunden, die bereits XLT einsetzen, sind herzlich zu einem Vorabtest der Entwicklungsversion 3.3 eingeladen.

Software Development, XLT

XLT 3.2 ist nicht mehr weit

Nächste Woche wollen wir XLT 3.2 releasen. Ich freue mich drauf, denn es ist wirklich gut geworden. Wir haben viele Dinge umgesetzt, die die Arbeit mit XLT schneller, effizienter und interessanter machen. Nichts davon ist praxisfern entstanden, sondern alle Verbesserungen und neuen Features sind aus der Arbeit mit XLT entstanden.

Mehr demnächst hier.

XLT

Der schwere Akt – Screencasts

Screencast anzufertigen ist echt kein triviales Thema. Heute habe ich mir mal die verfügbare Software angesehen. So richtig entschieden habe ich mich noch nicht, aber ich versuche wohl einfach mal einen Screencast für XLT und dann schauen wir weiter. Versuch macht klug.

Das Schwierige ist eigentlich eher das Storyboard, damit der Screencast keine langweilige Angelegenheit wird.

Testing, XLT

Implizite Safari-Tests

Es zeigt sich immer wieder, dass Webseiten, die sich schwer mit XLT automatisieren lassen und immer wieder mit Fehlern abbrechen, im Regelfall im Safari nicht laufen. Meist ist schlechtes HTML und fehlerhaftes Javascript Schuld. Praktisch diese impliziten Tests… aber manchmal auch nervig, da leider zuviele Leute den Safari, damit auch Google Chrome, ignorieren.

Das alles wäre gratis, wenn man einfach nur guten Code produzieren würde. Standards Baby, Standards!

XLT

Lasttest-Mailbox

Bild meiner Lasttest-Mailbox

Heute habe ich meine Lasttest-Mailbox aufgeräumt, denn es stauten sich mehr als 5000 Test-E-Mails. Aber was ist eine Lasttest-Mailbox?

Für die meisten Testszenarien im E-Commerce-Bereich benötigt man E-Mail-Adressen, weil oft Nutzer über die E-Mail identifiziert, Bestellbestätigungen oder schlicht Passwort-Erinnerungen verschickt werden. Für einige Fälle ist es ausreichend, erdachte Adressen zu verwenden, die nur dem allgemeinen Format einer E-Mail-Adresse (name@server.domain) genügen müssen.

Sobald aber das System unter Test wirklich diese Adressen nutzt und E-Mails verschickt, muss man auf gültige Daten achten, weil sonst das System unter der Flut von Rückläufen zu leiden beginnt und/oder man von den Administratoren eine Verwarnung kassiert.

Die beste Idee wären natürlich jede Menge Postfächer bei Google, aber wenn man 10000 Nutzer mit individuellen E-Mails braucht, dann kann und darf man bei Google keinen Pool anlegen. Allein die Unterscheidung, ob man beim bereits eine E-Mail im Test verwendet hat oder nicht, ist sehr schwer. Zusätzlich ist die Pflege von Testdatensätzen im Allgemeinen sehr zeitintensiv und fehleranfällig.

Wie soll es aber dann gehen?

Bewährt haben sich Catch-All Mailboxen beim eigenen E-Mailprovider oder auch Mailboxen auf virtuellen Servern. Hier kann man eine Domain und eine Mailbox konfigurieren und dann durch das Catch-All unendlich viele E-Mail-Adressen nutzen, die man einfach zufällig erzeugt.

Unter Java 6 ist diese Zeile Code sehr nützlich. Sie erzeugt recht zufällige E-Mail-Adressen mit einer Länge von 15 Zeichen für den Namen. Da die JDK 6 UUID-Klasse genutzt wird, ist eine ausreichende Eindeutigkeit garantiert. Nun gut, eigentlich darf man dann den String nicht einkürzen, aber die meisten Dienste können lange E-Mail-Adressen nicht leiden und so muss man sich beschränken.

Selbstverständlich muss die Domain yourdomainname54678765.net existieren, einem selbst gehören(!) und das Catch-All der Mailbox dafür korrekt konfiguriert sein.

P.S. Für den Test eines großen E-Mail Dienstes würde ich aber nicht darauf zurückgreifen, weil man zwar viele Mails erzeugen und versenden kann, aber diese Lösung nur für einen moderaten Verkehr ausgelegt ist. Schließlich gehen alle E-Mails den gleichen Weg und nisten sich im selben Briefkasten ein.

Für einen großen Test würde ich wohl eine Serverfarm bei Amazon-EC2 konfigurieren oder 20 virtuelle Server bei verschiedenen Hostern einkaufen.

XLT

Whitespaces und XPath

Machmal kann es nützlich sein, bei der Arbeit mit XPath-Ausdrücken in HtmlUnit respektive XLT, Werte von HTML-Elementen direkt in der XPath-Expression zu vergleichen. Wenn aber jede Menge Whitespaces vorkommen, und bei automatisch generiertem HTML-Code ist es leider meist so, dann scheitert der Vergleich:

Ein Hilfe ist hier die XPath-Funktion normalize-space(), die unnötige Whitespaces nach den Regel von XML reduziert. Also in der Regel doppelte Spaces, Spaces zwischen <> und dem Text, sowie Zeilenumbrüche entfernt. Damit sieht unser XPath-Ausdruck dann so aus:

P.S. Günstig wäre natürlich, wenn man diese unnützen Daten erst gar nicht transportieren würde. Ich möchte nicht wissen, was täglich an sinnlosen Whitespaces durch das Netz geschickt wird :)