Aller au contenu

Pilotage de l’exécution de tests automatisés depuis Squash TM

Info

Afin de piloter l'exécution de tests automatisés depuis Squash TM, vous avez besoin des composants suivants :

  • Squash TM
  • Squash Orchestrator
  • Plugin Result Publisher pour Squash TM
  • Plugin Squash AUTOM pour Squash TM
  • Si exécution de cas de test Agilitest ou UFT : l'agent OpenTestFactory pour l'environnement d'exécution des tests Agilitest/UFT
  • Si exécution de cas de test Ranorex : l'agent OpenTestFactory pour l'environnement d'exécution des tests Ranorex, et le chemin vers le dossier contenant MSBuild.exe renseigné dans une variable d'environnement nommée SQUASH_MSBUILD_PATH

Automatisation d’un cas de test Squash TM

Info

Cette page décrit les opérations communes à tous les frameworks de test supportés par cette version. Pour faciliter la navigation vous pouvez directement consulter les spécificités de l'automatisation de chaque technologie grâce aux liens suivants :

Sans utilisation de workflow d’automatisation Squash

Pour qu’un cas de test soit utilisable par Squash Orchestrator, il faut que le bloc Automatisation de l’onglet Information de la page de consultation d’un cas de test soit correctement renseigné :

Espace automatisation

Espace automatisation

  • Technologie du test automatisé : Liste déroulante permettant de choisir la technologie utilisée pour exécuter le cas de test.

  • URL du dépôt de code source : L’adresse du dépôt de source où se trouve le projet, tel que spécifié dans l'espace Serveurs de partage de code source de l’Administration.

  • Référence du test automatisé : Correspond à l’emplacement du test automatisé dans le projet. Cette référence doit respecter un format propre à la technologie de test employée (voir ici).

Info

Agilitest, Ranorex et UFT ne sont supportés que par la version Premium de Squash AUTOM.

Avec utilisation de workflow d’automatisation Squash

Cas de test classique

Pour qu’un cas de test soit utilisable par Squash Orchestrator, il doit être automatisé à partir de l’espace Automatisation (Automaticien) via trois colonnes à renseigner :

Espace automatisation

  • Tech. test auto. : Liste déroulante permettant de choisir la technologie utilisée pour exécuter le cas de test.

  • URL du SCM : L’adresse du dépôt de source où se trouve le projet.

  • Ref. test auto. : Correspond à l’emplacement du test automatisé dans le projet. Cette référence doit respecter un format propre à la technologie de test employée (voir ici).

Espace automatisation

  • TECHNO. : Liste déroulante permettant de choisir la technologie utilisée pour exécuter le cas de test.

  • URL SCM : L’adresse du dépôt de source où se trouve le projet.

  • REF. TEST AUTO : Correspond à l’emplacement du test automatisé dans le projet. Cette référence doit respecter un format propre à la technologie de test employée (voir ici).

Info

Agilitest, Ranorex et UFT ne sont supportés que par la version Premium de Squash AUTOM.

Cas de test BDD ou Gherkin

Les informations du bloc Automatisation sont remplis automatiquement lors de la transmission d’un script BDD ou Gherkin à un gestionnaire de code source distant. Ils sont également modifiables à tout moment par l’utilisateur.

Exploitation de paramètres Squash TM

