Ein HTTP(S)-Auslastungstest generiert gleichzeitige Anforderungen an eine einzelne URL. Es überprüft die Ziel-URL auf korrekten Inhalt, Fehler und fehlerhafte Links. Es unterstützt POST- und GET-Anforderungen, Cookies, Formularübermittlungen, benutzerdefinierte Header, passwortgesicherte Sites (grundlegende HTTP/HTTPS-Autorisierung sowie Cookie/Script-Autorisierungsmechanismen) und Timeout-Schwellenwerte. Der HTTP(S)-Auslastungstest unterstützt sowohl IPv4- als auch IPv6-Protokolle.

Sie können HTTP(S)-Anforderungsparameter in Kontextparameter konvertieren, um Werte zu übergeben, z. B. aus einer Antwort einer anderen Anforderung innerhalb des Auslastungstestgeräts abgerufen. Sie können Kontextparameter für die URL, Header, Anforderungsinhalte (für Post-, Put-, Patch-Methoden) und die Skripts zum Vorbereiten und Nachsenden einrichten. Weitere Informationen finden Sie unter Verwenden von Kontextparametern in HTTP(S)-Anforderungen.

Url

Geben Sie die URL ein, die Sie testen möchten. Die Adresse sollte genau so formatiert werden, wie Sie sie in einem Browser verwenden würden, z. B. http://www.example.com. Sie müssen die http:// oder https:// am Anfang der Adresse angeben. Sie können alle GET-Parameter am Ende Ihrer URL einfügen.

Schwellenwert für die Zeitüberprüfung (in Sekunden)

Geben Sie die Anzahl der Sekunden ein, die das System auf eine Antwort von der Zielressource warten soll, bevor ein Fehler zurückgegeben wird. Wenn diese Leerung leer gelassen wird, beträgt das Standardtimeout 120 Sekunden.

Anforderungstyp

Im Feld Anforderungstyp können Sie eine der am häufigsten verwendeten HTTP-Methoden auswählen, um Überwachungsanforderungen an eine Webseite zu senden. Wenn Sie eine Payload mit HTTP-Anfragen senden müssen, geben Sie sie in das entsprechende Feld ein (weitere Informationen finden Sie im Kapitel Request Body ). Die Nutzlast kann mit allen Arten von Anforderungen außer Trace (RFC2616) angegeben und gesendet werden.

URL-Umleitungen

Wenn die Option “Umleitung folgen” auf Jafestgelegt ist, folgt das System dem Pfad der URL, die mit der Antwort 301 gesendet wird, und betrachtet jede Umleitung als separate HTTP-Anforderung. Es ermöglicht Ihnen, die vollständige Umleitungskette (alle Links, durch die die Anforderung umgeleitet wird) in den Testergebnissen zu verfolgen, einschließlich Der Antwortzeiten sowohl für die ursprüngliche URL als auch für nachfolgende Antworten.

Es wird empfohlen, die Option “Weiterleiten folgen” aktiviert zu lassen, wenn Sie nicht nur die ursprüngliche URL, sondern alle URLs in der Kette testen müssen. Beispielsweise kann es nützlich sein, eine SSL-Zertifikatsprüfung für jede URL in einer Umleitungskette durchzuführen.

In Fällen, in denen Sie nur eine anfängliche URL testen möchten, deaktivieren Sie die Option Follow Redirects.

Beachten Sie, dass ein Standardumleitungslimit auf 10 Umleitungen festgelegt ist. Wenn das System eine bestimmte Anzahl von Umleitungen ausführen soll (weniger als 10), können Sie die Anzahl der URLs angeben, die Sie in Ihrer Umleitungskette testen möchten, im Feld Skript vorbereiten:

string url;
url = "http://wtatour.com/";
currentTask.TaskMaxRedirectAttempts = N;

Wobei N die Anzahl der Umleitungsorte ist, denen wir folgen möchten. Um keine Umleitungen zu folgen, legen Sie einfach die Anzahl der Umleitungsstandorte auf 0 fest.

Inhaltsvalidierung

Content Validation Keywords werden verwendet, um sicherzustellen, dass der erwartete Inhalt auf eine Webseite geladen wurde. In den Feldern Keyword können Sie ein oder mehrere Wörter oder Ausdrücke angeben, nach denen Sie im Webseiteninhalt suchen möchten. Wenn die erwarteten Schlüsselwörter nicht gefunden werden, gibt die Aufgabe einen Fehler zurück.

Sie können mehrere Zeichenfolgen in die Schlüsselwortfelder eingeben. Die eingegebenen Werte können durch logische Ausdrücke wie folgt getrennt werden:

{[("keyword1"&"keyword2")|!"keyword3"]}

