Die Latenz wird auf die Zeit eingestellt, die für die Anmeldung benötigt wird.

Mit diesem Sampler können Sie eine HTTP/HTTPS-Anfrage an einen Webserver senden. Außerdem können Sie steuern, ob JMeter HTML-Dateien nach Bildern und anderen eingebetteten Ressourcen parst und HTTP-Anforderungen sendet, um sie abzurufen. Die folgenden Arten von eingebetteten Ressourcen werden abgerufen:

• Bilder
• Applets
• Stylesheets (CSS) und Ressourcen, auf die von diesen Dateien verwiesen wird
• externe Skripte
• Frames, IFrames
• Hintergrundbilder (Körper, Tabelle, TD, TR)
• Hintergrundgeräusch

Der Standardparser ist org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser . Dies kann mit der Eigenschaft " htmlparser.className " geändert werden - siehe jmeter.properties für Details.

Wenn Sie mehrere Anfragen an denselben Webserver senden, sollten Sie die Verwendung eines HTTP-Anforderungsstandard - Konfigurationselements in Betracht ziehen, damit Sie nicht für jede HTTP-Anforderung dieselben Informationen eingeben müssen.

Anstatt HTTP-Anforderungen manuell hinzuzufügen, können Sie sie auch mit dem HTTP(S) Test Script Recorder von JMeter erstellen. Dies kann Ihnen Zeit sparen, wenn Sie viele HTTP-Anforderungen oder Anforderungen mit vielen Parametern haben.

Zur Definition der Probenehmer werden drei verschiedene Testelemente verwendet:

AJP/1.3-Sampler

verwendet das Tomcat-mod_jk-Protokoll (ermöglicht das Testen von Tomcat im AJP-Modus, ohne Apache httpd zu benötigen) Der AJP-Sampler unterstützt das Hochladen mehrerer Dateien nicht; nur die erste Datei wird verwendet.

HTTP-Anfrage

Dies hat ein Implementierungs-Dropdown-Feld, das die zu verwendende HTTP-Protokollimplementierung auswählt:

Java

verwendet die von der JVM bereitgestellte HTTP-Implementierung. Dies hat einige Einschränkungen im Vergleich zu den HttpClient-Implementierungen - siehe unten.

HTTPClient4

verwendet Apache HttpComponents HttpClient 4.x.

Leerer Wert

legt die Implementierung nicht auf HTTP-Samplern fest, verlässt sich also auf HTTP-Anforderungsstandards, falls vorhanden, oder auf die jmeter.httpsampler- Eigenschaft, die in jmeter.properties definiert ist

GraphQL-HTTP-Anfrage

Dies ist eine GUI-Variante der HTTP-Anforderung , um bequemere UI-Elemente zum Anzeigen oder Bearbeiten von GraphQL-Abfragen , Variablen und Vorgangsnamen bereitzustellen , während sie automatisch unter der Haube mit demselben Sampler in HTTP-Argumente konvertiert werden. Dadurch werden die folgenden UI-Elemente ausgeblendet oder angepasst, da sie für GraphQL-über-HTTP/HTTPS-Anforderungen weniger bequem oder irrelevant sind:

• Methode : Es sind nur POST- und GET-Methoden verfügbar, die der GraphQL-over-HTTP-Spezifikation entsprechen. Die POST-Methode ist standardmäßig ausgewählt.
• Registerkarten „ Parameter “ und „ Post Body “: Sie können den Parameterinhalt stattdessen über die UI-Elemente „Query“, „Variables“ und „Operation Name“ anzeigen oder bearbeiten.
• Registerkarte Datei-Upload : irrelevant für GraphQL-Abfragen.
• Abschnitt „Eingebettete Ressourcen aus HTML-Dateien “ auf der Registerkarte „Erweitert“: irrelevant in GraphQL-JSON-Antworten.

Die Java-HTTP-Implementierung weist einige Einschränkungen auf:

• Es gibt keine Kontrolle darüber, wie Verbindungen wiederverwendet werden. Wenn eine Verbindung von JMeter freigegeben wird, kann sie von demselben Thread wiederverwendet werden oder nicht.
• Die API eignet sich am besten für die Single-Thread-Nutzung – verschiedene Einstellungen werden über Systemeigenschaften definiert und gelten daher für alle Verbindungen.
• Keine Unterstützung der Kerberos-Authentifizierung
• Clientbasierte Zertifikatstests mit Keystore Config werden nicht unterstützt.
• Bessere Kontrolle des Wiederholungsmechanismus
• Es unterstützt keine virtuellen Hosts.
• Es unterstützt nur die folgenden Methoden: GET , POST , HEAD , OPTIONS , PUT , DELETE und TRACE
• Bessere Kontrolle über das DNS-Caching mit dem DNS-Cache-Manager

Wenn die Anforderung eine Server- oder Proxy-Anmeldeautorisierung erfordert (dh wenn ein Browser ein Popup-Dialogfeld erstellen würde), müssen Sie auch ein HTTP-Autorisierungs-Manager - Konfigurationselement hinzufügen. Für normale Anmeldungen (dh wenn der Benutzer Anmeldeinformationen in ein Formular eingibt) müssen Sie herausfinden, was die Schaltfläche zum Absenden des Formulars bewirkt, und eine HTTP-Anfrage mit der entsprechenden Methode (normalerweise POST ) und den entsprechenden Parametern aus der Formulardefinition erstellen . Wenn die Seite HTTP verwendet, können Sie den JMeter-Proxy verwenden, um die Anmeldesequenz zu erfassen.

Für jeden Thread wird ein separater SSL-Kontext verwendet. Wenn Sie einen einzelnen SSL-Kontext verwenden möchten (nicht das Standardverhalten von Browsern), legen Sie die JMeter-Eigenschaft fest:

https.sessioncontext.shared=true

httpclient.reset_state_on_thread_group_iteration=true

https.default.protocol=SSLv3

JMeter ermöglicht es auch, zusätzliche Protokolle zu aktivieren, indem die Eigenschaft https.socket.protocols geändert wird .

Wenn die Anfrage Cookies verwendet, benötigen Sie auch einen HTTP-Cookie-Manager . Sie können eines dieser Elemente der Thread-Gruppe oder der HTTP-Anforderung hinzufügen. Wenn Sie mehr als eine HTTP-Anforderung haben, die Autorisierungen oder Cookies benötigt, fügen Sie die Elemente der Thread-Gruppe hinzu. Auf diese Weise nutzen alle HTTP-Request-Controller die gleichen Authorization Manager- und Cookie Manager-Elemente.

Wenn die Anfrage eine Technik namens „URL-Umschreibung“ verwendet, um Sitzungen aufrechtzuerhalten, finden Sie weitere Konfigurationsschritte in Abschnitt 6.1 „Handhabung von Benutzersitzungen mit URL-Umschreibung “.

Mit diesem Sampler können Sie eine JDBC-Anforderung (eine SQL-Abfrage) an eine Datenbank senden.

Bevor Sie dies verwenden, müssen Sie ein Konfigurationselement für die JDBC-Verbindungskonfiguration einrichten

Wenn die Liste „Variablennamen“ bereitgestellt wird, werden die Variablen für jede von einer Select-Anweisung zurückgegebene Zeile mit dem Wert der entsprechenden Spalte eingerichtet (falls ein Variablenname bereitgestellt wird), und die Anzahl der Zeilen wird ebenfalls eingerichtet. Wenn die Select-Anweisung beispielsweise 2 Zeilen mit 3 Spalten zurückgibt und die Variablenliste A,,C ist, werden die folgenden Variablen eingerichtet:

A_#=2 (Anzahl Zeilen)
A_1=Spalte 1, Zeile 1
A_2=Spalte 1, Zeile 2
C_#=2 (Anzahl Zeilen)
C_1=Spalte 3, Zeile 1
C_2=Spalte 3, Zeile 2

Wenn die Select-Anweisung null Zeilen zurückgibt, werden die Variablen A_# und C_# auf 0 gesetzt , und es werden keine anderen Variablen gesetzt.

Alte Variablen werden bei Bedarf gelöscht. Wenn beispielsweise die erste Auswahl sechs Zeilen abruft und eine zweite Auswahl nur drei Zeilen zurückgibt, werden die zusätzlichen Variablen für die Zeilen vier, fünf und sechs entfernt.

Mit diesem Sampler können Sie eine Java-Klasse steuern, die die Schnittstelle org.apache.jmeter.protocol.java.sampler.JavaSamplerClient implementiert. Indem Sie Ihre eigene Implementierung dieser Schnittstelle schreiben, können Sie JMeter verwenden, um mehrere Threads, Eingabeparametersteuerung und Datenerfassung zu nutzen.

Das Pulldown-Menü enthält die Liste aller solcher Implementierungen, die JMeter in seinem Klassenpfad gefunden hat. Die Parameter können dann in der folgenden Tabelle angegeben werden - wie von Ihrer Implementierung definiert. Zwei einfache Beispiele ( JavaTest und SleepTest ) werden bereitgestellt.

Der Beispiel-Sampler JavaTest kann zum Überprüfen von Testplänen nützlich sein, da er es ermöglicht, Werte in fast allen Feldern festzulegen. Diese können dann von Assertions usw. verwendet werden. Die Felder ermöglichen die Verwendung von Variablen, sodass deren Werte leicht ersichtlich sind.

Wenn Sie mehrere Anfragen an denselben LDAP-Server senden, sollten Sie die Verwendung eines Standardkonfigurationselements für LDAP-Anfragen in Betracht ziehen, damit Sie nicht für jede LDAP-Anfrage dieselben Informationen eingeben müssen.

Wenn Sie mehrere Anfragen an denselben LDAP-Server senden möchten, sollten Sie ein LDAP Extended Request Defaults Configuration Element verwenden, damit Sie nicht für jede LDAP-Anfrage dieselben Informationen eingeben müssen.

AccessLogSampler wurde entwickelt, um Zugriffsprotokolle zu lesen und HTTP-Anforderungen zu generieren. Für diejenigen, die mit dem Zugriffsprotokoll nicht vertraut sind, es ist das Protokoll, das der Webserver über jede akzeptierte Anfrage führt. Das heißt jedes Bild, CSS-Datei, JavaScript-Datei, HTML-Datei, …

