SUPPORTER TEST - FERRAMENTA DE APOIO AO GERENCIAMENTO DE ... · SUPPORTER TEST - FERRAMENTA DE APOIO AO ... que deve ser testado, serve de base para os testes. Um parecer de cada

CENTRO UNIVERSITÁRIO UNIVATES

CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS

CURSO DE SISTEMAS DE INFORMAÇÃO

CASSIANO PATRIC WEISS

SUPPORTER TEST - FERRAMENTA DE APOIO AO GERENCIAMENTO DE TESTES DE SOFTWARE

Lajeado

2013

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

1

CASSIANO PATRIC WEISS

SUPPORTER TEST - FERRAMENTA DE APOIO AO GERENCIAMENTO DE TESTES DE SOFTWARE

Projeto apresentado ao Centro de Ciências Exatas e Tecnológicas do Centro Universitário UNIVATES, como parte dos requisitos para a obtenção do título de bacharel em Sistemas de Informação Área de concentração: Informática

Orientador: _________________________________

Prof. M. Sc. Fabrício Pretto, UNIVATES

Mestre pela PUCRS – Porto Alegre, Brasil.

Banca Examinadora:

Prof. M. Sc. Evandro Franzen, UNIVATES

Mestre pela UFRGS – Porto Alegre, Brasil.

Prof. M. Sc. Paulo Roberto Mallmann, UNIVATES

Mestre pela UNISINOS – São Leopoldo, Brasil

Coordenador do Curso de Sistemas de

Informação:_________________________

Prof. Evandro Franzen

Lajeado, Junho de 2013

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

2

Dedico este trabalho a minha família, principalmente pela dedicação e apoio em todos

os momentos difíceis.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

3

AGRADECIMENTOS

Agradeço aos meus pais, Célio e Elaine Weiss, pelo apoio durante todos os momentos

bons e difíceis durante o curso.

A minha noiva, Miriam Wenzel, por estar ao meu lado em todos os momentos, e pela

compreensão, paciência e apoio nos meus momentos que mais precisei.

A minha irmã, Stefana e seu namorado Valter, por todo apoio e auxilio no decorrer do

desenvolvimento deste trabalho.

Ao meu orientador Fabrício Pretto, pelo comprometimento, paciência, sugestões,

propostas e disponibilidade de tempo.

A empresa Cantu & Stange Ltda, representada pelo seu diretor técnico por me

conceder folga nos momentos que precisei para desenvolver esse trabalho.

E a todos que, de uma forma ou de outra, contribuíram para a realização deste

trabalho.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

4

RESUMO

A constante evolução dos computadores elevou o número de sistemas criados para possibilitar a comunicação entre as pessoas. Para garantir a qualidade dos softwares, é necessário executar diversos testes durante o processo de desenvolvimento dos mesmos. A execução dos testes nem sempre ocorre de forma organizada, pois é difícil mapear onde irá impactar uma alteração no sistema. Para que se consiga rastrear essas situações, foi desenvolvida uma ferramenta para auxiliar no gerenciamento de testes em sistemas web ou desktop. Na ferramenta desenvolvida é possível gerar scripts de teste, baseando-se apenas em algumas informações pré-cadastradas e uma definição de importância feita por um analista no momento de cada alteração. A execução dos testes é feita de forma manual ou com o auxílio de uma ferramenta de automação, porém, o script gerado, o qual contém apenas o roteiro do que deve ser testado, serve de base para os testes. Um parecer de cada item testado pode ser registrado, formando assim uma base de dados. Após o registro dos pareceres, é possível emitir relatórios para identificar em qual módulo, segmento ou área do sistema estão ocorrendo mais problemas. Além disso, a ferramenta possui um mapeamento das dependências e impactos de alterações nos módulos e telas, servindo como documentação, regramento e facilitador para a ação de treinar novos testadores.

Palavras-chave: Teste de software, Script de teste

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

5

ABSTRACT

The constant evolution of computers increased the number of systems designed to enable communication between people. To ensure the quality of the software, it is necessary to perform several tests during their development. Such tests do not always occur in an organized manner, it is difficult to map which will impact a change in the system. To be able to track these situations, was developed a tool to provide assistance in management of tests in web or desktop systems. In the developed tool is possible to generate test scripts, relying only on some pre-registered information and a definition of importance made by an analyst at the time of each change. The tests are made manually or with the support of an automation tool, however, the generated script, which contains only the script that should be tested, serve as basis for the tests. An opinion of each item tested can be registered, thereby forming a database. After registering the opinions, it is possible to issue reports to identify in which module, segment or system area are occurring more problems. Additionally, the tool has a mapping of dependencies and impacts of changes in the modules and screens, serving as documentation, regulation and facilitator for the action of training new testers. Keywords: Software Testing, Software Script

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

6

LISTA DE FIGURAS

Figura 1 - Testes na Engenharia de Software ........................................................................... 17 Figura 2 - Estrutura para abordagens de teste de integração .................................................... 21 Figura 3 - Sequência de testes bottom-up ................................................................................. 22 Figura 4 - Sequência de testes top-down .................................................................................. 22 Figura 5 - Sequência de testes big-bang ................................................................................... 23 Figura 6 - Sequência de testes ‘sanduíche’ ............................................................................... 24 Figura 7 - Tela de execução dos casos de teste no Selenium ................................................... 28 Figura 8 - Planilha keyword-data-driven que servirá de base para o AutoTest ....................... 29

Figura 9 - Tela de resultados do TestLink ................................................................................ 30 Figura 10 - Tela de resultado TestComplete ............................................................................ 31 Figura 11 - Resultado dos testes no Klaros TestManagement.................................................. 32 Figura 12 - Tela de criação de tarefas no Apache JMeter ........................................................ 33 Figura 13 - Tela de execução dos casos de teste no Aqua ........................................................ 34 Figura 14 - Tela de visualização dos casos de teste no Aqua ................................................... 35 Figura 15 - Tela de estatísticas do TestMaster ......................................................................... 36 Figura 16 - Casos de uso do analista de testes .......................................................................... 39 Figura 17 - Casos de uso do testador ........................................................................................ 40 Figura 18 - Fluxograma da ferramenta desenvolvida ............................................................... 40 Figura 19 - Modelo ER do banco de dados .............................................................................. 43 Figura 20 - Cadastro de Tela .................................................................................................... 47

Figura 21 - Ações por Tela ....................................................................................................... 48

Figura 22 - Manutenção de Ações ............................................................................................ 49 Figura 23 - Manutenção de Alterações ..................................................................................... 50 Figura 24 - Script ...................................................................................................................... 51

Figura 25 - Execução do script ................................................................................................. 52 Figura 26 - Gráfico de itens reprovados por módulo................................................................ 53 Figura 27 - Gráfico de scripts por módulo ............................................................................... 54 Figura 28 - Relatório sintético de itens reprovados .................................................................. 55 Figura 29 - Relatório analítico de itens reprovados .................................................................. 56 Figura 30 - Relatório analítico de itens reprovados por módulo .............................................. 57 Figura 31 - Relatório sintético de itens reprovados por módulo .............................................. 57

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

7

LISTA DE QUADROS

Quadro 1 - Exemplo de script .................................................................................................. 41

Quadro 2 - Nível de prioridade dos itens de teste..................................................................... 45 Quadro 3 - Rastreabilidade das ações em modo texto .............................................................. 46

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

8

LISTA DE TABELAS

Tabela 1 - Conceitos de Teste de Software .............................................................................. 16 Tabela 2 - Comparativo das ferramentas de teste de software ................................................. 37 Tabela 3 - Requisitos funcionais .............................................................................................. 41 Tabela 4 - Requisitos não funcionais ........................................................................................ 42 Tabela 5 - Participantes da avaliação da ferramenta ................................................................ 58

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

9

LISTA DE ABREVIATURAS

CSV: Comma Separated Values

ER: Entidade Relacionamento

GPL: General Public License

PC: Personal Computer

QA: Quality Assurance

SGBD: Sistema Gerenciador de Banco de Dados

SQA: Software Quality Assurance

SQL: Structured Query Language

V&V: Validação e Verificação

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

10

SUMÁRIO

1 INTRODUÇÃO ................................................................................................................ 11 1.1 Motivação ..................................................................................................................... 12 1.2 Objetivos gerais ............................................................................................................ 12 1.3 Objetivos específicos .................................................................................................... 13 1.4 Organização do trabalho ............................................................................................... 13 2 ESTADO DA ARTE ........................................................................................................ 14 2.1 Verificação e Validação................................................................................................ 14 2.2 Teste de software .......................................................................................................... 15 2.2.1 Técnicas de teste ........................................................................................................... 17 2.2.2 Fases de teste ................................................................................................................ 19 2.2.3 Abordagens de teste de integração ............................................................................... 21 2.3 Automação de testes ..................................................................................................... 24 2.3.1 Ferramentas para análise de código .............................................................................. 25 3 FERRAMENTAS DE APOIO AOS TESTES ................................................................. 27

3.1 Selenium ....................................................................................................................... 27 3.2 AutoTest ....................................................................................................................... 28 3.3 TestLink ........................................................................................................................ 29

3.4 JUnit ............................................................................................................................. 30

3.5 TestComplete ................................................................................................................ 30 3.6 Klaros TestManagement ............................................................................................... 31 3.7 Apache JMeter .............................................................................................................. 32 3.8 Aqua ............................................................................................................................. 33

3.9 TestMaster .................................................................................................................... 35 3.10 Testipool ....................................................................................................................... 36

3.11 Comparativo entre ferramentas .................................................................................... 37 4 DESENVOLVIMENTO DA FERRAMENTA ................................................................ 38

4.1 Requisitos funcionais, requisitos não funcionais e modelo ER .................................... 41

4.2 Cadastros gerais ............................................................................................................ 43 4.3 Scripts ........................................................................................................................... 44

4.4 Especificação e telas ..................................................................................................... 46 4.5 Validação e verificação do uso da ferramenta .............................................................. 57 5 CONSIDERAÇÕES FINAIS ........................................................................................... 60 REFERÊNCIAS ....................................................................................................................... 61

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

11

1 INTRODUÇÃO

Na década de 1980, os computadores eram usados pelas indústrias que necessitavam

de um grande poder de processamento de dados. Já na década de 1990, o PC (Personal

Computer) tornou o software acessível para o público em geral. Com isso novas tecnologias

surgiram, e os computadores se tornaram mais rápidos, potentes e também mais baratos,

fazendo com que muitas pessoas tivessem acesso aos mesmos. Isso resultou em uma maior

produção de computadores e softwares com diversas finalidades, e fez com que a exigência

pela qualidade de software também aumentasse. No entanto, pouco tempo era disponibilizado

para testar, fazendo com que muitos testes não fossem executados (apenas o que se entendia

como prioritário era testado). O resultado disso foi um número elevado de correções nos

