Nach längerer Forschung ist es uns nun gelungen, möglichst abstrakte und doch surreal schöne Diagramme zu malen. Leider werden wir unseren Kunden dieses wunderbare Feature in der endgültigen Softwareversion vorenthalten müssen.
P.S. Es war nicht mal ein Bug in der Software, einfach eine unerwartete Datenanomalie.
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:
Wir freuen uns schon auf die Fertigstellung von XLT 3.3. Zu den einzelnen Neuigkeiten wird es demnächst mehr Blogeinträge geben.
Wir 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 :)
Die 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.
In den letzten Wochen war es etwas ruhig in unserem Blog. Tut uns leid. Das liegt Gottseidank hauptsächlich an der guten Auftragslage. Zusätzlich arbeiten wir derzeit an der Fertigstellung der XLT-Versionen 3.1.1 und der 3.2, die einige schöne Neuerungen mitbringen wird.
Der Rekorder wird beispielsweise auch ungenutzte Form-Bestandteile aufzeichnen, so dass die spätere Anpassungen der Skripte vereinfacht wird. Mehr Infos gibt es, wenn wir das Release ausrollen.
Sobald wir eine Sekunde finden, wird auch mehr Blogeinträge geben. Weiter soll es mit den Webseiten-Tuning Tipps gehen und mehr zum Thema Lasttesten ist auch geplant.
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.
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!
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.
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.
|
1 2 3 |
final String email = UUID.randomUUID().toString().substring(0, 15). replaceAll("[^A-Za-z0-9]", "A") + "@yourdomainname54678765.net"; |
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.
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:
|
1 |
div[@class='stockstate' and . = 'unavailable'] |
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:
|
1 |
div[@class='stockstate' and normalize-space(.) = 'unavailable'] |
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 :)
Ich muss mich heute einfach mal über das Start-And-Go Feature von Xceptance Load Test (XLT) freuen. Früh im Hotel habe ich mich zum Cloud Service verbunden, den Lasttest hochgeladen und gestartet. Danach habe ich das Notebook abgeklemmt und bin Frühstücken gegangen.
Eine Stunde später sass ich im Büro, habe mein Notebook hochgefahren und mich wieder zur Cloud verbunden. Teststatus abgerufen und da der Test durch war, einfach die Ergebnisse runtergeladen.
Es ist echt praktisch, wenn man nicht ortsgebunden für einen Test ist und das Tool einen nicht zwingt, ständig mit den Testmaschinen verbunden zu sein. So machen auch die üblichen Netzunterbrechungen im Hotel oder via UMTS keine Probleme mehr.
Hatte ich schon erwähnt, dass ich beim letzten Mal vom Flughafen, ca. 30 min vor dem Boarding noch mehrere Lasttests laufen hatte? Auch sehr praktisch, dass XLT mit einer Shell auskommt und man den Controller ohne Probleme auf eine Drittmaschine verlagern kann, die man dann via Shell steuert.
Bei der heutigen Sicherheitslage in Rechenzentren bekommt man meist ja nur einen SSH-Zugang mit eigenem Schlüssel und sonst nichts. Aber genau dafür ist XLT gemacht. Mit wenig Ressourcen, viel zu erreichen.