Aceleración de las pruebas mediante el Análisis de impacto en las pruebas (TIA)

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

La integración continua (CI) es una práctica clave en el sector. Las integraciones son frecuentes y se comprueban con una compilación automatizada que ejecuta pruebas de regresión para detectar errores de integración lo antes posible. Sin embargo, a medida que la base de código crece y madura, su conjunto de pruebas de regresión tiende a crecer también, hasta el punto de que la ejecución de una prueba de regresión completa podría requerir horas. Esta prueba ralentiza la frecuencia de las integraciones y, en última instancia, derrota el propósito de la integración continua.

Para tener una canalización de CI que se complete rápidamente, algunos equipos aplazan la ejecución de sus pruebas de ejecución más largas en una fase independiente de la canalización. Sin embargo, esta acción solo sirve para derrotar aún más la integración continua.

En su lugar, habilite Análisis de impacto de pruebas (TIA) al usar la tarea Prueba de Visual Studio en una canalización de compilación. El TIA realiza la validación incremental mediante la selección automática de pruebas. Selecciona automáticamente solo el subconjunto de pruebas necesarias para validar el código que se confirma. Para una confirmación de código determinada que escriba la canalización de CI/CD, el TIA selecciona y ejecuta solo las pruebas pertinentes necesarias para validar esa confirmación. Por lo tanto, esa ejecución de pruebas se completa más rápidamente, si se produce un error, obtiene información antes y, dado que todo tiene ámbito por relevancia, el análisis también es más rápido.

El análisis de impacto en las pruebas (TIA) tiene:

• Un mecanismo de selección de pruebas sólido. Incluye las pruebas afectadas existentes, las pruebas con errores anteriores y las pruebas recién agregadas.
• Reserva segura. En el caso de confirmaciones y escenarios que el TIA no puede entender, vuelve a ejecutar todas las pruebas. El TIA está actualmente en el ámbito de solo código administrado y topología de máquina única. Por lo tanto, por ejemplo, si la confirmación del código contiene cambios en archivos HTML o CSS, no puede razonar sobre ellos y revierte a la ejecución de todas las pruebas.
• Invalidaciones configurables. Puede ejecutar todas las pruebas en una periodicidad configurada.

Sin embargo, tenga en cuenta las siguientes advertencias al usar el TIA con Visual Studio 2015:

• Ejecución de pruebas en paralelo. En este caso, las pruebas se ejecutan en serie.
• Ejecución de pruebas con cobertura de código habilitada. En este caso, los datos de cobertura de código no se recopilan.

Escenarios admitidos para el análisis de impacto de pruebas

El análisis de impacto en las pruebas (TIA) se admite en los escenarios siguientes:

• TFS 2017 Update 1 y Azure Pipelines
• Versión 2.* de la tarea Prueba de Visual Studio en la canalización de compilación
• Compilación de vNext, con varias tareas de VSTest
• VS2015 Update 3 y versiones posteriores en el agente de compilación
• Agentes de compilación locales y hospedados
• CI y en flujos de trabajo de PR
• Repositorios de Git, GitHub, otros Git, repositorios TFVC (incluidos los asignados parcialmente con una solución alternativa)
• Interacciones de IIS (a través de REST, API SOAP), mediante protocolos HTTP o HTTPS
• Pruebas automatizadas
• Topología de máquina única. Las pruebas y la aplicación (SUT) deben ejecutarse en la misma máquina.
• Código administrado (cualquier aplicación de .NET Framework, cualquier servicio .NET)

El TIA no es compatible en los escenarios siguientes:

• Topología de varias máquinas (donde la prueba está ejecutando una aplicación implementada en una máquina diferente)
• Pruebas controladas por datos
• Ejecución paralela de pruebas específicas del adaptador
• .NET Core
• UWP

Más información sobre el ámbito y las aplicaciones del TIA

Habilitar el análisis de impacto de las pruebas

El TIA se admite a través de la versión 2.* de la tarea Prueba de Visual Studio. Si la aplicación es de nivel único, lo que debe hacer es comprobar Ejecutar solo las pruebas afectadas en la interfaz de usuario de la tarea. El recopilador de datos de impacto de prueba se configura automáticamente. No es necesario ningún paso más.

Si la aplicación interactúa con un servicio en el contexto de IIS, también debe configurar el recopilador de datos de impacto de prueba para que se ejecute en el contexto de IIS mediante un archivo .runsettings . En el ejemplo siguiente se crea esta configuración:

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