Tomcat verwendet das gängige Format für Zugriffsprotokolle. Dies bedeutet, dass jeder Webserver, der das allgemeine Protokollformat verwendet, den AccessLogSampler verwenden kann. Zu den Servern, die ein gängiges Protokollformat verwenden, gehören: Tomcat, Resin, Weblogic und SunOne. Das übliche Protokollformat sieht folgendermaßen aus:

127.0.0.1 - - [21/Oct/2003:05:37:21 -0500] "GET /index.jsp?%2Findex.jsp= HTTP/1.1" 200 8343

Für die Zukunft könnte es sinnvoll sein, Einträge herauszufiltern, die keinen Antwortcode von 200 haben . Das Erweitern des Samplers sollte ziemlich einfach sein. Es gibt zwei Schnittstellen, die Sie implementieren müssen:

• org.apache.jmeter.protocol.http.util.accesslog.LogParser
• org.apache.jmeter.protocol.http.util.accesslog.Generator

Die aktuelle Implementierung von AccessLogSampler verwendet den Generator, um einen neuen HTTPSampler zu erstellen. Servername, Port und Get-Images werden von AccessLogSampler festgelegt. Als nächstes wird der Parser mit der Ganzzahl 1 aufgerufen und weist ihn an, einen Eintrag zu analysieren. Danach wird HTTPSampler.sample() aufgerufen, um die Anfrage zu stellen.

samp = (HTTPSampler) GENERATOR.generateRequest();
samp.setDomain(this.getDomain());
samp.setPort (this.getPort());
samp.setImageParser (this.isImageParser());
PARSER.parse(1);
res = sample.sample();
res.setSampleLabel(samp.toString());

• setGenerator(Generator)
• analysieren (int)

Klassen, die die Generator -Schnittstelle implementieren, sollten eine konkrete Implementierung für alle Methoden bereitstellen. Ein Beispiel für die Implementierung einer der beiden Schnittstellen finden Sie unter StandardGenerator und TCLogParser .

Mit diesem Sampler können Sie einen Sampler mit der Skriptsprache BeanShell schreiben.

Ausführliche Informationen zur Verwendung von BeanShell finden Sie auf der BeanShell-Website.

Das Testelement unterstützt die Schnittstellenmethoden ThreadListener und TestListener . Diese müssen in der Initialisierungsdatei definiert werden. Beispieldefinitionen finden Sie in der Datei BeanShellListeners.bshrc .

Der BeanShell-Sampler unterstützt auch die Interruptible -Schnittstelle. Die Methode interrupt() kann im Skript oder in der Init-Datei definiert werden.

Der JSR223-Sampler ermöglicht die Verwendung von JSR223-Skriptcode zur Durchführung eines Beispiels oder einiger Berechnungen, die zum Erstellen/Aktualisieren von Variablen erforderlich sind.

SampleResult.setIgnore();

Die JSR223-Testelemente verfügen über ein Feature (Kompilierung), das die Leistung erheblich steigern kann. So profitieren Sie von dieser Funktion:

• Verwenden Sie Skriptdateien, anstatt sie einzubetten. Dadurch wird JMeter sie kompilieren, wenn diese Funktion in ScriptEngine verfügbar ist, und sie zwischenspeichern.
• Oder Verwenden Sie Skripttext und aktivieren Sie die Eigenschaft Kompiliertes Skript zwischenspeichern, falls verfügbar .
  Stellen Sie bei Verwendung dieser Funktion sicher, dass Ihr Skriptcode keine JMeter-Variablen oder JMeter-Funktionsaufrufe direkt im Skriptcode verwendet, da beim Caching nur die erste Ersetzung zwischengespeichert würde. Verwenden Sie stattdessen Skriptparameter.
  Um vom Caching und der Kompilierung zu profitieren, muss die für die Skripterstellung verwendete Sprach-Engine die JSR223 Compilable- Schnittstelle implementieren (Groovy ist eine davon, Java, Beanshell und Javascript sind es nicht).
  Wenn Sie Groovy als Skriptsprache verwenden und Compiliertes Skript zwischenspeichern, falls verfügbar , nicht aktivieren (obwohl Caching empfohlen wird), sollten Sie diese JVM-Eigenschaft -Dgroovy.use.classvalue=true aufgrund eines Groovy-Speicherlecks ab Version 2.4.6 setzen, siehe:

  • GROOVY-7683
  • GROOVY-7591
  • JDK-8136353

jsr223.compiled_scripts_cache_size=100

Der TCP-Sampler öffnet eine TCP/IP-Verbindung zum angegebenen Server. Es sendet dann den Text und wartet auf eine Antwort.

Wenn „ Verbindung wiederverwenden“ ausgewählt ist, werden Verbindungen zwischen Samplern im selben Thread geteilt, vorausgesetzt, dass genau dieselbe Hostnamenzeichenfolge und derselbe Port verwendet werden. Unterschiedliche Hosts/Port-Kombinationen verwenden unterschiedliche Verbindungen, ebenso wie unterschiedliche Threads. Wenn sowohl „ Verbindung wiederverwenden “ als auch „ Verbindung schließen “ ausgewählt sind, wird der Socket nach dem Ausführen des Samplers geschlossen. Beim nächsten Sampler wird ein weiterer Socket erstellt. Möglicherweise möchten Sie am Ende jeder Fadenschleife einen Sockel schließen.

Wenn ein Fehler erkannt wird – oder „ Reuse Connection “ nicht ausgewählt ist – wird der Socket geschlossen. Beim nächsten Sample wird ein weiterer Socket wieder geöffnet.

Die folgenden Eigenschaften können verwendet werden, um seinen Betrieb zu steuern:

tcp.status.präfix

Text, der einer Statusnummer vorangestellt ist

tcp.status.suffix

Text, der einer Statusnummer folgt

tcp.status.properties

Name der Eigenschaftsdatei, um Statuscodes in Meldungen umzuwandeln

tcp.handler

Name der TCP-Handler-Klasse (Standard TCPClientImpl ) – wird nur verwendet, wenn nicht auf der GUI angegeben

Benutzer können ihre eigene Implementierung bereitstellen. Die Klasse muss org.apache.jmeter.protocol.tcp.sampler.TCPClient erweitern .

Die folgenden Implementierungen werden derzeit bereitgestellt.

• TCPClientImpl
• BinaryTCPClientImpl
• LengthPrefixedBinaryTCPClientImpl

TCPClientImpl

Diese Implementierung ist ziemlich einfach. Beim Lesen der Antwort wird bis zum Ende des Zeilenbytes gelesen, wenn dies durch Setzen der Eigenschaft tcp.eolByte definiert ist , ansonsten bis zum Ende des Eingabestroms. Sie können die Zeichensatzcodierung steuern, indem Sie tcp.charset festlegen , das standardmäßig die Standardcodierung der Plattform ist.

BinaryTCPClientImpl

Diese Implementierung wandelt die GUI-Eingabe, die eine Hex-codierte Zeichenfolge sein muss, in eine Binärdatei um und führt beim Lesen der Antwort das Gegenteil aus. Beim Lesen der Antwort wird bis zum Ende des Nachrichtenbytes gelesen, wenn dies durch Setzen der Eigenschaft tcp.BinaryTCPClient.eomByte definiert ist , ansonsten bis zum Ende des Eingabestroms.

LengthPrefixedBinaryTCPClientImpl

Diese Implementierung erweitert BinaryTCPClientImpl, indem den binären Nachrichtendaten ein Byte mit binärer Länge vorangestellt wird. Das Längenpräfix beträgt standardmäßig 2 Byte. Dies kann durch Setzen der Eigenschaft tcp.binarylength.prefix.length geändert werden .

Behandlung von Zeitüberschreitungen

Wenn das Timeout gesetzt ist, wird der Lesevorgang beendet, wenn dieses abgelaufen ist. Wenn Sie also ein eolByte / eomByte verwenden , achten Sie darauf, dass das Timeout ausreichend lang ist, da sonst der Lesevorgang vorzeitig abgebrochen wird.

Antwortbehandlung

Wenn tcp.status.prefix definiert ist, wird die Antwortnachricht nach dem darauffolgenden Text bis zum Suffix durchsucht. Wenn ein solcher Text gefunden wird, wird er verwendet, um den Antwortcode festzulegen. Die Antwortnachricht wird dann aus der Eigenschaftsdatei (falls vorhanden) abgerufen.

Verwendung von Prä- und Suffix ¶

Wenn beispielsweise das Präfix = " [ " und das Suffix = " ] " ist, dann die folgende Antwort:

[J28] XI123,23,GBP,CR

hätte den Antwortcode J28 .

Response Codes im Bereich „ 400 “ – „ 499 “ und „ 500 “ – „ 599 “ gelten derzeit als Fehler; alle anderen sind erfolgreich. [Dies muss konfigurierbar gemacht werden!]

JMS Publisher veröffentlicht Nachrichten an einem bestimmten Ziel (Thema/Warteschlange). Für diejenigen, die mit JMS nicht vertraut sind: Es ist die J2EE-Spezifikation für Messaging. Es gibt zahlreiche JMS-Server auf dem Markt und mehrere Open-Source-Optionen.

Der JMS-Abonnent abonniert Nachrichten in einem bestimmten Ziel (Thema oder Warteschlange). Für diejenigen, die mit JMS nicht vertraut sind: Es ist die J2EE-Spezifikation für Messaging. Es gibt zahlreiche JMS-Server auf dem Markt und mehrere Open-Source-Optionen.

Dieser Sampler sendet und empfängt optional JMS-Nachrichten über Punkt-zu-Punkt-Verbindungen (Warteschlangen). Es unterscheidet sich von Pub/Sub-Nachrichten und wird im Allgemeinen zur Abwicklung von Transaktionen verwendet.

