Oefening: belastingstests uitvoeren in Azure Pipelines

Voltooid

In deze sectie voert u het testplan uit dat u hebt gemaakt in de release-pijplijn. Het testplan maakt gebruik van Apache JMeter om belastingstests uit te voeren.

U voert de tests als volgt uit:

• Haal een Git-vertakking op en bekijk deze die de tests implementeert.
• Wijzig uw pijplijn om JMeter te installeren, voer het testplan uit, transformeer de resultaten naar JUnit en publiceer de resultaten naar Azure Pipelines.
• Push uw branch naar GitHub, kijk hoe de tests worden uitgevoerd in Azure Pipelines en controleer vervolgens de resultaten.

Haal de branch van GitHub op

In deze sectie haalt u de jmeter vertakking op van GitHub en checkt u deze vertakking uit of schakelt u over naar die vertakking.

Deze tak bevat het Space Game project waarmee u in eerdere modules hebt gewerkt. Het bevat ook een Azure Pipelines-configuratie om mee te beginnen.

1. Open in Visual Studio Code de geïntegreerde terminal.

2. Als u een vertakking met de naam jmeter wilt downloaden uit de Microsoft-opslagplaats en wilt overschakelen naar die vertakking, voert u de volgende git fetch en git checkout opdrachten uit:

   git fetch upstream jmeter
   git checkout -B jmeter upstream/jmeter
   

   Zoals u weet, verwijst upstream naar de Microsoft GitHub-opslagplaats. De Git-configuratie van uw project begrijpt de externe upstream omdat u die relatie hebt ingesteld wanneer u het project uit de Microsoft-opslagplaats hebt gesplitst en het lokaal hebt gekloond.

   Binnenkort pusht u deze tak naar uw GitHub-opslagplaats, die ook wel originwordt genoemd.

3. Open eventueel in Visual Studio Code het azure-pipelines.yml-bestand. Controleer de eerste configuratie.

   De configuratie lijkt op de configuratie die u in eerdere modules in dit leertraject hebt gemaakt. Hiermee wordt alleen de release--configuratie van de toepassing gebouwd. Kortom, het weglaat de triggers, handmatige goedkeuringen en tests die u in eerdere modules hebt ingesteld.

   Notitie

   Een robuustere configuratie kan de branches opgeven die deelnemen aan het build-proces. Als u bijvoorbeeld de codekwaliteit wilt controleren, kunt u eenheidstests uitvoeren telkens wanneer u een wijziging op een vertakking pusht. U kunt de toepassing ook implementeren in een omgeving die uitgebreidere tests uitvoert. Maar u doet deze implementatie alleen wanneer u een pull-aanvraag hebt, wanneer u een releasekandidaat hebt of wanneer u code samenvoegt naar hoofd-.

   Zie Een codewerkstroom implementeren in uw build-pijplijn met behulp van Git en GitHub en Build-pijplijntriggersvoor meer informatie.

4. U kunt desgewenst in Visual Studio Code het JMeter-testplanbestand bekijken, LoadTest.jmxen de XLST-transformatie JMeter2JUnit.xsl. Het XLST-bestand transformeert de JMeter-uitvoer naar JUnit, zodat Azure Pipelines de resultaten kan visualiseren.

Variabelen toevoegen aan Azure Pipelines

Het oorspronkelijke testplan van het team biedt een in code vastgelegde waarde voor de hostnaam van de Space Game website die wordt uitgevoerd in de faseringsomgeving.

Uw versie maakt gebruik van een JMeter-eigenschap om het testplan flexibeler te maken. U kunt een eigenschap beschouwen als een variabele die u vanaf de opdrachtregel kunt instellen.

Hier ziet u hoe de hostname variabele wordt gedefinieerd in JMeter:

Hier ziet u hoe de hostname variabele de __P-functie gebruikt om de hostname variabele te lezen.

Het bijbehorende testplanbestand, LoadTest.jmx, specificeert deze variabele en gebruikt deze om de hostnaam in te stellen.

Wanneer u JMeter uitvoert vanaf de opdrachtregel, gebruikt u het argument -J om de eigenschap hostname in te stellen. Hier volgt een voorbeeld:

apache-jmeter-5.4.3/bin/./jmeter -n -t LoadTest.jmx -o Results.xml -Jhostname=tailspin-space-game-web-staging-1234.azurewebsites.net

Hier stelt u de STAGING_HOSTNAME variabele in Azure Pipelines in. Deze variabele verwijst naar de hostnaam van jouw site die draait op App Service in je stagingsomgeving. U stelt ook de jmeterVersion in om de te installeren versie van JMeter op te geven.

Wanneer de agent wordt uitgevoerd, worden deze variabelen automatisch geëxporteerd naar de agent als omgevingsvariabelen, zodat uw pijplijnconfiguratie JMeter op deze manier kan uitvoeren:

apache-jmeter-5.4.3/bin/./jmeter -n -t LoadTest.jmx -o Results.xml -Jhostname=$(STAGING_HOSTNAME)

