Ćwiczenie — uruchamianie testów obciążeniowych w usłudze Azure Pipelines

• 12 min

W tej sekcji uruchomisz plan testowania utworzony w potoku wydania. Plan testu używa narzędzia Apache JMeter do uruchamiania testów obciążeniowych.

Poniżej przedstawiono sposób uruchamiania testów:

Pobieranie gałęzi z repozytorium GitHub

W tej sekcji pobierzesz jmeter gałąź z usługi GitHub i wyewidencjonujesz lub przełączysz się do tej gałęzi.

Ta gałąź zawiera projekt Space Game , z którym pracowaliśmy w poprzednich modułach. Zawiera również konfigurację usługi Azure Pipelines, od których należy zacząć.

1. W programie Visual Studio Code otwórz zintegrowany terminal.

2. Aby pobrać gałąź o nazwie jmeter z repozytorium Firmy Microsoft i przełączyć się do tej gałęzi, uruchom następujące git fetch polecenia i git checkout :

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

   Pamiętaj, że nadrzędny element odnosi się do repozytorium Microsoft GitHub. Konfiguracja usługi Git projektu rozumie nadrzędną relację zdalną, ponieważ podczas tworzenia rozwidlenia projektu z repozytorium Microsoft i klonowania go lokalnie.

   Wkrótce wypchniesz tę gałąź do repozytorium GitHub o nazwie origin.

3. Opcjonalnie w programie Visual Studio Code otwórz plik azure-pipelines.yml . Przejrzyj początkową konfigurację.

   Konfiguracja przypomina te, które zostały utworzone w poprzednich modułach w tej ścieżce szkoleniowej. Kompiluje tylko konfigurację wydania aplikacji. W celu zapewnienia zwięzłości pomija wyzwalacze, zatwierdzenia ręczne i testy skonfigurowane w poprzednich modułach.

   Uwaga

   Bardziej niezawodna konfiguracja może określać gałęzie, które uczestniczą w procesie kompilacji. Na przykład w celu sprawdzenia jakości kodu można uruchamiać testy jednostkowe za każdym razem, gdy wypchniesz zmianę w dowolnej gałęzi. Możesz również wdrożyć aplikację w środowisku, które wykonuje bardziej wyczerpujące testowanie. Jednak to wdrożenie jest możliwe tylko wtedy, gdy masz żądanie ściągnięcia, gdy masz kandydata do wydania lub gdy scalasz kod z główną wersją.

   Aby uzyskać więcej informacji, zobacz Implementowanie przepływu pracy kodu w potoku kompilacji przy użyciu wyzwalaczy git i GitHub i potoku kompilacji.

4. Opcjonalnie w programie Visual Studio Code możesz sprawdzić plik planu testu JMeter, LoadTest.jmx i przekształcenie XLST, JMeter2JUnit.xsl. Plik XLST przekształca dane wyjściowe JMeter na JUnit, aby usługa Azure Pipelines mogła wizualizować wyniki.

Dodawanie zmiennych do usługi Azure Pipelines

Oryginalny plan testowy zespołu zawiera zakodowaną wartość dla nazwy hosta witryny internetowej Space Game działającej w środowisku przejściowym .

Aby plan testu był bardziej elastyczny, wersja używa właściwości JMeter. Należy traktować właściwość jako zmienną, którą można ustawić z poziomu wiersza polecenia.

Oto jak zmienna jest zdefiniowana hostname w JMeter:

Oto jak zmienna hostname używa funkcji __P do odczytywania zmiennej hostname .

Odpowiedni plik planu testu LoadTest.jmx określa tę zmienną i używa jej do ustawienia nazwy hosta.

Po uruchomieniu narzędzia JMeter z wiersza polecenia należy użyć argumentu -J hostname , aby ustawić właściwość . Oto przykład:

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

W tym miejscu ustawisz zmienną STAGING_HOSTNAME w usłudze Azure Pipelines. Ta zmienna wskazuje nazwę hosta witryny uruchomioną w usłudze App Service w środowisku przejściowym . Należy również ustawić parametr jmeterVersion , aby określić wersję parametru JMeter do zainstalowania.

Po uruchomieniu agenta te zmienne są automatycznie eksportowane do agenta jako zmienne środowiskowe, więc konfiguracja potoku może uruchomić narzędzie JMeter w następujący sposób:

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

Teraz dodajmy zmienne potoku przed zaktualizowaniem konfiguracji potoku. Aby to zrobić:

1. W usłudze Azure DevOps przejdź do projektu Space Game — web — testy niefunkcjonalne .

2. W obszarze Potoki wybierz pozycję Biblioteka.

3. Wybierz grupę Zmiennych wydania .

4. W obszarze Zmienne wybierz pozycję + Dodaj.

