Automatiser des tests avec Squash DEVOPS

Squash AUTOM permet de lancer l’exécution des tests automatisés d’une itération, à partir de l’interface de Squash TM. Comment puis-je faire la même chose à partir de ma chaîne d’intégration continue ?

Je dispose de Squash TM, avec une campagne et une itération définie, et j’ai au moins un cas de test automatisé.

Je dispose en plus de Squash DEVOPS, et j’ai une chaîne d’intégration continue, aussi (ce peut être Jenkins, GitLab CI, GitHub Actions, ou autre chose).

Structure d’un workflow (ou “plan d’exécution as code” ou “PEaC”)

Un workflow est un fichier YAML qui contient obligatoirement au moins deux éléments : un nom et un job.

metadata:
  name: mon premier workflow
jobs:
  mon_premier_job:
    ...

Un workflow peut contenir d’autres éléments, mais ces autres éléments ne sont pas indispensables.

Le nom permet d’identifier le workflow. Il sera utilisé pour reconnaître mon workflow.

Le job indique quoi faire.

Mon premier job

Ici, je veux exécuter une itération en provenance de mon gestionnaire de cas de test, Squash TM.

Mon job va faire appel à un plugin de l’orchestrateur Squash, tm.squashtest.org/tm.generator@v1, qui va se charger de dialoguer avec mon Squash TM.

Ce plugin fait partie de Squash DEVOPS. Il prend quelques paramètres qui se répartissent en deux catégories :

1. Ce qu’il doit faire
2. Les coordonnées de l’instance Squash TM avec laquelle il va discuter

Ce que le job doit faire

Ce plugin sait faire deux choses : (1) exécuter les cas de tests d’une itération et (2) exécuter les cas de tests d’une suite de test.

Le premier paramètre, testPlanType, peut prendre deux valeurs, Iteration ou TestSuite.

Le second paramètre, testPlanUuid, identifie l’itération ou la suite de tests qui sera exécutée. Cet identifiant unique se trouve dans le bloc Information de mon itération, dans Squash TM.

Les coordonnées de l’instance Squash TM

Les coordonnées de l’instance Squash TM avec laquelle il va discuter comportent trois parties : son adresse, le compte et le mot de passe à utiliser.

En résumé

La définition du job ressemblera à ceci :

mon_premier_job:
  generator: tm.squashtest.org/tm.generator@v1
  with
    testPlanType: Iteration
    testPlanUuid: 1e2ae123-6b67-44b2-b229-274ea17ad489
    squashTMUrl: https://mySquashTMInstance.org/squash
    squashTMAutomatedServerLogin: tfserver
    squashTMAutomatedServerPassword: tfserver

Ce n’est pas parfait (comme j’ai le compte et plus encore le mot de passe de mon instance Squash TM, je ne peux pas stocker ce fichier dans mon gestionnaire de code source favori), mais cela va me permettre de vérifier que tout va bien.

Mon premier déclenchement d’une itération

Mon workflow est donc un fichier qui a pour contenu :

metadata:
  name: mon premier workflow
jobs:
  mon_premier_job:
    generator: tm.squashtest.org/tm.generator@v1
    with:
      testPlanType: Iteration
      testPlanUuid: 1e2ae123–6b67–44b2-b229–274ea17ad489
      squashTMUrl: https://mySquashTMInstance.org/squash
      squashTMAutomatedServerLogin: tfserver
      squashTMAutomatedServerPassword: tfserver

Je peux lui donner le nom que je veux. Par convention, je vais lui donner le nom ‘Squashfile’ (mais c’est juste ça, une convention).

