Påskynda testningen med hjälp av Test Impact Analysis (TIA)

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Kontinuerlig integrering (CI) är en viktig praxis i branschen. Integreringar är frekventa och verifieras med en automatiserad version som kör regressionstester för att identifiera integreringsfel så snart som möjligt. Men när kodbasen växer och mognar tenderar dess regressionstestsvit att växa också – i den utsträckning som det kan ta timmar att köra ett fullständigt regressionstest. Den här testningen saktar ned integreringsfrekvensen och besegrar slutligen syftet med kontinuerlig integrering.

För att ha en CI-pipeline som slutförs snabbt skjuter vissa team upp körningen av sina tester som körs längre till en separat fas i pipelinen. Men denna åtgärd tjänar bara till att ytterligare besegra kontinuerlig integrering.

Aktivera i stället Test Impact Analysis (TIA) när du använder Visual Studio-testaktiviteten i en bygg-pipeline. TIA utför inkrementell validering genom automatisk testval. Den väljer automatiskt endast den delmängd av tester som krävs för att verifiera koden som checkas in. För en viss kodincheckning som anger CI/CD-pipelinen väljer och kör TIA endast de relevanta tester som krävs för att verifiera incheckningen. Därför slutförs testkörningen snabbare, om det uppstår ett fel som du får aviseringar tidigare och eftersom allt är begränsat av relevans, är analysen också snabbare.

Jämförelse av testtider vid användning av TIA

Analys av testpåverkan har:

  • En robust testvalsmekanism. Den innehåller befintliga påverkade tester, tidigare misslyckade tester och nyligen tillagda tester.
  • Säker reserv. För incheckningar och scenarier som TIA inte kan förstå, återgår det till att köra alla tester. TIA är för närvarande begränsad till endast hanterad kod och topologi för en enda dator. Så om kodincheckningen till exempel innehåller ändringar i HTML- eller CSS-filer kan den inte resonera om dem och återgår till att köra alla tester.
  • Konfigurerbara åsidosättningar. Du kan köra alla tester med en konfigurerad periodicitet.

Tänk dock på följande varningar när du använder TIA med Visual Studio 2015:

  • Köra tester parallellt. I det här fallet körs testerna seriellt.
  • Köra tester med kodtäckning aktiverat. I det här fallet samlas inte kodtäckningsdata in.

Scenarier som stöds för testpåverkansanalys

Test impact analysis (TIA) stöds för följande scenarier:

  • TFS 2017 Uppdatering 1 och senare och Azure Pipelines
  • Version 2.* av Visual Studio-testaktiviteten i bygg-pipelinen
  • Skapa vNext med flera VSTest-uppgifter
  • VS2015 Uppdatering 3 och senare på byggagenten
  • Lokala och värdbaserade byggagenter
  • CI och i PR-arbetsflöden
  • Git, GitHub, Andra Git- och TFVC-lagringsplatser (inklusive delvis mappade TFVC-lagringsplatser med en lösning)
  • IIS-interaktioner (via REST, SOAP-API:er) med hjälp av HTTP/HTTPS-protokoll
  • Automatiserade tester
  • Topologi för en enda dator. Tester och appar (SUT) måste köras på samma dator.
  • Hanterad kod (alla .NET Framework-appar, alla .NET-tjänster)

TIA stöds inte för följande scenarier:

  • Topologi för flera datorer (där testet utövar en app som distribueras till en annan dator)
  • Datadrivna tester
  • Testa adapterspecifik parallell testkörning
  • .NET Core
  • UWP

Mer information om TIA-omfång och program

Aktivera analys av testpåverkan

TIA stöds via version 2.* av Visual Studio-testaktiviteten. Om din app är ett program på en nivå behöver du bara kontrollera Kör endast tester som påverkas i aktivitetsgränssnittet . Datainsamlaren Test Impact konfigureras automatiskt. Inga ytterligare steg krävs.

Aktivera TIA i vs-testaktivitetens användargränssnitt

