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
Fonte: adaptado de Pfleeger (2004, p. 292)
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
Fonte: adaptado de Pfleeger (2004, p. 292)
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
Fonte: adaptado de Pfleeger (2004, p. 294)
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’
Fonte: adaptado de Pfleeger (2004, p. 294)
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)
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
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).
Desenvolvida pela AutomatedQA, o TestComplete é uma ferramenta de automação de
testes de uso comercial. Um dos destaques do TestComplete é o suporte para a automação de
testes de sistemas desenvolvidos em Delphi. A ferramenta oferece recursos para automatizar
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
Após os testes serem aplicados, o TestComplete fornece os resultados desses testes em
forma de gráfico, conforme mostra a Figura 10.
30
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
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 do código e, no
caso da linguagem Java esse teste é feito através do JUnit em cada método separadamente
Desenvolvida pela AutomatedQA, o TestComplete é uma ferramenta de automação de
taques do TestComplete é o suporte para a automação de
testes de sistemas desenvolvidos em Delphi. A ferramenta oferece recursos para automatizar
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
Após os testes serem aplicados, o TestComplete fornece os resultados desses testes em
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.
de teste contém a lista mestre de todos os casos de teste para um determinado produto. No
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
permite importar e exportar planos de teste para formatos de arquivos CSV.
36
é um aplicativo escrito em PHP que permite
de software. Cada plano
de teste contém a lista mestre de todos os casos de teste para um determinado produto. No
executar todo e qualquer caso de teste. O Testitool
tais como: relatório de
Esse aplicativo também
permite importar e exportar planos de teste para formatos de arquivos CSV.
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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
Fonte: elaborada pelo autor
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.