Over pijplijntests
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
In dit artikel worden veelgebruikte termen beschreven die worden gebruikt in pijplijn , testrapport en testanalyses , en wordt er tips gegeven voor betere tests in Azure Pipelines.
| Begrip | Definitie |
|---|---|
| duur | De tijd die is verstreken tijdens de uitvoering van een test, testuitvoeringof volledige testuitvoering in een build- of release-pijplijn. |
| eigenaar | Eigenaar van een test of testuitvoering. De testeigenaar wordt doorgaans gespecificeerd als een attribuut in de testcode. Zie de Publiceer Testresultaten taak om de mapping van het kenmerk Eigenaar voor ondersteunde testresultaatindelingen te bekijken. |
| mislukte build | Dit verwijst naar de build waarin het eerste geval van opeenvolgende fouten in een testcase voorkomt. |
| mislukte release | Verwijzing naar de release met de eerste keer dat opeenvolgende fouten van een testgeval zijn opgetreden. |
| Resultaat | Er zijn 15 mogelijke resultaten voor een testresultaat: Afgebroken, Geblokkeerd, Fout, Mislukt, Inconclusief, In uitvoering, Geen, Niet van toepassing, Niet uitgevoerd, Geen effect, Geslaagd, Onderbroken, Time-out, Niet gespecificeerd en Waarschuwing. Enkele van de veelgebruikte resultaten zijn: - afgebroken: Testuitvoering is plotseling beëindigd vanwege interne of externe factoren, bijvoorbeeld slechte code, omgevingsproblemen. - Mislukt: Test voldoet niet aan het gewenste resultaat. - niet doorslaggevend: Test zonder definitief resultaat. - Niet uitgevoerd: Test gemarkeerd als overgeslagen voor uitvoering. - Niet beïnvloed: Test niet beïnvloed door de codewijziging die de pijplijn heeft geactiveerd. - geslaagde: Test is succesvol uitgevoerd. - Timeout: Testuitvoeringstijd die de gespecificeerde drempelwaarde overschrijdt. |
| Flaky-test | Een test met niet-deterministisch gedrag. De test kan bijvoorbeeld resulteren in verschillende resultaten voor dezelfde configuratie, code of invoer. |
| filter | Mechanisme voor het zoeken naar de testresultaten in de resultatenset, met behulp van de beschikbare kenmerken. Meer informatie. |
| groeperen | Een hulpmiddel voor het ordenen van de weergave testresultaten op basis van beschikbare kenmerken zoals Vereiste, Testbestanden, Prioriteiten meer. Zowel testrapport als testanalyse ondersteuning bieden voor het groeperen van testresultaten. |
| percentage doorgeven | Meting van het succes van testresultaten voor één exemplaar van uitvoering of gedurende een bepaalde periode. |
| Prioriteit | Hiermee geeft u de mate van belang of kritiek van een test. Prioriteit wordt doorgaans opgegeven als een kenmerk in de testcode. Zie taak Testresultaten publiceren om de toewijzing van het Priority attribuut voor ondersteunde testresultaatformaten weer te geven. |
| Analyses testen | Een weergave van de historische testgegevens om zinvolle inzichten te bieden. |
| Test case | Hiermee wordt een enkele test binnen de opgegeven vertakking uniek geïdentificeerd. |
| Testbestanden | Groepstests op basis van de manier waarop ze worden verpakt; zoals bestanden, DLL's of andere indelingen. |
| testrapport | Een weergave van één exemplaar van testuitvoering in de pijplijn met details van de status en ondersteuning bij probleemoplossing, traceerbaarheid en meer. |
| Testresultaat | Eén exemplaar van de uitvoering van een testcase met een specifiek resultaat en details. |
| testuitvoering | Logische groepering van testresultaten op basis van: - Test uitgevoerd met behulp van ingebouwde taken: alle tests die worden uitgevoerd met één taak, zoals Visual Studio Test, Ant, Maven, Gulp, Grunt of Xcode- worden gerapporteerd onder één testuitvoering - resultaten gepubliceerd met behulp van Testresultaten publiceren taak: Biedt een optie om alle testresultaten van een of meer testresultatenbestanden te groeperen in één uitvoering of afzonderlijke uitvoeringen per bestand - testresultaten die zijn gepubliceerd met API('s): API('s) de flexibiliteit bieden om testuitvoeringen te maken en testresultaten te organiseren voor elke uitvoering zoals vereist. |
| traceerbaarheid | De mogelijkheid om te traceren naar een vereiste, bug of broncode vanuit een testresultaat. |
Beste werkwijzen
Het garanderen van betrouwbaarheid van toepassingen vereist uitgebreide tests in Azure Pipelines, waarbij eenheidstests en integratietests essentieel zijn. Het testen van integraties in cloudomgevingen, met name serverloze toepassingen, vormt uitdagingen vanwege gedistribueerde architecturen, onjuist geconfigureerde IAM-machtigingenen problemen met service-naar-service-integratie.
U kunt dit oplossen door uw code lokaal uit te voeren tijdens interactie met legitieme Azure-services, realistische tests te vergemakkelijken en hulpprogramma's voor foutopsporingsprogramma's in te schakelen die geschikt zijn voor geautomatiseerde tests. Voor het implementeren van deze benadering zijn tijdelijke Azure-resources vereist. Maak idealiter afzonderlijke accounts voor elke omgeving; Dynamische inrichting binnen Azure-pijplijnen is ook mogelijk, hoewel dit de uitvoeringstijd verhoogt en een zorgvuldige planning voor het buiten gebruik stellen van resources vereist. Als u naamconflicten wilt minimaliseren, moet u expliciete naamgeving van resources voorkomen, tenzij dat nodig is en omgevingsnamen in resourcenamen opneemt.
Help en ondersteuning
- Zie onze pagina voor het oplossen van problemen met
- Krijg advies over Stack Overflow-en krijg ondersteuning via de Developer Community-