Dela via

Överväganden för användargränssnittstestning

  • Artikel

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

När du kör automatiserade tester i CI/CD-pipelinen kan du behöva en särskild konfiguration för att kunna köra användargränssnittstester, till exempel Selenium-, Appium- eller Coded-användargränssnittstester. Den här artikeln beskriver de typiska övervägandena för att köra användargränssnittstester.

Förutsättningar

Bekanta dig med agenter och distribuera en agent i Windows.

Huvudlöst läge eller synligt användargränssnittsläge?

När du kör Selenium-tester för en webbapp kan du starta webbläsaren på två sätt:

  1. Huvudlöst läge. I det här läget körs webbläsaren som vanligt men utan att några gränssnittskomponenter visas. Även om det här läget inte är användbart för att surfa på webben är det användbart för att köra automatiserade tester på ett obevakat sätt i en CI/CD-pipeline. Chrome - och Firefox-webbläsare kan köras i huvudlöst läge.

    Det här läget förbrukar vanligtvis mindre resurser på datorn eftersom användargränssnittet inte återges och testerna körs snabbare. Därför kan potentiellt fler tester köras parallellt på samma dator för att minska den totala testkörningstiden.

    Skärmbilder kan hämtas i det här läget och användas för felsökningsfel.

    Kommentar

    Microsoft Edge-webbläsaren kan för närvarande inte köras i huvudlöst läge.

  2. Synligt användargränssnittsläge. I det här läget körs webbläsaren normalt och gränssnittskomponenterna visas. När du kör tester i det här läget i Windows krävs särskild konfiguration av agenterna .

Om du kör användargränssnittstester för ett skrivbordsprogram, till exempel Appium-tester med WinAppDriver - eller Coded UI-tester, krävs en särskild konfiguration av agenterna .

Dricks

Användargränssnittstester från slutpunkt till slutpunkt tenderar vanligtvis att vara tidskrävande. När du använder det synliga användargränssnittsläget kan du, beroende på testramverket, kanske inte köra tester parallellt på samma dator eftersom appen måste vara i fokus för att ta emot tangentbords- och mushändelser. I det här scenariot kan du påskynda testcyklerna genom att köra tester parallellt på olika datorer. Se köra tester parallellt för alla testkörare och kör tester parallellt med hjälp av Visual Studio Test-uppgift.

Gränssnittstestning i synligt användargränssnittsläge

En särskild konfiguration krävs för att agenter ska kunna köra användargränssnittstester i synligt användargränssnittsläge.

Synlig användargränssnittstestning med Microsoft-värdbaserade agenter

Synlig UI-testning i stöds inte i Microsoft-värdbaserade agenter. Testet misslyckas med felmeddelandet "elementet kan inte interageras". Microsoft-värdbaserade agenter stöder huvudlös webbläsartestning.

Användargränssnittstest i huvudlöst läge med microsoft-värdbaserade agenter

Microsoft-värdbaserade agenter är förkonfigurerade för användargränssnittstestning och användargränssnittstester för webbappar. Microsoft-värdbaserade agenter är också förkonfigurerade med populära webbläsare och matchande webbdrivrutinsversioner som kan användas för att köra Selenium-tester. Webbläsare och motsvarande webbdrivrutiner uppdateras regelbundet. Mer information om hur du kör Selenium-tester finns i Användargränssnittstest med Selenium.

Synlig användargränssnittstestning med lokalt installerade Windows-agenter

Agenter som är konfigurerade att köras som tjänst kan endast köra Selenium-tester med huvudlösa webbläsare. Om du inte använder en huvudlös webbläsare, eller om du kör användargränssnittstester för skrivbordsappar, måste Windows-agenter konfigureras för att köras som en interaktiv process med automatisk loggning aktiverat.

När du konfigurerar agenter väljer du Nej när du uppmanas att köra som en tjänst. Med efterföljande steg kan du sedan konfigurera agenten med automatisk inloggning. När användargränssnittstesterna körs startas program och webbläsare i kontexten för användaren som anges i inställningarna för automatisk inloggning.