request_only wird normalerweise verwendet, um ein JMS-System zu belasten.
request_reply wird verwendet, wenn Sie die Antwortzeit eines JMS-Dienstes testen möchten, der Nachrichten verarbeitet, die an die Anforderungswarteschlange gesendet werden, da dieser Modus auf die Antwort in der von diesem Dienst gesendeten Antwortwarteschlange wartet.
browse gibt die aktuelle Warteschlangentiefe zurück, dh die Anzahl der Nachrichten in der Warteschlange.
read liest eine Nachricht aus der Warteschlange (falls vorhanden).
clear löscht die Warteschlange, dh entfernt alle Nachrichten aus der Warteschlange.

JMeter verwendet die Eigenschaften java.naming.security.[principal|credentials] – falls vorhanden – beim Erstellen der Warteschlangenverbindung. Wenn dieses Verhalten nicht erwünscht ist, setzen Sie die JMeter-Eigenschaft JMSSampler.useSecurity.properties=false

• Anstatt die Testschnittstelle von JMeter zu verwenden, durchsucht es die JAR-Dateien nach Klassen, die die TestCase - Klasse von JUnit erweitern. Das schließt jede Klasse oder Unterklasse ein.
• JUnit-Test-JAR-Dateien sollten im Verzeichnis „ jmeter/lib/junit “ statt im Verzeichnis „/ lib “ abgelegt werden . Sie können auch die Eigenschaft " user.classpath " verwenden, um anzugeben, wo nach Testfallklassen gesucht werden soll .
• Der JUnit-Sampler verwendet keine Name/Wert-Paare für die Konfiguration wie die Java-Anfrage . Der Sampler geht davon aus, dass setUp und tearDown den Test korrekt konfigurieren.
• Der Sampler misst die verstrichene Zeit nur für die Testmethode und beinhaltet nicht setUp und tearDown .
• Jedes Mal, wenn die Testmethode aufgerufen wird, übergibt JMeter das Ergebnis an die Listener.
• Die Unterstützung für oneTimeSetUp und oneTimeTearDown erfolgt als Methode. Da JMeter multithreaded ist, können wir oneTimeSetUp / oneTimeTearDown nicht so aufrufen , wie es Maven tut.
• Der Sampler meldet unerwartete Ausnahmen als Fehler. Es gibt einige wichtige Unterschiede zwischen standardmäßigen JUnit-Testläufern und der Implementierung von JMeter. Anstatt für jeden Test eine neue Instanz der Klasse zu erstellen, erstellt JMeter 1 Instanz pro Sampler und verwendet sie wieder. Dies kann mit der Checkbox „ Create a new instance per sample “ geändert werden.

öffentliche Klasse meinTestfall {
  öffentlich meinTestfall() {}
}

öffentliche Klasse meinTestfall {
  öffentlich meinTestfall(Stringtext) {
    super(text);
  }
}

Der Mail Reader Sampler kann E-Mail-Nachrichten mit POP3(S)- oder IMAP(S)-Protokollen lesen (und optional löschen).

Dieser Sampler kann auch in Verbindung mit dem Transaction Controller nützlich sein, da er das Einfügen von Pausen ermöglicht, ohne dass ein Sample generiert werden muss. Setzen Sie für variable Verzögerungen die Pausenzeit auf Null und fügen Sie einen Timer als Kind hinzu.

Die Aktion „ Stopp “ hält den Thread oder Test an, nachdem alle laufenden Proben abgeschlossen wurden. Die Aktion „ Jetzt stoppen “ stoppt den Test, ohne auf den Abschluss der Proben zu warten; es unterbricht alle aktiven Samples. Wenn einige Threads nicht innerhalb des 5-Sekunden-Zeitlimits beendet werden, wird eine Meldung im GUI-Modus angezeigt. Sie können versuchen, den Stop- Befehl zu verwenden, um zu sehen, ob dies die Threads stoppt, aber wenn nicht, sollten Sie JMeter beenden. Im CLI-Modus wird JMeter beendet, wenn einige Threads nicht innerhalb des Zeitlimits von 5 Sekunden beendet werden.

Der SMTP-Sampler kann E-Mail-Nachrichten über das SMTP/SMTPS-Protokoll senden. Es ist möglich, Sicherheitsprotokolle für die Verbindung (SSL und TLS) sowie die Benutzerauthentifizierung festzulegen. Wenn ein Sicherheitsprotokoll verwendet wird, erfolgt eine Überprüfung des Serverzertifikats.
Es stehen zwei Alternativen zur Handhabung dieser Überprüfung zur Verfügung:

Vertrauen Sie allen Zertifikaten

Dadurch wird die Überprüfung der Zertifikatskette ignoriert

Verwenden Sie einen lokalen Truststore

Mit dieser Option wird die Zertifikatskette anhand der lokalen Truststore-Datei validiert.

Der OS Process Sampler ist ein Sampler, der zum Ausführen von Befehlen auf dem lokalen Computer verwendet werden kann.
Es sollte die Ausführung aller Befehle ermöglichen, die über die Befehlszeile ausgeführt werden können.
Die Validierung des Rückkehrcodes kann aktiviert und der erwartete Rückkehrcode angegeben werden.

Beachten Sie, dass Betriebssystem-Shells im Allgemeinen eine Befehlszeilenanalyse bereitstellen. Dies variiert je nach Betriebssystem, aber im Allgemeinen teilt die Shell Parameter auf Leerzeichen auf. Einige Shells erweitern Wildcard-Dateinamen; manche nicht. Der Zitiermechanismus variiert auch zwischen den Betriebssystemen. Der Sampler verzichtet bewusst auf Parsing oder Quote-Handling. Der Befehl und seine Parameter müssen in der Form bereitgestellt werden, die von der ausführbaren Datei erwartet wird. Dies bedeutet, dass die Sampler-Einstellungen nicht zwischen Betriebssystemen übertragbar sind.

Viele Betriebssysteme verfügen über einige integrierte Befehle, die nicht als separate ausführbare Dateien bereitgestellt werden. Beispielsweise ist der Windows DIR - Befehl Teil des Befehlsinterpreters ( CMD.EXE ). Diese integrierten Programme können nicht als eigenständige Programme ausgeführt werden, sondern müssen dem entsprechenden Befehlsinterpreter als Argumente übergeben werden.

Beispielsweise muss die Windows-Befehlszeile: DIR C:\TEMP wie folgt angegeben werden:

Befehl:

CMD

Parameter 1:

/C

Parameter 2:

DIR

Parameter 3:

C:\TEMP

Mit diesem Sampler können Sie eine Anfrage an eine MongoDB senden.

Bevor Sie dies verwenden, müssen Sie ein Element MongoDB Source Config Configuration einrichten

Mit diesem Sampler können Sie Cypher-Abfragen über das Bolt-Protokoll ausführen.

Bevor Sie dies verwenden, müssen Sie eine Bolzenverbindungskonfiguration einrichten

Jede Anforderung verwendet eine aus dem Pool abgerufene Verbindung und gibt sie an den Pool zurück, wenn der Sampler abgeschlossen ist. Die Größe des Verbindungspools verwendet die Treibervorgaben (~100) und ist derzeit nicht konfigurierbar.

Die gemessene Antwortzeit entspricht der "vollständigen" Abfrageausführung, einschließlich sowohl der Zeit zum Ausführen der Chiffrierabfrage als auch der Zeit zum Verbrauchen der von der Datenbank zurückgesendeten Ergebnisse.

Mit dem Simple Logic Controller können Sie Ihre Sampler und andere Logic Controller organisieren. Im Gegensatz zu anderen Logic Controllern bietet dieser Controller keine Funktionalität, die über die eines Speichergeräts hinausgeht.

Wenn Sie Generative oder Logic Controller zu einem Loop Controller hinzufügen, durchläuft JMeter diese zusätzlich zu dem Loop-Wert, den Sie für die Thread-Gruppe angegeben haben, eine bestimmte Anzahl von Malen. Wenn Sie beispielsweise einem Loop Controller eine HTTP-Anforderung mit einer Schleifenanzahl von zwei hinzufügen und die Schleifenanzahl der Thread-Gruppe auf drei konfigurieren, sendet JMeter insgesamt 2 * 3 = 6 HTTP-Anforderungen.

Der Once Only Logic Controller weist JMeter an, den/die darin enthaltenen Controller nur einmal pro Thread zu verarbeiten und alle Anforderungen darunter während weiterer Iterationen durch den Testplan zu übergeben.

Der Once-Only-Controller wird jetzt immer während der ersten Iteration eines übergeordneten Controllers mit Schleife ausgeführt. Wenn also der Once-Only-Controller unter einem Loop-Controller platziert wird, der für eine fünfmalige Schleife spezifiziert ist, dann wird der Once-Only-Controller nur bei der ersten Iteration durch den Loop-Controller ausgeführt (dh alle fünf Male).

Beachten Sie, dass sich der Once-Only-Controller immer noch wie zuvor erwartet verhält, wenn er einer Thread-Gruppe zugeordnet wird (wird nur einmal pro Test pro Thread ausgeführt), aber der Benutzer hat jetzt mehr Flexibilität bei der Verwendung des Once-Only-Controllers.

Für Tests, die eine Anmeldung erfordern, sollten Sie die Anmeldeanforderung in diesem Controller platzieren, da sich jeder Thread nur einmal anmelden muss, um eine Sitzung einzurichten.

Wenn Sie einem Interleave-Controller generative oder logische Controller hinzufügen, wechselt JMeter zwischen jedem der anderen Controller für jede Loop-Iteration.

Der Random Logic Controller verhält sich ähnlich wie der Interleave Controller, außer dass er seine Sub-Controller und Sampler nicht der Reihe nach durchläuft, sondern bei jedem Durchgang zufällig einen auswählt.

Der Controller für zufällige Reihenfolge ähnelt einem einfachen Controller dahingehend, dass er jedes untergeordnete Element höchstens einmal ausführt, die Ausführungsreihenfolge der Knoten jedoch zufällig ist.

Mit dem Throughput Controller kann der Benutzer steuern, wie oft er ausgeführt wird. Es gibt zwei Modi:

• Prozent Ausführung
• totale Hinrichtungen

Prozent Hinrichtungen

bewirkt, dass der Controller einen bestimmten Prozentsatz der Iterationen durch den Testplan ausführt.

