3. Elemente eines Testplans

3.0 Testplan ¶

Das Testplan-Objekt hat ein Kontrollkästchen namens „ Functional Testing “. Wenn diese Option ausgewählt ist, zeichnet JMeter die vom Server zurückgegebenen Daten für jede Probe auf. Wenn Sie in Ihren Testlistenern eine Datei ausgewählt haben, werden diese Daten in die Datei geschrieben. Dies kann nützlich sein, wenn Sie einen kleinen Lauf durchführen, um sicherzustellen, dass JMeter richtig konfiguriert ist und Ihr Server die erwarteten Ergebnisse zurückgibt. Die Folge ist, dass die Datei schnell riesig wird und die Leistung von JMeter darunter leidet. Diese Option sollte deaktiviert sein, wenn Sie Stresstests durchführen (sie ist standardmäßig deaktiviert).

Wenn Sie die Daten nicht in einer Datei aufzeichnen, spielt diese Option keine Rolle.

Sie können auch die Schaltfläche Konfiguration auf einem Listener verwenden, um zu entscheiden, welche Felder gespeichert werden sollen.

3.1 Themengruppe ¶

Thread-Gruppenelemente sind die Ausgangspunkte eines jeden Testplans. Alle Controller und Sampler müssen sich in einer Thread-Gruppe befinden. Andere Elemente, z. B. Listener, können direkt unter dem Testplan platziert werden, in diesem Fall gelten sie für alle Thread-Gruppen. Wie der Name schon sagt, steuert das Thread-Gruppenelement die Anzahl der Threads, die JMeter verwendet, um Ihren Test auszuführen. Mit den Steuerelementen für eine Thread-Gruppe können Sie:

• Stellen Sie die Anzahl der Threads ein
• Stellen Sie die Hochlaufzeit ein
• Legen Sie fest, wie oft der Test ausgeführt werden soll

Jeder Thread führt den Testplan in seiner Gesamtheit und vollständig unabhängig von anderen Test-Threads aus. Mehrere Threads werden verwendet, um gleichzeitige Verbindungen zu Ihrer Serveranwendung zu simulieren.

Die Ramp-up-Periode teilt JMeter mit, wie lange es dauern soll, bis die volle Anzahl der ausgewählten Threads "ramp-up" ist. Wenn 10 Threads verwendet werden und die Hochlaufzeit 100 Sekunden beträgt, benötigt JMeter 100 Sekunden, um alle 10 Threads zum Laufen zu bringen. Jeder Thread beginnt 10 (100/10) Sekunden, nachdem der vorherige Thread gestartet wurde. Wenn es 30 Threads und eine Hochlaufzeit von 120 Sekunden gibt, wird jeder nachfolgende Thread um 4 Sekunden verzögert.

Das Ramp-up muss lang genug sein, um eine zu große Arbeitsbelastung zu Beginn eines Tests zu vermeiden, und kurz genug, dass die letzten Threads zu laufen beginnen, bevor die ersten fertig sind (es sei denn, man möchte, dass dies geschieht).

Beginnen Sie mit Ramp-up = Anzahl der Threads und passen Sie nach Bedarf nach oben oder unten an.

Standardmäßig ist die Thread-Gruppe so konfiguriert, dass sie ihre Elemente einmal durchläuft.

Die Thread-Gruppe ermöglicht auch die Angabe der Thread-Lebensdauer . Klicken Sie auf das Kontrollkästchen unten im Bereich „Thread-Gruppe“, um zusätzliche Felder zu aktivieren/deaktivieren, in die Sie die Dauer des Tests und die Startverzögerung eingeben können. Sie können Dauer (Sekunden) und Startverzögerung (Sekunden) konfigurieren , um die Dauer jedes Threads zu steuern Gruppe und nach wie viel Sekunden es startet. Wenn der Test gestartet wird, wartet JMeter eine Startverzögerung (Sekunden) , bevor die Threads der Thread-Gruppe gestartet und für die konfigurierte Dauer (Sekunden) ausgeführt werden.

3.2 Controller ¶

JMeter hat zwei Arten von Controllern: Sampler und logische Controller. Diese steuern die Verarbeitung eines Tests.

