Ć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:

Pobierz i wyewidencjonuj gałąź git, która implementuje testy.
Zmodyfikuj potok, aby zainstalować narzędzie JMeter, uruchomić plan testu, przekształcić wyniki w narzędzie JUnit i opublikować wyniki w usłudze Azure Pipelines.
Wypchnij gałąź do usługi GitHub, obejrzyj testy uruchamiane w usłudze Azure Pipelines, a następnie sprawdź wyniki.

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ąć.

W programie Visual Studio Code otwórz zintegrowany terminal.
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.
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.
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:

Screenshot of setting the hostname variable in Apache JMeter.

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

Screenshot for reading the hostname variable in Apache JMeter.

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ć:

W usłudze Azure DevOps przejdź do projektu Space Game — web — testy niefunkcjonalne .
W obszarze Potoki wybierz pozycję Biblioteka.
Wybierz grupę Zmiennych wydania .
W obszarze Zmienne wybierz pozycję + Dodaj.
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.
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.
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.

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.

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.

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.
Po zakończeniu kompilacji przejdź do strony podsumowania.

Zobaczysz, że wdrożenie i testy obciążeniowe zakończyły się pomyślnie.
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.
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.

Uwaga

Używasz planu usługi App Service B1, który działa w warstwie Podstawowa. Ten plan jest przeznaczony dla aplikacji, które mają wymagania dotyczące niskiego ruchu, takie jak aplikacje w środowisku testowym. Ze względu na ten plan wydajność witryny internetowej może być mniejsza niż oczekiwano. W praktyce należy wybrać plan środowiska przejściowego, który ściślej pasuje do środowiska produkcyjnego. Na przykład plany w warstwie Standardowa i Premium są przeznaczone dla obciążeń produkcyjnych. Są one uruchamiane w dedykowanych wystąpieniach maszyn wirtualnych.

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

Pobieranie gałęzi z repozytorium GitHub

Dodawanie zmiennych do usługi Azure Pipelines

Modyfikowanie konfiguracji potoku

Obejrzyj, jak usługa Azure Pipelines uruchamia testy

Opinia