DevOps integração da ferramenta de teste

  • Versão de lançamento: Xanadu
  • Atualizado 1 de ago. de 2024
  • 6 min. de leitura
  • A integração da ferramenta de teste permite exibir resultados de testes em DevOps para Jenkins, Azure DevOps, GitHub, GitHub Enterprise, e GitLab testes de unidade, funcionais e de desempenho.

    Para GitLab e Jenkins, somente a integração do tipo de teste JUnit é compatível.

    Nota:
    Para outros tipos de teste, use o endpoint DevOps - POST /devops/tool/{capability} da API DevOps.
    • Os testes do Selenium executados e publicados usando o TestNG são relatados pelo plug-in [ Jenkins para ServiceNow DevOps.
    • A categorização do tipo de teste é compatível.
    • Os resultados de testes adicionais relatados por ferramentas, como o Apache JMeter, podem ser processados em DevOps usando subfluxos Workflow Studio ] personalizados (não são necessárias mudanças de pipeline).
    Categoria Tipo de teste
    Unidade

    JUnit (padrão)

    NUnit

    XUnit

    Teste de unidade

    Nota:
    • Para GitLab e Jenkins, somente a integração do tipo de teste JUnit é compatível.
    • Para ADO, GitHub e GitHub Enterprise, as integrações de tipo de teste de unidade, JUnit, NUnit, XUnit e são compatíveis.

    Você pode mudar o tipo de teste padrão modificando o [sn_devops.default_test_type] DevOps propriedade.

    Funcional
    • Integração
    • Regressão
    • Fumaça
    • Sistema
    • Aceitação do usuário
    Desempenho Carregar

    Mapeamento de tipo de teste

    O mapeamento de tipo de teste conecta o tipo de teste e a entidade que está sendo testada à ferramenta DevOps (DevOps > Integrações > Mapeamentos de tipo de teste módulo.)

    Mapeamentos de tipo de teste

    Um mapeamento preciso do tipo de teste garante que o tipo de teste sempre apareça conforme pretendido nos resultados do resumo de teste.

    Campo Descrição
    Tipo de teste
    • JUnit
    • Nunit
    • Xunit
    • Teste de unidade
      Nota:
      • Para GitLab e Jenkins, somente a integração do tipo de teste JUnit é compatível.
      • Para ADO, GitHub e GitHub Enterprise, as integrações de tipo de teste de unidade, JUnit, NUnit, XUnit e são compatíveis.
    • Integração
    • Regressão
    • Fumaça
    • Sistema
    • Aceitação do usuário
    • Carregar
    ID da entidade do DevOps Nome da tabela

    DevOps nome da tabela que contém a entidade vinculada aos resultados de testes (na carga do relatório de teste).

    • Etapa [sn_devops_step]
    • Pipeline [sn_devops_pipeline]
    Nota:
    Somente as tabelas DevOps de Etapa e Pipeline são compatíveis.
    Documento

    Nome da entidade especificada na tabela selecionada.

    Por exemplo, o nome da etapa, pipeline, artefato ou pacote.

    Testar caminhos de arquivo

    (Jenkins testes somente)

    Caminho para o arquivo de resultados de testes gerado no servidor Jenkins.

    Isso é útil para que relatórios de teste com atributos que não estejam em conformidade com a implementação de JUnit ou TestNG, como JMeter, por exemplo, ainda possam ser aproveitados por DevOps.

    Separe vários arquivos por uma vírgula.

    Nota:
    Você deve usar um subfluxo Workflow Studio para transformar uma carga de teste bruta.
    Integração da ferramenta

    Ferramenta que está executando o teste.

    Tabela do DevOps

    DevOps tabela que corresponde ao nome da tabela na configuração de ID de entidade de DevOps.

    Figura 1. DevOps mapeamento de tipo de teste
    Mapeamento de tipo de teste de DevOps
    Figura 2. Exemplo de arquivo yaml de teste de unidade ADO
    Exemplo de arquivo yaml de teste de unidade ADO
    Figura 3. Exemplo de arquivo yaml de teste de unidade do GitHub
    Exemplo de arquivo yaml de teste de unidade do GitHub

    Como transformar uma carga de teste bruta

    Você pode transformar um relatório de teste bruto (um relatório que contém atributos que não estão em conformidade com a implementação de JUnit ou TestNG), como JMeter, por exemplo, configurando a tabela de decisão Política de subfluxo de teste de DevOps para chamar um subfluxo personalizado (Tabelas de Decisão > Tabelas de Decisão módulo).
    Nota:
    Você deve criar o subfluxo Workflow Studio personalizado que transforma a carga de teste bruta.

    Se houver mais de um tipo de teste em uma fase de desempenho, você poderá usar a tabela de decisão Política de tipo de teste do DevOps para configurar o tipo de teste para cada teste para que as cargas do resultado do teste sejam transformadas corretamente.

    Figura 4. DevOps tabelas de decisão
    Tabelas de decisão de DevOps
    Tabela 1. DevOps tabelas de decisão
    Tabela de decisão Finalidade Configuração
    Política de subfluxo de teste de DevOps

    Para chamar automaticamente um subfluxo personalizado que transforma a carga bruta recebida pela ferramenta.

    Entradas de decisão:

    • Carga do resultado de testes
    • Tipo de Teste

    Crie uma decisão que especifica o subfluxo personalizado a ser chamado quando a carga bruta é recebida.

    Defina as condições para conter campos que seriam incluídos na carga bruta.

    Por exemplo, para chamar Jenkins o subfluxo personalizado do Teste de desempenho BZ:

    Condições:
    • O tipo de teste é carga

      (Carga é o tipo de teste configurado para testes de desempenho)

    • A carga do resultado de testes contém rendimento
    • A carga do resultado de testes contém simultaneidade

    Resposta: Flow: Jenkins Teste de desempenho BZ

    Política de tipo de teste de DevOps

    Para definir automaticamente os tipos de teste quando mais de um tipo de teste estiver configurado em uma fase de teste de desempenho.

    Isso é necessário para que os resultados do segundo tipo de teste sejam transformados corretamente.

    Por exemplo, quando um teste de desempenho de carregamento e um teste de desempenho JUnit são mapeados na mesma etapa DevOps, os resultados do teste JUnit não serão formatados corretamente, a menos que uma decisão seja criada.

    Entradas de decisão:
    • Etapa
    • Carga do resultado de testes
    • Integração da Ferramenta
    • Pipeline

    Crie uma decisão para cada tipo de teste na fase de teste de desempenho para definir o tipo de teste.

    Teste de carga:
    • Condições:
      • A etapa é Testes de desempenho
      • A carga do resultado de testes contém rendimento
      • A carga do resultado de testes contém simultaneidade
    • Resposta: TestType: carregar

    Teste JUnit:

    • Condições:
      • A etapa é Testes de desempenho
      • A Carga do Resultado de Testes não contém o rendimento
      • A Carga do Resultado de Testes não contém simultaneidade
    • Resposta: TestType: JUnit

    Figura 5. DevOps vários tipos de teste de desempenho
    Vários tipos de teste de desempenho de DevOps
    Figura 6. DevOps vários mapeamentos de tipo de teste
    Mapeamentos de tipo de teste de DevOps
    Figura 7. DevOps decisão da tabela de decisão
    Decisão da tabela de decisão de DevOps

    Resultados do resumo de teste

    Você pode exibir os resultados do resumo de teste dessas maneiras.
    Figura 8. DevOps exemplo de resumo de teste de desempenho
    Resumo do teste de desempenho de DevOps

    Carga da capacidade de Notificação JSON padrão esperada - Ferramenta de teste

    Funcional:
    { 
    "name": "CorpSite-selenium#55", 
    "duration": 78.802, 
    "passedTests": 4, 
    "failedTests": 0, 
    "skippedTests": 0, 
    "blockedTests": 0, 
    "totalTests": 4, 
    "startTime": "2020-06-30T18:12:31Z", 
    "finishTime": "2020-06-30T18:12:31Z", 
    "passingPercent": 100, 
     
     
    // Use Artifact OR Package OR Build + Stage + PipelineName Attributes 
    
    Send only one Attribute combination. For example, send Attributes of either  Artifact or Package, or the combination of Build + Stage + PipelineName.
    
    If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.
    
    1.packages
    2.artifcats
    3.buildNumber + stageName + pipelineName
    
    "packages": [{"name": "CorpSite-pkg1"}], 
    "artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}], 
    "buildNumber": "55", 
    "stageName": "test", 
    "pipelineName": "CorpSite-selenium", 
    } 
    
    Notes:
    - The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
    - The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.
    Desempenho:
    { 
    "name": "Performance Tests", 
    "url": "http://abc.com", 
    "startTime": "2020-06-30T18:12:31Z", 
    "finishTime": "2020-06-30T18:12:31Z", 
    "duration": 78.802, 
    "maximumVirtualUsers": "", 
    "throughput": "", 
    "maximumTime": "", 
    "minimumTime": "", 
    "averageTime": "", 
    "ninetyPercent": "", 
    "standardDeviation": "", 
     
    // Use Artifact OR Package OR Build + Stage + PipelineName Attributes 
    
    Send only one Attribute combination. For example, send Attributes of either  Artifact or Package, or the combination of Build + Stage + PipelineName.
    
    If you send more than one Attribute, priority is given in the following order and the low priory one is ignored. For example, if you send attribute for both packages and artifacts, then attribute of package is considered and the attribute of artifacts is ignored.
    
    1.packages
    2.artifcats
    3.buildNumber + stageName + pipelineName
    
    "packages": [{"name": "CorpSite-pkg1"}], 
    "artifacts": [{"name": "CorpSite-artifact", "version": "1.0.0"}], 
    "buildNumber": "55", 
    "stageName": "test", 
    "pipelineName": "CorpSite-Performance", 
    } 
    
    Notes:
    - The pipelineName attribute value must be same as the value in the Orchestration pipeline field of the Pipeline [sn_devops_pipeline] table.
    - The stageName attribute value must be same as the value in the Orchestration stage field of the Step [sn_devops_step] table.