Automação de testes de desempenho para sistemas web utilizando a ferramenta jmeter

ESCOLA SUPERIOR DE CRICIÚMA – ESUCRI
CURSO DE SISTEMAS DE INFORMAÇÃO
LEANDRO ANTUNES UGIONI
RAMON DE PIERI SARAIVA
AUTOMAÇÃO DE TESTES DE DESEMPENHO PARA SISTEMAS WEB UTILIZANDO A FERRAMENTA JMETER
Criciúma (SC), Outubro/2014

Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação da Escola Superior de Criciúma, ESUCRI.
Orientador: Prof. Cristiano Damiani Tomasi
Criciúma (SC), Outubro/2014

Trabalho de Conclusão de Curso aprovado pela Banca Examinadora para obtenção do título de Bacharel em Sistemas de Informação da Escola Superior de Criciúma, ESUCRI.
Criciúma, 29 de Outubro de 2014.
BANCA EXAMINADORA:
_____________________________________
Prof. Cristiano Damiani Tomasi – Orientador
______________________________________
Prof. Gustavo Bisognin
______________________________________
Prof. Cristiano Ávila Salomão

AGRADECIMENTOS
Eu, Leandro Ugioni, agradeço primeiramente a Deus por me dar forças durante toda essa caminhada, agradeço aos meus pais e meus irmãos que sempre estiveram me apoiando, agradeço também ao meu amigo e colega Ramon Saraiva pelo companheirismo e força de vontade durante todo o trabalho, agradeço aos professores Cristiano Damiani Tomasi e Muriel de Fátima Bernhardt pelo acompanhamento e auxilio na realização desse trabalho, por fim a gradeço a todos os meus colegas de trabalho, colegas de curso e demais professores que colaboraram direta ou indiretamente para a realização e conclusão desse trabalho.
Eu, Ramon Saraiva, agradeço a Deus pelas oportunidades que me levaram por esse caminho, agradeço à minha mãe, pai, irmão e esposa que tiveram meu tempo compartilhado junto a esse trabalho realizado, também quero agradecer meu amigo e colega de trabalho Leandro Ugioni, que sempre foi dedicado e focado no seu objetivo durante todas as etapas do trabalho, meu muito obrigado a todos.

SUMÁRIO
LISTA DE FIGURAS ................................................................................................... 6
LISTA DE QUADROS ................................................................................................. 7
ABREVIATURAS ......................................................................................................... 8
RESUMO..................................................................................................................... 9
1 INTRODUÇÃO ...................................................................................................... 10
1.1 JUSTIFICATIVA ................................................................................................ 11
1.2 OBJETIVOS ...................................................................................................... 11
1.2.1 OBJETIVO GERAL ......................................................................................... 11
1.2.2 OBJETIVOS ESPECÍFICOS ........................................................................... 11
1.3 ORGANIZAÇÃO ............................................................................................... 12
2 QUALIDADE E TESTES DE SOFTWARE ............................................................ 13
2.1 QUALIDADE ..................................................................................................... 13
2.1.1 PADRONIZANDO ATIVIDADES ..................................................................... 14
2.1.2 O CICLO PDCA (PLAN, DO, CHECK, ACT) E MELHORIA CONTINUA ........ 16
2.2 QUALIDADE DE SOFTWARE .......................................................................... 17
2.2.1 IMPORTÂNCIA DA QUALIDADE DE SOFTWARE NAS EMPRESAS ........... 18
2.2.2 CONTROLE DE QUALIDADE E MELHORIA NO PROCESSO ...................... 19
2.3 TESTES DE SOFTWARE ................................................................................. 19
2.3.1 DIMENSÕES DE TESTE ................................................................................ 20
2.3.1.1 PRIMEIRA DIMENSÃO: ESTADO DO TESTE ("O MOMENTO") .............. 21
2.3.1.2 SEGUNDA DIMENSÃO: TÉCNICA DO TESTE ("COMO VOU TESTAR") 22
2.3.1.3 TERCEIRA DIMENSÃO: METAS DO TESTE ("O QUE TENHO DE TESTAR") .................................................................................................................. 22
2.3.1.4 QUARTA DIMENSÃO: ONDE SERÁ O TESTE ("O AMBIENTE DO TESTE") 24
2.3.2 MÉTRICAS DE TESTES ................................................................................ 24
2.3.2.1 MÉTRICAS DE "AUSÊNCIA DE EFICIÊNCIA" .......................................... 25
2.3.2.2 MÉTRICAS DE EVOLUÇÃO DO SOFTWARE ........................................... 26
2.3.2.3 MÉTRICAS DE AUTOMAÇÃO DE TESTE................................................. 26
2.4 RESUMO DO CAPÍTULO ................................................................................. 28
3 AUTOMAÇÃO DE TESTES DE DESEMPENHO .................................................. 29
3.1 AUTOMAÇÃO DE TESTES .............................................................................. 29
3.1.1 TIPOS DE AUTOMAÇÃO DE TESTES .......................................................... 30
3.1.2 FERRAMENTAS DE TESTES ........................................................................ 30
3.2 TESTES DE DESEMPENHO............................................................................ 31
4 DESEMPENHO DE SISTEMAS WEB .................................................................. 35
4.1 CONCEITOS BASE EM WEB........................................................................... 35
4.1.1 SERVIDOR DE APLICAÇÃO .......................................................................... 35
4.1.2 SERVIDOR WEB ............................................................................................ 35
4.1.3 ENDEREÇO IP (INTERNET PROTOCOL) ..................................................... 36
4.1.4 HTTP .............................................................................................................. 36
4.1.5 COOKIE .......................................................................................................... 37
4.1.6 PROXY ........................................................................................................... 37
4.2 DESEMPENHO DE SISTEMAS WEB .............................................................. 38
5 ESTUDO DAS FERRAMENTAS DE TESTES ...................................................... 41
5.1 FERRAMENTA LOADRUNNER ....................................................................... 41

5.1.1 CARACTERÍSTICAS ...................................................................................... 41
5.2 FERRAMENTA BLAZEMETER ........................................................................ 42
5.3 FERRAMENTA NEOLOAD ............................................................................... 44
5.4 FERRAMENTA LOADSTORM .......................................................................... 46
5.5 FERRAMENTA LOADUI ................................................................................... 47
5.6 FERRAMENTA JMETER .................................................................................. 49
5.7 COMPARATIVO ENTRE FERRAMENTAS ...................................................... 51
6 ESTUDO DE CASO .............................................................................................. 53
6.1 CONTEXTUALIZAÇÃO DO PROBLEMA ......................................................... 53
6.2 TIPOS DE TESTES EXECUTADOS ................................................................. 56
6.2.1 TESTES DE TEMPO DE RESPOSTA ............................................................ 56
6.2.2 TESTES DE THROUGHPUT .......................................................................... 57
6.3 CRIAÇÃO DOS TESTES .................................................................................. 57
6.4 EXECUÇÃO E AVALIAÇÃO DOS RESULTADOS ........................................... 66
7 CONSIDERAÇÕES FINAIS .................................................................................. 71
7.1 CONCLUSÕES ................................................................................................. 71
7.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS ..................................... 72
REFERÊNCIAS ......................................................................................................... 73

LISTA DE FIGURAS
Figura 1 - Exemplo geral de uma estrutura de aplicação web .................................. 36
Figura 2 - Exemplo de proxy ..................................................................................... 38
Figura 3 - Exemplo de pessoas comprando em uma loja real .................................. 39
Figura 4 - Exemplo de gráfico de tempo médio de resposta da transação ............... 42
Figura 5 - Exemplo do console da ferramenta no navegador .................................... 44
Figura 6 - Exemplo de tela onde são criados os cenários ......................................... 46
Figura 7 – Exemplo da tela do gráfico de distribuição do tempo de resposta ........... 47
Figura 8 - Exemplo da tela de monitoramento da base de dados ............................. 48
Figura 9 - Exemplo de tela de criação de cenários de teste ...................................... 50
Figura 10 - Comparativo entre ferramentas - Preço/Licença ..................................... 51
Figura 11 - Comparativo entre ferramentas - Plataforma/Gravação de Scripts ......... 51
Figura 12 – Comparativo entre ferramentas - Capacidade de Usuários ................... 51
Figura 13 - Tela de consulta ao acervo ..................................................................... 54
Figura 14 - Tela de consulta de notas parciais .......................................................... 55
Figura 15 - Tela de criação de aulas ......................................................................... 56
Figura 16 - Tela inicial da ferramenta JMeter ............................................................ 58
Figura 17 - Componente Servidor HTTP Proxy ......................................................... 59
Figura 18 - Componente Grupo de Usuários ............................................................ 59
Figura 19 - Exemplo do componente de requisições ................................................ 60
Figura 20 - Parametrizando 50 usuários virtuais ....................................................... 61
Figura 21 - Requisições do teste TempRes01 .......................................................... 62
Figura 22 - Componente de Gráfico Agregado.......................................................... 63
Figura 25 - Grupos de usuários com propriedade agendador ................................... 65
Figura 26 - Exemplo de relatório agregado ............................................................... 66
Figura 27 - Resultado do teste TempRes01 .............................................................. 67

LISTA DE QUADROS
Quadro 1 - Métricas da automação de testes............................................................ 27
Quadro 2 - Resultado do teste Vaz01 ....................................................................... 68

ABREVIATURAS
ADSL - Asymmetric Digital Subscriber Line
API – Application Programming Interface
ASF - Apache Software Foundation
EDD - Eficácia de Detecção de Defeitos
ESUCRI – Escola Superior de Criciúma
EUA - Estados Unidos da América
Fa - Número de funções ou módulos que foram adicionados na versão anterior
Fc - Número de funções ou módulos que sofreram alterações na versão anterior
Fd - Número de funções ou módulos removidos na versão anterior
HP - Hewlett-Packard
HTML - Hypertext Markup Language
HTTP - Hypertext Transfer Protocol
IEEE - Institute of Electric and Electronic Engineers
IP - Internet Protocol ISO - International Organization for Standardization
MA - Massachusetts
Mt - Número de funções ou módulos da versão atual
NM - Novo México
PDCA – Plan, Do, Check, Act
SaaS - Software as a Service
SMI - Maturity Metric
TDC - Defeitos encontrados pelo cliente
TDD - Defeitos encontrados pelo teste
TPS - Transações por segundo

RESUMO
O presente trabalho apresenta conceitos teóricos utilizados pela engenharia de software voltados a área da qualidade de software demonstrando desde conceitos de qualidade até quais pontos devem ser levados em consideração para mensurar- se há qualidade em um software. Foram demonstrados conceitos da aplicação e importância da qualidade nas empresas e padrões de qualidade, bem como uma abordagem abrangente na área de testes de software bem como suas técnicas e etapas de execução, aprofundando-se na automação de testes de desempenho, demonstrando um estudo nos testes de desempenho de sistemas web e das ferramentas que podem ser utilizadas para esse tipo de testes. Também foi apresentado um estudo de caso onde foram realizados testes de desempenho em uma aplicação web utilizando a ferramenta JMeter, sendo que foram realizados testes de tempo de resposta e vazão, demonstrando os resultados através de gráficos e relatórios fornecidos pela ferramenta.
Palavras-chave: Qualidade de software; Testes de software; Automação de testes.

