Un test de charge HTTP(S) génère des demandes simultanées vers une seule URL. Il vérifie l’URL cible pour le contenu approprié, les erreurs et les liens cassés. Il prend en charge les demandes POST et GET, les cookies, les soumissions de formulaires, les en-têtes personnalisés, les sites sécurisés par mot de passe (autorisation HTTP/HTTPS de base ainsi que les mécanismes d’autorisation des cookies/scripts) et les seuils de délai d’attente. Le test de charge HTTP(S) prend en charge les protocoles IPv4 et IPv6.

Vous pouvez convertir les paramètres de demande HTTP(S) en paramètres contextaux pour passer dans les valeurs, par exemple, récupérées à partir d’une réponse d’une autre demande dans le périphérique de test de charge. Vous pouvez configurer les paramètres de contexte de l’URL, des en-têtes, du contenu de demande (pour les méthodes Post, Put, Patch) et des scripts de préparation et de publication. Pour plus de détails, voir Comment utiliser les paramètres de contexte dans les requêtes HTTP(S).

Url

Entrez l’URL que vous souhaitez tester. L’adresse doit être formée exactement comme vous l’utiliseriez dans un navigateur, comme http://www.example.com. Vous devez inclure le http:// ou https:// au début de l’adresse. Vous pouvez inclure tous les paramètres GET à la fin de votre URL.

Seuil de validation temporelle (en secondes)

Entrez le nombre de secondes pendant lesquelles le système doit attendre une réponse de la ressource cible avant de renvoyer une erreur. Si ce délai est laissé vide, le délai d’attente par défaut est de 120 secondes.

Type de demande

Dans le champ Type de demande , vous pouvez sélectionner l’une des méthodes HTTP les plus couramment utilisées pour envoyer des demandes de surveillance à une page Web. Si vous devez envoyer une charge utile avec des requêtes HTTP, fournissez-la dans le champ correspondant (voir le chapitre Corps de la requête pour plus de détails). La charge utile peut être spécifiée et envoyée avec tous les types de demandes, à l’exception de Trace (RFC2616).

Url Redirige

Si l’option Suivez redirections est définie sur Oui,le système suivra le chemin de l’URL envoyée avec la réponse 301 et considérera chaque redirection comme une demande HTTP distincte. Il vous permet de suivre la chaîne de redirection complète (tous les liens que la demande est redirigée à travers) dans les résultats des tests, y compris les temps de réponse à la fois pour l’URL initiale et les réponses ultérieures.

Nous vous recommandons de laisser l’option Follow Redirects activée si vous avez besoin de tester non seulement l’URL initiale, mais toutes les URL de la chaîne. Par exemple, il peut être utile d’effectuer une vérification de certificat SSL pour chaque URL d’une chaîne de redirection.

Dans les cas où vous souhaitez tester une URL initiale uniquement, désactiver l’option Suivez redirections.

Notez qu’une limite de redirection par défaut est définie à 10 redirections. Si vous souhaitez que le système exécute un nombre particulier de redirections (moins de 10), vous pouvez spécifier le nombre d’URL que vous souhaitez tester dans votre chaîne de redirection dans le champ Préparer le script :

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

Où N est le nombre d’emplacements de redirection que nous voulons suivre. Pour ne pas suivre les redirections, il suffit de définir le nombre d’emplacements de redirection vers 0.

Validation du contenu

Les mots clés de validation de contenu sont utilisés pour s’assurer que le contenu attendu a été chargé sur une page Web. Dans les champs Mots clés, vous pouvez spécifier un ou plusieurs mots ou expressions que vous souhaitez rechercher dans le contenu de la page Web. Si les mots clés attendus ne sont pas trouvés, la tâche retournera une erreur.

Vous pouvez entrer plusieurs chaînes dans les champs de mots clés. Les valeurs que vous entrez peuvent être séparées par des expressions logiques comme suit :

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

où:
{[ – début de l’expression des mots clés;
]} – fin de l’expression des mots clés;
() – crochets de regroupement;
et – logique ET;
| – ou logique;
! – logique NON;
«string» – un mot clé.

Une expression de mot clé réussie doit inclure les supports de début et de fin comme suit :

{["keyword"]}

Authentification de base

Le schéma d’authentification de base est utilisé pour permettre aux utilisateurs d’accéder au contenu de certains sites Web. Une fois fournis, les identifiants de connexion seront transmis avec l’en-tête de la demande au serveur Web.

  • Nom d’utilisateur : contient un nom d’utilisateur pour l’authentification d’accès de base ou digeste HTTP/S.
  • Mot de passe utilisateur : contient un mot de passe pour l’authentification d’accès de base ou digeste HTTP/S.

Ne confondez pas l’authentification de base avec d’autres schémas d’authentification tels que l’authentification du porteur qui implique des jetons porteurs et OAuth 2.0 qui utilise des jetons d’accès.

Lisez les articles sur le nom d’utilisateur et le mot de passe d’authentification de base et surveillez les API basées sur OAuth 2.0 pour plus d’informations.

En-têtes

L’option permet d’ajouter des en-têtes personnalisés supplémentaires. Par exemple, vous pouvez définir le type MIME des données envoyées avec la demande dans l’en-tête de type contenu :

Content-Type: text/html

