Criando testes de performance e carga com o Visual Studio test (.webtest) e Fiddler

Continuando o uso do Load Test no VSTS, vamos trabalhar agora com o Visual Studio test e demonstrar como criar .webtest no Visual Studio ou na ferramenta Fiddler.

Visual Studio
Abra o Visual Studio (versão Enterprise) e crie um novo projeto Web Performance and Load Test Project.

vsts-web-perf-test-load

Em seguida, clique em Add Recording (no Visual Studio) para iniciar a gravação da sessão. No meu exemplo abaixo, fiz alguns testes de navegação no meu próprio blog, utilizando um navegador. Após terminar a navegação, volte ao VS e pare a gravação. Salve o arquivo web test gravado para executarmos no VSTS posteriormente.

vsts-web-perf-site
* mais informações sobre sobre criação e gravação de projetos de teste em: Criar projetos de testeRecording and working with web tests e Recording Web Test.


Fiddler

Faça o download do Fiddler. Após a instalação, abra a ferramenta e mantenha a opção  Capture Traffic (opção File) habilitada. A partir desta configuração, veja o rastreamento capturado de toda a navegação realizada, por exemplo em websites, utilizando o navegador.

fiddler.png* mais informações e recursos do Fiddler em: Configure Browsers for Fiddler

Ao concluir a navegação, utilize a opção File > Export Sessions > Visual Studio Web Test. O formato .webtest será gerado, permitindo trabalhar com o projeto no Visual Studio ou executar o arquivo nas opções de Load Test do VSTS (como veremos a seguir).

fiddler-webtest.png

VSTS
O VSTS possui recurso para execução do arquivo .webtest criado anteriormente. Para isso, acesse Load Test > New Visual Studio test. Escolha o arquivo gerado em seu projeto de teste e escolha OK.

vsts-web-test.png

Pronto! Confirme agora os resultados apresentados nas guias de Summary, ChartsDiagnostics e Logs.

test-result-01test-result-02test-result-03

 

 

 

DevOps, ALM e MVP no Programa Inova 360 – Record News

Programa: Inova 360
Emissora:
Record News
Apresentador: Reginaldo Pereira
Data do programa
: 26/08/2018
Participantes: Leonardo Matsumota (IT Innovation Manager) | Leonardo Stringher (System Architect) | Glauter Jannuzzi (Microsoft MVP Lead)

O vídeo do programa está disponível no Youtube e falamos um pouco mais sobre DevOps e a importância do processo de Integração Contínua em times distribuídos com o intuito de habilitar o time-to-market na empresa.

Por fim, uma abordagem sobre as soluções da Microsoft para gerenciar o ciclo de vida da aplicação e a união entre times de desenvolvimento e infraestrutura, além dos programas e contribuições em comunidades.

Executando testes com HTTP archive based test no VSTS

Em continuação aos dois últimos posts sobre Teste de Carga no VSTS: Executando Load Tests no VSTSTestes de carga com Apache JMeter test no VSTS, neste post, vamos abordar outra forma de realizar o Teste de Carga, utilizando a opção HTTP Archive based test.

Acesse o VSTS (Test > New… HTTP Archive based test) e escolha o arquivo HTTP (.har) a ser importado. Acesse Learn more e veja como criar o arquivo .har no seu navegador.

vsts-archive-based-test

Criar o arquivo HAR é bem simples e pode ser feito em diversos navegadores. Para o exemplo abaixo, utilizamos o Google Chrome:

  • Inicie o DevTools do navegador com a tecla F12
  • Na aba Network, utilize Clear para limpar históricos indesejados
  • Em seguida, inicie a gravação clicando em Record network log
  • Mantenha a opção Preserve Log selecionada
  • Faça a navegação necessária na aplicação (que você deseja verificar analisar o teste de carga)
  • Pare a gravação (clicando em Record network log novamente)
  • Com o botão direito, escolha a opção “Save as HAR with content”

chrome-network.png

Importe o arquivo .har no VSTS, conforme imagem abaixo.

vsts-http-import

Pronto! Verifique os resultados apresentados nas abas de Summary, Charts, Diagnostics Logs. Entre as principais métricas estão: tempo de resposta médio, carga de usuário, requisições por segundo e falhas de requisição.

