Поделиться через

Ускорение тестирования с помощью анализа влияния тестов (TIA)

  • Статья

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

Непрерывная интеграция (CI) является ключевой практикой в отрасли. Интеграция часто выполняется и проверяется с помощью автоматической сборки, которая выполняет тесты регрессии для обнаружения ошибок интеграции как можно скорее. Но по мере роста и развития базы кода набор регрессионных тестов обычно также увеличивается, и выполнение полного теста может занять несколько часов. Это тестирование замедляет частоту интеграции и в конечном итоге побеждает цель непрерывной интеграции.

Для быстрого завершения конвейера CI некоторые команды переносят выполнение более длительных тестов на отдельный этап в процессе. Но это действие служит только для дальнейшего поражения непрерывной интеграции.

Вместо этого включите анализ влияния на тест (TIA) при использовании задачи тестирования Visual Studio в конвейере сборки. TIA выполняет добавочную проверку путем автоматического выбора теста. Он автоматически выбирает только подмножество тестов, необходимых для проверки внесения изменений в код. Для коммита кода, который входит в конвейер CI/CD, TIA выбирает и выполняет только соответствующие тесты, необходимые для проверки этого коммита. Таким образом, этот тест выполняется быстрее: если возникает сбой, вы получите оповещение раньше, и благодаря тому, что все это оценивается по релевантности, анализ тоже проходит быстрее.

Сравнение времени тестирования при использовании TIA

У анализа влияния тестов есть:

  • Надежный механизм выбора теста. Он включает существующие затронутые тесты, ранее неудачные тесты и только что добавленные тесты.
  • Безопасный резервный вариант. Для коммитов и сценариев, которые TIA не может понять, TIA возвращается к выполнению всех тестов. TIA в настоящее время ограничивается только управляемым кодом и топологией одного компьютера. Например, если фиксация кода содержит изменения в HTML- или CSS-файлах, система не может их анализировать и поэтому выполняет все тесты.
  • Настраиваемые переопределения. Все тесты можно выполнять в настроенной периодичности.

Однако следует учитывать следующие предостережения при использовании TIA с Visual Studio 2015:

  • Параллельное выполнение тестов. В этом случае тесты выполняются последовательно.
  • Выполнение тестов с активированным покрытием кода. В этом случае данные покрытия кода не собираются.

Поддерживаемые сценарии анализа влияния на тестирование

Анализ влияния на тест (TIA) поддерживается для следующих сценариев:

  • Начиная с обновления 1 для TFS 2017 и Azure Pipelines
  • Задача Visual Studio Test версии 2.* в конвейере сборки
  • Построение vNext с множеством задач VSTest
  • Начиная с обновления 3 для VS2015 на агенте сборки
  • Локальные и размещенные агенты сборки
  • в рабочих процессах CI и в PR
  • Репозитории Git, GitHub, Other Git, TFVC (включая частично сопоставленные репозитории TFVC с обходным решением)
  • Взаимодействие IIS (через REST, API SOAP) с помощью протоколов HTTP/HTTPS
  • Автоматические тесты
  • Топология одного компьютера. Тесты и приложения (SUT) должны выполняться на одном компьютере.
  • Управляемый код (любое приложение платформа .NET Framework, любая служба .NET)

TIA не поддерживается для следующих сценариев:

  • Топология с несколькими компьютерами (где тест выполняет приложение, развернутое на другом компьютере)
  • Тесты на основе данных
  • Выполнение параллельного тестирования для конкретного адаптера
  • .NET Core
  • UWP

Дополнительные сведения о области и приложениях TIA

Включение анализа влияния на тест

TIA поддерживается через версию 2.* задачи Visual Studio Test. Если ваше приложение является одноуровневым, нужно только отметить Выполнение только затронутых тестов в пользовательском интерфейсе задачи. Сборщик данных влияния теста настраивается автоматически. Дальнейшие шаги не требуются.

Включение TIA в пользовательском интерфейсе задачи VS Test

