JMeter

Aus THM-Wiki
Wechseln zu: Navigation, Suche

JMeter ist eine Java-Anwendung zur Durchführung von Lasttests für Client/Serversysteme mit Schwerpunkt auf webbasierende Systeme. Die dabei gewonnenen Daten ermöglichen Aussagen über das Antwort- und Antwortzeitverhalten unter Last, sowie generell über korrekte Funktionsweise der Anwendung.

JMeter ist Open Source und wurde von Stefano Mazzocchi entwickelt, um Lasttests für den Apache JServ (heute Apache Tomcat) durchzuführen. Später wurde JMeter vom Jarkarta Projekt weiterentwickelt - insbesondere die grafische Benutzeroberfläche und die Funktionstest wurden ergänzt. Das Jakarta Projekt erstellt Open-Source Lösungen auf Basis von Java und arbeitet unter der Schirmherrschaft der Apache Software Foundation (ASP). Weitere bekannte Projekte sind der Apache HTTP Server oder der Apache Tomcat.

JMeter kann Anfragen für eine Vielzahl von Systemen erzeugen, wie z.B. HTTP, HTTPS, FTP, SOAP, Java Servlets, CGI Scripts, JDBC (Java Database Connectivity)´, JNDI (Java Naming and Directory Interface), LDAP (Lightweight Directory Access Protocol), DNS (Domain Name System), NIS (Network Information Service), CORBA, Dateisysteme, etc.

Ein weiter Bestanteil des JMeter ist ein HTTP Proxy Server für Webanfragen. Wird dieser gestartet und von einem Webbrowser verwendet, können sämtliche Anfragen vom Proxy protokolliert und in einem Testplan gespeichert werden. So lassen sich sehr schnell auch umfangreichere Testpläne erstellen und echtes Anwenderverhalten kann simuliert werden.


Systemvoraussetzungen und Installation

JMeter benötigt Java Development Kit (JDK) in Verions 1.3 oder höher. Empfohlen ist allerdings eine Version 1.4 oder neuer, hier sind dann verschiedene Komponenten, wie die SSL Unterstützung bereits vorhanden und müssen nicht nachinstalliert werden.

Aufgrund der Java-Architektur funktioniert JMeter auf jedem Betriebssystem mit einer JVM. Es wurde unter folgenden Betriebssystemen getestet:

Unix (Solaris, Linux, etc) Windows (98, NT, 2000, XP) OpenVMS Alpha 7.3+

Source und Binarys können auf der Produkthomepage frei heruntergeladen werden: //jakarta.apache.org/jmeter/. Der Installationspfad sollte in einem Pfad ohne Leerzeichen erfolgen (also bei Windows zum Beispiel nicht in C:\PROGRAM FILES). Die grafische Oberfläche unterstützt neben Englisch auch Deutsch und weitere Sprachen. Dabei kann es bei Version 2.2 unter Windows zur Vermischung der Betriebssystemsprache und der eingestellten Sprache in der GUI kommen. Dies kann vermieden werden wenn sowohl Betriebssystem und GUI in Englisch verwendet werden. Der Programmaufruf erfolgt bei Windows über die JMETER.BAT, bei Linux über jmeter.

Testpläne

Innerhalb eines Testplans können Serveranfragen definiert und als Thread abgespielt werden. Durch gleichzeitiges mehrfaches Ausführen des Testplans und Wiederholungen kann auf einfache Weise Serverlast erzeugt werden. Durch gezielte Auswahl der Serveranfragen und Ihrer Reihenfolge können realitätsnahe Anwendungsfälle nachgestellt werden, wie etwa die Anmeldung an einem Webportal und der Aufruf bestimmter Webseiten.

Während der Ausführung eines Testplans sammelt JMeter eine Vielzahl von Daten, so können Auswertungen über das Antwortzeitverhalten des Servers unter Last durchgeführt werden. Dafür sind die so genannten Listener verantwortlich.

Über Eingabedateien lassen sich dynamische Testpläne erzeugen, die bei jeder Ausführung einen neuen Datensatz aus der Datei einlesen und die enthaltenen Werte in Variablen weiterverwenden können. So lässt sich beispielsweise eine Eingabedatei für Benutzerkennungen und Passwörter generieren, so dass jeder Thread eines Testplans unter einer anderen Benutzerkennung ausgeführt werden kann.

