Amazon non CodeCatalyst è più aperta a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Test con flussi di lavoro
In CodeCatalyst, puoi eseguire test come parte di diverse azioni del flusso di lavoro, come build e test. Tutte queste azioni del flusso di lavoro possono generare report sulla qualità. Un'*azione di test* è un'azione del flusso di lavoro che produce report di test, copertura del codice, analisi della composizione del software e analisi statiche. Questi report vengono visualizzati nella CodeCatalyst console.
**Topics**
+ [Tipi di report sulla qualità](#test-reporting)
+ [Aggiungere l'azione di test](test-add-action.md)
+ [Visualizzazione dei risultati di un'azione di test](test-view-results.md)
+ [Ignorare i test non riusciti in un'azione](test.error-handling.md)
+ [Integrazione con universal-test-runner](test.universal-test-runner.md)
+ [Configurazione dei report sulla qualità in un'azione](test-config-action.md)
+ [Le migliori pratiche per i test](test-best-practices.md)
+ [Proprietà SARIF supportate](test.sarif.md)
## Tipi di report sulla qualità
L'azione CodeCatalyst di test di Amazon supporta i seguenti tipi di report sulla qualità. Per un esempio su come formattare questi report in YAML, consulta. [Rapporti sulla qualità (esempio YAML).](test-config-action.md#test.success-criteria-example)
**Topics**
+ [Rapporti dei test](#test-reports)
+ [Report di copertura del codice](#test-code-coverage-reports)
+ [Rapporti di analisi della composizione del software](#test-sca-reports)
+ [Rapporti di analisi statica](#test-static-analysis-reports)
### Rapporti dei test
In CodeCatalyst, puoi configurare test unitari, test di integrazione e test di sistema da eseguire durante le build. Quindi CodeCatalyst puoi creare report che contengono i risultati dei tuoi test.
È possibile utilizzare un rapporto di prova per risolvere i problemi relativi ai test. Se disponi di molti rapporti di test relativi a più build, puoi utilizzarli per visualizzare i tassi di errore e ottimizzare le tue build.
Puoi utilizzare i seguenti formati di file dei report di test:
+ Cucumber JSON (.json)
+ JUnit XML (.xml)
+ NUnit XML (.xml)
+ NUnit3 XML (.xml)
+ TestNg XML (.xml)
+ Visual Studio TRX (.trx, .xml)
### Report di copertura del codice
Nel CodeCatalyst, puoi generare report sulla copertura del codice per i tuoi test. CodeCatalyst fornisce le seguenti metriche di copertura del codice:
Copertura della linea
Misura il numero di affermazioni coperte dai test. Una dichiarazione è una singola istruzione, esclusi i commenti.
`line coverage = (total lines covered)/(total number of lines)`
Copertura del ramo
Misura il numero di rami coperti dai test rispetto a ogni possibile ramo di una struttura di controllo, ad esempio un'`case`istruzione `if` or.
`branch coverage = (total branches covered)/(total number of branches)`
Sono supportati i seguenti formati di file di report di copertura del codice:
+ JaCoCo XML (.xml)
+ SimpleCov [JSON (generato da [simplecov, non da simplecov-json](https://github.com/simplecov-ruby/simplecov), .json)](https://github.com/vicentllongo/simplecov-json)
+ Clover XML (versione 3, .xml)
+ Copertura XML (.xml)
+ LCOV (.info)
### Rapporti di analisi della composizione del software
In CodeCatalyst, puoi utilizzare gli strumenti di analisi della composizione del software (SCA) per analizzare i componenti dell'applicazione e verificare eventuali vulnerabilità di sicurezza note. È possibile scoprire e analizzare i report SARIF che descrivono in dettaglio le vulnerabilità con gravità diverse e i modi per risolverle. I valori di gravità validi, dalla più severa alla meno severa, sono:`CRITICAL`,,,,. `HIGH` `MEDIUM` `LOW` `INFORMATIONAL`
Sono supportati i seguenti formati di file di report SCA:
+ SARIF (.sarif, .json)
### Rapporti di analisi statica
Puoi utilizzare i report di analisi statica (SA) per identificare i difetti del codice a livello di sorgente. Inoltre CodeCatalyst, puoi generare report SA per aiutare a risolvere i problemi del codice prima di distribuirlo. Questi problemi includono bug, vulnerabilità di sicurezza, problemi di qualità e altre vulnerabilità. I valori di gravità validi, dalla più severa alla meno severa, sono:`CRITICAL`,, `HIGH``MEDIUM`, `LOW` e. `INFORMATIONAL`
CodeCatalyst fornisce le seguenti metriche SA:
bug
Identifica una serie di possibili bug trovati nel codice sorgente. Questi bug possono includere problemi relativi alla sicurezza della memoria. Di seguito è riportato un esempio di bug.
```
// 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;
}
```
Vulnerabilità di sicurezza
Identifica una serie di possibili vulnerabilità di sicurezza presenti nel codice sorgente. Queste vulnerabilità di sicurezza possono includere problemi come la memorizzazione dei token segreti in testo non crittografato.
Problemi di qualità
Identifica una serie di possibili problemi di qualità riscontrati nel codice sorgente. Questi problemi di qualità possono includere problemi riguardanti le convenzioni di stile. Di seguito è riportato un esempio di problema di qualità.
```
// The function name doesn't adhere to the style convention of camelCase
int SUBTRACT(int x, int y) {
return x-y
}
```
Altre vulnerabilità
Identifica una serie di possibili altre vulnerabilità presenti nel codice sorgente.
CodeCatalyst supporta i seguenti formati di file di report SA:
+ PyLint (.py)
+ ESLint (.js, .jsx, .ts, .tsx)
+ SARIF (.sarif, .json)
# Aggiungere l'azione di test
Utilizza la seguente procedura per aggiungere un'azione di test al tuo CodeCatalyst flusso di lavoro.
------
#### [ Visual ]
**Per aggiungere un'azione di test utilizzando l'editor visuale**
1. Apri la CodeCatalyst console all'[indirizzo https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**
1. Scegli il nome del tuo flusso di lavoro. Puoi filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro.
1. Scegli **Modifica**.
1. Scegli **Visual**.
1. Scegli **Azioni**.
1. In **Azioni**, scegli **Test**.
1. Nelle schede **Ingressi** e **Configurazione**, completa i campi in base alle tue esigenze. Per una descrizione di ogni campo, vedi. [Crea e testa azioni YAML](build-action-ref.md) Questo riferimento fornisce informazioni dettagliate su ogni campo (e sul valore della proprietà YAML corrispondente) così come appaiono sia nell'editor YAML che in quello visivo.
1. (Facoltativo) Scegliete **Convalida per convalidare il codice YAML** del flusso di lavoro prima di eseguire il commit.
1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.**
------
#### [ YAML ]
**Per aggiungere un'azione di compilazione utilizzando l'editor YAML**
1. [Apri la CodeCatalyst console all'indirizzo https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**
1. Scegli il nome del tuo flusso di lavoro. Puoi filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro.
1. Scegli **Modifica**.
1. Scegli **YAML**.
1. Scegli **Azioni**.
1. **In **Azioni**, scegli Test.**
1. Modifica le proprietà del codice YAML in base alle tue esigenze. Una spiegazione di ogni proprietà disponibile è fornita in. [Crea e testa azioni YAML](build-action-ref.md)
1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima di eseguire il commit.
1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.**
------
## Definizione dell'azione di test
L'azione di test è definita come un insieme di proprietà YAML all'interno del file di definizione del flusso di lavoro. Per informazioni su queste proprietà, vedere [Crea e testa azioni YAML](build-action-ref.md) in. [Definizione YAML del flusso di lavoro](workflow-reference.md)
# Visualizzazione dei risultati di un'azione di test
Utilizza le seguenti istruzioni per visualizzare i risultati di un'azione di test, inclusi i log, i report e le variabili generati.
**Per visualizzare i risultati di un'azione di test**
1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**
1. Scegli il nome del tuo flusso di lavoro. Puoi filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro.
1. **Nel diagramma del flusso di lavoro, scegli il nome dell'azione di test, ad esempio Test.**
1. **Per visualizzare i log generati da un'azione, scegli Registri.** Vengono visualizzati i registri delle varie fasi dell'azione. È possibile espandere o comprimere i registri in base alle esigenze.
1. Per visualizzare i report sui test prodotti dall'azione di test, scegli **Rapporti** o nel riquadro di navigazione scegli **Report**. Per ulteriori informazioni, consulta [Tipi di report sulla qualità](test-workflow-actions.md#test-reporting).
1. Per visualizzare la configurazione utilizzata per l'azione di test, scegli **Configurazione**. Per ulteriori informazioni, consulta [Aggiungere l'azione di test](test-add-action.md).
1. Per visualizzare le variabili utilizzate dall'azione di test, scegliete **Variabili**. Per ulteriori informazioni, consulta [Utilizzo delle variabili nei flussi di lavoro](workflows-working-with-variables.md).
# Ignorare i test non riusciti in un'azione
Se la tua azione ha più di un comando di test, potresti voler consentire l'esecuzione dei comandi di test successivi dell'azione anche se un comando precedente fallisce. Ad esempio, nei seguenti comandi, potresti `test2` voler eseguirli sempre, anche se `test1` fallisce.
```
Steps:
- Run: npm install
- Run: npm run test1
- Run: npm run test2
```
Normalmente, quando un passaggio restituisce un errore, Amazon CodeCatalyst interrompe l'azione del flusso di lavoro e la contrassegna come non riuscita. Puoi consentire ai passaggi di azione di continuare a essere eseguiti reindirizzando l'output dell'errore a. `null` È possibile eseguire questa operazione aggiungendo `2>/dev/null` al comando. Con questa modifica, l'esempio precedente sarebbe simile al seguente.
```
Steps:
- Run: npm install
- Run: npm run test1 2>/dev/null
- Run: npm run test2
```
Nel secondo frammento di codice, lo stato del `npm install` comando verrà rispettato, ma qualsiasi errore restituito dal `npm run test1` comando verrà ignorato. Di conseguenza, il comando viene `npm run test2` eseguito. In questo modo, è possibile visualizzare entrambi i report contemporaneamente indipendentemente dal fatto che si verifichi un errore.
# Integrazione con universal-test-runner
Le azioni di test si integrano con lo strumento `universal-test-runner` a riga di comando open source. `universal-test-runner`utilizza il [Test Execution Protocol](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md) per eseguire i test per qualsiasi lingua in un determinato framework. `universal-test-runner`supporta i seguenti framework:
+ [Gradle](https://gradle.org/)
+ [Scherzo](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` viene installato solo sulle immagini selezionate per le azioni di test. Se configuri un’azione di test per utilizzare un Docker Hub o Amazon ECR personalizzato, devi installare manualmente `universal-test-runner` per abilitare le funzionalità di test avanzate. A tale scopo, installa Node.js (14 o versione successiva) sull’immagine, quindi installa `universal-test-runner` tramite `npm` utilizzando il comando shell `- Run: npm install -g @aws/universal-test-runner`. Per ulteriori informazioni sull'installazione di Node.js nel contenitore tramite i comandi della shell, consulta [Installazione e aggiornamento di Node Version Manager](https://github.com/nvm-sh/nvm#install--update-script).
Per ulteriori informazioni su `universal-test-runner`, consulta [Che cos'è universal-test-runner](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner).
------
#### [ Visual ]
**Da utilizzare universal-test-runner nell'editor visuale**
1. Apri la CodeCatalyst console all'[indirizzo https://codecatalyst.aws/](https://codecatalyst.aws/).
1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**
1. Scegli il nome del tuo flusso di lavoro.
1. Scegli **Modifica**.
1. Scegli **Visual**.
1. Scegli **Azioni**.
1. In **Azioni**, scegli **Test**.
1. Nella scheda **Configurazione**, completa il campo **Comandi Shell** aggiornando il codice di esempio con la tua scelta dei framework supportati. Ad esempio, per utilizzare un framework supportato, è necessario utilizzare un `Run` comando simile al seguente.
```
- Run: run-tests
```
Se il framework che desideri non è supportato, considera di contribuire con un adattatore o un runner personalizzato. Per una descrizione del campo dei **comandi Shell**, vedere[Steps](build-action-ref.md#build.configuration.steps).
1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima di eseguire il commit.
1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.**
------
#### [ YAML ]
**Da usare universal-test-runner nell'editor YAML**
1. [Apri la CodeCatalyst console all'indirizzo https://codecatalyst.aws/.](https://codecatalyst.aws/)
1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**
1. Scegli il nome del tuo flusso di lavoro.
1. Scegli **Modifica**.
1. Scegli **YAML**.
1. Scegli **Azioni**.
1. **In **Azioni**, scegli Test.**
1. Modifica il codice YAML in base alle tue esigenze. Ad esempio, per utilizzare un framework supportato, è necessario utilizzare un `Run` comando simile al seguente.
```
Configuration:
Steps:
- Run: run-tests
```
Se il framework che desideri non è supportato, considera di contribuire con un adattatore o un runner personalizzato. Per una descrizione della proprietà **Steps**, vedere[Steps](build-action-ref.md#build.configuration.steps).
1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima di eseguire il commit.
1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.**
------
# Configurazione dei report sulla qualità in un'azione
Questa sezione descrive come configurare un rapporto sulla qualità in un'azione.
**Topics**
+ [Rilevamento automatico e report manuali](#test.auto-discovery)
+ [Configurazione dei criteri di successo per i report](#test.success-criteria)
+ [Rapporti sulla qualità (esempio YAML).](#test.success-criteria-example)
## Rilevamento automatico e report manuali
Quando l'individuazione automatica è abilitata, CodeCatalyst cerca tutti gli input passati all'azione e tutti i file generati dall'azione stessa, cercando report di test, copertura del codice, analisi della composizione del software (SCA) e analisi statica (SA). È possibile visualizzare e manipolare ciascuno di questi report in. CodeCatalyst
È inoltre possibile configurare manualmente i report da generare. Puoi specificare il tipo di rapporto che desideri generare e il formato del file. Per ulteriori informazioni, consulta [Tipi di report sulla qualità](test-workflow-actions.md#test-reporting).
## Configurazione dei criteri di successo per i report
È possibile impostare i valori che determinano i criteri di successo per un rapporto di test, copertura del codice, analisi della composizione del software (SCA) o analisi statica (SA).
I criteri di successo sono soglie che determinano se un report ha esito positivo o negativo. CodeCatalyst genera innanzitutto il rapporto, che può essere un rapporto di test, di copertura del codice, SCA o SA, e quindi applica i criteri di successo ai report generati. Quindi mostra se i criteri di successo sono stati soddisfatti e in che misura. Se un rapporto non soddisfa i criteri di successo specificati, l' CodeCatalyst azione che ha specificato i criteri di successo ha esito negativo.
Ad esempio, quando si impostano i criteri di successo per il rapporto SCA, i valori di vulnerabilità validi, dal più grave al meno grave, sono:`CRITICAL`,, `HIGH``MEDIUM`,`LOW`. `INFORMATIONAL` Se si impostano i criteri per la scansione di una vulnerabilità per livello di `HIGH` gravità, il rapporto avrà esito negativo se è presente almeno una vulnerabilità con `HIGH` gravità o nessuna vulnerabilità con `HIGH` gravità, ma almeno una vulnerabilità con un livello di gravità più elevato, ad esempio una vulnerabilità per gravità. `CRITICAL`
Se non si specificano criteri di successo, allora:
+ Il CodeCatalyst rapporto generato in base ai report non elaborati non mostrerà criteri di successo.
+ I criteri di successo non verranno utilizzati per determinare se l'azione del flusso di lavoro associata ha esito positivo o negativo.
------
#### [ Visual ]
**Per configurare i criteri di successo**
1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**
1. Scegli un flusso di lavoro contenente un'azione che generi un report. Questo è il rapporto per il quale desideri applicare i criteri di successo. È possibile filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro.
1. Scegli **Modifica**.
1. Scegli **Visual**.
1. Nel diagramma del flusso di lavoro, scegli l'azione che hai configurato per generare CodeCatalyst report.
1. Seleziona la scheda **Outputs (Output)**.
1. In **Individuazione automatica dei report** o in **Configura manualmente i report**, scegli Criteri di **successo**.
Vengono visualizzati i criteri di successo. A seconda delle selezioni precedenti, è possibile visualizzare alcune o tutte le seguenti opzioni:
**Frequenza di superamento**
Specificare la percentuale di test in un rapporto di prova che deve essere superato affinché il CodeCatalyst rapporto associato venga contrassegnato come superato. I valori validi includono i numeri decimali. Ad esempio, `50`, `60.5`. I criteri relativi alla percentuale di superamento vengono applicati solo ai rapporti di prova. Per ulteriori informazioni sui rapporti di prova, vedere[Rapporti dei test](test-workflow-actions.md#test-reports).
**Copertura della linea**
Specificate la percentuale di righe in un rapporto sulla copertura del codice che devono essere coperte affinché il CodeCatalyst rapporto associato venga contrassegnato come superato. I valori validi includono i numeri decimali. Ad esempio, `50`, `60.5`. I criteri di copertura delle linee vengono applicati solo ai report sulla copertura del codice. Per ulteriori informazioni sui rapporti sulla copertura del codice, vedere[Report di copertura del codice](test-workflow-actions.md#test-code-coverage-reports).
**Copertura delle filiali**
Specificate la percentuale di filiali in un rapporto sulla copertura del codice che deve essere coperta affinché il CodeCatalyst rapporto associato venga contrassegnato come approvato. I valori validi includono i numeri decimali. Ad esempio, `50`, `60.5`. I criteri di copertura delle filiali vengono applicati solo ai report sulla copertura del codice. Per ulteriori informazioni sui rapporti sulla copertura del codice, vedere[Report di copertura del codice](test-workflow-actions.md#test-code-coverage-reports).
**Vulnerabilità (SCA)**
Specificare il numero e la gravità massimi di vulnerabilità consentiti nel rapporto SCA affinché il CodeCatalyst rapporto associato venga contrassegnato come superato. Per specificare le vulnerabilità, è necessario specificare:
+ La gravità minima delle vulnerabilità da includere nel conteggio. I valori validi, dal più grave al meno grave, sono:`CRITICAL`,`HIGH`,, `MEDIUM``LOW`,`INFORMATIONAL`.
Ad esempio, se si sceglie`HIGH`, verranno `HIGH` `CRITICAL` conteggiate tutte le vulnerabilità.
+ Il numero massimo di vulnerabilità della gravità specificata che desideri consentire. Il superamento di questo numero fa sì che il CodeCatalyst rapporto venga contrassegnato come fallito. I valori validi sono numeri interi.
I criteri di vulnerabilità vengono applicati solo ai report SCA. Per ulteriori informazioni sui report SCA, vedere. [Rapporti di analisi della composizione del software](test-workflow-actions.md#test-sca-reports)
**Bug**
Specificate il numero e la gravità massimi di bug consentiti nel rapporto SA affinché il CodeCatalyst rapporto associato venga contrassegnato come superato. Per specificare i bug, è necessario specificare:
+ La gravità minima dei bug da includere nel conteggio. I valori validi, dal più grave al meno grave, sono:`CRITICAL`,`HIGH`,, `MEDIUM``LOW`,`INFORMATIONAL`.
Ad esempio, se scegli`HIGH`, allora `HIGH` i `CRITICAL` bug verranno conteggiati.
+ Il numero massimo di bug della gravità specificata che desideri consentire. Il superamento di questo numero fa sì che il CodeCatalyst rapporto venga contrassegnato come fallito. I valori validi sono numeri interi.
I criteri relativi ai bug vengono applicati solo PyLint ai report ESLint SA. Per ulteriori informazioni sui report SA, vedere[Rapporti di analisi statica](test-workflow-actions.md#test-static-analysis-reports).
**Vulnerabilità di sicurezza**
Specificare il numero e la gravità massimi di vulnerabilità di sicurezza consentite nel rapporto SA affinché il CodeCatalyst rapporto associato venga contrassegnato come superato. Per specificare le vulnerabilità di sicurezza, è necessario specificare:
+ La gravità minima delle vulnerabilità di sicurezza da includere nel conteggio. I valori validi, dal più grave al meno grave, sono:`CRITICAL`,`HIGH`,, `MEDIUM``LOW`,`INFORMATIONAL`.
Ad esempio, se lo desideri`HIGH`, verranno `HIGH` conteggiate le vulnerabilità di `CRITICAL` sicurezza.
+ Il numero massimo di vulnerabilità di sicurezza della gravità specificata che desideri consentire. Il superamento di questo numero fa sì che il CodeCatalyst rapporto venga contrassegnato come fallito. I valori validi sono numeri interi.
I criteri di vulnerabilità di sicurezza vengono applicati solo ai report PyLint e ESLint SA. Per ulteriori informazioni sui report SA, vedere[Rapporti di analisi statica](test-workflow-actions.md#test-static-analysis-reports).
**Problemi di qualità**
Specificare il numero e la gravità massimi dei problemi di qualità consentiti nel rapporto SA affinché il CodeCatalyst rapporto associato venga contrassegnato come superato. Per specificare i problemi di qualità, è necessario specificare:
+ La gravità minima dei problemi di qualità da includere nel conteggio. I valori validi, dal più grave al meno grave, sono: `CRITICAL``HIGH`,,`MEDIUM`,`LOW`,`INFORMATIONAL`.
Ad esempio, se si sceglie`HIGH`, verranno presi `HIGH` in `CRITICAL` considerazione i problemi di qualità.
+ Il numero massimo di problemi di qualità della gravità specificata che si desidera consentire. Il superamento di questo numero fa sì che il CodeCatalyst rapporto venga contrassegnato come fallito. I valori validi sono numeri interi.
I criteri relativi ai problemi di qualità vengono applicati solo PyLint ai report ESLint SA. Per ulteriori informazioni sui report SA, vedere[Rapporti di analisi statica](test-workflow-actions.md#test-static-analysis-reports).
1. Scegli **Applica**.
1. Esegui il flusso di lavoro per CodeCatalyst applicare criteri di successo ai report non elaborati e rigenera i CodeCatalyst report associati includendo le informazioni sui criteri di successo. Per ulteriori informazioni, consulta [Avvio manuale dell’esecuzione di un flusso di lavoro](workflows-manually-start.md).
------
#### [ YAML ]
**Per configurare i criteri di successo**
1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**
1. Scegli un flusso di lavoro contenente un'azione che generi un report. Questo è il rapporto per il quale desideri applicare i criteri di successo. È possibile filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro.
1. Scegli **Modifica**.
1. Scegli **YAML**.
1. Nel diagramma del flusso di lavoro, scegli l'azione che hai configurato per generare report. CodeCatalyst
1. Nel riquadro dei dettagli, scegli la scheda **Output**.
1. Nell'azione, nella `AutoDiscoverReports` sezione o nella `Reports` sezione, aggiungi una **SuccessCriteria**proprietà, insieme a`PassRate`,`LineCoverage`,`BranchCoverage`, `Vulnerabilities` `StaticAnalysisBug``StaticAnalysisSecurity`, e `StaticAnalysisQuality` proprietà.
Per una spiegazione di ciascuna di queste proprietà, consulta il[Crea e testa azioni YAML](build-action-ref.md).
1. Scegli **Applica**.
1. Esegui il flusso di lavoro per CodeCatalyst applicare criteri di successo ai report non elaborati e rigenera i CodeCatalyst report associati includendo le informazioni sui criteri di successo. Per ulteriori informazioni sull'avvio di un flusso di lavoro, consulta[Avvio manuale dell’esecuzione di un flusso di lavoro](workflows-manually-start.md).
------
## Rapporti sulla qualità (esempio YAML).
L'esempio seguente mostra come configurare manualmente quattro report: un rapporto di test, un rapporto sulla copertura del codice, un rapporto di analisi della composizione del software e un rapporto di analisi statico.
```
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
```
# Le migliori pratiche per i test
Quando si utilizzano le funzionalità di test fornite da CodeCatalyst, si consiglia di seguire queste best practice.
**Topics**
+ [Rilevamento automatico](#test.best-auto-discovery)
+ [Criteri di successo](#test.best-success-criteria)
+ [Includi/escludi percorsi](#test.best-include-exclude)
## Rilevamento automatico
Durante la configurazione delle azioni CodeCatalyst, l'individuazione automatica consente di scoprire automaticamente gli output di vari strumenti, come i report dei JUnit test, e di generare CodeCatalyst report pertinenti da essi. L'individuazione automatica aiuta a garantire che i report continuino a essere generati anche se i nomi o i percorsi degli output rilevati cambiano. Quando vengono aggiunti nuovi file, li CodeCatalyst rileva automaticamente e produce report pertinenti. Tuttavia, se si utilizza l'individuazione automatica, è importante tenere conto di alcuni dei seguenti aspetti di questa funzionalità:
+ Quando attivi l'individuazione automatica nella tua azione, tutti i report dello stesso tipo scoperti automaticamente condivideranno gli stessi criteri di successo. Ad esempio, un criterio condiviso come la frequenza minima di superamento si applicherebbe a tutti i report dei test scoperti automaticamente. Se hai bisogno di criteri diversi per report dello stesso tipo, devi configurare in modo esplicito ciascuno di questi report.
+ L'individuazione automatica può anche trovare i report prodotti dalle dipendenze e, se sono configurati criteri di successo, l'azione su questi report potrebbe fallire. Questo problema può essere risolto aggiornando la configurazione del percorso di esclusione.
+ Non è garantito che l'individuazione automatica produca sempre lo stesso elenco di report, poiché analizza l'azione in fase di esecuzione. Nel caso in cui si desideri che venga sempre prodotto un determinato report, è necessario configurare i report in modo esplicito. Ad esempio, se i test smettessero di essere eseguiti come parte della build, il framework di test non produrrebbe alcun output e, di conseguenza, non verrebbe prodotto alcun rapporto di test e l'azione potrebbe avere successo. Se vuoi che il successo della tua azione dipenda da quel particolare test, devi configurare esplicitamente quel rapporto.
**Suggerimento**
Quando inizi a lavorare su un progetto nuovo o esistente, usa l'individuazione automatica per l'intera directory del progetto (include`**/*`). Ciò richiama la generazione di report su tutti i file del progetto, inclusi quelli all'interno delle sottodirectory.
Per ulteriori informazioni, consulta [Configurazione dei report sulla qualità in un'azione](test-config-action.md).
## Criteri di successo
È possibile applicare soglie di qualità ai report configurando criteri di successo. Ad esempio, se due report sulla copertura del codice sono stati scoperti automaticamente, uno con una copertura di linea dell'80% e l'altro con una copertura di linea del 60%, sono disponibili le seguenti opzioni:
+ Imposta i criteri di successo del rilevamento automatico per la copertura di linea all'80%. Ciò comporterebbe l'approvazione del primo rapporto e il fallimento del secondo rapporto, con conseguente fallimento dell'azione complessiva. Per sbloccare il flusso di lavoro, aggiungi nuovi test al progetto fino a quando la copertura di linea per il secondo rapporto non supera l'80%.
+ Imposta i criteri di successo del rilevamento automatico per la copertura di linea al 60%. Ciò comporterebbe l'approvazione di entrambi i report, il che comporterebbe il successo dell'azione. Potresti quindi lavorare per aumentare la copertura del codice nel secondo rapporto. Tuttavia, con questo approccio, non è possibile garantire che la copertura del primo rapporto non scenda al di sotto dell'80%.
+ Configura in modo esplicito uno o entrambi i report utilizzando l'editor visivo o aggiungendo una sezione e un percorso YAML espliciti per ogni report. Ciò consentirebbe di configurare criteri di successo separati e nomi personalizzati per ogni rapporto. Tuttavia, con questo approccio, l'azione potrebbe fallire se i percorsi dei report cambiano.
Per ulteriori informazioni, consulta [Configurazione dei criteri di successo per i report](test-config-action.md#test.success-criteria).
## Includi/escludi percorsi
Quando si esaminano i risultati delle azioni, è possibile modificare l'elenco dei report generati CodeCatalyst mediante la configurazione e. `IncludePaths` `ExcludePaths`
+ Utilizzato `IncludePaths` per specificare i file e i percorsi dei file CodeCatalyst da includere durante la ricerca di report. Ad esempio, se si specifica`"/test/report/*"`, CodeCatalyst cerca l'intera immagine di build utilizzata dall'azione che cerca la `/test/report/` directory. Quando trova quella directory, cerca CodeCatalyst i report in quella directory.
**Nota**
Per i report configurati manualmente, `IncludePaths` deve essere presente uno schema a globo che corrisponda a un singolo file.
+ `ExcludePaths`Da utilizzare per specificare i file e i percorsi dei file che si CodeCatalyst desidera escludere durante la ricerca di report. Ad esempio, se si specifica`"/test/reports/**/*"`, non CodeCatalyst cercherà i file nella `/test/reports/` directory. Per ignorare tutti i file in una directory, utilizzate il pattern `**/*` glob.
Di seguito sono riportati alcuni esempi di possibili pattern a glob.
| Pattern | Description |
| --- | --- |
| `*.*` | Corrisponde a tutti i nomi di oggetti nella directory corrente che contengono un punto |
| `*.xml` | Corrisponde a tutti i nomi degli oggetti nella directory corrente che terminano con `.xml` |
| `*.{xml,txt}` | Corrisponde a tutti i nomi degli oggetti nella directory corrente che terminano con `.xml` o `.txt` |
| `**/*.xml` | Corrisponde ai nomi degli oggetti in tutte le directory che terminano con `.xml` |
| `testFolder` | Corrisponde a un oggetto chiamato`testFolder`, trattandolo come un file |
| `testFolder/*` | Corrisponde agli oggetti in un livello della sottocartella da`testFolder`, ad esempio `testFolder/file.xml` |
| `testFolder/*/*` | Corrisponde agli oggetti in due livelli della sottocartella da`testFolder`, ad esempio `testFolder/reportsFolder/file.xml` |
| `testFolder/**` | Individua la sottocartella `testFolder`, insieme ai file all'interno di `testFolder`, ad esempio `testFolder/file.xml` e `testFolder/otherFolder/file.xml` |
CodeCatalyst interpreta i pattern globulari come segue:
+ Il carattere slash (`/`) separa le directory nei percorsi dei file.
+ L'asterisco (`*`) individua zero o più caratteri di un componente del nome entro i limiti della cartella.
+ Un doppio asterisco (`**`) corrisponde a zero o più caratteri di un componente del nome in tutte le directory.
**Nota**
`ExcludePaths`ha la precedenza su. `IncludePaths` Se entrambi `ExcludePaths` includono `IncludePaths` la stessa cartella, tale cartella non viene analizzata per individuare eventuali report.
# Proprietà SARIF supportate
Lo Static Analysis Results Interchange Format (SARIF) è un formato di file di output disponibile nell'analisi della composizione del software (SCA) e nei report di analisi statica in Amazon. CodeCatalyst L'esempio seguente mostra come configurare manualmente SARIF in un report di analisi statica:
```
Reports:
MySAReport:
Format: SARIFSA
IncludePaths:
- output/sa_report.json
SuccessCriteria:
StaticAnalysisFinding:
Number: 25
Severity: HIGH
```
CodeCatalyst supporta le seguenti proprietà SARIF che possono essere utilizzate per ottimizzare la visualizzazione dei risultati dell'analisi nei report.
**Topics**
+ [Oggetto `sarifLog`](#test.sarif.sarifLog)
+ [Oggetto `run`](#test.sarif.run)
+ [Oggetto `toolComponent`](#test.sarif.toolComponent)
+ [Oggetto `reportingDescriptor`](#test.sarif.reportingDescriptor)
+ [Oggetto `result`](#test.sarif.result)
+ [Oggetto `location`](#test.sarif.location)
+ [Oggetto `physicalLocation`](#test.sarif.physicalLocation)
+ [Oggetto `logicalLocation`](#test.sarif.logicalLocation)
+ [Oggetto `fix`](#test.sarif.fix)
## Oggetto `sarifLog`
| Nome | Richiesto | Descrizione |
| --- | --- | --- |
| `$schema` | Sì | [L'URI dello schema JSON SARIF per la versione 2.1.0.](https://json.schemastore.org/sarif-2.1.0.json) |
| `version` | Sì | CodeCatalyst supporta solo la versione SARIF 2.1.0. |
| `runs[]` | Sì | Un file SARIF contiene una matrice di una o più esecuzioni, ognuna delle quali rappresenta una singola esecuzione dello strumento di analisi. |
## Oggetto `run`
| Nome | Richiesto | Descrizione |
| --- | --- | --- |
| `tool.driver` | Sì | Un `toolComponent` oggetto che descrive lo strumento di analisi. |
| `tool.name` | No | Una proprietà che indica il nome dello strumento utilizzato per eseguire l'analisi. |
| `results[]` | Sì | I risultati dello strumento di analisi visualizzati su CodeCatalyst. |
## Oggetto `toolComponent`
| Nome | Richiesto | Descrizione |
| --- | --- | --- |
| `name` | Sì | Il nome dello strumento di analisi. |
| `properties.artifactScanned` | No | Numero totale di artefatti analizzati dallo strumento. |
| `rules[]` | Sì | Una serie di `reportingDescriptor` oggetti che rappresentano regole. In base a queste regole, lo strumento di analisi rileva problemi nel codice analizzato. |
## Oggetto `reportingDescriptor`
| Nome | Richiesto | Descrizione |
| --- | --- | --- |
| `id` | Sì | L'identificatore univoco della regola utilizzata per fare riferimento a un risultato. Lunghezza massima: 1.024 caratteri |
| `name` | No | Il nome visualizzato della regola. Lunghezza massima: 1.024 caratteri |
| `shortDescription.text` | No | Una breve descrizione della regola. Lunghezza massima: 3.000 caratteri |
| `fullDescription.text` | No | Una descrizione completa della regola. Lunghezza massima: 3.000 caratteri |
| `helpUri` | No | Una stringa che può essere localizzata per contenere l'URI assoluto della documentazione principale della regola. Lunghezza massima: 3.000 caratteri |
| `properties.unscore` | No | Un contrassegno che indica se il risultato della scansione è stato valutato. |
| `properties.score.severity` | No | Un set fisso di stringhe che specificano il livello di gravità del risultato. Lunghezza massima: 1.024 caratteri |
| `properties.cvssv3_baseSeverity` | No | Una valutazione di gravità qualitativa del [Common Vulnerability Scoring](https://www.first.org/cvss/v3.1/specification-document) System v3.1. |
| `properties.cvssv3_baseScore` | No | [Un punteggio di base CVSS v3 compreso tra 0,0 e 10,0.](https://nvd.nist.gov/vuln-metrics/cvss) |
| `properties.cvssv2_severity` | No | Se i valori CVSS v3 non sono disponibili, cerca i valori CVSS v2. CodeCatalyst |
| `properties.cvssv2_score` | No | [Un punteggio di base CVSS v2 compreso tra 0,0 e 10,0.](https://nvd.nist.gov/vuln-metrics/cvss) |
| `properties.severity` | No | Un insieme fisso di stringhe che specificano il livello di gravità del risultato. Lunghezza massima: 1.024 caratteri |
| `defaultConfiguration.level` | No | La severità predefinita di una regola. |
## Oggetto `result`
| Nome | Richiesto | Descrizione |
| --- | --- | --- |
| `ruleId` | Sì | L'identificatore univoco della regola utilizzata per fare riferimento a un risultato. Lunghezza massima: 1.024 caratteri |
| `ruleIndex` | Sì | L'indice della regola associata nel componente `rules[]` utensile. |
| `message.text` | Sì | Un messaggio che descrive il risultato e visualizza il messaggio per ogni risultato. Lunghezza massima: 3.000 caratteri |
| `rank` | No | Un valore compreso tra 0,0 e 100,0 inclusi che rappresenta la priorità o l'importanza del risultato. Il valore di questa scala è 0,0 come priorità più bassa e 100,0 come priorità più alta. |
| `level` | No | La gravità del risultato. Lunghezza massima: 1.024 caratteri |
| `properties.unscore` | No | Un contrassegno che indica se il risultato della scansione è stato valutato. |
| `properties.score.severity` | No | Un set fisso di stringhe che specificano il livello di gravità del risultato. Lunghezza massima: 1.024 caratteri |
| `properties.cvssv3_baseSeverity` | No | Una valutazione di gravità qualitativa del [Common Vulnerability Scoring](https://www.first.org/cvss/v3.1/specification-document) System v3.1. |
| `properties.cvssv3_baseScore` | No | [Un punteggio di base CVSS v3 compreso tra 0,0 e 10,0.](https://nvd.nist.gov/vuln-metrics/cvss) |
| `properties.cvssv2_severity` | No | Se i valori CVSS v3 non sono disponibili, cerca i valori CVSS v2. CodeCatalyst |
| `properties.cvssv2_score` | No | [Un punteggio di base CVSS v2 compreso tra 0,0 e 10,0.](https://nvd.nist.gov/vuln-metrics/cvss) |
| `properties.severity` | No | Un insieme fisso di stringhe che specificano il livello di gravità del risultato. Lunghezza massima: 1.024 caratteri |
| `locations[]` | Sì | L'insieme di posizioni in cui è stato rilevato il risultato. È necessario includere solo una posizione, a meno che il problema non possa essere corretto solo apportando una modifica in ogni posizione specificata. CodeCatalyst utilizza il primo valore nell'array di posizione per annotare il risultato. Numero massimo di `location` oggetti: 10 |
| `relatedLocations[]` | No | Un elenco di riferimenti a località aggiuntivi inclusi nel risultato. Numero massimo di `location` oggetti: 50 |
| `fixes[]` | No | Una serie di `fix` oggetti che rappresentano la raccomandazione fornita dallo strumento di scansione. CodeCatalyst utilizza la prima raccomandazione dell'`fixes`array. |
## Oggetto `location`
| Nome | Richiesto | Descrizione |
| --- | --- | --- |
| `physicalLocation` | Sì | Identifica l'artefatto e la regione. |
| `logicalLocations[]` | No | L'insieme di posizioni descritte per nome senza riferimento all'artefatto. |
## Oggetto `physicalLocation`
| Nome | Richiesto | Descrizione |
| --- | --- | --- |
| `artifactLocation.uri` | Sì | L'URI che indica la posizione di un artefatto, in genere un file nel repository o generato durante una compilazione. |
| `fileLocation.uri` | No | L'URI di riserva che indica la posizione del file. Viene utilizzato se i risultati `artifactLocation.uri` sono vuoti. |
| `region.startLine` | Sì | Il numero di riga del primo carattere nella regione. |
| `region.startColumn` | Sì | Il numero di colonna del primo carattere nella regione. |
| `region.endLine` | Sì | Il numero di riga dell'ultimo carattere nella regione. |
| `region.endColumn` | Sì | Il numero di colonna dell'ultimo carattere nella regione. |
## Oggetto `logicalLocation`
| Nome | Richiesto | Description |
| --- | --- | --- |
| `fullyQualifiedName` | No | Informazioni aggiuntive che descrivono la posizione del risultato. Lunghezza massima: 1.024 caratteri |
## Oggetto `fix`
| Nome | Richiesto | Description |
| --- | --- | --- |
| `description.text` | No | Un messaggio che mostra un consiglio per ogni risultato. Lunghezza massima: 3.000 caratteri |
| `artifactChanges.[0].artifactLocation.uri` | No | L'URI che indica la posizione dell'elemento che deve essere aggiornato. |