We gaan nu de pijplijnvariabelen toevoegen voordat u de pijplijnconfiguratie bijwerkt. Ga hiervoor als volgt te werk:

1. Ga in Azure DevOps naar je Space Game - web - niet-functionele testen project.

2. Selecteer onder PijplijnenBibliotheek.

3. Selecteer de variabelegroep Release.

4. Selecteer onder Variabelen+toevoegen.

5. Voer STAGING_HOSTNAMEin als de naam van de variabele. Voer voor de waarde de URL in van het App Service-exemplaar dat overeenkomt met uw fase ringsomgeving, zoals tailspin-space-game-web-staging-1234.azurewebsites.net.

   Belangrijk

   Neem het http:// of https:// protocolvoorvoegsel niet op in uw waarde. JMeter biedt het protocol wanneer de tests worden uitgevoerd.

6. Voeg een tweede variabele toe met de naam jmeterVersion. Geef 5,4.3op voor de waarde.

   Notitie

   Dit is de versie van JMeter die we voor het laatst hebben gebruikt om deze module te testen. Ga naar Download Apache JMeterom de nieuwste versie te verkrijgen.

7. Als u de variabele wilt opslaan in de pijplijn, selecteert u Opslaan boven aan de pagina.

   Uw variabelegroep lijkt op de groep die wordt weergegeven in de volgende afbeelding:

   

De pijplijnconfiguratie wijzigen

In deze sectie wijzigt u de pijplijn om uw loadtests uit te voeren in de Staging-fase.

1. Open in Visual Studio Code het azure-pipelines.yml-bestand. Wijzig vervolgens het bestand als volgt:

   Fooi

   U kunt het hele bestand vervangen of het gedeelte bijwerken dat is gemarkeerd.

   trigger:
   - '*'
   
   variables:
     buildConfiguration: 'Release'
   
   stages:
   - stage: 'Build'
     displayName: 'Build the web application'
     jobs:
     - job: 'Build'
       displayName: 'Build job'
       pool:
         vmImage: 'ubuntu-20.04'
         demands:
         - npm
   
       variables:
         wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
         dotnetSdkVersion: '6.x'
   
       steps:
       - task: UseDotNet@2
         displayName: 'Use .NET SDK $(dotnetSdkVersion)'
         inputs:
           version: '$(dotnetSdkVersion)'
   
       - task: Npm@1
         displayName: 'Run npm install'
         inputs:
           verbose: false
   
       - script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
         displayName: 'Compile Sass assets'
   
       - task: gulp@1
         displayName: 'Run gulp tasks'
   
       - script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
         displayName: 'Write build info'
         workingDirectory: $(wwwrootDir)
   
       - task: DotNetCoreCLI@2
         displayName: 'Restore project dependencies'
         inputs:
           command: 'restore'
           projects: '**/*.csproj'
   
       - task: DotNetCoreCLI@2
         displayName: 'Build the project - $(buildConfiguration)'
         inputs:
           command: 'build'
           arguments: '--no-restore --configuration $(buildConfiguration)'
           projects: '**/*.csproj'
   
       - task: DotNetCoreCLI@2
         displayName: 'Publish the project - $(buildConfiguration)'
         inputs:
           command: 'publish'
           projects: '**/*.csproj'
           publishWebProjects: false
           arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
           zipAfterPublish: true
   
       - publish: '$(Build.ArtifactStagingDirectory)'
         artifact: drop
   
   - stage: 'Dev'
     displayName: 'Deploy to the dev environment'
     dependsOn: Build
     jobs:
     - deployment: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: dev
       variables:
       - group: Release
       strategy:
         runOnce:
           deploy:
             steps:
             - download: current
               artifact: drop
             - task: AzureWebApp@1
               displayName: 'Azure App Service Deploy: website'
               inputs:
                 azureSubscription: 'Resource Manager - Tailspin - Space Game'
                 appName: '$(WebAppNameDev)'
                 package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
   
   - stage: 'Test'
     displayName: 'Deploy to the test environment'
     dependsOn: Dev
     jobs:
     - deployment: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: test
       variables:
       - group: 'Release'
       strategy:
         runOnce:
           deploy:
             steps:
             - download: current
               artifact: drop
             - task: AzureWebApp@1
               displayName: 'Azure App Service Deploy: website'
               inputs:
                 azureSubscription: 'Resource Manager - Tailspin - Space Game'
                 appName: '$(WebAppNameTest)'
                 package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
   
   - stage: 'Staging'
     displayName: 'Deploy to the staging environment'
     dependsOn: Test
     jobs:
     - deployment: Deploy
       pool:
         vmImage: 'ubuntu-20.04'
       environment: staging
       variables:
       - group: 'Release'
       strategy:
         runOnce:
           deploy:
             steps:
             - download: current
               artifact: drop
             - task: AzureWebApp@1
               displayName: 'Azure App Service Deploy: website'
               inputs:
                 azureSubscription: 'Resource Manager - Tailspin - Space Game'
                 appName: '$(WebAppNameStaging)'
                 package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
     - job: RunLoadTests
       dependsOn: Deploy
       displayName: 'Run load tests'
       pool:
         vmImage: 'ubuntu-20.04'
       variables:
       - group: Release
       steps:
       - script: |
           wget -c archive.apache.org/dist/jmeter/binaries/apache-jmeter-$(jmeterVersion).tgz
           tar -xzf apache-jmeter-$(jmeterVersion).tgz
         displayName: 'Install Apache JMeter'
       - script: apache-jmeter-$(jmeterVersion)/bin/./jmeter -n -t LoadTest.jmx -o Results.xml -Jhostname=$(STAGING_HOSTNAME)
         displayName: 'Run Load tests'
       - script: |
           sudo apt-get update
           sudo apt-get install xsltproc
           xsltproc JMeter2JUnit.xsl Results.xml > JUnit.xml
         displayName: 'Transform JMeter output to JUnit'
       - task: PublishTestResults@2
         inputs:
           testResultsFormat: JUnit
           testResultsFiles: JUnit.xml
   

   Hier volgt een samenvatting van de wijzigingen:

   • De RunLoadTests-taak voert belastingtests uit vanuit een Linux-agent.
   • De RunLoadTests taak is afhankelijk van de Deploy taak om ervoor te zorgen dat de taken in de juiste volgorde worden uitgevoerd. U moet de website implementeren in App Service voordat u de belastingstests kunt uitvoeren. Als u deze afhankelijkheid niet opgeeft, kunnen taken in de fase in elke willekeurige volgorde worden uitgevoerd of parallel worden uitgevoerd.
   • De eerste script taak downloadt en installeert JMeter. De jmeterVersion pijplijnvariabele geeft de versie van JMeter op die moet worden geïnstalleerd.
   • De tweede script-taak voert JMeter uit. Met het argument -J wordt de eigenschap hostname in JMeter ingesteld door de STAGING_HOSTNAME variabele uit de pijplijn te lezen.
   • De derde script taak installeert xsltproc-, een XSLT-processor en transformeert de JMeter-uitvoer naar JUnit.
   • De PublishTestResults@2 taak plaatst het resulterende JUnit-rapport, JUnit.xml, in de pijplijn. Met Azure Pipelines kunt u de testresultaten visualiseren.