Wo:
[– Schlüsselwortausdrucksstart;
]- – Schlüsselwortausdrucksende;
() – Gruppieren von Klammern;
& – logisch UND;
| – logisches ODER;
! – logisches NICHT;
“string” – ein Schlüsselwort.

Ein erfolgreicher Schlüsselwortausdruck muss die Anfangs- und End-Brackets wie folgt enthalten:

{["keyword"]}

Standardauthentifizierung

Das Standardauthentifizierungsschema wird verwendet, um Benutzern den Zugriff auf Inhalte auf einigen Websites zu ermöglichen. Nach der Bereitstellung werden die Anmeldeinformationen zusammen mit dem Anforderungsheader an den Webserver übergeben.

  • Benutzername: enthält einen Benutzernamen für die HTTP/S-Basis- oder Digest-Zugriffsauthentifizierung.
  • Benutzerkennwort: enthält ein Kennwort für die HTTP/S-Basis- oder Digest-Zugriffsauthentifizierung.

Verwechseln Sie die Standardauthentifizierung nicht mit anderen Authentifizierungsschemata wie der Bearer Authentication, die Inhabertoken umfasst, und OAuth 2.0, das Zugriffstoken verwendet.

Weitere Informationen finden Sie in den Artikeln zu Benutzername und Kennwort für die Standardauthentifizierung und zur Überwachung von OAuth 2.0-basierten APIs.

Header

Die Option ermöglicht das Hinzufügen zusätzlicher benutzerdefinierter Header. Sie können z. B. den MIME-Typ der gesendeten Daten zusammen mit der Anforderung im Content-Type-Header definieren:

Content-Type: text/html

Wenn der Content-Type-Header nicht für die Anforderung angegeben ist, wird die Anforderung mit dem Standardinhaltstyp application/x-www-form-urlencodedgesendet.

The default User-Agent header is set to:

User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) DMBrowser/2.1 (SV)

However, the user-agent string can be replaced with any other string. To do this, add a custom header with the name “user-agent” and the specific value needed.

DNS-Optionen

Mit der Funktion DNS-Optionen können Benutzer auswählen, wie DNS-Anforderungen (Domain Name Server) während einer Überwachungsaufgabe ausgeführt werden. Geben Sie im Abschnitt Benutzerdefinierte DNS-Hosts benutzerdefinierte Zuordnungen von IP-Adressen zu Hostnamen an. Es kann sinnvoll sein, Ihre Websites während einer Migration einem Lasttest zu unterziehen. So können Sie Ihre Website auf einem neuen Server testen, während alle Ihre Benutzer sie weiterhin unter einer vertrauten IP-Adresse verwenden.

Beispiele:

192.168.107.246 example.com user.example.com userauth.example.com tools.example.com
192.168.107.246 example.com
192.168.107.246 user.example.com
192.168.107.246 userauth.example.com

Beachten Sie, dass die Option von LoadView On-site Agents nicht unterstützt wird. Detaillierte Richtlinien zum Einrichten von benutzerdefinierten DNS-Hosts für On-Site-Agenten finden Sie im Artikel Einrichten von benutzerdefinierten DNS-Hosts für Auslastungstests mit On-Site-Agent in unserer Knowledge Base.

Post (Put, Patch) Daten

Mit Dotcom-Monitor können Sie Nutzlasten in HTTP(S)-Anfragen (außer Trace-Anfragen) senden. Der Inhalt innerhalb des HTTP-Anforderungstextes kann als “Rohdaten” (JSON, XML usw.) oder als statische Namenswertsammlung (Formulardaten) gesendet werden.

Um mit einer Namenswertauflistung zu arbeiten, können Sie den detaillierten Eingabemodus aktivieren, indem Sie den Detaillierter-Switcher oben im Abschnitt verwenden und Anforderungsparameternamen und -werte im entsprechenden Feld angeben.