sistemas operacionais Windows, Linux, Mac OS, entre outros. Com o surgimento da Web,

novas considerações de testes foram necessárias, pois as aplicações passaram a ser executadas

em navegadores, sendo necessário testar várias versões e em diversos tipos de PC possíveis

(MOLINARI, 2008).

Conforme Pfleeger (2004), assim como os fabricantes buscam garantir a qualidade dos

produtos que produzem, os engenheiros de software também procuram formas e métodos que

asseguram a qualidade dos softwares desenvolvidos, tornando-os aceitáveis para seus

usuários.

Documentar o que deve ser testado é uma difícil etapa do teste de software, pois é

necessário identificar o que é desejado e até onde deve ser testado, e isso deve ser feito antes

da execução dos testes. Para Molinari (2008) há essa dificuldade, e essa etapa se chama

elaboração de requisitos de teste. Em várias situações, a especificação de o que deve ser

testado está espalhada em vários documentos, ou ainda apenas na cabeça dos testadores, ou

seja, os testes são feitos apenas com a experiência daqueles que testam.

Segundo Barbosa e Torres (2012), teste de software é uma das atividades que busca

contribuir para a melhoria da qualidade do software. O teste revela a presença de defeitos no

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

12 software e atende as exigências de qualidade de software que estão se tornando cada vez

maiores, devido ao crescimento do número de usuários que desejam softwares confiáveis e

eficientes.

Segundo Pfleeger (2004), um bom planejamento de teste ajuda a realizar os testes de

forma adequada. Um plano de teste envolve os objetivos do teste e visa garantir que o

software a ser testado funcione corretamente. Para isso, o plano de teste descreve o que,

quando e como será feito o teste, e ainda quais são os resultados esperados deste. Nesse

trabalho, um script de teste se assemelha ao plano de testes, pois envolve esse processo de

definição de o que, quando e como os testes serão executados.

Com a intenção de executar os testes de forma rápida e organizada, muitas empresas

utilizam scripts no seu processo de teste. Um script de teste é um documento onde há um ou

mais itens desse script. Esse script servirá de base para que os testadores, ao executarem seus

testes, utilizem cada item desse script, ou seja, em cada item de script estará descrito

exatamente o que deve ser testado (MOLINARI, 2010).

1.1 Motivação

Muitas empresas de desenvolvimento de software enfrentam dificuldades no setor de

teste. Isso se deve a muitos fatores, que serviram de motivação para o desenvolvimento deste

trabalho. Dentre os principais problemas encontrados, pode-se citar:

• Muitos testes são feitos com base apenas na experiência do testador;

• Há falta de documentação do que deve ser testado;

• Há falta de documentação do que foi testado;

• Quando ocorre uma alteração não é possível saber a dimensão imediata do que será

afetado (rastreabilidade).

1.2 Objetivos gerais

Com o objetivo de possibilitar aos profissionais de teste de software um

gerenciamento mais detalhado sobre seus testes, e que a execução dos testes seja feita de

forma organizada. A proposta descrita nesse documento permitirá a geração de scripts de

teste, baseando-se em informações previamente cadastradas, tais como a aplicação que será

testada, o módulo e a tela onde foi feita a alteração, a própria alteração, e também diversos

itens que terão que ser testados. Cada alteração terá uma importância e, combinando essas

informações, é que o script de teste será gerado a cada nova alteração. Após o script ser

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

13 gerado, ele poderá ser utilizado nos testes para que, mesmo um testador não muito experiente,

possa executá-los seguindo a sequência dos itens do script. Outra possibilidade será a emissão

de relatórios e gráficos, onde também será possível obter diversas informações, como por

exemplo, os erros mais recorrentes, as telas ou módulos mais críticos (onde ocorrem mais

problemas), entre outros.

1.3 Objetivos específicos

Os objetivos específicos foram definidos baseados nos problemas identificados no

item 1.1 deste trabalho. Desta forma, foram definidos os seguintes objetivos:

• Auxiliar na documentação do que deve ser e do que foi testado;

• Auxiliar a executar os testes de forma organizada;

• Possibilitar um gerenciamento mais detalhado sobre os testes (emissão de relatórios e

gráficos);

• Diminuir a dependência da experiência de um analista para execução de teste.

Especificamente a ferramenta terá as seguintes funcionalidades:

• Geração de scripts de teste com diversos itens a serem testados;

• Cadastramento de aplicações, módulos, telas e ações;

• Cadastramento de itens de script (itens que serão testados);

• Registros de alterações e a importância das mesmas;

• Relatório de alterações: relatórios que mostrem quais aplicações, módulos e/ou

telas que sofrem mais alterações;

• Relatório de itens: relatórios que mostrem os itens de script mais reprovados;

1.4 Organização do trabalho

Este documento está dividido em capítulos conforme a seguinte sequência: no capítulo

2 será apresentada a fundamentação teórica, envolvendo conceitos de teste de software,

técnicas de teste, fases de teste, abordagens de teste de integração, conceitos de verificação e

validação, e automação de teste. O capítulo 3 descreve as ferramentas de apoio aos testes de

software já existentes, suas funcionalidades e alguns screenshots das mesmas. No capítulo 4

será apresentado o desenvolvimento do projeto, com uma descrição detalhada do que foi

desenvolvido no trabalho e também algumas telas. Por fim, o capítulo 5 apresenta as

considerações finais sobre o desenvolvimento do trabalho.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

14

2 ESTADO DA ARTE

Neste capítulo será apresentada uma revisão geral do estado da arte, as técnicas e as

fases de um processo de teste de software. Nas técnicas de teste será enfatizado o teste

funcional, teste estrutural e teste baseado em erros. No que se refere às fases de teste, diversas

fases serão detalhadas, com destaque para a fase de teste de integração, que ainda será

dividida em diversas abordagens: bottom-up, top-down, big-bang e sanduíche. As atividades

de Verificação e Validação também serão estudadas nesse capítulo. Outro assunto que será

abordado será a automação de testes, onde serão detalhados alguns tipos de ferramentas para a

automação de teste de software.

2.1 Verificação e Validação

A atividade de teste pode ser composta por dois processos distintos: verificação e

validação. Esses processos são conhecidos como V&V e, embora possam parecer a mesma

coisa, existe uma diferença entre eles. Verificação se destina a mostrar que o projeto do

software atende a sua especificação, enquanto que validação se destina a mostrar que o

software realiza exatamente o que o usuário espera que ele faça. O objetivo principal do

processo de V&V é estabelecer confiança de que o sistema de software está adequado ao seu

propósito. O nível de confiabilidade exigido depende de fatores como função do software,

expectativas do usuário, ambiente e mercado (TERRA e BIGONHA, 2008).

Segundo Sommerville (2007), existem duas abordagens complementares para a

verificação e validação do sistema:

• Inspeções de software: é analisado e verificado representações de software

como documentos de requisitos, diagramas de projeto e código fonte do

programa. Pode-se usar inspeções em todos os estágios do processo. Essas

inspeções podem ser suplementadas por alguma análise automática de texto

fonte um sistema ou de documentos associados. Inspeções de software e

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

15

• análises automatizadas são técnicas de V&V estáticas, quando não se precisa

executar o software em um computador;

• Testes de software: envolvem executar uma implementação do software com

dados de teste para examinar as saídas e o comportamento operacional e assim

verificar se o desempenho está conforme o necessário. O teste é uma técnica

dinâmica de validação e verificação.

Em resumo, Sommerville (2007) define os processos de validação e verificação da

seguinte forma:

• Validação: Estamos construindo o produto correto?

• Verificação: Estamos construindo o produto corretamente?

2.2 Teste de software

Para um melhor entendimento sobre teste de software, que está diretamente ligado a

este trabalho, na sequência será apresentada uma revisão sobre a engenharia de software, a

qual o teste faz parte.

Segundo Tonsig (2008) a engenharia de software deveria seguir o exemplo da

engenharia de uma bicicleta, que quando chega ao seu cliente final em uma caixa, pode, com

o auxilio de um manual, ser facilmente montada com total segurança. Com essa comparação,

o autor quer dizer que a engenharia de uma bicicleta evoluiu, e pode ser considerada fácil para

montar e também para se utilizar, e ainda de uma forma confiável. Através da engenharia, o

software pode ser desenvolvido para atender as necessidades do usuário de uma forma cada

vez mais fácil, confiável, eficiente e economicamente viável. Além disso, a engenharia de

software permite especificar, projetar, implementar, manter sistemas de software e, através

dos testes, garantir a qualidade dos mesmos.

Teste é uma parte importante que compõe a QA (Quality Assurance ou Garantia de

Qualidade). Em teste de software, fala-se em SQA (Software Quality Assurance ou Garantia

da Qualidade de Software). Segundo Molinari (2008), SQA é composto por vários elementos,

como a gerência de configuração, que é responsável pela gerência, controle e registro dos

artefatos que compõe o software, incluindo todo o histórico da mudança do software em si.

Outro elemento que compõe a SQA é a gerência de requisitos, que diz respeito à gerência,

controle e registro das necessidades do sistema (requisitos) e dos usuários em todos os níveis,

incluindo a rastreabilidade das necessidades e da sua mudança. O último elemento que faz

parte do SQA, ainda segundo Molinari (2008), são os próprios testes, que correspondem à

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

16 gerência, planejamento, controle e execução dos testes em todos os níveis, de modo a garantir

a implementação (projeto, desenvolvimento e entrega) das necessidades especificadas.

Segundo Molinari (2010), há diversos conceitos pertinentes a testes, conforme mostra

a Tabela 1.

Tabela 1 - Conceitos de Teste de Software

Conceito Definição Plano de testes É o resultado do processo de planejamento dos testes. É composto por requisitos de testes,

casos de testes, e cenários de testes a serem utilizados nos testes.

Requisito de testes São requisitos específicos de testes. Representam o que deve-se testar em termos de meta.

Tipo de teste São os tipos de testes realizados em um ambiente qualquer, tais como teste funcional, de desempenho e de segurança.

Caso de teste Conhecido também como teste. É o que deve ser testado em termos de situação de teste em si. Desdobramento natural dos requisitos de testes, mas para existir ou ser criado, não precisa destes. Um caso de teste pode atender a mais de um requisito de teste.

Script ou script de teste

É conhecido também como “script de automação” ou “script automatizado”. Conjunto de ações que são executadas em uma ferramenta de automação de execução de testes automatizados. Representa em geral uma automação de um ou mais casos de teste.

Cenário de teste É um conjunto de casos de teste, ou de scripts, a serem executados em uma ordem qualquer com o intuito de caracterizar uma grande situação de teste. Exemplo: executa-se o primeiro script Z3, depois o Z1 e ao final executa-se o script Z2.

Relatório de teste É o relatório com informações dos testes.

Defeito Não conformidade encontrada na aplicação. Por exemplo, um requisito que foi implementado e não funciona corretamente.