Om ditt program interagerar med en tjänst i kontexten för IIS måste du även konfigurera datainsamlaren Test Impact så att den körs i kontexten för IIS med hjälp av en .runsettings-fil . Följande exempel skapar den här konfigurationen:

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

Visa resultat av analys av testpåverkan

TIA är integrerat i befintlig testrapportering på både sammanfattnings- och informationsnivå, inklusive e-postaviseringar.

Rapportsammanfattning innehåller TIA-integrering

Sidan Rapporteringstester innehåller TIA-integrering

Mer information om TIA- och Azure Pipelines-integrering

Hantera beteende för analys av testpåverkan

Du kan påverka hur testerna antingen inkluderas eller ignoreras under en testkörning:

  • Via VSTest-uppgiftsgränssnittet. TIA kan villkoras för att köra alla tester med en konfigurerad periodicitet. Att ange det här alternativet rekommenderas och är ett sätt att reglera testvalet.
  • Genom att ange en byggvariabel. Även när TIA har aktiverats i VSTest-aktiviteten kan du inaktivera den för en specifik version genom att ange variabeln DisableTestImpactAnalysis till true. Den här åsidosättningen tvingar TIA att köra alla tester för den versionen. I efterföljande versioner går TIA tillbaka till optimerat testval.

När TIA öppnar en incheckning och ser en okänd filtyp återgår den till att köra alla tester. Även om den här åtgärden är bra ur ett säkerhetsperspektiv kan det vara användbart att justera det här beteendet i vissa fall. Till exempel:

  • Ange variabeln TI_IncludePathFilters till specifika sökvägar så att endast dessa sökvägar inkluderas i en lagringsplats som du vill att TIA ska gälla för. Den här åtgärden är användbar när team använder en delad lagringsplats. Om du anger den här variabeln inaktiveras TIA för alla andra sökvägar som inte ingår i inställningen.
  • Ange TIA_IncludePathFilters variabel för att ange filtyper som inte påverkar resultatet av tester och för vilka ändringar ska ignoreras. Om du till exempel vill ignorera ändringar i.csproj-filer anger du variabeln till värdet: !\*\*\\\*.csproj.

Använd minimatchmönstret när du ställer in variabler och separera flera objekt med semikolon.

Så här utvärderar du om TIA väljer lämpliga tester:

  • Verifiera markeringen manuellt. En utvecklare som vet hur SUT och tester utformas kan manuellt validera testvalet med hjälp av TIA-rapporteringsfunktionerna.
  • Kör valda TIA-tester och sedan alla tester i följd. I en byggpipeline använder du två testuppgifter – en som endast kör påverkade tester (T1) och en som kör alla tester (T2). Om T1 passerar kontrollerar du också att T2 passerar. Om det uppstod ett misslyckat test i T1 kontrollerar du att T2 rapporterar samma uppsättning fel.

Mer information om avancerad TIA-konfiguration

Ange anpassade beroendemappningar

TIA använder beroendekartor i följande formulär.

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

TIA kan generera en beroendekarta för körning av hanterad kod. Om sådana beroenden finns i .cs och .vb filer, kan TIA automatiskt titta efter incheckningar i sådana filer och sedan köra tester som hade dessa källfiler i sin lista över beroenden.

Du kan utöka omfånget för TIA genom att uttryckligen ange mappningen av beroenden som en XML-fil. Du kanske till exempel vill ha stöd för kod på andra språk, till exempel JavaScript eller C++, eller stödja scenariot där tester och produktkod körs på olika datorer. Mappningen kan till och med vara ungefärlig, och den uppsättning tester som du vill köra kan anges i termer av ett testfallsfilter som du vanligtvis anger i VSTest-uppgiftsparametrarna.

XML-filen bör checkas in på lagringsplatsen, vanligtvis på rotnivå. Ange sedan byggvariabeln TIA. UserMapFile för att peka på den. Om filen till exempel heter TIAmap.xml anger du variabeln $ (System.DefaultWorkingDirectory)/TIAmap.xml.

Ett exempel på XML-filformatet finns i TIA-anpassad beroendemappning.

Se även

Hjälp och support