DevOps intégration d’outils de test

L’intégration d’outils de test vous permet d’afficher les résultats des tests dans pour DevOpsJenkins, Azure DevOpsGitHub, GitHub Enterprise et des tests unitaires, fonctionnels et GitLab de performances.

Pour GitLab et Jenkins, seule l’intégration de type test JUnit est prise en charge.

Remarque :

Pour les autres types de test, utilisez le point de terminaison DevOps : POST /devops/tool/{capability} de l’API DevOps.

• Les tests Selenium exécutés et publiés à l’aide de TestNG sont signalés par le Jenkins plugin pour ServiceNow DevOps.
• La catégorisation des types de test est prise en charge.
• Les résultats des tests supplémentaires signalés par des outils, tels qu’Apache JMeter, peuvent être traités à DevOps l’aide de flux secondaires personnalisés Studio de workflow (aucune modification du pipeline n’est requise).

Catégorie	Type de test
Unité	JUnit (par défaut) NUnit XUnit Test unitaire Remarque : Pour GitLab et Jenkins, seule l’intégration du type de test JUnit est prise en charge. Pour ADO, GitHub et GitHub Enterprise, les intégrations de type test JUnit, NUnit, XUnit et Unit sont prises en charge. Vous pouvez modifier le type de test par défaut en modifiant le [sn_devops.default_test_type] DevOps property.
Fonctionnel	Intégration Régression Fumée Système Acceptation de l'utilisateur
Performances	Charge

Mappage de type de test

Le mappage de type de test connecte le type de test et l’entité testés avec l’outil DevOps (DevOps > Intégrations > Mappages de type de test module.)

Un mappage précis des types de test garantit que le type de test apparaît toujours comme prévu dans les résultats du résumé du test.

Champ		Description
Type de test		JUnit Nunit Xunit Test unitaire Remarque : Pour GitLab et Jenkins, seule l’intégration du type de test JUnit est prise en charge. Pour ADO, GitHub et GitHub Enterprise, les intégrations de type test JUnit, NUnit, XUnit et Unit sont prises en charge. Intégration Régression Fumée Système Acceptation de l'utilisateur Charge
ID de l'entité DevOps	Nom de la table	DevOps Nom de table contenant l’entité liée aux résultats des tests (dans la charge utile du rapport de test). Étape [sn_devops_step] Pipeline [sn_devops_pipeline] Remarque : Seules DevOps les tables d’étape et de pipeline sont prises en charge.
	Document	Nom de l’entité spécifiée dans la table sélectionnée. Par exemple, le nom de l’étape, du pipeline, de l’artefact ou du package.
Chemins d'accès aux fichiers de test Jenkins(tests uniquement)		Chemin d’accès au fichier de résultat des tests généré sur le Jenkins serveur. Ceci est utile pour que les rapports de test avec des attributs qui ne sont pas conformes à l’implémentation JUnit ou TestNG, tels que JMeter par exemple, puissent toujours être exploités par DevOps. Séparez plusieurs fichiers par une virgule. Remarque : Vous devez utiliser un Studio de workflow flux secondaire pour transformer une charge utile de test brute.
Intégration d'outils		Outil qui exécute le test.
Table DevOps		DevOps Table qui correspond au nom de la table dans le paramètre ID d’entité DevOps .

Figure 1. DevOps Mappage du type de test

Figure 2. Exemple de fichier yaml de test unitaire ADO

Figure 3. Exemple de fichier yaml de test unitaire GitHub

Transformation d’une charge utile de test brute

Vous pouvez transformer un rapport de test brut (un rapport contenant des attributs qui ne sont pas conformes à l’implémentation JUnit ou TestNG), tel que JMeter par exemple, en configurant la table de décision de politique de flux secondaire de test DevOps pour appeler un flux secondaire personnalisé (Tables de décision > Tables de décision module).

Remarque :

Vous devez créer le flux secondaire personnalisé Studio de workflow qui transforme la charge utile brute du test.

S’il existe plusieurs types de test dans une étape de performance, vous pouvez utiliser la table de décision de politique de type de test DevOps pour configurer le type de test pour chaque test afin que les charges utiles des résultats des tests soient transformées correctement.

Figure 4. DevOps Tables de décision

Tableau 1. DevOps Tables de décision