Bug ou falha Problema encontrado na aplicação e que não está ligado a algum defeito. É algo não previsto. É natural que todo bug vire depois um defeito no sistema.

Fonte: adaptado de Molinari (2010, p. 38)

A engenharia de software está inserida em uma área de conhecimento da computação,

onde o resultado final é a organização, produtividade e qualidade no desenvolvimento de

software. Dentro da engenharia de software existem várias etapas a serem cumpridas durante

o desenvolvimento de um sistema, tais como levantamento de requisitos, projeto,

desenvolvimento, testes, implantação, entre outras (ENGENHARIA DE SOFTWARE, 2010).

A atividade de teste é composta por uma análise dinâmica do produto e uma atividade

para a identificação e eliminação de erros que persistem. As informações originadas das

atividades de teste são importantes para as atividades de depuração, manutenção e estimativa

de confiabilidade de software. A atividade de teste tem sido apontada como uma das mais

onerosas no desenvolvimento de software. O teste de software envolve basicamente as

seguintes etapas: planejamento de testes, projeto de casos de teste, execução e avaliação dos

resultados dos testes (MALDONADO, BARBOSA, et al., 2004).

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

17

Em geral, em teste de software pode-se estabelecer três técnicas distintas: a funcional,

a estrutural e a baseada em erros. Na técnica funcional, os critérios e requisitos de teste são

estabelecidos a partir da função de especificação do software; na técnica estrutural, os

critérios e requisitos são baseados nas características de uma implementação; e, na técnica

baseada em erros, os critérios e requisitos de teste são originam-se do conhecimento sobre

erros conhecidos cometidos no processo de desenvolvimento de software (MALDONADO,

BARBOSA, et al., 2004).

O teste faz parte de um processo dentro da engenharia de software, assim como outros

processos, como levantamento de requisitos, projeto e desenvolvimento. Para Molinari

(2008), os testes e a qualidade de software estão situados dentro da engenharia de software

conforme mostrado na Figura 1.

Figura 1 - Testes na Engenharia de Software

Fonte: adaptado de Molinari (2008, p. 27)

2.2.1 Técnicas de teste

Inúmeros projetos de software possuem pouco tempo para realização dos testes. É

necessário um bom planejamento para que se consiga entregar um produto com qualidade e

no prazo estipulado. Para que esses processos sejam realizados com eficiência, será necessário

a utilização das técnicas de teste de software (DEVMEDIA, 2008).

No que diz respeito às técnicas de teste, Maldonado, Barbosa, et al. (2004) destaca três

principais técnicas:

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

18 2.2.1.1 Teste funcional

Essa técnica também é conhecida como teste de caixa preta, pois trata o software

como sendo uma caixa, sem saber do conteúdo. Só é possível visualizar o lado externo, ou

seja, apenas se tem o conhecimento dos dados de entrada e os resultados produzidos na saída,

não sendo possível acompanhar o processamento interno no código fonte. Nos testes

funcionais, não há preocupação com os detalhes da implementação, pois apenas as funções do

sistema é que são verificadas (MALDONADO, BARBOSA, et al., 2004).

Nos testes funcionais, o foco é testar todos os componentes essenciais de um sistema

sob o ponto de vista funcional, ou seja, testar as funções de software ou de um componente de

software. Teste funcional tem por objetivo medir a qualidade funcional dos componentes de

um sistema. O objetivo também é assegurar a funcionalidade do sistema, incluindo entrada de

dados, processamento e resposta (MOLINARI, 2008).

Em outras palavras, o objetivo é determinar se o programa satisfaz aos requisitos

funcionais e não-funcionais que foram especificados antes da implementação. O problema é

que, em geral, a especificação existente é informal. Sendo assim, a determinação da cobertura

total da especificação que foi obtida por um conjunto de casos de teste também é informal. No

entanto, os critérios de teste baseados em especificação podem ser utilizados em qualquer

contexto (procedimental ou orientado a objetos) e em qualquer fase de teste sem a

necessidade de modificação (MALDONADO, BARBOSA, et al., 2004).

Para Molinari (2008), teste funcional é o mais importante teste, pois ele se caracteriza

por mostrar se a aplicação funciona ou não, de acordo com o que ela se propõe a atender em

termos de funcionalidades.

2.2.1.2 Teste estrutural

Para executar um teste estrutural é preciso conhecer a estrutura do sistema todo, para

se projetar testes que exercitem todas as partes. Essa técnica de teste pode ajudar na execução

de cada declaração pelo menos uma vez. O teste de caminho é uma estratégia de teste

estrutural, e seu objetivo é garantir que cada caminho independente seja executado pelo

menos uma vez (SOMMERVILLE, 2007).

Também conhecida como teste de caixa branca, a técnica de teste estrutural apresenta

limitações e desvantagens (decorrentes dessas limitações). Sérios problemas podem ser

identificados na automatização do processo de validação de software. Independentemente

dessas desvantagens, essa técnica é vista como complementar a técnica funcional e

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

19 informações obtidas pela aplicação desses critérios são importantes para as atividades de

manutenção, depuração e confiabilidade de software. Na técnica de teste estrutural, os

aspectos relativos a implementação são fundamentais na definição dos casos de teste. O teste

estrutural baseia-se no conhecimento da estrutura interna da implementação (MALDONADO,

BARBOSA, et al., 2004).

2.2.1.3 Teste baseado em erros

No teste baseado em erros os critérios e requisitos de teste originam-se do

conhecimento sobre erros comuns, cometidos no processo de desenvolvimento de software.

Essa técnica utiliza informações sobre os tipos de erros mais frequentes no processo de

desenvolvimento de software para derivar os requisitos de teste. Os testes são focados nos

erros que o programador ou projetista pode cometer durante o processo de desenvolvimento e

nas abordagens que podem ser usadas para detectar a ocorrência desses erros

(MALDONADO, BARBOSA, et al., 2004).

2.2.2 Fases de teste

Maldonado, Barbosa, et al. (2004), Pfleeger (2004) e Sommerville (2007), concordam

sobre algumas atividades de teste de software. Para todos esses autores, os testes podem ser

divididos nas seguintes fases:

• Teste de módulo, componente ou unidade: concentra esforços na menor

unidade do projeto de software. Cada componente do programa é testado,

isolado dos outros componentes do sistema. O teste de unidade verifica se cada

componente está funcionando corretamente, considerando os tipos de entrada

esperadas. Sempre que possível, esse tipo de teste deve ser feito em um

ambiente controlado, de modo que a equipe de teste, que pode ser composta

pelos próprios desenvolvedores, possa fornecer ao componente a ser testado

um conjunto de dados predeterminado, e a observar quais ações e dados são

produzidos. Além disso, nesse tipo de teste são verificadas as estruturas de

dados interna, a lógica e as condições limite para os dados de entrada e saída;

• Teste de integração: atividade sistemática utilizada durante a integração da

estrutura do software, tentando localizar erros associados às interfaces entre os

módulos; o objetivo é assegurar que foi dado a devida atenção as interfaces

entre os componentes. O teste de integração é executado após se estar

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

20

convencido de que os componentes individuais estão funcionando. Testar a

integração é o processo de verificar se os componentes do sistema, juntos,

trabalham conforme está descrito nas especificações do sistema e do projeto do

programa;

• Teste de sistema: é realizado após a integração do sistema e visa a identificar

erros de funções e características de desempenho que não estejam de acordo

com a especificação. O teste de sistema envolve a integração de dois ou mais

componentes que implementam funções ou características do sistema e depois

o teste desse sistema integrado;

Pfleeger (2004) e Sommerville (2007) destacam ainda as seguintes fases de teste:

• Teste de desempenho: esse teste compara o sistema com o restante dos

requisitos de software e hardware. Tem por objetivo assegurar que o sistema

possa operar com a carga necessária. Nesse tipo de teste geralmente a carga de

dados é elevada até que o desempenho torne-se inaceitável. Em cima disso é

feito uma análise, comparando a situação do teste com a possível situação real

do cliente. Quando o teste é realizado com sucesso em um ambiente de

trabalho real do cliente, ele produz um sistema válido;

• Teste de aceitação: os testes são feitos em novas versões que serão liberadas

para os usuários e, por isso, o teste de aceitação também é chamado de teste de

release. Esse teste é realizado em conjunto com os clientes, e tem por objetivo

conferir se o sistema está de acordo com o que foi solicitado. Além disso,

também é feito uma comparação entre o que foi desenvolvido e a descrição dos

requisitos do cliente. Após esse teste, o sistema pode então ser instalado no

ambiente em que será utilizado. Esse tipo de teste concentra-se em validar se o

que foi feito atende aos requisitos e se está confiável;

Muitos testes são feitos antes da liberação do sistema para o cliente, confiando que ele

funcione apropriadamente. Alguns testes dependem do que está sendo testado: componentes,

grupos de componentes, subsistemas, ou todo o sistema. Outros testes dependem do que se

quer saber: o sistema está funcionando de acordo com o projeto? De acordo com os

requisitos? E com as expectativas do cliente? Pfleeger (2004) destaca também o teste de

instalação como fase de teste. Esse teste é executado no cliente após a instalação definitiva do

sistema, e tem por objetivo assegurar que o sistema está funcionando como devido.

Segundo Sommerville (2007), ainda há o teste de interface, que concentra-se,

principalmente, em testar se a interface do componente está de acordo com o que foi

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

21 especificado. O teste de interface é particularmente importante para o desenvolvimento

orientado a objetos e baseado em componentes.

Com o objetivo de criar vários casos de teste para descobrir defeitos do programa e

comprovar que o sistema está de acordo com os requisitos, Sommerville (2007) destaca, além

das citadas anteriormente, algumas outras fases que podem ser utilizadas:

• Teste baseado em requisitos: os casos de teste são projetados para testarem os

requisitos do sistema. É uma das abordagens mais utilizada quando os

requisitos do sistema são implementados por vários componentes. Deve-se

identificar os casos de teste onde se possa demonstrar que o sistema atende aos

requisitos;

• Teste de partições: são identificadas partições1 de entrada e de saída do

sistema. Depois são projetados os testes para que o sistema processe as

entradas e gere as saídas em todas as partições.

2.2.3 Abordagens de teste de integração

Ainda sobre teste de integração, pode-se citar algumas abordagens de teste. Para

melhor ilustrar essas abordagens, a Figura 2 ilustra a hierarquia de um sistema, e essa

estrutura servirá de base para cada uma das abordagens explicadas a seguir:

Figura 2 - Estrutura para abordagens de teste de integração

Fonte: adaptado de Pfleeger (2004, p. 291)

2.2.3.1 Integração bottom-up

Segundo Pfleeger (2004), nessa abordagem os componentes são integrados, com o

objetivo de testar o sistema maior. Dessa forma, cada componente no nível inferior da

hierarquia do sistema é testado individualmente. Os próximos componentes a serem testados

