Bonjour,
Je travaille sur Squash TM avec Squash Orchestrator Community et j'ai une question sur le comportement du clonage Git lors de l'exécution d'un cas de test de type keyword driven.
Dans mon cas, j'ai un cas de test Classique qui appelle plusieurs autres cas de test Classiques (via la fonctionnalité "Appeler un cas de test"). Certains de ces cas de test appelés sont automatisés : ils ont leurs champs Technologie, URL SCM et Référence test automatisé renseignés, et pointent vers des scripts Robot Framework stockés dans un dépôt Git. Ces scripts s'exécutent dans un conteneur Docker.
Je comprends que lors de l'exécution, les cas de test appelés sont vus comme des pas de test du cas de test appelant. Mais au niveau de Squash Orchestrator, je ne sais pas exactement comment il traite ça :
Est-ce que l'Orchestrator traite l'ensemble du cas de test parent comme un seul job, et donc fait un seul git clone pour tous les action words automatisés qui pointent vers le même dépôt ?
Ou est-ce qu'il traite chaque cas de test appelé automatisé comme un job indépendant, et donc fait potentiellement un git clone pour chacun d'eux ?
Le but est d'éviter des clones Git entre chaque action word automatisé lors d'une même exécution, sachant que tous mes scripts sont dans le même dépôt.
J'ai cherché dans la documentation officielle (autom-devops-fr.doc.squashtest.com) mais je n'ai pas trouvé de réponse claire sur ce comportement spécifique aux tests keyword driven avec action words automatisés.
Merci d'avance pour votre aide.
Comportement git clone avec action words automatisés dans un test keyword driven
Re: Comportement git clone avec action words automatisés dans un test keyword driven
Bonjour,
La fonctionnalité "Appeler un cas de test" n'est représentative que pour le lancement des tests manuels au sein de l'interface SquashTM.
En effet, la description du cas de test, et son implémentation en tant que code pour les tests automatisés n'ont pas forcément à être corrélés.
Dans votre cas, uniquement le cas de test lancé sera exécuté. Il vous revient donc, d'adapter l'implémentation de votre script de test pour correspondre au fonctionnement voulu paramétré dans SquashTM.
Si votre cas de test appelle un autre dans votre interface SquashTM, votre script de cas de test automatisé doit donc préciser l'appel de ce cas de test afin que l'ensemble soit exécuté comme voulu. Cependant, les résultats dans SquashTM reviennent au cas de test source. Le job lancé par le Squash Orchestrator, ne voit lui que le cas de test lancé initialement, l'implémentation du script ne le concerne pas.
Le clone git effectue un clone du dépôt global, puis lancera les cas de tests de votre plan de test, un à un, sans se soucier de l'implémentation réelle. Le clone ne sera supprimé qu'après tous les cas de tests de votre plan de test ayant comme code source ce dépôt-ci. Il n'y a donc logiquement, qu'un clone réalisé, et qu'un seul job pour l'entièreté de ce dépôt. Si votre plan de test contient plusieurs dépôts, alors plusieurs jobs peuvent être créés, un par dépôt.
J'espère que ceci répond à vos interrogations.
Cordialement.
La fonctionnalité "Appeler un cas de test" n'est représentative que pour le lancement des tests manuels au sein de l'interface SquashTM.
En effet, la description du cas de test, et son implémentation en tant que code pour les tests automatisés n'ont pas forcément à être corrélés.
Dans votre cas, uniquement le cas de test lancé sera exécuté. Il vous revient donc, d'adapter l'implémentation de votre script de test pour correspondre au fonctionnement voulu paramétré dans SquashTM.
Si votre cas de test appelle un autre dans votre interface SquashTM, votre script de cas de test automatisé doit donc préciser l'appel de ce cas de test afin que l'ensemble soit exécuté comme voulu. Cependant, les résultats dans SquashTM reviennent au cas de test source. Le job lancé par le Squash Orchestrator, ne voit lui que le cas de test lancé initialement, l'implémentation du script ne le concerne pas.
Le clone git effectue un clone du dépôt global, puis lancera les cas de tests de votre plan de test, un à un, sans se soucier de l'implémentation réelle. Le clone ne sera supprimé qu'après tous les cas de tests de votre plan de test ayant comme code source ce dépôt-ci. Il n'y a donc logiquement, qu'un clone réalisé, et qu'un seul job pour l'entièreté de ce dépôt. Si votre plan de test contient plusieurs dépôts, alors plusieurs jobs peuvent être créés, un par dépôt.
J'espère que ceci répond à vos interrogations.
Cordialement.