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. Testowanie to spowalnia częstotliwość integracji i ostatecznie zaprzepaszcza sens ciągłej integracji.

Aby potok CI kończył się szybko, niektóre zespoły odraczają wykonywanie dłużej trwających testów na oddzielnym etapie 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. TIA przeprowadza walidację inkrementalną przez automatyczny wybór testów. 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 kończy się szybciej, jeśli wystąpi błąd, wcześniej zostaniesz powiadomiony, a ponieważ wszystko jest ukierunkowane na istotność, analiza jest szybsza również.

Analiza wpływu testu ma:

• Niezawodny mechanizm wyboru testów. Obejmuje istniejące testy objęte wpływem, wcześniej zakończone niepowodzeniem testy oraz 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 potrafi ich analizować i zamiast tego uruchamia wszystkie testy.
• 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 zostają zbierane.

Obsługiwane scenariusze analizy wpływu testów

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

• TFS 2017 od aktualizacji 1 wzwyż i Azure Pipelines
• Wersja 2.* zadania testowego programu Visual Studio w potoku kompilacji
• Kompilowanie narzędzia vNext z wieloma zadaniami VSTest
• VS2015 Update 3 lub późniejsza wersja na kompilacyjnym agencie
• Lokalni i hostowani agenci kompilacji
• Przepływy pracy ciągłej integracji i żądania aktualizacji
• Git, GitHub, Inne Git, repozytoria TFVC (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 przez wersję 2.* zadania testowego programu Visual Studio. Jeśli twoja aplikacja jest aplikacją jednotierową, wystarczy zaznaczyć opcję Uruchamiaj tylko dotknięte testy w interfejsie użytkownika zadania. 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 skutków testów

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ć zaprogramowana, aby uruchamiać wszystkie testy z skonfigurowaną częstotliwością. 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 wersjach TIA wraca do zoptymalizowanego wyboru testów.

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 zakończy się poprawnie, sprawdź, czy T2 również zakończy się poprawnie. 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 zaawansowanej konfiguracji TIA

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 plikach .cs i .vb, TIA może automatycznie obserwować zatwierdzenia w tych 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ć za pomocą filtra przypadków testowych, podawanego 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ć ją. 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