Totale Hinrichtungen

bewirkt, dass der Controller die Ausführung stoppt, nachdem eine bestimmte Anzahl von Ausführungen stattgefunden hat.

Der Laufzeitcontroller steuert, wie lange seine Kinder laufen. Der Controller führt seine untergeordneten Elemente aus, bis die konfigurierte (n) Laufzeit(en) überschritten sind.

Mit dem If-Controller kann der Benutzer steuern, ob die darunter liegenden Testelemente (seine Kinder) ausgeführt werden oder nicht.

Standardmäßig wird die Bedingung nur einmal beim ersten Eintrag ausgewertet, aber Sie haben die Möglichkeit, sie für jedes im Controller enthaltene ausführbare Element auszuwerten.

Die beste Option (Standardeinstellung) ist, Bedingung als Variablenausdruck interpretieren zu aktivieren? , dann hast du im Bedingungsfeld 2 Möglichkeiten:

• Option 1: Verwenden Sie eine Variable, die wahr oder falsch enthält
  Wenn Sie testen möchten, ob das letzte Sample erfolgreich war, können Sie ${JMeterThread.last_sample_ok} verwenden.

  
• Option 2: Verwenden Sie eine Funktion ( ${__jexl3()} wird empfohlen), um einen Ausdruck auszuwerten, der wahr oder falsch zurückgeben muss

  

"${meineVar}" == "\${meineVar}"

"${meineVar}" != "\${meineVar}"

Der While-Controller führt seine Kinder aus, bis die Bedingung " false " ist.

Mögliche Bedingungswerte:

• leer - Schleife verlassen, wenn der letzte Abtastwert in der Schleife fehlschlägt
• LAST - Schleife verlassen, wenn der letzte Abtastwert in der Schleife fehlschlägt. Wenn das letzte Sample direkt vor der Schleife fehlgeschlagen ist, geben Sie Schleife nicht ein.
• Andernfalls - Schleife verlassen (oder nicht betreten), wenn die Bedingung gleich der Zeichenfolge " false " ist

• ${VAR} – wobei VAR durch ein anderes Testelement auf „false “ gesetzt wird
• ${__jexl3(${C}==10)}
• ${__jexl3("${VAR2}"=="abcd")}
• ${_P(property)} - wo Eigenschaft woanders auf " false " gesetzt ist

Der Switch-Controller verhält sich insofern wie der Interleave-Controller , als er eines der untergeordneten Elemente bei jeder Iteration ausführt, aber anstatt sie nacheinander auszuführen, führt der Controller das durch den Schalterwert definierte Element aus.

Wenn der Schalterwert außerhalb des zulässigen Bereichs liegt, wird das nullte Element ausgeführt, das daher als Standard für den numerischen Fall fungiert. Es führt auch das nullte Element aus, wenn der Wert die leere Zeichenfolge ist.

Wenn der Wert nicht numerisch (und nicht leer) ist, sucht der Switch Controller nach dem Element mit demselben Namen (Groß-/Kleinschreibung ist wichtig). Wenn keiner der Namen übereinstimmt, wird das Element mit dem Namen „ default “ (Groß-/Kleinschreibung nicht signifikant) ausgewählt. Wenn es keinen Standardwert gibt, wird kein Element ausgewählt und der Controller führt nichts aus.

Ein ForEach-Controller durchläuft die Werte eines Satzes verwandter Variablen. Wenn Sie Sampler (oder Controller) zu einem ForEach-Controller hinzufügen, wird jedes Sample (oder jeder Controller) einmal oder mehrmals ausgeführt, wobei die Variable während jeder Schleife einen neuen Wert hat. Die Eingabe sollte aus mehreren Variablen bestehen, die jeweils mit einem Unterstrich und einer Zahl erweitert werden. Jede solche Variable muss einen Wert haben. Wenn also die Eingabevariable beispielsweise den Namen inputVar hat, sollten die folgenden Variablen definiert worden sein:

• inputVar_1 = Wendy
• EingabeVar_2 = Karl
• inputVar_3 = peter
• inputVar_4 = john

Hinweis: Das Trennzeichen „ _ “ ist jetzt optional.

Wenn die Rückgabevariable als " returnVar " angegeben wird, wird die Sammlung von Samplern und Controllern unter dem ForEach-Controller 4 Mal hintereinander ausgeführt, wobei die Rückgabevariable die jeweiligen oben genannten Werte hat, die dann in den Samplern verwendet werden können.

Es eignet sich besonders für die Ausführung mit dem Postprozessor für reguläre Ausdrücke. Dieser kann aus den Ergebnisdaten einer vorangegangenen Anfrage die notwendigen Eingangsvariablen „erzeugen“. Durch Weglassen des Trennzeichens „ _ “ kann der ForEach-Controller verwendet werden, um die Gruppen zu durchlaufen, indem die Eingabevariable refName_g verwendet wird, und kann auch alle Gruppen in allen Übereinstimmungen durchlaufen, indem eine Eingabevariable der Form refName_${C verwendet wird }_g , wobei C eine Zählervariable ist.

Der Modulcontroller stellt einen Mechanismus zum Ersetzen von Testplanfragmenten in den aktuellen Testplan zur Laufzeit bereit.

Ein Testplanfragment besteht aus einem Controller und allen darin enthaltenen Testelementen (Samplern etc.). Das Fragment kann sich in jeder Thread-Gruppe befinden. Wenn sich das Fragment in einer Thread-Gruppe befindet, kann sein Controller deaktiviert werden, um zu verhindern, dass das Fragment außer vom Modul-Controller ausgeführt wird. Oder Sie können die Fragmente in einer Dummy-Thread-Gruppe speichern und die gesamte Thread-Gruppe deaktivieren.

Es können mehrere Fragmente vorhanden sein, denen jeweils eine andere Serie von Samplern zugeordnet ist. Der Modulcontroller kann dann zum einfachen Umschalten zwischen diesen mehreren Testfällen verwendet werden, indem einfach der entsprechende Controller in seinem Dropdown-Feld ausgewählt wird. Dies bietet Komfort für die schnelle und einfache Ausführung vieler alternativer Testpläne.

Ein Fragmentname besteht aus dem Controller-Namen und allen übergeordneten Namen. Zum Beispiel:

Testplan/Protokoll: JDBC/Control/Interleave Controller (Modul1)

Alle vom Module Controller verwendeten Fragmente müssen einen eindeutigen Namen haben , da der Name verwendet wird, um den Zielcontroller zu finden, wenn ein Testplan neu geladen wird. Stellen Sie aus diesem Grund am besten sicher, dass der Controller-Name von der Voreinstellung geändert wird - wie im obigen Beispiel gezeigt -, da sonst versehentlich ein Duplikat erstellt werden kann, wenn neue Elemente zum Testplan hinzugefügt werden.

Der Include-Controller ist darauf ausgelegt, eine externe JMX-Datei zu verwenden. Um es zu verwenden, erstellen Sie unterhalb des Testplans ein Testfragment und fügen darunter beliebige Sampler, Controller usw. hinzu. Speichern Sie dann den Testplan. Die Datei kann jetzt als Teil anderer Testpläne eingefügt werden.

Der Einfachheit halber kann zu Debugging-Zwecken auch eine Thread-Gruppe in der externen JMX-Datei hinzugefügt werden. Ein Modulcontroller kann verwendet werden, um auf das Testfragment zu verweisen. Die Thread-Gruppe wird während des Include-Prozesses ignoriert.

Wenn der Test einen Cookie-Manager oder benutzerdefinierte Variablen verwendet, sollten diese im Testplan der obersten Ebene platziert werden, nicht in der enthaltenen Datei, da sonst nicht garantiert wird, dass sie funktionieren.

Wenn die Datei an dem durch Präfix + Dateiname angegebenen Speicherort nicht gefunden werden kann , versucht der Controller, den Dateinamen relativ zum JMX-Startverzeichnis zu öffnen .

Der Transaktionscontroller generiert ein zusätzliches Muster, das die Gesamtzeit misst, die zum Ausführen der verschachtelten Testelemente benötigt wird.

Es gibt zwei Betriebsarten:

• zusätzliches Sample wird nach den verschachtelten Samples hinzugefügt
• zusätzliche Probe wird als übergeordnetes Element der verschachtelten Proben hinzugefügt

Die generierte Sample-Zeit beinhaltet alle Zeiten für die verschachtelten Sampler, ausgenommen standardmäßig (seit 2.11) Timer und die Verarbeitungszeit von Pre-/Post-Prozessoren, es sei denn, das Kontrollkästchen „ Dauer von Timer und Pre-Post-Prozessoren in generiertes Sample einbeziehen “ ist aktiviert. Je nach Taktauflösung kann sie etwas länger sein als die Summe der einzelnen Sampler plus Timer. Die Uhr kann ticken, nachdem der Controller die Startzeit aufgezeichnet hat, aber bevor die erste Probe beginnt. Ebenso am Ende.

Die erzeugte Stichprobe gilt nur dann als erfolgreich, wenn alle ihre Teilstichproben erfolgreich sind.

Im Parent-Modus sind die einzelnen Samples weiterhin im Tree View Listener zu sehen, erscheinen aber nicht mehr als separate Einträge in anderen Listenern. Außerdem erscheinen die Teilproben nicht in CSV-Protokolldateien, sie können jedoch in XML-Dateien gespeichert werden.

Der Recording Controller ist ein Platzhalter, der angibt, wo der Proxy-Server Samples aufzeichnen soll. Während des Testlaufs hat es keine Auswirkung, ähnlich wie beim einfachen Controller. Aber während der Aufzeichnung mit dem HTTP(S) Test Script Recorder werden alle aufgezeichneten Samples standardmäßig unter dem Recording Controller gespeichert.

Der Critical Section Controller stellt sicher, dass seine untergeordneten Elemente (Sampler/Controller usw.) von nur einem Thread ausgeführt werden, da eine benannte Sperre vorgenommen wird, bevor untergeordnete Elemente des Controllers ausgeführt werden.

