Om pipelinetester
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Den här artikeln beskriver vanliga termer som används i pipeline testrapport och testanalysoch innehåller tips för bättre testning i Azure Pipelines.
| Term | Definition |
|---|---|
| varaktighet | Tiden som har förflutit under utförandet av ett test, testkörning, eller hela testutförandet i en bygg- eller utgivningspipeline. |
| ägare | Ägare till ett -test eller en -testkörning. Testägaren anges vanligtvis som ett attribut i testkoden. Se Publicera testresultat uppgift för att visa mappningen av attributet Ägare för testresultatformat som stöds. |
| Det går inte att skapa | Referens till bygga med den första förekomsten av efterföljande fel i ett testfall. |
| Det går inte att släppa | Referens till -versionen med den första förekomsten av på varandra följande fel i ett testfall. |
| utfall | Det finns 15 möjliga utfall av ett test: Avbrutet, Blockerat, Fel, Misslyckat, Oklart, Pågående, Inget, Ej tillämpligt, Ej utfört, Ej påverkad, Godkänt, Pausat, Timeout, Ospecificerat och Varning. Några av de vanligaste resultaten är: - Avbruten: Testkörningen avbröts plötsligt på grund av interna eller externa faktorer, t.ex. felaktig kod, miljöproblem. - Misslyckades: Test som inte uppfyller önskat resultat. - Ofullständig: Test utan ett definitivt utfall. - Ej utförd: Test markerad som hoppad över. - Påverkas inte: Testet påverkas inte av kodändringen som utlöste pipelinen. - Godkänd: Testet har körts framgångsrikt. - Timeout: Testkörningens varaktighet överskrider det angivna tröskelvärdet. |
| Opålitligt test | Ett test med icke-deterministiskt beteende. Testet kan till exempel resultera i olika resultat för samma konfiguration, kod eller indata. |
| Filtrera | Mekanism för att söka efter testresultaten i resultatuppsättningen med hjälp av tillgängliga attribut. Läs mer. |
| Gruppering | Ett stöd för att organisera testresultatvyn baserat på tillgängliga attribut, till exempel Requirement, Test files, Prioritymed mera. Både testrapport och testanalys ger stöd för gruppering av testresultat. |
| Procent av passet | Mått på framgång i testresultatet för en enskild genomförande eller under en viss tidsperiod. |
| Prioritet | Anger graden av prioritet eller kritiskhet för ett test. Prioritet anges vanligtvis som ett attribut i testkoden. Se Publicera testresultat uppgift för att visa mappningen av attributet Priority för testresultatformat som stöds. |
| Testanalytik | En vy över historiska testdata för att ge meningsfulla insikter. |
| Testfall | Identifierar unikt ett enskilt test inom den angivna grenen. |
| Testfiler | Gruppera tester baserat på hur de paketeras. till exempel filer, DLL:er eller andra format. |
| Testrapport | En vy över en enskild instans av testkörning i pipelinen som innehåller information om status och hjälp för felsökning, spårning och mycket mer. |
| Testresultat | Enskild instans av körning av ett testfall med ett specifikt resultat och detaljer. |
| Testkörning | Logisk gruppering av testresultat baserat på: - Test som körs med hjälp av inbyggda uppgifter: Alla tester som körs med hjälp av en enda uppgift, till exempel Visual Studio Test, Ant, Maven, Gulp, Grunt eller Xcode rapporteras under en enda testkörning - Resultat som publicerats med Publicera testresultat uppgift: Ger ett alternativ för att gruppera alla testresultat från en eller flera testresultatfiler i en enda körning eller enskilda körningar per fil - Testresultat som publicerats med hjälp av API:er: API:er ger flexibiliteten att skapa testkörningar och organisera testresultat för varje körning efter behov. |
| Spårningsbarhet | Möjlighet att spåra framåt eller bakåt till ett krav, en bugg eller källkod från ett testresultat. |
Metodtips
För att säkerställa programmets tillförlitlighet krävs omfattande testning i Azure Pipelines, där enhetstester och integreringstester är viktiga. Testning av integreringar i molnmiljöer, särskilt serverlösa program, innebär utmaningar på grund av distribuerade arkitekturer, felkonfigurerade IAM-behörigheteroch integreringsproblem mellan tjänster.
För att åtgärda detta bör du överväga att köra koden lokalt medan du interagerar med äkta Azure-tjänster, underlättar realistiska tester och aktiverar felsökningsverktyg som är lämpliga för automatiserad testning. Implementering av den här metoden kräver etablering av tillfälliga Azure-resurser. Vi rekommenderar att du skapar separata konton för varje miljö; Alternativt är dynamisk etablering i Azure-pipelines möjlig, även om detta ökar körningstiden och kräver noggrann resursavstängningsplanering. Undvik explicit namngivning av resurser om det inte behövs och inkludera miljönamn i resursnamn för att minimera namngivningskonflikter.
Hjälp och support
- Se vår felsökningssida för
- Få råd om Stack Overflowoch få support via Developer Community