1 Partições são grupos de dados com características em comum, como números negativos, todos os nomes com menos de 30 caracteres, todos os eventos que surgem pela escolha de itens de um menu, etc.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

22 são aqueles que “chamam” os que foram previamente testados. Esse teste se repete até que

todos os componentes sejam testados. A Figura 3 ilustra a sequência dos testes bottom-up,

baseando-se na estrutura da Figura 2.

Figura 3 - Sequência de testes bottom-up


Conforme Figura 3, primeiramente são testados os níveis inferiores: E, F e G. Como

não há componentes prontos para chamar os programas em um nível inferior, é necessário

criar códigos especiais para auxiliarem na integração.

Um fator negativo para a abordagem bottom-up é que os componentes do nível

superior, que geralmente são os mais importantes por coordenarem as principais atividades do

sistema, são sempre os últimos à serem testados.

2.2.3.2 Integração top-down

Nessa abordagem os testes começam justamente pelo lado oposto em relação ao

bottom-up, ou seja, no top-down os testes começam pelo nível superior. A Figura 4 mostra

que, baseando-se na estrutura da Figura 1, primeiramente são feitos os testes no componente

A (nível 1). Após, são incluídos os testes dos componentes B, C e D (nível 2) e, somente

então são incluídos os testes dos componentes E, F e G (nível 3) (PFLEEGER, 2004).

Figura 4 - Sequência de testes top-down


BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

23 2.2.3.3 Integração big-bang

Para Myers (1979) apud Pfleeger (2004), quando todos os componentes são testados

isoladamente, é tentador reuni-los no sistema final e verificar se ele funciona na primeira vez.

A Figura 5 mostra a sequência de testes utilizando a abordagem big-bang.

Figura 5 - Sequência de testes big-bang


Como nessa abordagem todos os componentes são reunidos de uma vez, é difícil saber

a causa de uma falha. Por isso, o método big-bang não é recomendado para nenhum sistema,

porém, ele ainda é utilizado em sistemas pequenos.

2.2.3.4 Integração ‘sanduíche’

A integração ‘sanduíche’ engloba um pouco da abordagem top-down e também um

pouco da abordagem bottom-up. O sistema é visto como três camadas, como um sanduíche:

uma camada alvo no meio, os níveis acima do alvo e os níveis abaixo do alvo. A abordagem

top-down é utilizada na camada superior e a abordagem bottom-up é utilizada na camada

inferior. Contudo, a integração sanduíche consiste em executar os testes em grupos parciais

ou em blocos. Sendo assim, os testes menores são reunidos em grupos intermediários, e em

um segundo momento unifica-se tudo novamente. A Figura 6 ilustra a sequência dos testes

utilizando a abordagem ‘sanduíche’ (MYERS, 1979) apud (PFLEEGER, 2004).

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

24 Figura 6 - Sequência de testes ‘sanduíche’


Na estrutura de exemplo Figura 2, a camada alvo seria o nível onde estão os

componentes B, C e D.

2.3 Automação de testes

Segundo Graham e Fewster (1999) apud Molinari (2010), existe uma diferença entre

testes e automação de testes. No primeiro é realizada a tarefa de testar, e no segundo é

utilizado um software que imita a interação com a aplicação no que se refere ao teste, tal qual

um ser humano faria (com algumas limitações). Ou seja, o software automatizará o teste que

se deseja fazer.

Segundo Molinari (2008), a automação de testes ganhou muita importância,

principalmente pelo crescimento dos sistemas e aplicações, e pelo aumento da complexidade

desses sistemas. Para atender a essas demandas deve-se utilizar ferramentas de automação de

testes. Existem ferramentas simples para auxiliar nos testes, porém, algumas são complexas e

possuem linguagens internas próprias para realizar os testes, exigindo que, quem for utilizá-la,

terá que entender de programação e lógica de programação.

Para Sommerville (2007), as ferramentas de teste de software estão entre as primeiras

ferramentas de software a serem desenvolvidas. O uso dessas ferramentas pode diminuir os

custos de teste. Na automação pode-se fazer um workbench de testes de software, que é um

conjunto integrado de ferramentas de apoio ao processo de teste. Em um workbench podem

ser utilizadas ferramentas para simular outras partes do sistema, com o objetivo de gerar

dados de teste. Dentre as ferramentas que podem ser incluídas nesse processo, pode-se citar:

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

25

• Gerenciador de testes: gerencia a execução de testes de programa, e ainda

mantém o acompanhamento desses dados, resultados esperados e recursos de

programa testados;

• Gerador de dados de teste: gera os dados de teste para o programa a ser testado.

Essa geração pode ser feita com a seleção de dados de um banco de dados ou

utilizando padrões para gerar dados aleatórios de maneira correta;

• Oráculo: gera previsões de resultado de teste esperados. Podem ser versões

anteriores ou protótipos do sistema;

• Comparador de arquivos: compara os resultados dos testes de programa com os

resultados dos testes anteriores e relata a diferença entre elas. São usados para

fazer testes de regressão, onde são comparados resultados de testes de

diferentes versões;

• Gerador de relatórios: fornece recursos para geração de relatórios para os

resultados de teste;

• Analisador dinâmico: adiciona código ao programa para contar o número de

vezes que uma declaração de programa foi executada. Após, um perfil de

execução é gerado para mostrar quantas vezes cada declaração foi executada.

2.3.1 Ferramentas para análise de código

Segundo Pfleeger (2004), há duas categorias de ferramentas para análise de código:

análise estática (é realizada quando o programa não está sendo executado) e a análise

dinâmica (é feita quando o programa está sendo executado). Cada tipo de ferramenta fornece

informações sobre o código em si ou sobre o caso de teste que está sendo executado.

Na análise estática há diversas ferramentas que podem analisar um código-fonte antes

que ele seja executado. As ferramentas que investigam a correção de um programa ou do

conjunto de componentes podem ser agrupadas em quatro tipos:

• Analisador de código: a sintaxe dos componentes é avaliada automaticamente.

Os comandos podem ser ressaltados se a sintaxe não estiver correta, se uma

construção pode apresentar defeitos, ou se um item não estiver definido;

• Verificadores de estrutura: é gerado um grafo dos componentes submetidos

como entrada. O grafo mostra o fluxo lógico, já a ferramenta verifica

problemas estruturais;

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

26

• Analisador de dados: avalia as estruturas de dados, as declarações de dados e

as interfaces entre os componentes, e registra os links impróprios entre os

componentes, definições de dados em conflito e uso ilegal de dados;

• Verificador de sequência: verifica as sequências dos eventos. Se a codificação

não estiver na sequência correta, os eventos são ressaltados.

Características estruturais e medições fazem parte das saídas das ferramentas

de análise estática.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

27

3 FERRAMENTAS DE APOIO AOS TESTES

Ao referir-se a gerência, refere-se também ao processo, ou seja, automatizar a gerência

de testes é também automatizar o processo de testes. Quando uma ferramenta de gerência de

testes é implantada, o processo existente na empresa é afetado direta ou indiretamente, ou, em

alguns casos, a empresa se adapta ao processo proposto pela ferramenta.

Neste capítulo serão apresentadas algumas ferramentas de teste de software, e em cada

ferramenta serão apresentados alguns screenshots para melhor ilustrá-las. As ferramentas que

serão apresentadas são as seguintes: Selenium, AutoTest, TestLink, JUnit, TestComplete,

Klaros TestManagement, Apache JMeter e Aqua.

3.1 Selenium

Segundo Molinari (2010), o Selenium é uma ferramenta multiplataforma de

automação de testes funcionais web, e faz parte de um pacote composto pelo Selenium IDE,

Selenium Remote Control e Selenium Grid.

O Selenium IDE é uma extensão de código aberto para o Firefox, e com ele pode-se

criar scripts de reprodução rápida de bugs e criar scripts para auxiliar no teste de automação.

Com o Selenium Remote Control é possível salvar em outras linguagens (tais como Ruby e

Java) o que já está gravado, além de poder alterar o que foi gravado, acrescentando loops,

funções e bibliotecas que venham a ser criados. O Selenium Remote Control foi substituído

pelo Selenium WebDriver, e com ele é possível criar casos de teste mais robustos, executar

testes de regressão, dimensionar e distribuir os scripts de teste entre vários ambientes,

executando os testes de forma coordenada (SELENIUM, 2012).

Com o Selenium pode-se gravar e reproduzir os testes, porém, para executar os testes

diretamente no browser (simulando a situação do usuário), deve-se utilizar o Selenium Core.

Sendo assim, para que essa extensão possa ser utilizada, é necessária a instalação remota no

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

28 servidor, e as páginas de teste devem estar hospedadas neste mesmo servidor

(TEXTEXPERT, 2007).

A Figura 7 mostra a tela do Selenium IDE. Nessa tela é possível criar os casos de

teste, detalhando cada instrução, e depois executar o teste de forma automática.

Figura 7 - Tela de execução dos casos de teste no Selenium

Fonte: adaptado de Selenium (2012)

3.2 AutoTest

Desenvolvido pela plataforma IBM Rational Functional Tester for Java and Web, o

framework AutoTest possui como característica principal a sua reutilização na automação de

teste funcional em diferentes projetos de desenvolvimento de software, visando a melhoria de

suas produtividade e qualidade, porém, oferece suporte somente à programação e a execução

de scripts de teste. Esse framework é formado por um conjunto de ferramentas de software,

scripts de teste, templates de planilhas, e regras e procedimentos de utilização que não mudam

em função de novos projetos.

A elaboração do AutoTest foi feita com base, principalmente, em uma técnica mista de

automação de teste, chamada de técnica keyword-data-driven. Para novos projetos de teste de

software, a infra-estrutura para sua automação já está montada. Assim, as atividades

específicas ainda necessárias para o novo projeto de teste em questão são: a elaboração das

planilhas de teste com os dados e procedimentos de teste; e a manutenção do framework,

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

29 incluindo a elaboração de novos scripts de teste que sejam necessários. A Figura 8 ilustra uma

planilha keyword-data-driven, onde está especificado o procedimento de teste que deve servir

de base durante a execução dos casos de teste. Ainda na Figura 8, na coluna ‘A’ estão as

palavras-chave, que serão interpretadas pelo AutoTest e então será executada uma ação de um

script (FANTINATO, DA CUNHA, et al., 2004).

Figura 8 - Planilha keyword-data-driven que servirá de base para o AutoTest

Fonte: adaptado de Fantinato, Da Cunha et al. (2004)

3.3 TestLink

O TestLink permite criar e gerir casos de teste, bem como organizá-los em planos de

teste. Estes planos permitem que o analista de teste priorize e atribua testes para os testadores

e, na medida em que os testes são executados, seus resultados são armazenados, gerando

relatórios em tempo real, e permitindo o acompanhamento do ciclo de teste como pode ser

