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