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 3.3 RESUMO DO CAPÍTULO ................................................................................. 34

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 4.3 RESUMO DO CAPÍTULO ................................................................................. 40 5 ESTUDO DAS FERRAMENTAS DE TESTES ...................................................... 41 5.1 FERRAMENTA LOADRUNNER ....................................................................... 41

5.1.1 CARACTERÍSTICAS ...................................................................................... 41

5.2 FERRAMENTA BLAZEMETER ........................................................................ 42 5.2.1 CARACTERÍSTICAS ...................................................................................... 42 5.3 FERRAMENTA NEOLOAD ............................................................................... 44 5.3.1 CARACTERÍSTICAS ...................................................................................... 44 5.4 FERRAMENTA LOADSTORM .......................................................................... 46

5.4.1 CARACTERÍSTICAS ...................................................................................... 46 5.5 FERRAMENTA LOADUI ................................................................................... 47 5.5.1 CARACTERÍSTICAS ...................................................................................... 48 5.6 FERRAMENTA JMETER .................................................................................. 49 5.6.1 CARACTERÍSTICAS ...................................................................................... 49

5.7 COMPARATIVO ENTRE FERRAMENTAS ...................................................... 51 5.8 RESUMO DO CAPÍTULO ................................................................................. 52

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

6.5 RESUMO DO CAPÍTULO ................................................................................. 70 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 23 - Requisições do teste TempRes02 .......................................................... 64

Figura 24 - Requisições do teste TempRes03 .......................................................... 64 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 Figura 28 - Resultado do teste TempRes02 .............................................................. 67 Figura 29 - Resultado do teste TempRes03 .............................................................. 68

LISTA DE QUADROS

Quadro 1 - Métricas da automação de testes............................................................ 27

Quadro 2 - Resultado do teste Vaz01 ....................................................................... 68 Quadro 3 - Resultado do teste Vaz02 ....................................................................... 69 Quadro 4 - Resultado do teste Vaz03 ....................................................................... 69

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


Manutenibilidade X

Flexibilidade X

28

Confiabilidade X

Robusteza X

Usabilidade 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,


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,


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,


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:

58

Figura 16 - Tela inicial da ferramenta JMeter

Fonte: Dos Autores

Inicialmente para a criação dos scripts de testes utiliza-se na Área de

Trabalho o componente Servidor HTTP Proxy que será responsável por gravar a

navegação nas funcionalidades para posterior utilização nos testes, também utiliza-

se no Plano de Teste o componente Grupo de Usuários que irá receber a gravação

das requisições realizadas pelo usuário, conforme demonstrado na Figura 17 e

Figura 18:

59

Figura 17 - Componente Servidor HTTP Proxy

Fonte: Dos Autores

Figura 18 - Componente Grupo de Usuários

Fonte: Dos Autores

A gravação é iniciada após o servidor proxy ser iniciado e o acesso ser

realizado por um navegador configurado para o proxy criado, dessa forma ao

navegar por uma determinada funcionalidade o JMeter irá gravar as requisições de

cada página e armazená-las no plano de testes para posterior utilização, conforme

demonstrado na Figura 19:

60

Figura 19 - Exemplo do componente de requisições

Fonte: Dos Autores

A partir desse ponto com as requisições já gravadas para a navegação de

cada funcionalidade, inicia-se a montagem dos testes, o primeiro teste a ser criado

será o teste de tempo de resposta na funcionalidade de consulta ao acervo, à

criação do teste inicia-se com a parametrização do componente Grupo de Usuários,

informando para o número de usuários virtuais o valor 50 conforme demonstrado na

Figura 20:

61

Figura 20 - Parametrizando 50 usuários virtuais

Fonte: Dos Autores

Após isso deve-se verificar as requisições gravadas para a funcionalidade

afim de conferir se todos os dados gravados estão corretos, no caso do teste

TempRes01 serão realizadas 9 requisições que incluem o login no portal e a

consulta no acervo buscando pelo termo ‘Windows’ no filtro de títulos e subtítulos

conforme demonstrado na Figura 21 :

62

Figura 21 - Requisições do teste TempRes01

Fonte: Dos Autores

Conferidas todas as requisições deve-se adicionar um ouvinte que será o

componente que irá exibir os resultados da execução do teste.

Para o teste realizado será utilizado o componente Gráfico Agregado que

calcula a média do tempo de resposta para cada requisição, conforme demonstrado

na Figura 22:

63

Figura 22 - Componente de Gráfico Agregado