observado na Figura 9. Essa ferramenta tem uma interface baseada na web sob a licença GPL

(General Public License). Ela utiliza a linguagem PHP e pode usar os SGBDs (Sistema

Gerenciador de Banco de Dados) MySQL, PostgreSQL ou MS-SQL Server. O TestLink

coopera com sistemas de rastreamento de bugs, tais como Bugzilla e Mantis, e o projeto é

mantido pela comunidade Open source (DE SOUZA e MENDES, 2011).

Segundo Molinari (2010), o foco principal do TestLink é controlar o ciclo de vida dos

testes: planejamento, execução e resultados.

Na sequência, a Figura 9 ilustra a tela de resultados dos testes no TestLink.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

Figura 9 - Tela de resultados do TestLink

Fonte: adaptado de Paloma Costa (2008)

3.4 JUnit

JUnit é um framework de código aberto utilizado para auxiliar no desenvolvimento de

códigos em Java, verificando se os resultados gerados pelos métodos são os esperados. Caso

não sejam, o JUnit exibe os possíveis erros que estão ocorrendo nos métodos

(WIKIDOT.COM, 2008).

Esse framework pode auxiliar quando uma bateria de testes é feita no código fonte de

um programa. Um desses testes é o teste de unidade que testa a menor parte

caso da linguagem Java esse teste é feito através do JUnit em cada método separadamente

(DE PAULA NETO, 2010).

3.5 TestComplete

Desenvolvida pela AutomatedQA, o TestComplete é uma ferramenta de automação de

testes de uso comercial. Um dos des

testes de sistemas desenvolvidos em Delphi. A ferramenta oferece recursos para automatizar

os testes, transformando as ações dos usuários em um

(playback) posteriormente. A arquitetura é baseada em

de Projeto. Por exemplo, se for preciso testar um web

de projeto chamado Web

(DEVMEDIA, 2009).

Após os testes serem aplicados, o TestComplete fornece os resultados desses testes em

forma de gráfico, conforme mostra a

Tela de resultados do TestLink

Paloma Costa (2008)





um programa. Um desses testes é o teste de unidade que testa a menor parte


(DE PAULA NETO, 2010).


testes de uso comercial. Um dos destaques do TestComplete é o suporte para a automação de


os testes, transformando as ações dos usuários em um script que pode ser reproduzido

. A arquitetura é baseada em plugins, e estes são chamados de Itens

de Projeto. Por exemplo, se for preciso testar um web service, será necessário adicionar o item

Services para poder usar essa funcionalidade, e assim por diante


forma de gráfico, conforme mostra a Figura 10.

30





um programa. Um desses testes é o teste de unidade que testa a menor parte do código e, no



taques do TestComplete é o suporte para a automação de


que pode ser reproduzido

, e estes são chamados de Itens

, será necessário adicionar o item

para poder usar essa funcionalidade, e assim por diante


BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

31 Figura 10 - Tela de resultado TestComplete

Fonte: adaptado de Dunstanthomas (2012)

3.6 Klaros TestManagement

Klaros Testmanagement é uma aplicação web baseada em Ajax para organizar e

gerenciar o processo de teste em projetos de desenvolvimento de software. Essa aplicação

suporta um gerente de teste em cada fase do ciclo de desenvolvimento de software e fornecer-

lhe as informações necessárias para o cumprimento das tarefas de teste. A Figura 11 mostra a

tela de resultado dos testes executados no Klaros TestManagement. Nessa tela é mostrada a

situação de cada caso de teste (área contornada e identificada com número 1) e a possibilidade

de ver mais detalhes desse caso de teste (área contornada e identificada com número 2)

(KLAROS TESTMANAGEMENT, 2008).

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

32 Figura 11 - Resultado dos testes no Klaros TestManagement

Fonte: adaptado de Gstatic (2009)

3.7 Apache JMeter

O Apache JMeter é uma aplicação desktop de fonte aberta e direcionada para Java.

Desenvolvido pelo grupo Apache, essa aplicação foi projetada para auxiliar nos testes

funcionais e de desempenho. Originalmente o Apache JMeter foi projetado para testar

aplicações web, mas acabou se expandindo para outras funções de teste, dentre elas, simular

uma carga pesada em um servidor de rede, e também fazer uma análise gráfica de

desempenho (APACHE, 2012).

A Figura 12 mostra a tela de criação das tarefas no Apache JMeter. Após criar essas

tarefas, elas podem ser executadas uma a uma.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

33 Figura 12 - Tela de criação de tarefas no Apache JMeter

Fonte: adaptado de John e Cailin (2008)

3.8 Aqua

Conforme Andagon (2009), com a ferramenta Aqua é possível gerenciar requisitos,

defeitos, testes e projetos de software. No caso do gerenciamento de testes, a execução dos

casos de teste pode ser manual ou automatizada (utilizando alguma outra ferramenta). A idéia

dessa ferramenta é que sejam previamente cadastradas as instruções de teste e o resultado

esperado após a execução dessa instrução. Após o teste ser executado, o resultado desse teste

pode ser registrado no Aqua. A Figura 13 mostra a tela onde há essa situação.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

34 Figura 13 - Tela de execução dos casos de teste no Aqua

Fonte: adaptado de Andagon (2009)

A partir dos casos de teste executados, é possível gerar os elementos de erros, e o

conjunto desses elementos será a base para a geração de relatórios. Na sequência, a Figura 14

mostra a tela do Aqua onde é possível ver os erros encontrados casos de teste (área

contornada e identificada com número 1). Nessa mesma tela é possível ver os casos de teste,

que são mostrados após o usuário clicar em Test Cases (área contornada e identificada com

número 2).

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

Figura 14 - Tela de visualização dos casos de teste no Aqua

Fonte: adaptado de Andagon (2009)

3.9 TestMaster

Segundo Sourceforge.net (2008)

teste, relatórios e ferramenta de automação de teste.

utiliza Apache como servidor web. F

de casos de teste a partir de documentos Word, arquivos CSV

além de entrada manual ou SQL

possível registrar algumas notas do testador

Aprovado ou Reprovado. Outra funcionalidade é a apresentação de estatísticas sobre os testes,

conforme mostra a Figura 15

Tela de visualização dos casos de teste no Aqua

Andagon (2009)

Sourceforge.net (2008) TestMaster é uma ferramenta para registro de caso de

teste, relatórios e ferramenta de automação de teste. Desenvolvido em

utiliza Apache como servidor web. Foi desenvolvida baseada em web e

de casos de teste a partir de documentos Word, arquivos CSV (Comma Separated Values

além de entrada manual ou SQL(Structured Query Language). No TestMaster também é

possível registrar algumas notas do testador referente ao que foi testado, além do estado:

Outra funcionalidade é a apresentação de estatísticas sobre os testes,

15.

35

TestMaster é uma ferramenta para registro de caso de

Desenvolvido em Perl, esta ferramenta

nvolvida baseada em web e permite importação

Comma Separated Values),

. No TestMaster também é

referente ao que foi testado, além do estado:

Outra funcionalidade é a apresentação de estatísticas sobre os testes,

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

Figura 15 - Tela de estatísticas do TestMaster

Fonte: adaptado de Sourceforge.net (2008)

3.10 Testipool

Conforme Majordojo (2008)

que um gerenciamento dos

de teste contém a lista mestre de todos os casos de teste para um determinado produto. No

entanto, para qualquer versão é

permite gerar vários relatórios de diferentes tipos de plano de teste,

bug, relatório de progresso, e relatório de taxa de falha,

permite importar e exportar planos de teste para formatos de arquivos CSV.

Tela de estatísticas do TestMaster

Sourceforge.net (2008)

Majordojo (2008), Testipool é um aplicativo escrito em PHP que permite

um gerenciamento dos planos de teste de controle de qualidade de software.


anto, para qualquer versão é possível executar todo e qualquer caso de teste.

relatórios de diferentes tipos de plano de teste, tais

relatório de progresso, e relatório de taxa de falha, entre outros. Esse aplicativo também


36

é um aplicativo escrito em PHP que permite

de software. Cada plano


executar todo e qualquer caso de teste. O Testitool

tais como: relatório de

Esse aplicativo também


BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

37 3.11 Comparativo entre ferramentas

Conforme apresentado, há diversas ferramentas para auxiliarem no processo de teste

de software, seja na documentação ou na execução dos testes. As ferramentas Selenium,

TestLink, TestComplete e Klaros TestManagement podem ser utilizadas para documentação

de testes, mas o foco principal dessas ferramentas é a execução dos testes automatizados. As

ferramentas AutoTest, JUnit e Apache JMeter são exclusivas para execução de testes

automatizados. Já as ferramentas Aqua, TestMaster e Testipool são de uso apenas para

documentação dos testes de software, ou seja, não executam testes automatizados. Na

sequência a Tabela 2 mostra um comparativo das ferramentas apresentadas.

Tabela 2 - Comparativo das ferramentas de teste de software

Ferramenta Plataforma de execução Aplicação Licença

Tipo de teste que a aplicação executa

Aqua Desktop Documentação de teste

Proprietário Apenas documentação

AutoTest Web Web GPL Funcional JMeter Desktop

Web e desktop

Apache Licence

Funcional e desempenho

JUnit Desktop Web e desktop Open Source Teste de unidade TestComplete Desktop Web e desktop Proprietário Testes funcionais Testipool Web Web Proprietário Apenas

documentação

TestLink Web Web GPL Testes funcionais TestManagement Desktop Web Proprietário Testes funcionais TestMaster Web Web GPL Apenas

documentação

Selenium Web Web Apache 2.0 Testes de regressão

Fonte: elaborada pelo autor

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

38

4 DESENVOLVIMENTO DA FERRAMENTA

Nesse trabalho de conclusão de curso foi desenvolvida uma ferramenta que pode

auxiliar profissionais da área de teste de software a efetuarem os testes, gerenciando os testes

de forma que seja possível gerar scripts de teste com seus respectivos itens. A ferramenta

desenvolvida foi nomeada Supporter Test, e é de caráter de documentação e mapeamento de

teste, ou seja, ela não será usada no teste propriamente dito. Após qualquer alteração em uma

aplicação, um novo script de teste será gerado, e então os testes serão executados baseados

nesse script. Em um setor de teste de software existem diversas funções distribuídas entre os

envolvidos, e uma dessas funções é a do analista de testes, que tem como suas principais

responsabilidades analisar as alterações feitas, identificar onde essas alterações impactam,

definir a importância de cada alteração, e então gerar o script de teste. Essas atividades são

desenvolvidas antes da execução dos testes, por isso são chamadas de pré-teste. A Figura 16

ilustra os casos de uso de um analista de testes.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

39 Figura 16 - Casos de uso do analista de testes


Outro usuário da ferramenta Supporter Test será o testador, que terá a função, baseado

no script gerado pelo analista, de executar os testes. Após a execução dos testes, o testador irá