Um “Rohdaten” zusammen mit der Anforderung zu senden, z. B. ein JSON-Objekt, geben Sie Ihre JSON-Nutzlast in das Eingabefeld ein. Sie können den Anforderungstext auch dynamisch ändern. Wenn Sie z. B. das aktuelle Datum und die aktuelle Uhrzeit als Teil Ihrer POST-Anforderung senden oder die aktuelle Sitzungs-ID in der JSON-Nutzlast an einen Remoteserver übergeben müssen. Dotcom-Monitor ermöglicht das dynamische Ändern der Nutzlast von HTTP-Anforderungen mithilfe der Razor-Syntax und der Datenmasken.

  • Beispiel. Dynamischer JSON-Körper für HTTP-Post-Anforderungen

    Um besser zu verstehen, wie Dynamic JSON-Körper in der HTTP-Anforderung funktioniert, werfen wir einen Blick auf das folgende Beispiel. Angenommen, wir müssen einen Auftrag auf einer Website einreichen, und die Übermittlungstransaktion umfasst drei grundlegende Schritte, die sequenziell ausgeführt werden:

    1. einloggen
    2. Check-in
    3. Auftragseinreichung

    Um einen Test mit diesen Schritten einzurichten, die sequenziell ausgeführt werden, müssen wir drei HTTP-Tasks innerhalb eines Überwachungsgeräts (oder Auslastungstests, wenn Auslastungstests stattfinden) erstellen.

    Nehmen wir an, dass wir die aktuelle Uhrzeit und eine eindeutige GUID in der JSON mit der HTTP-Anforderung senden müssen, um mit der Anwendung einzuchecken. Um eine Bestellung zu senden, ist außerdem eine Benutzersitzungs-ID erforderlich, die bei der Anmeldung generiert wird, und eine Bestellzeit, die von der Anwendung benötigt wird.

    Um diesen Test zu implementieren, müssen wir zunächst eine Anmeldeanforderung mit grundlegenden Authentifizierungsparametern für den Webserver der Webanwendung konfigurieren. Als Nächstes müssen wir eine HTTP-Anforderung konfigurieren, um die tatsächliche Eincheckzeit und die eindeutige GUID zusammen mit einem JSON-Text zu übergeben. In diesem Beispiel geben wir die folgende Zeichenfolge mithilfe der Razor-Syntax im JSON-Text ein:

    { "CheckInTime": "@Model["CurrentTime"]", "GenGuid": "@Model["Guid"]" }

    Wo @Model[” < Parametername > “] auf einen erforderlichen Kontextparameternamen im Razor-Ausdruck verweist.

    Wir müssen die Kontextparameter deklarieren und angeben, wie die Post-Daten im Feld Skript vorbereiten verarbeitet werden sollen:

    context.Guid = Guid.NewGuid().ToString(); // uniq random string
context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\\Thh:mm:ss") + ".0Z"; // get current time in UTC
ProcessPostDataByRazor(currentTask); // the call to process the Post Data content with the Razor engine

    Das Ergebnis HTTP-Anforderung sieht ähnlich wie folgt aus:

    03:15:23
POST https://www.dotcom-monitor.com/CheckIn
{ "CheckInTime": "2021-03-30T08:15:22.0Z", "GenGuid": "5c5e3d23-66fd-49d0-bd57-62c516aea7e7" }

    Im nächsten Schritt müssen wir die HTTP-Anforderung so konfigurieren, dass eine Bestellung übermittelt wird. Dazu geben wir die aktuelle Uhrzeit und Sitzungs-ID der Bestellung zusammen mit der Modell-Identifikationsnummer des Elements im JSON-Text an den Zielendpunkt weiter. Siehe jsON-Stelle für diese Anfrage unten:

    { "OrderTime": "@Model["OrderTime"]",   "VIEWSTATE": "@Model["Session"]",  "ModelID": "2128506" }

    Um einen Wert der aktuellen Sitzungs-ID-Variablen zu übergeben, müssen wir ihn mithilfe der View State-Methode von der Anmeldeseite abrufen, die beim ersten Anmeldeschritt aufgerufen wird. Sie kann im Vorbereitungsskript codiert werden. Um die Denkzeit eines echten Benutzers zu simulieren, legen wir außerdem die Auftragszeitvariable mit einem Drei-Minuten-Offset fest. Daher enthält das Feld Skript vorbereiten die folgenden Zeichenfolgen:

    context.OrderTime = DateTime.Now.AddMinutes(3).ToUniversalTime().ToString("yyyy-MM-dd\\Thh:mm:ss") + ".0Z"; // order time + 3 min
context.Session = (Tasks["Login"] as Http).body["//INPUT[@ID='__VIEWSTATE']", "VALUE"]; // track state value from Login page 
ProcessPostDataByRazor(currentTask);

    Die resultierende HTTP-Anforderung sieht wie folgt aus:

    03:15:45
POST https://www.dotcom-monitor.com/Order
{ "OrderTime": "2021-03-30T08:18:45.0Z", "VIEWSTATE": "<Server Generated ViewState>", "ModelID": "2128506" }

Informationen zum Konfigurieren einer HTTP-Anforderung mit einer sich dynamisch ändernden Nutzlast finden Sie unter Dynamisches Ändern der Nutzlast in HTTP-Anforderung.

Vorbereiten von Skript und Postskript

Die Felder können Code enthalten, der für bestimmte POST-, GET-, URL-Daten oder für die Validierung oder Veröffentlichung benutzerdefinierter Header verwendet werden kann. Weitere Informationen zur Verwendung finden Sie im Artikel “Vorbereiten von Skripts und Postskripten”, oder wenden Sie sich an den technischen Support.

Nachdem das Auslastungstestgerät erstellt wurde, werden Sie aufgefordert, das Auslastungstestszenariozu konfigurieren.