Listener können so konfiguriert werden, dass sie verschiedene Elemente in den Ergebnisprotokolldateien (JTL) speichern, indem Sie das Konfigurations-Popup wie unten gezeigt verwenden. Die Standardwerte sind wie in der Dokumentation Listener Default Configuration beschrieben definiert . Elemente mit ( CSV ) nach dem Namen gelten nur für das CSV-Format; Elemente mit ( XML ) gelten nur für das XML-Format. Das CSV-Format kann derzeit nicht zum Speichern von Elementen verwendet werden, die Zeilenumbrüche enthalten.

Beachten Sie, dass Cookies, Methode und der Abfragestring als Teil der Option " Sampler Data " gespeichert werden.

Der Graph Results-Listener generiert ein einfaches Diagramm, das alle Abtastzeiten darstellt. Am unteren Rand des Diagramms werden das aktuelle Sample (schwarz), der aktuelle Durchschnitt aller Samples (blau), die aktuelle Standardabweichung (rot) und die aktuelle Durchsatzrate (grün) in Millisekunden angezeigt.

Die Durchsatzzahl stellt die tatsächliche Anzahl der Anfragen/Minute dar, die der Server bearbeitet hat. Diese Berechnung beinhaltet alle Verzögerungen, die Sie Ihrem Test hinzugefügt haben, und die interne Verarbeitungszeit von JMeter. Der Vorteil einer solchen Berechnung besteht darin, dass diese Zahl etwas Reales darstellt - Ihr Server hat tatsächlich so viele Anfragen pro Minute verarbeitet, und Sie können die Anzahl der Threads erhöhen und/oder die Verzögerungen verringern, um den maximalen Durchsatz Ihres Servers zu ermitteln. Wenn Sie dagegen Berechnungen anstellen, die Verzögerungen und die Verarbeitung von JMeter berücksichtigen, wäre unklar, was Sie aus dieser Zahl schließen könnten.

Der Assertionsergebnis-Visualizer zeigt das Label jeder entnommenen Probe an. Es meldet auch Fehler bei Assertions , die Teil des Testplans sind.

Es gibt mehrere Möglichkeiten, die Antwort anzuzeigen, die über ein Dropdown-Feld unten im linken Bereich ausgewählt werden können.

Trefferzahl: 74
Übereinstimmung[1]=#Funktionen
Match[2]=#what_can_do
Übereinstimmung[3]=#wo
Übereinstimmung[4]=#wie
Match[5]=#function_helper
Übereinstimmung[6]=#Funktionen
Übereinstimmung[7]=#__regexFunktion
Übereinstimmung[8]=#__regexFunction_parms
Übereinstimmung[9]=#__Zähler
… usw …

Anzahl der Spiele: 26
Match[1][0]=JMeter - Apache JMeter</title>
Übereinstimmung[1][1]=JMeter
Match[2][0]=JMeter" title="JMeter" border="0"/></a>
Übereinstimmung[2][1]=JMeter
Match[3][0]=JMeterCommitters">Beitragende</a>
Übereinstimmung[3][1]=JMeterCommitter
… usw …

Bild/
Audio/
Video/

Automatisch scrollen? Option erlaubt die Anzeige des letzten Knotens in der Baumauswahl

Mit der Suchoption ermöglichen die meisten Ansichten auch das Durchsuchen der angezeigten Daten; das Ergebnis der Suche wird oben im Display hervorgehoben. Der folgende Screenshot der Systemsteuerung zeigt beispielsweise ein Ergebnis der Suche nach " Java ". Beachten Sie, dass die Suche auf den sichtbaren Text angewendet wird, sodass Sie möglicherweise unterschiedliche Ergebnisse erhalten, wenn Sie in den Text- und HTML-Ansichten suchen.
Hinweis: Der reguläre Ausdruck verwendet die Java-Engine (keine ORO-Engine wie der Regular Expression Extractor oder die Regexp Tester-Ansicht).

Wenn kein Inhaltstyp angegeben ist , wird der Inhalt in keinem der Antwortdatenfelder angezeigt. Sie können Antworten in einer Datei speichern verwenden, um die Daten in diesem Fall zu speichern. Beachten Sie, dass die Antwortdaten weiterhin im Probenergebnis verfügbar sind, sodass sie weiterhin mit Postprozessoren aufgerufen werden können.

Wenn die Antwortdaten größer als 200 KB sind, werden sie nicht angezeigt. Um dieses Limit zu ändern, legen Sie die JMeter-Eigenschaft view.results.tree.max_size fest . Sie können auch die gesamte Antwort in einer Datei speichern, indem Sie Antworten in einer Datei speichern verwenden .

Zusätzliche Renderer können erstellt werden. Die Klasse muss die Schnittstelle org.apache.jmeter.visualizers.ResultRenderer implementieren und/oder die abstrakte Klasse org.apache.jmeter.visualizers.SamplerResultTab erweitern , und der kompilierte Code muss für JMeter verfügbar sein (z. B. durch Hinzufügen zur lib/ ext- Verzeichnis).

Der Durchsatz wird aus Sicht des Sampler-Targets (z. B. des entfernten Servers bei HTTP-Samples) berechnet. JMeter berücksichtigt die Gesamtzeit, in der die Anfragen generiert wurden. Wenn sich andere Sampler und Timer im selben Thread befinden, erhöhen diese die Gesamtzeit und verringern daher den Durchsatzwert. Zwei identische Sampler mit unterschiedlichen Namen haben also den halben Durchsatz von zwei Samplern mit demselben Namen. Es ist wichtig, die Probennehmernamen richtig auszuwählen, um die besten Ergebnisse aus dem Gesamtbericht zu erhalten.