registrar um parecer em cada item de teste executado, e então poderão ser emitidos diversos

relatórios. Como essas ações são feitas após a execução do teste, podem ser chamadas de pós-

teste. A Figura 17 mostra os casos de uso de um testador.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

40 Figura 17 - Casos de uso do testador


A ferramenta Supporter Test não será utilizada para executar os testes, mas sim para

documentá-los. Por isso, pode-se dizer que ela será utilizada apenas nas fases de Pré e Pós-

teste. Como o teste será executado (se manual ou com o auxílio de uma ferramenta de

automação) não faz diferença para a utilização desta ferramenta. Na Figura 18 é possível

identificar o fluxo de teste, com as fases de Pré e Pós-teste, e também o próprio Teste.

Figura 18 - Fluxograma da ferramenta desenvolvida


O Quadro 1 ilustra um exemplo da estrutura de um script, onde é possível identificar o

código da alteração no sistema, a importância dessa alteração, o código do script

(normalmente será o mesmo da alteração, já que para cada alteração será gerado um script de

teste) e os itens do script. Essa estrutura mostra como seria se o script fosse armazenado em

um formulário.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

41 Quadro 1 - Exemplo de script

Alteração: 3459 Importância: 5 Script: 3459 Itens do script

1 Informar dados inválidos nos campos de entrada de dados 2 Importar pedido 3 Importar ordem de serviço


4.1 Requisitos funcionais, requisitos não funcionais e modelo ER

Para o desenvolvimento da ferramenta Supporter Test, foram levantados diversos

requisitos funcionais, conforme mostra a Tabela 3.

Tabela 3 - Requisitos funcionais

ID Requisito Detalhamento Prioridade RF001 Manter alterações Deve ser possível registrar as alterações feitas na

aplicação. Obrigatório

RF002 Manter cadastro de aplicações

Considerando que a ferramenta proposta poderá atender o gerenciamento de testes de diversos sistemas, é necessário um controle por aplicação.

Obrigatório

RF003 Manter cadastro de módulos

Uma aplicação poderá ser dividida em diversos módulos (por exemplo, faturamento, contas a pagar, estoque, entre outros), portanto, deve ser possível cadastrar esses módulos para que seja possível identificar uma alteração na aplicação a ser testada.

Obrigatório

RF004 Manter cadastro de telas

Para que se saiba exatamente onde a alteração foi feita, é necessário registrar qual a aplicação, o módulo e a tela de tal alteração. Por isso, deve haver um cadastro de telas.

Obrigatório

RF005 Manter cadastro de ações

As ações são executadas a partir de uma tela, por isso, é necessário um cadastro de ações.

Obrigatório

RF006 Manter scripts Os scripts serão gerados logo após o desenvolvimento de uma alteração, ou seja, antes de começar os testes. O script deve ser identificado por uma situação ("Aberto", "Em testes", "Concluído" ou "Fechado").

Obrigatório

RF007 Manter itens de script

Um ou mais itens de teste irão compor um script de teste. Ao executar os testes baseados em um script, o testador irá registrar um parecer para cada item desse script.

Obrigatório

RF008 Relatório de alterações

Deve ser possível imprimir relatórios que mostrem quais as aplicações, os módulos e/ou as telas que sofrem mais alterações.

Obrigatório

RF009 Relatório de itens de script

Deve ser possível imprimir relatórios que mostrem os itens de script mais reprovados.

Obrigatório

RF010 Visualização de estatísticas em gráficos

Deve ser possível visualizar estatísticas em gráficos. Dentre as estatísticas estão: itens de teste reprovados; módulos com mais reprovações; telas com mais reprovações.

Importante

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

42 RF011 Registro de um

parecer em cada item de script

Deve ser possível registrar um parecer para cada item do script. Esse parecer será registrado após o teste de tal item do script.

Obrigatório

RF012 Permitir alterar situação de um item de script

Um item de script deverá ter controle por situação, podendo ser: Aguardando, Aprovado ou Reprovado.

Obrigatório

RF013 Exportação do script gráfico no formato de imagem

Deve ser possível exportar o script gráfico com as ações anteriores e posteriores no formato de imagem (JPG ou PNG).

Desejável

RF014 Visualizar a rastreabilidade em modo texto

Deve ser possível visualizar as ações anteriores e posteriores de uma tela no formato texto, formando assim uma listagem dessas ações. Essa listagem deve separar as ações anteriores das posteriores.

Desejável


Além dos requisitos funcionais, também foram identificados os requisitos não

funcionais, os quais são apresentados na Tabela 4.

Tabela 4 - Requisitos não funcionais

ID Requisito Detalhamento Prioridade RNF001 Acesso por usuário

e senha O controle de acesso às telas deve ser por usuário e senha. Importante

RNF002 Backup automático Deve ter backup automático periodicamente. Deve ser possível configurar os horários dos backups.

Desejável

RNF003 Desenvolvimento em Java

O desenvolvimento do sistema deve ser na linguagem de programação Java.

Desejável

RNF004 Banco de dados MySQL

O SGBD deve ser MySql. Desejável


O modelo ER (Entidade Relacionamento) do banco de dados demonstra todas as

tabelas necessárias para o desenvolvimento da Supporter Test, além das ligações entre as

tabelas, identificando os tipos de relacionamento entre as mesmas. Na sequência, a Figura 19

mostra o modelo ER do banco de dados.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

43 Figura 19 - Modelo ER do banco de dados


As tabelas Alteração, Script e Item são identificadas como as principais, sendo que as

principais informações serão armazenadas nelas. Logo, os relatórios serão baseados nessas

três tabelas, considerando que toda movimentação da ferramenta ocorre basicamente nessas

tabelas. As demais tabelas são de cadastro ou ligação entre as mesmas.

4.2 Cadastros gerais

Conforme requisitos levantados, a ideia é que, para cada alteração no sistema, uma

nova alteração seja criada na Supporter Test, e para que seja possível identificar onde

exatamente essa alteração foi feita, serão necessários os cadastros de aplicações, de módulos e

de telas. Ao criar uma alteração, o usuário que está criando (testador, analista de teste, gerente

de testes, ou outro) irá definir o nível de importância dessa alteração. Esse nível será em

números de 0 (zero) a 5 (cinco), sendo 0 para a alteração menos importante e 5 para a mais

importante. Esse nível de importância irá definir quais os itens de teste farão parte do script,

pois no cadastro de cada item também haverá um nível de prioridade. No caso de uma

alteração com importância nível 2, o script será composto por todos os itens cujo nível de

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

44 prioridade seja 2 ou menor, e cujo item faz parte da ação que a tela alterada poderá executar.

O cadastro de aplicações se justifica pelo fato de que as empresas ou pessoas que utilizarão a

ferramenta Supporter Test poderão manter mais de uma aplicação, ou seja, diversas

aplicações poderão ser mantidas ao mesmo tempo na ferramenta desenvolvida.

Dentro dessa aplicação poderá haver diversos módulos, e dentro desses módulos

haverá diversas telas. Por isso serão necessários, respectivamente, os cadastros de módulos e

de telas. Outro cadastro importante é o cadastro de ações, pois é a partir dessas ações que um

script de teste será criado. Uma ação pode ser lançamento no estoque, lançamento no contas a

receber, lançamento no caixa, entre outras. A tela de emissão de nota fiscal (que pertence ao

módulo faturamento) poderá executar, por exemplo, a ação de lançamento no caixa,

lançamento no estoque, lançamento no contas a receber, entre outras ações, no entanto, uma

ação poderá ser executada por diversas telas. Uma das ações originadas na emissão de nota

fiscal é a ação de lançamento no estoque, no entanto, essa ação também poderá ser executada

ao lançar uma nota de entrada no estoque (que pertence ao módulo estoque).

4.3 Scripts

A ferramenta Supporter Test também contará com scripts de teste, que serão gerados

antes dos testes serem executados, pois o teste será executado seguindo um script. Um script

será composto por diversos itens, e esses itens de teste poderão estar em diversos scripts. O

script pode ter uma das seguintes situações: Aberto, Em testes, Concluído, Fechado ou Re-

gerado.

O script cuja situação é Aberto significa que este está aberto, porém, nada foi feito

ainda, ou seja, nenhum teste foi feito baseado nesse script. A situação Em testes significa que

estão sendo feitos os testes desse script. Já um script Concluído significa que os testes foram

feitos, porém, algum item teve algum problema e terá que ser testado novamente após a

correção. A situação Fechado significa que todos os itens foram testados e estão corretos.

Sabendo que uma correção de um item reprovado pode causar algum erro em um item

aprovado anteriormente, um script que foi totalmente testado e possui pelo menos um item

reprovado, deve ser gerado novamente com todos os itens a serem testados. Nesse caso, a

situação do script original será Re-gerado.

No cadastro do item de teste também será definido o nível de prioridade desse item,

portanto, o nível de importância da alteração é um dos fatores que define se um item fará

parte de um script ou não. Após uma alteração feita, será gerado um script de teste baseado na

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

45 importância dessa alteração, portanto, supondo que os itens A, B, C, D e E tenham definidos

em seus cadastros, respectivamente, as prioridades 1, 2, 3, 4 e 5, ao gerar o script de teste,

será levado em consideração os itens de teste conforme mostrado no Quadro 2:

Quadro 2 - Nível de prioridade dos itens de teste

Nível de importância da alteração Itens a serem testados

5 Item A, Item B, Item C, Item D, Item E 4 Item A, Item B, Item C, Item D 3 Item A, Item B, Item C 2 Item A, Item B 1 Item A

Fonte: elaborado pelo autor

Considerando que em uma alteração só serão afetadas as ações que tal tela executa, a

ação da tela é outro fator que define se o item fará ou não parte do script. Em um item de teste

estará descrito o que deve-se fazer (por exemplo, informar valores inválidos), e qual o

objetivo deste item (por exemplo, não permitir gravar dados inválidos). Durante a execução

dos testes, um parecer poderá ser gravado em cada item do script e também uma situação

poderá ser definida: Aguardando, Aprovado ou Reprovado.

A rastreabilidade das ações executadas por uma tela, tanto ações principais, anteriores

e posteriores, além de ser visualizada em modo gráfico, também poderá ser visualizada em

forma de uma lista (modo texto), conforme ilustra o Quadro 3.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

46 Quadro 3 - Rastreabilidade das ações em modo texto

Tela: Emissão de nota fiscal

Ações principais:

Emitir Nota Fiscal

Importar pedidos

Importar ordens de serviço

Ações anteriores:

Cadastrar cliente

Cadastrar forma de pagamento

Cadastrar natureza fiscal

Cadastrar produto

Ações posteriores:

Lançar no caixa

Lançar no contas a receber

Lançar no estoque

Lançar no fiscal

Fonte: elaborado pelo autor

4.4 Especificação e telas

O sistema de gestão de testes de software tem o objetivo de auxiliar no gerenciamento

