Category Archives: Testing

Why Test Automation Costs Too Much

I got a pretty nice link today. Check out that short article about the usual obstacles when trying or applying test automation: Why Test Automation Costs Too Much. Elisabeth covers the aspects of disconnected teams and the often practiced sharp distinction between programmers and testers pretty well.

Bottom line: the reason test automation costs so much is that it’s done in a silo far removed from the development effort.

Buffered from the consequences of design decisions that decrease testability, the developers continue to create software that’s nigh onto impossible to automate.

And isolated from the technical expertise of how the software was constructed, the test automation specialists are in a situation where they cannot help but be both inefficient and ineffective.

Enjoy reading!

Load Testing Web Applications – Do it on the DOM Level!

We published the article “Load Testing Web Applications – Do it on the DOM Level!” in the 10th issue of the testing magazine “Testing Experience“. This issue is all about performance testing. The article discusses our experience in web load testing on HTTP level versus HTML/DOM level.

There is a free PDF version of the magazine that requires an online registration, where your e-mail address and country are required fields.

Enjoy reading!

XLT 3.3.1 – Neue Kommentarfunktion

XLT-LogoJeder Tester hat sich bestimmt schon über den Aufwand geärgert, den man treiben muss, damit Testkonfigurationen, -ergebnisse und Änderungen an der Zielplattform für die spätere Testauswertung zur Verfügung stehen. Vor allem viele Änderungen während der Fehlersuche können das Testleben recht schwer machen. Weiss man dann wirklich immer noch, wie viele Server in diesem Moment liefen oder ob man die Cacheeinstellungen für diesen Testlauf angepasst hatte?

XLT hat hier bisher schon immer einen guten Job gemacht, denn es archiviert automatisch die Konfiguration zusammen mit dem Testreport und erlaubt so, jederzeit den Test zu wiederholen oder die Einstellungen nachzuprüfen. Aber Kommentare und Notizen zum Testzweck waren bisher nicht Teil der Daten.

Mit XLT 3.3.1 haben wir das geändert und eine Kommentarfunktion integriert, um schnell Testgedanken erfassen zu können und zusammen mit dem Test zu archivieren und natürlich auch in den Testergebnissen darzustellen.

Ab sofort können Kommentare und Informationen zur aktuellen Testkonfiguration hinzugefügt werden. Das ist vor allem wichtig, wenn man im Team arbeitet. Zusätzlich kann jeder Testlauf kommentiert werden. XLT fragt, ob man einen Kommentar hinzufügen möchte und speichert diesen gemeinsam mit dem Testergebnis ab. Alle Kommentare werden dann in den Testreport gerendert. So hat man sofort Ergebnisse und Notizen gemeinsam verfügbar.

Damit man seine Gedanken und Anmerkungen auch strukturieren kann, erlaubt XLT an dieser Stelle HTML als Eingabe. Besonders nützlich sind die Tags für Absätze (p), Listen (ul, li) und Hervorhebungen (em, strong).

Mehr dazu in den Release Notes von XLT 3.3.1.

Alle Verzeichnisse in einem Verzeichnis einpacken

Wer auf seiner Serverplatte (Linux) mal aufräumen möchte, der könnte den folgenden Shell-Schnipsel nützlich finden. Es TARt und komprimiert alle Verzeichnisse im ggw. Verzeichnis und räumt danach das gerade frisch eingepackte Verzeichnis weg. So lässt sich Platz sparen. Zum Beispiel weil man viele Testergebnisse herumliegen hat.

for i in ls -d * ; do tar cfz $i.tar.gz $i ; rm -rf $i; done

Getestet auf OpenSuse.

Andere Blogs rund ums Testen

Natürlich gibt es noch andere Blogs, die sich mit Testen und Qualitätssicherung beschäftigen. Einige davon möchte ich heute mit einem kurzen Kommentar vorstellen:

  • DevelopSense von Michael Bolton (nicht der Sänger). Für Michael ist der Fakt wichtig, dass ein Tester viel wertvoller ist, als jede Automation. Das Hirn eines Testers ist sein Werkzeug. Er nennt es auch: Checking is not testing.
  • James Bach vertritt eine ähnliche Meinung und verurteilt die blinden Bestrebungen, alles unkontrolliert zu automatisieren. Sein Kernbotschaft dreht sich um Exploratory Testing. Das intuitive, aber nicht zufällige Testen.
  • Eric Jacobson legt sich nicht auf Gebiete fest, sondern kommentiert alles Querbeet.
  • Nicht zu vergessen das Google Testing Blog. Hier berichten Google Tester aus ihrer täglichen Arbeit und den Herausforderungen von großer Software.

Wer kennt weitere empfehlenswerte Blogs?

Was QA nicht machen soll

Es gibt immer große Missverständnisse über die Rolle von QA/Test. Einige Leute wollen, dass QA das Produkt explizit freigibt und notfalls es aufhält, wenn es schlecht ist. Andere meinen, dass es besser ist, wenn QA einfach nur eine Empfehlung ausspricht.

Jon Bach hat heute auf der STPCon 2009 mit einem kurzen Satz schön zusammengefasst, welche Aufgabe QA hat. Ich teile seine Ansicht voll.