10
1 INTRODUÇÃO
Nas empresas desenvolvedoras de software de pequeno e médio porte a área de testes de software é um setor em constante crescimento, porém ainda são facilmente encontrados softwares de baixa e média qualidade, sendo que isso ocorre devido a prazos curtos e pouco investimento no setor de qualidade.
Os profissionais da área de qualidade não são tão valorizados como um desenvolvedor ou um analista de requisitos, isso ocorre, pois é um reflexo da importância que as organizações estão dando a esse setor, no entanto isso vem mudando gradativamente.
Com a popularização dos softwares, devido a um ambiente altamente concorrido e desregulamentado como a internet, o acesso à informação por parte de todos em qualquer lugar do mundo, faz com que as empresas desenvolvedoras de softwares necessitem de diferenciais em seus produtos. Surge então nesse contexto, a necessidade de introduzir a qualidade de software como processo fundamental nos processos de Engenharia de Software.
Na era atual, cada vez mais os usuários de softwares possuem e adquirem maior conhecimento sobre o assunto, aumentando o seu intelectual crítico, com isso possuem o total discernimento para julgar os atributos de um software ou serviço que utilizam.
Atualmente com as novas tecnologias e hábitos existentes, é cada vez maior o sentimento de que o tempo ficou curto e que os fatos ocorrem em uma velocidade impressionante, fato esse que aliado ao crescente conhecimento dos clientes sobre os softwares e serviços que utilizam se faz necessário por parte das empresas o direcionamento de maiores esforços para garantir o desempenho das aplicações.
Empresas portadoras de serviços ou produtos web dirigiram seus olhares ao desempenho de suas aplicações, pois sabem que em um ambiente de negócio concorrido e crítico como a internet é inaceitável que o usuário invista seu precioso tempo aguardando uma fila de processamento ou necessite voltar em outro período menos movimentado. Empresas como essas investem boa parte do custo total do projeto na qualidade de performance de suas aplicações.
O trabalho apresentado demonstrará algumas das principais soluções comerciais e gratuitas em testes de performance no ambiente web. No decorrer do trabalho o leitor será apresentado há alguns conceitos de qualidade e em qual nível

11
o teste de performance ocorre na engenharia de software. Ao final será apresentado de forma prática em um ambiente real o uso e os resultados da ferramenta de testes de performance Jmeter.
1.1 JUSTIFICATIVA
Devido ao enorme crescimento no setor de desenvolvimento de sistemas web e comércio eletrônico que seguem projetos curtos, possuindo cronogramas limitados e que possuem como um de seus principais objetivos a qualidade e a satisfação do usuário, além disso, deve-se considerar nesse cenário, a ocorrência de altíssima carga de dados e o número ilimitado de usuários, exigindo que os sistemas sejam rápidos, estáveis e seguros.
No que diz respeito à qualidade, é essencial considerar o contexto de testes de software, onde testes de desempenho são criados e executados de maneira complexa e criteriosa e quando executados manualmente, podem ocasionar falhas e mascarar os resultados de maneira negativa, podendo comprometer todo o projeto.
Com a utilização de um procedimento que automatize os testes, pretende-se fornecer uma solução que garanta o nível de qualidade e desempenho de maneira padronizada e que esses testes possam ser reutilizados e evoluídos, gerando gráficos dos resultados de maneira simplificada facilitando o entendimento do atual desempenho da aplicação considerando importantes indicadores do mercado de software atual.
A implementação dessa solução permitiria o desenvolvimento de testes automatizados impactando positivamente na conclusão e evolução dos projetos.
1.2 OBJETIVOS
1.2.1 OBJETIVO GERAL
Realizar um estudo na área de testes de desempenho de sistemas web, aplicando os conceitos na utilização da ferramenta JMeter.
1.2.2 OBJETIVOS ESPECÍFICOS
Os objetivos específicos definidos para esse trabalho são:
 Estudar a área de testes de software;
 Estudar os conceitos e técnicas de testes de desempenho;

12
 Analisar fatores relevantes ao desempenho de um sistema web;
 Avaliar as características funcionais da ferramenta Jmeter;
 Utilizar a ferramenta para aplicar testes de desempenho em uma aplicação web;
 Demonstrar os resultados obtidos nos testes realizados.
1.3 ORGANIZAÇÃO
Este trabalho está organizado da seguinte forma:
O capítulo 2 apresenta as definições iniciais de qualidade e qualidade de software, focando também nos conceitos de testes de software e suas dimensões.
O capítulo 3 conceitua a automação de testes e as ferramentas de automação, abrangendo de forma detalhada os testes de desempenho.
No capítulo 4 são apresentados os conceitos básicos utilizados na arquitetura de sistemas web e o conceito de desempenho de sistemas web.
O capítulo 5 apresenta uma análise de determinadas ferramentas de testes de performance e detalha suas características e funcionalidades.
O capítulo 6 demonstra a aplicação prática da ferramenta na execução dos testes e a análise dos resultados obtidos.
Finalmente o capítulo 7 apresenta as considerações finais, com as conclusões e as recomendações para trabalhos futuros.

13
2 QUALIDADE E TESTES DE SOFTWARE
Este capítulo apresenta uma visão sobre conceitos de qualidade, qualidade de software e testes de software baseando-se nos modelos e padrões de desenvolvimento adotados atualmente.
2.1 QUALIDADE
O conceito de qualidade é conhecido e utilizado desde a época em que o homem começou a se organizar para produzir e comercializar seus produtos, baseando-se na avaliação dos mesmos e tratando a qualidade de forma subjetiva, considerando-se que vários fatores influenciam na real qualidade do produto, inclusive a pessoa a qual avalia a qualidade. Considerando esses fatores, a qualidade deve ser medida baseando-se na utilização de atributos para que se possa estabelecer uma avaliação justa para produtos produzidos em série sendo eles físicos ou abstratos, como é o caso do software, devendo ser destacados fatores que demonstrem visibilidade ao produto (CÔRTES; CHIOSSI, 2001).
Considerando alguns aspectos isolados no que diz respeito à qualidade, define-se que qualidade pode ser algo abstrato, variando conforme a necessidade atual. Pode ser sinônimo de perfeição, referindo-se à ausência total de falhas ou erros; pode ser considerada imutável para determinado produto, variando a avaliação de pessoa para pessoa, ou mesmo definindo como se deu a conclusão de um projeto conforme a ideia original (PALADINI, 2004).
Reforçando os conceitos de qualidade, pode-se destacar a adequação do produto ao cliente ou organização, atendendo aos padrões pré-estabelecidos garantindo segurança e confiabilidade, e no caso de softwares, gerando informações claras e precisas na sua utilização, sendo produzido com o melhor aproveitamento de tempo e recursos para sua produção e garantindo a satisfação do cliente e longevidade do produto perante a concorrência (REZENDE, 2005).
Em relação à postura das organizações Sommerville (2003, p. 458) afirma que:
Atingir um alto nível de qualidade de produto ou serviço é o objetivo da maioria das organizações. Atualmente, não é mais aceitável entregar produtos com baixa qualidade e reparar os problemas e as deficiências depois que os produtos foram entregues ao cliente.

14
2.1.1 PADRONIZANDO ATIVIDADES
Por não haver controle sem padronização, pode-se dizer que uma empresa que não padroniza suas atividades não tem como garantir a qualidade (VIEIRA FILHO, 2010).
Para Sommerville (2003, p. 459), “A ISO1 9001 é um modelo genérico de processo de qualidade que descreve vários aspectos do processo e define quais padrões e procedimentos devem existir dentro de uma organização”.
Entre as atividades realizadas para garantir a qualidade, uma das mais importantes é a padronização. Para que uma empresa tire a certificação ISO 9001 (International Organization for Standardization) não se pode descartar a elaboração de padrões e capacitação de pessoal (VIEIRA FILHO, 2010).
Desta forma demonstra-se um exemplo de fácil entendimento: ao adquirir-se pão numa mesma padaria em horários diferentes, o pão pode ser do mesmo tipo, mas pode ser muito diferente do pão comprado anteriormente em outro horário, isso ocorre pois, por não haver padrão na padaria para fabricação de pão, cada padeiro faz o pão da maneira que conhece ou da maneira que julgar melhor (VIEIRA FILHO, 2010).
A padronização é para dar garantia que todos saibam o que fazer e como fazer durante todo o processo, criando um processo por escrito mostrando de forma clara os passos a serem executados (GUELBERT, 2012).
A criação de padronização é necessária sempre que uma atividade executada for crítica para a qualidade. Após ser identificada a atividade, é criado um procedimento padrão de forma escrita ou em formato de fluxograma de processo. Outro ponto importante é a auditoria periódica dos procedimentos executados para ter certeza que a atividade será sempre executada conforme planejada (GUELBERT, 2012).
Segundo Vieira Filho (2010, p. 35-36), uma definição para padronização é: "Unificação de comportamentos de indivíduos seguindo um modelo definido por um grupo". Uma padronização deve possuir as seguintes características básicas (VIEIRA FILHO, 2010):
 Focalizar o usuário - O padrão deve respeitar sempre as pessoas que irão utiliza- lo; 1 International Organization for Standardization

15
 Simplicidade - Deve ser simples e possuir linguagem clara;
 Mapear a atividade atual - O padrão é criado em cima da atividade executada atualmente;
 Manutenção fácil - Já que a melhoria é contínua os padrões sempre precisam de ajustes, por isso os padrões devem ser de fácil revisão;
 Deve ser viável sua aplicação - Não podem existir dificuldades em seguir os padrões na rotina diária de trabalho;
 Participação dos usuários - As pessoas que irão utilizar o padrão para executar as tarefas são as que possuem maior conhecimento na tarefa executada, tornando sua participação na elaboração do padrão algo imprescindível.
Ao padronizar suas tarefas a empresa é recompensada com inúmeros benefícios, conhecidos como: "Benefícios da padronização", citam-se alguns como (VIEIRA FILHO, 2010):
 Melhor utilização de recursos - Se quantidade e qualidade forem especificadas no padrão, os recursos serão mais bem utilizados, isso também inclui mão de obra;
 Padronização do trabalho realizado - As tarefas executadas serão sempre da mesma forma;
 Registro de conhecimento - Ao perder uma pessoa experiente na empresa, o conhecimento daquela pessoa não se perde junto, pois possuindo um padrão a empresa estará adquirindo e registrando os conhecimentos;
 Facilitador de treinamento - Os padrões podem ser utilizados como norte a ser seguido para treinamento de novos especialistas;
 Maior nível técnico - As pessoas que utilizarão os padrões ganharão desempenho e conhecimento;
 Ganho de tempo - Não existirá mais a necessidade de improvisar, visto que os padrões devem ser elaborados detalhadamente. Sendo assim as situações específicas serão tratadas pelos padrões fazendo com que a produtividade aumente.
O controle da atividade passa por uma padronização e é acompanhado por um treinamento. No entanto, esses procedimentos e padrões não são eternos, eles são adaptados e moldados naturalmente com a validação realizada pelo pessoal mais experiente (TEBOUL, 1991).