Sampler weisen JMeter an, Anfragen an einen Server zu senden. Fügen Sie beispielsweise einen HTTP-Request-Sampler hinzu, wenn Sie möchten, dass JMeter eine HTTP-Anfrage sendet. Sie können eine Anfrage auch anpassen, indem Sie einem Sampler ein oder mehrere Konfigurationselemente hinzufügen. Weitere Informationen finden Sie unter Sampler .

Mit logischen Controllern können Sie die Logik anpassen, die JMeter verwendet, um zu entscheiden, wann Anfragen gesendet werden. Sie können beispielsweise einen Interleave Logic Controller hinzufügen, um zwischen zwei HTTP-Request-Samplern zu wechseln. Weitere Informationen finden Sie unter Logische Controller .

3.2.1 Sampler ¶

Sampler weisen JMeter an, Anfragen an einen Server zu senden und auf eine Antwort zu warten. Sie werden in der Reihenfolge verarbeitet, in der sie im Baum erscheinen. Controller können verwendet werden, um die Anzahl der Wiederholungen eines Samplers zu ändern.

Zu den JMeter-Samplern gehören:

• FTP-Anfrage
• HTTP Request (kann auch für SOAP oder REST Webservice verwendet werden)
• JDBC-Anfrage
• Java-Objektanforderung
• JMS-Anfrage
• JUnit-Testanforderung
• LDAP-Anfrage
• Mailanfrage
• Betriebssystem Prozessanforderung
• TCP-Anfrage

Wenn Sie mehrere Anforderungen desselben Typs (z. B. HTTP-Anforderung) an denselben Server senden, sollten Sie die Verwendung eines Standardkonfigurationselements in Erwägung ziehen. Jeder Controller hat ein oder mehrere Defaults-Elemente (siehe unten).

Denken Sie daran, Ihrem Testplan einen Listener hinzuzufügen, um die Ergebnisse Ihrer Anfragen auf der Festplatte anzuzeigen und/oder zu speichern.

Wenn Sie daran interessiert sind, dass JMeter eine grundlegende Validierung der Antwort auf Ihre Anfrage durchführt, fügen Sie dem Sampler eine Assertion hinzu. Beim Belastungstest einer Webanwendung kann der Server beispielsweise einen erfolgreichen „HTTP-Antwort“-Code zurückgeben, aber die Seite kann Fehler enthalten oder Abschnitte fehlen. Sie könnten Zusicherungen hinzufügen, um nach bestimmten HTML-Tags, allgemeinen Fehlerzeichenfolgen usw. zu suchen. Mit JMeter können Sie diese Behauptungen mithilfe regulärer Ausdrücke erstellen.

Die integrierten Sampler von JMeter

3.2.2 Logik-Controller ¶

Mit Logic Controllern können Sie die Logik anpassen, die JMeter verwendet, um zu entscheiden, wann Anfragen gesendet werden. Logik-Controller können die Reihenfolge der Anforderungen ändern, die von ihren untergeordneten Elementen kommen. Sie können die Anfragen selbst ändern, JMeter veranlassen, Anfragen zu wiederholen usw.

Um die Auswirkung von Logik-Controllern auf einen Testplan zu verstehen, betrachten Sie den folgenden Testbaum:

• Versuchsplan
• Themengruppe
• Einmaliger Controller
• Anmeldeanfrage (eine HTTP-Anfrage )
• Suchseite laden (HTTP Sampler)
• Interleave-Controller
• Suche "A" (HTTP-Sampler)
• Suche "B" (HTTP-Sampler)
• HTTP-Standardanforderung (Konfigurationselement)
• HTTP-Standardanforderung (Konfigurationselement)
• Cookie-Manager (Konfigurationselement)

Das Erste an diesem Test ist, dass die Anmeldeanforderung nur beim ersten Mal ausgeführt wird. Nachfolgende Iterationen werden es überspringen. Dies liegt an den Effekten des Once Only Controllers .

Nach der Anmeldung lädt der nächste Sampler die Suchseite (stellen Sie sich eine Webanwendung vor, bei der sich der Benutzer anmeldet und dann zu einer Suchseite geht, um eine Suche durchzuführen). Dies ist nur eine einfache Anforderung, die nicht durch einen Logic Controller gefiltert wird.