QA does not make quality. QA helps to make an informed decision about the quality.

QA/Test stellt den Zustand der Software/Hardware fest und informiert darüber. QA wird sich auf keinen Fall die Aufgabe auf den Tisch ziehen, zu richten. Das soll bitteschön der Auftraggeber, Programmmanager oder Projektmanager machen. Er bekommt den Bonus, er darf entscheiden. QA hilft nur dabei und zwar so gut, dass er eigentlich nicht anders kann, als der QA-Empfehlung zu folgen.

Was sind Visits, was sind Sessions?

Wenn wir mit Kunden über die möglichen Lasttesteckdaten sprechen, dann ist immer wieder von Visits und Sessions die Rede. Beide Begriffe stammen aus dem Englischen, sind aber durch das Internet und die meist in Englisch ablaufende Softwareentwicklung in den allgemeinen Sprachgebrauch im Bereich Last- und Performancetests eingegangen. Selbstverständlich gibt es auch deutsche Entsprechungen, wenn auch weniger oft benutzt: Besuche und Sitzungen.

Warum geht es im Allgemeinen?

Visits und Sessions sind Begriffe aus der Webentwicklung, werden aber auch als Metriken im Webumfeld genutzt. Der technische Teil verbindet sich in der endgültigen Definition mit der wirtschaftlich/mathematischen zur eigentliche Bedeutung. Was wir also wollen ist: a) wissen was dahinter steckt, b) erfahren was die Begriffe definieren und c) wissen wozu man die Zahlen braucht.

Was ist ein Visit?

Wenn man sich dazu entschließt, eine Webseite zu besuchen, dann ruft man irgendwann eine erste Seite auf. In diesem Moment hat man einen Visit begonnen oder auf Deutsch – man ist zum Besucher geworden. So lange man sein Surfen auf dieser Webseite fortsetzt, solange setzt man seinen Visit fort. Alle einzelnen Seiten zusammengenommen, bilden damit, beginnnend mit der ersten Seite, einen Visit.

Für den Betreiber ist damit klar, dass ein Interessent oder Kunde seiner Webseite einen Besuch abgestattet hat. Am besten läßt sich das mit dem Besuch eines realen Ladens vergleichen. Wenn man in den Laden geht, dann beginnt man seinen Besuch/Visit und wenn man ihn wieder verlässt, dann endet der Besuch/Visit.

Natürlich gibt es auch Ausnahmen von der Regel. Wenn man nur mal schnell 5 Minuten in die Küche geht bzw. in einem realen Laden schnell zum Auto läuft, weil man sein Geld vergessen hat, dann zählt das nur als ein Visit, weil man nur eine Besuchsabsicht hatte.

Über die Metrik Visit läßt sich damit einfach messen, wieviele Besuchsabsichten pro Zeiteinheit vorgelegen haben und auch in die Tat umgesetzt wurden. Dabei spielt es keine Rolle, ob man etwas kauft, zurückbringt oder gleich wieder an der Tür kehrt macht.

Im Internet gibt es nicht nur echte Besucher, sondern auch jede Menge Automaten, die sich in den Netzweiten herumtreiben und mit jedem Abruf einer oder mehrerer Seite jeweils auch einen Visit erzeugen. Das bringt natürlich die Statistiken durcheinander. Deshalb versucht man durch technische Maßnahmen, diese meist unrelevanten Besuche herauszurechnen. Das Wie kann bei Interesse ein weiterer Blogeintrag werden.

Was ist eine Session?

Nun haben wir geklärt, was hinter dem Begriff Visit steckt, aber was ist dann eine Session?

Einfach gesagt, ist eine Session die technische Abbildung eines Besuchs/Visit. Die genutzte Technik und Software müssen sich nämlich merken, welche Anfragen zusammengehören, damit es möglich wird, Dinge wie ein Login oder einen Warenkorb technisch umzusetzen.

Sessions bestehen aus Daten, die Informationen über die Vorgänge des Visits zusammenfassen, oft als Sessioninformationen bezeichnet. Diese Datensätze haben im Regelfall eine begrenzte Lebenszeit. Wenn man seinen Visit beendet bzw. nicht fortsetzt, also nicht mehr klickt, dann beginnt eine Uhr zu ticken, die nach eine einstellbaren Zeit (oft 30 Minuten bis 2 Stunden), die Daten entfernt, damit es zu keinen Überläufen kommt. Das nennt sich Session-Timeout. Nimmt man vor Ablauf der Zeit seinen Besuch wieder auf, kommt also in den Laden zurück, dann beginnt die Uhr von Neuem zu ticken.

Vergleichbar ist es mit der Situation, dass man an der Kasse sein Geld nicht findet, den Korb schnell an der Kasse lässt, um Geld zu holen. Kommt man nun nicht rechtzeitig zurück, dann hat jemand den Korb ausgeräumt und die Waren zurückgestellt.

Die Anzahl der Sessions müsste eigentlich immer gleich der Anzahl der Visits sein. Da aber Visits oft anders gezählt werden, weil geschäftliche Kriterien dahinter stehen und keine technischen, liegen oft die Visits unter der Anzahl der Sessions pro Zeiteinheit.