5. Jako nazwę zmiennej wprowadź STAGING_HOSTNAME. Jako wartość wprowadź adres URL wystąpienia usługi App Service, który odpowiada środowisku przejściowemu , na przykład tailspin-space-game-web-staging-1234.azurewebsites.net.

   Ważne

   Nie dołączaj prefiksu http:// lub https:// protokołu do wartości. JMeter udostępnia protokół po uruchomieniu testów.

6. Dodaj drugą zmienną o nazwie jmeterVersion. Dla jej wartości określ wartość 5.4.3.

   Uwaga

   Jest to wersja narzędzia JMeter, która była ostatnio używana do testowania tego modułu. Aby uzyskać najnowszą wersję, zobacz Pobieranie narzędzia Apache JMeter.

7. Aby zapisać zmienną w potoku, wybierz pozycję Zapisz w górnej części strony.

   Grupa zmiennych przypomina grupę pokazaną na poniższej ilustracji:

   

Modyfikowanie konfiguracji potoku

W tej sekcji zmodyfikujesz potok, aby uruchamiał testy obciążeniowe podczas etapu przejściowego.

1. W programie Visual Studio Code otwórz plik azure-pipelines.yml . Następnie zmodyfikuj plik w następujący sposób:

   Napiwek

   Możesz zastąpić cały plik lub po prostu zaktualizować wyróżnioną część.

   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
   

   Oto podsumowanie zmian:

   • Zadanie RunLoadTests wykonuje testy obciążeniowe z agenta systemu Linux.
   • Zadanie RunLoadTests zależy od Deploy zadania, aby upewnić się, że zadania są uruchamiane w odpowiedniej kolejności. Przed uruchomieniem testów obciążeniowych należy wdrożyć witrynę internetową w usłudze App Service. Jeśli nie określisz tej zależności, zadania w ramach etapu mogą być uruchamiane w dowolnej kolejności lub uruchamiane równolegle.
   • Pierwsze script zadanie pobiera i instaluje JMeter. Zmienna jmeterVersion potoku określa wersję narzędzia JMeter do zainstalowania.
   • script Drugie zadanie uruchamia narzędzie JMeter. -J Argument ustawia hostname właściwość w JMeter, odczytując zmienną STAGING_HOSTNAME z potoku.
   • Trzecie script zadanie instaluje xsltproc, procesor XSLT i przekształca dane wyjściowe JMeter na JUnit.
   • Zadanie PublishTestResults@2 publikuje wynikowy raport JUnit, JUnit.xml, do potoku. Usługa Azure Pipelines może pomóc w wizualizacji wyników testu.

2. W zintegrowanym terminalu dodaj azure-pipelines.yml do indeksu, zatwierdź zmiany i wypchnij gałąź do usługi GitHub.

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

Obejrzyj, jak usługa Azure Pipelines uruchamia testy

W tym miejscu zobaczysz przebieg potoku. Testy obciążeniowe będą uruchamiane podczas przemieszczania.

1. W usłudze Azure Pipelines przejdź do kompilacji i prześledź ją podczas jej uruchamiania.

   Podczas przemieszczania po wdrożeniu witryny internetowej zostaną uruchomione testy obciążeniowe.

2. Po zakończeniu kompilacji przejdź do strony podsumowania.

   

   Zobaczysz, że wdrożenie i testy obciążeniowe zakończyły się pomyślnie.

3. W górnej części strony zanotuj podsumowanie.

   Zobaczysz, że artefakt kompilacji dla witryny internetowej Space Game jest publikowany tak jak zawsze. Zwróć również uwagę na sekcję Testy i pokrycie , która pokazuje, że testy obciążeniowe przeszły.

   

4. Wybierz podsumowanie testu, aby wyświetlić pełny raport.

   Raport pokazuje, że oba testy przeszły.

   

   Jeśli jakikolwiek test zakończy się niepowodzeniem, zobaczysz szczegółowe wyniki niepowodzenia. Z tych wyników można zbadać źródło błędu.

   Pamiętaj, że plik XSLT tworzy plik JUnit o nazwie JUnit.xml. Plik JUnit odpowiada na następujące dwa pytania:

   • Czy średni czas żądania jest krótszy niż jedna sekunda?
   • Czy mniej niż 10 procent żądań zajmuje więcej niż jedną sekundę do ukończenia?

   W sprawozdaniu stwierdza się, że te wymagania zostały spełnione. Aby wyświetlić więcej szczegółów, wybierz strzałkę Wynik w raporcie. Następnie upewnij się, że wybrano opcję Tylko przekazano .

   

   Zobaczysz, że średni czas odpowiedzi i maksymalne przypadki testowe czasu odpowiedzi zakończyły się powodzeniem.