Przyspieszanie testowania przy użyciu analizy wpływu testów (TIA)

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

Ciągła integracja (CI) to kluczowa praktyka w branży. Integracje są częste i weryfikowane przy użyciu zautomatyzowanej kompilacji, która uruchamia testy regresji w celu jak najszybszego wykrywania błędów integracji. Jednak wraz ze wzrostem i dojrzewaniem bazy kodu jej zestaw testów regresji również rośnie — do tego stopnia, że uruchomienie pełnego testu regresji może wymagać godzin. Ten test spowalnia częstotliwość integracji i ostatecznie pokonuje cel ciągłej integracji.

Aby mieć potok ciągłej integracji, który zostanie ukończony szybko, niektóre zespoły odroczyć wykonywanie dłuższych uruchomionych testów do oddzielnego etapu w potoku. Jednak ta akcja służy tylko do dalszej porażki ciągłej integracji.

Zamiast tego włącz analizę wpływu testu (TIA) podczas korzystania z zadania Test programu Visual Studio w potoku kompilacji. Funkcja TIA przeprowadza walidację przyrostowa przez automatyczny wybór testu. Automatycznie wybiera tylko podzbiór testów wymaganych do zweryfikowania zatwierdzonego kodu. W przypadku danego zatwierdzenia kodu wchodzącego w potok ciągłej integracji/ciągłego wdrażania TIA wybiera i uruchamia tylko odpowiednie testy wymagane do zweryfikowania tego zatwierdzenia. W związku z tym przebieg testu zostanie ukończony szybciej, jeśli wystąpi błąd, otrzymasz alert wcześniej i ponieważ wszystkie są objęte zakresem istotności, analiza jest też szybsza.

Analiza wpływu testu ma:

• Niezawodny mechanizm wyboru testów. Obejmuje istniejące testy, których dotyczy ten wpływ, wcześniej testy zakończone niepowodzeniem i nowo dodane testy.
• Bezpieczny powrót. W przypadku zatwierdzeń i scenariuszy, których TIA nie może zrozumieć, wraca do uruchamiania wszystkich testów. TIA jest obecnie ograniczona tylko do zarządzanego kodu i topologii pojedynczej maszyny. Na przykład jeśli zatwierdzenie kodu zawiera zmiany w plikach HTML lub CSS, nie może się z nich zapoznać i powrócić do uruchamiania wszystkich testów.
• Konfigurowalne przesłonięcia. Wszystkie testy można uruchamiać w skonfigurowanym okresie.

Należy jednak pamiętać o następujących zastrzeżeniach w przypadku korzystania z TIA w programie Visual Studio 2015:

• Równoległe uruchamianie testów. W takim przypadku testy są uruchamiane szeregowo.
• Uruchamianie testów z włączonym pokryciem kodu. W takim przypadku dane pokrycia kodu nie są zbierane.

Obsługiwane scenariusze analizy wpływu testów

Analiza wpływu testu (TIA) jest obsługiwana w następujących scenariuszach:

• TfS 2017 Update 1 i Azure Pipelines
• Wersja 2.* zadania testowego programu Visual Studio w potoku kompilacji
• Kompilowanie narzędzia vNext z wieloma zadaniami VSTest
• Program VS2015 Update 3 jest nowszy na agencie kompilacji
• Lokalni i hostowani agenci kompilacji
• Przepływy pracy ciągłej integracji i żądań ściągnięcia
• Git, GitHub, Other Git, TFVC repos (w tym częściowo mapowane repozytoria TFVC z obejściem)
• Interakcje z usługami IIS (za pośrednictwem interfejsów API REST, SOAP) przy użyciu protokołów HTTP/HTTPS
• Testy automatyczne
• Topologia pojedynczej maszyny. Testy i aplikacja (SUT) muszą być uruchomione na tej samej maszynie.
• Kod zarządzany (dowolna aplikacja .NET Framework, dowolna usługa .NET)

TIA nie jest obsługiwana w następujących scenariuszach:

• Topologia wielu maszyn (gdzie test wykonuje aplikację wdrożona na innej maszynie)
• Testy oparte na danych
• Testowanie wykonywania testów równoległych specyficznych dla adaptera
• .NET Core
• Platforma UWP

Więcej informacji o zakresie i aplikacjach TIA

Włączanie analizy wpływu testu

TIA jest obsługiwana w wersji 2.* zadania testowego programu Visual Studio. Jeśli aplikacja jest aplikacją z jedną warstwą, wystarczy sprawdzić, czy w interfejsie użytkownika zadania uruchomisz tylko testy , których dotyczy ten wpływ. Moduł zbierający dane wpływu testu jest automatycznie konfigurowany. Nie są wymagane żadne dalsze kroki.

Jeśli aplikacja wchodzi w interakcję z usługą w kontekście usług IIS, należy również skonfigurować moduł zbierający dane Test Impact do uruchamiania w kontekście usług IIS przy użyciu pliku .runsettings . Poniższy przykład tworzy tę konfigurację:

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