Nach dem Laden der Suchseite wollen wir eine Suche durchführen. Eigentlich wollen wir zwei verschiedene Suchen durchführen. Wir möchten jedoch die Suchseite selbst zwischen jeder Suche neu laden. Wir könnten dies tun, indem wir 4 einfache HTTP-Anforderungselemente haben (Suche laden, Suche "A", Suche laden, Suche "B"). Stattdessen verwenden wir den Interleave Controller , der jedes Mal durch den Test eine untergeordnete Anfrage weiterleitet. Es behält die Reihenfolge seiner untergeordneten Elemente bei (dh es gibt keines zufällig weiter, sondern "merkt sich" seinen Platz). Das Verschachteln von 2 untergeordneten Anforderungen kann übertrieben sein, aber es könnten leicht 8 oder 20 untergeordnete Anforderungen vorhanden sein.

Beachten Sie die Standardeinstellungen für HTTP-Anforderungendas gehört zum Interleave Controller. Stellen Sie sich vor, dass „Suche A“ und „Suche B“ dieselben PATH-Informationen teilen (eine HTTP-Anforderungsspezifikation umfasst Domäne, Port, Methode, Protokoll, Pfad und Argumente sowie andere optionale Elemente). Das macht Sinn - beides sind Suchanfragen, die dieselbe Back-End-Suchmaschine treffen (sagen wir ein Servlet oder ein CGI-Skript). Anstatt beide HTTP-Sampler mit denselben Informationen in ihrem PATH-Feld zu konfigurieren, können wir diese Informationen zu einem einzigen Konfigurationselement abstrahieren. Wenn der Interleave-Controller Anforderungen von „Suche A“ oder „Suche B“ „weiterleitet“, füllt er die Lücken mit Werten aus dem HTTP-Standardanforderungs-Konfigurationselement. Also lassen wir das PATH-Feld für diese Anfragen leer, und fügen Sie diese Informationen in das Konfigurationselement ein. In diesem Fall ist dies bestenfalls ein kleiner Vorteil, aber es demonstriert die Funktion.

Das nächste Element im Baum ist eine weitere HTTP-Standardanforderung, die diesmal der Thread-Gruppe selbst hinzugefügt wurde. Die Thread-Gruppe hat einen eingebauten logischen Controller und verwendet daher dieses Konfigurationselement genau wie oben beschrieben. Es füllt die Lücken jeder durchlaufenden Anfrage aus. Beim Webtesten ist es äußerst nützlich, das DOMAIN-Feld in allen Ihren HTTP-Sampler-Elementen leer zu lassen und diese Informationen stattdessen in ein HTTP-Standardanforderungselement einzufügen, das der Thread-Gruppe hinzugefügt wird. Auf diese Weise können Sie Ihre Anwendung auf einem anderen Server testen, indem Sie einfach ein Feld in Ihrem Testplan ändern. Andernfalls müssten Sie jeden einzelnen Sampler bearbeiten.

Das letzte Element ist ein HTTP-Cookie-Manager . Allen Webtests sollte ein Cookie-Manager hinzugefügt werden – sonst ignoriert JMeter Cookies. Indem wir es auf Thread-Gruppenebene hinzufügen, stellen wir sicher, dass alle HTTP-Anforderungen dieselben Cookies teilen.

Logiksteuerungen können kombiniert werden, um verschiedene Ergebnisse zu erzielen. Sehen Sie sich die Liste der integrierten Logic Controller an .

3.2.3 Testfragmente ¶

Das Testfragment-Element ist ein spezieller Controller -Typ, der sich in der Testplanstruktur auf derselben Ebene wie das Thread-Gruppenelement befindet. Sie unterscheidet sich von einer Thread-Gruppe dadurch, dass sie nicht ausgeführt wird, es sei denn, sie wird von einem Module Controller oder einem Include_Controller referenziert .

Dieses Element dient ausschließlich der Wiederverwendung von Code in Testplänen

3.3 Zuhörer ¶

Listener bieten Zugriff auf die Informationen, die JMeter über die Testfälle sammelt, während JMeter läuft. Der Listener „ Graph Results “ zeichnet die Antwortzeiten in einem Diagramm auf. Der Listener „View Results Tree“ zeigt Details von Sampler-Anforderungen und -Antworten und kann grundlegende HTML- und XML-Darstellungen der Antwort anzeigen. Andere Listener stellen zusammenfassende oder aggregierte Informationen bereit.