16
2.1.2 O CICLO PDCA (PLAN, DO, CHECK, ACT) E MELHORIA CONTINUA
Idealizado por Shewhart, mas difundido por Willian Edwards Deming, o ciclo PDCA teve início após a segunda guerra. Esse ciclo tem como princípio deixar os processos envolvidos em uma gestão mais claros. Esse clico é dividido em quatro principais passos: Plan, Do, Check e Act (DAYCHOUM, 2013).
O PDCA é simples, porém possui muitos níveis de entendimento que levam uma vida para entender completamente. Deming apresentou o PDCA aos japoneses durante suas palestras no ano de 1954 na Associação Japonesa de Cientistas e Engenheiros. Deming manteve os créditos ao seu mentor Walter Shewhart, que foi quem realizou uma pesquisa inicial sobre projeto, produção e vendas, servindo de base para o PDCA (DENNIS, 2008).
Trata-se de um processo gerencial usado para tomar decisões que possam garantir as metas da empresa, sendo muito usado para realizar melhoria continua (VIEIRA FILHO, 2010).
Ainda segundo Vieira Filho (2010), o PDCA é divido em quatro etapas:
 P: to plan (Planejar). São definidas as metas que a empresa deseja atingir. Essas metas devem ser definidas com precisão absoluta devendo-se considerar a micro e macro economia, clientes, mercado, produto e muitos outros indicadores da empresa. A pessoa responsável pela definição das metas deve ter ótimo conhecimento da empresa como um todo. Após a definição da meta, devem ser criados os procedimentos que serão usados para que as metas sejam atingidas.
Daychoum (2013) cita que nesse item deve-se estabelecer a missão, visão, objetivos, procedimentos e processos para atingir os resultados;
 D: to do (Executar). Etapa onde os colaboradores envolvidos são treinados para executar os procedimentos criados com base nas metas estabelecidas. Nesta fase são executadas atividades e realizadas coletas de informações;
 C: to check (Verificar). Etapa gerencial, onde as informações coletadas a partir dos procedimentos executados na etapa anterior são confrontadas com as informações da etapa de planejamento;
 A: to act (Atuar). Nessa etapa os erros cometidos nos procedimentos são corrigidos. Faz-se necessário pois, caso os procedimentos realizados não estejam de acordo com o planejado, um plano de ação a ser aplicado com objetivo de atingir a meta estabelecida.
No momento em que as metas são atingidas pode-se dar início à melhoria

17
contínua. Nesta etapa, volta-se a planejar e elaborar novas metas, novos planejamentos e procedimentos (VIEIRA FILHO, 2010).
Segundo Daychoum (2013) o PDCA é aplicado nas normas de gestão e deve ser usado por toda organização com o intuito de garantir o sucesso nos negócios independentemente do departamento da organização. Nesse ciclo é realizado primeiramente o planejamento, no passo seguinte as ações planejadas são executadas e no final é verificado se o que foi feito ficou de acordo com o planejado e repetidamente esse clico deve ser seguido com o objetivo de reduzir os defeitos nos produtos ou no processo.
2.2 QUALIDADE DE SOFTWARE
Pressman (2002, p. 193) diz que para seu objetivo deve-se definir a qualidade de software como “Conformidade com requisitos funcionais e de desempenho explicitamente documentados e características implícitas, que são esperadas em todo software desenvolvido profissionalmente”.
Para Bastos et al (2012, p. 73), no que se refere à qualidade de maneira funcional, “Um sistema de software é considerado portador de boa qualidade quando atinge níveis adequados de confiabilidade na realização de suas funcionalidades”.
Conforme Côrtes e Chiossi (2001), a qualidade de software deve ser uma iniciativa a nível corporativo para que os devidos efeitos sejam notados no produto, pois muitas vezes grandes softwares são desenvolvidos gerando expectativas ao cliente e o nível de qualidade não é atingido devido a esforços insuficientes por parte de uma equipe, pois não ocorrem mudanças na cultura da empresa.
Côrtes e Chiossi (2001, p. 29) ainda afirmam que “É possível construir software com alta qualidade, no prazo e a baixo custo, mas não da forma caótica como é frequentemente feito hoje”.
A definição de qualidade de software pode ser usada para enfatizar três pontos (PRESSMAN, 2002):
 Requisitos de software são a base inicial onde a qualidade de software é medida, ou seja, divergências do software com o requisito é falta de qualidade;
 O processo de desenvolvimento da produção do software deve seguir padrões especificados. Caso esses padrões não sejam seguidos é quase que certo que a qualidade não será atingida;
 Um grupo de requisitos que não são demonstrados de forma objetiva e clara, os

18
chamados "requisitos implícitos" podem passar despercebidos. Um bom exemplo é a manutenibilidade do código, se esse índice não for bom, a qualidade do software é suspeita.
2.2.1 IMPORTÂNCIA DA QUALIDADE DE SOFTWARE NAS EMPRESAS
Pressman (2002, p. 187) fala sobre o assunto da seguinte forma:
Você pode fazer direito ou fazer novamente. Se uma equipe de software enfatiza a qualidade em todas as atividades de engenharia de software, reduz a quantidade de trabalho que tem que refazer. Isso resulta em menores custos e, mais importante, melhor prazo para colocação no mercado.
Alguns consultores acham que os investimentos em qualidade de software são apenas para reduzir custos, outros gestores acham que se faz necessário para que as necessidades e expectativas da aplicação ocorram como desejado. Todos eles estão certos, mas pode-se completar a resposta citando que ao investir em qualidade está se investindo em prevenção de defeitos, com isso pode-se garantir que aquilo que foi desejado está sendo entregue de acordo com as especificações e necessidades. Como consequência, evidenciam-se diversos pontos positivos, como por exemplo: satisfação do usuário, imagem positiva da empresa, confiança no produto e redução de custos (MOLINARI, 2010).
O maior desejo das empresas que produzem software é ter menos custos e tempo para desenvolver os sistemas, com isso muitas empresas deixam de lado os processos de engenharia de software pensando em economia de tempo e redução de custos. Engholm Jr (2010) afirma que a idéia abordada por essas empresas é falsa, pois a não utilização de processos de qualidade acaba por gerar softwares de má qualidade, que não agradam os usuários e geram custos da manutenção no software, fazendo com que o custo economizado antes seja gasto em manutenção das correções, prejudicando assim a imagem do produto e da empresa.
Para Myers (2004) quanto antes forem encontrados os erros em um software, menor será o custo de correção e maior será a probabilidade de que o programador realize a tarefa corretamente. Considerando também que se os erros são todos encontrados em uma etapa avançada do projeto, os programadores passam por uma mudança psicológica e tendem a cometer novos erros ao efetuar as correções.
Um software pode ser desenvolvido usando ou não uma metodologia de desenvolvimento. Alguns dos problemas em criar softwares sem uma metodologia

19
são as consequências geradas pós conclusão do projeto. Esses resultados são negativos e podem passar despercebidos por toda a equipe de desenvolvimento por anos. Uma metodologia de desenvolvimento de software permite que as atividades sejam bem definidas, garantindo o controle e apoio às decisões (LOBO, 2008).
2.2.2 CONTROLE DE QUALIDADE E MELHORIA NO PROCESSO
Bastos et al (2012, p. 71) conceituam que “O controle de qualidade é um processo pelo qual a qualidade do produto é comparada com os padrões aplicáveis; quando uma não conformidade é detectada, são tomadas as devidas providencias”.
Para Côrtes e Chiossi (2001), quando se controla a qualidade no processo de desenvolvimento de um software o custo do mesmo pode ser estimado mais precisamente, pois pode-se obter informações detalhadas sobre os níveis alcançados, sendo que esse controle pode ser usado tanto para produto quanto para processo, ou seja, deve-se avaliar e controlar a qualidade nas diversas atividades que compõem o desenvolvimento de um software.
Côrtes e Chiossi (2001), ainda afirmam que manter a melhoria nos processos de produtos de software aumenta a produtividade e facilita a manutenção do projeto, sempre focando as atividades que são mais propensas a problemas e que possuem um nível maior de complexidade, para que estas atividades sejam rigorosamente acompanhadas desde o início do desenvolvimento.
2.3 TESTES DE SOFTWARE
Sabendo-se da complexidade que envolve a criação de um software devido a sua gama de características e dimensões, seu desenvolvimento está sujeito a problemas que interferem negativamente no resultado final, sendo que a maioria destes problemas decorre de erro humano. Para evitar esse tipo de problemas utilizam-se procedimentos de testes de software para realizar a descoberta de erros bem como as devidas validações no software a ser entregue (DELAMARO; MALDONADO; JINO, 2007).
Para Bastos et al (2012, p. 17), “O objetivo de um processo de teste, com metodologia própria, é minimizar os riscos causados por defeitos provenientes do processo de desenvolvimento”.
No processo de testes de software conforme Delamaro, Maldonado e Jino (2007), utilizam-se de alguns termos para evidenciar os problemas encontrados

20
durante o processo de desenvolvimento do software, são eles: defeito, engano, erro e falha.
Conceitua-se defeito em testes de software como sendo uma execução do processo de forma incorreta na utilização de um software. Esses defeitos são causados por uma ação humana incorreta chamada de engano, tendo em vista esses conceitos a ocorrência dos mesmos podem levar a um erro, ou seja, a execução do programa em um estado inesperado ou inconsistente. Na presença de erros o software responde de forma incompatível com o resultado esperado gerando o que se chama de falha (DELAMARO; MALDONADO; JINO, 2007).
Segundo Bastos et al (2012), os projetos de testes devem acompanhar de forma paralela o desenvolvimento do software visando a redução dos custos na correção de defeitos ainda em fase inicial. Assim, caso não seja possível submeter o software a testes completos deve-se priorizar as funcionalidades mais importantes baseando-se nos riscos para o negócio. Isso se torna possível utilizando-se de técnicas escolhidas conforme a situação, sempre visando reduzir tempo, manutenção e custos do projeto.
Molinari (2003) ainda reforça que, para certos tipos de testes, deve-se optar pela realização de testes manuais, ou seja, realizados por um profissional da área de testes. São casos onde os testes envolvem o help do sistema, testes de usabilidade, múltiplas configurações e compatibilidade, e ainda testes de tratamento de erros, devido ao fato de estes tipos de testes dependerem em grande parte de intervenção humana para sua execução. Já para outros tipos de testes, como testes de regressão, carga de dados, performance e testes aleatórios, pode-se optar pela execução de testes automatizados.
2.3.1 DIMENSÕES DE TESTE
Conforme Molinari (2003), planejar o teste é fundamental. Um bug no software muitas vezes não significa que o erro é da aplicação, mas sim do processo de teste realizado. Pode-se dizer que o ideal é que sempre que possível, deve-se encontrar algum bug durante o teste.
Todo teste deve possuir o planejamento no qual é gerado um plano de testes, a elaboração de casos de testes (que nada mais é do que o processo de elencar as possíveis situações de testes), a execução e a análise dos resultados dos testes. Quando um teste é realizado e não se encontra nenhum bug deve-se tomar

21
cuidado, pois o teste pode estar viciado (MOLINARI, 2003).
Existem muitos tipos de teste, para cada tipo de teste pode-se dizer que trata-se de uma dimensão diferente com propriedades próprias, na prática pode-se utilizar mais de um tipo de teste (MOLINARI, 2003).
Existem muitos tipos de teste, esse cenário na maioria das vezes causa confusão para que os tipos de testes sejam categorizados, alguns autores preferem escrever um a um em forma de tópicos, outros criam algumas categorias de acordo com seu entendimento. Molinari (2003) usa o conceito de dimensão de testes onde cita que para cada tipo de teste pode-se dizer que se trata de uma dimensão diferente com propriedades próprias, na prática pode-se utilizar mais de um tipo de teste.
2.3.1.1 PRIMEIRA DIMENSÃO: ESTADO DO TESTE ("O MOMENTO")
Essa dimensão é composta por três tipos bases (MOLINARI, 2003):
 Teste de Unidade;
 Teste de Integração;
 Teste de Sistema.
