Exercício – Executar testes de carga no Azure Pipelines
Nesta seção, você executará o plano de teste criado no pipeline de lançamento. O plano de teste usa o Apache JMeter para executar testes de carga.
Veja como executar os testes:
- Busque e faça o check-out de um Git branch que implemente os testes.
- Modifique seu pipeline para instalar o JMeter, execute o plano de teste, transforme os resultados em JUnit e publique os resultados no Azure Pipelines.
- Envie por push seu branch para o GitHub, assista à execução de teste no Azure Pipelines e examine os resultados.
Buscar o branch do GitHub
Nesta seção, você buscará o branch jmeter do GitHub e fará check-out dele ou mudará para ele.
Esse branch contém o projeto do Space Game com o qual você trabalhou nos módulos anteriores. Ele também contém uma configuração do Azure Pipelines com a qual começar.
No Visual Studio Code, abra o terminal integrado.
Para baixar um branch chamado
jmeterno repositório da Microsoft, alterne para esse branch e execute os seguintes comandosgit fetchegit checkout:git fetch upstream jmeter git checkout -B jmeter upstream/jmeterLembre-se de que upstream se refere ao repositório GitHub da Microsoft. A configuração do Git do seu projeto compreende o repositório remoto upstream, porque você configurou essa relação quando criou o fork do projeto do repositório da Microsoft e o clonou localmente.
Em breve, você efetuará push desse branch para seu repositório do GitHub, conhecido como
origin.Opcionalmente, no Visual Studio Code, abra o arquivo azure-pipelines.yml. Examine a configuração inicial.
A configuração é semelhante àquelas que você criou nos módulos anteriores neste roteiro de aprendizagem. Ela compila apenas a configuração de Versão do aplicativo. Para resumir, ela omite os gatilhos, as aprovações manuais e os testes que você configurou nos módulos anteriores.
Observação
Uma configuração mais robusta pode especificar os branches que participam do processo de build. Por exemplo, para ajudar a verificar a qualidade do código, você pode executar testes de unidade cada vez que efetuar push de uma alteração em qualquer branch. Você também pode implantar o aplicativo em um ambiente que executa testes mais exaustivos. Porém, realize essa implantação somente quando você tiver uma solicitação de pull, uma versão Release Candidate ou quando mesclar o código com o principal.
Para obter mais informações, confira Implement a code workflow in your build pipeline by using Git and GitHub e Gatilhos de pipeline de build.
Opcionalmente, no Visual Studio Code, você pode conferir o arquivo de plano de teste do JMeter, LoadTest.jmx, e a transformação XLST, JMeter2JUnit. xsl. O arquivo XLST transforma a saída do JMeter em JUnit para que o Azure Pipelines possa visualizar os resultados.
Adicionar variáveis ao Azure Pipelines
O plano de teste original da equipe fornece um valor embutido em código para o nome do host do site do Space Game que é executado no ambiente de preparo.
Para tornar o plano de teste mais flexível, sua versão usa uma propriedade JMeter. Imagine uma propriedade como uma variável que você pode definir na linha de comando.
Veja como a variável hostname é definida no JMeter:
Veja como a variável hostname usa a função __P para ler a variável hostname.
O arquivo de plano de teste correspondente, LoadTest.jmx, especifica essa variável e a usa para definir o nome do host.
Quando você executa o JMeter na linha de comando, usa o argumento -J para definir a propriedade hostname. Veja um exemplo:
apache-jmeter-5.4.3/bin/./jmeter -n -t LoadTest.jmx -o Results.xml -Jhostname=tailspin-space-game-web-staging-1234.azurewebsites.net
Aqui, você define a variável STAGING_HOSTNAME no Azure Pipelines. Essa variável aponta para o nome de host do site que é executado no Serviço de Aplicativo em seu ambiente de preparo. Você também define a jmeterVersion para especificar a versão do JMeter a ser instalada.
Quando o agente é executado, essas variáveis são exportadas automaticamente para o agente como variáveis de ambiente, para que a configuração do pipeline possa executar o JMeter da seguinte maneira:
apache-jmeter-5.4.3/bin/./jmeter -n -t LoadTest.jmx -o Results.xml -Jhostname=$(STAGING_HOSTNAME)
Vamos adicionar as variáveis de pipeline agora antes de atualizar a configuração do pipeline. Para fazer isso:
No Azure DevOps, acesse o seu projeto Space Game – Web – Nonfunctional tests.
Em Pipelines, selecione Library.
Selecione o grupo de variáveis Release.
Em Variables, selecione + Add.
Para o nome da variável, insira STAGING_HOSTNAME. Para o valor, insira a URL da instância do Serviço de Aplicativo que corresponde ao seu ambiente de preparo, como tailspin-space-game-web-staging-1234.azurewebsites.net.
Importante
Não inclua o prefixo de protocolo
http://ouhttps://em seu valor. O JMeter fornece o protocolo quando os testes são executados.Adicione uma segunda variável chamada jmeterVersion. No campo de valor, especifique 5.4.3.
Observação
Esta é a versão do JMeter usada pela última vez para testar este módulo. Para obter a versão mais recente, confira Baixar o Apache JMeter.
Para salvar sua variável no pipeline, selecione Salvar perto da parte superior da página.
Seu grupo de variáveis é semelhante ao mostrado na seguinte imagem:
Modificar a configuração do pipeline
Nesta seção, você modificará o pipeline para executar seus testes de carga durante o estágio de preparo.
No Visual Studio Code, abra o arquivo azure-pipelines.yml. Em seguida, modifique o arquivo como a seguir:
Dica
Você pode substituir todo o arquivo ou apenas atualizar a parte que está realçada.
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.xmlAqui está um resumo das alterações:
- O trabalho
RunLoadTestsrealiza testes de carga de um agente do Linux. - O trabalho
RunLoadTestsdepende do trabalhoDeploypara garantir que os trabalhos sejam executados na ordem correta. Você precisa implantar o site no Serviço de Aplicativo para executar os testes de carga. Se você não especificar essa dependência, os trabalhos nessa fase poderão ser executados em qualquer ordem ou em paralelo. - A primeira tarefa
scriptbaixa e instala o JMeter. A variável de pipelinejmeterVersionespecifica a versão do JMeter a ser instalada. - A segunda tarefa
scriptexecuta o JMeter. O argumento-Jdefine a propriedadehostnameno JMeter lendo a variávelSTAGING_HOSTNAMEdo pipeline. - A terceira tarefa
scriptinstala o xsltproc, um processador XSLT, e transforma a saída JMeter em JUnit. - A tarefa
PublishTestResults@2publica o relatório JUnit resultante, JUnit.xml, no pipeline. O Azure Pipelines pode ajudá-lo a visualizar os resultados de teste.
- O trabalho
No terminal integrado, adicione azure-pipelines.yml ao índice, faça commit das alterações e efetue push do branch para o GitHub.
git add azure-pipelines.yml git commit -m "Run load tests with Apache JMeter" git push origin jmeter
Assista aos Azure Pipelines executarem os testes
Aqui, você observará a execução do pipeline. Você verá os testes de carga executados durante processo de preparo.
No Azure Pipelines, acesse o build e rastreie-o enquanto ele é executado.
Durante o Preparo, você verá os testes de carga serem executados depois que o site for implantado.
Após a conclusão do build, acesse a página de resumo.
Você verá que a implantação e os testes de carga foram concluídos com êxito.
Próximo à parte superior da página, observe o resumo.
Você verá que o artefato de compilação do site do Space Game é publicado como sempre. Observe também a seção Tests and coverage, que mostra que os testes de carga foram aprovados.
Selecione o resumo do teste para ver o relatório completo.
O relatório mostra que ambos os testes foram aprovados.
Se algum teste falhar, você verá resultados detalhados da falha. Com base nesses resultados, você pode investigar a origem da falha.
Lembre-se de que o arquivo XSLT produz um arquivo JUnit chamado JUnit.xml. O arquivo JUnit responde a estas duas perguntas:
- O tempo médio de solicitações é inferior a um segundo?
- Menos de 10% das solicitações levam mais de um segundo para serem concluídas?
O relatório comprova que esses requisitos são cumpridos. Para ver mais detalhes, selecione a seta Outcome no relatório. Em seguida, verifique se apenas Passed está selecionado.
Você verá que os casos de teste Average Response Time e Max Response Time foram ambos bem-sucedidos.
Observação
Você está usando o plano do Serviço de Aplicativo B1, que é executado na camada Básica. Esse plano destina-se a aplicativos que têm poucos requisitos de tráfego, como aplicativos em um ambiente de teste. Devido a esse plano, o desempenho do seu site pode ser menor que o esperado. Na prática, você escolheria um plano para o ambiente de preparo que correspondesse mais de perto ao seu ambiente de produção. Por exemplo, os planos Standard e Premium são voltados para cargas de trabalho de produção. Eles são executados em instâncias de máquina virtual dedicadas.