Die Testpläne sind hierarchisch aufgebaut und bestehen aus unterschiedlichen Funktionselementen, für die jeweils Konfigurationseinstellungen möglich sind. Folgende Funktionselemente stehen zur Verfügung: Controller, Sampler, Logical Controller, Listener („Lauscher“), Timer, Assertions, Configuration Elements, Pre-Processor Elements und Post-Processor Elements.


Thread Groups

Auf oberster Ebene, unterhalb des Testplans, befinden sich die Thread Groups. Über deren Einstellungen wird insbesondere festgelegt, wie viele Threads insgesamt laufen sollen, in welchen Zeitabständen diese gestartet werden und wie oft die Threads wiederholt werden. Ein Paramter ist die Ramp-up Period. Er legt fest wie lange es dauert, bis alle Threads gestartet werden. Bei einer Zahl von 10 Threads und einer Ramp-up Period von 5 würde demnach alle 5 Sekunden ein neuer Thread gestartet. So kann eine zu große Last zu beginn des Tests vermieden werden. Ein guter Initialwert für die Ramp-up Period ist die Anzahl der Threads (jede Sekunde wird ein Thread gestartet). Mit der Funktion Scheduler kann die Teststart- und Testendzeit genau abgestimmt werden.


Controller

Controller unterteilen sich in Sampler und Logical Controller. Die Sampler stellen die eigentlichen Serveranfragen dar (Requests), z.B. per HTTP, FTP, JDBC, LDAP, SOAP, usw. Für jede Art von Requests stehen unfangreiche Konfigurationseinstellungen zur Verfügung. Logik-Controller gruppieren die Request-Definitionen logisch und binden ihre Ausführung an bestimmte Bedingungen. Damit lassen sich im Testskript Kontrollflusskonstrukte definieren, die aus den Programmiersprachen bekannt sind, wie z.b. for, while, oder if Konstrukte. So kann ein Login-Request an einen OnlyOnce-Controller gehängt werden, um sicher zu gehen, dass dieser Request sinnvollerweise nur einmal während des Testlaufs ausgeführt wird. Der Recording Controller spielt eine besondere Rolle beim Aufzeichnen von Anfragen über einen HTTP Proxy Server.

Listener

Listener dienen der Präsentation der Testergebnisse. Sie können an ein beliebiges Element des Testskriptes angehängt werden und reagieren auf das Antwortzeitverhalten der Anwendung unter Test, indem sie die Antwortzeit protokolieren und sie graphisch oder maschinenlesbar (Tabellen/XML) aufbereiten. Grundsätzlich können Listener die Testergebnisse in eine angegebene Datei umleiten. Listener können z.B. dafür verwendet werden, um ein Diagramm der Performance darstellen, wo durchschnittliche Antwortzeiten und große Abweichungen dargestellt werden, oder eine Zusammenfassung der Testergebnisse erstellen. Viele Listener werden von JMeter bereitgestellt, andere können als Erweiterungen hinzugefügt werden. Es existieren Listener die Informationen in Form von Graphen darstellen, wie Aggregate Graph oder Graph Result. Der View Results Tree zeigt jede gesendete Anfrage und die Antwort des Servers an. Handelt es sich bei der Antwort zum Beispiel um HTTP-Quellcode, kann zusätzlich auch gleich die interpretierte Webseite angezeigt werden. Mit den Assertion Results können die Ergebnisse von Assertions (Prüfungen) ausgewertet werden.


Timer

Timer ermöglichen es Wartezeiten zwischen zwei Anfragen zu definieren. So lässt sich realistisches Benutzerverhalten simulieren, da zwischen mehreren Anfragen meist eine gewisse Bedenkzeit des Anwenders, zum Beispiel zum Lesen eines angezeigten Textes, zu erwarten ist. Es existieren unterschiedliche Timer, wie der Constant oder der Random Timer.


Assertions

Die Assertions (Zusicherungen) werden dafür eingesetzt, um einen bestimmten erwarteten Zustand der zu testenden Anwendung zu definieren. Eine Zusicherung wird gebrochen, wenn dieser Zustand von dem Erwartungswert an der definierten Stelle abweicht. (Vgl. JUnit assert...-Funktionen.) Mit Zusicherungen kann also die Funktionalität der zu testenden Anwendung geprüft werden. JMeter sichert Daten auf der Request/Response-Ebene zu. So kann ein Wert in einem HTTP-Response als Voraussetzung für eine fehlerfreie Ausführung der Anwendung definiert werden. Stimmt der tatsächliche Wert während der Ausführung nicht mit dem Erwartungswert überein, dann wird ein Fehler gemeldet. Unter anderem können Antwortcodes abgefragt werden oder das Vorhandensein bestimmter Textmuster. So wird eine erfolgreiche Antwort einer HTTP-Anfrage beispielsweise mit dem Code 200 dargestellt (RFC2616). Mit Hilfe des Listeners "Assertion Results" wird die Assertion ausgewertet.