Die Berechnung der Werte für den Median und die 90 %-Linie (90. Perzentil ⁾ erfordert zusätzlichen Speicher. JMeter kombiniert jetzt Samples mit der gleichen verstrichenen Zeit, bisher wird weniger Speicher verwendet. Bei Samples, die länger als ein paar Sekunden dauern, ist es jedoch wahrscheinlich, dass weniger Samples identische Zeiten haben, in diesem Fall wird mehr Speicher benötigt. Beachten Sie, dass Sie diesen Listener später verwenden können, um eine CSV- oder XML-Ergebnisdatei neu zu laden. Dies ist die empfohlene Methode, um Leistungseinbußen zu vermeiden. Siehe Zusammenfassungsbericht für einen ähnlichen Listener, der keine einzelnen Samples speichert und daher konstanten Speicher benötigt.

• Bezeichnung - Die Bezeichnung der Probe. Wenn „ Gruppennamen in Bezeichnung aufnehmen? “ ausgewählt ist, wird der Name der Thread-Gruppe als Präfix hinzugefügt. Dadurch können identische Etiketten aus unterschiedlichen Garngruppen bei Bedarf separat zusammengetragen werden.
• # Proben - Die Anzahl der Proben mit demselben Etikett
• Durchschnitt - Die durchschnittliche Zeit einer Reihe von Ergebnissen
• Median – Der Median ist die Zeit in der Mitte einer Reihe von Ergebnissen. 50 % der Proben brauchten nicht länger als diese Zeit; der Rest dauerte mindestens genauso lange.
• 90 %-Linie – 90 % der Proben dauerten nicht länger als diese Zeit. Die restlichen Proben dauerten mindestens so lange. ( 90. ^Perzentil )
• 95 %-Linie – 95 % der Proben dauerten nicht länger als diese Zeit. Die restlichen Proben dauerten mindestens so lange. ( 95. ^Perzentil )
• 99 % Linie - 99 % der Proben dauerten nicht länger als diese Zeit. Die restlichen Proben dauerten mindestens so lange. ( 99. ^Perzentil )
• Min - Die kürzeste Zeit für Proben mit demselben Etikett
• Max – Die längste Zeit für Proben mit demselben Etikett
• Fehler % – Prozentsatz der Anfragen mit Fehlern
• Durchsatz – der Durchsatz wird in Anforderungen pro Sekunde/Minute/Stunde gemessen. Die Zeiteinheit ist so gewählt, dass der angezeigte Kurs mindestens 1,0 beträgt. Wenn der Durchsatz in einer CSV-Datei gespeichert wird, wird er in Anfragen/Sekunde ausgedrückt, dh 30,0 Anfragen/Minute werden als 0,5 gespeichert.
• Empfangene KB/s – Der Durchsatz, gemessen in empfangenen Kilobyte pro Sekunde
• Gesendete KB/s – Der Durchsatz, gemessen in gesendeten Kilobyte pro Sekunde

Die Zeiten sind in Millisekunden.

Standardmäßig werden nur die Haupt- (Eltern-)Samples angezeigt; die Sub-Samples (Kind-Samples) werden nicht angezeigt. JMeter hat ein Kontrollkästchen „ Untergeordnete Proben? “. Wenn dies ausgewählt ist, werden die Unterproben anstelle der Hauptproben angezeigt.

Der Mailer-Visualizer kann so eingerichtet werden, dass E-Mails gesendet werden, wenn ein Testlauf zu viele fehlgeschlagene Antworten vom Server erhält.

Der BeanShell Listener ermöglicht die Verwendung von BeanShell zum Verarbeiten von Samples zum Speichern usw.

Ausführliche Informationen zur Verwendung von BeanShell finden Sie auf der BeanShell-Website.

Das Testelement unterstützt die Methoden ThreadListener und TestListener . Diese sollten in der Initialisierungsdatei definiert werden. Beispieldefinitionen finden Sie in der Datei BeanShellListeners.bshrc .

Der Durchsatz wird aus Sicht des Sampler-Targets (z. B. des entfernten Servers bei HTTP-Samples) berechnet. JMeter berücksichtigt die Gesamtzeit, in der die Anfragen generiert wurden. Wenn sich andere Sampler und Timer im selben Thread befinden, erhöhen diese die Gesamtzeit und verringern daher den Durchsatzwert. Zwei identische Sampler mit unterschiedlichen Namen haben also den halben Durchsatz von zwei Samplern mit demselben Namen. Es ist wichtig, die Probenetiketten richtig auszuwählen, um die besten Ergebnisse aus dem Bericht zu erhalten.

• Bezeichnung - Die Bezeichnung der Probe. Wenn „ Gruppennamen in Bezeichnung aufnehmen? “ ausgewählt ist, wird der Name der Thread-Gruppe als Präfix hinzugefügt. Dadurch können identische Etiketten aus unterschiedlichen Garngruppen bei Bedarf separat zusammengetragen werden.
• # Proben - Die Anzahl der Proben mit demselben Etikett
• Durchschnitt – Die durchschnittlich verstrichene Zeit einer Reihe von Ergebnissen
• Min – Die niedrigste verstrichene Zeit für die Proben mit demselben Etikett
• Max – Die längste verstrichene Zeit für die Proben mit demselben Etikett
• Std. Entwickler - die Standardabweichung der verstrichenen Zeit der Probe
• Fehler % – Prozentsatz der Anfragen mit Fehlern
• Durchsatz – der Durchsatz wird in Anforderungen pro Sekunde/Minute/Stunde gemessen. Die Zeiteinheit ist so gewählt, dass der angezeigte Kurs mindestens 1,0 beträgt . Wenn der Durchsatz in einer CSV-Datei gespeichert wird, wird er in Anfragen/Sekunde ausgedrückt, dh 30,0 Anfragen/Minute werden als 0,5 gespeichert .
• Empfangene KB/s – Der Durchsatz, gemessen in Kilobyte pro Sekunde
• Gesendet KB/s – Der Durchsatz, gemessen in Kilobyte pro Sekunde
• Durchschn. Bytes – durchschnittliche Größe der Beispielantwort in Bytes.

Die Zeiten sind in Millisekunden.

Dieses Testelement kann beliebig im Testplan platziert werden. Für jede Probe in ihrem Geltungsbereich wird eine Datei mit den Antwortdaten erstellt. Die primäre Verwendung dafür ist das Erstellen von Funktionstests, aber es kann auch nützlich sein, wenn die Antwort zu groß ist, um im View Results Tree Listener angezeigt zu werden. Der Dateiname wird aus dem angegebenen Präfix plus einer Nummer gebildet (sofern dies nicht deaktiviert ist, siehe unten). Die Dateiendung wird, falls bekannt, aus dem Dokumenttyp gebildet. Wenn nicht bekannt, wird die Dateierweiterung auf „ unbekannt “ gesetzt'. Wenn die Nummerierung deaktiviert ist und das Hinzufügen eines Suffix deaktiviert ist, wird das Dateipräfix als vollständiger Dateiname verwendet. Dadurch kann bei Bedarf ein fester Dateiname generiert werden. Der generierte Dateiname wird in der Beispielantwort gespeichert und kann bei Bedarf in der Testprotokoll-Ausgabedatei gespeichert werden.

Das aktuelle Sample wird zuerst gespeichert, gefolgt von allen Sub-Samples (Kind-Samples). Wenn ein Variablenname angegeben wird, werden die Namen der Dateien in der Reihenfolge gespeichert, in der die Teilstichproben erscheinen. Siehe unten.

Der JSR223-Listener ermöglicht die Anwendung von JSR223-Skriptcode auf Beispielergebnisse.

# Definieren Sie die folgende Eigenschaft, um automatisch einen Summierer mit diesem Namen zu starten
# (gilt nur für den CLI-Modus)
#summariser.name=Zusammenfassung
#
# Intervall zwischen Zusammenfassungen (in Sekunden) Standard 3 Minuten
#summariser.interval=30
#
# Meldungen in Logdatei schreiben
#summariser.log=true
#
# Nachrichten an System.out schreiben
#summariser.out=true

Label + 16 in 0:00:12 = 1,3/s Avg: 1608 Min: 1163 Max: 2009 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label + 82 in 0:00:30 = 2,7/s Avg: 1518 Min: 1003 Max: 2020 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label = 98 in 0:00:42 = 2,3/s Avg: 1533 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 85 in 0:00:30 = 2,8/s Avg: 1505 Min: 1008 Max: 2005 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label = 183 in 0:01:13 = 2,5/s Avg: 1520 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 79 in 0:00:30 = 2,7/s Avg: 1578 Min: 1089 Max: 2012 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Bezeichnung = 262 in 0:01:43 = 2,6/s Durchschnitt: 1538 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 80 in 0:00:30 = 2,7/s Avg: 1531 Min: 1013 Max: 2014 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Bezeichnung = 342 in 0:02:12 = 2,6/s Durchschnitt: 1536 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 83 in 0:00:31 = 2,7/s Avg: 1512 Min: 1003 Max: 1982 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label = 425 in 0:02:43 = 2,6/s Avg: 1531 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 83 in 0:00:29 = 2,8/s Avg: 1487 Min: 1023 Max: 2013 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label = 508 in 0:03:12 = 2,6/s Durchschnitt: 1524 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 78 in 0:00:30 = 2,6/s Avg: 1594 Min: 1013 Max: 2016 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label = 586 in 0:03:43 = 2,6/s Durchschnitt: 1533 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 80 in 0:00:30 = 2,7/s Avg: 1516 Min: 1013 Max: 2005 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label = 666 in 0:04:12 = 2,6/s Avg: 1531 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 86 in 0:00:30 = 2,9/s Avg: 1449 Min: 1004 Max: 2017 Fehler: 0 (0,00 %) Aktiv: 5 Begonnen: 5 Beendet: 0
Label = 752 in 0:04:43 = 2,7/s Avg: 1522 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)
Label + 65 in 0:00:24 = 2,7/s Avg: 1579 Min: 1007 Max: 2003 Fehler: 0 (0,00 %) Aktiv: 0 Gestartet: 5 Beendet: 5
Label = 817 in 0:05:07 = 2,7/s Durchschnitt: 1526 Min: 1003 Max: 2020 Fehler: 0 (0,00 %)

Das Etikett wird verwendet, um Probenergebnisse zu gruppieren. Wenn Sie also mehrere Thread-Gruppen haben und über alle zusammenfassen möchten, verwenden Sie dieselbe Bezeichnung – oder fügen Sie den Summierer zum Testplan hinzu (damit alle Thread-Gruppen im Geltungsbereich sind). Verschiedene Zusammenfassungsgruppierungen können implementiert werden, indem geeignete Bezeichnungen verwendet werden und die Zusammenfassungen zu geeigneten Teilen des Testplans hinzugefügt werden.

CSV Data Set Config wird verwendet, um Zeilen aus einer Datei zu lesen und sie in Variablen aufzuteilen. Sie ist einfacher zu verwenden als die Funktionen __CSVRead() und __StringFromFile() . Es eignet sich gut zum Umgang mit einer großen Anzahl von Variablen und ist auch zum Testen mit "zufälligen" und eindeutigen Werten nützlich.

Das Generieren eindeutiger Zufallswerte zur Laufzeit ist in Bezug auf CPU und Speicher teuer, also erstellen Sie die Daten einfach vor dem Test. Bei Bedarf können die "zufälligen" Daten aus der Datei in Verbindung mit einem Laufzeitparameter verwendet werden, um unterschiedliche Wertesätze aus jedem Durchlauf zu erstellen - zB durch Verkettung - was viel billiger ist, als alles zur Laufzeit zu generieren.

JMeter erlaubt das Zitieren von Werten; Dadurch kann der Wert ein Trennzeichen enthalten. Wenn „ Daten in Anführungszeichen zulassen “ aktiviert ist, kann ein Wert in doppelte Anführungszeichen gesetzt werden. Diese werden entfernt. Um doppelte Anführungszeichen in ein Feld in Anführungszeichen einzufügen, verwenden Sie zwei doppelte Anführungszeichen. Zum Beispiel:

1, "2,3", "4" "5" =>
1
2,3
4 "5

JMeter unterstützt CSV-Dateien, die eine Kopfzeile haben, die die Spaltennamen definiert. Um dies zu ermöglichen, lassen Sie das Feld „ Variablennamen “ leer. Das richtige Trennzeichen muss angegeben werden.

JMeter unterstützt CSV-Dateien mit Daten in Anführungszeichen, die Zeilenumbrüche enthalten.

Standardmäßig wird die Datei nur einmal geöffnet und jeder Thread verwendet eine andere Zeile aus der Datei. Die Reihenfolge, in der Zeilen an Threads übergeben werden, hängt jedoch von der Reihenfolge ab, in der sie ausgeführt werden, die zwischen Iterationen variieren kann. Zeilen werden zu Beginn jeder Testiteration gelesen. Der Dateiname und -modus werden in der ersten Iteration aufgelöst.

Weitere Optionen finden Sie unten in der Beschreibung des Share-Modus. Wenn Sie möchten, dass jeder Thread seinen eigenen Satz von Werten hat, müssen Sie einen Satz von Dateien erstellen, eine für jeden Thread. Zum Beispiel test1.csv , test2.csv , …, test n .csv . Verwenden Sie den Dateinamen test${__threadNum}.csv und stellen Sie den " Freigabemodus " auf " Aktueller Thread ".

Als Sonderfall wird die Zeichenfolge " \t " (ohne Anführungszeichen) im Trennzeichenfeld als Tabulator behandelt.

Wenn das Dateiende ( EOF ) erreicht ist und die Option recycle true ist , beginnt das Lesen erneut mit der ersten Zeile der Datei.

Wenn die Option recycle false und stopThread false ist , werden alle Variablen auf <EOF> gesetzt, wenn das Dateiende erreicht ist. Dieser Wert kann durch Festlegen der JMeter-Eigenschaft csvdataset.eofstring geändert werden .

Wenn die Recycle-Option false und Stop Thread true ist , wird das Erreichen von EOF dazu führen, dass der Thread gestoppt wird.

Das DNS-Cache-Manager-Element ermöglicht das Testen von Anwendungen, die mehrere Server hinter Load Balancern (CDN usw.) haben, wenn Benutzer Inhalte von verschiedenen IPs erhalten. Standardmäßig verwendet JMeter den JVM-DNS-Cache. Aus diesem Grund wird nur ein Server aus dem Cluster belastet. Der DNS-Cache-Manager löst Namen für jeden Thread bei jeder Iteration separat auf und speichert die Ergebnisse der Auflösung in seinem internen DNS-Cache, der unabhängig von JVM- und OS-DNS-Caches ist.