Fonte: Dos Autores

Finalizando a criação do teste deve-se salvar o arquivo para posterior

execução.

Para a criação dos testes TempRes02 e TempRes03 os primeiros passos se

repetem desde a gravação das requisições, passando pela conferência das

requisições, parametrização dos usuários virtuais e adição do ouvinte, nesse caso a

única diferença entre os testes são as requisições que foram gravadas conforme

demonstrado na Figura 23 e Figura 24:

64


Fonte: Dos Autores


Fonte: Dos Autores

Para a criação dos testes de vazão o procedimento é semelhante ao dos

testes de tempo de resposta, se diferenciando apenas em dois pontos, na adição de

mais de um grupo de usuários e na adição de outro tipo de ouvinte.

Os grupos de usuários serão um total de cinco grupos que irão conter as

mesmas requisições, sendo que cada um deles estará parametrizado para 20

65

usuários virtuais, totalizando 100 usuários e para esses grupos de usuários será

utilizada a propriedade do agendador onde será possível inserir os dois segundos de

intervalo entre os grupos de usuários, conforme demonstrado na Figura 25:

Figura 25 - Grupos de usuários com propriedade agendador

Fonte: Dos Autores

Para verificar o resultado desse teste será utilizado o ouvinte do tipo

Relatório Agregado que demonstra os dados da execução de cada requisição e

evidencia se ocorreu erro em alguma das requisições, conforme demonstrado na

Figura 26:

66

Figura 26 - Exemplo de relatório agregado

Fonte: Dos Autores

As requisições dos testes de vazão são as mesmas demonstradas

anteriormente e utilizadas nos testes de tempo de resposta, sendo que apenas

foram agrupadas em mais grupos de usuários e foi adicionado um novo ouvinte, com

isso encerra-se a criação dos testes que podem ser executados a qualquer momento

acessando o arquivo salvo e executando o mesmo na ferramenta JMeter.

6.4 EXECUÇÃO E AVALIAÇÃO DOS RESULTADOS

Nessa etapa serão executados os testes e demonstrados os resultados para

todos os testes criados na etapa anterior finalizando o estudo de caso.

Na execução do teste TempRes01 obteve-se o seguinte resultado, o teste foi

executado dia 29 de setembro de 2014 as 15:00 horas e levou aproximadamente 90

segundos para ser executado pela ferramenta, resultando em uma média de 4,5

segundos para as requisições, sendo que o pico de tempo de resposta foi na

requisição que realiza o login no portal, esses resultados são demonstrados na

Figura 27:

67

Figura 27 - Resultado do teste TempRes01

Fonte: Dos Autores


executado dia 29 de setembro de 2014 as 15:10 horas e levou aproximadamente 80

segundos para ser executado pela ferramenta, resultando em uma média de 4,6


requisição que realiza o login no portal, esses resultados são demonstrados na

Figura 28:


Fonte: Dos Autores


executado dia 29 de setembro de 2014 as 17:40 horas e levou aproximadamente

240 segundos para ser executado pela ferramenta, resultando em uma média de 8,4


requisição que acessa o diário de classe, esses resultados são demonstrados na

Figura 29:

68


Fonte: Dos Autores

Na execução do teste Vaz01 obteve-se o seguinte resultado, o teste foi


120 segundos para ser executado pela ferramenta, ao final da execução dos 100

usuários virtuais não foram encontradas falhas em nenhuma das requisições, esses

resultados são demonstrados no Quadro 2:

Quadro 2 - Resultado do teste Vaz01

Rótulo #Amostras % de Erro

.../login.php 100 0.0

.../login.php?tid=0&lid=0&pid =23&sid=258aa88… 100 0.0

.../grupo_selecionar.php 100 0.0

.../index.php 100 0.0

.../inicial.php 100 0.0

.../index.php 100 0.0

.../consulta.php 100 0.0

.../consulta.php?tid=0&lid =0&pid=4&sid=258… 100 0.0

TOTAL 800 0.0

Fonte: Dos Autores




usuários virtuais não foram encontradas falhas em nenhuma das requisições, esses


69



.../login.php 100 0.0



.../index.php 100 0.0


.../notas_frequencias_listar.php 100 0.0

.../notas_frequencias_parciais.php 100 0.0

TOTAL 700 0.0

Fonte: Dos Autores




usuários virtuais foram encontradas falhas em duas das requisições, esses




.../login.php 100 0.0



.../index.php 100 0.0