Konfigurationselemente (Configuration Elements)

Konfigurationselemente beziehen sich auf Sampler auf gleicher oder untergeordneter Ebene. Sie stellen erweitere Konfiguraitonsoptionen zur Verfügung, führen aber selbst keine Serveranfragen aus. Ein wichtiges Konfigurationselement ist der HTTP Cookie Manager, der einer Serveranwendung ermöglicht Cookies zu speichern und wieder zu lesen. Viele Anwendungen sind ohne diese Funktionen gar nicht lauffähig. Platziert man den HTTP Cookie Manager direkt unterhalb einer Thread Group kann er von allen Anfragen innhalb der Gruppe verwendet werden. Ebenfalls sinvoll ist die Verwendung eines 'HTTP Request Defaults'. Dieser erlaut es unter anderem Servername und Port für HTTP Requests anzugeben. So kann ein Testplan auf dem Server des "localhost" erstellt und später einfach auf einen Server im Netzwerk geändert werden, ohne jede einzelne Anfrage bearbeiten zu müssen. An dieser Stelle existiert ein interessanter Design-Fehler. Zwar kann man auch den Server-Pfad in den Default-Einstellungen festlegen, dieser vererbt sich jeder (wie die anderen Felder auch) nur dann, wenn das Feld bei den Anfragen leer ist. Da der Pfad aber auch die aufzurufende Seite beinhaltet, kann das Feld aber nie leer sein. Abhilfe schafft eine Benutzerdefinierte Variable PATH die man auf Ebene des Testplans erstellen kann und die über ${PATH} jeder Anfrage hinzugefügt werden kann. Zuletzt soll noch das CSV Data Set Config erwähnt werden, das für das Erstellen von dynamischen Testplänen erforderlich ist. Mit diesem Konfigurationselement lässt sich eine Eingabedatei im CSV-Format angeben.

HTTP Proxy Server (Aufzeichnen von HTTP Anfragen)

Bei umfangreichen Testszenarien kann die manuelle Erstellung der Testpläne schnell sehr aufwändig werden. Ein mächtiges Werkzeug dies zu vereinfachen, stellt die Proxy-Funktionalität von JMeter dar. Sie erlaubt die Aufzeichnung von Serveranfragen, aus der direkt ein Testplan erstellt werden kann. Dazu ist zunächst unterhalb der Workbench ein neues Non Test Element zu erzeugen: ein HTTP Proxy Server. In den Einstellungen des Proxy wählt man einen freien Port, zum Beispiel 9999. Nun kann man den Proxy Server in einem Webbrowser unter Angabe des Servernamens (localhost) und des Ports (9999) zu konfigurieren. Die genauen Einstellungen sind browserabhängig. Befindet sich die zu testende Anwendung auf dem lokalen Rechner ist darauf zu achten, dass der Proxy für localhost nicht umgangen wird.

Da die Aufzeichnung umfangreicher Tests schnell unübersichtlich werden kann, empfiehlt es sich Grafiken und Stylesheets auszufiltern (nicht mit aufzuzeichnen). Dazu können in den Proxyeinstellungen Filter mit Hilfe von Regulären Ausdrücken definiert werden. Das folgende Beispiel filtert Stylesheets und verschiedene Grafikformate:

.\.css
.\.gif
.\.jpg
.\.jpeg
.\.gif

Ein Uniform Random Timer unterhalb des Proxy erlaubt das Aufzeichnen von Wartezeiten. Dazu muss der Maximum Milliseconds Count mit der JMeter-Variable ${T} ersetzt werden.

Im Testplan muss nun noch ein Recording Controller' eingefügt werden. Hier erscheinen die aufgezeichneten Anfragen. Nun kann der Proxy gestartet und die Tests mit dem Webbrowser können aufgezeichnet werden.

Leider unterstützt der Proxy keine Aufzeichnung von HTTPS-Anfragen. Auf Grund der Verschlüsselung ist es schon technisch nicht möglich SSL-Anfragen auszulesen. Unterstützt der zu testende Server sowohl HTTP als auch HTTPS, so kann man ohne SSL aufzeichnen und später das Protokoll auf HTTPS und den Port auf 443 ändern.