Darüber hinaus können Zuhörer die Daten zur späteren Verwendung in eine Datei leiten. Jeder Listener in JMeter stellt ein Feld bereit, um die Datei anzugeben, in der Daten gespeichert werden sollen. Es gibt auch eine Konfigurationsschaltfläche, mit der Sie auswählen können, welche Felder gespeichert werden sollen und ob das CSV- oder XML-Format verwendet werden soll.

Zuhörer können überall im Test hinzugefügt werden, auch direkt unter dem Testplan. Sie sammeln nur Daten von Elementen auf oder unter ihrer Ebene.

Es gibt mehrere Listener , die mit JMeter geliefert werden.

3.4 Timer ¶

Standardmäßig führt ein JMeter-Thread Sampler nacheinander ohne Pause aus. Wir empfehlen, dass Sie eine Verzögerung angeben, indem Sie Ihrer Thread-Gruppe einen der verfügbaren Timer hinzufügen. Wenn Sie keine Verzögerung hinzufügen, könnte JMeter Ihren Server überlasten, indem es in sehr kurzer Zeit zu viele Anfragen stellt.

Ein Timer bewirkt, dass JMeter vor jedem Sampler, der sich in seinem Gültigkeitsbereich befindet , eine bestimmte Zeitspanne verzögert .

Wenn Sie mehr als einen Timer zu einer Thread-Gruppe hinzufügen, nimmt JMeter die Summe der Timer und pausiert für diesen Zeitraum, bevor die Sampler ausgeführt werden, für die die Timer gelten. Timer können als Kinder von Samplern oder Controllern hinzugefügt werden, um die Sampler einzuschränken, auf die sie angewendet werden.

Um an einer einzelnen Stelle in einem Testplan eine Pause zu machen, kann man den Flow Control Action Sampler verwenden.

3.5 Behauptungen ¶

Behauptungen ermöglichen es Ihnen, Fakten über Antworten zu behaupten, die Sie vom getesteten Server erhalten haben. Mit einer Assertion können Sie im Wesentlichen „testen“, ob Ihre Anwendung die erwarteten Ergebnisse zurückgibt.

Sie können beispielsweise behaupten, dass die Antwort auf eine Anfrage einen bestimmten Text enthält. Der von Ihnen angegebene Text kann ein regulärer Ausdruck im Perl-Stil sein, und Sie können angeben, dass die Antwort den Text enthalten oder mit der gesamten Antwort übereinstimmen soll.

Sie können jedem Sampler eine Behauptung hinzufügen. Beispielsweise können Sie einer HTTP-Anfrage eine Assertion hinzufügen, die den Text " </HTML> " prüft. JMeter prüft dann, ob der Text in der HTTP-Antwort vorhanden ist. Wenn JMeter den Text nicht finden kann, markiert es dies als fehlgeschlagene Anfrage.

Um Assertion-Ergebnisse anzuzeigen, fügen Sie der Thread-Gruppe einen Assertion Listener hinzu. Fehlgeschlagene Assertionen werden auch in der Baumansicht und den Tabellen-Listenern angezeigt und zählen zum Fehlerprozentsatz, beispielsweise in den aggregierten und zusammenfassenden Berichten.

3.6 Konfigurationselemente ¶

Ein Konfigurationselement arbeitet eng mit einem Sampler zusammen. Obwohl es keine Anforderungen sendet (mit Ausnahme von HTTP(S) Test Script Recorder ), kann es Anforderungen hinzufügen oder ändern.

Auf ein Konfigurationselement kann nur innerhalb des Baumzweigs zugegriffen werden, in dem Sie das Element platzieren. Wenn Sie beispielsweise einen HTTP-Cookie-Manager in einem Simple Logic Controller platzieren, ist der Cookie-Manager nur für HTTP-Request-Controller zugänglich, die Sie im Simple Logic Controller platzieren (siehe Abbildung 1). Der Cookie-Manager ist für die HTTP-Anforderungen „Webseite 1“ und „Webseite 2“, aber nicht für „Webseite 3“ zugänglich.

Außerdem hat ein Konfigurationselement innerhalb eines Baumzweigs eine höhere Priorität als das gleiche Element in einem "Eltern"-Zweig. Zum Beispiel haben wir zwei HTTP Request Defaults-Elemente definiert, „Web Defaults 1“ und „Web Defaults 2“. Da wir „Web Defaults 1“ in einem Loop Controller platziert haben, kann nur „Web Page 2“ darauf zugreifen. Die anderen HTTP-Anforderungen verwenden „Web Defaults 2“, da wir es in der Thread-Gruppe (dem „Elternteil“ aller anderen Zweige) platziert haben.