Eine Zuordnung für statische Hosts kann verwendet werden, um so etwas wie die Datei /etc/hosts zu simulieren. Diese Einträge werden gegenüber dem benutzerdefinierten Resolver bevorzugt. Benutzerdefinierten DNS-Resolver verwenden muss aktiviert sein, wenn Sie diese Zuordnung verwenden möchten.

Mit dem Autorisierungs-Manager können Sie eine oder mehrere Benutzeranmeldungen für Webseiten angeben, die mithilfe der Serverauthentifizierung eingeschränkt sind. Sie sehen diese Art der Authentifizierung, wenn Sie Ihren Browser verwenden, um auf eine eingeschränkte Seite zuzugreifen, und Ihr Browser zeigt ein Anmeldedialogfeld an. JMeter übermittelt die Anmeldeinformationen, wenn es auf diese Art von Seite stößt.

Die Autorisierungs-Header werden möglicherweise nicht auf der Registerkarte „ Request “ des Strukturansicht -Listeners angezeigt . Die Java-Implementierung führt eine präventive Authentifizierung durch, gibt jedoch den Authorization-Header nicht zurück, wenn JMeter die Header abruft. Die Implementierung von HttpComponents (HC 4.5.X) ist seit 3.2 standardmäßig präemptiv und der Header wird angezeigt. Um dies zu deaktivieren, legen Sie die Werte wie folgt fest. In diesem Fall wird die Authentifizierung nur als Antwort auf eine Abfrage durchgeführt.

Setzen Sie in der Datei jmeter.properties httpclient4.auth.preemptive=false

Der HTTP-Cache-Manager wird verwendet, um HTTP-Anforderungen innerhalb seines Bereichs Caching-Funktionalität hinzuzufügen, um die Browser-Cache-Funktion zu simulieren. Jeder virtuelle Benutzerthread hat seinen eigenen Cache. Standardmäßig speichert Cache Manager unter Verwendung des LRU-Algorithmus bis zu 5000 Elemente im Cache pro Thread für virtuelle Benutzer. Verwenden Sie die Eigenschaft „ maxSize “, um diesen Wert zu ändern. Beachten Sie, dass je mehr Sie diesen Wert erhöhen, desto mehr Speicher verbraucht der HTTP-Cache-Manager. Stellen Sie daher sicher, dass Sie die JVM-Option -Xmx entsprechend anpassen.

Wenn ein Beispiel erfolgreich ist (dh den Antwortcode 2xx hat ), werden die Werte Last-Modified und Etag (und Expired , falls relevant) für die URL gespeichert. Vor der Ausführung des nächsten Beispiels prüft der Sampler, ob ein Eintrag im Cache vorhanden ist, und wenn dies der Fall ist, werden die bedingten Header „ If-Last-Modified “ und „ If-None-Match “ für die Anforderung festgelegt.

Wenn außerdem die Option " Cache-Control/Expires-Header verwenden " ausgewählt ist, wird der Cache-Control / Expires - Wert mit der aktuellen Zeit verglichen. Wenn die Anforderung eine GET -Anforderung ist und der Zeitstempel in der Zukunft liegt, kehrt der Sampler sofort zurück, ohne die URL vom Remote-Server anzufordern. Dies soll das Browserverhalten emulieren. Beachten Sie, dass, wenn der Cache-Control- Header " no-cache " ist, die Antwort als vorab abgelaufen im Cache gespeichert wird, sodass eine bedingte GET - Anforderung generiert wird. Wenn Cache-Control einen anderen Wert hat, wird die Datei " max-age" Die Ablaufoption wird verarbeitet, um die Lebensdauer des Eintrags zu berechnen. Wenn sie fehlt, wird der Ablauf-Header verwendet, wenn auch der fehlende Eintrag gemäß RFC 2616, Abschnitt 13.2.4 , unter Verwendung der Zeit der letzten Änderung und des Antwortdatums zwischengespeichert wird.

Das Cookie-Manager-Element hat zwei Funktionen:
Erstens speichert und sendet es Cookies wie ein Webbrowser. Wenn Sie eine HTTP-Anforderung haben und die Antwort ein Cookie enthält, speichert der Cookie-Manager dieses Cookie automatisch und verwendet es für alle zukünftigen Anforderungen an diese bestimmte Website. Jeder JMeter-Thread hat seinen eigenen "Cookie-Speicherbereich". Wenn Sie also eine Website testen, die ein Cookie zum Speichern von Sitzungsinformationen verwendet, hat jeder JMeter-Thread seine eigene Sitzung. Beachten Sie, dass solche Cookies nicht in der Anzeige des Cookie-Managers erscheinen, aber mit dem View Results Tree Listener angezeigt werden können.

JMeter prüft, ob empfangene Cookies für die URL gültig sind. Das bedeutet, dass keine domainübergreifenden Cookies gespeichert werden. Wenn Sie fehlerhaftes Verhalten haben oder möchten, dass Cross-Domain-Cookies verwendet werden, definieren Sie die JMeter-Eigenschaft „ CookieManager.check.cookies=false “.

Empfangene Cookies können als JMeter-Thread-Variablen gespeichert werden. Um Cookies als Variablen zu speichern, definieren Sie die Eigenschaft " CookieManager.save.cookies=true ". Außerdem wird den Namen von Cookies das Präfix „ COOKIE_ “ vorangestellt, bevor sie gespeichert werden (dies vermeidet eine versehentliche Beschädigung lokaler Variablen). Um zum ursprünglichen Verhalten zurückzukehren, definieren Sie die Eigenschaft „ CookieManager.name.prefix= “ (ein oder mehrere Leerzeichen). Wenn aktiviert, kann der Wert eines Cookies mit dem Namen TEST als ${COOKIE_TEST} bezeichnet werden .

Zweitens können Sie dem Cookie-Manager manuell ein Cookie hinzufügen. Wenn Sie dies tun, wird das Cookie jedoch von allen JMeter-Threads geteilt.

Beachten Sie, dass solche Cookies mit einer weit in der Zukunft liegenden Ablaufzeit erstellt werden

Cookies mit Nullwerten werden standardmäßig ignoriert. Dies kann durch Festlegen der JMeter-Eigenschaft geändert werden: CookieManager.delete_null_cookies=false . Beachten Sie, dass dies auch für manuell definierte Cookies gilt – solche Cookies werden von der Anzeige entfernt, wenn sie aktualisiert wird. Beachten Sie auch, dass der Cookie-Name eindeutig sein muss – wenn ein zweites Cookie mit demselben Namen definiert wird, ersetzt es das erste.

Mit diesem Element können Sie Standardwerte festlegen, die Ihre HTTP-Anforderungscontroller verwenden. Wenn Sie beispielsweise einen Testplan mit 25 HTTP-Anforderungscontrollern erstellen und alle Anforderungen an denselben Server gesendet werden, können Sie ein einzelnes HTTP-Anforderungsstandardelement mit ausgefülltem Feld „Servername oder IP “ hinzufügen. Dann , lassen Sie beim Hinzufügen der 25 HTTP-Request-Controller das Feld „ Servername oder IP “ leer. Die Controller erben diesen Feldwert vom Element „HTTP Request Defaults“.

Mit dem Header-Manager können Sie HTTP-Anforderungsheader hinzufügen oder überschreiben.

JMeter unterstützt jetzt mehrere Header-Manager . Die Header-Einträge werden zur Liste für den Sampler zusammengeführt. Wenn ein zusammenzuführender Eintrag mit einem vorhandenen Kopfzeilennamen übereinstimmt, ersetzt er den vorherigen Eintrag. Auf diese Weise können Sie einen Standardsatz von Kopfzeilen einrichten und Anpassungen an bestimmten Samplern vornehmen. Beachten Sie, dass ein leerer Wert für einen Header keinen vorhandenen Header entfernt, sondern nur seinen Wert ersetzt.

Mit der Komponente „Java Request Defaults“ können Sie Standardwerte für Java-Tests festlegen. Siehe die Java-Anfrage .

Mit dem Keystore-Konfigurationselement können Sie konfigurieren, wie Keystore geladen wird und welche Schlüssel verwendet werden. Diese Komponente wird normalerweise in HTTPS-Szenarien verwendet, in denen Sie die Keystore-Initialisierung nicht in der Antwortzeit berücksichtigen möchten.

Um dieses Element zu verwenden, müssen Sie zunächst einen Java Key Store mit den zu testenden Client-Zertifikaten einrichten:

1. Erstellen Sie Ihre Zertifikate entweder mit dem Java Keytool- Dienstprogramm oder über Ihre PKI
2. Wenn Sie von PKI erstellt wurden, importieren Sie Ihre Schlüssel in Java Key Store, indem Sie sie in ein von JKS akzeptiertes Format konvertieren
3. Verweisen Sie dann auf die Keystore-Datei über die beiden JVM-Eigenschaften (oder fügen Sie sie in system.properties hinzu ):
   • -Djavax.net.ssl.keyStore=Pfad_zum_Schlüsselspeicher
   • -Djavax.net.ssl.keyStorePassword=password_of_keystore

Um PKCS11 als Quelle für den Store zu verwenden, müssen Sie javax.net.ssl.keyStoreType auf PKCS11 und javax.net.ssl.keyStore auf NONE setzen .

Mit dem Login-Konfigurationselement können Sie Benutzernamen- und Kennworteinstellungen in Probenehmern hinzufügen oder überschreiben, die Benutzernamen und Kennwort als Teil ihrer Einrichtung verwenden.

Mit der Komponente „LDAP-Anforderungsstandards“ können Sie Standardwerte für LDAP-Tests festlegen. Siehe LDAP-Anfrage .

Mit der Komponente „Standardwerte für erweiterte LDAP-Anforderungen“ können Sie Standardwerte für erweiterte LDAP-Tests festlegen. Siehe die erweiterte LDAP-Anforderung .

Die TCP-Sampler-Konfiguration stellt Standarddaten für den TCP-Sampler bereit

Mit dem Element „Benutzerdefinierte Variablen“ können Sie einen anfänglichen Satz von Variablen definieren , genau wie im Testplan .

