Es kann relativ aufwendig sein einen sinnvollen und realistischen Testplan mit JMeter zu erstellen. In unseren Fall wollte ich diesen Testplan auf verschiedenen Testumgebungen einsetzen und mal mit der JMeter Gui und mal auf der Konsole mittels Jenkins laufen lassen. Hierbei unterscheiden sich die Urls, Userdaten und Laufzeiten des Tests. Wenn ich den Plan kopiert hätte, wäre die Wartung sehr aufwendig.

JMeter Properties

Es gibt bei JMeter die Möglichkeit eine Properties Datei für den Testplan anzugeben.

jmeter –p dev.properties –t testplan.jmx

In dieser Datei kann man beispielsweise die Domain definieren.

domain=example.com

Im Testplan kann man auf diesen Wert dann wie folgt zugreifen:

${__P(domain)}

Man kann auch einen Default Wert angeben.

${__P(domain,www.example.com)}

JMeter Funktionen

Mit dem JMeter Funktionen kann man noch einiges mehr machen. Beispielsweise: Daten aus einer CSV lesen oder Zufallszahlen verwendet.

http://jakarta.apache.org/jmeter/usermanual/functions.html

Im Hilfe Menü gibt es ein ganz praktisches Tool um mit den Funktionen zu arbeiten. Hierbei wird einem auch der richtige Code generiert.

Berechnungen

Es lassen sich auch Berechnungen durchführen. Diese werden mit der Javascript Funktion gemacht:

${__javaScript(${DURCHSATZ}/100*38.5)}

Wir hatten die Aufgabe für eine Webseite Lasttests zu erstellen. Die zu erzeugende Last sollte sehr real sein. Da man mit einen einzigen Rechner nicht so eine hohe Last erzeugen kann haben wir uns für die Amazon Cloud entschieden. Dort kann man für einen kurzen Zeitraum eine hohe Zahl an Rechnern verwenden und das mit sehr geringen Kosten.

Als Lasttest Tool wird JMeter verwendet. Mit JMeter kann man sehr granulare Testpläne erstellen und damit ein relativ gutes Abbild der realen Last simulieren.

http://jakarta.apache.org/jmeter/

JMeter ist in der Lage die Tests über verteilte Rechner auszuführen. Dadurch kann man eine sehr große Last erzeugen.

http://jakarta.apache.org/jmeter/usermanual/remote-test.html

JMeter ist in der Lage alle Anfragen über einen Proxy laufen zu lassen. So kann man IP geschützte Seiten testen indem man die IP vom Proxy freischaltet. In unseren Fall verwenden wir den Squid Proxy mit einer geschützten Authentifizierung.

Vorbereitung

Proxy Server AMI erstellen

In der Amazon Cloud gibt es sogenannte AMI (Amazon Machine Images). Das sind Abbildungen von Systemen die man erstellen kann um diese immer wieder zu verwenden.

AMI erstellen

AWS Management Console https://console.aws.amazon.com/ec2/ auf den Reiter ec2 wechseln und eine Instanz starten. Den  Rechner nach eigenen Wünschen anpassen und dann über das Menü „Instance Action“ eine AMI erstellen. Amazon erstellt dann von dem aktuellen System ein Abbild das man wiederverwenden kann.

Squid Proxy in der Cloud installieren:

http://home.engineering.iastate.edu/~hawklan/squidProxy/squidProxy.html

Dieser Proxy muss natürlich abgesichert werden, da er sonst missbraucht werden könnte.

Passwort Authentifizierung einrichten

In der Squid Konforgurations Datei (/etc/squid/squid.conf) muss als erstes das Authentifizierungs Programm eingestellt werden. Es gibt diverse Möglichkeiten. ncsa_auth ist wahrscheinlich die einfachste. Man erzeugt mit htpasswd eine Passwort Datei (/etc/squid/squid_user) und gibt diese in der Konfiguration an.

auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/squid_user

Der Proxy lässt sich damit nur noch mittels Usernamen und Passwort aufrufen.

Caching auschalten

Squid speichert die Anfragen normalerweise. Das würde aber das Ergebniss verfälschen. Deshalb muss man noch das Caching ausschalten. Dazu genügt es folgende Zeile in die Squid Konforgurations Datei (/etc/squid/squid.conf)  einzufügen.

