DevOps Intégration d’outils de test

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 6 minutes de lecture
  • L’intégration de l’outil de test vous permet d’afficher les résultats des tests pour DevOpsJenkins, Azure DevOps, GitHub, GitHub Enterprise et GitLab les tests unitaires, fonctionnels et de performances.

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

    Remarque :
    Pour les autres types de tests, 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 du type de test est prise en charge.
    • Les résultats des tests supplémentaires rapporté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 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 Unitaire sont prises en charge.

    Vous pouvez modifier le type de test par défaut en modifiant le paramètre [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ée à l’outil DevOps (DevOps > Intégrations > Mappages de type de test dans le module.)

    Mappages de type de test

    Un mappage précis du type de test garantit que le type de test s’affiche toujours comme prévu dans les résultats récapitulatifs des tests.

    Champ Description
    Type de test
    • JUnit
    • Par Nunit
    • Unité X
    • Test unitaire
      Remarque :
      • Pour GitLab 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 Unitaire 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 qui contient 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 les DevOps tables d’étapes et de pipelines 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 des résultats des tests généré sur le Jenkins serveur.

    C’est utile pour que les rapports de test avec des attributs qui ne sont pas conformes à l’implémentation de JUnit ou de TestNG, comme 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 de type de test
    Mappage de type de test DevOps
    Figure 2. Exemple de fichier yaml de test unitaire ADO
    Exemple de fichier yaml de test unitaire ADO
    Figure 3. Exemple de fichier yaml de test unitaire GitHub
    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 de JUnit ou de TestNG), tel que JMeter par exemple, en configurant la table de décision de la 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 de test brute.

    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 de chaque test afin que les charges utiles des résultats des tests soient transformées correctement.

    Figure 4. DevOps Tables de décision
    Tables de décision DevOps
    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 de sorte qu’elles contiennent des champs qui seront inclus dans la charge utile brute.

    Par exemple, pour appeler Jenkins le flux secondaire personnalisé Test des performances BZ :

    Conditions :
    • Le type de test est Chargement

      (La charge est le type de test configuré pour les tests de performances)

    • La charge utile du résultat de test contient le débit
    • Résultat du test La charge utile contient la concurrence

    Réponse : Flux : Jenkins Test de performance BZ

    DevOps : politique du type de test

    Pour définir automatiquement les types de test lorsque plusieurs types de tests sont configurés dans une étape de test de performance.

    Ceci 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 chargement 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 de test de performance afin de définir le type de test.

    Test de charge :
    • Conditions :
      • L’étape correspond à des tests de performance
      • La charge utile du résultat de test contient le débit
      • Résultat du test La charge utile contient la concurrence
    • Réponse : TestType : Charger

    Test JUnit :

    • Conditions :
      • L’étape correspond à des 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 la concurrence
    • Réponse : TestType : JUnit

    Figure 5. DevOps Plusieurs types de test de performance
    Types de tests de performance multiples DevOps
    Figure 6. DevOps Mappages de plusieurs types de tests
    Mappages de type de test DevOps
    Figure 7. DevOps Décision de la table de décision
    Décision de la table de décision DevOps

    Résultats du résumé du test

    Vous pouvez afficher les résultats récapitulatifs des tests de cette façon.
    Figure 8. DevOps Exemple de résumé du test de performances
    Résumé du test de performances DevOps

    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.