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

Статья
04/04/2024

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

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

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

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

Анализ влияния на тест имеет:

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

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

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

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

В настоящее время TIA поддерживается для:

TFS 2017 с обновлением 1 и Azure Pipelines
Версия 2.* задачи тестирования Visual Studio в конвейере сборки
Сборка 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 с помощью файла runettings . Ниже приведен пример, который создает эту конфигурацию:

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

См. также

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

См. нашу страницу по устранению неполадок
Получите советы по Stack Overflow и получите поддержку через Сообщество разработчиков