Wyświetlanie wyniku analizy wpływu testu

TIA jest zintegrowana z istniejącym raportowaniem testów na poziomie podsumowania i szczegółów, w tym wiadomości e-mail z powiadomieniami.

Więcej informacji na temat integracji usług TIA i Azure Pipelines

Zarządzanie zachowaniem analizy wpływu testu

Możesz wpływać na sposób dołączania lub ignorowania testów podczas przebiegu testu:

• Za pomocą interfejsu użytkownika zadania VSTest. TIA może być warunkowa, aby uruchamiać wszystkie testy w skonfigurowanym okresie. Ustawienie tej opcji jest zalecane i jest sposobem regulowania wyboru testu.
• Ustawiając zmienną kompilacji. Nawet po włączeniu funkcji TIA w zadaniu VSTest można wyłączyć ją dla określonej kompilacji, ustawiając zmienną DisableTestImpactAnalysis na wartość true. To zastąpienie wymusza, aby TIA uruchamiała wszystkie testy dla tej kompilacji. W kolejnych kompilacjach TIA wraca do zoptymalizowanego wyboru testu.

Gdy TIA otworzy zatwierdzenie i zobaczy nieznany typ pliku, wraca do uruchamiania wszystkich testów. Chociaż ta akcja jest dobra z punktu widzenia bezpieczeństwa, dostrajanie tego zachowania może być przydatne w niektórych przypadkach. Na przykład:

• Ustaw zmienną TI_IncludePathFilters na określone ścieżki, aby uwzględnić tylko te ścieżki w repozytorium, dla którego ma być stosowane TIA. Ta akcja jest przydatna, gdy zespoły korzystają z udostępnionego repozytorium. Ustawienie tej zmiennej wyłącza funkcję TIA dla wszystkich innych ścieżek, które nie zostały uwzględnione w ustawieniu.
• Ustaw zmienną TIA_IncludePathFilters , aby określić typy plików, które nie mają wpływu na wynik testów i dla których zmiany powinny być ignorowane. Aby na przykład zignorować zmiany w plikach csproj, ustaw zmienną na wartość : !\*\*\\\*.csproj.

Użyj wzorca minimatch podczas ustawiania zmiennych i oddzielania wielu elementów średnikami.

Aby ocenić, czy TIA wybiera odpowiednie testy:

• Ręcznie zweryfikuj zaznaczenie. Deweloper, który wie, w jaki sposób zaprojektowano architekturę SUT i testy, może ręcznie zweryfikować wybór testu przy użyciu funkcji raportowania TIA.
• Uruchom wybrane testy TIA, a następnie wszystkie testy w sekwencji. W potoku kompilacji użyj dwóch zadań testowych — jednego, który uruchamia tylko testy, których dotyczy wpływ (T1) i jednego, który uruchamia wszystkie testy (T2). Jeśli T1 przebiegnie, sprawdź, czy T2 również przechodzi. Jeśli w T1 wystąpił test zakończony niepowodzeniem, sprawdź, czy T2 zgłasza ten sam zestaw błędów.

Więcej informacji na temat konfiguracji TIA advanced configuration

Udostępnianie niestandardowych mapowań zależności

TIA używa map zależności w następującej formie.

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

TIA może wygenerować mapę zależności na potrzeby wykonywania kodu zarządzanego. Jeśli takie zależności znajdują się w .cs plikach i .vb , TIA może automatycznie obserwować zatwierdzenia w takich plikach, a następnie uruchamiać testy, które miały te pliki źródłowe na liście zależności.

Zakres TIA można rozszerzyć, jawnie podając mapę zależności jako plik XML. Na przykład możesz chcieć obsługiwać kod w innych językach, takich jak JavaScript lub C++, lub obsługiwać scenariusz, w którym testy i kod produktu są uruchomione na różnych maszynach. Mapowanie może być nawet przybliżone, a zestaw testów, które chcesz uruchomić, można określić pod względem filtru przypadku testowego, takiego jak zwykle w parametrach zadania VSTest.

Plik XML należy zaewidencjonować w repozytorium, zazwyczaj na poziomie głównym. Następnie ustaw zmienną kompilacji TIA. UserMapFile , aby wskazać go. Jeśli na przykład plik ma nazwę TIAmap.xml, ustaw zmienną $(System.DefaultWorkingDirectory)/TIAmap.xml.

Aby zapoznać się z przykładem formatu pliku XML, zobacz Niestandardowe mapowanie zależności TIA.

Zobacz też

• Omówienie usługi TIA i integracja usługi VSTS
• Zakres i aplikacje TIA
• Zaawansowana konfiguracja TIA
• Niestandardowe mapowanie zależności TIA

Pomoc i obsługa techniczna 

• Zobacz naszą stronę rozwiązywania problemów
• Uzyskaj porady dotyczące rozwiązania Stack Overflow i uzyskaj pomoc techniczną za pośrednictwem społeczności deweloperów