.../diario_classes/index.php 100 2.0

.../diario_classes/turmas_listar.php 100 2.0

.../diario_classes/aulas_listar.php 100 0.0

.../diario_classes/aulas_inserir.php 100 0.0

.../diario_classes/aulas_inserir.php?tid=0&lid=... 100 0.0

.../diario_classes/aulas_listar.php?tid=0&lid=... 100 0.0

TOTAL 1100 0.36

Fonte: Dos Autores

Após a execução dos testes foi constatado que apesar de alguns testes não

atingirem os níveis de performance esperados o sistema se comporta de forma

rápida e segura, onde muitas das requisições alcançam taxas mínimas de 0,2

segundos e com taxa de erros quase nula, sendo que um dos pontos que elevou os

70

tempos dos testes executados foi a realização do login no portal, fato esse que é

justificável devido as questões de segurança e autenticação envolvidas nesse

processo.


Nesse capítulo foi elaborado um estudo de caso sobre a problemática de um

sistema web de portal acadêmico que gerencia as atividades relacionadas à

instituição de ensino superior, também foram escolhidas como funcionalidades a

serem testadas a consulta de acervo da biblioteca, consulta de notas do acadêmico

e a criação de aulas.

Com base no sistema a ser avaliado foi definido como tipo de testes a serem

executados os testes referentes a tempo de resposta e throughput (vazão). Para o

teste de tempo de resposta os parâmetros base da avaliação a ser realizada foram

definidos como: 50 usuários virtuais simultâneos com tolerância de picos de 1,5

segundos no final dos testes. Já no teste de Throughput os parâmetros foram: 20

usuários virtuais simultâneos e a cada 2 segundos um incremento de mais 20

usuários, os resultados apurados foram avaliados para a verificação de falhas em

alguma das requisições.

O capítulo seguiu com um passo a passo da criação prática do teste na

ferramenta JMeter, explicando os componentes utilizados como Plano de Teste,

Área de Trabalho, HTTP Proxy e Grupo de Usuários que são necessários para a

gravação das requisições que serão usadas na montagem dos teste. E finalizando

foi demonstrada a criação do teste, execução e avaliação dos resultados.

71

7 CONSIDERAÇÕES FINAIS

Neste capítulo serão apresentadas as conclusões e recomendações para

trabalhos futuros.

7.1 CONCLUSÕES

A necessidade de testes de software aumentou significativamente com a

crescente demanda de produção de software, com isso os processos de testes que

podem ser automatizados refletem em ganho de tempo, produtividade e qualidade e

impactam diretamente no custo de produção do produto.

Com a realização do estudo desse trabalho focando os testes de

performance automatizados em sistemas web, conclui-se que as algumas das

ferramentas pesquisadas necessitam de um investimento alto e profissionais

altamente qualificados, pois as ferramentas pagas tem um preço considerável e

algumas delas fazem cobrança por teste realizado, sendo assim os scripts de testes

devem ser eficientes e sem erros.

O fato das empresas voltarem seus olhares e investirem um valor alto em

testes de performance é explicado pela situação atual do mercado, onde milhares de

requisições web são realizadas na rede o tempo todo, ocasionando engarrafamentos

digitais e lentidão. O produto ou serviço que tiver um melhor desempenho e não fizer

o usuário esperar ganhará mais clientes.

Considerando os fatores relevantes para o desempenho de sistemas web, o

tempo de reposta e vazão, a ferramenta JMeter foco desse trabalho, mostrou-se

eficaz e com custo referente apenas ao profissional qualificado. A criação dos scripts

de testes se faz de forma simples e os resultados esperados são rapidamente

obtidos.

Ao comparar a fermenta JMeter com as demais ferramentas comerciais fica

evidente que o JMeter pode ser uma solução para a maioria das empresas, nota-se

também que grandes corporações podem atender suas necessidades optando pelo

JMeter, necessitando apenas de uma estrutura básica de operação e profissionais

da área de testes de performance.

Por fim o estudo prático da ferramenta JMeter em um sistema web já

utilizado no mercado, possibilitou a realização de uma avaliação de usabilidade,

comportamento e interpretação dos resultados e confrontar com os conceitos base

72

de testes de performance que foram abordados durante o trabalho realizado,

permitindo assim confirmar a base teórica com a prática.

7.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS

Baseando-se no conhecimento adquirido através da pesquisa e

desenvolvimento desse trabalho, podem-se destacar os seguintes temas como

recomendações para trabalhos futuros:

Realizar testes funcionais em conjunto com os testes de desempenho através da

ferramenta JMeter;

Realizar testes de desempenho na camada do servidor da aplicação web;

Criação de um protótipo de ferramenta para automação de testes de desempenho

baseado no código fonte do JMeter;

Realizar um estudo de caso utilizando uma ferramenta de automação de testes de

desempenho desenvolvida no formato SaaS.

73

REFERÊNCIAS

APACHE. Foundation. 2014. Disponível em: <http://www.apache.org/foundation/>. Acesso em: 09 ago. 2014. BASTOS, Aderson. et al. Base de conhecimento em teste de software. 3. ed. São Paulo: Martins Fontes, 2012. BERNARDO, Paulo C.; KON, Fabio. A importância dos testes automatizados. Engenharia de Software Magazine. a. 1, n. 3, pp. 54-57, 2008. Disponível em: <http://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf>. Acesso em: 15 maio 2014. BIRD, Jim. Testes automatizados como documentação. 2013. Disponível em: <http://imasters.com.br/desenvolvimento/testes-automatizados-como-documentacao/>. Acesso em: 15 maio 2014. BLAZEMETER. BlazeMeter the load testing cloud. 2014a. Disponível em: <http://blazemeter.com/>. Acesso em: 06 ago. 2014. ______. Mobile. 2014b. Disponível em: <http://blazemeter.com/mobile>. Acesso em: 06 ago. 2014. ______. Features. 2014c. Disponível em: <http://blazemeter.com/features>. Acesso em: 07 ago. 2014. ______. Join our team. 2014d. Disponível em: <http://blazemeter.com/join-our-team>. Acesso em: 09 ago. 2014. BUSINESSWEEK. SmartBear software inc.: private company information – businessweek. 2014. Disponível em: <http://investing.businessweek.com/research/stocks/private/snapshot.asp?privcapId=11214573>. Acesso em: 14 ago. 2014. CAETANO, Cristiano. Introdução à automação de testes. [2014]a. Disponível em: <http://www.qualister.com.br/blog/introducao-a-automacao-de-testes>. Acesso em: 26 maio 2014. ______. Melhores práticas e desafios na automação de testes. [2014]b. Disponível em: <http://www.qualister.com.br/blog/melhores-praticas-e-desafios-na-automacao-de-testes>. Acesso em: 15 maio 2014. ______. Níveis de maturidade em automação de testes. [2014]c. Disponível em: <http://www.qualister.com.br/blog/niveis-de-maturidade-em-automacao-de-testes>. Acesso em: 26 maio 2014. CAMPOS, Fábio Martinho. Teste de desempenho: conceitos, objetivos e aplicação - parte 1. [2011]. Disponível em: <http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx>. Acesso em: 13 maio 2014.

74

CAMPOS, Fabrício Ferrari de. Indicadores de testes. 2010. Disponível em: <http://qualidadebr.wordpress.com/2010/04/25/indicadores-de-teste>. Acesso em: 10 maio 2014. CANAL TECH. Tudo sobre HP. 2014. Disponível em: <http://canaltech.com.br/tag/HP/>. Acesso em: 09 ago. 2014. CONTACTCENTERWORLD. Neotys – company profile. 2014. Disponível em: <http://www.contactcenterworld.com/company/neotys.aspx>. Acesso em: 09 ago. 2014. COLLINS, Eliane. Automação de testes é.... 2013. Disponível em: <http://www.divus.com.br/sobre/blog/item/14-automacao-de-testes-e>. Acesso em: 15 maio 2014. CÔRTES, Mario Lúcio; CHIOSSI, Thelma C. dos Santos. Modelos de qualidade de software. Campinas, SP: Unicamp, Instituto de Computação, 2001. COSTA, Pedro. Os tipos de teste de software. 2013. Disponível em: <http://crowdtest.me/tipos-teste-software/>. Acesso em: 03 ago. 2014. DAYCHOUM, Merhi. 40+10 ferramentas e técnicas de gerenciamento. Rio de Janeiro: Brasport, 2013. Disponível em: <http://books.google.com.br/books?id=6zIuAgAAQBAJ>. Acesso em: 14 maio 2014. DELAMARO, Márcio Eduardo; MALDONADO, José Carlos; JINO, Mario. Introdução ao teste de software. Rio de Janeiro: Elsevier, 2007. DENNIS, Pascal. Produção Lean simplificada: um guia para entender o sistema de produção mais poderoso do mundo. São Paulo: Artmed, 2008. Disponível em: <http://books.google.com.br/books?id=V8hK2KJjwsQC>. Acesso em: 14 maio 2014. ENGHOLM JR, Hélio. Engenharia de software na prática. São Paulo: Novatec, 2010. Disponível em: <https://novatec.com.br/livros/engenhariasoftware/capitulo9788575222171.pdf>. Acesso em: 10 maio 2014. FOWLER, Martin. et al. Padrões de arquitetura de aplicações corporativas. São Paulo: Artmed, 2003. Disponível em: <http://books.google.com.br/books?id=8uSN0Qwz2kQC>. Acesso em: 13 maio 2014. GUELBERT, Marcelo. Estratégia de gestão de processos e da qualidade. Curitiba: IESDE Brasil, 2012. Disponível em: <http://books.google.com.br/books?id=RHMA7tHU2XUC>. Acesso em: 14 maio 2014. HP. Hewlett-Packard. Visão geral. 2014. Disponível em: <http://www8.hp.com/br/pt/software-solutions/loadrunner-load-testing/index.html>. Acesso em: 06 ago. 2014.