3.7 Vorprozessorelemente ¶

Ein Pre-Processor führt einige Aktionen aus, bevor eine Sampler-Anfrage gestellt wird. Wenn ein Vorprozessor an ein Sampler-Element angehängt ist, wird er unmittelbar vor der Ausführung dieses Sampler-Elements ausgeführt. Ein Vorprozessor wird am häufigsten verwendet, um die Einstellungen einer Beispielanforderung kurz vor der Ausführung zu ändern oder um Variablen zu aktualisieren, die nicht aus dem Antworttext extrahiert werden. Weitere Einzelheiten dazu, wann Vorprozessoren ausgeführt werden, finden Sie in den Scoping-Regeln .

3.8 Postprozessor-Elemente ¶

Ein Postprozessor führt eine Aktion aus, nachdem eine Sampler-Anfrage gestellt wurde. Wenn ein Postprozessor an ein Sampler-Element angehängt ist, wird er unmittelbar nach der Ausführung dieses Sampler-Elements ausgeführt. Ein Postprozessor wird meistens verwendet, um die Antwortdaten zu verarbeiten, häufig um Werte daraus zu extrahieren. Weitere Einzelheiten dazu, wann Postprozessoren ausgeführt werden, finden Sie in den Scoping-Regeln .

3.9 Ausführungsreihenfolge ¶

0. Konfigurationselemente
1. Vorprozessoren
2. Timer
3. Sampler
4. Postprozessoren (es sei denn, SampleResult ist null )
5. Behauptungen (es sei denn, SampleResult ist null )
6. Listener (es sei denn, SampleResult ist null )

Beispielsweise im folgenden Testplan:

• Regler
• Postprozessor 1
• Sampler 1
• Sampler 2
• Timer 1
• Behauptung 1
• Vorprozessor 1
• Timer 2
• Postprozessor 2

Vorprozessor 1
Timer 1
Timer 2
Sampler 1
Postprozessor 1
Postprozessor 2
Behauptung 1

Vorprozessor 1
Timer 1
Timer 2
Sampler 2
Postprozessor 1
Postprozessor 2
Behauptung 1

3.10 Scoping-Regeln ¶

Der JMeter-Testbaum enthält Elemente, die sowohl hierarchisch als auch geordnet sind. Einige Elemente in den Testbäumen sind streng hierarchisch (Listener, Config Elements, Post-Processors, Pre-Processors, Assertions, Timers) und einige sind primär geordnet (Controller, Sampler). Wenn Sie Ihren Testplan erstellen, erstellen Sie eine geordnete Liste von Musteranforderungen (über Sampler), die eine Reihe von auszuführenden Schritten darstellen. Diese Anfragen werden oft innerhalb von Controllern organisiert, die ebenfalls bestellt werden. Gegeben ist der folgende Testbaum:

Die Reihenfolge der Anfragen ist Eins, Zwei, Drei, Vier.

Einige Controller beeinflussen die Reihenfolge ihrer Unterelemente, und Sie können über diese spezifischen Controller in der Komponentenreferenz nachlesen .

Andere Elemente sind hierarchisch. Eine Assertion beispielsweise ist im Testbaum hierarchisch. Wenn ihr übergeordnetes Element eine Anforderung ist, wird es auf diese Anforderung angewendet. Wenn sein übergeordnetes Element ein Controller ist, wirkt es sich auf alle Anforderungen aus, die Nachkommen dieses Controllers sind. Im folgenden Testbaum:

Behauptung Nr. 1 wird nur auf Anfrage Eins angewendet, während Behauptung Nr. 2 auf die Anfragen Zwei und Drei angewendet wird.

Ein weiteres Beispiel, diesmal mit Timern:

In diesem Beispiel werden die Anforderungen so benannt, dass sie die Reihenfolge widerspiegeln, in der sie ausgeführt werden. Timer Nr. 1 gilt für die Anforderungen Zwei, Drei und Vier (beachten Sie, dass die Reihenfolge für hierarchische Elemente irrelevant ist). Behauptung Nr. 1 gilt nur für Anfrage Drei. Timer #2 wirkt sich auf alle Anfragen aus.