2. Voeg in de geïntegreerde terminal azure-pipelines.yml toe aan de index, voer de wijzigingen door en push de vertakking naar GitHub.

   git add azure-pipelines.yml
   git commit -m "Run load tests with Apache JMeter"
   git push origin jmeter
   

Bekijk hoe Azure Pipelines de tests uitvoert

Hier bekijkt u het pijplijnproces. U ziet dat de belastingstests worden uitgevoerd tijdens Staging.

1. Ga in Azure Pipelines naar de build en traceer deze terwijl deze wordt uitgevoerd.

   Tijdens faserings-ziet u dat de belastingstests worden uitgevoerd nadat de website is geïmplementeerd.

2. Nadat de build is voltooid, gaat u naar de overzichtspagina.

   

   U ziet dat de implementatie en de belastingstests zijn voltooid.

3. Noteer de samenvatting aan de bovenkant van de pagina.

   U ziet dat het buildartefact voor de Space Game-website zoals altijd wordt gepubliceerd. Let ook op de sectie Tests en dekking, waarin wordt aangegeven dat de belastingstests zijn geslaagd.

   

4. Selecteer de testsamenvatting om het volledige rapport weer te geven.

   In het rapport ziet u dat beide tests zijn geslaagd.

   

   Als er een test mislukt, ziet u gedetailleerde resultaten van de fout. Op basis van deze resultaten kunt u de bron van de fout onderzoeken.

   Zoals u weet, produceert het XSLT-bestand een JUnit-bestand met de naam JUnit.xml. Het JUnit-bestand beantwoordt deze twee vragen:

   • Is de gemiddelde aanvraagtijd minder dan één seconde?
   • Duurt het minder dan 10 procent van de aanvragen meer dan één seconde om te voltooien?

   Het rapport bewijst dat aan deze vereisten wordt voldaan. Als u meer details wilt zien, selecteert u de pijl Resultaat in het rapport. Zorg er vervolgens voor dat alleen Geslaagd is geselecteerd.

   

   U ziet dat de gemiddelde reactietijd en maximale reactietijd testcases beide zijn geslaagd.

   

Notitie

U gebruikt het B1 App Service-plan, dat wordt uitgevoerd op de laag Basic. Dit plan is bedoeld voor apps met weinig verkeer, zoals apps in een testomgeving. Vanwege dit plan zijn de prestaties van uw website mogelijk minder dan verwacht. In de praktijk kiest u een plan voor de faseringsomgeving die nauwer overeenkomt met uw productieomgeving. De Standard-- en Premium--abonnementen zijn bijvoorbeeld bedoeld voor productieworkloads. Deze worden uitgevoerd op toegewezen exemplaren van virtuele machines.