Table de décision	Objectif	Configuration
Politique de flux secondaire de test DevOps	Pour appeler automatiquement un flux secondaire personnalisé qui transforme la charge utile brute reçue par l’outil. Entrées de décision : Charge utile du résultat du test Type de test	Créez une décision qui spécifie le flux secondaire personnalisé à appeler lorsque la charge utile brute est reçue. Définissez les conditions pour contenir les champs qui sont inclus dans la charge utile brute. Par exemple, pour appeler Jenkins le flux secondaire personnalisé de test de performance BZ : Conditions : Le type de test est Chargement (Chargement est le type de test configuré pour les tests de performances) La charge utile du résultat du test contient le débit La charge utile du résultat du test contient la concurrence Réponse : FLow : Jenkins Test de performance BZ
Politique de type de test DevOps	Définir automatiquement les types de test lorsque plusieurs types de test sont configurés dans une étape de test de performance. Cela est nécessaire pour que les résultats du deuxième type de test soient transformés correctement. Par exemple, lorsqu’un test de performances de charge et un test de performances JUnit sont mappés dans la même DevOps étape, les résultats des tests JUnit ne sont pas formatés correctement à moins qu’une décision ne soit créée. Entrées de décision : Étape Charge utile du résultat du test Intégration d'outils Pipeline	Créez une décision pour chaque type de test à l’étape du test de performances afin de définir le type de test. Test de charge : Conditions : L’étape est Tests de performance La charge utile du résultat du test contient le débit La charge utile du résultat du test contient la concurrence Réponse : TestType : charger Test JUnit : Conditions : L’étape est Tests de performance La charge utile du résultat du test ne contient pas de débit La charge utile du résultat du test ne contient pas de concurrence Réponse : TestType : JUnit

Figure 5. DevOps Plusieurs types de tests de performances

Figure 6. DevOps Mappages de plusieurs types de test

Figure 7. DevOps Décision de la table de décision

Résultats de la synthèse du test

Vous pouvez afficher les résultats des résumés des tests de cette façon.

• DevOps > Résultats des tests (Résumés des tests et Résumés des tests de performances).
• Demande de changement DevOps : liste connexe Résultats des tests.
• DevOps Pipeline UI - Carrelage de qualité.

Figure 8. DevOps Exemple de résumé du test de performances

JSON standard attendu Charge utile de l’aptitude de notification : outil de test

Fonctionnel:

{ 
"name": "CorpSite-selenium#55", 
"duration": 78.802, 
"passedTests": 4, 
"failedTests": 0, 
"skippedTests": 0, 
"blockedTests": 0, 
"totalTests": 4, 
"startTime": "2020-06-30T18:12:31Z", 
"finishTime": "2020-06-30T18:12:31Z", 
"passingPercent": 100, 
 
 
// Use Artifact OR Package OR Build + Stage + PipelineName Attributes 

Send only one Attribute combination. For example, send Attributes of either  Artifact or Package, or the combination of Build + Stage + PipelineName.

If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.

1.packages
2.artifcats
3.buildNumber + stageName + pipelineName

"packages": [{"name": "CorpSite-pkg1"}], 
"artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}], 
"buildNumber": "55", 
"stageName": "test", 
"pipelineName": "CorpSite-selenium", 
} 

Notes:
- The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
- The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.

Performance:

{ 
"name": "Performance Tests", 
"url": "http://abc.com", 
"startTime": "2020-06-30T18:12:31Z", 
"finishTime": "2020-06-30T18:12:31Z", 
"duration": 78.802, 
"maximumVirtualUsers": "", 
"throughput": "", 
"maximumTime": "", 
"minimumTime": "", 
"averageTime": "", 
"ninetyPercent": "", 
"standardDeviation": "", 
 
// Use Artifact OR Package OR Build + Stage + PipelineName Attributes 

Send only one Attribute combination. For example, send Attributes of either  Artifact or Package, or the combination of Build + Stage + PipelineName.

If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.

1.packages
2.artifcats
3.buildNumber + stageName + pipelineName

"packages": [{"name": "CorpSite-pkg1"}], 
"artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}], 
"buildNumber": "55", 
"stageName": "test", 
"pipelineName": "CorpSite-Performance", 
} 

Notes:
- The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
- The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.

• Configurer un outil de test dans DevOps
  Configurez un outil de test dans pour DevOps afficher les résultats des tests unitaires, fonctionnels et de performances.
• Ajouter des résultats des tests aux demandes de changement à l’aide de l’API de test
  Ajoutez des résultats des tests aux DevOps demandes de changement à l’aide de l’aptitude de test de l’API DevOps : POST /devops/tool/{capability}. L’API est disponible pour tous les types de test pour divers outils connectés à Vélocité de changement DevOps.
• Ajouter des pièces jointes aux demandes de changement à l’aide de l’API de pièce jointe
  Ajoutez des rapports XML de test en tant que pièces jointes aux demandes de changement DevOps à l’aide de l’API de pièce jointe.