vsts-http-results-01vsts-http-results-02vsts-http-results-03

 

 

 

Testes de carga com Apache JMeter test no VSTS

No último post introduzimos os recursos de Testes existentes no VSTS e os benefícios obtidos com eles. Continuando esta abordagem, ainda na área de Load Tests (Testes de Carga) do VSTS, o Apache JMeter test é outra opção para realizar os testes de carga, verificando as requisições, threads e performance das aplicações.

Apache JMeter pode ler e executar testes em diferentes aplicações, servidores e protocolos: Web – HTTP e HTTPS (ASP.NET, NodeJS…), SOAP / REST Webservices, FTP, TCP, LDAP, etc.

Importante lembrar que você deve criar um Plano de Teste JMeter e realizar o upload no VSTS. Este plano não pode ter listeners ativos. O VSTS suporta a versão 2.13 do Apache JMeter. Outro ponto é o suporte apenas de HTTP e 20.000 minutos de usuários virtuais gratuito.

Acesse o VSTS (Test > Load Test) e crie um novo Apache JMeter test. Escolha o arquivo .jmx criado no plano de teste e parâmetros de agente, região e duração.

vsts-apache-jmeter

Em seguida, veja os resultados dos testes realizados na aplicação. Na aba Summary, um resumo do tempo de resposta, carga de usuários, requisições, falhas de requisição e erros. Explore também as abas de Charts (gráficos), Diagnostics e Logs.

vsts-load-test

A aba de gráficos demonstra Performance, Throughput, Erros e Tests.

vsts-load-test-01

Obrigado pela visita! Em breve mais posts sobre testes no VSTS. Até lá…

 

 

Executando Load Tests no VSTS

O VSTS possui a área Test [Test Plans | Run | Load Test] que direciona os processos de qualidade ao longo do desenvolvimento do sistema. Em um único lugar, utilize os recursos para criar planos e casos de testes, teste manual e exploratório, também obter feedback de validação.

tests-vsts
Veja mais em: Exploratory & Manual Testing

A extensão paga do Test Manager possui recursos mais avançados para habilitar o gerenciamento dos testes da aplicação.

vsts-test.png

Neste post vamos trabalhar com a área de Load Test e criar um novo URL Based Test. Acesse então o VSTS e escolha New > URL Based Test. Para um simples teste de carga, mantenha o HTTP method como GET e escolha a URL do site a ser testado.

Na guia Settings, defina os parâmetros dos testes como: número de usuários, duração,  mix de browser, etc. A localização permite que o teste seja realizado na área próxima dos seus usuários.

vsts-load-test-settingsvsts-load-test-settings-01

Veja os resultados dos testes realizados. Há 4 guias (Summary | Charts | Diagnostics | Logs) e os principais indicadores são de tempo de resposta, quantidade de usuários, requisições por segundo, erros e requisições com falha. Os gráficos de performance,  throughput, erros e requisições, além de Diagnósticos e Logs também contribuem com a análise.

This slideshow requires JavaScript.

 

 

Dashboard de projetos ágeis em larga escala no VSTS

Já falamos no post anterior sobre as configurações no VSTS para gerenciar projetos ágeis em larga escala. Agora, vamos demonstrar como criar dashboards para representar os principais indicadores do Programa (PI – Program Increment) e respectivas sprints, trabalhando com múltiplos times.

O SAFe (Scaled Agile Framework) recomenda algumas métricas como:

  • Portfolio Metrics: Lean Portfolio Metrics, Portfolio Kanban Board, Epic Burn-Up Chart, Epic Progress Measure, Enterprise Balanced Scorecard e Lean Portfolio Management Self-Assessment
  • Large Solution Metrics: Solution Kanban Board, Solution Train Predictability Measure, Solution Train Performance Metrics

  • Program Metrics: Feature Progress Report, Program Kanban Board, Program Predictability Measure, Program Performance Metrics, PI Burn-Down Chart, Cumulative Flow Diagram, Agile Release Train Self-Assessment, Continuous Delivery Pipeline Efficiency, Deployments and Releases per Timebox, Recovery over Time, Innovation Accounting and Leading Indicators, Hypotheses Tested over Time, DevOps Health Radar

  • Team Metrics: Iteration Metrics, Team Kanban Board, Team PI Performance Report, SAFe Team Self-Assessment