75

HYNES, Owen. BlazeMeter reviews. 2013. Disponível em: <http://www.getapp.com/reviews/listing/blazemeter-application>. Acesso em: 14 ago. 2014. IMOBILIS. Uso do Jmeter para testes de desempenho na web. 2012. Disponível em: <http://www.decom.ufop.br/imobilis/?p=1146>. Acesso em: 15 ago. 2014. ITCENTRALSTATION. LoadRunner review - cost effective performance validation tool | IT central station. 2014a. Disponível em: <http://www.itcentralstation.com/product_reviews/loadrunner-review-by-rutger>. Acesso em: 14 ago. 2014. ______. Powerful open source with wide community support: needs experience to match commercial alternatives. 2014b. Disponível em: <http://www.itcentralstation.com/product_reviews/21452 >. Acesso em: 17 ago. 2014. JMETER. Apache jmeter. 2013. Disponível em: <http://jmeter.apache.org/>. Acesso em: 15 ago. 2014. LOADSTORM. Loadstorm pro benefits. 2014a. Disponível em: <http://loadstorm.com/pro/>. Acesso em: 13 ago. 2014. ______. Tour of loadstorm pro. 2014b. Disponível em: <http://loadstorm.com/tour-of-loadstorm/>. Acesso em: 13 ago. 2014. ______. Load testing company. 2014c. Disponível em: <http://loadstorm.com/load-testing-company/>. Acesso em: 14 ago. 2014. LOBO, Edson J. R. Curso de engenharia de software: métodos e processos para garantir a qualidade no desenvolvimento de softwares. São Paulo: Digerati Books, 2008. Disponível em: <http://books.google.com.br/books?id=ZJznA9UrtVAC>. Acesso em: 14 maio 2014. LOURENÇO, Marcelo. Teste de aceitação. 2010. Disponível em: <http://qualidade-de-software.blogspot.com.br/2010/01/teste-de-aceitacao.html>. Acesso em: 03 ago. 2014. LUIZ, Rogério da Costa Dantas. Plone 4: administrando servidores 4.x na prática. Rio de Janeiro: Brasport, 2014. Disponível em: <http://books.google.com.br/books?id=zLTUAgAAQBAJ>. Acesso em: 24 maio 2014. MARIE, Pierre. Hi all, have you used both NeoLoad and LoadRunner for performance testing?. 2012. Disponível em: <http://www.linkedin.com/groups/Hi-all-have-you-used-132947.S.94503941>. Acesso em: 14 ago. 2014. MARTINEZ, Marina. Endereçamento IP. Infoescola. 2014. Disponível em: <http://www.infoescola.com/redes-de-computadores/enderecamento-ip/>. Acesso em: 25 maio 2014. MARTINS, Vidal. Servidores de aplicação. 2009. Disponível em:

76