Au lancement d’un plan d’exécution Squash TM (via un PEaC ou directement depuis l'espace campagne), celui-ci transmet différentes informations sur les éléments du plan d'exécution qu’il est possible d’exploiter dans un cas de test. Les détails de cette fonctionnalité sont décrits dans la section correspondant à la technologie utilisée.

Info

Les technologies suivantes supportent l'exploitation des paramètres Squash TM au sein des cas de test :

Spécificités pour l’automatisation suivant le framework d’automatisation

Automatisation avec Agilitest

Cette fonctionnalité est disponible uniquement dans la version Premium de Squash AUTOM.

1. Référence du test

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

[1] / [2]

Avec :

  • [1] : Nom du projet sur le dépôt de source.

  • [2] : Chemin et nom du fichier de script ActionTestScript à partir de la racine du projet (avec son extension .ats).

Focus

Les scripts ATS doivent impérativement se trouver dans une arborescence de fichiers de la forme src/main/ats/* , conformément à l'architecture classique d'un projet ATS.

2. Nature des paramètres Squash TM exploitables

Les paramètres Squash TM exploitables dans un script ActionTestScript vont différer suivant si vous utilisez les composants Squash DEVOPS Community ou Squash DEVOPS Premium.

Voici le tableau des paramètres exploitables :

Nature Clé Community Premium
Nom du jeu de données DSNAME OK OK
Paramètre d'un jeu de données DS_[nom] OK OK
Référence du cas de test TC_REF OK OK
Champ personnalisé du cas de test TC_CUF_[code] OK OK
Champ personnalisé de l'itération IT_CUF_[code] KO OK
Champ personnalisé de la campagne CPG_CUF_[code] KO OK
Champ personnalisé de la suite de tests TS_CUF_[code] KO OK

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
3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec Agilitest d’exploiter des paramètres Squash TM au sein de celui-ci.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des champs personnalisés dans Squash TM et les associer au projet portant le plan de tests à exécuter.

  • S'assurer que les champs code des paramètres correspondent aux noms des variables d'environnement existants dans le script ActionTestScript.

Info

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.

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

agilitest-param-1

agilitest-param-2

agilitest-param-1

agilitest-param-2

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec ATS 2.1.4. Toute version récente devrait fonctionner.

Automatisation avec Cucumber

1. Référence du test

Info

Dans le cas où un nom de scénario n'est pas spécifié, le résultat de chaque exécution du cas de test Squash TM est calculé en prenant en compte les résultats individuels de chaque scénario inclus dans le fichier lié :

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

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

[1] / [2] # [3] # [4]

Avec :

  • [1] : Nom du projet sur le dépôt de source.

  • [2] : Chemin et nom du fichier de test Cucumber à partir de la racine du projet (avec son extension .feature).

  • [3] : Nom de la feature tel que renseigné dans le fichier de test Cucumber. Ce paramètre est optionnel.

  • [4] : Nom du scénario tel que renseigné dans le fichier de test Cucumber. Ce paramètre est optionnel.

2. Nature des paramètres Squash TM exploitables

Squash AUTOM et Squash DEVOPS sont capables d'exploiter le nom d'un jeu de données Squash TM d'un cas de test comme valeur d'un tag à utiliser pour l'exécution d'un sous-ensemble spécifique d'une feature Cucumber.

Cette exploitation est possible par les composants en version Community ou Premium.

3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec Cucumber d’exploiter un nom de jeu de données Squash TM pour n'exécuter qu'un jeu de données particulier d'un scénario Cucumber.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des jeux de données dans l'onglet Paramètres du cas de test dans Squash TM.

  • Créer au sein de son scénario Cucumber autant de tableaux exemple que de jeux de données et annoter ces tableaux d'un tag correspondant au nom d'un jeu de données Squash TM.

  • Créer une seule ligne d'éléments dans chaque tableau exemple afin de fixer une valeur pour les différents paramètres du scénario.

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

cucumber-tags-1

cucumber-tags-2

cucumber-tags-3

cucumber-tags-1

cucumber-tags-2

cucumber-tags-3

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec Cucumber-JVM 4.2.6. Certains utilisateurs ont reporté des problèmes avec Cucumber-JVM 6.X, ceux-ci vont être analysés.

Automatisation avec Cypress

1. Référence du test

Info

Dans cette version de Squash AUTOM il n'est pas possible de sélectionner un test spécifique dans un fichier .spec.js qui en contiendrait plusieurs : tous les tests du fichier sont donc exécutés ensemble.
Le résultat de chaque exécution du cas de test Squash TM est calculé en prenant en compte les résultats individuels de chaque test inclus dans le fichier lié :

  • 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é fonctionnelement 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.

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

[1] / [2]

Avec :

  • [1] : Nom du projet sur le dépôt de source.

  • [2] : Chemin et nom du fichier de test Cypress à partir de la racine du projet (avec son extension .spec.js).

2. Nature des paramètres Squash TM exploitables

Les paramètres Squash TM exploitables dans un script Cypress vont différer suivant si vous utilisez les composants Squash DEVOPS Community ou Squash DEVOPS Premium.

Voici le tableau des paramètres exploitables :

Nature Clé Community Premium
Nom du jeu de données DSNAME OK OK
Paramètre d'un jeu de données DS_[nom] OK OK
Référence du cas de test TC_REF OK OK
Champ personnalisé du cas de test TC_CUF_[code] OK OK
Champ personnalisé de l'itération IT_CUF_[code] KO OK
Champ personnalisé de la campagne CPG_CUF_[code] KO OK
Champ personnalisé de la suite de tests TS_CUF_[code] KO OK

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
3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec Cypress d’exploiter des paramètres Squash TM au sein de celui-ci.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des champs personnalisés dans Squash TM et les associer au projet portant le plan de tests à exécuter.

  • S'assurer que les champs code des paramètres correspondent aux noms des variables d'environnement existants dans le script Cypress.

Info

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.

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

cypress-params-1

cypress-params-2

cypress-params-1

cypress-params-2

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec Cypress 8.5.0. Toute version récente devrait fonctionner.

Automatisation avec JUnit

1; Référence du test

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

[1] / [2] # [3]

Avec :

  • [1] : Nom du projet sur le dépôt de source.

  • [2] : Nom qualifié de la classe de test.

  • [3] : Nom de la méthode à tester dans la classe de test. Ce paramètre est optionnel.

Ci-dessous un exemple de classe de test Junit et l’automatisation du cas de test Squash TM associé :

junit-1

junit-2

junit-1

junit-2

2. Nature des paramètres Squash TM exploitables

Les paramètres Squash TM exploitables dans un script JUnit vont différer suivant si vous utilisez les composants Squash DEVOPS Community ou Squash DEVOPS Premium.

Voici le tableau des paramètres exploitables :

Nature Clé Community Premium
Nom du jeu de données DSNAME OK OK
Paramètre d'un jeu de données DS_[nom] OK OK
Référence du cas de test TC_REF OK OK
Champ personnalisé du cas de test TC_CUF_[code] OK OK
Champ personnalisé de l'itération IT_CUF_[code] KO OK
Champ personnalisé de la campagne CPG_CUF_[code] KO OK
Champ personnalisé de la suite de tests TS_CUF_[code] KO OK

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
3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec JUnit d’exploiter des paramètres Squash TM au sein de celui-ci.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des champs personnalisés dans Squash TM et les associer au projet portant le plan de tests à exécuter.

  • Importer la libraire opentestfactory-java-param-library dans le projet JUnit contenant les tests à exécuter en ajoutant au fichier pom.xml :

    • le dépôt Maven suivant :
    <repositories>
    <repository>
        <id>org.squashtest.repo.release</id>
        <name>Squashtest repository for releases</name>
        <url>https://repo.squashtest.org/maven2/release</url>
    </repository>
</repositories>
    • la dépendance Maven suivante :
    <dependencies>
    <dependency>
        <groupId>org.opentestfactory.util</groupId>
        <artifactId>opentestfactory-java-param-library</artifactId>
        <version>1.0.0</version>
    </dependency>
</dependencies>

  • Vous pouvez ensuite récupérer la valeur d’un paramètre Squash TM du type souhaité en utilisant la syntaxe suivante :

ParameterService.INSTANCE.getString("paramName");
ParameterService.INSTANCE.getInt("paramName");
ParameterService.INSTANCE.getFloat("paramName");
ParameterService.INSTANCE.getDouble("paramName");
ParameterService.INSTANCE.getBoolean("paramName");

  • Les méthodes ci-dessus recherchent le paramètre souhaité dans les paramètres de tests transmis par Squash TM; si elles ne le trouvent pas, elles le cherchent ensuite dans les paramètres globaux transmis par Squash TM.
    Ces méthodes propagent une ParameterNotFoundException si le paramètre n'est pas trouvé. Si le paramètre est trouvé mais ne peut être converti dans le type souhaité, une ParameterFormatException est propagée. Pensez à gérer ces exception dans vos classes de tests.
    Attention: la conversion de données booléennes renvoie true lorsque la chaine de caractère à convertir est égale à "true" (quelqu'en soit la casse), false dans tous les autres cas; mais ne propage jamais d'exception.

  • Il est aussi possible de définir un paramètre par défaut dans le cas où le paramètre Squash TM n'est pas trouvé en utilisant la syntaxe suivante :

ParameterService.INSTANCE.getString("paramName", defaultValue);
ParameterService.INSTANCE.getInt("paramName", defaultValue);
ParameterService.INSTANCE.getFloat("paramName", defaultValue);
ParameterService.INSTANCE.getDouble("paramName", defaultValue);
ParameterService.INSTANCE.getBoolean("paramName", defaultValue);

  • Les méthodes ci-dessus ne propagent donc pas de ParameterNotFoundException quand le paramètre Squash TM recherché n'est pas trouvé mais propagent une ParameterFormatException si le paramètre Squash TM est bien trouvé, mais ne peut être converti dans le type souhaité.

  • Il est également possible de cibler un paramètre de tests ou un paramètre global avec des méthodes spécifiques. Comme pour les méthodes précedentes, elle sont disponibles dans des versions avec et sans paramètre par défaut. En voici quelques exemples :

ParameterService.INSTANCE.getTestString("paramName");
ParameterService.INSTANCE.getGlobalInt("paramName");
ParameterService.INSTANCE.getTestFloat("paramName", defaultValue);
ParameterService.INSTANCE.getGlobalBoolean("paramName", defaultValue);

Ci-dessous un exemple de fichier de test JUnit et l’automatisation du cas de test Squash TM associé :

junit-params-1

junit-params-2

junit-params-3

junit-params-1

junit-params-2

junit-params-3

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec

  • JUnit 4.12, toute version plus récente de JUnit 4 devrait fonctionner
  • JUnit 5.3.2, toute version de JUnit 5 devrait fonctionner

De plus, il est recommandé d'utiliser Surefire 2.19.1 ou supérieur.

Automatisation avec Ranorex

Cette fonctionnalité est disponible uniquement dans la version Premium de Squash AUTOM.

Les prérequis nécessaires pour l'utiliser sont l'installation de l'agent OpenTestFactory pour l'environnement d'exécution des tests Ranorex. De plus, le chemin vers le dossier contenant MSBuild.exe doit être renseigné dans une variable d'environnement nommée SQUASH_MSBUILD_PATH. Vous pouvez exécuter la commande suivante pour trouver le chemin vers votre exécutable MSBuild :

reg.exe query "HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0" /v MSBuildToolsPath
1. Référence du test

Pour lier un cas de test Squash TM à un test automatisé, le champ Référence du test automatisé du bloc Automatisation du cas de test doit avoir une forme spécifique au framework de test utilisé :

[1] / [2] # [3] # [4] # [5]

Avec :

  • [1] : Nom du projet sur le dépôt de source.

  • [2] : Chemin vers le fichier .sln de la solution à partir de la racine du projet sur le dépôt de source.

  • [3] : Nom du projet Ranorex à exécuter.

  • [4] : Nom de la suite de tests Ranorex à exécuter.

  • [5] : Nom du cas de test Ranorex à exécuter. Ce paramètre est optionnel.

2. Nature des paramètres Squash TM exploitables

Voici le tableau des paramètres exploitables :

Nature Clé
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_REF
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
3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec Ranorex d’exploiter des paramètres Squash TM au sein de celui-ci.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des champs personnalisés dans Squash TM et les associer au projet portant le plan de tests à exécuter.

  • S'assurer que les champs code des paramètres correspondent aux noms des paramètres existants dans la solution Ranorex.

Info

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.

Ci-dessous un exemple de solution Ranorex et l’automatisation du cas de test Squash TM associé :

ranorex-params-1

ranorex-params-2

ranorex-params-1

ranorex-params-2

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec Ranorex 9.5. Toute version récente devrait fonctionner.

Automatisation avec Robot Framework

1. Référence du test

Pour lier un cas de test Squash TM à un test automatisé, le champ Référence du test automatisé du bloc Automatisation du cas de test doit avoir une forme spécifique au framework de test utilisé :

[1] / [2] # [3]

Avec :

  • [1] : Nom du projet sur le dépôt de source.

  • [2] : Chemin et nom du fichier de test Robot Framework à partir de la racine du projet (avec son extension .robot).

  • [3] : Nom du cas de test à exécuter dans le fichier .robot.

2. Nature des paramètres Squash TM exploitables

Les paramètres Squash TM exploitables dans un script Robot Framework vont différer suivant si vous utilisez les composants Squash DEVOPS Community ou Squash DEVOPS Premium.

Voici le tableau des paramètres exploitables :

Nature Clé Community Premium
Nom du jeu de données DSNAME OK OK
Paramètre d'un jeu de données DS_[nom] OK OK
Référence du cas de test TC_REF OK OK
Champ personnalisé du cas de test TC_CUF_[code] OK OK
Champ personnalisé de l'itération IT_CUF_[code] KO OK
Champ personnalisé de la campagne CPG_CUF_[code] KO OK
Champ personnalisé de la suite de tests TS_CUF_[code] KO OK

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
3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec Robot Framework d’exploiter des paramètres Squash TM au sein de celui-ci.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des champs personnalisés dans Squash TM et les associer au projet portant le plan de tests à exécuter.

  • Installer sur le/les environnement(s) d’exécution Robot Framework la librairie python squash-tf-services. Elle est accessible par le gestionnaire de package pip et peut s’installer en exécutant la ligne de commande suivante :

python -m pip install squash-tf-services
  • Importer la librairie au sein du fichier .robot dans la section Settings :
Library squash_tf.TFParamService
  • Vous pouvez ensuite récupérer la valeur d’un paramètre Squash TM en faisant appel au mot-clef suivant :
Get Param <clé du paramètre>

Ci-dessous un exemple de fichier de test Robot Framework et l’automatisation du cas de test Squash TM associé :

robot-params-1

robot-params-2

robot-params-1

robot-params-2

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec Robot Framework 4.0. Toute version récente devrait fonctionner.

Automatisation avec SKF

1. Référence du test

Pour lier un cas de test Squash TM à un test automatisé, le champ Référence du test automatisé du bloc Automatisation du cas de test doit avoir une forme spécifique au framework de test utilisé :

[1] / [2] . [3] # [4]

Avec :

  • [1] : Chemin du dossier SKF racine (qui contient le fichier pom.xml) sur le dépôt de source.

  • [2] : Écosystème de tests par défaut du projet SKF (tests).

  • [3] : Sous écosytème de tests (il est possible d'en rajouter plusieurs en les séparant par un .; ce paramètre est optionnel).

  • [4] : Nom du script de test à exécuter ( avec son extension .ta; ce paramètre est obligatoire)

2. Nature des paramètres Squash TM exploitables

Les paramètres Squash TM exploitables dans un script SKF vont différer suivant si vous utilisez les composants Squash DEVOPS Community ou Squash DEVOPS Premium.

Voici le tableau des paramètres exploitables :

Nature Clé Community Premium
Nom du jeu de données DSNAME OK OK
Paramètre d'un jeu de données DS_[nom] OK OK
Référence du cas de test TC_REF OK OK
Champ personnalisé du cas de test TC_CUF_[code] OK OK
Champ personnalisé de l'itération IT_CUF_[code] KO OK
Champ personnalisé de la campagne CPG_CUF_[code] KO OK
Champ personnalisé de la suite de tests TS_CUF_[code] KO OK

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
3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec SKF d’exploiter des paramètres Squash TM au sein de celui-ci.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des champs personnalisés dans Squash TM et les associer au projet portant le plan de tests à exécuter.

  • Faire appel aux paramètres désirés dans les fichiers utilisés par votre test SKF via la syntaxe ${clé}

  • Au sein du test SKF, appeler la commande pour remplacer au sein d'un fichier les références des paramètres par les valeurs transmises à l'exécution.
    La commande à utiliser est de la forme CONVERT {resourceToConvert<Res:file>} TO file (param) USING context_global_params, context_script_params AS {converted<Res:file>}

Info

Retrouvez plus d'informations sur l'utilisation des paramètres dans un test SKF dans sa documentation

Ci-dessous un exemple de projet SKF exploitant un paramètre dans un fichier xml et l’automatisation du cas de test Squash TM associé :

skf-params-1

skf-params-3

skf-params-2

skf-params-1

skf-params-3

skf-params-2

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec SKF 1.14.0.

Automatisation avec SoapUI

Référence du test

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

[1] / [2] # [3] # [4]

Avec :

  • [1] : Nom du projet sur le dépôt de source.

  • [2] : Chemin et nom du fichier de test SoapUI à partir de la racine du projet (avec son extension .xml).

  • [3] : Nom de la Suite de test SoapUI contenant le cas de test.

  • [4] : Nom du cas de test à exécuter.

Ci-dessous un exemple de fichier de test SoapUI et l’automatisation du cas de test Squash TM associé :

soapui-1

soapui-2

soapui-1

soapui-2

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec SoapUI 5.6.0. Toute version récente devrait fonctionner.

Automatisation avec UFT

Cette fonctionnalité est disponible uniquement dans la version Premium de Squash AUTOM.

Le prérequis nécessaire pour l'utiliser est l'installation de l'agent OpenTestFactory pour l'environnement d'exécution des tests UFT.

Attention

Les Service Tests UFT ne sont pas supportés dans la version actuelle de Squash AUTOM/Squash DEVOPS.

Focus

Pour la remontée d'information vers Squash TM, UFT doit être configuré pour générer un rapport au format RRV.

uft-report-format

1. Référence du test

Pour lier un cas de test Squash TM à un test automatisé, le champ Référence du test automatisé du bloc Automatisation du cas de test doit avoir une forme spécifique au framework de test utilisé :

[1]

Avec :

  • [1] : Chemin vers le dossier du test à exécuter.
2. Nature des paramètres Squash TM exploitables

Voici le tableau des paramètres exploitables :

Nature Clé
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_REF
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
3. Utilisation de paramètres Squash TM

Il est possible lors de l’exécution d’un cas de test Squash TM automatisé avec UFT d’exploiter des paramètres Squash TM au sein de celui-ci.

Pour cela, il faut suivre les étapes suivantes :

  • Renseigner des champs personnalisés dans Squash TM et les associer au projet portant le plan de tests à exécuter.

  • S'assurer que les champs code des paramètres correspondent aux noms des paramètres existants dans le test UFT.

Ci-dessous un exemple de projet UFT et l’automatisation du cas de test Squash TM associé :

uft-params-1

uft-params-2

uft-params-1

uft-params-2

4. Versions supportées

Squash AUTOM et Squash DEVOPS ont été validés avec UFT 15.0.2. Toute version récente devrait fonctionner.

Exécution d'une suite automatisée

L'exécution d'un plan d'exécution automatisée se déroule de la façon habituelle dans Squash TM :

  • Accédez au plan d'exécution de l'itération ou de la suite de test choisie.

  • Exécutez les tests automatisés en utilisant un des boutons de l'image ci-dessous :

test-plan

test-plan

  • Une popup de suivi d'exécution apparaît.

Info

La popup de suivi contient une nouvelle section qui rappelle le nom des tests en cours d'exécution par Squash Orchestrator. Cependant il n'y a pas de suivi d'avancement dans la version actuelle.

Remontées de résultats après exécution d’un plan d’exécution Squash TM

Quelle que soit la façon dont le plan d’exécution est déclenché (depuis Squash TM ou depuis un pipeline Jenkins), vous avez en fin d’exécution une remontée de résultats au sein de Squash TM qui diffère suivant si vous êtes sous licence Community ou Premium.

Squash AUTOM Community

Après exécution d’un plan d’exécution Squash TM (itération ou suite de tests), les informations suivantes sont mises à jour :

  • Mise à jour du statut des ITPI (Iteration Test Plan Item, voir le glossaire Squash TM).

  • Mise à jour du statut de la suite automatisée.

  • Le rapport au format Allure correspondant à l'ensemble des tests exécutés.

  • Les rapports d’exécution des différents ITPI sont accessibles depuis l’onglet de consultation des suites automatisées :

automated-suite-tab

automated-suite-tab

Info

Tous les résultats de la suite automatisée sont compilés dans un rapport au format Allure, disponible dans la liste de rapports sous forme d'archive .tar.

Pour plus d'information sur la façon d'exploiter ce rapport et les possibilités de personnalisation, veuillez consulter la documentation Allure.

Cependant, voici ce qu’il ne se passe pas :

  • Création d’une nouvelle exécution pour chaque ITPI qui a été exécuté.

Squash AUTOM Premium

Si vous disposez des composants Squash AUTOM Premium, vous avez accès à deux types de remontées d’informations :

  • Légère (valeur par défaut).

  • Complète.

Le choix du type de remontée se fait par projet en accédant à la configuration du plugin Squash TM Result Publisher depuis l’onglet Plugins de la page de consultation d’un projet :

plugin-configuration

plugin-configuration

Remontée d’information Légère

En choisissant la remontée d’information Légère, les informations suivantes sont mises à jour après exécution d’un plan d’exécution Squash TM (itération ou suite de tests) :

  • Mise à jour du statut des ITPI.

  • Mise à jour du statut de la suite automatisée.

  • Le rapport au format Allure correspondant à l'ensemble des tests exécutés.

  • Les rapports d’exécution des différents ITPI sont accessibles depuis l’onglet de consultation des suites automatisées :

automated-suite-tab

automated-suite-tab

Info

Tous les résultats de la suite automatisée sont compilés dans un rapport au format Allure, disponible dans la liste de rapports sous forme d'archive .tar.
Pour plus d'information sur la façon d'exploiter ce rapport et les possibilités de personnalisation, veuillez consulter la documentation Allure.

Cependant, voici ce qu’il ne se passe pas :

  • Création d’une nouvelle exécution pour chaque ITPI qui a été exécuté.

Remontée d’information Complète

En choisissant la remontée d’information Complète, les informations suivantes sont mises à jour après exécution d’un plan d’exécution Squash TM (itération ou suite de tests) :

  • Mise à jour du statut des ITPI.

  • Création d’une nouvelle exécution pour chaque ITPI.

  • Mise à jour du statut de la suite automatisée.

  • Le rapport au format Allure correspondant à l'ensemble des tests exécutés.

  • Les rapports d’exécution des différentes exécutions sont accessibles depuis l’onglet de consultation des suites automatisées ou depuis l’écran de consultation de l’exécution (ils sont présents dans les pièces jointes).

iteration-execution-tab

iteration-execution-detail

iteration-execution-tab

iteration-execution-detail

Info

Tous les résultats de la suite automatisée sont compilés dans un rapport au format Allure, disponible dans la liste de rapports sous forme d'archive .tar.
Pour plus d'information sur la façon d'exploiter ce rapport et les possibilités de personnalisation, veuillez consulter la documentation Allure.

Retour en haut de la page