Acelerar o teste usando a TIA (Análise de Impacto de Teste)

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

A CI (integração contínua) é uma prática fundamental no setor. As integrações são frequentes e verificadas com um build automatizado que executa testes de regressão para detectar 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 reduz a frequência de integrações e, por fim, invalida a finalidade da integração contínua.

Para ter um pipeline de CI concluído rapidamente, algumas equipes adiam a execução de seus testes de execução mais longa para uma fase separada no pipeline. Mas, esta ação só serve para invalidar ainda mais a integração contínua.

Em vez disso, habilite a TIA (Análise de Impacto de Teste) ao usar a tarefa Teste do Visual Studio em um pipeline de build. A TIA executa a validação incremental por seleção automática de teste. 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 insere o 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 está no escopo por relevância, a análise também é mais rápida.

A análise do impacto do teste tem:

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

No entanto, lembre-se das seguintes advertências ao usar o TIA com o Visual Studio 2015:

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

Cenários com suporte para Análise de Impacto de Teste

A Análise de Impacto de Teste (TIA) é suportada para os seguintes cenários:

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

TIA não têm suporte nos cenários a seguir:

• Topologia de vários computadores (em que o teste está exercendo um aplicativo implantado em um computador diferente)
• Testes direcionados a dados
• Execução de teste paralela específica do adaptador de teste
• .NET Core
• UWP

Mais informações sobre o escopo e os aplicativos da TIA

Habilitar Análise do Impacto de Teste

A TIA tem suporte por meio da versão 2.* da tarefa teste do Visual Studio. Se seu aplicativo for um aplicativo de camada única, bastará marcar Executar somente testes afetados na interface do usuário da tarefa. O coletor de dados impacto de teste é configurado automaticamente. Não são necessárias outras etapas.

Se o aplicativo interagir com um serviço no contexto do IIS, você também deverá configurar o coletor de dados de teste de impacto para execução no contexto do IIS usando um arquivo .runsettings. O exemplo a seguir cria a configuração de host:

<?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>

Exibir o resultado da Análise de Impacto do Teste

A TIA é integrada aos relatórios de teste existentes nos níveis de resumo e detalhes, incluindo emails de notificação.

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

Gerenciar o comportamento da Análise de Impacto de Teste

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

• Por meio da interface do usuário da tarefa VSTest. A TIA pode ser condicionada para executar todos os testes em uma periodicidade configurada. A definição dessa opção é recomendada e é o meio de regular a seleção de teste.
• Como definir uma variável de build. Mesmo depois que a TIA tiver sido habilitada na tarefa VSTest, ela pode ser desabilitada para um build específico definindo a variável DisableTestImpactAnalysis como true. Essa substituição força a TIA a executar todos os testes para esse build. Em builds subsequentes, a TIA volta para a seleção de teste otimizada.

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

• Defina a variável TI_IncludePathFilters como caminhos específicos para incluir apenas esses caminhos em um repositório ao qual você deseja aplicar a TIA. Esta ação é útil quando as equipes usam um repositório compartilhado. Definir essa variável desabilita a 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 minimatch ao definir variáveis e separe vários itens com um ponto e vírgula.

Para avaliar se a TIA está selecionando os testes apropriados:

• Valide manualmente a seleção. Um desenvolvedor que sabe como o SUT e os testes são projetados pode validar manualmente a seleção de teste usando as funcionalidades de relatório da TIA.
• Execute os testes selecionados da TIA e, em seguida, todos os testes em sequência. Em um pipeline de build, use duas tarefas de teste: uma que executa apenas testes afetados (T1) e outra que executa todos os testes (T2). Se T1 passar, marcar que T2 também passe. Se houve um teste com falha no T1, marcar que o T2 relata o mesmo conjunto de falhas.

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

Fornecer mapeamentos de dependência personalizados

A TIA usa mapas de dependência do formulário a seguir.

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

A TIA pode gerar esse mapa de dependência para execução de código gerenciado. Quando essas dependências residem em arquivos .cs e .vb, aTIA pode inspecionar automaticamente confirmações nesses arquivos e 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 dar suporte ao código em outras linguagens, como JavaScript ou C++, ou dar suporte ao cenário em que testes e código do produto estão em execução em computadores 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 de tarefa VSTest.

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

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

Confira Também

• Visão geral da TIA e integração do VSTS
• Escopo e aplicativos da TIA
• Configuração avançada da TIA
• Mapeamento de dependência personalizado da TIA

Ajuda e suporte

• Confira nossa página de solução de problemas
• Obtenha conselhos sobre Stack Overflow e obtenha suporte por meio do Developer Community