Zuletzt noch ein Tipp: die Elemente in der Workbench werden nicht mit dem Testplan gespeichert, sondern beim Beenden von JMeter verworfen. Nach erstellen eines HTTP Proxy Server Elementes kann dieses jedoch in den Testplan verschoben werden. Dies ist besonders dann sinnvoll, wenn detaillierte Filter eingestellt worden sind, und wenn man die Aufzeichnung des Tests noch einmal wiederholen muss.

Tests mit dynamischen Daten

Die Thread Group erlaubt das gleichzeitige Ausführen mehrerer Test-Threads. Die einzelnen Anfragen können mit Logical Controllers gesteuert werden, was eine gewisse Dynamik in der Abfolge erlaubt. Die Daten, die mit den einzelnen Serveranfragen gesendet werden sind jedoch statisch. Häufig möchte man aber, dass jeder Thread mit individuellen Daten arbeiten kann, beispielsweise wenn eine Benutzeranmeldung durchgeführt wird und sich jeder Thread mit einem anderen Benutzer anmelden soll. Zu diesem Zweck kann JMeter Datensätze aus einer bereitgestellten CSV-Datei auslesen und in den Anfragen dynamisch verwenden. Dies soll am Beispiel einer Eingabedatei für Benutzeranmeldedaten erklärt werden. Zunächst muss die CSV-Datei erstellt werden:

thheil,password1
sschind,password2
shenni,password3
smeyer,pferdi

Dann zeichnet man, wie unter Aufzeichnung von HTTP Anfragen beschrieben, die Benutzeranmeldung am Webserver, sowie die einzelnen Aktionen auf. Ist die Aufzeichnung beendet fügt man unterhalb des Recording Controllres ein CSV Data Set Config Konfigurationselement ein. Hier kann der Name der CSV-Datei und das Format der Datensätze angegeben werden (hier: USER,PASS).

Abbildung 1: CSV Data Set Config



Nun sucht man sich den HTTP Request der für die Anmeldung am Server verantwortlich ist. Mann ersetzt den Benutzernamen und das Passwort, dass man während der Aufzeichnung verwendet hat durch die entsprechenden Variablen:

${USER}
${PASS}

Zuletzt sollte man dem Testplan geeignete Listener hinzufügen, um die Ergebnisse des dynamischen Tests auswerten zu können, wie einen View Results Tree oder einen Summary Report.

Abbildung 2: Testplan mit dynamischen Daten


Testerstellung Schritt für Schritt

Um einen ersten Testskript zu erzeugen gehen Sie die folgenden Schritte durch:

Benutzer hinzufügen

Fügen Sie eine Threadgruppe als Knoten direkt unter dem Testplan-Knoten ein. Eine Threadgruppe beschreibt im Testskript eine Menge von Benutzern, die parallel Requests an das zu testende System schicken. Stellen Sie in den Eigenschaften des neuen Knotens die Anzahl der Benutzer/Threads, die Anzahl der Wiederholungen des Testfalls und die Zeit, die zwischen dem Starten einzelner Threads vergehen soll, ein. Ändern Sie den Namen der Threadgruppe auf einen sprechenden Namen, der zum geplanten Testfall passt.

Globale Request-Eigenschaften angeben

Fügen Sie jetzt einen HTTP-Request Defaults Knoten als Kind des Threadguppenknoten ein. Die Einstellungen, die in diesem neuen Knoten gesetzt werden, beeinflussen somit alle Requests unterhalb des Threadgruppenknoten. In den Eigenschaften des neuen Knoten legen Sie die Adresse des Servers, auf dem die zu testenden Anwendung liegt, fest. (z.B. localhost.) Die restlichen Felder sinf requestspezifisch. Lassen Sie sie deshalb an dieser Stelle leer.

Cookies-Unterstützung hinzufügen

Die meisten Anwendungen setzen Cookie-Unterstützung des Clients voraus. Die J2EE Servlet Spezifikation benutzt Cookies standardmäßig als Mittel für die Realisierung des Session-Konzeptes. Erzeugen Sie deshalb noch ein Kind des Threadgruppenknoten - diesmal das Konfigurationselement HTTP Cookie Manager.

Requests definieren