do setor de teste de software, possibilitando a geração de scripts de testes, para que, durante a

execução dos testes, esses scripts sirvam de base. Para um bom gerenciamento e tomadas de

decisão, também será possível emitir relatórios e gráficos, podendo esses serem detalhados

por aplicativo, módulo ou tela.

Na sequência, serão apresentadas as figuras representando algumas telas da ferramenta

Supporter Test.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

47 Figura 20 - Cadastro de Tela


A Figura 20 mostra a tela de Manutenção de Telas, onde é possível cadastrar novas

telas e manter as já existentes. No cadastro de tela é possível definir à qual módulo essa tela

pertence e também quais são as ações que essa tela poderá executar. As ações poderão ser da

própria tela, anteriores ou posteriores.

As alterações nos sistemas ocorrem em determinadas telas, e cada uma dessas telas

podem exercer diversas ações. Como exemplo, a Figura 20 ilustra o cadastro da tela Nota

fiscal, que pertence ao módulo Faturamento, que por sua vez pertence à aplicação Zada (área

contornada e identificada com número 1). Nesse exemplo também foram informadas as

possíveis ações da tela Nota fiscal e, dentre essas ações, são consideradas ações anteriores,

posteriores e principais da tela (área contornada e identificada com número 2).

Na Supporter Test é possível ver de uma forma prática quais são as possíveis ações de

uma determinada tela. Além disso, poderá se ter uma rastreabilidade de cada tela e suas

possíveis ações, sendo possível rapidamente identificar quais são as ações anteriores e as

ações posteriores de uma determinada tela.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

48 Figura 21 - Ações por Tela


Na Figura 21, pode-se perceber que são mostradas as ações anteriores, posteriores e da

própria tela, onde as ações anteriores são mostradas na grade de cor vermelha, as principais na

grade de cor branca e as posteriores na grade de cor verde. A principal funcionalidade desta

ferramenta é a rastreabilidade que se terá entre as telas e as ações de cada uma delas. Na

Figura 21, na parte onde há informações sobre uma determinada tela (área contornada e

identificada com número 1) a tela denominada Nota Fiscal está sendo mostrada, e isso faz

com que as informações dessa tela sejam carregadas logo abaixo (área contornada e

identificada com número 2). Percebe-se que nessa segunda parte há três colunas, onde há as

ações anteriores, posteriores e as próprias ações da tela. Baseando-se nesse exemplo, é

possível saber quais as ações da tela Nota Fiscal, onde essas ações irão impactar, e também as

ações possíveis que antecedem a emissão de uma nota fiscal.

Outro cadastro importante para a estrutura da Supporter Test é o cadastro das ações.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

49 Figura 22 - Manutenção de Ações


A Figura 22 mostra a tela de Manutenção de Ações, onde é possível cadastrar novas

ações, e ainda alterar ou excluir as já existentes. É possível identificar também algumas

informações iniciais como o código e a descrição da ação (área contornada e identificada com

número 1) e os itens que fazem parte dessa ação (área contornada e identificada com número

2). Nessa segunda parte, cada item é adicionado à ação e em cada item pode-se observar, além

do código e da descrição deste, também a prioridade, que será importante no momento da

geração do script. A geração do script será melhor explicada na sequência deste trabalho.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

50 Figura 23 - Manutenção de Alterações


Quando uma alteração ou uma implementação forem realizadas, essas devem ser

registradas, conforme mostra a Figura 23. Nesse registro deve constar a aplicação, o módulo e

a tela a qual se referem, a descrição do que foi alterado ou implementado, e principalmente a

importância que essa alteração ou implementação representa para a aplicação modificada.

Com essas informações, já é possível gerar um script, pois o script gerado baseia-se

justamente nessas informações. Uma vez que se sabe qual a tela onde foi efetuada a alteração

ou implementação, sabem-se quais as possíveis ações dessa tela e, sabendo-se as ações,

sabem-se os itens que terão que ser testados. O que ainda terá influência para definir quais os

itens farão parte do script é a importância, pois somente os itens que possuem prioridade

maior ou igual a importância da alteração é que serão levados para o script. Sendo assim, no

exemplo de uma alteração na tela de Nota fiscal, cuja importância seja 3 (três), somente itens

pertencentes às ações que a tela Nota fiscal exerce e que possuem prioridade 3, 4 ou 5 é que

serão levados para o script de teste.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

51 Figura 24 - Script


A Figura 24 mostra a tela de script, onde é possível identificar alguns dados de

cabeçalho, como o código e a situação do script, e também a aplicação, o módulo e a tela que

a alteração foi feita (área contornada e identificada com número 1). Além disso, também é

possível identificar os itens de script gerados (área contornada e identificada com número 2)

e, caso necessário, pode-se obter mais detalhes sobre a alteração clicando no atalho (área

contornada e identificada com número 3). No exemplo da Figura 24, alguns itens estão com a

situação Aguardando, outros estão com a situação Aprovado e outros estão com a situação

Reprovado (área contornada e identificada com número 7). Itens com a situação Aguardando

são aqueles que ainda não foram testados, itens com a situação Aprovado são aqueles que já

foram testados e não foi encontrado erro durante os testes, e itens com a situação Reprovado

são aqueles que já foram testados e algum problema foi encontrado. Além disso, a Figura 24

mostra que também é possível imprimir os dados da tela (área contornada e identificada com

número 4), além de executar o teste (área contornada e identificada com número 6) do item

selecionado. Ao clicar nesse botão para executar o teste abrirá uma nova tela, onde é possível

registrar um parecer sobre o item testado (conforme será mostrado na sequência na Figura

25). Além dessas funcionalidades, a tela mostrada na Figura 24 também pode re-gerar um

script (área contornada e identificada com número 5). Um script só pode ser re-gerado se

todos os itens forem testados e pelo menos um desses itens foi reprovado. Ao re-gerar um

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

52 script, um novo será gerado com os mesmos itens e todos esses itens com a situação

Aguardando. Esse novo script terá o mesmo código do anterior, porém, será um novo

sequencial.

Figura 25 - Execução do script


A Figura 25 mostra a tela que será utilizada durante a execução dos testes. Ela é aberta

após clicar no botão “Executar teste” mostrado na Figura 24 (área contornada e identificada

com número 6). Nessa tela há algumas informações sobre o item que está sendo testado, tais

como a ação que originou esse item, a descrição e o objetivo do teste desse item, sendo que

todas essas informações não são editáveis, ou seja, o usuário não poderá alterá-las. Após isso,

será possível alterar a situação (de Aguardando para Aprovado ou para Reprovado), registrar

um parecer para o item em questão (área contornada e identificada com número 2) e gravar.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

53 Figura 26 - Gráfico de itens reprovados por módulo


A Supporter Test permite a geração de alguns gráficos, tais como o gráfico de itens

reprovados por módulo, mostrado na Figura 26. Nesta figura pode-se perceber um gráfico do

tipo pizza (área contornada e identificada com número 2) e algumas informações no

cabeçalho (área contornada e identificada com número 1). Olhando para a Figura 26 sabe-se

que durante o mês de maio de 2013 (período de 01/05/2013 à 31/05/2013), dentre os itens de

script testados na aplicação Zada, 3 (três) foram reprovados e que desses, 33% (trinta e três

por cento) são do módulo Contabilidade e 67% (sessenta e sete por cento) são do módulo

Tabelas.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

54 Figura 27 - Gráfico de scripts por módulo


Outra possibilidade de geração de gráfico é mostrada na Figura 27. Esse exemplo

mostra um gráfico do tipo barras, e também são apresentados alguns dados de cabeçalho.

Com as informações deste exemplo, sabe-se que durante o mês de maio de 2013 (período de

01/05/2013 à 31/05/2013), 5 (cinco) scripts foram testados na aplicação Zada, dos quais 2

(dois) tiveram que ser re-gerados, pois tiveram pelo menos um de seus itens reprovado (essas

informações estão na área contornada e identificada com número 1). Olhando para o gráfico,

percebe-se que o módulo Contabilidade teve 2 (dois) scripts testados, dos quais 1 (um) teve

que ser re-gerado, e também que o módulo Tabelas teve 3 (três) scripts testados e, desses, 1

(um) teve que ser re-gerado. Esses números estão dispostos no topo de cada barra e,

observando a legenda, é possível concluir a que se refere cada número.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

55 Figura 28 - Relatório sintético de itens reprovados


Além da geração de gráficos, também é possível emitir relatórios, assim como mostra

a Figura 28. Esse exemplo mostra um cabeçalho (área contornada e identificada com número

1) com as informações da aplicação, do período e o total de itens reprovados nesse período. A

aplicação e o período são filtros informados no momento da geração do relatório. O corpo do

relatório (área contornada e identificada com número 2) apresenta os itens reprovados com

sua respectiva prioridade e também o percentual cada item reprovado representa em todos os

itens testados. Nesse exemplo, o percentual total de itens reprovados (8,82 %) é a comparação

do total de itens reprovados no período (3) com o total de itens testados no período (34).

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

56 Figura 29 - Relatório analítico de itens reprovados


Além da geração de relatórios sintéticos, com a ferramenta Supporter Test também é

possível gerar relatórios analíticos, que além de informações de itens reprovados (conforme

mostrado na Figura 28), mostra também quais os módulos que cada item foi reprovado. A

Figura 29 mostra um exemplo com as mesmas informações que a Figura 28, no entanto, no

corpo do relatório há um detalhamento para cada item (área contornada e identificada com

número 1), onde também é mostrada a quantidade de itens reprovados desse módulo e o

percentual que esses itens reprovados do módulo representam na quantidade de reprovações

do item em que está inserido. O tipo de relatório (sintético ou analítico) é determinado no

momento da geração.

Os relatórios apresentados na Figura 28 e na Figura 29 apresentam exemplos de

relatórios com foco nos itens de script, mostrando primeiramente os itens reprovados e, em

um segundo nível, os módulos que ocorreram tais reprovações. Além desses, também é

possível gerar relatórios com o foco nos módulos, ou seja, relatórios que apresentem os

primeiramente os módulos onde ocorreram as reprovações e, em cada módulo, o

detalhamento de quais foram os itens reprovados.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

57 Figura 30 - Relatório analítico de itens reprovados por módulo


A Figura 30 ilustra um exemplo de relatório analítico de itens reprovados por módulo.

Figura 31 - Relatório sintético de itens reprovados por módulo


O relatório de itens reprovados por módulo também pode ser gerado na forma

sintética, conforme mostra a Figura 31.

4.5 Validação e verificação do uso da ferramenta

Com a intenção de validar a ferramenta Supporter Test, criou-se um cenário de testes

onde 5 (cinco) profissionais que atuam em diferentes áreas no processo de desenvolvimento

de software utilizaram a ferramenta. Todos os participantes atuam em uma mesma empresa de

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