Segundo o mesmo autor, um quarto tipo pode aparecer em algumas bibliografias, no entanto é um tipo de teste contraditório:
 Teste de aceitação: define a aceitação do usuário, ou seja, se o sistema está fazendo o que deveria.
Os testes de unidade, conhecidos como testes unitários, são executados por profissionais da área de testes, mas muitas vezes também são executados por programadores visto que esses testes visam garantir o funcionamento do programa, validando sua estrutura interna e aspectos de implementação. Para esse tipo de testes podem ser utilizadas ferramentas de automação específicas para cada linguagem (BASTOS et al, 2012; DELAMARO; MALDONADO; JINO, 2007).
Os testes de integração, normalmente executados posteriormente aos testes unitários, devem garantir a integração entre componentes ou módulos do sistema de modo que os mesmos estejam sendo usados de maneira coerente e possam ser integrados aos demais componentes ou módulos para possibilitar a execução das funcionalidades (BASTOS et al, 2012; DELAMARO; MALDONADO; JINO, 2007).
Os testes de sistema são os testes que exploram o sistema de forma a validar se todos os requisitos que foram especificados estão implementados de

22
forma correta. Nessa etapa algumas equipes de testes além de testar os requisitos funcionais também testam os requisitos não funcionais (BASTOS et al, 2012; DELAMARO; MALDONADO; JINO, 2007).
Para Bastos et al (2012), os testes de aceitação são realizados por usuários, os quais validam se o que foi especificado está implementado de forma correta no produto a ser entregue.
2.3.1.2 SEGUNDA DIMENSÃO: TÉCNICA DO TESTE ("COMO VOU TESTAR")
Esses tipos de testes são apresentados por muitos autores de forma não agrupada, mas se for colocada sobre o ponto de visto do "como", pode-se chegar à conclusão que elas têm muito em comum (MOLINARI, 2003):
 Teste Operacional;
 Teste Negativo-Positivo;
 Teste de Regressão;
 Teste de Caixa-Preta;
 Teste de Caixa-Branca;
 Teste Beta;
 Teste de Verificação de Versão.
Bastos et al (2012) conceituam que os testes de caixa-branca são testes que visam validar a estrutura interna do programa, ou seja, seu código fonte. Já os testes de caixa-preta visam validar os requisitos implementados e suas especificações sem levar em conta a estrutura do software.
Os testes de regressão são executados durante todo ciclo de vida do software, servindo para certificar que as modificações efetuadas funcionem corretamente e que os requisitos já implementados continuem funcionando após alguma modificação ou criação de funcionalidades novas. Como são testes longos e exaustivos, sugere-se a utilização da automação de testes visando diminuir o esforço empregado e maximizar os resultados (BASTOS et al, 2012; DELAMARO; MALDONADO; JINO, 2007).
2.3.1.3 TERCEIRA DIMENSÃO: METAS DO TESTE ("O QUE TENHO DE TESTAR")
Considera-se como a mais forte dimensão entre as três, sendo mais conhecida como "tipo de testes" (MOLINARI, 2003).

23
 Teste Funcional;
 Teste de Interface;
 Teste de Aceitação do Usuário;
 Teste de Estresse;
 Teste de Volume;
 Teste de Configuração;
 Teste de Instalação;
 Teste de Documentação;
 Teste de Integridade;
 Teste de Segurança;
 Teste de Performance e Teste de Carga.
As principais metas de teste serão detalhadas a seguir para maior entendimento dessa dimensão.
O teste funcional visa validar se as funcionalidades estão de acordo com o que foi especificado para o software (BASTOS et al, 2012).
O teste de interface avalia as características da interface do software e valida se tudo está de acordo com o especificado permitindo integração entre usuário e sistema (BASTOS et al, 2012).
O teste de aceitação do usuário possui forte relação com o cliente e serve para validar a qualidade externa do software e qualidade em uso do software, normalmente é executado próximo à conclusão do projeto podendo ser realizado no cliente ou no ambiente de desenvolvimento (LOURENÇO, 2010).
O teste de estresse leva o software a condições extremas de uso e situações anormais visando planejar manutenções futuras e planos de contingência para eventuais problemas (BASTOS et al, 2012).
O teste de configuração assegura que o software irá ser executado corretamente em diversos cenários de configuração de hardware e/ou software tentando abranger uma gama maior de usuários (BASTOS et al, 2012).
O teste de instalação valida à execução do instalador de um software em diferentes ambientes de hardware e software, bem como situações críticas no decorrer da instalação (COSTA, 2013).
O teste de integridade visa à validação da robustez do software, verificando se o mesmo possui falhas que comprometam os dados do usuário (COSTA, 2013).
O teste de segurança deve garantir que determinadas informações só

24
podem ser acessadas por atores específicos com permissões definidas previamente (BASTOS et al, 2012).
Os testes de performance e carga trabalham com cargas de dados em determinados perfis visando validar o comportamento e reposta do sistema em diversas situações a fim de encontrar pontos a serem otimizados (BASTOS et al, 2012). Esses testes são o tema desse trabalho e serão mais detalhados no decorrer do próximo capítulo.
2.3.1.4 QUARTA DIMENSÃO: ONDE SERÁ O TESTE ("O AMBIENTE DO TESTE")
De acordo com Molinari (2003) essa dimensão tem sua origem na experiência e no avanço tecnológico. Não se pode aplicar os itens das dimensões anteriores nessa dimensão sem ter uma estratégia, isso impactaria no valor final do projeto devido a um teste mal planejado.
 Teste de Aplicações Mainframe;
 Teste de Aplicações Client;
 Teste de Aplicações Server;
 Teste de Aplicações Network;
 Teste de Aplicações Web.
Para Bastos et al (2012), a fase que antecede a execução dos testes é a preparação do ambiente de testes, que não trata apenas de configurações de hardware ou software, mas sim de toda a estrutura preparada para se realizar os testes incluindo massa de dados, configuração de ferramentas e modelos de dados.
2.3.2 MÉTRICAS DE TESTES
Qual o motivo de medir o teste e a automação de teste? Existem vários, citam-se dois: retorno de investimento e qualidade do produto final (MOLINARI, 2003).
Silveira (2013) julga métricas como "As métricas são um bom meio para entender, monitorar, controlar, prever e testar o desenvolvimento de software e os projetos de manutenção”.
Independentemente da medição, reduz-se o custo de possíveis problemas, também pode-se diminuir o número de bugs encontrados, melhorando a aplicação e confiança do cliente que comprou a aplicação e de quem vai utilizá-la (MOLINARI,

25
2003).
Os seguintes atributos compõem as métricas de testes de software: ausência de eficiência, evolução do software e automação de teste. Esses atributos são detalhados na sequência.
2.3.2.1 MÉTRICAS DE "AUSÊNCIA DE EFICIÊNCIA"
Usadas para análise de defeitos encontrados no processo. Existem grandes variações, mas todas são pequenos detalhes, como percentual de defeitos em períodos de proporções diferentes. Seguem as métricas apresentadas por Molinari (2003):
 Percentual de defeitos encontrados: É o resultado da operação (total de defeitos nos testes/total de defeitos conhecidos). Onde o "total de defeitos conhecidos" é o que foi encontrado até o momento, não considerando aqui a resolução deles, ou seja, os solucionados os não solucionados e os novos entram no cálculo. Isso permite saber se a qualidade do software está aumentando ou diminuindo. Nos casos em que isso ocorre possui-se o chamado "software imprevisível";
 Percentual de defeitos resolvidos: Resultado da operação (total de defeitos encontrados antes da nova versão do software / total de defeitos encontrados). Parecido com o anterior, no entanto mostra se o processo de depuração (não faz parte da atividade de teste) do software está melhorando ou não;
 Métrica de conferência e análise de teste: Nas situações que são encontrados poucos ou nenhum defeito. É realizada uma métrica subjetiva usando-se o resultado de defeitos em relação à eficiência do teste numa escala de 2 a 10, nesse caso usa-se a opinião de cinco pessoas de cada área envolvida sendo que a média é realizada por área;
 Métricas de código: Voltada para o processo de desenvolvimento onde a quantidade de defeitos encontrada é baixa. É divida em dois grupos: (1) subjetivas, nesta métrica é realizada a seguinte pergunta: "O código foi testado todo ou não?"; e (2) objetivas ou de coberturas, representam o percentual do que foi testado: (o que foi testado / tudo que deveria ser testado). Por exemplo: 20 linhas de códigos foram testadas em um total de 100 linhas;
 EDD (Eficácia de Detecção de Defeitos): Demonstra a eficácia do produto em relação aos testes realizados. Varia de empresa para empresa, logo não basta conhecer apenas o resultado, deve-se conhecer também o processo definido pela

26
empresa. Essa métrica é obtida usando a seguinte fórmula: EDD = TDD/(TDD+TDC) * 100. Onde TDD = Defeitos encontrados pelo teste. TDC = Defeitos encontrados pelo cliente (AGAPITO apud CAMPOS, 2010);
 Gestão de Incidências: Demonstra um grau de resolução dos defeitos encontrados. Um valor baixo significa um alto nível de defeitos não resolvidos, ou seja, software com problemas (SILVEIRA, 2013).
2.3.2.2 MÉTRICAS DE EVOLUÇÃO DO SOFTWARE
Para Molinari (2003) algumas das métricas existentes para evolução de software são:
 Métricas de requerimentos de teste: Usado no planejamento e acompanhamento dos testes em um nível de gerência, é semelhante à métrica de cobertura citada, a diferença é que é voltada a área de testes. Por exemplo: dos 40 casos de testes foram testados 20 casos de testes;
 Métrica de estimativa de clico de teste: Usado para demonstrar o tempo de teste na execução de uma tarefa. O cálculo é realizado usando as seguintes informações: Total de defeitos esperados, média de defeitos encontrados / total de defeitos esperados e tempo de teste acumulado;
 Volume de erros por etapa: Quando se chega a um ponto que fica difícil ou impossível encontrar erros no software testado, pode-se dizer que esse fator indica a qualidade do software. Esse critério pode ser utilizado para ter uma visão da qualidade do software como um todo. Supõe-se que quanto mais se corrige os erros melhor será a qualidade do software (SILVEIRA, 2013);
 IEEE (Institute of Electric and Electronic Engineers) Maturity Metric: SMI = (Mt - (Fa + Fc + Fd) / Mt), onde Mt = número de funções ou módulos da versão atual, Fc = número de funções ou módulos que sofreram alterações na versão anterior, Fa = número de funções ou módulos que foram adicionados na versão anterior e Fd = número de funções ou módulos removidos na versão anterior;
 Outras: Existem diversas outras métricas, por exemplo, Benchmark de Performance que mede o tempo de resposta de software.
2.3.2.3 MÉTRICAS DE AUTOMAÇÃO DE TESTE
Na automação de testes existem as seguintes métricas (MOLINARI, 2003):
 Manutenibilidade: devido à mudança do software essa métrica é aplicada para