Als Nächstes sollen die eigentlichen Requests an den Server definiert werden. Für jeden Request, den Sie erstellen wollen, legen Sie einen Sampler->HTTP Request Kindknoten direkt unterhalb des Threadgruppenknoten an. In den Eigenschaften des Requestknoten geben Sie Portnummer, Protokoll, Requestmethode (Get/Post...), und die Requestargumente an. Außerdem definieren Sie hier die URI der angeforderten Ressource. Die Serveradresse brauchen Sie hier nicht einzugeben, weil Sie sie in den globalen Requesteinstellungen bereits gemacht haben. (Sollten Sie die Adresse doch eingeben, dann wird der globale Wert mit dem lokalen überschrieben.)

Listener anschliessen

Um die Testergebnisse einsehen zu können, müssen Sie Ihrem Testskript einen (oder mehrere) Listener hinzufügen. Listener geben die Testergebnisse grafisch oder tabellarisch aus. Fügen Sie Ihrer Threadgruppe noch einen Kindknoten hinzu - den Graph Results Listener. Damit werden die Reaktionszeiten des Servers in einem grafischen Diagramm dargestellt. In den Eigenschaften des Listeners kann der Name der Datei definiert werden, in welche die Ergebnisse umgeleitet werden sollen.

Testskript speichern und ausführen

Damit ist die Testerstellung abgeschlossen. Jetzt kann der Testskript gespeichert und ausgeführt werden. Die Ausführung erfolgt über die Tastenkombination Ctrl+R

Erweiterungsmöglichkeiten

JMeter lässt sich relativ leicht erweitern. Erweiterungen funktionieren auf dem Prinzip der Addons. Die Quelltexte der Erweiterungsklassen werden in dem Ordner addons abgelegt. Mit der Ant-Build-Datei addons.xml werden die Quelltexte übersetzt, verpackt und JMeter hinzugefügt. Beim nächsten Start lädt JMeter die so entstandene ApacheJMeter_addons.jar Bibliothek direkt nach dem Laden der Startklasse und macht so die Erweiterungen verfügbar.

Eigene Sampler

Als Beispiel soll hier die Erstellung eines einfachen benutzerspezifischen Samplers demonstriert werden. Dazu wird eine neue Klasse von der JMeter Klasse AbstractSampler abgeleitet und die Methode sample implementiert. Der Code des Beispielsamplers sieht folgendermaßen aus:

import java.io.Serializable;
import org.apache.jmeter.samplers.AbstractSampler;
import org.apache.jmeter.samplers.Entry;
import org.apache.jmeter.samplers.SampleResult;

public class HelloSampler extends AbstractSampler 
  implements Serializable 
{

  private static final long serialVersionUID = 1L;
  public static final String TO_GREET="HelloSampler.ToGreet";

  public HelloSampler() 
  {
    super();
  }

  public SampleResult sample(Entry e) 
  { 
    SampleResult res = new SampleResult(); 
    res.sampleStart();	
    String hello = "Hello "
        +this.getPropertyAsString(TO_GREET)+"!";

    res.setDataType(SampleResult.TEXT);
    res.setResponseData(hello.getBytes());	
    res.setSampleLabel(hello);
    res.setSuccessful(true);	
    try 
    {
      Thread.sleep(2000);
    } 
    catch (InterruptedException e1) 
    {	
      e1.printStackTrace();	
    }	
    res.sampleEnd();	
    return res;	
  }
}

Die Methode sample liest den zu begrüßenden Namen aus der Property TO_GREET aus und erstellt einen Begrüßungstext. Dieser Text wird dem Ergebnisobjekt res vom Typ SampleResult hinzugefügt. Der sample-Vorgang wird von den Methoden res.sampleStart(); und res.sampleEnd(); umrahmt, um die Dauer des Vorgangs im res-Objekt festzuhalten. In diesem Beispiel wird der Sampler-Thread für zwei Sekunden in den Schlafzustand versetzt, um Bearbeitungszeit zu simulieren.

Eigene GUIs für Parametereingabe

Um den oben erstellten Sampler in die JMeter Oberfläche einzubinden und eine bequeme Möglichkeit der Sampler-Parametereingabe zu bieten, soll nun eine Sampler-GUI erstellt werden. Dazu erweitern wir die Klasse AbstractSamplerGui und implementieren die Methoden createTestElement,configure,modifyTestElement und getLabelResource:

import java.awt.BorderLayout;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JTextField;
import org.apache.jmeter.gui.util.VerticalPanel;
import org.apache.jmeter.samplers.gui.AbstractSamplerGui;
import org.apache.jmeter.testelement.TestElement;