cache deny all

Proxy automatisch starten

Damit der Proxy automatisch mit dem Starten der Instanz mit gestartet wird kann man in der Datei /etc/rc.local diesen Befehl eintragen /etc/init.d/squid start .

Proxy starten

In der AWS Management Console starten wir die vorgefertigte AMI.

JMeter Master Server

Für den JMeter Master Server verwenden wir einen vorgefertigte Windows AMI bei der JMeter vorinstalliert ist. Dieser Rechner kann dann über Remote Desktop bedient werden.

Auf den Master Server muss dann der Testplan kopiert werden.

Auf dem Master Server wird die Testausführung gesteuert.

JMeter Slaves

Die JMeter Slaves sind beliebig viele Linux Rechner auf denen der JMeter im Server Modus gestartet ist. Dafür benötigt man eine AMI auf der JMeter vorhanden ist und dieser Befehl Autostart (/etc/rc.local) ist

{pathtojmeter}/bin/jmeter-server

Dafür steht auch die öffentliche AMI zur Verfügung: ami-823f0df6

Die Adressen der Slave Rechner müssen in die JMeter Properties Datei auf den Master Server eingetragen werden. So das dieser seine Remote Maschinen kennt.

jmeter.properties

remote_hosts=...,....

Starten der Tests

Wenn die Slaves hochgefahren sind kann der Testplan auf den Remote Servern gestartet werden.

Die Selenium-RC Version 1.0.1 ist leider nicht kompatibel mit dem neuen Firefox 4.

Das Selenium Server Paket enthält einige Firefox Erweiterungen in denen eine maximale Kompatibilität zu Firefox 3.5 angegeben wurde. Diese Erweiterungen sind auch mit der Version 4 lauffähig, doch man muss die install.rdf Dateien anpassen.

Anleitung zum modifizieren des Selenium RC

1. Entpacke das Java Archiv selenium-server.jar
2. Suche alle Dateien mit dem Namen install.rdf in dem ausgepackten Verzeichnis.
3. Ändere in den Dateien den Wert <em:maxVersion>3.5.*</em:maxVersion> auf <em:maxVersion>4.*</em:maxVersion>
4. Erzeuge eine neue jar Datei
   1. Gehe in der Kommando Zeile in das ausgepackte Verzeichnis
   2. Stelle sicher dass das JDK im Pfad vorhanden ist.  (PATH=C:\Programme\Java\jdk1.6.0_18\bin)
   3. Erzeuge die neue Jar Datei: jar -cvfm selenium-server.jar META-INF/MANIFEST.MF *
5. Tausche die alte selenium-server.jar mit der neuen aus.

Bei der Erstellung der Codecoverage mit phpUnit bin ich schon mehrmals aus diesen PHP Fehler gestoßen:

PHP Fatal error:  Cannot redeclare class

Aus dem Code war kein Grund dafür ersichtlich da alle Dateien mit require_once eingebunden waren. Das Problem lag dabei in der Verwendung von Mock Klassen ohne diese vorher importiert zu haben.

Ich kann mit folgenden Code eine Object der Klasse Example erstellen ohne die original Klasse zu laden.

$object = $this->getMock ( 'Example', array (), array (), '', false );

Wenn danach die original Klasse Example importiert wird, ist diese schon deklariert und es kommt zu diesen Fehler. Abhilfe tut hier ein require_once im Test:

require_once('path/to/Example.php');
$object = $this->getMock ( 'Example', array (), array (), '', false );

Dann klappt es auch mit der Coverage Auswertung.

Der IETester ist ein praktisches Tool zum Testen einer Webseite in verschiedenen Internet Explorer Versionen. Ich habe bereits mit einigen Tools herum probiert aber keines was so unproblematisch und schnell zu bedienen wie der IETester.

Man startet nur ein einziges Tool und kann über Tabs die Seiten in verschiedenen Versionen testen. Das Tool lässt sich bedienen wie ein normaler Internet Explorer. Es hat Lesezeichen und die normalen Navigations-Funktionen.

Das Tool ist kostenlos und kann bei My DebugBar heruntergeladen werden.