Automatisation avec Postman

Le support de Postman est disponible à partir de Squash TM 3.0.

Configuration de l'environnement d'exécution

newman et son générateur de rapports HTML (newman-reporter-html) doivent être présents dans l'environnement d'exécution.

Ils peuvent être installés avec les commandes :

npm install -g newman
npm install -g newman-reporter-html

(Si npm n'est pas disponible, vous devez télécharger et installer Node.js.)

Référence du test dans Squash TM

Pour lier un cas de test Squash TM à un test automatisé Postman, le champ Référence du test automatisé du bloc Automatisation du cas de test doit avoir la forme suivante :

[dépôt]/[collection]#[dossier]#[requête]
ou
[dépôt]/[collection]#[dossier]
ou
[dépôt]/[collection]
(La référence contient zéro, un ou deux caractères #.)

avec :

[dépôt] : Nom du dépôt Git.
[collection] : Chemin et nom du fichier de collection Postman à partir de la racine du projet (avec son extension .postman_collection.json).

Non support du renommage des fichiers de collection

Squash Orchestrator considère que le nom du fichier permet de déterminer le nom de la collection, c'est-à-dire que si le fichier s'appelle <name>.postman_collection.json, alors la collection est considérée comme nommée <name>. Squash Orchestrator utilise ce nom <name> pour analyser le rapport d'exécution et déterminer le résultat du test.
Si le fichier de collection a été renommé, ce mécanisme ne fonctionnera plus.
[dossier] : Nom d'un répertoire spécifique dans la collection (option --folder de Newman).
Ce paramètre est optionnel, c'est-à-dire que les deux derniers composants de la référence du test peuvent être absents.
Il est également possible d'y indiquer une chaîne vide et de préciser un nom de requête (dans [requête]).
[requête] : Nom d'une requête spécifique à parser pour laquelle on désire obtenir un résultat en particulier.
Ce paramètre est optionnel, c'est-à-dire qu'il peut être absent.

Référence du test automatisé et exécution

La précision de la requête [requête] dans la référence du test n'influe pas sur l'exécution, mais sur la détermination du résultat du test.
Ainsi, même en définissant une granularité à l'échelle de la requête, la totalité des requêtes contenues dans le répertoire (si [dossier] est défini) ou dans la collection (si [dossier] est vide) sera exécutée ; ce qui signifie, par exemple, que si plusieurs cas de test Squash TM pointent vers le même répertoire / la même collection mais vers des requêtes différentes, toutes les requêtes du répertoire / de la collection seront exécutées plusieurs fois.
Les rapports de test contiennent les traces de toutes les requêtes exécutées. Par contre, seuls les statuts Error / Failed / Success correspondant à cette granularité fine seront considérés pour définir le résultat du cas de test.

Détermination du résultat du cas de test

Si une requête [requête] n'est pas spécifiée, le résultat du cas de test Squash TM est calculé en prenant en compte les résultats individuels de chaque requête Postman incluse dans le répertoire [dossier] s'il est défini, dans la collection [collection] entière sinon :

Si au moins un test est en statut Error (dans le cas d'un problème technique), l'exécution sera en statut Blocked.
Si au moins un test a échoué fonctionnellement et qu'aucun test n'est en statut Error, l'exécution sera en statut Failed.
Si tous les tests ont réussi, l'exécution sera en statut Success.

Unicité du répertoire spécifique

Si le répertoire racine du projet contient plusieurs répertoires ayant pour nom [dossier], Newman n'exécutera que le premier qu'il trouve. Il est donc fortement conseillé de choisir des noms uniques pour les répertoires de plus bas niveau.

Nature des paramètres Squash TM exploitables

Les paramètres Squash TM exploitables vont différer suivant si vous utilisez les composants Community/Premium ou Ultimate de Squash.

Voici le tableau des paramètres exploitables (ces paramètres sont transmis en tant que paramètres de test, voir ci-dessous, Squash TM ne génère pas de paramètres globaux) :

Nature	Clé	Community/Premium	Ultimate
Nom du jeu de données	DSNAME	✅	✅
Paramètre d'un jeu de données	DS_[nom]	✅	✅
ID d'exécution	TC_EXECUTION_ID	❌	✅
Référence du cas de test	TC_REFERENCE	✅	✅
UUID interne du cas de test	TC_UUID	✅	✅
Champ personnalisé du cas de test	TC_CUF_[code]	✅	✅
Champ personnalisé de l'itération	IT_CUF_[code]	❌	✅
Champ personnalisé de la campagne	CPG_CUF_[code]	❌	✅
Champ personnalisé de la suite de tests	TS_CUF_[code]	❌	✅

Légende :

[code] : valeur renseignée dans le champ “Code” d’un champ personnalisé
[nom] : nom du paramètre tel que renseigné dans Squash TM

Disponibilité de l'ID d'exécution

TC_EXECUTION_ID est disponible uniquement avec Squash TM 8.0 ou une version ultérieure.

Comme indiqué, Squash TM ajoute un préfixe au code du champ personnalisé transmis. Assurez-vous de le prendre en compte.

Voir la documentation de Squash TM pour plus d'information sur les champs personnalisés.

Utilisation de paramètres

Il est possible lors de l’exécution d’un test Postman d’exploiter des paramètres au sein de celui-ci. Un paramètre peut être un paramètre de test ou un paramètre global. Squash TM ne transmet que des paramètres de test. Des paramètres de test et des paramètres globaux peuvent être utilisés dans le cas d'un lancement à partir d'un pipeline CI/CD avec l'action postman/params.

Les paramètres globaux sont transmis en tant que global variables.
Les paramètres de test sont transmis en tant que environment variables.
Voir la documentation de Postman où sont décrits ces types de variables et comment les utiliser.
Cela signifie que

la valeur d'un paramètre global peut être récupérée grâce à pm.globals.get("param_name")
la valeur d'un paramètre de test peut être récupérée grâce à pm.environment.get("param_name")
la valeur d'un paramètre global ou d'un paramètre de test peut être récupérée grâce à la syntaxe {{param_name}} ; si un paramètre global et un paramètre de test ont tous deux pour nom param_name, la valeur du paramètre de test est utilisée

Exemple

Ci-dessous un exemple d'un fichier de collection Postman et l’automatisation du cas de test Squash TM associé :

Exemple Postman

Ajout de paramètres sur la ligne de commande de lancement d'un test

Il est possible de passer des paramètres supplémentaires à la commande newman run en utilisant la variable d'environnement POSTMAN_EXTRA_OPTIONS. La définition d'une variable d'environnement dans Squash TM et son association à l'orchestrateur sont exemplifiées ici.

Certains paramètres sont déjà définis dans la commande newman run utilisée pour lancer un test :

newman run \
  "{collection_path}"  \
  -g _opentf_global_params.json -e _opentf_environment_params.json \
  --reporters junit,html \
  --reporter-junit-export newman-run-report.xml \
  --reporter-html-export newman-run-report.html $POSTMAN_EXTRA_OPTIONS

Il faut éviter de passer, via la variable d’environnement POSTMAN_EXTRA_OPTIONS, des paramètres sur la ligne de commande qui sont en conflit avec ceux déjà utilisés ou qui impactent la création ou la localisation des rapports attendus par l’orchestrateur (voir leur liste ici).

Non support du caractère espace sur Linux

Squash Orchestrator ne supporte aujourd'hui pas le caractère espace () dans la variable d’environnement POSTMAN_EXTRA_OPTIONS pour les tests exécutés dans un environnement d'exécution Linux.

Versions supportées

Squash a été validé avec Postman 8.12.1. Toute version récente devrait fonctionner.