27
saber se a manutenção do teste é viável;
 Eficácia: aplicado para saber se vale a pena automatizar levando em consideração o custo e número de vezes que o teste será utilizado. Em situações que o teste será realizado apenas uma vez, é mais barato usar o teste manual do que investir tempo automatizando;
 Confiabilidade: mede os falsos positivos da ferramenta, deve-se descobrir se o erro encontrado é da ferramenta de teste ou da aplicação;
 Flexibilidade: corresponde a cada alteração ou preparação do teste executado e às vezes mudança do ambiente de teste de forma radical. Esse índice é fundamental para saber se vale a pena o tempo investido em ir de um conjunto de testes para outro e o da manutenção dos scripts;
 Usabilidade: índice usado para saber se uma função do script de teste é funcional em uma nova situação. Também pode ser usado para medir o tempo de resposta do resultado de teste para a nova funcionalidade;
 Robusteza: usado para saber quantos testes serão ignorados devido a um defeito novo encontrado no software. Também é considerado o tempo gasto para investigar as causas de eventos inesperados;
 Portabilidade: tempo gasto para a preparação do teste em uma nova configuração de ambiente.
Referente às métricas de automação de testes, existem três situações que podem ocorrer em termos de organização das métricas. Dependendo da situação esses atributos são classificados como fortes ou fracos, conforme demonstrado no Quadro 1:
Quadro 1 - Métricas da automação de testes Situação Atributo Atributo Forte Atributo Fraco
Situação 1
Portabilidade
X
Manutenibilidade
X
Flexibilidade
X
Confiabilidade
X
Robusteza
X
Usabilidade
X
Situação 2
Portabilidade
X
Manutenibilidade
X
Flexibilidade
X

28
Confiabilidade
X
Robusteza
X
Usabilidade
X
Situação 3
Portabilidade
X
Manutenibilidade
X
Flexibilidade
X
Confiabilidade
X
Robusteza
X
Usabilidade
X
Fonte: Adaptado de MOLINARI (2003, p. 63).
2.4 RESUMO DO CAPÍTULO
Nesse capítulo inicialmente foram abordados conceitos de qualidade demonstrando sua importância para a comercialização de produtos visando à satisfação dos clientes, logo após foi abordada a padronização das atividades, o que contribui para se elevar os níveis da qualidade em qualquer área de atuação, também foi abordado o ciclo PDCA desde sua criação até sua utilização.
Foram abordados conceitos de qualidade de software e da importância da qualidade de software para as organizações, demonstrando que a qualidade de software está voltada a atender os requisitos do projeto da forma mais correta possível trazendo benefícios tanto ao usuário quanto a empresa.
Finalizando o capítulo foi abordado o teste de software, onde o software é executado de diversas formas em busca de erros, para isso demonstram-se também as técnicas utilizadas para a execução dos testes bem como as métricas utilizadas para mensurar e monitorar a execução dos testes.
O estudo desses conceitos na área de qualidade bem como um estudo detalhado nos conceitos de testes de software e seu ciclo de vida, servem como base para que no próximo capítulo sejam abordados os tópicos de automação dos testes e os testes de desempenho de maneira detalhada.

29
3 AUTOMAÇÃO DE TESTES DE DESEMPENHO
Este capítulo apresenta uma visão sobre conceitos de automação de testes, ferramentas de automação, testes de desempenho e sua importância no atual cenário de desenvolvimento de software.
3.1 AUTOMAÇÃO DE TESTES
Segundo Bernardo e Kon (2008), os testes automatizados são de certa forma programas que realizam os testes de maneira automática e efetuam as devidas validações. Sendo assim, todos os testes escritos podem ser reutilizadas rapidamente quantas vezes for necessário, podendo dessa forma reproduzir passos importantes do teste que poderiam ser ignorados devido a falha humana.
Em relação aos custos de implementar a automação e mantê-la, inicialmente necessita-se de um investimento que envolve treinamentos, ferramentas e tempo para que a automação comece a ser implementada. Porém, com o passar do tempo e a medida que os testes são organizados e escritos, o custo de executá-los se torna baixo pois testes que antes levavam dias para serem executados manualmente passam a levar horas e apresentam resultados muitos mais precisos (COLLINS, 2013).
Para Collins (2013), o momento certo para se iniciar a automação de testes em um projeto ocorre no momento em que a ideia está sincronizada com todos os membros envolvidos e comprometidos sendo que todos devem estar alinhados com o cronograma do projeto e as futuras manutenções dos scripts de testes criados e os devidos cuidados com o ambiente onde os testes são executados.
A automação dos testes deve focar inicialmente em áreas críticas do sistema criando testes que auxiliem a realizar a regressão e validação de novas instalações. Também deve-se levar em consideração rotinas críticas que possuem alto valor para o negócio e projetar testes mais detalhados para as mesmas, sendo assim, não se deve tentar automatizar tudo, pois isso inviabilizaria o projeto de automação acabando por gerar altos custos (CAETANO, [2014]b).
Bird (2013), ressalta que os testes após serem escritos podem ser utilizados como documentação do sistema entre os testadores se os mesmos forem de grande abrangência no sistema, mantidos atualizados e escritos de forma clara e objetiva. Desta forma, se os testes estiverem no nível correto de abstração, os mesmos são

30
considerados uma forma de documentação de todo seu funcionamento, porém isso não é uma regra e, para alguns casos, os testes são apenas scripts que pouco falam sobre o funcionamento do sistema.
Caetano ([2014]b) afirma que apesar da automação de testes, os testes manuais são insubstituíveis, pois a automação deve atuar como uma técnica adicional que visa elevar os níveis de qualidade e agregar valor ao produto, fazendo com que atividades repetitivas sejam automatizadas permitindo ao testador dedicar mais tempo a outros tipos de testes manuais.
3.1.1 TIPOS DE AUTOMAÇÃO DE TESTES
Segundo Caetano ([2014]c), os testes automatizados passam por quatro níveis de maturidade, iniciando-se pelo estágio da automação acidental onde a inciativa é individual, porém sem uma devida organização, sendo que nesse estágio não existem ferramentas ou padrões definidos. Após esse estágio inicia-se a automação proposital, onde a alta gerência já começa a perceber a possibilidade de maior cobertura; nesse estágio normalmente inicia-se um projeto piloto. Quando tudo corre bem nos primeiros estágios, inicia-se a automação formal, onde a automação de testes é tratada como um projeto e é utilizada em todos os níveis de testes. Após esse estágio se mantém o estágio de automação formal em otimização, são mantidos os projetos de automação e aplicados a eles metodologias para revisão e evoluções.
Os testes automatizados funcionais possuem alguns tipos, citados na sequência (CAETANO, [2014]a):
 Gravação/Execução (Capture/Playback);
 Dirigido a dados (Data-Driven);
 Dirigido à palavra-chave (Keyword-Driven);
 Baseado na linha de comando (Command Line Interface);
 Baseado em API (Application Programming Interface);
 Test Harness.
3.1.2 FERRAMENTAS DE TESTES
Delamaro, Maldonado e Jino (2007), afirmam que a aplicação de diversos tipos de testes está diretamente vinculada à utilização de ferramentas de automação, considerando que com o uso das mesmas o processo de testes se torna

31
mais ágil e menos propenso a erros propiciando também maior qualidade nos testes e produtividade se comparados com os testes manuais.
Para Bastos et al (2012), a escolha da ferramenta pode interferir diretamente na eficácia dos testes devido a grande quantidade de ferramentas, sendo que as mesmas possuem características específicas e diversas formas de utilização, ou seja, cada uma pode alcançar um objetivo em específico nos testes.
Deve-se levar em consideração que as ferramentas nada mais são que softwares que testam outros softwares. Desta forma, as ferramentas também possuem suas limitações e erros, sendo que por várias vezes essas limitações podem atrasar o projeto de automação e até mesmo inviabilizá-lo (CAETANO, [2014]b).
3.2 TESTES DE DESEMPENHO
Para Campos ([2011]), o teste de desempenho ou performance pode ser resumido em uma única frase:
Teste de Performance é normalmente executado para ajudar a identificar gargalos sistema, estabelecer uma baseline para futuras análises/testes, apoio no esforço de performance tuning, determinar a conformidade com requisitos e metas de performance, e/ou coleta de outros dados relacionados ao desempenho para assim ajudar os stakeholders a tomar decisões relacionados com a qualidade total da aplicação que está sendo testada. Além disso, os resultados do Teste de Performance e análises podem ajudar você a estimar a configuração do hardware necessária para suportar a aplicação quando você liberar para o uso em produção.
Conforme Molinari (2009), para definir os testes de desempenho ou performance, deve-se elencar quatro conceitos principais:
 Vazão ou throughput;
 Tempo de resposta;
 Carga de trabalho ou capacidade de usuários simultâneos;
 Gargalo.
O teste de desempenho ou performance é usado para saber o tempo de resposta de um sistema levando em consideração uma carga definida. Também é usado para identificar possíveis gargalos de um sistema (CAMPOS, [2011]).
Seguindo a idéia de Molinari (2009) outras informações de performance e gráficos de análise giram em torno dos conceitos citados acima.
Pode-se entender por vazão (throughput) a capacidade de um fluxo de algo, por um tempo determinado. Imagine-se, por exemplo, um cano onde passa água. A

32
vazão desse cano seria: vazão = quantidade de água que passa pelo cano / tempo medido. Levando esse conceito para sistemas web, a vazão do sistema seria: throughput = quantidade de requisições que passam pelo sistema / tempo medido (MOLINARI, 2009).
Esse termo é definido por Fowler et al (2003, p. 29) como:
O throughput é a quantidade de coisas que você pode fazer em uma dada quantidade de tempo. Se você estiver contabilizando o tempo gasto na cópia de um arquivo, o throughput poderia ser medido em bytes por segundo. Para aplicações corporativas, uma medida típica é o número de transações por segundo (tps), mas o problema é que isso depende da complexidade da sua transação. Para seu sistema específico, você deve escolher um conjunto usual de transações.
Levando o termo throughput para o cenário de testes de software, o assim chamado teste de throughput é usado para medir o throughput de uma infraestrutura de uma aplicação web, nesse caso o throughput é considerado a métrica de bytes enviados num período determinado de tempo. Alguns exemplos dessa medida são: kilobits por segundo, consultas em banco de dados por minuto, transação por hora ou qualquer outra informação vinculada ao tempo (CAMPOS, [2011]).
O tempo de resposta pode ser compreendido como o tempo total de uma operação após ser solicitada. Por exemplo, após abrir uma bica de água, pode-se considerar como tempo de resposta o tempo que a água leva para percorrer o cano e sair pela bica. Levando o conceito para á área de sistemas web, esse tempo pode ser considerado, como exemplo, o tempo que uma página demora a ser demonstrada por completa, após o usuário clicar em um link (MOLINARI, 2009).
Fowler et al (2013) citam tempo de resposta como sendo uma quantidade de tempo que o sistema usa para processar uma solicitação.
Molinari (2009, p. 58) descreve a situação de forma mais simplificada:
Uma coisa é testar a performance e estressar a aplicação, e outra é saber se o tempo de resposta está adequado. O usuário não quer saber sobre a estrutura e por onde passa o request da aplicação, o que ele precisa é de algo bem simples: - está rápido?
Levando o quesito tempo de resposta para área de testes de software, Campos ([2011]) fala de teste de tempo de resposta como sendo a percepção que o usuário tem sobre a velocidade de resposta do sistema após fazer uma requisição. Essa percepção pode ser rápida ou lenta, tudo irá depender da atividade que deve ser executada. No entanto, a aceitação desse tempo é algo variável de usuário para usuário e está relacionada à psicologia humana. Mesmo assim, existem algumas

33
normas:
 Sistemas multimídia - O tempo de resposta deve ser 0.1 segundos ou menos;
 Sistemas online com tarefas inter-relacionadas - O tempo de resposta deve ser até 0.5 segundos;
 Sistemas online multitarefa - O tempo de resposta deve ser até 1 segundo.