public class HelloSamplerGui extends AbstractSamplerGui 
{
  private static final long serialVersionUID = 1L;
  private JTextField txtToGreet;
  public HelloSamplerGui() 
  { 
    super();
    setLayout(new BorderLayout(0,5));
    setBorder(makeBorder());
    add(makeTitlePanel(), BorderLayout.NORTH);
    JLabel label = new JLabel("To greet");
    txtToGreet = new JTextField(10);
    label.setLabelFor(txtToGreet);
    JPanel paramsPanel = new JPanel(new BorderLayout(5, 0));
    paramsPanel.add(label, BorderLayout.WEST);
    paramsPanel.add(txtToGreet, BorderLayout.CENTER);
    VerticalPanel mainPanel = new VerticalPanel();
    mainPanel.add(paramsPanel);
    add(mainPanel, BorderLayout.CENTER);
  }

  public TestElement createTestElement() 
  {
    HelloSampler sampler = new HelloSampler();
    modifyTestElement(sampler);
    return sampler;
  }

  public void configure(TestElement element) 
  {
    super.configure(element);	 
    txtToGreet.setText(
        element.getPropertyAsString(HelloSampler.TO_GREET));
  }

  public void modifyTestElement(TestElement element) 
  {
    configureTestElement(element);
    element.setProperty(HelloSampler.TO_GREET,
        txtToGreet.getText());
  }

  public String getLabelResource() 
  {
    return "BEGRUESSER REQUEST";
  }
}

createTestElement erstellt einen neuen Sampler. getLabelResource definiert den Namen, unter welchem der Sampler in der JMeter Oberfläche gefunden werden kann. modifyTestElement schreibt den in die GUI des Samplers eingetragenen Wert in die entsprechende Eigenschaft des Samplers. configure implementiert die umgekehrte Übergabe des Wertes.

Eigene Listener

Wir wollen die Testergebnisse des HelloSampler nun mit Hilfe eines Listener ausgeben. Dafür erstellen wir einen eigenen Listener, der die Antworttexte und die Bearbeitungszeit des Samplers ausgibt. Wie gewohnt erweitern wir dafür eine abstrakte Klasse des JMeter. (Diesmal die Klasse AbstractVisualizer.) Der Quellcode des neuen Listeners sieht folgendermaßen aus.

import java.awt.BorderLayout;
import javax.swing.BorderFactory;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
import org.apache.jmeter.samplers.Clearable;
import org.apache.jmeter.samplers.SampleResult;
import org.apache.jmeter.visualizers.gui.AbstractVisualizer;

public class SimplestVisualizer extends AbstractVisualizer 
implements Clearable
{
  private static final long serialVersionUID = 1L;
  private JScrollPane scrollPanel = null;
  private JTextArea textArea = null;
  private int sampleNo = 0;
  
  public SimplestVisualizer()
  {
    super();
    init();
  }

  public String getLabelResource()
  {
    return "SIMPLEST VISUALIZER";
  }

  private void init()
  {
    setLayout(new BorderLayout());
    setBorder(makeBorder());
    add(makeTitlePanel(), BorderLayout.NORTH);
    textArea = new JTextArea();
    textArea.setEditable(false);
    textArea.setLineWrap(true);
    textArea.setWrapStyleWord(true);
    scrollPanel = makeScrollPane(textArea);
    scrollPanel.setViewportBorder(
        BorderFactory.createEmptyBorder(2, 2, 2, 2));

    add(scrollPanel);
  }

  public void add(SampleResult res)
  {
    sampleNo++;
    textArea.append(sampleNo+";"
        +res.getSampleLabel()+";"
        +res.getTime()+" Millis.");
    textArea.append("\n");
  }

  public synchronized void clear()
  {
    textArea.setText("");
    sampleNo = 0;
    scrollPanel.revalidate();
    scrollPanel.repaint();
  }
}

In der Methode init wird der Listener initialisiert und die Oberfläche für die Ausgabe der Testergebnisse erstellt. Die Methode add gibt jedes Testergebnis aus, indem sie den Ergebnistext und die Bearbeitungszeit aus dem SampleResult-Objekt ausliest. clear löscht die Darstelllung aller Ergebnisse.

Präsentation und Beispieldateien

Präsentationsunterlagen und Beispieldateien

Quellen für diesen Artikel

JMeter Homepage [Zugriff am 16.1.06]

JMeter User Manual [Zugriff am 16.1.06]

Artikel auf informit.com "Introduction to JMeter" [7.7.06]

"JMeter" auf Wikipedia [19.12.06]

"JMeter" auf Wikipedia (englisch) [2.12.06]

Martin Heider, JMeter: Last- und Stresstests mit Open Source - Java Magazin 8.05