Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Tests avec des flux de travail
Dans CodeCatalyst, vous pouvez exécuter des tests dans le cadre de différentes actions de flux de travail, telles que la création et le test. Ces actions de flux de travail peuvent toutes générer des rapports de qualité. Une *action de test* est une action de flux de travail qui produit des rapports de test, de couverture de code, d'analyse de la composition logicielle et d'analyse statique. Ces rapports sont affichés dans la CodeCatalyst console.
**Topics**
+ [Types de rapports sur la qualité](#test-reporting)
+ [Ajouter l'action de test](test-add-action.md)
+ [Afficher les résultats d'une action de test](test-view-results.md)
+ [Ignorer les tests ayant échoué dans une action](test.error-handling.md)
+ [Intégration avec universal-test-runner](test.universal-test-runner.md)
+ [Configuration des rapports de qualité dans une action](test-config-action.md)
+ [Bonnes pratiques en matière de tests](test-best-practices.md)
+ [Propriétés SARIF prises en charge](test.sarif.md)
## Types de rapports sur la qualité
L'action de CodeCatalyst test Amazon prend en charge les types de rapports de qualité suivants. Pour un exemple de mise en forme de ces rapports dans votre fichier YAML, consultez[Exemple de rapports de qualité YAML](test-config-action.md#test.success-criteria-example).
**Topics**
+ [Rapports d'essais](#test-reports)
+ [Rapports de couverture du code](#test-code-coverage-reports)
+ [Rapports d'analyse de la composition des logiciels](#test-sca-reports)
+ [Rapports d'analyse statiques](#test-static-analysis-reports)
### Rapports d'essais
Dans CodeCatalyst, vous pouvez configurer des tests unitaires, des tests d'intégration et des tests système exécutés pendant les builds. CodeCatalyst Vous pouvez ensuite créer des rapports contenant les résultats de vos tests.
Vous pouvez utiliser un rapport de test pour résoudre les problèmes liés à vos tests. Si vous disposez de nombreux rapports de test provenant de plusieurs versions, vous pouvez utiliser vos rapports de test pour afficher les taux d'échec afin de vous aider à optimiser vos versions.
Vous pouvez utiliser les formats de fichier de rapport de test suivants :
+ Concombre JSON (.json)
+ JUnit XML (.xml)
+ NUnit XML (.xml)
+ NUnit3 XML (.xml)
+ TestNG XML (.xml)
+ Visual Studio TRX (.trx, .xml)
### Rapports de couverture du code
Dans CodeCatalyst, vous pouvez générer des rapports de couverture de code pour vos tests. CodeCatalyst fournit les mesures de couverture du code suivantes :
Couverture de ligne
Mesure le nombre de déclarations couvertes par vos tests. Une instruction est une instruction unique, sans les commentaires.
`line coverage = (total lines covered)/(total number of lines)`
Couverture de branche
Mesure le nombre de branches couvertes par vos tests parmi toutes les branches possibles d'une structure de contrôle, telle qu'une `case` instruction `if` or.
`branch coverage = (total branches covered)/(total number of branches)`
Les formats de fichier de rapport de couverture du code suivants sont pris en charge :
+ JaCoCo XML (.xml)
+ SimpleCov [JSON (généré par [simplecov, pas par simplecov-json](https://github.com/simplecov-ruby/simplecov), .json)](https://github.com/vicentllongo/simplecov-json)
+ Clover XML (version 3, .xml)
+ Couverture XML (.xml)
+ LCOV (.info)
### Rapports d'analyse de la composition des logiciels
Dans CodeCatalyst, vous pouvez utiliser les outils d'analyse de la composition logicielle (SCA) pour analyser les composants de votre application et vérifier les vulnérabilités de sécurité connues. Vous pouvez découvrir et analyser les rapports SARIF qui détaillent les vulnérabilités de gravité variable et les moyens de les corriger. Les valeurs de gravité valides, de la plus sévère à la moins sévère, sont les suivantes : `CRITICAL``HIGH`,`MEDIUM`,`LOW`,,`INFORMATIONAL`.
Les formats de fichier de rapport SCA suivants sont pris en charge :
+ SARIF (.sarif, .json)
### Rapports d'analyse statiques
Vous pouvez utiliser des rapports d'analyse statique (SA) pour identifier les défauts du code au niveau de la source. Dans CodeCatalyst, vous pouvez générer des rapports SA pour aider à résoudre les problèmes liés à votre code avant de le déployer. Ces problèmes incluent des bogues, des failles de sécurité, des problèmes de qualité et d'autres vulnérabilités. Les valeurs de gravité valides, de la plus sévère à la moins sévère, sont les suivantes : `CRITICAL` `HIGH``MEDIUM`,`LOW`,, et`INFORMATIONAL`.
CodeCatalyst fournit les métriques SA suivantes :
Insectes
Identifie un certain nombre de bogues potentiels trouvés dans votre code source. Ces bogues peuvent inclure des problèmes liés à la sécurité de la mémoire. Voici un exemple de bogue.
```
// The while loop will inadvertently index into array x out-of-bounds
int x[64];
while (int n = 0; n <= 64; n++) {
x[n] = 0;
}
```
Failles de sécurité
Identifie un certain nombre de failles de sécurité possibles détectées dans votre code source. Ces failles de sécurité peuvent inclure des problèmes tels que le stockage de vos jetons secrets en texte clair.
Problèmes de qualité
Identifie un certain nombre de problèmes de qualité potentiels trouvés dans votre code source. Ces problèmes de qualité peuvent inclure des problèmes liés aux conventions de style. Voici un exemple de problème de qualité.
```
// The function name doesn't adhere to the style convention of camelCase
int SUBTRACT(int x, int y) {
return x-y
}
```
Autres vulnérabilités
Identifie un certain nombre d'autres vulnérabilités possibles détectées dans votre code source.
CodeCatalyst prend en charge les formats de fichier de rapport SA suivants :
+ PyLint (.py)
+ ESLint (.js, .jsx, .ts, .tsx)
+ SARIF (.sarif, .json)
# Ajouter l'action de test
Utilisez la procédure suivante pour ajouter une action de test à votre CodeCatalyst flux de travail.
------
#### [ Visual ]
**Pour ajouter une action de test à l'aide de l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Choisissez **Actions**.
1. Dans **Actions**, sélectionnez **Test**.
1. Dans les onglets **Entrées** et **Configuration**, complétez les champs en fonction de vos besoins. Pour obtenir une description de chaque champ, consultez le[Créez et testez des actions YAML](build-action-ref.md). Cette référence fournit des informations détaillées sur chaque champ (et la valeur de propriété YAML correspondante) tel qu'il apparaît dans les éditeurs YAML et visuels.
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**Pour ajouter une action de génération à l'aide de l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Choisissez **Actions**.
1. Dans **Actions**, sélectionnez **Test**.
1. Modifiez les propriétés du code YAML en fonction de vos besoins. Une explication de chaque propriété disponible est fournie dans le[Créez et testez des actions YAML](build-action-ref.md).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
## Définition de l'action de test
L'action de test est définie comme un ensemble de propriétés YAML dans votre fichier de définition de flux de travail. Pour plus d'informations sur ces propriétés, consultez [Créez et testez des actions YAML](build-action-ref.md) le[Définition du flux de travail YAML](workflow-reference.md).
# Afficher les résultats d'une action de test
Utilisez les instructions suivantes pour afficher les résultats d'une action de test, y compris les journaux, les rapports et les variables générés.
**Pour afficher les résultats d'une action de test**
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Dans le diagramme du flux de travail, choisissez le nom de votre action de test, par exemple **Test**.
1. Pour afficher les journaux générés par une action, choisissez **Logs**. Les journaux des différentes phases d'action sont affichés. Vous pouvez agrandir ou réduire les journaux selon vos besoins.
1. Pour afficher les rapports de test produits par l'action de test, choisissez **Rapports**, ou dans le volet de navigation, sélectionnez **Rapports**. Pour de plus amples informations, veuillez consulter [Types de rapports sur la qualité](test-workflow-actions.md#test-reporting).
1. Pour afficher la configuration utilisée pour l'action de test, choisissez **Configuration**. Pour de plus amples informations, veuillez consulter [Ajouter l'action de test](test-add-action.md).
1. Pour afficher les variables utilisées par l'action de test, sélectionnez **Variables**. Pour de plus amples informations, veuillez consulter [Utilisation de variables dans les flux de travail](workflows-working-with-variables.md).
# Ignorer les tests ayant échoué dans une action
Si votre action comporte plusieurs commandes de test, vous souhaiterez peut-être autoriser les commandes de test suivantes à s'exécuter même si une commande précédente échoue. Par exemple, dans les commandes suivantes, vous souhaiterez peut-être toujours `test2` exécuter, même en cas d'`test1`échec.
```
Steps:
- Run: npm install
- Run: npm run test1
- Run: npm run test2
```
Normalement, lorsqu'une étape renvoie une erreur, Amazon CodeCatalyst arrête l'action du flux de travail et la marque comme ayant échoué. Vous pouvez autoriser la poursuite des étapes d'action en redirigeant le résultat d'erreur vers`null`. Vous pouvez le faire en ajoutant `2>/dev/null` à la commande. Avec cette modification, l'exemple précédent ressemblerait à ce qui suit.
```
Steps:
- Run: npm install
- Run: npm run test1 2>/dev/null
- Run: npm run test2
```
Dans le second extrait de code, le statut de la `npm install` commande sera respecté, mais toute erreur renvoyée par la `npm run test1` commande sera ignorée. Par conséquent, la `npm run test2` commande est exécutée. Ainsi, vous pouvez consulter les deux rapports en même temps, qu'une erreur se produise ou non.
# Intégration avec universal-test-runner
Les actions de test s'intègrent à l'outil `universal-test-runner` de ligne de commande open source. `universal-test-runner`utilise le [protocole d'exécution des tests](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md) pour exécuter vos tests pour n'importe quel langage dans un framework donné. `universal-test-runner`prend en charge les frameworks suivants :
+ [Gradle](https://gradle.org/)
+ [Jest](https://jestjs.io/)
+ [Maven](https://maven.apache.org/)
+ [pytest](https://pytest.org)
+ [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/)
`universal-test-runner` est installé uniquement sur les images sélectionnées pour les actions de test. Si vous configurez une action de test pour utiliser un Docker Hub personnalisé ou Amazon ECR, vous devez installer manuellement `universal-test-runner` pour activer les fonctionnalités de test avancées. Pour ce faire, installez Node.js (14 ou supérieur) sur l’image, puis installez `universal-test-runner` via `npm` à l’aide de la commande shell `- Run: npm install -g @aws/universal-test-runner`. Pour plus d'informations sur l'installation de Node.js dans votre conteneur via des commandes shell, consultez la section [Installation et mise à jour du gestionnaire de versions de Node](https://github.com/nvm-sh/nvm#install--update-script).
Pour plus d’informations sur `universal-test-runner`, consultez [Qu’est-ce que universal-test-runner ?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner)
------
#### [ Visual ]
**À utiliser universal-test-runner dans l'éditeur visuel**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Choisissez **Actions**.
1. Dans **Actions**, sélectionnez **Test**.
1. Dans l'onglet **Configuration**, complétez le champ des **commandes Shell** en mettant à jour l'exemple de code avec les frameworks pris en charge de votre choix. Par exemple, pour utiliser un framework pris en charge, vous devez utiliser une `Run` commande similaire à la suivante.
```
- Run: run-tests
```
Si le cadre que vous souhaitez n’est pas pris en charge, envisagez de fournir un adaptateur ou runner personnalisé. Pour une description du champ de **commandes Shell**, consultez[Steps](build-action-ref.md#build.configuration.steps).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
#### [ YAML ]
**À utiliser universal-test-runner dans l'éditeur YAML**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez le nom de votre flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Choisissez **Actions**.
1. Dans **Actions**, sélectionnez **Test**.
1. Modifiez le code YAML en fonction de vos besoins. Par exemple, pour utiliser un framework pris en charge, vous devez utiliser une `Run` commande similaire à la suivante.
```
Configuration:
Steps:
- Run: run-tests
```
Si le cadre que vous souhaitez n’est pas pris en charge, envisagez de fournir un adaptateur ou runner personnalisé. Pour une description de la propriété **Steps**, voir[Steps](build-action-ref.md#build.configuration.steps).
1. (Facultatif) Choisissez **Valider** pour valider le code YAML du flux de travail avant de le valider.
1. Choisissez **Valider**, entrez un message de validation, puis choisissez à nouveau **Valider**.
------
# Configuration des rapports de qualité dans une action
Cette section décrit comment configurer un rapport de qualité dans le cadre d'une action.
**Topics**
+ [Découverte automatique et rapports manuels](#test.auto-discovery)
+ [Configuration des critères de réussite pour les rapports](#test.success-criteria)
+ [Exemple de rapports de qualité YAML](#test.success-criteria-example)
## Découverte automatique et rapports manuels
Lorsque la découverte automatique est activée, CodeCatalyst recherche toutes les entrées transmises à l'action et tous les fichiers générés par l'action elle-même, à la recherche de rapports de test, de couverture de code, d'analyse de la composition logicielle (SCA) et d'analyse statique (SA). Vous pouvez consulter et manipuler chacun de ces rapports dans CodeCatalyst.
Vous pouvez également configurer manuellement les rapports qui sont générés. Vous pouvez spécifier le type de rapport que vous souhaitez générer ainsi que le format de fichier. Pour de plus amples informations, veuillez consulter [Types de rapports sur la qualité](test-workflow-actions.md#test-reporting).
## Configuration des critères de réussite pour les rapports
Vous pouvez définir les valeurs qui déterminent les critères de réussite d'un test, d'un rapport de couverture du code, d'analyse de la composition logicielle (SCA) ou d'un rapport d'analyse statique (SA).
Les critères de réussite sont des seuils qui déterminent si un rapport est réussi ou non. CodeCatalyst génère d'abord votre rapport, qui peut être un rapport de test, de couverture de code, SCA ou SA, puis applique les critères de réussite aux rapports générés. Il indique ensuite si les critères de réussite ont été remplis et dans quelle mesure. Si un rapport ne répond pas aux critères de succès spécifiés, l' CodeCatalyst action qui a spécifié les critères de réussite échoue.
Par exemple, lorsque vous définissez les critères de réussite de votre rapport SCA, les valeurs de vulnérabilité valides, allant de la plus grave à la moins grave, sont les suivantes : `CRITICAL``HIGH`,, `MEDIUM``LOW`,`INFORMATIONAL`. Si vous définissez les critères d'analyse d'une vulnérabilité en termes de `HIGH` gravité, le rapport échouera s'il existe au moins une vulnérabilité grave ou aucune vulnérabilité grave, mais au moins une vulnérabilité de niveau de gravité supérieur, telle qu'une vulnérabilité de `CRITICAL` gravité supérieure. `HIGH` `HIGH`
Si vous ne spécifiez aucun critère de réussite, alors :
+ Le CodeCatalyst rapport généré sur la base de vos rapports bruts n'affichera aucun critère de réussite.
+ Les critères de réussite ne seront pas utilisés pour déterminer si l'action de flux de travail associée est réussie ou échoue.
------
#### [ Visual ]
**Pour configurer les critères de réussite**
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez un flux de travail contenant une action qui génère un rapport. Il s'agit du rapport pour lequel vous souhaitez appliquer des critères de réussite. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **Visual**.
1. Dans le diagramme du flux de travail, choisissez l'action que vous avez configurée pour générer des CodeCatalyst rapports.
1. Choisissez l'onglet **Outputs**.
1. Sous **Rapports de découverte automatique** ou sous **Configuration manuelle des rapports**, sélectionnez **Critères de réussite**.
Les critères de réussite apparaissent. En fonction de vos sélections précédentes, vous pouvez voir l'une ou l'ensemble des options suivantes :
**Taux de réussite**
Spécifiez le pourcentage de tests dans un rapport de test qui doivent être réussis pour que le CodeCatalyst rapport associé soit marqué comme réussi. Les valeurs valides incluent les nombres décimaux. Par exemple `50`, `60.5`. Les critères de taux de réussite ne sont appliqués qu'aux rapports de test. Pour plus d'informations sur les rapports de test, consultez[Rapports d'essais](test-workflow-actions.md#test-reports).
**Couverture de ligne**
Spécifiez le pourcentage de lignes d'un rapport de couverture de code qui doivent être couvertes pour que le CodeCatalyst rapport associé soit marqué comme transmis. Les valeurs valides incluent les nombres décimaux. Par exemple `50`, `60.5`. Les critères de couverture de ligne sont appliqués uniquement aux rapports de couverture de code. Pour plus d'informations sur les rapports de couverture du code, consultez[Rapports de couverture du code](test-workflow-actions.md#test-code-coverage-reports).
**Couverture des succursales**
Spécifiez le pourcentage de branches dans un rapport de couverture de code qui doivent être couvertes pour que le CodeCatalyst rapport associé soit marqué comme transmis. Les valeurs valides incluent les nombres décimaux. Par exemple `50`, `60.5`. Les critères de couverture des succursales sont appliqués uniquement aux rapports de couverture par code. Pour plus d'informations sur les rapports de couverture du code, consultez[Rapports de couverture du code](test-workflow-actions.md#test-code-coverage-reports).
**Vulnérabilités (SCA)**
Spécifiez le nombre maximum et la gravité des vulnérabilités autorisées dans le rapport SCA pour que le CodeCatalyst rapport associé soit marqué comme transmis. Pour définir les vulnérabilités, vous devez spécifier :
+ La gravité minimale des vulnérabilités que vous souhaitez inclure dans le décompte. Les valeurs valides, de la plus sévère à la moins sévère, sont les suivantes : `CRITICAL``HIGH`,`MEDIUM`,`LOW`,,`INFORMATIONAL`.
Par exemple, si vous le souhaitez`HIGH`, `HIGH` les `CRITICAL` vulnérabilités seront comptabilisées.
+ Le nombre maximum de vulnérabilités de la gravité spécifiée que vous souhaitez autoriser. Le dépassement de ce nombre entraîne le marquage CodeCatalyst du rapport comme ayant échoué. Les valeurs valides sont des nombres entiers.
Les critères de vulnérabilité sont appliqués uniquement aux rapports SCA. Pour plus d'informations sur les rapports SCA, consultez[Rapports d'analyse de la composition des logiciels](test-workflow-actions.md#test-sca-reports).
**Insectes**
Spécifiez le nombre maximum et la gravité des bogues autorisés dans le rapport SA pour que le CodeCatalyst rapport associé soit marqué comme passé. Pour spécifier les bogues, vous devez spécifier :
+ La gravité minimale des bogues que vous souhaitez inclure dans le décompte. Les valeurs valides, de la plus sévère à la moins sévère, sont les suivantes : `CRITICAL``HIGH`,`MEDIUM`,`LOW`,,`INFORMATIONAL`.
Par exemple, si vous le souhaitez`HIGH`, `HIGH` les `CRITICAL` bogues seront comptabilisés.
+ Le nombre maximum de bogues de la gravité spécifiée que vous souhaitez autoriser. Le dépassement de ce nombre entraîne le marquage CodeCatalyst du rapport comme ayant échoué. Les valeurs valides sont des nombres entiers.
Les critères relatifs aux bogues s'appliquent uniquement aux rapports PyLint et ESLint SA. Pour plus d'informations sur les rapports SA, consultez[Rapports d'analyse statiques](test-workflow-actions.md#test-static-analysis-reports).
**Failles de sécurité**
Spécifiez le nombre maximum et la gravité des vulnérabilités de sécurité autorisées dans le rapport SA pour que le CodeCatalyst rapport associé soit marqué comme transmis. Pour spécifier les failles de sécurité, vous devez spécifier :
+ La gravité minimale des failles de sécurité que vous souhaitez inclure dans le décompte. Les valeurs valides, de la plus sévère à la moins sévère, sont les suivantes : `CRITICAL``HIGH`,`MEDIUM`,`LOW`,,`INFORMATIONAL`.
Par exemple, si vous le souhaitez`HIGH`, `HIGH` les failles `CRITICAL` de sécurité seront prises en compte.
+ Le nombre maximum de failles de sécurité de la gravité spécifiée que vous souhaitez autoriser. Le dépassement de ce nombre entraîne le marquage CodeCatalyst du rapport comme ayant échoué. Les valeurs valides sont des nombres entiers.
Les critères relatifs aux vulnérabilités de sécurité s'appliquent uniquement PyLint aux rapports ESLint SA. Pour plus d'informations sur les rapports SA, consultez[Rapports d'analyse statiques](test-workflow-actions.md#test-static-analysis-reports).
**Problèmes de qualité**
Spécifiez le nombre maximum et la gravité des problèmes de qualité autorisés dans le rapport SA pour que le CodeCatalyst rapport associé soit marqué comme réussi. Pour définir les problèmes de qualité, vous devez spécifier :
+ La gravité minimale des problèmes de qualité que vous souhaitez inclure dans le décompte. Les valeurs valides, de la plus sévère à la moins sévère, sont les suivantes : `CRITICAL``HIGH`,`MEDIUM`,`LOW`,,`INFORMATIONAL`.
Par exemple, si vous le souhaitez`HIGH`, `HIGH` les problèmes `CRITICAL` de qualité seront pris en compte.
+ Le nombre maximum de problèmes de qualité de la gravité spécifiée que vous souhaitez autoriser. Le dépassement de ce nombre entraîne le marquage CodeCatalyst du rapport comme ayant échoué. Les valeurs valides sont des nombres entiers.
Les critères relatifs aux problèmes de qualité ne s'appliquent qu' PyLint aux rapports ESLint SA. Pour plus d'informations sur les rapports SA, consultez[Rapports d'analyse statiques](test-workflow-actions.md#test-static-analysis-reports).
1. Choisissez **Commit (Valider)**.
1. Exécutez votre flux de travail pour CodeCatalyst appliquer des critères de réussite à vos rapports bruts, et régénérez les CodeCatalyst rapports associés en incluant les informations sur les critères de réussite. Pour de plus amples informations, veuillez consulter [Démarrage manuel de l’exécution d’un flux de travail](workflows-manually-start.md).
------
#### [ YAML ]
**Pour configurer les critères de réussite**
1. **Dans le volet de navigation, choisissez **CI/CD**, puis Workflows.**
1. Choisissez un flux de travail contenant une action qui génère un rapport. Il s'agit du rapport pour lequel vous souhaitez appliquer des critères de réussite. Vous pouvez filtrer par le nom du référentiel source ou de la branche où le flux de travail est défini, ou filtrer par nom ou statut du flux de travail.
1. Choisissez **Modifier**.
1. Choisissez **YAML.**
1. Dans le diagramme du flux de travail, choisissez l'action que vous avez configurée pour générer des CodeCatalyst rapports.
1. Dans le volet de détails, choisissez l'onglet **Sorties**.
1. Dans l'action, dans `AutoDiscoverReports` la section ou dans la `Reports` section, ajoutez une **SuccessCriteria**propriété, ainsi que`PassRate`,`LineCoverage`,`BranchCoverage`,`Vulnerabilities`, `StaticAnalysisBug``StaticAnalysisSecurity`, et `StaticAnalysisQuality` des propriétés.
Pour une explication de chacune de ces propriétés, consultez le[Créez et testez des actions YAML](build-action-ref.md).
1. Choisissez **Commit (Valider)**.
1. Exécutez votre flux de travail pour CodeCatalyst appliquer des critères de réussite à vos rapports bruts, et régénérez les CodeCatalyst rapports associés avec les informations sur les critères de succès incluses. Pour plus d'informations sur le démarrage d'un flux de travail, consultez[Démarrage manuel de l’exécution d’un flux de travail](workflows-manually-start.md).
------
## Exemple de rapports de qualité YAML
L'exemple suivant montre comment configurer manuellement quatre rapports : un rapport de test, un rapport de couverture du code, un rapport d'analyse de la composition logicielle et un rapport d'analyse statique.
```
Reports:
MyTestReport:
Format: JUNITXML
IncludePaths:
- "*.xml"
ExcludePaths:
- report1.xml
SuccessCriteria:
PassRate: 90
MyCoverageReport:
Format: CLOVERXML
IncludePaths:
- output/coverage/jest/clover.xml
SuccessCriteria:
LineCoverage: 75
BranchCoverage: 75
MySCAReport:
Format: SARIFSCA
IncludePaths:
- output/sca/reports.xml
SuccessCriteria:
Vulnerabilities:
Number: 5
Severity: HIGH
MySAReport:
Format: ESLINTJSON
IncludePaths:
- output/static/eslint.xml
SuccessCriteria:
StaticAnalysisBug:
Number: 10
Severity: MEDIUM
StaticAnalysisSecurity:
Number: 5
Severity: CRITICAL
StaticAnalysisQuality:
Number: 0
Severity: INFORMATIONAL
```
# Bonnes pratiques en matière de tests
Lorsque vous utilisez les fonctionnalités de test fournies par CodeCatalyst, nous vous recommandons de suivre ces meilleures pratiques.
**Topics**
+ [Découverte automatique](#test.best-auto-discovery)
+ [Critères de réussite](#test.best-success-criteria)
+ [Inclure/exclure des chemins](#test.best-include-exclude)
## Découverte automatique
Lorsque vous configurez des actions dans CodeCatalyst, la découverte automatique vous permet de découvrir automatiquement les résultats de divers outils, tels que les rapports de JUnit test, et de générer des CodeCatalyst rapports pertinents à partir de ceux-ci. La découverte automatique permet de garantir que les rapports continuent d'être générés même si les noms ou les chemins des sorties découvertes changent. Lorsque de nouveaux fichiers sont ajoutés, il les découvre CodeCatalyst automatiquement et produit des rapports pertinents. Toutefois, si vous utilisez la détection automatique, il est important de prendre en compte certains des aspects suivants de cette fonctionnalité :
+ Lorsque vous activez la détection automatique dans votre action, tous les rapports découverts automatiquement du même type partagent les mêmes critères de réussite. Par exemple, un critère partagé tel que le taux de réussite minimum s'appliquerait à tous les rapports de test découverts automatiquement. Si vous avez besoin de critères différents pour les rapports du même type, vous devez configurer explicitement chacun de ces rapports.
+ La détection automatique peut également détecter les rapports produits par vos dépendances et, si des critères de réussite sont configurés, l'action sur ces rapports risque d'échouer. Ce problème peut être résolu en mettant à jour la configuration du chemin d'exclusion.
+ Il n'est pas garanti que la découverte automatique produise la même liste de rapports à chaque fois, car elle analyse l'action au moment de l'exécution. Dans le cas où vous souhaitez qu'un rapport particulier soit toujours produit, vous devez configurer les rapports de manière explicite. Par exemple, si les tests cessaient de s'exécuter dans le cadre de votre build, le framework de test ne produirait aucun résultat et, par conséquent, aucun rapport de test ne serait produit et l'action pourrait réussir. Si vous souhaitez que le succès de votre action dépende de ce test en particulier, vous devez configurer explicitement ce rapport.
**Astuce**
Lorsque vous commencez à travailler sur un projet nouveau ou existant, utilisez la détection automatique pour l'ensemble du répertoire du projet (y compris`**/*`). Cela implique la génération de rapports pour tous les fichiers de votre projet, y compris ceux des sous-répertoires.
Pour de plus amples informations, veuillez consulter [Configuration des rapports de qualité dans une action](test-config-action.md).
## Critères de réussite
Vous pouvez appliquer des seuils de qualité à vos rapports en configurant des critères de réussite. Par exemple, si deux rapports de couverture de code ont été découverts automatiquement, l'un avec une couverture de ligne de 80 % et l'autre avec une couverture de ligne de 60 %, les options suivantes s'offrent à vous :
+ Définissez les critères de réussite de la détection automatique pour la couverture des lignes à 80 %. Cela entraînerait l'adoption du premier rapport et l'échec du second rapport, ce qui entraînerait l'échec de l'action globale. Pour débloquer le flux de travail, ajoutez de nouveaux tests à votre projet jusqu'à ce que la couverture linéaire du deuxième rapport dépasse 80 %.
+ Définissez les critères de réussite de la détection automatique pour la couverture des lignes à 60 %. Cela entraînerait la transmission des deux rapports, ce qui se traduirait par le succès de l'action. Vous pourriez ensuite travailler à augmenter la couverture du code dans le deuxième rapport. Toutefois, avec cette approche, vous ne pouvez pas garantir que le taux de couverture indiqué dans le premier rapport ne descendra pas en dessous de 80 %.
+ Configurez explicitement l'un des rapports ou les deux à l'aide de l'éditeur visuel ou en ajoutant une section YAML et un chemin explicites pour chaque rapport. Cela vous permettra de configurer des critères de réussite distincts et des noms personnalisés pour chaque rapport. Toutefois, avec cette approche, l'action peut échouer si les chemins des rapports changent.
Pour de plus amples informations, veuillez consulter [Configuration des critères de réussite pour les rapports](test-config-action.md#test.success-criteria).
## Inclure/exclure des chemins
Lorsque vous examinez les résultats des actions, vous pouvez ajuster la liste des rapports générés CodeCatalyst par en configurant `IncludePaths` et`ExcludePaths`.
+ Permet `IncludePaths` de spécifier les fichiers et les chemins de fichiers que vous CodeCatalyst souhaitez inclure lors de la recherche de rapports. Par exemple, si vous le spécifiez`"/test/report/*"`, CodeCatalyst recherche l'intégralité de l'image de construction utilisée par l'action à la recherche du `/test/report/` répertoire. Lorsqu'il trouve ce répertoire, CodeCatalyst il recherche des rapports dans ce répertoire.
**Note**
Pour les rapports configurés manuellement, `IncludePaths` il doit s'agir d'un modèle global correspondant à un seul fichier.
+ Permet `ExcludePaths` de spécifier les fichiers et les chemins de fichiers que vous CodeCatalyst souhaitez exclure lors de la recherche de rapports. Par exemple, si vous le spécifiez`"/test/reports/**/*"`, ne CodeCatalyst recherchera pas de fichiers dans le `/test/reports/` répertoire. Pour ignorer tous les fichiers d'un répertoire, utilisez le modèle `**/*` glob.
Vous trouverez ci-dessous des exemples de modèles globaux possibles.
| Modèle | Description |
| --- | --- |
| `*.*` | Correspond à tous les noms d'objets du répertoire actuel contenant un point |
| `*.xml` | Correspond à tous les noms d'objets du répertoire actuel se terminant par `.xml` |
| `*.{xml,txt}` | Correspond à tous les noms d'objets du répertoire actuel se terminant par `.xml` ou `.txt` |
| `**/*.xml` | Fait correspondre les noms d'objets dans tous les répertoires se terminant par `.xml` |
| `testFolder` | Correspond à un objet appelé`testFolder`, en le traitant comme un fichier |
| `testFolder/*` | Fait correspondre les objets d'un niveau du sous-dossier à partir de`testFolder`, tels que `testFolder/file.xml` |
| `testFolder/*/*` | Fait correspondre les objets situés à deux niveaux du sous-dossier à partir de`testFolder`, tels que `testFolder/reportsFolder/file.xml` |
| `testFolder/**` | Correspond au sous-dossier `testFolder`, ainsi qu'aux fichiers sous `testFolder`, tels que `testFolder/file.xml` et `testFolder/otherFolder/file.xml` |
CodeCatalyst interprète les modèles globulaires comme suit :
+ Le caractère slash (`/`) sépare les répertoires dans les chemins de fichiers.
+ L'astérisque (`*`) correspond à zéro ou plusieurs caractères d'un composant de nom sans dépasser les limites d'un dossier.
+ Un double astérisque (`**`) correspond à zéro ou plusieurs caractères d'un composant de nom dans tous les répertoires.
**Note**
`ExcludePaths`a la priorité sur. `IncludePaths` Si `IncludePaths` les deux `ExcludePaths` incluent le même dossier, ce dossier n'est pas scanné pour les rapports.
# Propriétés SARIF prises en charge
Le format d'échange de résultats d'analyse statique (SARIF) est un format de fichier de sortie disponible dans les rapports d'analyse de composition logicielle (SCA) et d'analyse statique sur Amazon. CodeCatalyst L'exemple suivant montre comment configurer manuellement le SARIF dans un rapport d'analyse statique :
```
Reports:
MySAReport:
Format: SARIFSA
IncludePaths:
- output/sa_report.json
SuccessCriteria:
StaticAnalysisFinding:
Number: 25
Severity: HIGH
```
CodeCatalyst prend en charge les propriétés SARIF suivantes qui peuvent être utilisées pour optimiser la façon dont les résultats d'analyse apparaîtront dans vos rapports.
**Topics**
+ [Objet `sarifLog`](#test.sarif.sarifLog)
+ [Objet `run`](#test.sarif.run)
+ [Objet `toolComponent`](#test.sarif.toolComponent)
+ [Objet `reportingDescriptor`](#test.sarif.reportingDescriptor)
+ [Objet `result`](#test.sarif.result)
+ [Objet `location`](#test.sarif.location)
+ [Objet `physicalLocation`](#test.sarif.physicalLocation)
+ [Objet `logicalLocation`](#test.sarif.logicalLocation)
+ [Objet `fix`](#test.sarif.fix)
## Objet `sarifLog`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `$schema` | Oui | L'URI du schéma JSON SARIF pour la version [2.1.0.](https://json.schemastore.org/sarif-2.1.0.json) |
| `version` | Oui | CodeCatalyst ne prend en charge que la version 2.1.0 de SARIF. |
| `runs[]` | Oui | Un fichier SARIF contient un tableau d'une ou de plusieurs exécutions, chacune représentant une exécution unique de l'outil d'analyse. |
## Objet `run`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `tool.driver` | Oui | `toolComponent`Objet qui décrit l'outil d'analyse. |
| `tool.name` | Non | Propriété qui indique le nom de l'outil utilisé pour effectuer l'analyse. |
| `results[]` | Oui | Les résultats de l'outil d'analyse qui sont affichés sur CodeCatalyst. |
## Objet `toolComponent`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `name` | Oui | Nom de l'outil d'analyse. |
| `properties.artifactScanned` | Non | Nombre total d'artefacts analysés par l'outil. |
| `rules[]` | Oui | Tableau d'`reportingDescriptor`objets représentant des règles. Sur la base de ces règles, l'outil d'analyse détecte les problèmes dans le code analysé. |
## Objet `reportingDescriptor`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `id` | Oui | Identifiant unique de la règle utilisée pour référencer un résultat. Longueur maximale : 1 024 caractères |
| `name` | Non | Le nom d'affichage de la règle. Longueur maximale : 1 024 caractères |
| `shortDescription.text` | Non | Description abrégée de la règle. Longueur maximale : 3 000 caractères |
| `fullDescription.text` | Non | Description complète de la règle. Longueur maximale : 3 000 caractères |
| `helpUri` | Non | Chaîne qui peut être localisée pour contenir l'URI absolu de la documentation principale de la règle. Longueur maximale : 3 000 caractères |
| `properties.unscore` | Non | Un indicateur qui indique si le résultat du scan a été noté. |
| `properties.score.severity` | Non | Ensemble fixe de chaînes qui spécifient le niveau de gravité du résultat. Longueur maximale : 1 024 caractères |
| `properties.cvssv3_baseSeverity` | Non | Évaluation qualitative de la gravité du [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document). |
| `properties.cvssv3_baseScore` | Non | Un score de base CVSS v3 compris entre [0,0 et 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.cvssv2_severity` | Non | Si les valeurs CVSS v3 ne sont pas disponibles, CodeCatalyst recherche les valeurs CVSS v2. |
| `properties.cvssv2_score` | Non | Un score de base CVSS v2 compris entre [0,0 et 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.severity` | Non | Ensemble fixe de chaînes qui spécifient le niveau de gravité du résultat. Longueur maximale : 1 024 caractères |
| `defaultConfiguration.level` | Non | La sévérité par défaut d'une règle. |
## Objet `result`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `ruleId` | Oui | Identifiant unique de la règle utilisée pour référencer un résultat. Longueur maximale : 1 024 caractères |
| `ruleIndex` | Oui | Index de la règle associée dans le composant de l'outil`rules[]`. |
| `message.text` | Oui | Message qui décrit le résultat et affiche le message correspondant à chaque résultat. Longueur maximale : 3 000 caractères |
| `rank` | Non | Une valeur comprise entre 0,0 et 100,0 inclus qui représente la priorité ou l'importance du résultat. Cette échelle indique 0,0 comme priorité la plus basse et 100,0 comme priorité la plus élevée. |
| `level` | Non | La sévérité du résultat. Longueur maximale : 1 024 caractères |
| `properties.unscore` | Non | Un indicateur qui indique si le résultat du scan a été noté. |
| `properties.score.severity` | Non | Ensemble fixe de chaînes qui spécifient le niveau de gravité du résultat. Longueur maximale : 1 024 caractères |
| `properties.cvssv3_baseSeverity` | Non | Évaluation qualitative de la gravité du [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document). |
| `properties.cvssv3_baseScore` | Non | Un score de base CVSS v3 compris entre [0,0 et 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.cvssv2_severity` | Non | Si les valeurs CVSS v3 ne sont pas disponibles, CodeCatalyst recherche les valeurs CVSS v2. |
| `properties.cvssv2_score` | Non | Un score de base CVSS v2 compris entre [0,0 et 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.severity` | Non | Ensemble fixe de chaînes qui spécifient le niveau de gravité du résultat. Longueur maximale : 1 024 caractères |
| `locations[]` | Oui | Ensemble d'emplacements où le résultat a été détecté. Un seul emplacement doit être inclus, sauf si le problème ne peut être résolu qu'en apportant une modification à chaque emplacement spécifié. CodeCatalyst utilise la première valeur du tableau d'emplacements pour annoter le résultat. Nombre maximum d'`location`objets : 10 |
| `relatedLocations[]` | Non | Une liste de références de lieux supplémentaires dans la constatation. Nombre maximum d'`location`objets : 50 |
| `fixes[]` | Non | Tableau d'`fix`objets représentant les recommandations fournies par l'outil de numérisation. CodeCatalyst utilise la première recommandation du `fixes` tableau. |
## Objet `location`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `physicalLocation` | Oui | Identifie l'artefact et la région. |
| `logicalLocations[]` | Non | Ensemble de lieux décrits par leur nom sans référence à l'artefact. |
## Objet `physicalLocation`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `artifactLocation.uri` | Oui | L'URI indiquant l'emplacement d'un artefact, généralement un fichier dans le référentiel ou généré lors d'une compilation. |
| `fileLocation.uri` | Non | L'URI de secours indiquant l'emplacement du fichier. Ceci est utilisé si les `artifactLocation.uri` retours sont vides. |
| `region.startLine` | Oui | Numéro de ligne du premier caractère de la région. |
| `region.startColumn` | Oui | Numéro de colonne du premier caractère de la région. |
| `region.endLine` | Oui | Numéro de ligne du dernier caractère de la région. |
| `region.endColumn` | Oui | Numéro de colonne du dernier caractère de la région. |
## Objet `logicalLocation`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `fullyQualifiedName` | Non | Informations supplémentaires qui décrivent l'emplacement du résultat. Longueur maximale : 1 024 caractères |
## Objet `fix`
| Nom | Obligatoire | Description |
| --- | --- | --- |
| `description.text` | Non | Un message qui affiche une recommandation pour chaque résultat. Longueur maximale : 3 000 caractères |
| `artifactChanges.[0].artifactLocation.uri` | Non | L'URI indiquant l'emplacement de l'artefact qui doit être mis à jour. |