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
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] | ✅ | ✅ |
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
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 nomparam_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é :
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.