<http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1016>. Acesso em: 03 ago. 2014. MOLINARI, Leonardo. Inovação e automação de teste de software. São Paulo: Érica, 2010. ______. Testes de performance. Florianópolis: Visual Books, 2009. ______. Testes de software: produzindo sistemas melhores e mais confiáveis. 2. ed. São Paulo: Érica, 2003. MORAES, Luísa Péret; MORAES, Paula Péret. Conceito: o que é cookie?. 2009. Disponível em: <http://webiscool.wordpress.com/2009/05/16/conceito-o-que-cookie/>. Acesso em: 04 ago. 2014. MYERS, Glenford J. The art of software testing. 2004. Disponível em: <http://webserver2.tecgraf.puc-rio.br/~raquelg/LIVRO_TheArtOfSoftwareTesting.pdf>. Acesso em: 02 nov. 2014. NEOTYS. Neoload key features. 2014a. Disponível em: <http://www.neotys.com/product/neoload-features.html>. Acesso em: 07 ago. 2014. ______. Neoload screenshots. 2014b. Disponível em: <http://www.neotys.com/product/screenshots-web-stress-tools.html#!prettyPhoto[pp_gal]/3/>. Acesso em: 08 ago. 2014. OLIVEIRA, Arize. O que é proxy?: descubra o significado desse termo. 2013. Disponível em: <http://www.techtudo.com.br/artigos/noticia/2011/05/o-que-e-proxy-descubra-o-significado-desse-termo.html>. Acesso em: 25 maio 2014. PALADINI, Edson Pacheco. Gestão da qualidade: teoria e prática. 2. ed. São Paulo: Atlas, 2004. PISA, Pedro. O que é IP?. 2012. Disponível em: <http://www.techtudo.com.br/artigos/noticia/2012/05/o-que-e-ip.html>. Acesso em: 25 maio 2014. PRESSMAN, Roger S. Engenharia de software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002. RAMOS, Thiago Santiago. Medindo o desempenho de aplicações web – parte 1. 2014. Disponível em: <http://blog.octo.com/pt-br/medindo-o-desempenho-de-aplicacoes-web-parte-1/>. Acesso em: 04 ago. 2014. REZENDE, Denis Alcides. Engenharia de software e sistemas de informação. 3. ed. Rio de Janeiro: Brasport, 2005. SILVEIRA, Sarah Gonçalves. Métricas na qualidade de software. 2013. Disponível em: <http://www.tiegestao.com.br/2013/06/30/metricas-na-qualidade-de-software>. Acesso em: 10 maio 2014.

77

SMARTBEAR. Create load tests. 2014a. Disponível em: <http://smartbear.com/products/qa-tools/web-service-load-testing/creating-web-service-load-tests/>. Acesso em: 14 ago. 2014. ______. Analyze server performance. 2014b. Disponível em: <http://smartbear.com/products/qa-tools/web-service-load-testing/features/server-monitoring/>. Acesso em: 14 ago. 2014. ______. Report and analyze results. 2014c. Disponível em: <http://smartbear.com/products/qa-tools/web-service-load-testing/features/analysis-and-reporting/>. Acesso em: 14 ago. 2014. SOFTWARE TESTING HELP. Top 15 performance testing tools – comprehensive list of in-demand tools with download link. 2012. Disponível em: <http://www.softwaretestinghelp.com/performance-testing-tools-load-testing-tools/>. Acesso em: 20 ago. 2014. SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Addison Wesley, 2003. TEBOUL, James. Gerenciando a dinâmica da qualidade. Rio de Janeiro: Qualitymark, 1991. Disponível em: <http://books.google.com.br/books?id=Ce3lZr-wi6IC>. Acesso em: 14 maio 2014. UNIMESTRE. Consulta ao acervo. 2014a. Disponível em: <http://intranet.esucri.com.br/projetos/portal_online/index.php?tid=0&lid=0&pid=23&sid=869e1f0d805>. Acesso em: 25 set. 2014. ______. Notas parciais. 2014b. Disponível em: <http://intranet.esucri.com.br/projetos/diario_classes/notas_frequencias_parciais.php?cd_aluno=MTIwMTE3Mg==&anosemestre=MjAxNDI=&disciplina=MjU5&turma=U0lfNiBVLg%3D%3D&turmamatricula=U0lfOCBV&curso=U0k%3D&nr_etapa=MQ==&sid=869e1f0d805#ancora_np>. Acesso em: 25 set. 2014. ______. Diário de classe. 2014c. Disponível em: <http://intranet.esucri.com.br/projetos/portal_online/index.php?tid=0&lid=0&pid=23&sid=cf36573e02c>. Acesso em: 29 set. 2014. VIEIRA FILHO, Geraldo. Gestão da qualidade total: uma abordagem prática. 3. ed. Campinas, SP: Alínea, 2010. ZOTTO, Ozir F. A. Protocolo HTTP (Hypertext Transfer Protocol). 2009. Disponível em: <http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=138>. Acesso em: 04 ago. 2014.