Para definir o conceito de carga de trabalho pode-se considerar no exemplo da tubulação de água, como sendo equivalente "a quantidade de água que o cano é submetido" (MOLINARI, 2009, p. 52).
Fowler et al (2013, p. 29) fazem uma comparação de carga com tempo de resposta:
A carga é uma medida da pressão a que o sistema está submetido, que poderia ser medida pelo número de usuário a ele conectados em um determinado instante de tempo. A carga é geralmente um contexto para alguma outra medida, como um tempo de resposta. Assim, você pode dizer que o tempo de resposta para alguma solicitação é de 0,5 segundo com 10 usuários e de 2 segundos com 20 usuários.
O conceito de carga levado para à área de testes de software é conhecido como teste de capacidade, o qual mede a capacidade total do sistema e demonstra o ponto máximo do tempo de resposta e throughput. Nesse contexto é realizado um teste usando carga de dados normal para que seja possível definir a capacidade extrema que o sistema suporta. No teste onde é usada uma sobrecarga (teste de estresse) o sistema é testado com uma carga até que falhe (CAMPOS, [2011]).
No exemplo da tubulação de água, Molinari (2009) exemplifica o conceito de gargalo como sendo "onde o conjunto de canos 'trava' ou tem baixo desempenho. Um cano entupido representa um 'engarrafamento aquático', ou melhor, um gargalo".
Campos ([2011]) diz que no cenário de testes de software, esses gargalos podem existir nos seguintes lugares:
 Aplicação - Os codificadores podem usar ferramentas para buscar códigos lentos;
 Banco de dados - DBAs podem usar otimização de buscas;
 Sistema Operacional - Analistas de sistemas usam ferramentas que monitoram o uso do hardware;
 Rede - Administradores de redes usam ferramentas para monitorar e analisar o tráfego na rede.

34
Nesse capítulo inicialmente foram abordados os conceitos de automação de testes demonstrando uma etapa de testes de alto nível e maior precisão e reutilização, onde os testes são desenvolvidos e executados de forma automática quantas vezes for necessário para que se atinja o resultado esperado.
Também foi apresentada a seção das ferramentas da automação que são os softwares onde são criados e executados os testes automatizados sendo elas de grande importância para um projeto de automação, contextualizando também os tipos de automação de testes que podem ser adotados dentro de um projeto.
Foi abordado o conceito de testes de desempenho demonstrando de forma detalhada como o mesmo é executado e quais os fatores devem ser medidos e levados em consideração nesse tipo de testes para que se possam mensurar os níveis adequados de qualidade.
A partir desse embasamento teórico, no próximo capítulo pode-se realizar um estudo aprofundado na arquitetura do ambiente de um sistema web e seus protocolos de navegação.

35
4 DESEMPENHO DE SISTEMAS WEB
Este capítulo apresenta uma visão sobre os conceitos que envolvem o funcionamento de um sistema web, bem como conceitos que influenciam direta ou indiretamente no desempenho do sistema e fatores que podem influenciar no desempenho.
4.1 CONCEITOS BASE EM WEB
Compreender os itens e termos seguintes é essencial para iniciar os testes de performance em sistemas web (MOLINARI, 2009).
4.1.1 SERVIDOR DE APLICAÇÃO
Considera-se um servidor de aplicação um software que agrupa funções de negócio e de serviços que se integram para satisfazer as necessidades do usuário, sendo que consideram-se como importantes os serviços de monitoramento de transações e gerenciamento de fila de requisições (MARTINS, 2009).
Conhecido como software middleware, o servidor de aplicação é um programa que permite disponibilizar um ambiente de instalação e execução de aplicativos, tendo como objetivo disponibilizar algumas funcionalidades que só poderão ser executadas em conjunto com um sistema operacional (MOLINARI, 2009).
4.1.2 SERVIDOR WEB
Define-se como servidor web, um software que tem como responsabilidade exibir o conteúdo HTML requisitado pelo browser, ou seja, o servidor web está em execução no lado do servidor e o browser do lado cliente. O protocolo usado por esses servidores é o HTTP (Hypertext Transfer Protocol) e são os principais distribuidores de conteúdo na internet, um exemplo de servidor web é o software Apache (LUIZ, 2014).
Pode-se visualizar a estrutura de uma aplicação web conforme demonstrado na Figura 1:

36
Figura 1 - Exemplo geral de uma estrutura de aplicação web
Fonte: Adaptado de MOLINARI (2009, p. 42).
4.1.3 ENDEREÇO IP (INTERNET PROTOCOL)
O IP é um protocolo de comunicação que tem como função enviar e receber os pacotes de comunicação de uma rede de computadores (PISA, 2012).
O IP é um número de identificação único usado por um dispositivo (computador, celular, tablet, entre outros) conectado a uma rede de computadores. O formato desse número é uma sequência de 32 bits na forma binária (MARTINEZ, 2014).
4.1.4 HTTP
Para entender melhor o HTTP divide-se o termo em dois. HTTP request e HTTP response. A função do HTTP é a transferência de dados via rede de computadores, seja interna (intranet) ou externa (internet). Essa função é realizada da seguinte forma: a estação cliente faz um HTTP request (conhecido como requisição), a estação servidor recebe a requisição e realiza um HTTP response (conhecido como resposta), essa resposta é recebida (em situações normais) apenas pela estação cliente (MOLINARI, 2009).
O protocolo HTTP vem sendo usado em aplicações web desde 1990, sendo que o mesmo é um protocolo de aplicação que pode suportar a execução de softwares distribuídos cooperativos de hipermídia (ZOTTO, 2009).

37
4.1.5 COOKIE
Para Molinari (2009, p. 44) entende-se como cookie “[...] um grupo de dados trocados entre o navegador e o servidor de páginas, colocado num arquivo de texto criado no computador do utilizador”.
O cookie é utilizado para manter informações de uma sessão criada em HTTP, por exemplo, quando um usuário faz uma autenticação em um site e salva sua senha (MOLINARI, 2009).
Os cookies gravam informações localmente na máquina do usuário em uma pasta temporária para a posterior consulta dos dados gravados, em alguns casos são usados para guardar informações de login e senha, porem não são muito seguros e confiáveis para esse proposito (MORAES; MORAES, 2009).
Para que o cookie funcione o servidor envia no protocolo HTTP uma linha de comando com o conteúdo do cookie. Do lado cliente esse cookie fica guardado nos arquivos temporários por um tempo determinado, toda vez que o cliente fizer comunicação com o mesmo servidor, o conteúdo desse cookie é enviado junto ao HTTP request (MOLINARI, 2009).
4.1.6 PROXY
O proxy é um termo utilizado para definir serviços que funcionam como intermediários entre estações cliente e servidor, ou seja, quando é realizada uma requisição de uma estação cliente para uma estação servidor, nos casos onde existe o servidor proxy, esse atende a requisição da estação cliente e repassa para a estação servidor (OLIVEIRA, 2013).
Pode-se visualizar um exemplo de proxy conforme demonstrado na Figura 2:

38
Figura 2 - Exemplo de proxy
Fonte: MOLINARI (2009, p. 47).
4.2 DESEMPENHO DE SISTEMAS WEB
Com o grande fluxo de informações em sistemas web e o crescente número de usuários surgem os chamados engarrafamentos digitais, onde são lançadas milhões de requisições as aplicações web a cada segundo que se passa, com isso surge a exigência de velocidade de resposta fazendo com que as empresas passem a competir cada vez mais, pois o software que é mais rápido é mais utilizado (RAMOS, 2014).
Pensando em uma loja de vendas real, vários clientes após terem decidido o produto que irão adquirir, pegam uma fila para realizar o pagamento, nessa fila eles ficam até serem atendidos por um caixa livre. Nesse exemplo o desempenho está diretamente ligado a eficiência do caixa e a quantidade de caixas disponíveis para realizar o atendimento (MOLINARI, 2009).
Pode-se visualizar um exemplo onde simula-se pessoas em uma loja real, conforme demonstrado na Figura 3:

39
Figura 3 - Exemplo de pessoas comprando em uma loja real
Fonte: MOLINARI (2009, p. 29).
Na Figura 3 existem cinco caixas ocupados atendendo um cliente cada, não existe ninguém na fila, cinco clientes estão escolhendo seus produtos e um cliente está pedindo informação sobre os produtos para depois escolher (MOLINARI, 2009).
Por outro lado, a situação demonstrada em uma loja virtual (sistema web) ficaria com o seguinte contexto: cinco clientes usando o navegador escolhendo os produtos em um site, um cliente usando o recurso de busca do site, cinco clientes finalizando a compra e pagando os produtos na sessão de pagamentos do site (MOLINARI, 2009).
Concluindo, uma loja virtual deve ter as mesmas divisões que uma loja real, torna-se semelhante também em situações reais, quando a loja real está atendendo muitos clientes ela deve estar preparada para esta situação. O mesmo ocorre em uma loja virtual, quando isso ocorre o sistema web deve estar preparado para suportar essa quantidade de acessos (MOLINARI, 2009).
A média de acessos deve ser mapeada e usada para avaliação de desempenho, pois como existem momentos de alta e outros de baixa existirão de tempos em tempos "gargalos". Molinari (2009, p. 31) faz uma advertência breve e realista: “Um consumidor não gosta de esperar, e a espera pode significar a perda de um cliente. A maioria dos clientes insatisfeitos não reclama, simplesmente vai

40
embora e procura outro local que o atenda”.
Nesse capítulo foram abordados os conceitos de desempenho de sistemas web, demonstrando conceitos básicos no ambiente de sistemas web, como internet, browser, os servidores que comportam as aplicações e os protocolos de navegação, sendo que com base nesses conceitos pode-se mensurar o desempenho de um sistema web.
Foi abordada também a importância do desempenho de um sistema web que já se enquadra como um fator importante de mercado, onde sistemas mais rápidos atraem mais usuários e como o fator de desempenho pode ser comparado com situações cotidianas onde o usuário preza pela qualidade e velocidade, demonstrando exemplos de uma loja física e um sistema web de vendas.
Com base nos conceitos apresentados nos capítulos anteriores, no próximo capítulo podem-se demonstrar ferramentas de automação de testes de desempenho explorando suas características e objetivos específicos, realizando um estudo detalhado na ferramenta Jmeter que será aplicada nesse trabalho.

41
5 ESTUDO DAS FERRAMENTAS DE TESTES
Este capítulo apresenta uma visão sobre as principais características funcionais das ferramentas de automação de testes de desempenho e um breve comparativo entre essas ferramentas.
5.1 FERRAMENTA LOADRUNNER
Trata-se de uma ferramenta de automação de testes desenvolvida pela HP (Hewlett-Packard), que possui como foco os testes de carga e a criação de scripts de forma facilitada e interativo com o usuário (HP, 2014).
A empresa Hewlett-Packard, possui sua sede em Palo Alto e está envolvida nas áreas de computação, impressão, manipulação de imagens, vendas de software e serviços para área de tecnologia, sendo que a mesma abrange também suítes de automação para controle de qualidade de software (CANAL TECH, 2014).
5.1.1 CARACTERÍSTICAS
Como características da ferramenta pode-se citar a ampla compatibilidade com as linguagens de desenvolvimento web e a possiblidade de execução de testes em aplicativos mobile baseados em navegadores bem como a integração com o ambiente de desenvolvimento (HP, 2014).
Para a geração de scripts de testes o sistema utiliza a tecnologia TruClient que auxilia a criação dos testes de forma interativa, e para demonstrar os resultados dos testes a ferramenta apresenta uma diversidade de relatórios e a análise de desempenho que tenta encontrar e demonstrar em tempo real a causa de alguma perda de desempenho (HP, 2014).
Um dos pontos fortes da ferramenta é a opção de ser adquirida em formato de software como serviço sob demanda, onde a ferramenta é executada de forma online ficando independente de instalações locais, fato esse que se torna um facilitador pra grandes e extensos projetos (HP, 2014).
Dentre os pontos fracos da ferramenta cita-se o fato de que o LoadRunner não é um software fácil de aprender, o uso requer planejamento e recursos qualificados (ITCENTRALSTATION, 2014a).
Ficha técnica das principais características da ferramenta (HP, 2014):
 Ferramenta paga;

