Acelere os testes usando a Análise de Impacto de Teste (TIA)

  • Artigo

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

A Integração Contínua (IC) é uma prática chave na indústria. As integrações são frequentes e verificadas com uma compilação automatizada que executa testes de regressão para detetar erros de integração o mais rápido possível. Mas, à medida que a base de código cresce e amadurece, seu conjunto de testes de regressão tende a crescer também - na medida em que a execução de um teste de regressão completa pode exigir horas. Esse teste diminui a frequência das integrações e, em última análise, derrota o propósito da integração contínua.

Para ter um pipeline de CI que seja concluído rapidamente, algumas equipes adiam a execução de seus testes de execução mais longa para um estágio separado no pipeline. Mas, esta ação só serve para derrotar ainda mais a integração contínua.

Em vez disso, habilite a análise de impacto de teste (TIA) ao usar a tarefa de teste do Visual Studio em um pipeline de compilação. O TIA realiza a validação incremental por seleção automática de testes. Ele seleciona automaticamente apenas o subconjunto de testes necessários para validar o código que está sendo confirmado. Para uma determinada confirmação de código que entra no pipeline de CI/CD, a TIA seleciona e executa apenas os testes relevantes necessários para validar essa confirmação. Portanto, essa execução de teste é concluída mais rapidamente, se houver uma falha, você é alertado mais cedo e, como tudo tem escopo por relevância, a análise também é mais rápida.

Comparação dos tempos de teste ao usar AIT

A Análise de Impacto do Teste tem:

  • Um mecanismo robusto de seleção de testes. Inclui testes impactados existentes, testes anteriormente reprovados e testes recém-adicionados.
  • Fallback seguro. Para confirmações e cenários que o TIA não consegue entender, ele volta a executar todos os testes. Atualmente, o TIA tem como escopo apenas código gerenciado e topologia de máquina única. Assim, por exemplo, se a confirmação de código contiver alterações em arquivos HTML ou CSS, ela não poderá raciocinar sobre elas e voltará a executar todos os testes.
  • Substituições configuráveis. Você pode executar todos os testes em uma periodicidade configurada.

No entanto, esteja ciente das seguintes advertências ao usar o TIA com o Visual Studio 2015:

  • Execução de testes em paralelo. Neste caso, os testes são executados em série.
  • Execução de testes com cobertura de código habilitada. Nesse caso, os dados de cobertura de código não são coletados.

Cenários suportados pela Análise de Impacto de Teste

A análise de impacto de teste (TIA) é suportada para os seguintes cenários:

  • TFS 2017 Atualização 1 em diante e Azure Pipelines
  • Versão 2.* da tarefa de teste do Visual Studio no pipeline de compilação
  • Crie o vNext, com várias tarefas VSTest
  • VS2015 Atualização 3 em diante no agente de compilação
  • Agentes de compilação locais e hospedados
  • CI e em fluxos de trabalho de RP
  • Git, GitHub, Outros repositórios Git, TFVC (incluindo repositórios TFVC parcialmente mapeados com uma solução alternativa)
  • Interações do IIS (sobre REST, APIs SOAP), usando protocolos HTTP/HTTPS
  • Testes automatizados
  • Topologia de máquina única. Os testes e o aplicativo (SUT) devem estar em execução na mesma máquina.
  • Código gerenciado (qualquer aplicativo .NET Framework, qualquer serviço .NET)

Não há suporte para TIA nos seguintes cenários:

  • Topologia de várias máquinas (onde o teste está exercendo um aplicativo implantado em uma máquina diferente)
  • Testes orientados por dados
  • Execução de teste paralelo específico do adaptador de teste
  • .NET Core
  • UWP

Mais informações sobre o escopo e as aplicações da TIA

Habilite a análise de impacto do teste

O TIA é suportado através da versão 2.* da tarefa de teste do Visual Studio. Se seu aplicativo for um aplicativo de camada única, tudo o que você precisa fazer é verificar Executar somente testes afetados na interface do usuário da tarefa. O coletor de dados Test Impact é configurado automaticamente. Não são necessárias mais etapas.

Habilitar TIA na interface do usuário da tarefa VS Test

