A Amazon não CodeCatalyst está mais aberta a novos clientes. Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte [Como migrar do CodeCatalyst](migration.md).
As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Teste com fluxos de trabalho
Em CodeCatalyst, você pode executar testes como parte de diferentes ações do fluxo de trabalho, como criar e testar. Todas essas ações de fluxo de trabalho podem gerar relatórios de qualidade. Uma *ação de teste* é uma ação de fluxo de trabalho que produz relatórios de teste, cobertura de código, análise de composição de software e análise estática. Esses relatórios são exibidos no CodeCatalyst console.
**Topics**
+ [Tipos de relatório de qualidade](#test-reporting)
+ [Adição da ação de teste](test-add-action.md)
+ [Visualização dos resultados de uma ação de teste](test-view-results.md)
+ [Omissão dos testes com falha em uma ação](test.error-handling.md)
+ [Integrando com universal-test-runner](test.universal-test-runner.md)
+ [Configuração de relatórios de qualidade em uma ação](test-config-action.md)
+ [Melhores práticas de teste](test-best-practices.md)
+ [Propriedades SARIF compatíveis](test.sarif.md)
## Tipos de relatório de qualidade
A ação CodeCatalyst de teste da Amazon oferece suporte aos seguintes tipos de relatórios de qualidade. Para ver um exemplo de como formatar esses relatórios em seu YAML, consulte [Exemplo de relatórios de qualidade YAML](test-config-action.md#test.success-criteria-example).
**Topics**
+ [Relatórios de teste](#test-reports)
+ [Relatórios de cobertura de código](#test-code-coverage-reports)
+ [Relatórios de análise de composição de software](#test-sca-reports)
+ [Relatórios de análise estática](#test-static-analysis-reports)
### Relatórios de teste
Em CodeCatalyst, você pode configurar testes de unidade, testes de integração e testes de sistema que são executados durante as compilações. Em seguida, CodeCatalyst pode criar relatórios que contêm os resultados dos seus testes.
Você pode usar um relatório de teste para ajudar a solucionar problemas com seus testes. Se tiver muitos relatórios de teste de várias compilações, você poderá usar seus relatórios de teste para visualizar taxas de falha para ajudá-lo a otimizar suas compilações.
É possível usar os seguintes formatos de arquivo de relatório de testes:
+ Cucumber JSON (.json)
+ JUnit XML (.xml)
+ NUnit XML (.xml)
+ NUnit3 XML (.xml)
+ TestNG XML (.xml)
+ Visual Studio TRX (.trx, .xml)
### Relatórios de cobertura de código
Em CodeCatalyst, você pode gerar relatórios de cobertura de código para seus testes. CodeCatalyst fornece as seguintes métricas de cobertura de código:
Cobertura de linha
Mede quantas declarações seus testes abrangem. Declaração é uma instrução única, que não inclui comentários.
`line coverage = (total lines covered)/(total number of lines)`
Cobertura de ramificações
Mede quantas ramificações seus testes cobrem de cada ramificação possível de uma estrutura de controle, como uma declaração `if` ou `case`.
`branch coverage = (total branches covered)/(total number of branches)`
Os seguintes formatos de arquivo de relatório de cobertura de código são compatíveis:
+ JaCoCo XML (.xml)
+ SimpleCov JSON (gerado por [simplecov, não [simplecov-json](https://github.com/vicentllongo/simplecov-json)](https://github.com/simplecov-ruby/simplecov), .json)
+ Clover XML (versão 3, .xml)
+ Cobertura XML (.xml)
+ LCOV (.info)
### Relatórios de análise de composição de software
Em CodeCatalyst, você pode usar ferramentas de análise de composição de software (SCA) para analisar componentes do seu aplicativo e verificar se há vulnerabilidades de segurança conhecidas. Você pode descobrir e analisar relatórios do SARIF que detalham vulnerabilidades com severidades variadas e formas de corrigi-las. Os valores de gravidade válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`.
Os seguintes formatos de arquivo de relatório SCA são compatíveis:
+ SARIF (.sarif, .json)
### Relatórios de análise estática
Você pode usar relatórios de análise estática (SA) para identificar defeitos no código de origem. Em CodeCatalyst, você pode gerar relatórios de SA para ajudar a resolver problemas em seu código antes de implantá-lo. Esses problemas incluem bugs, vulnerabilidades de segurança, problemas de qualidade e outras vulnerabilidades. Os valores de gravidade válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`.
CodeCatalyst fornece as seguintes métricas de SA:
Bugs
Identifica vários possíveis bugs encontrados em seu código de origem. Esses bugs podem incluir problemas relacionados à segurança da memória. Veja a seguir um exemplo de um 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;
}
```
Vulnerabilidades de segurança
Identifica várias vulnerabilidades de segurança possíveis encontradas em seu código de origem. Essas vulnerabilidades de segurança podem incluir problemas, como armazenar seus tokens secretos em texto simples.
Problemas de qualidade
Identifica vários possíveis problemas de qualidade encontrados em seu código de origem. Esses problemas de qualidade podem incluir problemas relacionados às convenções de estilo. Veja a seguir um exemplo de um problema de qualidade.
```
// The function name doesn't adhere to the style convention of camelCase
int SUBTRACT(int x, int y) {
return x-y
}
```
Outras vulnerabilidades
Identifica várias outras vulnerabilidades possíveis encontradas em seu código de origem.
CodeCatalyst suporta os seguintes formatos de arquivo de relatório SA:
+ PyLint (.py)
+ ESLint (.js, .jsx, .ts, .tsx)
+ SARIF (.sarif, .json)
# Adição da ação de teste
Use o procedimento a seguir para adicionar uma ação de teste ao seu CodeCatalyst fluxo de trabalho.
------
#### [ Visual ]
**Como adicionar uma ação de teste usando o editor visual**
1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **Visual**.
1. Escolha **Ações**.
1. Em **Ações**, selecione **Teste**.
1. Nas guias **Entradas** e **Configuração**, preencha os campos de acordo com suas necessidades. Para ver uma descrição de cada campo, consulte [Ações de criação e de teste YAML](build-action-ref.md). Essa referência fornece informações detalhadas sobre cada campo (e o valor da propriedade YAML correspondente) conforme elas aparecem nos editores YAML e visual.
1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar.
1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente.
------
#### [ YAML ]
**Como adicionar uma ação de criação usando o editor YAML**
1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **YAML**.
1. Escolha **Ações**.
1. Em **Ações**, selecione **Teste**.
1. Modifique as propriedades no código YAML de acordo com as suas necessidades. Uma explicação de cada propriedade disponível é fornecida em [Ações de criação e de teste YAML](build-action-ref.md).
1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar.
1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente.
------
## Definição da ação de teste
A ação de teste é definida como um conjunto de propriedades YAML dentro do arquivo de definição do fluxo de trabalho. Para ter mais informações sobre essas propriedades, consulte [Ações de criação e de teste YAML](build-action-ref.md) em [Definição do YAML do fluxo de trabalho](workflow-reference.md).
# Visualização dos resultados de uma ação de teste
Use as instruções a seguir para visualizar os resultados de uma ação de teste, incluindo os logs, relatórios e variáveis gerados.
**Para visualizar os resultados de uma ação de teste**
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Selecione o nome do fluxo de trabalho. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho.
1. No diagrama do fluxo de trabalho, selecione o nome da ação de teste, por exemplo, **Teste**.
1. Para visualizar os logs gerados por uma ação, selecione **Logs**. Os logs das várias fases de ação são exibidos. Você pode expandir ou recolher os logs conforme necessário.
1. Para visualizar os relatórios de teste produzidos pela ação de teste, selecione **Relatórios** ou, no painel de navegação, selecione **Relatórios**. Para obter mais informações, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting).
1. Para visualizar a configuração usada para a ação de teste, selecione **Configuração**. Para obter mais informações, consulte [Adição da ação de teste](test-add-action.md).
1. Para visualizar as variáveis usadas pela ação de teste, selecione **Variáveis**. Para obter mais informações, consulte [Uso de variáveis em fluxos de trabalho](workflows-working-with-variables.md).
# Omissão dos testes com falha em uma ação
Se sua ação tiver mais de um comando de teste, talvez você queira permitir que comandos de teste subsequentes na ação sejam executados mesmo se um comando anterior falhar. Por exemplo, nos comandos a seguir, talvez você queira que `test2` execute sempre, mesmo se `test1` falhar.
```
Steps:
- Run: npm install
- Run: npm run test1
- Run: npm run test2
```
Normalmente, quando uma etapa retorna um erro, a Amazon CodeCatalyst interrompe a ação do fluxo de trabalho e a marca como falhada. Você pode permitir que as etapas da ação continuem sendo executadas redirecionando a saída de erro para `null`. É possível fazer isso adicionando `2>/dev/null` ao comando. Com essa modificação, o exemplo anterior seria semelhante ao seguinte.
```
Steps:
- Run: npm install
- Run: npm run test1 2>/dev/null
- Run: npm run test2
```
No segundo trecho de código, o status do comando `npm install` será respeitado, mas qualquer erro retornado pelo comando `npm run test1` será ignorado. Como resultado, o comando `npm run test2` é executado. Ao fazer isso, você pode visualizar ambos os relatórios ao mesmo tempo, independentemente de ocorrer um erro.
# Integrando com universal-test-runner
As ações de teste são integradas à ferramenta de linha de comando de código aberto `universal-test-runner`. O `universal-test-runner` usa o [Protocolo de execução de teste](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md) para executar seus testes para qualquer linguagem em uma determinada estrutura. O `universal-test-runner` é compatível com as seguintes estruturas:
+ [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/)
O `universal-test-runner` é instalado somente nas imagens selecionadas para ações de teste. Se você configurar uma ação de teste para usar um Docker Hub ou Amazon ECR personalizado, deverá instalar manualmente o `universal-test-runner` para habilitar recursos de teste avançados. Para fazer isso, instale o Node.js (14 ou superior) na imagem e, depois, instale `universal-test-runner` por meio do `npm` usando o comando shell `- Run: npm install -g @aws/universal-test-runner`. Para ter mais informações sobre como instalar o Node.js no contêiner por meio de comandos shell, consulte [Installing and Updating Node Version Manager](https://github.com/nvm-sh/nvm#install--update-script).
Para obter mais informações sobre o `universal-test-runner`, consulte [O que é universal-test-runner?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner)
------
#### [ Visual ]
**Para usar universal-test-runner no editor visual**
1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Selecione o nome do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **Visual**.
1. Escolha **Ações**.
1. Em **Ações**, selecione **Teste**.
1. Na guia **Configuração**, preencha o campo **Comandos do Shell** atualizando o código de amostra com as estruturas compatíveis de sua escolha. Por exemplo, para usar uma estrutura compatível, você usaria um comando `Run` semelhante ao seguinte.
```
- Run: run-tests
```
Se a estrutura que você deseja não for compatível, considere contribuir com um adaptador ou executor personalizado. Para ver uma descrição do campo de **comandos do Shell**, consulte[Steps](build-action-ref.md#build.configuration.steps).
1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar.
1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente.
------
#### [ YAML ]
**Para usar universal-test-runner no editor YAML**
1. Abra o CodeCatalyst console em [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Selecione o nome do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **YAML**.
1. Escolha **Ações**.
1. Em **Ações**, selecione **Teste**.
1. Modifique o código YAML de acordo com as suas necessidades. Por exemplo, para usar uma estrutura compatível, você usaria um comando `Run` semelhante ao seguinte.
```
Configuration:
Steps:
- Run: run-tests
```
Se a estrutura que você deseja não for compatível, considere contribuir com um adaptador ou executor personalizado. Para ver uma descrição da propriedade **Etapas**, consulte [Steps](build-action-ref.md#build.configuration.steps).
1. (Opcional) Selecione **Validar** para validar o código YAML do fluxo de trabalho antes de confirmar.
1. Selecione **Confirmar**, insira uma mensagem de confirmação e escolha **Confirmar** novamente.
------
# Configuração de relatórios de qualidade em uma ação
Esta seção descreve como configurar um relatório de qualidade em uma ação.
**Topics**
+ [Descoberta automática e relatórios manuais](#test.auto-discovery)
+ [Configuração de critérios de sucesso para relatórios](#test.success-criteria)
+ [Exemplo de relatórios de qualidade YAML](#test.success-criteria-example)
## Descoberta automática e relatórios manuais
Quando a descoberta automática está ativada, CodeCatalyst pesquisa todas as entradas passadas para a ação e todos os arquivos gerados pela própria ação, procurando relatórios de teste, cobertura de código, análise de composição de software (SCA) e análise estática (SA). Você pode visualizar e manipular cada um desses relatórios em CodeCatalyst.
Você também pode configurar manualmente quais relatórios são gerados. Você pode especificar o tipo de relatório que deseja gerar, bem como o formato do arquivo. Para obter mais informações, consulte [Tipos de relatório de qualidade](test-workflow-actions.md#test-reporting).
## Configuração de critérios de sucesso para relatórios
Defina os valores que determinam os critérios de sucesso para um teste, cobertura de código, análise de composição de software (SCA) ou relatório de análise estática (SA).
Os critérios de sucesso são limites que determinam se um relatório é aprovado ou reprovado. CodeCatalyst primeiro gera seu relatório, que pode ser um relatório de teste, cobertura de código, SCA ou SA, e depois aplica os critérios de sucesso aos relatórios gerados. Em seguida, mostra se os critérios de sucesso foram atendidos e em que medida. Se algum relatório não atender aos critérios de sucesso especificados, a CodeCatalyst ação que especificou os critérios de sucesso falhará.
Por exemplo, quando você define os critérios de sucesso para seu relatório de SCA, os valores de vulnerabilidade válidos que variam do mais ao menos grave são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`. Se você definir os critérios para verificar uma vulnerabilidade com a gravidade `HIGH`, o relatório falhará se houver pelo menos uma vulnerabilidade com a gravidade `HIGH` ou nenhuma vulnerabilidade com a gravidade `HIGH`, mas pelo menos uma vulnerabilidade em um nível de gravidade mais alto, como uma vulnerabilidade em uma gravidade `CRITICAL`.
Se você não especificar os critérios de sucesso, então:
+ O CodeCatalyst relatório gerado com base em seus relatórios brutos não exibirá critérios de sucesso.
+ Os critérios de sucesso não serão usados para determinar se a ação do fluxo de trabalho associada será aprovada ou falhará.
------
#### [ Visual ]
**Para configurar critérios de sucesso**
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Escolha um fluxo de trabalho com uma ação que gere um relatório. Este é o relatório ao qual você deseja aplicar os critérios de sucesso. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **Visual**.
1. No diagrama do fluxo de trabalho, escolha a ação que você configurou para gerar CodeCatalyst relatórios.
1. Escolha a guia **Outputs**.
1. Em **Relatórios de descoberta automática** ou em **Configurar relatórios manualmente**, selecione **Critérios de sucesso**.
Os critérios de sucesso são exibidos. Dependendo das suas seleções anteriores, você pode ver uma ou todas essas opções:
**Taxa de aprovação**
Especifique a porcentagem de testes em um relatório de teste que devem ser aprovados para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de taxa de aprovação são aplicados somente aos relatórios de teste. Para ter mais informações sobre os relatórios de teste, consulte [Relatórios de teste](test-workflow-actions.md#test-reports).
**Cobertura de linha**
Especifique a porcentagem de linhas em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de linha são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports).
**Cobertura de ramificações**
Especifique a porcentagem de filiais em um relatório de cobertura de código que devem ser cobertas para que o CodeCatalyst relatório associado seja marcado como aprovado. Os valores válidos são números decimais. Por exemplo: `50`, `60.5`. Os critérios de cobertura de ramificações são aplicados somente aos relatórios de cobertura de código. Para ter mais informações sobre relatórios de cobertura de código, consulte [Relatórios de cobertura de código](test-workflow-actions.md#test-code-coverage-reports).
**Vulnerabilidades (SCA)**
Especifique o número máximo e a gravidade das vulnerabilidades permitidas no relatório SCA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar vulnerabilidades, é necessário especificar:
+ A gravidade mínima das vulnerabilidades que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`.
Por exemplo, se você escolher `HIGH`, as vulnerabilidades `HIGH` e `CRITICAL` serão contabilizadas.
+ O número máximo de vulnerabilidades da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros.
Os critérios de vulnerabilidade são aplicados somente aos relatórios de SCA. Para ter mais informações sobre os relatórios de SCA, consulte [Relatórios de análise de composição de software](test-workflow-actions.md#test-sca-reports).
**Bugs**
Especifique o número máximo e a gravidade dos bugs permitidos no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar bugs, é necessário especificar:
+ A gravidade mínima dos bugs que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`.
Por exemplo, se você escolher `HIGH`, os bugs `HIGH` e `CRITICAL` serão contabilizados.
+ O número máximo de bugs da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros.
Os critérios de bugs são aplicados somente PyLint aos relatórios do ESLint SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports).
**Vulnerabilidades de segurança**
Especifique o número máximo e a gravidade das vulnerabilidades de segurança permitidas no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar vulnerabilidades de segurança, é necessário especificar:
+ A gravidade mínima das vulnerabilidades de segurança que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`.
Por exemplo, se você escolher `HIGH`, as vulnerabilidades de segurança `HIGH` e `CRITICAL` serão contabilizadas.
+ O número máximo de vulnerabilidades de segurança da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros.
Os critérios de vulnerabilidades de segurança são aplicados somente aos PyLint relatórios do ESLint SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports).
**Problemas de qualidade**
Especifique o número máximo e a gravidade dos problemas de qualidade permitidos no relatório SA para que o CodeCatalyst relatório associado seja marcado como aprovado. Para especificar problemas de qualidade, é necessário especificar:
+ A gravidade mínima dos problemas de qualidade que você deseja incluir na contagem. Os valores válidos, do mais grave para o menos grave, são: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` e `INFORMATIONAL`.
Por exemplo, se você escolher `HIGH`, os problemas de qualidade `HIGH` e `CRITICAL` serão contabilizados.
+ O número máximo de problemas de qualidade da gravidade especificada que você deseja permitir. Exceder esse número faz com que o CodeCatalyst relatório seja marcado como falhado. Os valores válidos são números inteiros.
Os critérios de problemas de qualidade são aplicados somente PyLint aos relatórios ESLint da SA. Para ter mais informações sobre os relatórios SA, consulte [Relatórios de análise estática](test-workflow-actions.md#test-static-analysis-reports).
1. Selecione **Confirmar**.
1. Execute seu fluxo de trabalho para CodeCatalyst aplicar critérios de sucesso aos seus relatórios brutos e regenere os CodeCatalyst relatórios associados com as informações dos critérios de sucesso incluídas. Para obter mais informações, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md).
------
#### [ YAML ]
**Para configurar critérios de sucesso**
1. No painel de navegação, escolha **CI/CD** e **Fluxos de trabalho**.
1. Escolha um fluxo de trabalho com uma ação que gere um relatório. Este é o relatório ao qual você deseja aplicar os critérios de sucesso. É possível filtrar pelo nome do repositório ou da ramificação de origem em que o fluxo de trabalho está definido, ou filtrar pelo nome ou o status do fluxo de trabalho.
1. Escolha **Editar**.
1. Selecione **YAML**.
1. No diagrama do fluxo de trabalho, escolha a ação que você configurou para gerar CodeCatalyst relatórios.
1. No painel de detalhes, selecione a guia **Saídas**.
1. Na ação, na `AutoDiscoverReports` seção ou na `Reports` seção, adicione uma **SuccessCriteria**propriedade junto com`PassRate`,`LineCoverage`,`BranchCoverage`,`Vulnerabilities`, `StaticAnalysisBug``StaticAnalysisSecurity`, e `StaticAnalysisQuality` propriedades.
Para ver uma explicação de cada uma dessas propriedades, consulte [Ações de criação e de teste YAML](build-action-ref.md).
1. Selecione **Confirmar**.
1. Execute seu fluxo de trabalho para CodeCatalyst aplicar critérios de sucesso aos seus relatórios brutos e regenere os CodeCatalyst relatórios associados com as informações dos critérios de sucesso incluídas. Para ter mais informações sobre como iniciar um fluxo de trabalho, consulte [Iniciar um fluxo de trabalho executado manualmente](workflows-manually-start.md).
------
## Exemplo de relatórios de qualidade YAML
O exemplo a seguir mostra como configurar manualmente quatro relatórios: um relatório de teste, um relatório de cobertura de código, um relatório de análise de composição de software e um relatório de análise estática.
```
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
```
# Melhores práticas de teste
Ao usar os recursos de teste fornecidos pelo CodeCatalyst, recomendamos que você siga essas melhores práticas.
**Topics**
+ [Descoberta automática](#test.best-auto-discovery)
+ [Critérios de sucesso](#test.best-success-criteria)
+ [Inclusão/exclusão de caminhos](#test.best-include-exclude)
## Descoberta automática
Ao configurar ações CodeCatalyst, a descoberta automática permite que você descubra automaticamente os resultados de várias ferramentas, como relatórios de JUnit teste, e gere CodeCatalyst relatórios relevantes a partir deles. A descoberta automática ajuda a garantir que os relatórios continuem sendo gerados, mesmo se os nomes ou caminhos para as saídas descobertas mudarem. Quando novos arquivos são adicionados, os descobre CodeCatalyst automaticamente e produz relatórios relevantes. No entanto, se você usa a descoberta automática, é importante pensar em alguns dos seguintes aspectos desse recurso:
+ Ao ativar a descoberta automática em sua ação, todos os relatórios descobertos automaticamente do mesmo tipo compartilharão os mesmos critérios de sucesso. Por exemplo, um critério compartilhado, como taxa mínima de aprovação, se aplicaria a todos os relatórios de teste descobertos automaticamente. Se você precisar de critérios diferentes para relatórios do mesmo tipo, configure explicitamente cada um desses relatórios.
+ A descoberta automática também pode encontrar relatórios produzidos por suas dependências e, se os critérios de sucesso estiverem configurados, poderá falhar na ação desses relatórios. Esse problema pode ser resolvido atualizando a configuração do caminho de exclusão.
+ Não é garantido que a descoberta automática produza sempre a mesma lista de relatórios, pois ela verifica a ação em runtime. Se você quiser que um relatório específico seja sempre produzido, configure os relatórios explicitamente. Por exemplo, se os testes parassem de ser executados como parte de sua compilação, a estrutura de teste não produziria nenhuma saída e, como resultado, nenhum relatório de teste seria produzido e a ação poderia ser bem-sucedida. Se você quiser que o sucesso de sua ação dependa desse teste específico, configure explicitamente esse relatório.
**dica**
Ao começar um projeto novo ou existente, use a descoberta automática para todo o diretório do projeto (incluir `**/*`). Isso invoca a geração de relatórios em todos os arquivos do seu projeto, incluindo aqueles em subdiretórios.
Para obter mais informações, consulte [Configuração de relatórios de qualidade em uma ação](test-config-action.md).
## Critérios de sucesso
Você pode impor limites de qualidade em seus relatórios configurando critérios de sucesso. Por exemplo, se dois relatórios de cobertura de código foram descobertos automaticamente, um com uma cobertura de linha de 80% e outro com uma cobertura de linha de 60%, você tem as seguintes opções:
+ Defina os critérios de sucesso da descoberta automática para cobertura de linha em 80%. Isso faria com que o primeiro relatório fosse aprovado e o segundo falhasse, o que resultaria na falha geral da ação. Para desbloquear o fluxo de trabalho, adicione novos testes ao seu projeto até que a cobertura da linha para o segundo relatório exceda 80%.
+ Defina os critérios de sucesso da descoberta automática para cobertura de linha em 60%. Isso faria com que ambos os relatórios fossem aprovados, o que resultaria no sucesso da ação. Você poderia então trabalhar para aumentar a cobertura do código no segundo relatório. No entanto, com essa abordagem, você não pode garantir que a cobertura no primeiro relatório não caia abaixo de 80%.
+ Configure explicitamente um ou ambos os relatórios usando o editor visual ou adicionando uma seção e um caminho YAML explícitos para cada relatório. Isso permitiria que você configurasse critérios de sucesso e nomes personalizados separados para cada relatório. No entanto, com essa abordagem, a ação pode falhar se os caminhos do relatório mudarem.
Para obter mais informações, consulte [Configuração de critérios de sucesso para relatórios](test-config-action.md#test.success-criteria).
## Inclusão/exclusão de caminhos
Ao analisar os resultados da ação, você pode ajustar a lista de relatórios que são gerados CodeCatalyst pela configuração e. `IncludePaths` `ExcludePaths`
+ Use `IncludePaths` para especificar os arquivos e caminhos de arquivo que você CodeCatalyst deseja incluir ao pesquisar relatórios. Por exemplo, se você especificar`"/test/report/*"`, CodeCatalyst pesquisa toda a imagem de compilação usada pela ação procurando o `/test/report/` diretório. Quando encontra esse diretório CodeCatalyst , procura relatórios nesse diretório.
**nota**
Em relatórios configurados manualmente, `IncludePaths` deverá ser um padrão global que corresponda a um único arquivo.
+ Use `ExcludePaths` para especificar os arquivos e caminhos de arquivo que você CodeCatalyst deseja excluir ao pesquisar relatórios. Por exemplo, se você especificar`"/test/reports/**/*"`, não CodeCatalyst procurará arquivos no `/test/reports/` diretório. Para ignorar todos os arquivos em um diretório, use o padrão de glob `**/*`.
Veja a seguir alguns exemplos de padrões glob possíveis.
| Padrão | Description |
| --- | --- |
| `*.*` | Corresponde a todos os nomes de objetos no diretório atual que contêm um ponto |
| `*.xml` | Corresponde a todos os nomes de objetos no diretório atual que terminam com `.xml` |
| `*.{xml,txt}` | Corresponde a todos os nomes de objetos no diretório atual que terminam com `.xml` ou `.txt` |
| `**/*.xml` | Corresponde aos nomes dos objetos em todos os diretórios que terminam com `.xml` |
| `testFolder` | Corresponde a um objeto chamado `testFolder`, tratando-o como um arquivo |
| `testFolder/*` | Corresponde a objetos em um nível de subpasta de `testFolder`, como `testFolder/file.xml` |
| `testFolder/*/*` | Corresponde a objetos em dois níveis da subpasta de `testFolder`, como `testFolder/reportsFolder/file.xml` |
| `testFolder/**` | Corresponde a subpasta `testFolder` bem como aos arquivos abaixo de `testFolder`, por exemplo, `testFolder/file.xml` e `testFolder/otherFolder/file.xml` |
CodeCatalyst interpreta os padrões globais da seguinte forma:
+ O caractere de barra (`/`) separa os diretórios nos caminhos dos arquivos.
+ O caractere de asterisco (`*`) corresponde a zero ou mais caracteres de um componente de nome sem cruzar limites da pasta.
+ Um asterisco duplo (`**`) corresponde a zero ou mais caracteres de um componente de nome em todos os diretórios.
**nota**
`ExcludePaths` tem precedência sobre `IncludePaths`. Se ambos `IncludePaths` e `ExcludePaths` incluírem a mesma pasta, essa pasta não será examinada em busca de relatórios.
# Propriedades SARIF compatíveis
O Static Analysis Results Interchange Format (SARIF) é um formato de arquivo de saída que está disponível em análise de composição de software (SCA) e relatórios de análise estática na Amazon. CodeCatalyst O exemplo a seguir mostra como configurar manualmente o SARIF em um relatório de análise estática:
```
Reports:
MySAReport:
Format: SARIFSA
IncludePaths:
- output/sa_report.json
SuccessCriteria:
StaticAnalysisFinding:
Number: 25
Severity: HIGH
```
CodeCatalyst suporta as seguintes propriedades SARIF, que podem ser usadas para otimizar a forma como os resultados da análise aparecerão em seus relatórios.
**Topics**
+ [Objeto `sarifLog`](#test.sarif.sarifLog)
+ [Objeto `run`](#test.sarif.run)
+ [Objeto `toolComponent`](#test.sarif.toolComponent)
+ [Objeto `reportingDescriptor`](#test.sarif.reportingDescriptor)
+ [Objeto `result`](#test.sarif.result)
+ [Objeto `location`](#test.sarif.location)
+ [Objeto `physicalLocation`](#test.sarif.physicalLocation)
+ [Objeto `logicalLocation`](#test.sarif.logicalLocation)
+ [Objeto `fix`](#test.sarif.fix)
## Objeto `sarifLog`
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `$schema` | Sim | O URI do esquema SARIF JSON para a versão [2.1.0](https://json.schemastore.org/sarif-2.1.0.json). |
| `version` | Sim | CodeCatalyst suporta apenas a versão 2.1.0 do SARIF. |
| `runs[]` | Sim | Um arquivo SARIF contém uma ou mais execuções, cada uma das quais representando uma única execução da ferramenta de análise. |
## Objeto `run`
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `tool.driver` | Sim | Um objeto `toolComponent` que descreve a ferramenta de análise. |
| `tool.name` | Não | Uma propriedade que indica o nome da ferramenta usada para realizar a análise. |
| `results[]` | Sim | Os resultados da ferramenta de análise que são exibidos em CodeCatalyst. |
## Objeto `toolComponent`
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `name` | Sim | O nome da ferramenta de análise. |
| `properties.artifactScanned` | Não | Um número total de artefatos analisados pela ferramenta. |
| `rules[]` | Sim | Uma matriz de objetos `reportingDescriptor` que representam regras. Com base nessas regras, a ferramenta de análise encontra problemas no código que é analisado. |
## Objeto `reportingDescriptor`
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `id` | Sim | O identificador exclusivo da regra que é usada para referenciar uma descoberta. Tamanho máximo: 1.024 caracteres |
| `name` | Não | O nome de exibição da regra. Tamanho máximo: 1.024 caracteres |
| `shortDescription.text` | Não | Uma descrição resumida da regra. Tamanho máximo: 3.000 caracteres |
| `fullDescription.text` | Não | Uma descrição completa da regra. Tamanho máximo: 3.000 caracteres |
| `helpUri` | Não | Uma string que pode ser localizada para conter o URI absoluto da documentação primária da regra. Tamanho máximo: 3.000 caracteres |
| `properties.unscore` | Não | Um sinalizador que indica se a descoberta do escaneamento foi pontuada. |
| `properties.score.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres |
| `properties.cvssv3_baseSeverity` | Não | Uma classificação de gravidade qualitativa do [Sistema de pontuação de vulnerabilidades comuns v3.1](https://www.first.org/cvss/v3.1/specification-document). |
| `properties.cvssv3_baseScore` | Não | Uma pontuação básica do CVSS v3 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.cvssv2_severity` | Não | Se os valores do CVSS v3 não estiverem disponíveis, CodeCatalyst pesquisa os valores do CVSS v2. |
| `properties.cvssv2_score` | Não | Uma pontuação básica do CVSS v2 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres |
| `defaultConfiguration.level` | Não | A gravidade padrão de uma regra. |
## Objeto `result`
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `ruleId` | Sim | O identificador exclusivo da regra que é usada para referenciar uma descoberta. Tamanho máximo: 1.024 caracteres |
| `ruleIndex` | Sim | O índice da regra associada no componente da ferramenta `rules[]`. |
| `message.text` | Sim | Uma mensagem que descreve o resultado e exibe a mensagem de cada descoberta. Tamanho máximo: 3.000 caracteres |
| `rank` | Não | Um valor entre 0,0 e 100,0, inclusive, que representa a prioridade ou importância do resultado. Essa escala considera 0,0 como a prioridade mais baixa e 100,0 como a prioridade mais alta. |
| `level` | Não | A gravidade do resultado. Tamanho máximo: 1.024 caracteres |
| `properties.unscore` | Não | Um sinalizador que indica se a descoberta do escaneamento foi pontuada. |
| `properties.score.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres |
| `properties.cvssv3_baseSeverity` | Não | Uma classificação de gravidade qualitativa do [Sistema de pontuação de vulnerabilidades comuns v3.1](https://www.first.org/cvss/v3.1/specification-document). |
| `properties.cvssv3_baseScore` | Não | Uma pontuação básica do CVSS v3 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.cvssv2_severity` | Não | Se os valores do CVSS v3 não estiverem disponíveis, CodeCatalyst pesquisa os valores do CVSS v2. |
| `properties.cvssv2_score` | Não | Uma pontuação básica do CVSS v2 variando de [0,0 a 10,0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.severity` | Não | Um conjunto fixo de strings que especificam o nível de gravidade da descoberta. Tamanho máximo: 1.024 caracteres |
| `locations[]` | Sim | O conjunto de locais em que o resultado foi detectado. Somente um local deve ser incluído, a menos que o problema só possa ser corrigido fazendo uma alteração em cada local especificado. CodeCatalyst usa o primeiro valor na matriz de localização para anotar o resultado. Número máximo de objetos `location`: 10 |
| `relatedLocations[]` | Não | Uma lista de referências de localizações adicionais na descoberta. Número máximo de objetos `location`: 50 |
| `fixes[]` | Não | Uma matriz de `fix` objetos que representam a recomendação fornecida pela ferramenta de digitalização. CodeCatalyst usa a primeira recomendação na `fixes` matriz. |
## Objeto `location`
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `physicalLocation` | Sim | Identifica o artefato e a região. |
| `logicalLocations[]` | Não | O conjunto de locais descritos pelo nome sem referência ao artefato. |
## Objeto `physicalLocation`
| Nome | Obrigatório | Descrição |
| --- | --- | --- |
| `artifactLocation.uri` | Sim | O URI que indica a localização de um artefato, geralmente um arquivo no repositório ou gerado durante uma compilação. |
| `fileLocation.uri` | Não | O URI de retorno indicando a localização do arquivo. Isso será usado se `artifactLocation.uri` retornar vazio. |
| `region.startLine` | Sim | O número da linha do primeiro caractere na região. |
| `region.startColumn` | Sim | O número da coluna do primeiro caractere na região. |
| `region.endLine` | Sim | O número da linha do último caractere na região. |
| `region.endColumn` | Sim | O número da coluna do último caractere na região. |
## Objeto `logicalLocation`
| Nome | Obrigatório | Description |
| --- | --- | --- |
| `fullyQualifiedName` | Não | Informações adicionais que descrevem a localização do resultado. Tamanho máximo: 1.024 caracteres |
## Objeto `fix`
| Nome | Obrigatório | Description |
| --- | --- | --- |
| `description.text` | Não | Uma mensagem que exibe uma recomendação para cada descoberta. Tamanho máximo: 3.000 caracteres |
| `artifactChanges.[0].artifactLocation.uri` | Não | O URI que indica a localização do artefato que precisa ser atualizado. |