Om du använder Fjärrskrivbord för att komma åt den dator där en agent körs med automatisk loggning kan det hända att datorn låses när fjärrskrivbordet kopplas från och alla användargränssnittstester som körs på den här agenten misslyckas. Undvik fel genom att använda tscon-kommandot på fjärrdatorn för att koppla från Fjärrskrivbord. Till exempel:

%windir%\System32\tscon.exe 1 /dest:console

I det här exemplet är talet "1" ID för fjärrskrivbordssessionen. Det här numret kan ändras mellan fjärrsessioner, men kan visas i Aktivitetshanteraren. Om du vill automatisera sökningen efter det aktuella sessions-ID:t kan du också skapa en batchfil som innehåller följande kod:

for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do (
  %windir%\System32\tscon.exe %%s /dest:console
)

Spara batchfilen och skapa en genväg till den och ändra sedan genvägsegenskaperna till "Kör som administratör". När du kör batchfilen från den här genvägen kopplas den från fjärrskrivbordet, men användargränssnittssessionen bevaras och användargränssnittstester kan köras.

Etableringsagenter på virtuella Azure-datorer för användargränssnittstestning

Om du etablerar virtuella datorer i Azure är agentkonfiguration för gränssnittstestning tillgänglig via agentartefakten för DevTest Labs.

agentArtifactDTL

Ställa in skärmupplösning

Innan du kör användargränssnittstester kan du behöva justera skärmupplösningen så att apparna återges korrekt. För detta är en skärmupplösningsverktygsuppgift tillgänglig från Marketplace. Använd den här uppgiften i pipelinen för att ange skärmupplösningen till ett värde som stöds av agentdatorn. Som standard anger det här verktyget upplösningen till det optimala värde som stöds av agentdatorn.

Om du stöter på fel med hjälp av skärmmatchningsaktiviteten kontrollerar du att agenten är konfigurerad för att köras med automatisk inloggning aktiverat och att alla fjärrskrivbordssessioner kopplas från på ett säkert sätt med hjälp av tscon-kommandot enligt beskrivningen ovan.

Kommentar

Skärmupplösningsverktyget körs på den enhetliga bygg-/versions-/testagenten och kan inte användas med den inaktuella uppgiften Kör funktionella tester. Lösningsåtgärden fungerar inte heller för virtuella Azure-datorer.

Felsöka fel i användargränssnittstester

När du kör användargränssnittstester på ett obevakat sätt är det användbart att samla in diagnostikdata, till exempel skärmbilder eller video , för att identifiera programmets tillstånd när felet påträffades.

Ta skärmbilder

De flesta gränssnittstestramverk ger möjlighet att ta skärmdumpar. Skärmbilderna som samlas in är tillgängliga som en bifogad fil till testresultaten när dessa resultat publiceras på servern.

Om du använder Visual Studio-testuppgiften för att köra tester måste insamlade skärmbilder läggas till som en resultatfil för att vara tillgänglig i testrapporten. Använd följande kod för detta:

Kontrollera först att TestContext har definierats i testklassen. Till exempel: public TestContext TestContext { get; set; }

Lägg till skärmbildsfilen med hjälp av TestContext.AddResultFile(fileName); //Where fileName is the name of the file.

Om du använder aktiviteten Publicera testresultat för att publicera resultat kan bifogade testresultat endast publiceras om du använder VSTest-resultatformatet (TRX) eller NUnit 3.0-resultatformatet .

Resultatbilagor kan inte publiceras om du använder JUnit- eller xUnit-testresultat. Det beror på att dessa testresultatformat inte har någon formell definition för bifogade filer i resultatschemat. Du kan använda någon av metoderna nedan för att publicera testbilagor i stället.

Spela in video

Om du använder Visual Studio-testuppgiften för att köra tester kan video av testet fångas in och är automatiskt tillgänglig som en bifogad fil till testresultatet. För detta måste du konfigurera videodatainsamlaren i en .runsettings-fil och den här filen måste anges i aktivitetsinställningarna.

runSettings

Hjälp och support