So verwenden Sie URL-Query-Parameter

Query-Parameter zu einer Anfrage hinzufügen

Sie können Query-Parameter zu Ihrer Anfrage entweder in der URL oder im Feld Query-Parameter hinzufügen.

https://www.example.com?query1=value1&query2=value2
https://www.example.com?query1=value1&query2=value2#hash1
https://api.example.com/v2/resources/1?query1=value1&query2=value2

Beide Methoden sind gültig. Wenn Sie Query-Parameter sowohl in der URL als auch im Feld Query-Parameter hinzufügen, werden sie verkettet, und es werden alle Query-Parameter verwendet.

Warum Query-Parameter bei einem Lasttest wichtig sind

Query-Parameter sind Teil der Anfrage-URL, sodass der Server (und alles davor, wie ein CDN, Reverse Proxy oder WAF) sie als Teil dessen sieht, wonach gefragt wird. Das ist bei einem Lasttest in zwei Punkten relevant:

• Routing und Filterung: Viele APIs verwenden Query-Parameter, um eine Ressource, eine Seite oder einen Filter auszuwählen (?page=2, ?status=active, ?locale=en). Wenn Ihr Test immer nur eine Kombination von Parametern aufruft, testen Sie nur einen einzigen Codepfad. Ein Such-Endpunkt, der bei ?q=shoes schnell ist, kann sich bei ?q= (leer) oder einer Anfrage mit vielen gleichzeitig angewendeten Filtern ganz anders verhalten.
• Caching: Ein CDN oder Reverse Proxy behandelt üblicherweise die vollständige URL, einschließlich des Query-Strings, als Cache-Key. Wird ein Query-Parameter hinzugefügt, der sich bei jeder Anfrage ändert (ein Cache-Busting-Zeitstempel, eine zufällige ID), kann das versehentlich einen cachefähigen Endpunkt in einen verwandeln, der bei jedem einzelnen virtuellen Benutzer einen Cache-Miss erzeugt. Das sieht dann aus wie ein deutlich langsameres, deutlich stärker belastetes Backend, als es echter Produktions-Traffic je erzeugen würde, obwohl die eigentliche Ursache der Query-String selbst ist.

Statische Parameter vs. Werte pro Anfrage

Die Parameter, die Sie in eine Testanfrage eingeben, sind statisch: Jeder virtuelle Benutzer sendet bei jeder Iteration exakt denselben Query-String. Das ist für die meisten konzeptionellen Tests in Ordnung (Prüfen, ob sich ein Endpunkt korrekt verhält und unter Last schnell bleibt), aber behalten Sie zwei Dinge im Hinterkopf:

• Sie können einen Query-Parameter nicht "global" machen und ihn automatisch auf jede Anfrage im Test anwenden lassen, zum Beispiel einen API-Schlüssel, der als ?api_key=... übergeben wird. Er muss jeder Anfrage-URL (oder dem Feld Query-Parameter) einzeln hinzugefügt werden, wo immer er benötigt wird.
• Wenn der getestete Endpunkt pro Aufruf einen anderen Wert erwartet, einen Paginierungs-Cursor, eine eindeutige Bestell-ID, ein Einmal-Token, wird ein fester Query-String immer nur diesen einen Wert wiederholt ausüben. Echter Traffic trifft viele unterschiedliche Werte, sodass Ergebnisse auf Basis eines statischen Werts nur diesen einen Fall widerspiegeln, nicht die volle Bandbreite des Produktionsverhaltens.

Häufige Fallstricke

• URL-Encoding vergessen: Leerzeichen, &, = und andere reservierte Zeichen innerhalb eines Werts müssen prozentcodiert werden, sonst wird der String als zusätzliche Parameter statt als ein einzelner Wert geparst.
• Fragment mit Parameter verwechseln: Alles nach # (wie #hash1 im Beispiel oben) ist ein URL-Fragment, kein Query-Parameter. Browser behalten Fragmente clientseitig und senden sie nie an den Server, daher haben sie keine Auswirkung auf serverseitige Lasttests.
• Einen Parameter an beiden Stellen duplizieren: Da die Werte aus der URL und dem Feld Query-Parameter verkettet werden, sendet das Hinzufügen desselben Schlüssels an beiden Stellen ihn doppelt, was bei Servern, die pro Schlüssel nur einen Wert erwarten, zu abweichendem und unbeabsichtigtem Verhalten führen kann.

Weiterführende Hinweise finden Sie unter https://loadfocus.com/docs/de-de/knowledge-base/using-valid-url-endpoints und https://loadfocus.com/docs/de-de/guides/load-testing/how-to-url-query-parameters.