58 desenvolvimento de software, porém, executam diferentes tipos de teste no seu dia-a-dia,

conforme mostra a Tabela 5.

Tabela 5 - Participantes da avaliação da ferramenta


Antes dos participantes começarem a utilizar a ferramenta foi lhes passado uma breve

explicação sobre como o teste deve ser feito quando uma alteração é realizada em uma

aplicação (já que alguns dos participantes não são da área específica de testes). Nessa

explicação apenas foi passado que existe o script de teste, que esse script possui vários itens a

serem testados, e que, durante os testes, um parecer deve ser registrado para cada item. Após

essas explicações, os participantes começaram a utilizar a Supporter Test no seu dia-a-dia

durante 5 (cinco) dias.

Após a utilização da ferramenta, todos os participantes deram seus respectivos

pareceres, conforme segue:

• Participante 1: “A ferramenta foi útil, pois consigo executar os testes na sequência

correta. Quando comparado aos testes utilizando a ferramenta e os testes sem a

utilização da ferramenta, percebi que muitos itens não eram testados sem a utilização

da ferramenta. Quanto ao tempo dispersado no teste de cada script, posso afirmar que

o uso da ferramenta agilizou os testes, pois como antes (sem o uso da ferramenta) não

se sabia o que realmente deveria ser testado, gastava-se bastante tempo pensando no

que testar”.

• Participante 2: “A ferramenta é interessante, pois com ela pude organizar melhor meus

testes e com isso ganhei tempo para fazer outras coisas (como atender clientes). Em

alguns momentos percebi que alguns itens do script talvez não precisassem ser

testados, porém, acredito que isso seja definição das prioridades de cada item”.

• Participante 3: “Quando comparado o tempo total de testes com e sem a ferramenta

referentes a uma alteração no sistema, posso dizer que não teve ganho de tempo

durante a execução dos testes, pois os testes continuam sendo feito como antes (sem a

ferramenta). No entanto, posso afirmar que com o uso da ferramenta o tempo total dos

Participantes Função/Setor Tipo de teste que executaParticipante 1 Testador VerificaçãoParticipante 2 Atendimento ao cliente ValidaçãoParticipante 3 Atendimento ao cliente ValidaçãoParticipante 4 Programador VerificaçãoParticipante 5 Programador Verificação

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

59

testes foi menor, pois a ferramenta mostra o que deve ser testado, sem ser necessário

fazer uma análise antes de começar os testes, o que levaria um certo tempo”.

• Participante 4: “No meu dia-a-dia faço apenas testes de unidade, portanto, o uso da

ferramenta para auxiliar os testes não foi tão importante. Porém, se utilizar a

ferramenta antes de fazer a implementação no sistema, é possível ter uma visão de

onde essa implementação poderá afetar. Hoje, quando é feito uma alteração mais

importante, sempre tenho que procurar no sistema (fazer uma análise) onde estão

sendo utilizadas as rotinas que serão alteradas, afim de identificar onde a alteração que

será realizada terá impacto. Com o uso dessa ferramenta, não seria necessária tal

análise”.

• Participante 5: “Em testes simples, a execução foi mais lenta utilizando a ferramenta

do que não utilizando-a, porque se torna necessário ir e voltar a ferramenta para

verificar se todos os itens foram devidamente testados, e como se fazem os mesmo

testes repetidas vezes durante o desenvolvimento, isto acaba se tornando mais lento.

Mas ressalto que a ferramenta foi muito útil para não se esquecer de nenhum teste, o

que é comum de acontecer.”

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

60

5 CONSIDERAÇÕES FINAIS

O processo de desenvolvimento de um sistema envolve diversas fases, desde o

levantamento de requisitos, o projeto, o desenvolvimento e também os testes, que irão apontar

possíveis falhas dos processos anteriores. Porém, fases como a de testes muitas vezes são

realizadas as pressas ou, quando realizadas com tempo adequado, são feitas sem uma estrutura

adequada (o que exatamente deve ser testado, registrar os pareceres oriundos dos testes).

Além disso, testes realizados de forma adequada podem resultar em informações importantes

para melhoria do processo.

Esse trabalho de conclusão de curso apresentou o desenvolvimento da ferramenta

Supporter Test, que pode ser utilizada no gerenciamento de testes de software, uma vez que

permite registrar e manter alterações em diversas aplicações a serem testadas. Além das

alterações, a ferramenta desenvolvida também poderá gerar scripts com os itens que deverão

ser testados. A utilização desta ferramenta possibilita emissão de relatórios e geração de

gráficos, afim de se obter informações sobre o que (quais itens) e onde (quais módulos ou

telas) ocorrem os problemas dentro da aplicação, sendo que essas informações servirão de

base para uma possível tomada de decisão para que se diminua a quantidade de problemas

após as alterações realizadas em tal aplicação.

Portanto, a ferramenta desenvolvida pode auxiliar para que um software possa ter uma

melhora contínua e cada vez menos erros.

Como trabalho futuro, poderá ser desenvolvida a execução de testes automatizados

através da ferramenta Supporter Test, uma vez que ela já permite cadastrar o que deve ser

testado. Para executar testes automatizados, será necessário cadastrar quais as entradas de

dados e quais saídas esperadas em cada item de teste. Além disso, os itens de teste deverão ter

níveis mais detalhados, onde será possível definir as entradas esperadas de cada item.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

61 REFERÊNCIAS

ANDAGON , 2009. Disponivel em: <http://www.andagon.com/aqua/eng/index.php>. Acesso em: 28 out. 2012.

APACHE. The Apache Software Foundation, 2012. Disponivel em: <http://jmeter.apache.org/>. Acesso em: 31 out. 2012.

BARBOSA, F. B.; TORRES, I. V. O Teste de Software no Mercado de Trabalho. Revista Tecnologias em Projeção, Brasília, v. 2, p. 49-52, Março 2012.

DE PAULA NETO, A. V. Criando Testes com JUnit. Centro de Informática - Universidade Federal de Pernambuco. Recife: [s.n.]. 2010.

DE SOUZA, E. R.; MENDES, L. R. R. N. Processo de Testes de Desempenho Não-Intrusivos Para. V EBTS - Encontro Brasileiro de Testes de Software. Recife: Gotest Consultoria e Treinamento. 2011.

DEVMEDIA , 2008. Disponivel em: <http://www.devmedia.com.br/tecnicas-de-caixa-preta-de-teste-de-software/8898>. Acesso em: 11 nov. 2012.

DEVMEDIA , 2009. Disponivel em: <http://www.devmedia.com.br/artigo-clube-delphi-102-testcomplete/11758>. Acesso em: 07 out. 2012.

DUNSTANTHOMAS , 2012. Disponivel em: <http://www.dthomas.co.uk/dtalm/training/courses/Test/Testing/SmartBear-TestComplete.htm>. Acesso em: 14 out. 2012.

ENGENHARIA DE SOFTWARE, 2010. Disponivel em: <http://files.engenharia-de-software7.webnode.com/200000019-3866c3960f/Engenharia%20de%20%20Software%20Metodologias%20de%20Desenvolvimento%20de%20Sistemas.pdf#page=4>. Acesso em: 02 jun. 2013.

FANTINATO, M. et al. AutoTest – Um Framework Reutilizável para a Automação de. III Simpósio Brasileiro de Qualidade de Software. Brasília: BDB Comp Biblioteca Digital Brasileira de Computação. 2004.

GRAHAM, D.; FEWSTER, M. Software test automation. Londres: Addison-Wesley, 1999.

GSTATIC , 2009. Disponivel em: <http://t3.gstatic.com/images?q=tbn:ANd9GcRAFpJ9V0cECCViVccRqDv29XZFGhGSDrKQBaiajPD48svdumEtIypqDXxQ>. Acesso em: 14 out. 2012.

JOHN E CAILIN, 2008. Disponivel em: <http://www.johnandcailin.com/blog/john/load-test-your-drupal-application-scalability-apache-jmeter%3A-part-two>. Acesso em: 14 out. 2012.

KLAROS TESTMANAGEMENT, 2008. Disponivel em: <http://www.klaros-testmanagement.com/>. Acesso em: 14 out. 2012.

MAJORDOJO , 2008. Disponivel em: <http://www.majordojo.com/testitool/>. Acesso em: 24 nov. 2012.

BD

U –

Bib

liote

ca D

igita

l da

UN

IVAT

ES

(htt

p://w

ww

.uni

vate

s.br/

bdu)

62 MALDONADO, J. C. et al. Introdução ao Teste de Software. São Carlos: ICMC/USP, 2004.

MOLINARI, L. Testes Funcionais de Software. Florianópolis: Visual Books, 2008.

MOLINARI, L. Inovação e Automação de Testes de Software. 1ª Edição. ed. São Paulo: Érica Ltda, 2010.

MYERS, G. J. The art of software testing. Nova York: John Wiley, 1979.

PALOMA COSTA, 2008. Disponivel em: <http://javawoman.wordpress.com/2008/11/05/o-que-e-testlink/>. Acesso em: 14 out. 2012.

PAULA, D. M. Avaliação dos testes de software e estudo das características da ferramenta TestComplete, 2005. Disponivel em: <www.arcos.pucminas.br/si/documentos/monografias/SI_PUC_ARCOS_monografia_devair_>. Acesso em: 14 out. 2012.

PFLEEGER, S. L. Engenraria de Software: Teoria e Prática. 2ª. ed. São Paulo: Pearson, 2004.

SELENIUM , 2012. Disponivel em: <http://seleniumhq.org/>. Acesso em: 26 out. 2012.

SOMMERVILLE, I. Engenharia de Software. 8ª. ed. São Paulo: Pearson, 2007.

SOURCEFORGE.NET , 2008. Disponivel em: <http://testmaster.sourceforge.net/>. Acesso em: 24 nov. 2012.

SOUZA, C. S. D. et al. Projeto de Interfaces de Usuário. Rio de Janeiro: PUC-Rio, 2000.

TERRA, R.; BIGONHA, R. S. Ferramentas para Análise Estática de Códigos Java. III EBTS - Encontro Brasileiro de Testes de. Recife: [s.n.]. 2008.

TEXTEXPERT. TextExpert website, 2007. Disponivel em: <http://www.testexpert.com.br/?q=node/591>. Acesso em: 16 set. 2012.

TONSIG, S. L. Engenharia de Software - Análise e Projeto de Sistemas. 2ª. ed. Rio de Janeiro: Ciência Moderna Ltda, 2008.

WIKIDOT.COM. Wikidot.com website, 2008. Disponivel em: <http://junit.wikidot.com/>. Acesso em: 16 set. 2012.

Documents

SUPPORTER TEST - FERRAMENTA DE APOIO AO GERENCIAMENTO DE ... · SUPPORTER TEST - FERRAMENTA DE APOIO AO ... que deve ser testado, serve de base para os testes. Um parecer de cada