Если ваше приложение взаимодействует со службой в контексте IIS, необходимо также настроить сборщик данных влияния тестирования для работы в контексте IIS, используя файл .runsettings. Следующий пример создает эту конфигурацию:

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

Просмотр результатов анализа влияния на тест

TIA интегрирована в существующие тестовые отчеты на уровне обзора и подробностей, включая уведомления по электронной почте.

Сводка отчетов включает интеграцию TIA

Страница тестирования отчетов включает интеграцию TIA

Дополнительные сведения об интеграции TIA и Azure Pipelines

Управление поведением анализа влияния теста

Вы можете повлиять на то, как тесты включены или игнорируются во время тестового выполнения:

  • Через пользовательский интерфейс задачи VSTest. TIA может быть настроена для запуска всех тестов с заданной периодичностью. Этот параметр рекомендуется использовать и является средством регулирования выбора теста.
  • Задав переменную сборки. Даже после включения TIA в задаче VSTest его можно отключить для определенной сборки, установив для переменной DisableTestImpactAnalysisзначение true. Это переопределение заставляет TIA выполнять все тесты для этой сборки. В последующих сборках TIA возвращается к оптимизированной выборке теста.

Когда TIA открывает коммит и видит неизвестный тип файла, она переходит к выполнению всех тестов. Хотя это действие хорошо с точки зрения безопасности, настройка этого поведения может оказаться полезной в некоторых случаях. Например:

  • Задайте для переменной TI_IncludePathFilters определенные пути, чтобы включить только эти пути в репозиторий, для которого необходимо применить TIA. Это действие полезно, если команды используют общий репозиторий. Установка этой переменной отключает TIA для всех остальных путей, не включенных в параметр.
  • Задайте переменную TIA_IncludePathFilters, чтобы указать типы файлов, которые не влияют на результат тестов и для которых следует игнорировать изменения. Например, чтобы игнорировать изменения в CSPROJ-файлах, задайте для переменной значение: !\*\*\\\*.csproj

Используйте шаблон миниматча при настройке переменных и разделите несколько элементов с запятой.

Чтобы оценить, выбирает ли TIA соответствующие тесты:

  • Вручную проверьте выбор. Разработчик, который знает, как проектируются SUT и тесты, может вручную проверить отбор тестов с помощью возможностей отчетности TIA.
  • Выполните выбранные тесты TIA, а затем все тесты в последовательности. В конвейере сборки используйте две тестовые задачи— одну, которая запускает только затронутые тесты (T1) и ту, которая выполняет все тесты (T2). Если T1 проходит, убедитесь, что T2 также проходит. Если в T1 произошел сбой теста, убедитесь, что T2 сообщает тот же набор сбоев.

Дополнительные сведения о расширенной конфигурации TIA

Предоставление настраиваемых сопоставлений зависимостей

TIA использует карты зависимостей следующей формы.

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

TIA может создать карту зависимостей для выполнения управляемого кода. Где такие зависимости находятся в .cs и .vb файлах, TIA может автоматически отслеживать фиксации в таких файлах, а затем запускать тесты, имеющие эти исходные файлы в их списке зависимостей.

Вы можете расширить сферу действия TIA, явно предоставив сопоставление зависимостей в виде XML-файла. Например, может потребоваться поддерживать код на других языках, таких как JavaScript или C++, или поддерживать сценарий, в котором тесты и код продукта выполняются на разных компьютерах. Сопоставление может быть даже приблизительным, и набор тестов, которые требуется выполнить, можно указать с точки зрения фильтра тестового случая, например, как обычно, в параметрах задачи VSTest.

XML-файл должен быть зафиксирован в вашем репозитории, как правило, на корневом уровне. Затем задайте переменную сборки TIA.UserMapFile, указывающую на него. Например, если файл называется TIAmap.xml, задайте для переменной значение $(System.DefaultWorkingDirectory)/TIAmap.xml.

Пример формата файла XML см. в разделе настраиваемое сопоставление зависимостей TIA.

См. также

Справка и поддержка