Je vais donc pouvoir lancer l’exécution des cas de test de mon itération via la commande suivante depuis mon poste de travail (mon instance de l’orchestrateur Squash a été déployée avec docker-compose et est accessible via l’URL http://orchestrator.squash) :

curl -X POST \
    --data-binary @Squashfile \
    -H "Authorization: Bearer <yourtoken>" \
    -H "Content-type: application/x-yaml" \
    http://orchestrator.squash/workflows

Cette commande va me retourner l’identifiant de mon workflow. Je pourrais m’en servir pour suivre son déroulé.

Pour voir l’avancement, je peux lancer la commande suivante :

curl -X POST \
    -H "Authorization: Bearer <yourtoken>" \
    http://orchestrator.squash/workflows/<workflow_id>/status

Si tout se passe bien, une fois mes tests exécutés, je dois voir les résultats dans Squash TM, associés à mon itération.

Ajout à ma chaîne d’intégration continue

Si tout s’est bien passé, je suis prêt à ajouter cette étape d’exécution d’une itération à ma chaîne d’intégration continue.

(1) je déclenche l’exécution du workflow, (2) l’orchestrateur interroge Squash TM, (3) Squash TM retourne la liste des cas de tests, (4) après exécution, l’orchestrateur publie les résultats dans Squash TM, (5) la chaîne d’intégration continue peut se poursuivre.

Pour cela, je dois faire deux choses : retirer les secrets (ici, le mot de passe qui permet de se connecter à Squash TM, et le token si je passe par la commande curl pour déclencher les opérations) et ajouter mon workflow dans mon gestionnaire de code source.

Je n’aurai plus alors qu’à ajouter une étape dans ma chaîne d’intégration continue pour déclencher l’exécution de l’itération.

Pour les secrets, je vais passer par des variables d’environnement. Selon l’outil que j’utilise pour mon intégration continue, cela pourra avoir un nom un peu différent, mais le principe sera a priori toujours présent.

Je vais donc définir deux secrets, ORCHESTRATOR_TOKEN et SQUASHTM_PWD.

Je vais ensuite modifier mon workflow pour qu’il référence cette variable d’environnement (SQUASHTM_PWD) :

metadata:
  name: mon premier workflow
jobs:
  mon_premier_job:
    generator: tm.squashtest.org/tm.generator@v1
    with:
      testPlanType: Iteration
      testPlanUuid:
      squashTMUrl: https://mysquashtminstance.org/squash
      squashTMAutomatedServerLogin: tfserver
      squashTMAutomatedServerPassword: ${{ variables.SQUASHTM_PWD }}

La notation ${{ variables.SQUASHTM_PWD }} va, à l’exécution, être remplacée par la valeur de l’expression, ici, le contenu de la variable d’environnement SQUASHTM_PWD.

Je pourrais aussi variabiliser l’UUID de l’itération, ou même le type de plan de test.

Je peux maintenant ajouter ce fichier dans mon gestionnaire de code.

git add Squashfile
git commit -m "Ajout workflow Squash DEVOPS"

Il ne me reste plus qu’à ajouter une étape dans ma chaîne d’intégration continue. Comme j’utilise Jenkins, mon pipeline va ressembler à cela :

pipeline {
  agent { label 'agent' }
  environment {
    ORCHESTRATOR_TOKEN = credentials('squash-devops-token')
    SQUASHTM_PWD = credentials('squash-tm-password')
  }
  stages{
    stage('Build'){
      // ...
    }
    // ...
    stage('Tests automatisés'){
      sh '''
      curl -X POST \
        -H "Authorization: Bearer ${ORCHESTRATOR_TOKEN}" \
        -H "Content-type: application/x-yaml" \
        -F workflow=@Squashfile \
        -F variables="SQUASHTM_PWD=${SQUASHTM_PWD}" \
        http://orchestrator.squash/workflows
      '''
    }
    // ...
  }
}

Je n’ai pas utilisé ici le plugin Jenkins, ni opentf-ctl, pour que l’exemple soit facilement adaptable si j’utilisais un autre outil pour ma chaîne d’intégration continue, mais, en pratique, je l’utiliserais.

Et voilà, à chaque fois que ma chaîne d’intégration continue se déclenche, les tests de mon itération sont exécutés, et je peux voir les résultats dans Squash TM. Et si je modifie la composition de cette itération, les exécutions ultérieures incluront ces modifications.

Martin Lafaix
Architecte

En savoir plus :

SQUASH - Squash DEVOPS pour l'extension du CI/CD et le test en continu

SQUASH - Roadmap & releases Squash DEVOPS