Si l’en-tête de type contenu n’est pas spécifié pour la demande, la demande sera envoyée avec l’application de type de contenu par défaut/x-www-form-urlencoded.

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 Options

La fonction Options DNS permet aux utilisateurs de choisir comment les demandes de serveur de noms de domaine (DNS) sont effectuées au cours d’une tâche de surveillance. Dans la section Hôtes DNS personnalisés , spécifiez les mappages personnalisés des adresses IP aux noms d’hôte. Il peut être utile de tester la charge de vos sites Web lors d’une migration. Ainsi, vous pouvez tester votre site Web sur un nouveau serveur pendant que tous vos utilisateurs continuent à l’utiliser sur une adresse IP familière.

Exemples:

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

Notez que l’option n’est pas prise en charge par les agents LoadView sur site. Pour obtenir des instructions détaillées sur la configuration d’hôtes DNS personnalisés pour l’agent sur site, consultez l’article Comment configurer des hôtes DNS personnalisés pour les tests de charge avec l’agent sur site de notre base de connaissances.

Publier (Put, Patch) Les données

Dotcom-Monitor vous permet d’envoyer des charges utiles dans les requêtes HTTP(S) (à l’exception des requêtes Trace). Le contenu de l’organisme de demande HTTP peut être envoyé sous forme de données « brutes » (JSON, XML, etc.) ou de collecte statique de valeur nommative (Données de formulaire).

Pour travailler avec une collection de valeur nom-valeur, vous pouvez activer le mode d’entrée détaillé en utilisant l’interrupteur détaillé en haut de la section et fournir des noms de paramètres de demande et des valeurs dans le champ correspondant.

Pour envoyer des données « brutes » avec la demande, comme un objet JSON, entrez votre charge utile JSON dans le champ d’entrée. Vous pouvez également modifier dynamiquement le corps de demande. Par exemple, si vous devez envoyer la date et l’heure actuelles dans le cadre de votre demande POST ou passer l’ID de session en cours dans la charge utile JSON à un serveur distant. Dotcom-Monitor permet de modifier dynamiquement la charge utile de la demande HTTP en utilisant la syntaxe Razor et les masques de données.

  • exemple. Organe JSON dynamique pour les demandes de poste HTTP

    Pour mieux comprendre comment fonctionne le corps Dynamic JSON dans la demande HTTP, jetons un coup d’œ coup d’œuvre à l’exemple suivant. Supposons que nous devons soumettre une commande sur un site Web et que la transaction de soumission comprend trois étapes de base exécutées séquentiellement :

    1. connectez-vous
    2. enregistrement
    3. Soumission de commande

    Pour configurer un test avec ces étapes exécutées séquentiellement, nous devons créer trois tâches HTTP au sein d’un seul dispositif de surveillance (ou test de charge, si des tests de charge ont lieu).

    Supposons que nous devons envoyer l’heure actuelle et un GUID unique dans le JSON avec la demande HTTP pour vérifier avec l’application. En outre, pour soumettre une commande, un ID de session utilisateur généré lors de la connexion et un temps de commande est requis par l’application.

    Pour implémenter ce test, nous devons d’abord configurer une demande de connexion avec des paramètres d’authentification de base sur le serveur Web de l’application Web. Ensuite, nous devons configurer une demande HTTP pour passer l’heure d’enregistrement réelle et guid unique avec un organisme JSON. Pour cet exemple, nous entreons la chaîne suivante à l’aide de la syntaxe Razor dans le corps JSON :

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

    Lorsque @Model[» Nom de < paramètre > «] fait référence à un nom de paramètre de contexte nécessaire dans l’expression Razor.

    Nous devons déclarer les paramètres du contexte et préciser comment les données postales doivent être traitées dans le champ Préparer le script :

    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

    La demande HTTP de résultat ressemblera à ceci :

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

    Dans l’étape suivante, nous devons configurer la demande HTTP pour soumettre une commande. Pour ce faire, nous transmettons l’heure actuelle de l’ordre et l’ID de session, ainsi que le numéro d’identification du modèle de l’élément, dans l’organisme JSON au point de terminaison cible. Voir l’organisme JSON pour cette demande ci-dessous:

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

    Pour passer une valeur de la variable d’identification de session en cours, nous devons la récupérer à partir de la page de connexion, appelée à la première étape de connexion, en utilisant la méthode Afficher l’état. Il peut être codé dans le script de préparation. En outre, pour simuler le temps de réflexion d’un utilisateur réel, nous allons définir la variable de temps de commande avec un décalage de trois minutes. Par conséquent, le champ Préparer le script contiendra les chaînes suivantes :

    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);

    La demande HTTP qui en résultera ressemblera à ceci :

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

Pour savoir comment configurer une demande HTTP avec une charge utile en évolution dynamique, voir Comment modifier dynamiquement la charge utile dans la demande HTTP.

Préparer le script et poster le script

Les champs peuvent contenir du code C#, qui peut être utilisé pour des données POST, GET, URL spécifiques ou pour valider ou publier des en-têtes personnalisés. Veuillez consulter l’article Using Prepare Script and Post Script ou contacter le support technique pour plus de détails sur l’utilisation.

Une fois que le dispositif de test de charge a été créé, vous serez invité à configurer le scénario de test de charge.