Ускорение тестирования с помощью анализа влияния тестов (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 и получите поддержку через Сообщество разработчиков

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