UDVs sollten nicht mit Funktionen verwendet werden, die bei jedem Aufruf unterschiedliche Ergebnisse generieren. Nur das Ergebnis des ersten Funktionsaufrufs wird in der Variablen gespeichert. UDVs können jedoch mit Funktionen wie __P() verwendet werden, zum Beispiel:

HOST ${__P(host,localhost)}

Dadurch würde die Variable " HOST " so definiert, dass sie den Wert der JMeter-Eigenschaft " host " hat und standardmäßig " localhost " ist, wenn sie nicht definiert ist.

Informationen zum Definieren von Variablen während eines Testlaufs finden Sie unter Benutzerparameter . UDVs werden in der Reihenfolge verarbeitet, in der sie im Plan erscheinen, von oben nach unten.

Der Einfachheit halber wird vorgeschlagen, dass UDVs nur am Anfang einer Thread-Gruppe (oder vielleicht unter dem Testplan selbst) platziert werden.

Nachdem der Testplan und alle UDVs verarbeitet wurden, wird der resultierende Satz von Variablen in jeden Thread kopiert, um den anfänglichen Satz von Variablen bereitzustellen.

Wenn ein Laufzeitelement wie ein User Parameters Pre-Processor oder ein Regular Expression Extractor eine Variable mit demselben Namen wie eine der UDV-Variablen definiert, ersetzt dies den Anfangswert, und alle anderen Testelemente im Thread sehen den aktualisierten Wert Wert.

Das Random Variable Config Element wird verwendet, um zufällige numerische Zeichenfolgen zu generieren und sie zur späteren Verwendung in Variablen zu speichern. Es ist einfacher als die Verwendung von benutzerdefinierten Variablen zusammen mit der Funktion __Random() .

Die Ausgabevariable wird mithilfe des Zufallszahlengenerators erstellt, und dann wird die resultierende Zahl mithilfe der Formatzeichenfolge formatiert. Die Zahl wird mit der Formel minimum+Random.nextInt(maximum-minimum+1) berechnet . Random.nextInt() erfordert eine positive Ganzzahl. Das bedeutet, dass Maximum-Minimum - dh der Bereich - kleiner als 2147483647 sein muss , jedoch können die minimalen und maximalen Werte beliebig lange Werte sein, solange der Bereich in Ordnung ist.

Ermöglicht dem Benutzer, einen Zähler zu erstellen, auf den überall in der Thread-Gruppe verwiesen werden kann. Mit der Zählerkonfiguration kann der Benutzer einen Startpunkt, ein Maximum und das Inkrement konfigurieren. Der Zähler durchläuft eine Schleife vom Start bis zum Maximum und beginnt dann wieder mit dem Start und fährt so fort, bis der Test beendet ist.

Der Zähler verwendet einen Long-Wert, um den Wert zu speichern, sodass der Bereich von -2^63 bis 2^63-1 reicht .

Mit dem einfachen Konfigurationselement können Sie beliebige Werte in Samplern hinzufügen oder überschreiben. Sie können den Namen des Werts und den Wert selbst auswählen. Obwohl einige abenteuerlustige Benutzer eine Verwendung für dieses Element finden könnten, ist es hier hauptsächlich für Entwickler als grundlegende GUI gedacht, die sie beim Entwickeln neuer JMeter-Komponenten verwenden können.

Sie können dann mit diesem Code über das Element MongoDBHolder auf das Objekt com.mongodb.DB in Beanshell oder JSR223 Test Elements zugreifen

com.mongodb.DB importieren;
import org.apache.jmeter.protocol.mongodb.config.MongoDBHolder;
DB db = MongoDBHolder.getDBFromSource("Wert der Eigenschaft MongoDB Source",
            "Wert der Eigenschaft Datenbankname");
…
    

Im Bedienfeld für die Antwortzusicherung können Sie Musterzeichenfolgen hinzufügen, die mit verschiedenen Feldern der Anfrage oder Antwort verglichen werden. Die Musterzeichenfolgen sind:

• Enthält , Übereinstimmungen : Reguläre Ausdrücke im Perl5-Stil
• Equals , Substring : Nur-Text, Groß-/Kleinschreibung beachten

Eine Zusammenfassung der Mustererkennungszeichen finden Sie unter ORO Perl5 Regular Expressions.

Sie können auch auswählen, ob erwartet wird, dass die Zeichenfolgen mit der gesamten Antwort übereinstimmen , oder ob die Antwort nur das Muster enthalten soll. Für zusätzliche Flexibilität können Sie jedem Controller mehrere Zusicherungen zuordnen.

Beachten Sie, dass die Musterzeichenfolge keine einschließenden Trennzeichen enthalten sollte, dh verwenden Sie Price: \d+ und nicht /Price: \d+/ .

Standardmäßig befindet sich das Muster im mehrzeiligen Modus, was bedeutet, dass das Metazeichen „ . “ nicht mit Zeilenumbruch übereinstimmt. Im mehrzeiligen Modus stimmen " ^ " und " $ " mit dem Anfang oder Ende einer beliebigen Zeile innerhalb der Zeichenfolge überein - nicht nur mit dem Anfang und Ende der gesamten Zeichenfolge. Beachten Sie, dass \s New-Line entspricht. Auch der Fall ist von Bedeutung. Um diese Einstellungen zu überschreiben, kann man die erweiterte reguläre Ausdruckssyntax verwenden . Zum Beispiel:

(?ich)

Fall ignorieren

(?s)

behandle das Ziel als einzelne Zeile, dh " . " passt auf eine neue Zeile

(?ist)

beide oben

(?i)Apfel(?-i) Pie

passt zu „ Apfelkuchen “, aber nicht zu „ Apfelkuchen “

(?s)Apple.+?Pie

entspricht Apple gefolgt von Pie , das sich möglicherweise in einer nachfolgenden Zeile befindet.

Apple(?s).+?Pie

wie oben, aber es ist wahrscheinlich klarer, die (?s) am Anfang zu verwenden.

Die Duration Assertion testet, ob jede Antwort innerhalb einer bestimmten Zeit empfangen wurde. Jede Antwort, die länger als die angegebene Anzahl von Millisekunden (vom Benutzer angegeben) dauert, wird als fehlgeschlagene Antwort markiert.

Die Größenzusicherung testet, ob jede Antwort die richtige Anzahl von Bytes enthält. Sie können angeben, dass die Größe gleich, größer, kleiner oder ungleich einer bestimmten Anzahl von Bytes sein soll.

Die XML-Assertion testet, ob die Antwortdaten aus einem formal korrekten XML-Dokument bestehen. Es validiert das XML nicht auf der Grundlage einer DTD oder eines Schemas oder führt eine weitere Validierung durch.

Die BeanShell-Assertion ermöglicht es dem Benutzer, die Assertion-Überprüfung mit einem BeanShell-Skript durchzuführen.

Ausführliche Informationen zur Verwendung von BeanShell finden Sie auf der BeanShell-Website.

Beachten Sie, dass für jedes unabhängige Vorkommen der Assertion in jedem Thread in einem Testskript ein anderer Interpreter verwendet wird, aber der gleiche Interpreter für nachfolgende Aufrufe verwendet wird. Das bedeutet, dass Variablen über Aufrufe der Assertion hinweg bestehen bleiben.

Alle Assertionen werden vom gleichen Thread wie der Sampler aufgerufen.

Wenn die Eigenschaft „ beanshell.assertion.init “ definiert ist, wird sie als Name einer Quelldatei an den Interpreter übergeben. Dies kann verwendet werden, um allgemeine Methoden und Variablen zu definieren. Es gibt eine Beispiel-Init-Datei im bin - Verzeichnis: BeanShellAssertion.bshrc

Das Testelement unterstützt die Methoden ThreadListener und TestListener . Diese sollten in der Initialisierungsdatei definiert werden. Beispieldefinitionen finden Sie in der Datei BeanShellListeners.bshrc .

Die MD5Hex-Assertion ermöglicht es dem Benutzer, den MD5-Hash der Antwortdaten zu überprüfen.

Die HTML-Assertion ermöglicht es dem Benutzer, die HTML-Syntax der Antwortdaten mit JTidy zu überprüfen.

Die XPath-Assertion testet ein Dokument auf Wohlgeformtheit, hat die Möglichkeit, gegen eine DTD zu validieren oder das Dokument durch JTidy zu schicken und auf einen XPath zu testen. Wenn dieser XPath existiert, ist die Behauptung wahr. Die Verwendung von " / " passt zu jedem wohlgeformten Dokument und ist der Standard-XPath-Ausdruck. Die Assertion unterstützt auch boolesche Ausdrücke wie " count(//*error)=2 ". Weitere Informationen zu XPath finden Sie unter http://www.w3.org/TR/xpath .

• //title[text()='Text to match'] - passt <title>Text to match</title> irgendwo in der Antwort an
• /title[text()='Text to match'] - Gleicht <title>Text to match</title> auf Stammebene in der Antwort ab

Die XPath2-Assertion testet ein Dokument auf Wohlgeformtheit. Die Verwendung von " / " passt zu jedem wohlgeformten Dokument und ist der Standard-XPath2-Ausdruck. Die Assertion unterstützt auch boolesche Ausdrücke wie " count(//*error)=2 ".

• //title[text()='Text to match'] - passt <title>Text to match</title> irgendwo in der Antwort an
• /title[text()='Text to match'] - Gleicht <title>Text to match</title> auf Stammebene in der Antwort ab

Die XML-Schema-Assertion ermöglicht dem Benutzer, eine Antwort anhand eines XML-Schemas zu validieren.

Die JSR223-Assertion ermöglicht die Verwendung von JSR223-Skriptcode, um den Status des vorherigen Beispiels zu überprüfen.

• bcmail-xxx.jar (BouncyCastle SMIME/CMS)
• bcprov-xxx.jar (BouncyCastle-Anbieter)

Wenn Sie den Mail Reader Sampler verwenden , stellen Sie bitte sicher, dass Sie " Nachricht mit MIME (roh) speichern" auswählen, da die Assertion die Nachricht sonst nicht korrekt verarbeiten kann.