Hoffentlich machen diese Beispiele deutlich, wie Konfigurationselemente (hierarchische Elemente) angewendet werden. Wenn Sie sich vorstellen, dass jede Anfrage die Äste des Baums hochgereicht wird, zu ihrem Elternteil, dann zu dem Elternteil ihres Elternteils usw., und jedes Mal alle Konfigurationselemente dieses Elternteils gesammelt werden, dann werden Sie sehen, wie es funktioniert.

3.11 Eigenschaften und Variablen ¶

JMeter - Eigenschaften werden in jmeter.properties definiert ( weitere Einzelheiten finden Sie unter Erste Schritte – Konfigurieren von JMeter ).
Eigenschaften sind global für jmeter und werden hauptsächlich verwendet, um einige der Standardwerte zu definieren, die JMeter verwendet. Zum Beispiel definiert die Eigenschaft remote_hosts die Server, die JMeter versuchen wird, remote auszuführen. Eigenschaften können in Testplänen referenziert werden – siehe Funktionen – eine Eigenschaft lesen – aber nicht für Thread-spezifische Werte verwendet werden.

JMeter- Variablen sind für jeden Thread lokal. Die Werte können für jeden Thread gleich oder unterschiedlich sein.
Wenn eine Variable von einem Thread aktualisiert wird, wird nur die Thread-Kopie der Variablen geändert. Beispielsweise setzt der Postprozessor des Extraktors für reguläre Ausdrücke seine Variablen gemäß dem Muster, das sein Thread gelesen hat, und diese können später von demselben Thread verwendet werden. Einzelheiten zum Referenzieren von Variablen und Funktionen finden Sie unter Funktionen und Variablen

Beachten Sie, dass die durch den Testplan und das Konfigurationselement „ Benutzerdefinierte Variablen “ definierten Werte beim Start für den gesamten Testplan verfügbar gemacht werden. Wenn dieselbe Variable von mehreren UDV-Elementen definiert wird, wird das letzte wirksam. Sobald ein Thread gestartet wurde, wird der anfängliche Satz von Variablen in jeden Thread kopiert. Andere Elemente wie der User Parameters Pre-Processor oder der Regular Expression Extractor Post-Processor können verwendet werden, um dieselben Variablen neu zu definieren (oder neue zu erstellen). Diese Neudefinitionen gelten nur für den aktuellen Thread.

Die Funktion setProperty kann verwendet werden, um eine JMeter-Eigenschaft zu definieren. Diese gelten global für den Testplan und können daher verwendet werden, um Informationen zwischen Threads auszutauschen – falls dies erforderlich sein sollte.

3.12 Verwenden von Variablen zum Parametrisieren von Tests ¶

Variablen müssen nicht variieren – sie können einmal definiert werden und ändern ihren Wert nicht, wenn sie in Ruhe gelassen werden. Sie können sie also als Abkürzung für Ausdrücke verwenden, die häufig in einem Testplan vorkommen. Oder für Elemente, die während eines Laufs konstant sind, sich aber zwischen den Läufen ändern können. Beispielsweise der Name eines Hosts oder die Anzahl der Threads in einer Thread-Gruppe.

Beachten Sie bei der Entscheidung, wie Sie einen Testplan strukturieren, welche Elemente für den Lauf konstant sind, sich aber zwischen den Läufen ändern können. Entscheiden Sie sich für einige Variablennamen für diese - verwenden Sie möglicherweise eine Namenskonvention, z. B. indem Sie ihnen das Präfix C_ oder K_ voranstellen oder nur Großbuchstaben verwenden, um sie von Variablen zu unterscheiden, die während des Tests geändert werden müssen. Überlegen Sie auch, welche Elemente für einen Thread lokal sein müssen – zum Beispiel Zähler oder Werte, die mit dem Postprozessor für reguläre Ausdrücke extrahiert wurden. Möglicherweise möchten Sie für diese eine andere Namenskonvention verwenden.

Beispielsweise können Sie Folgendes im Testplan definieren:

HOST www.example.com
FÄDEN 10
SCHLEIFEN 20

HOST ${__P(host,www.example.com)}
FÄDEN ${__P(Fäden,10)}
LOOPS ${__P(loops,20)}

jmeter … -Jhost=www3.example.org -Jloops=13