42
 Possibilidade de testes em aplicativos mobile;
 Opção do formato de software como serviço sob demanda;
 Interatividade e facilidade na criação de scripts;
 Grande abrangência de linguagens de desenvolvimento web.
Pode-se visualizar um exemplo da tela que demonstra o gráfico de tempo médio de resposta da transação, conforme demonstrado na Figura 4:
Figura 4 - Exemplo de gráfico de tempo médio de resposta da transação
Fonte: Adaptado de HP (2014).
5.2 FERRAMENTA BLAZEMETER
BlazeMeter é uma ferramenta de automação de testes de desempenho totalmente online que se destaca por possuir compatibilidade total com a ferramenta Jmeter, possibilitando o reaproveitamento de scripts e facilidade na migração de uma ferramenta para outra ou até mesmo a utilização das duas em conjunto (BLAZEMETER, 2014a).
Criada pela empresa com o mesmo nome, BlazeMeter é uma startup com um crescimento promissor criado pela próxima geração, usando tecnologia nas nuvens, desenvolve soluções para testes de performance em todo o mundo e sua sede é localizada em São Francisco – Califórnia (BLAZEMETER, 2014d).
A ferramenta além de permitir a execução dos testes em sistemas web

43
também possibilita a execução dos testes em aplicativos mobile diretamente em aparelhos físicos, realizando a execução diretamente no Android dentre outros sistemas mobile, podendo inclusive simular o tráfego de redes móveis, fato esse que torna o teste muito mais preciso e realista, pois não depende apenas de ambientes simulados (BLAZEMETER, 2014b).
Uma das características fortes da ferramenta é a tecnologia FollowMe, onde os testes são gravados a partir das ações realizadas pelo usuário em determinado sistema, a ferramenta conta também com agendamento para a execução dos testes que podem ter a duração máxima de setenta e duas horas e comportar de cinquenta a um milhão de usuários virtuais em um único teste (BLAZEMETER, 2014c).
Para demonstrar os resultados dos testes à ferramenta conta com gráficos simplificados, existindo a possibilidade da criação de gráficos personalizados pelo usuário, permitindo a comparação entre testes já executados e a exportação desses resultados para posterior análise (BLAZEMETER, 2014c).
Um dos pontos desfavoráveis da ferramenta é a forma de cobrança ser efetuada por teste realizado e não por tempo, ou seja, um teste de dez minutos terá o mesmo valor de um teste de uma hora (HYNES, 2013).
Ficha técnica das principais características da ferramenta (BLAZEMETER, 2014c):
 Ferramenta paga com desconto em pacotes anuais;
 Possibilidade de testes em aplicativos mobile diretamente em aparelho físico;
 Tecnologia FollowMe de gravação de testes;
 Suporte de até um milhão de usuários virtuais.
Pode-se visualizar um exemplo do console da ferramenta no navegador, onde podem ser realizadas algumas configurações e a gravação dos testes, conforme demonstrado na Figura 5:

44
Figura 5 - Exemplo do console da ferramenta no navegador
Fonte: Adaptado de BLAZEMETER (2014c).
5.3 FERRAMENTA NEOLOAD
Um produto da empresa Neotys que desenvolve ferramentas para melhorar o desempenho de sistemas de informação. A principal ferramenta da companhia é o NeoLoad que testa o desempenho de sistemas web. A empresa foi fundada em 2005 por um grupo de desenvolvedores que reconheceram uma demanda na área de testes de desempenho por um preço acessível (CONTACTCENTERWORLD, 2014).
A ferramenta NeoLoad conta com a possibilidade de criação de perfis de usuário, para os usuários virtuais onde pode-se criar uma amostragem mais realista para a utilização nos testes, para isso utiliza-se do recurso drag & drop para definir repetições, condições e outras características do perfil, para ajustes mais avançados

45
pode-se utilizar a linguagem Javascript (NEOTYS, 2014a).
Destaca-se o fato de que se podem realizar testes específicos em áudios e vídeos utilizando métricas específicas para esse tipo de mídia, e a possibilidade de alterar a quantidade de usuários virtuais durante a execução dos testes que podem ser acompanhados em tempo real e ajustados conforme a necessidade (NEOTYS, 2014a).
Como forma de exibição de resultados a ferramenta conta com um analisador inteligente, que após ser pré-configurado indica como os resultados ficaram em relação às métricas definidas pelo usuário, dispõe também de comparativos de resultados entre testes e uma análise de negócio específica para cada empresa (NEOTYS, 2014a).
Compreende-se que o ponto fraco do NeoLoad é a falta de uma interface de programação, os scripts podem ser modificados manualmente no entanto pode demandar tempo em scripts mais complexos (MARIE, 2012).
Ficha técnica das principais características da ferramenta (NEOTYS, 2014a):
 Configuração de perfil de usuário virtual utilizando drag & drop;
 Testes específicos em áudios e vídeos;
 Alteração do cenário de teste em tempo de execução;
 Analisador inteligente para resultados dos testes.
Pode-se visualizar um exemplo da tela de criação de cenários de testes, conforme demonstrado na Figura 6:

46
Figura 6 - Exemplo de tela onde são criados os cenários
Fonte: Adaptado de NEOTYS (2014b).
5.4 FERRAMENTA LOADSTORM
A ferramenta LoadStorm é executada de forma online utilizando a tecnologia de computação na nuvem e dispensado instalações locais, para a execução de testes em sistemas web onde podem ser utilizados até trezentos e cinquenta mil usuários virtuais para cada teste executado em um período máximo de dez horas (LOADSTORM, 2014a).
O produto foi criado e comercializado pela empresa CustomerCentrix fundada em 1997, sua sede fica localizada em Albuquerque – NM (Novo México) nos EUA (Estados Unidos da América), a CustomerCentrix é uma companhia especializada em desenvolver aplicações web no modelo de comercialização SaaS (Software as a Service), sendo que seu mais novo produto é a ferramenta LoadStorm (LOADSTORM, 2014c).
A criação dos scripts de testes pode ser feita de forma automática realizando a gravação das ações do usuário no sistema, onde são gravadas todas as requisições e envios de dados a outras páginas permitindo também que esses scripts sejam alterados posteriormente sem qualquer codificação manual, sendo que esses testes podem ser incrementados por ferramentas de desenvolvimento no

47
próprio navegador (LOADSTORM, 2014a).
Para demonstrar os resultados à ferramenta conta com indicadores que são atualizados a cada um minuto durante a execução do teste, também são disponibilizados gráficos com as métricas de teste definidas e os filtros disponibilizados auxiliam a visualização ágil da ocorrência de lentidões e erros em locais específicos (LOADSTORM, 2014a).
Ficha técnica das principais características da ferramenta (LOADSTORM, 2014a):
 Ferramenta executada completamente de forma online;
 Suporte com consultores especialistas na área;
 Indicadores atualizados minuto a minuto;
 Versionamento e histórico dos scripts de testes.
Pode-se visualizar um exemplo do gráfico de distribuição do tempo de resposta, conforme demonstrado na Figura 7:
Figura 7 – Exemplo da tela do gráfico de distribuição do tempo de resposta
Fonte: Adaptado de LOADSTORM (2014b).
5.5 FERRAMENTA LOADUI
A ferramenta LoadUi caracteriza-se pelo recurso de drag & drop na criação de cenários, onde apenas arrastando os componentes pode-se criar e alterar os cenários de testes, possuindo também um controlador de fluxo para que os testes sejam controlados inclusive durante sua execução (SMARTBEAR, 2014a).
A empresa SmartBear Software Inc, produz e comercializa ferramentas de teste e desenvolvimento de software, fundada em 1999 com sede em na cidade de

48
Beverly – MA (Massachusetts) nos EUA, possui produtos com renome no mercado, sendo o mais conhecido o famoso TestComplete uma ferramenta que automatiza testes funcionais em diversas plataformas (BUSINESSWEEK, 2014).
Uma das características da ferramenta são os recursos de análise dos servidores onde o sistema exibe através de gráficos o desempenho dos servidores de aplicação, web, da base de dados e do sistema operacional dando uma cobertura eficaz no impacto da utilização dos recursos durante a execução dos testes (SMARTBEAR, 2014b).
Como forma de demonstrar os resultados obtidos a ferramenta conta com a possibilidade de personalização dos relatórios conforme as métricas de cada projeto, a exportação dos relatórios em diversos formatos e um painel de monitoramento detalhado dos testes em tempo real (SMARTBEAR, 2014c).
Ficha técnica das principais características da ferramenta (SMARTBEAR, 2014a, 2014b, 2014c):
 Tecnologia de controle de fluxo na execução dos testes;
 Criação de cenários de testes utilizando drag & drop;
 Monitoramento completo dos servidores;
 Relatórios de testes personalizados.
Pode-se visualizar um exemplo da tela de monitoramento da base de dados, conforme demonstrado na Figura 8:
Figura 8 - Exemplo da tela de monitoramento da base de dados
Fonte: Adaptado de SMARTBEAR (2014b).

49
5.6 FERRAMENTA JMETER
Ferramenta criada e mantida pela ASF (Apache Software Foundation), uma organização sem fins lucrativos fundada em 1999 que fornece suporte financeiro e organizacional para mais de 140 projetos de software de código aberto (APACHE, 2014).
JMeter é uma ferramentas de testes de performance para sistemas web que possibilita que o usuário defina requisições que podem ser configuradas para uma determinada quantidade de repetições, também podem ser adicionados pontos de verificação dentro do script (MOLINARI, 2010).
A ferramenta é desenvolvida na linguagem Java e não depende de instalação sendo totalmente portável e compatível com qualquer computador que contenha a máquina virtual do Java instalada, possui interface gráfica simplificada que permite melhor visualização dos controles da ferramenta (JMETER, 2013).
O fato de a ferramenta ser de código aberto permite que a mesma seja personalizada por usuários com conhecimento técnicos avançados e também possibilita o acoplamento de várias extensões que potencializam a gama de testes executados (JMETER, 2013).
Como ponto fraco do JMeter cita-se, que para que consiga se adequar a maioria das capacidades que já existem nas ferramentas comerciais, deve-se ter um profissional experiente para construir ferramentas personalizadas (ITCENTRALSTATION, 2014b).
Como forma de exibir seus resultados o JMeter utiliza o componente de listeners que após ser adicionado ao plano de testes permite que sejam exibidos relatórios e gráficos conforme as necessidades do usuário, podendo personalizar os listeners em cada teste realizado (MOLINARI, 2010).
Conforme Molinari (2010, p. 121), para a criação dos testes a ferramenta conta com diversos componentes que podem ser utilizados de forma individual ou combinados, dentre eles pode-se citar:
 Test plan ou plano de teste: é o topo da árvore agrupando todos os itens debaixo dele. [...]
 Workbench ou área de trabalho: é uma área temporária para trabalho que apoia o plano de testes.
 Thread group ou grupo de usuário: representa o grupo de Vus cujas requisições serão executadas.