Wir hoffen, dass diese kurze Erklärung hilft, die Begriffe Visit und Session zu verstehen und auseinander zu halten.

Begriffe erklärt: Lasttest, Stresstest, …

Es gibt zahlreiche Begriffe für die verschiedenen Lasttest-Arten. Unsere Erfahrung aus der täglichen Arbeit, aus Gesprächen mit Kunden und aus der Auswertung von Suchwörtern zeigt, dass die Begriffe oft unklar sind und manchmal nicht ganz korrekt benutzt werden. Daher möchten wir hier unsere Sicht auf diese Begriffe darstellen.

  • Lasttest: Bei einem Lasttest wird die zukünftige Nutzung des zu testenden Systems unter Berücksichtigung bestimmter Benutzer- und Transaktionsmengen simuliert und bewertet. Dabei werden zwei grundsätzliche Ziele verfolgt. Das erste Ziel ist die Aufdeckung funktionaler Fehler, die nur unter paralleler oder intensiver Nutzung des Systems auftreten. Das zweite Ziel ist die Überprüfung des Zeit- und Verbrauchsverhaltens des getesteten Systems unter einer gegebenen Last. Dabei werden beispielsweise Antwortzeiten sowie der Verbrauch von Hauptspeicher und Rechenleistung ermittelt. Lasttests können auf unterschiedliche Aspekte eines Systems ausgerichtet sein. Dafür sind jeweils auch unterschiedliche Lastprofile und Testszenarien erforderlich, die oft mit eigenen Begriffen bezeichnet werden. Beispiele dafür sind “Skalierungstest”, “Stresstest” oder “Dauerlasttest”. Der Begriff “Lasttest” ist der Oberbegriff für alle diese Testarten.
  • Stresstest: Bei einem Stresstest wird die simulierte Last über das im Normalbetrieb erwartete Maß erhöht, bis funktionale Fehler auftreten oder das Antwortverhalten des getesteten Systems bestimmte Grenzen überschreitet. Hierfür wird oft eine kontinuierlich ansteigende Nutzerzahl simuliert. Stresstests verwendet man beispielsweise zur Ermittlung des Systemverhaltens in und nach Überlastsituationen, zur Ermittlung der maximal akzeptierbaren Last oder zum Finden von Performance-Schwachstellen (Bottlenecks). Continue reading Begriffe erklärt: Lasttest, Stresstest, …

Xceptance LoadTest 3.3 ist verfügbar

Ab sofort steht das Softwarepaket Xceptance LoadTest (XLT) 3.3 zum kostenlosen Download bereit.

Dahinter verbirgt sich schon die erste Neuerung, denn mit dem Download besitzt man automatisch eine freie Basislizenz. Sie erlaubt Tests mit bis zu fünf virtuellen Nutzern, gilt zeitlich unbegrenzt und unterliegt keinen Nutzungseinschränkungen. Damit darf man XLT auch kommerziell einsetzen, beispielsweise intern oder in Kundenprojekten. So kann man ungehindert prüfen, ob XLT das Werkzeug der Wahl ist oder man kann XLT bereits produktiv für Regressionstests verwenden.

XLT 3.3 bietet einige neue Features, die die tägliche Arbeit effizienter gestalten und den Einsatzbereich von XLT erweitern:

  • Comparison-Reports zum detaillierten Vergleich zweier Testläufe
  • Trend-Reports zur Visualisierung von Veränderungen in den Testergebnissen über mehrere Testläufe hinweg
  • Unterstützung des Google WebDriver API für schnelles Prototyping von Testfällen
  • Ruby als zusätzliche Scriptsprache zur Testfallerstellung
  • Programmierbeispiele für typische Anwendungsfälle, zum Beispiel für die Bearbeitung von Ajax-Requests und die Behandlung von Popups oder Frames
  • Überarbeiteter Testrecorder mit der Unterstützung für Voreinstellungen zur Codegenerierung

Zusätzlich sind wieder viele Detailverbesserungen in diese Version eingeflossen. Weiterführende Informationen gibt es in den Releasenotes oder auf den Produktseiten unseres Webauftritts.

Lesepflicht – OWASP zu XSS

Heute gibt es einen Link über Cross-Site-Scripting (XSS), was es ist, was man dagegen tun kann oder kurz: Wie beugt man XSS vor?

Der Artikel stammt vom OWASP, der Authoriät im Sachen Internetsicherheit bzw. Informationen zur Sicherheit.

This article provides a simple positive model for preventing XSS using output escaping/encoding properly. While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack.

These rules apply to all the different varieties of XSS. Both reflected and stored XSS can be addressed by performing the appropriate escaping on the server-side. The use of an escaping/encoding library like the one in ESAPI is strongly recommended as there are many special cases. DOM Based XSS can be addressed by applying these rules on the client on untrusted data.

For a great cheatsheet on the attack vectors related to XSS, please refer to the excellent XSS Cheat Sheet by RSnake. More background on browser security and the various browsers can be found in the Browser Security Handbook.

Quelle: OWASP unter CC-BY-SA-3.0