Visualización del resultado del análisis de impacto de pruebas

El TIA se integra en los informes de pruebas existentes en los niveles de resumen y detalles, incluidos los correos electrónicos de notificación.

Más información sobre la integración del TIA y Azure Pipelines

Administrar el comportamiento del análisis de impacto de pruebas

Puede influir en la forma en que las pruebas se incluyen o se omiten durante una ejecución de prueba:

• A través de la interfaz de usuario de la tarea VSTest. El TIA puede condicionarse para ejecutar todas las pruebas con una periodicidad configurada. Se recomienda establecer esta opción, que es el medio para regular la selección de pruebas.
• Estableciendo una variable de compilación. Incluso después de habilitar el TIA en la tarea VSTest, puede deshabilitarlo para una compilación específica estableciendo la variable DisableTestImpactAnalysis en true. Esta invalidación obliga al TIA a ejecutar todas las pruebas para esa compilación. En las compilaciones posteriores, el TIA vuelve a la selección de prueba optimizada.

Cuando el TIA abre una confirmación y ve un tipo de archivo desconocido, vuelve a ejecutar todas las pruebas. Aunque esta acción es buena desde una perspectiva de seguridad, el ajuste de este comportamiento puede ser útil en algunos casos. Por ejemplo:

• Establezca la variable TI_IncludePathFilters en trazados específicos para incluir solo estas rutas de acceso en un repositorio para el que desea que se aplique el TIA. Esta acción resulta útil cuando los equipos usan un repositorio compartido. Establecer esta variable deshabilita el TIA para todos los demás trazados no incluidos en la configuración.
• Establezca la variable TIA_IncludePathFilters para especificar tipos de archivo que no influyen en el resultado de las pruebas y para qué cambios se deben omitir. Por ejemplo, para omitir los cambios en los archivos .csproj, establezca la variable en el valor: !\*\*\\\*.csproj.

Use el patrón minimatch al establecer variables y separar varios elementos con punto y coma.

Para evaluar si el TIA selecciona las pruebas adecuadas:

• Valide manualmente la selección. Un desarrollador que sepa cómo se diseñan los SUT y las pruebas podría validar manualmente la selección de pruebas mediante las funcionalidades de informes del TIA.
• Ejecute pruebas seleccionadas por el TIA y, a continuación, todas las pruebas en secuencia. En una canalización de compilación, use dos tareas de prueba: una que solo ejecute pruebas afectadas (T1) y otra que ejecute todas las pruebas (T2). Si T1 pasa, compruebe que T2 también pasa. Si se produjo una prueba con errores en T1, compruebe que T2 notifica el mismo conjunto de errores.

Más información sobre la configuración avanzada del TIA

Proporcionar asignaciones de dependencias personalizadas

El TIA usa asignaciones de dependencias del siguiente formulario.

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

El TIA puede generar un mapa de dependencias para la ejecución de código administrado. Cuando estas dependencias residen en archivos .cs y .vb, el TIA puede observar automáticamente las confirmaciones en dichos archivos y, a continuación, ejecutar pruebas que tenían estos archivos de origen en su lista de dependencias.

Puede ampliar el ámbito del TIA proporcionando explícitamente la asignación de dependencias como un archivo XML. Por ejemplo, es posible que quiera admitir código en otros lenguajes, como JavaScript o C++, o bien admitir el escenario en el que las pruebas y el código de producto se ejecutan en diferentes máquinas. La asignación puede ser incluso aproximada y el conjunto de pruebas que desea ejecutar se puede especificar en términos de un filtro de caso de prueba, como normalmente proporcionaría en los parámetros de la tarea VSTest.

El archivo XML debe estar protegido en el repositorio, normalmente en el nivel raíz. A continuación, establezca la variable de compilación TIA.UserMapFile para que apunte a él. Por ejemplo, si el archivo se denomina TIAmap.xml, establezca la variable en $(System.DefaultWorkingDirectory)/TIAmap.xml.

Para obtener un ejemplo del formato de archivo XML, consulte Asignación de dependencias personalizada del TIA.

Consulte también

• Introducción al TIA e integración de VSTS
• Ámbito y aplicaciones del TIA
• Configuración avanzada del TIA
• Asignación de dependencias personalizadas del TIA

Ayuda y soporte técnico

• Vea la guía de solución de problemas
• Obtenga consejos sobre Stack Overflow y soporte técnico de Developer Community