50
 Configuration elements ou elementos de configuração: este elemento não faz requisições propriamente ditas, exceto no caso de HTTP Proxy Server, mas pode modificá-las.
 Listeners ou ouvintes: são os elementos que permitem acesso aos resultados dos testes.
 Timers ou temporizadores: são usados para incluir pausas entre as requisições, pois por definição o JMeter faz requisições sem pausa entre elas.
 Controllers ou controladores: dividem-se nos grupos samplers (controladores predefinidos para requisições específicas) e logic controllers (controladores genéricos, podendo ser customizados com a inserção de outros controllers, [...]).
 Assertions ou asserções: são usadas para verificar e validar se a resposta obtida na execução da requisição é a esperada.
 Pre-processor elements ou elementos pré-processadores: executam uma ação qualquer antes de fazer a requisição desejada.
 Post-processor elements ou elementos pós-processadores: executam uma ação qualquer depois de fazer a requisição desejada. [...]
Ficha técnica das principais características da ferramenta (JMETER, 2013; MOLINARI, 2010):
 Desenvolvido em Java e possui código aberto;
 Permite o acoplamento de diversas extensões;
 Grande quantidade de componentes para a criação de testes;
 Possibilidade de personalizar relatórios e gráficos a cada teste.
Pode-se visualizar um exemplo da tela de criação de cenários de testes onde está sendo configurado um temporizador, conforme demonstrado na Figura 9:
Figura 9 - Exemplo de tela de criação de cenários de teste
Fonte: Adaptado de IMOBILIS (2012).

51
5.7 COMPARATIVO ENTRE FERRAMENTAS
Nos tópicos anteriores foram apresentadas algumas das ferramentas que
são lideres de mercado na área de automação de testes de performance,
demonstrando suas principais características, durante a realização das pesquisas
também verificou-se outras ferramentas que não foram citadas nesse trabalho mas
que também cumprem esse proposito, dentre elas pode-se citar: Appvance, Loadster
e OpenSTA (SOFTWARE TESTING HELP, 2012).
Seguem os comparativos entre as ferramentas citadas nesse trabalho, na
Figura 10 pode-se visualizar um comparativo de preços e licenças, na Figura 11
pode-se visualizar um comparativo das plataformas suportadas e da forma de
gravação de scripts e na Figura 12 pode-se visualizar um comparativo da
capacidade de usuários virtuais:
Figura 10 - Comparativo entre ferramentas - Preço/Licença
Ferramenta Empresa Preço Licença
LoadRunner HP $2,00 à $0,56/VUD Commercial - Virtual User Days
BlazeMeter BlazeMeter $649/mês Commercial - PRO
NeoLoad Neotys Por VU via orçamento Commercial - PRO
LoadStorm CustomerCentrix $299/mês Comercial - Cyclone
LoadUI SmartBear $9,400/1 ano Commercial - Renewal
Jmeter Apache Software Foundation Grátis Open Source - Apache License
Fonte: Dos Autores
Figura 11 - Comparativo entre ferramentas - Plataforma/Gravação de Scripts
Ferramenta Empresa Ambiente de Testes Criação de Scripts: Manual/Gravador
LoadRunner HP Web/Desktop/Mobile Gravador
BlazeMeter BlazeMeter Web/Mobile Gravador
NeoLoad Neotys Web/Mobile Gravador
LoadStorm CustomerCentrix Web Gravador
LoadUI SmartBear Web Gravador
Jmeter Apache Software Foundation Web Manual
Fonte: Dos Autores
Figura 12 – Comparativo entre ferramentas - Capacidade de Usuários
Ferramenta Empresa Capacidade Máxima de VU(Usuários Virtuais)
LoadRunner HP Ilimitado
BlazeMeter BlazeMeter 5000
NeoLoad Neotys 50 - 1000000
LoadStorm CustomerCentrix 2000
LoadUI SmartBear Ilimitado
Jmeter Apache Software Foundation Ilimitado
Fonte: Dos Autores

52
Nesse capítulo foram abordadas algumas ferramentas de testes, demonstrando de forma detalhada suas características, pontos fortes e fracos e a forma de utilização de cada ferramenta exibida em imagens.
Foram evidenciadas características referentes a preço da licença das ferramentas, capacidade de tempo de testes e quantidade de usuários virtuais, forma de visualização dos resultados e formato de gravação dos scripts de testes.
Finalizando o capitulo também foram citadas outras ferramentas de menor porte encontradas durante as pesquisas e foram demonstrados três comparativos entre as fermentas levando em consideração alguns fatores importantes como preço, capacidade de testes e formato de gravação dos scripts.
A partir dessa pesquisa, no próximo capítulo pode-se realizar a aplicação prática da ferramenta JMeter em um sistema web baseando-se na contextualização de um problema específico do sistema web a ser testado.

53
6 ESTUDO DE CASO
Nesse capítulo será apresentado um estudo de caso baseando-se na aplicação prática da ferramenta JMeter em um software, bem como a coleta e análise dos resultados obtidos.
6.1 CONTEXTUALIZAÇÃO DO PROBLEMA
Para a aplicação prática dos conceitos vistos nos capítulos anteriores, será contextualizada uma determinada situação em um software chamado Portal Acadêmico utilizado pelos alunos e professores na Faculdade Esucri.
Trata-se de um sistema web para o gerenciamento das atividades acadêmicas da instituição, possui usuários de todos os cursos sendo eles alunos e professores, devido ao porte do software e sua importância dentro da instituição surgiu a necessidade de verificar se o tempo de resposta das principais funcionalidades do sistema pode-se considerar aceitável, para determinar esse tempo de resposta uma carga de dados deverá ser definida e aplicada, também será definida a capacidade de vazão (throughput) das funcionalidades do sistema, ou seja, serão verificadas quantas TPS (transações por segundo) as funcionalidades suportam.
Baseando-se na experiência dos usuários serão realizados testes nas funcionalidades de consulta ao acervo onde o usuário pode realizar buscas no acervo da biblioteca da faculdade, consulta de notas parciais onde o usuário pode visualizar suas notas durante o semestre para cada matéria cursada e criação de aulas onde o usuário pode realizar a criação das aulas que serão ministradas em cada matéria.
A seguir serão descritas as funcionalidades de forma mais detalhada, demonstrando sua importância dentro do sistema bem como sua principal característica funcional e demonstração da tela de cada funcionalidade.
A funcionalidade de buscas ao acervo da biblioteca permite ao usuário realizar diversos tipos de buscas dentro do acervo da biblioteca da instituição, podem ser realizadas buscas utilizando vários filtros e termos, essa foi uma das funcionalidades escolhidas para o teste devido sua importância na utilização dos acadêmicos e ao fato de que dependendo da busca podem-se ter diferentes amostragens de resultados, conforme demonstrado na Figura 13:

54
Figura 13 - Tela de consulta ao acervo
Fonte: Adaptado de UNIMESTRE (2014a).
A funcionalidade de consulta de notas parciais permite aos alunos que sejam consultadas as notas que foram lançadas para trabalhos e avaliações, separadas por cada matéria cursada, essa funcionalidade foi escolhida para os testes devido a grande utilização pelos acadêmicos durante todo o semestre e os constantes acessos em épocas de avaliações, conforme demonstrado na Figura 14:

55
Figura 14 - Tela de consulta de notas parciais
Fonte: Adaptado de UNIMESTRE (2014b).
A funcionalidade de criação de aulas permite ao professor realizar a criação de aulas para cada matéria, controlando a partir desse registro as frequências e conteúdos da matéria, essa funcionalidade foi escolhida para os testes devido a grande utilização por parte dos professores no seu dia-a-dia, conforme demonstrado na Figura 15:

56
Figura 15 - Tela de criação de aulas
Fonte: Adaptado de UNIMESTRE (2014c).
6.2 TIPOS DE TESTES EXECUTADOS
Na sequência serão abordados dois tipos de testes de desempenho que serão aplicados no software com a finalidade de mensurar os resultados e alcançar o objetivo da contextualização do problema.
Os parâmetros utilizados nos testes, como quantidade de usuários e conexão com a internet, foram definidos para simular o cenário de um usuário final do sistema, respeitando também as limitações do hardware utilizado e da conexão com a internet disponível, para que a ferramenta possa demonstrar resultados reais e precisos sobre os testes executados.
6.2.1 TESTES DE TEMPO DE RESPOSTA
Nesse tipo de testes será medido o tempo de resposta das funcionalidades citadas, ou seja, o tempo que o software leva para interpretar e responder ao usuário após uma determinada requisição.
Nesse teste serão utilizados 50 usuários virtuais que irão interagir simultaneamente com o software, cada usuário irá realizar uma requisição nas funcionalidades e irá aguardar a resposta da requisição, os testes serão realizados a partir de um computador considerando o ambiente client com conexão ADSL (Asymmetric Digital Subscriber Line) de 2 megabytes (taxa de 200 kilobytes/segundo

57
de download e 50 kilobytes/segundo de upload), para que os testes sejam considerados com resultado positivo espera-se um tempo de resposta menor que 1 segundo para cada requisição, podendo ter picos de 1.5 segundos ao final dos testes.
6.2.2 TESTES DE THROUGHPUT
Nesse tipo de testes será medida a capacidade de vazão do software, aplicando uma carga de dados incremental no mesmo de forma global e verificando a taxa de transações por segundo aceitável para uso cotidiano.
Nesse teste serão utilizados inicialmente 20 usuários virtuais simultâneos e a cada 2 segundos serão adicionados mais 20 usuários até que se obtenha um total de 100 usuários ativos, cada usuário estará realizando uma requisição e irá aguardar a resposta, os testes serão realizados a partir de um computador considerando o ambiente client com conexão ADSL de 2 megabytes (taxa de 200 kilobytes/segundo de download e 50 kilobytes/segundo de upload), para avaliar os resultados desses testes os usuários serão incrementados e será verificado se as respostas das requisições irão apresentar algum tipo de falha na ferramenta.
6.3 CRIAÇÃO DOS TESTES
Para facilitar o entendimento da etapa de criação dos testes, será utilizada uma legenda para cada teste realizado, demonstrada a seguir:
 TempRes01 = Teste de tempo de resposta na funcionalidade consulta ao acervo;
 TempRes02 = Teste de tempo de resposta na funcionalidade consulta de notas parciais;
 TempRes03 = Teste de tempo de resposta na funcionalidade criação de aulas;
 Vaz01 = Teste de vazão na funcionalidade consulta ao acervo;
 Vaz02 = Teste de vazão na funcionalidade consulta de notas parciais;
 Vaz03 = Teste de vazão na funcionalidade criação de aulas.
Para iniciar a criação dos testes deve-se acessar a ferramenta JMeter que ao ser aberta demonstra a seguinte tela contendo apenas o Plano de Testes e a Área de Trabalho, conforme demonstrado na Figura 16:

Automação de testes de desempenho para sistemas web utilizando a ferramenta jmeter

Automação de testes de desempenho para sistemas web utilizando a ferramenta jmeter

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Automação de testes de desempenho para sistemas web utilizando a ferramenta jmeter

Semelhante a Automação de testes de desempenho para sistemas web utilizando a ferramenta jmeter (20)

Automação de testes de desempenho para sistemas web utilizando a ferramenta jmeter