Se seu aplicativo interage com um serviço no contexto do IIS, você também deve configurar o coletor de dados Test Impact para ser executado no contexto do IIS usando um arquivo .runsettings . O exemplo a seguir cria essa configuração:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <!-- This is the TestImpact data collector.-->
      <DataCollector uri="datacollector://microsoft/TestImpact/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TraceCollector.TestImpactDataCollector, Microsoft.VisualStudio.TraceCollector, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Test Impact">
        <Configuration>
          <!-- enable IIS data collection-->
          <InstrumentIIS>True</InstrumentIIS>
          <!-- file level data collection -->
          <ImpactLevel>file</ImpactLevel>
          <!-- any job agent related executable or any other service that the test is using needs to be profiled. -->
          <ServicesToInstrument>
            <Name>TeamFoundationSshService</Name>
          </ServicesToInstrument>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

Ver o resultado da Análise de Impacto do Teste

O TIA é integrado aos relatórios de teste existentes nos níveis de resumo e detalhes, incluindo e-mails de notificação.

O resumo dos relatórios inclui a integração TIA

A página Testes de relatórios inclui integração TIA

Mais informações sobre a integração TIA e Azure Pipelines

Gerenciar o comportamento da Análise de Impacto do Teste

Você pode influenciar a maneira como os testes são incluídos ou ignorados durante uma execução de teste:

  • Através da interface do usuário da tarefa VSTest. O TIA pode ser condicionado a executar todos os testes em uma periodicidade configurada. Recomenda-se definir essa opção e é o meio de regular a seleção do teste.
  • Definindo uma variável de compilação. Mesmo depois que o TIA estiver habilitado na tarefa VSTest, você poderá desativá-lo para uma compilação específica definindo a variável DisableTestImpactAnalysis como true. Essa substituição força o TIA a executar todos os testes para essa compilação. Em compilações subsequentes, o TIA volta para a seleção de teste otimizada.

Quando o TIA abre uma confirmação e vê um tipo de arquivo desconhecido, ele volta a executar todos os testes. Embora essa ação seja boa do ponto de vista da segurança, ajustar esse comportamento pode ser útil em alguns casos. Por exemplo:

  • Defina a variável TI_IncludePathFilters para caminhos específicos para incluir apenas esses caminhos em um repositório ao qual você deseja que o TIA se aplique. Essa ação é útil quando as equipes usam um repositório compartilhado. A configuração dessa variável desabilita o TIA para todos os outros caminhos não incluídos na configuração.
  • Defina a variável TIA_IncludePathFilters para especificar tipos de arquivo que não influenciam o resultado dos testes e para os quais as alterações devem ser ignoradas. Por exemplo, para ignorar alterações em arquivos .csproj, defina a variável como o valor: !\*\*\\\*.csproj.

Use o padrão de minicorrespondência ao definir variáveis e separe vários itens com ponto-e-vírgula.

Para avaliar se o AIT está selecionando os testes apropriados:

  • Valide manualmente a seleção. Um desenvolvedor que sabe como o SUT e os testes são arquitetados pode validar manualmente a seleção do teste usando os recursos de relatório TIA.
  • Execute os testes selecionados do TIA e, em seguida, todos os testes em sequência. Em um pipeline de compilação, use duas tarefas de teste - uma que executa apenas testes impactados (T1) e outra que executa todos os testes (T2). Se T1 passar, verifique se T2 passa também. Se houve um teste de falha em T1, verifique se T2 relata o mesmo conjunto de falhas.

Mais informações sobre a configuração avançada TIA

Fornecer mapeamentos de dependência personalizados

O TIA usa mapas de dependência do seguinte formulário.

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

O TIA pode gerar um mapa de dependência para execução de código gerenciado. Onde essas dependências residem em .cs e .vb arquivos, o TIA pode observar automaticamente confirmações em tais arquivos e, em seguida, executar testes que tinham esses arquivos de origem em sua lista de dependências.

Você pode estender o escopo do TIA fornecendo explicitamente o mapa de dependências como um arquivo XML. Por exemplo, talvez você queira oferecer suporte a código em outras linguagens, como JavaScript ou C++, ou dar suporte ao cenário em que testes e código de produto estão sendo executados em máquinas diferentes. O mapeamento pode até ser aproximado, e o conjunto de testes que você deseja executar pode ser especificado em termos de um filtro de caso de teste, como você normalmente forneceria nos parâmetros da tarefa VSTest.

O arquivo XML deve ser verificado em seu repositório, normalmente no nível raiz. Em seguida, defina a variável build TIA . UserMapFile para apontar para ele. Por exemplo, se o arquivo tiver o nome TIAmap.xml, defina a variável como $(System.DefaultWorkingDirectory)/TIAmap.xml.

Para obter um exemplo do formato de arquivo XML, consulte Mapeamento de dependência personalizado TIA.

Consulte Também

Ajuda e suporte