E assim, criamos um dashboard no VSTS para representar as principais métricas:

  • Flow: número de tarefas (ou features) por status. Ajuda a visualizar a distribuição e refinamento do board. Por exemplo, se há muitas tarefas em homologação.
  • Workstream: gráfico com representatividade similar, mas separado por  workstream, assim você pode analisar a distribuição de tarefas em cada time.
  • Kanban: visão numérica da distribuição de tarefas por status (pode ser a soma de pontos das features ou horas de atividades).
  • Riscos e Blocks: ajuda o time a representar riscos ou bloqueios para o Scrum Master, RTE (Release Train Engineer), PM (Product Manager) e PO (Product Owner).
  • Burndown: progresso de cada time em relação a sprint.

dashboard-vsts-agil-escala

Vamos iniciar? Crie um novo dashboard no VSTS. O primeiro gráfico está no widget  Chart for work items. Adicione e configure conforme abaixo. O tipo do gráfico é o  stacked area e a query necessária é bem simples, também na figura abaixo.

This slideshow requires JavaScript.

O próximo gráfico de Workstream pode utilizar a mesma query. Adicione novamente o gráfico chart for work items e selecione o tipo Stacked Bar. Os critérios utilizados são: Area Path (times de projeto) e agrupando por State (estado da tarefa ou feature).

vsts-workstream

O gráfico seguinte utiliza a mesma query e widget. O tipo do gráfico agora é o Pivot Table. Configure a Area Path (em Rows) e State (em Columns).

vsts-pivot

Os indicadores de Risco e Bloqueio podem ser representados com o widget Query Tile Pro. As querys fazem referência a um custom field que criamos para sinalizar no Work Item quando há um risco ou block naquela atividade.

This slideshow requires JavaScript.

Por fim, adicionamos o widget Burndown para representar a evolução das atividades na Sprint para cada time. Como são vários times trabalhando, não conseguimos juntar em um único dashboard o Burndown nativo do VSTS (Sprint Burndown) e por isso, configuramos este para na mesma tela representar todos.

vsts-burndown

É claro que a representação pode ser única com a visão de todos os times. Neste caso optei por criar um Burndown para cada time. Outro ponto é na configuração do período. Escolhemos data (plot burndown by), pois a intenção é analisar a evolução naquela sprint.

A opção Iteration faz a comparação entre Sprints, e esta visão se projeta quando o objetivo é analisar a evolução do programa (PI – Program Increment).

 

 

Agile Software Development – comparação de ferramentas

Quando trabalhamos com desenvolvimento ágil, precisamos utilizar ferramentas que vão nos apoiar durante todo o ciclo de vida da aplicação. Fizemos uma análise das principais ferramentas de mercado para checar a aplicabilidade ao seu ambiente em função dos recursos apresentado.

agile-tools

É bem importante considerar alguns pontos ao escolher a solução para a sua empresa:

  • Conectividade: API e outras formas de conectar na plataforma são importantes, pois o ciclo de vida da aplicação é muito abrangente, e dificilmente uma única plataforma conseguirá nativamente cobrir tudo. Por exemplo, a análise de qualidade do código pode ser feita pelo SonarQube e integrada com o VSTS.
  • Customização: possibilitar a customização de Boards e habilitar times para trabalhar com Kanban, Scrum, SAFe, etc. Desta forma, você consegue criar campos ou tarefas (bugs, test case, etc.) que vão contribuir para a análise da Sprint, por exemplo a sinalização de impedimentos, ou até mesmo a criação de critérios de aceitação.
  • CI/CD: considerar o processo de Continuous Integration Continuous Deployment para garantir o apoio em versionamento do código-fonte, gestão de builds releases, qualidade do código, automação, orquestração e testes unitários .
  • Gerenciamento de times e atividades: capacity, velocidade, backlog, dashboards, iterações, tudo que precisa para ter uma boa visão da Sprint e contar com a inspeção e previsibilidade das entregas.
  • Suporte: como é o suporte e licenciamento da solução? Vale a pena verificar o  Quadrante Mágico do Gartner e também experimentar as versões Trial para utilizar as principais funcionalidades do sistema.