UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMTICA
GRADUAO EM CINCIA DA COMPUTAO

Framework para automao de testes funcionais

utilizando o Rational Functional Tester
TRABALHO DE GRADUAO

Aluno: Rafael Oliveira Nbrega (ron@cin.ufpe.br)

Orientador: Alexandre Marcos Lins de Vasconcelos (amlv@cin.ufpe.br)

Recife, 10 de Outubro de 2006.

Assinatura
Este Trabalho de Graduao resultado dos esforos do aluno Rafael Oliveira
Nbrega, sob a orientao do professor Alexandre Marcos Lins de Vasconcelos, sob o
ttulo de Framework para automao de testes funcionais utilizando o Rational Functional
Tester. Todos abaixo esto de acordo com o contedo deste documento e os
resultados deste Trabalho de Graduao.

_________________________________________
Rafael Oliveira Nbrega

_________________________________________
Alexandre Marcos Lins de Vasconcelos

-I-

Agradecimentos
Gostaria de agradecer a todas as pessoas que ajudaram direta ou
indiretamente para a realizao deste trabalho:

Agradeo a toda minha famlia por estar mais uma vez ao meu lado e
por sempre me incentivar apesar dos meus momentos de ausncia.

Ao professor Alexandre Vasconcelos pela seriedade da orientao do

meu trabalho de graduao.

Ao pessoal da Qualiti e do C.E.S.A.R., Juliana Lima, Paulo Santos,

Eduardo Ferraz, Vinicius Samico e Breno Santos por terem tido
bastante pacincia comigo ultimamente.

Aos meus amigos e companheiros de faculdade e meus scios da

Effektiv com os quais vivi momentos inesquecveis que levarei comigo
pra sempre.

A todos que trabalharam no projeto, Ricardo, Livar, Marilia, Juliana,

Fbio, Egito, Diogo, Lenildo e Joo Marcelo.

A todos meus amigos da qualiti, por me darem incentivo e conselhos

nos momentos decisivos: Paulinho, Mara, Aninha, Isabela, Rico e
Marlia.

A todos meus amigos que entenderam meus momentos de ausncia:

Gacho, Bode, Rico, Bruno, Henrique, Teteu e Noggy.

E um agradecimento especial Lila, minha namorada, que sempre

entendeu e me apoiou com muita pacincia, ternura e carinho em todos
meus momentos de ausncia.

Nada vem de graa

Rafael Nbrega

-II-

Resumo
Este trabalho prope a construo de um framework para automao de
testes funcionais utilizando a ferramenta Rational Functional Tester e a tcnica
para construo e organizao de scripts de teste por decomposio funcional.
A utilizao de frameworks para automatizar testes de software isola a
aplicao sob teste dos scripts de teste provendo um conjunto de funes e
bibliotecas de funes que sero utilizados durante a automao.
Esta abordagem aumenta a independncia na execuo e o reuso de
cdigo entre os scripts de automao, melhorando a robustez da execuo e a
manutenibilidade dos scripts, respectivamente.

-III-

Sumrio
1.

Introduo............................................................................................................... 1
1.1. Metodologia para realizao do trabalho .................................................. 2
1.2. Estrutura do Trabalho................................................................................... 3
2. Automao de Testes Funcionais ........................................................................ 4
2.1. Dificuldades da automao de testes de software.................................... 4
2.2. Fatores de sucesso da automao de testes de software.......................... 5
2.3. Consideraes Finais..................................................................................... 8
3. Ferramenta IBM Rational Functional Tester...................................................... 9
3.1. Viso Geral...................................................................................................... 9
3.2. Processo de Automao.............................................................................. 10
3.3. Extenso do Rational Functional Tester ................................................... 16
3.4. Consideraes Finais................................................................................... 19
4. Framework para automao de testes funcionais ............................................. 20
4.1.
Melhorias no processo ................................................................................ 20
4.2.
Arquitetura do Sistema............................................................................... 26
4.3.
Consideraes Finais................................................................................... 28
5. Resultados Obtidos ............................................................................................. 30
5.1.
Contexto ........................................................................................................ 30
5.2.
Anlise dos Resultados ............................................................................... 31
5.3.
Consideraes Finais................................................................................... 37
6. Concluses e Trabalhos Futuros........................................................................ 39
6.1.
Dificuldades Encontradas .......................................................................... 39
6.2.
Trabalhos Futuros........................................................................................ 40
Referncias.................................................................................................................... 41
APNDICE A - Comparao entre Ferramentas de Automao de Testes
Funcionais..................................................................................................................... 43

-IV-

ndice de Figuras
Figura 1 Rational Software Development Platform - Rational Functional
Tester .......................................................................................................................... 9
Figura 2 Tela Inicial do Rational Functional Tester......................................... 10
Figura 3 Processo Record & Playback........... ........................................................ 11
Figura 4 Datapool do Rational Functional Tester. ............................................ 12
Figura 5 Janela mostrada durante filmagem dos scripts. ............................... 13
Figura 6 Janela mostrada durante execuo dos scripts................................. 13
Figura 7 Log gerado pela Execuo. .................................................................. 15
Figura 8 Extenso do Processo Record & Playback............................................ 16
Figura 9 Janelas mostradas durante a adio de um ponto de verificao.. 18
Figura 10 Processo de Decomposio Funcional ............................................. 25
Figura 11 Arquitetura do Sistema ..................................................................... 26
Figura 12 Arquitetura do pacote acoes ............................................................ 27
Figura 13 Arquitetura do pacote POI ............................................................... 28
Figura 14 Comparao dos custos de execuo automtica e manual por
ciclo ........................................................................................................................... 37

-V-

ndice de Tabelas
Tabela 1 Custos Fixos da Automao de Testes.................................................... 33
Tabela 2 Custos Variveis da Automao de Testes............................................. 33
Tabela 3 Custos Variveis dos Testes Manuais ..................................................... 34
Tabela 3 Variveis do ROI da automao de testes .............................................. 36
Tabela 4 Matriz de comparao entre Ferramentas de Automao de Testes
Funcionais..................................................................................................................... 46

-VI-

1. Introduo
A atividade de teste envolve a execuo de uma implementao do
software com os dados de teste e a anlise de suas sadas e de seu
comportamento operacional, a fim de verificar se foi executada conforme o
esperado [14].
O custo para correo de um erro na fase de manuteno de sessenta a
cem vezes maior do que corrigi-lo durante o desenvolvimento [11].
Dessa forma, a atividade de testes uma etapa crtica para o
desenvolvimento de um software. Embora durante todo o processo de
desenvolvimento de software sejam utilizados mtodos, tcnicas e ferramentas a
fim de evitar que erros sejam introduzidos no produto, a atividade de teste
continua sendo de fundamental importncia para a eliminao dos erros que
persistem.
Para se desenvolver um software podemos fazer diferentes tipos de teste,
com diversos objetivos - performance, carga, funcionalidade, estresse, entre
outros [7].
Os testes funcionais so testes derivados da especificao do software ou
componente, ou aqueles que o testador se preocupa somente com a
funcionalidade do sistema e no com sua implementao, so os mais utilizados
devido necessidade que os softwares produzidos faam o que foi acordado com
o cliente na fase de anlise de requisitos [14].
J a execuo de testes de software pode ser feita tanto de forma manual
quanto automatizada. A execuo manual consiste na reproduo por uma
pessoa do teste previamente definido e documento. J a execuo automtica
consiste na automao do processo de teste manual atualmente em uso [17].
Scripts de teste devem ser construdos para reproduzir os testes que sero
executados automaticamente.
Cada uma destas formas tem suas vantagens e desvantagens, mas os
testes manuais tm um grande problema em relao ao tempo de execuo em
relao ao tempo de execuo de testes automatizados.
-1-

Os testes funcionais devem ser automatizados quando so muito

repetitivos e demandam um esforo considervel de tempo quando realizados
manualmente [17]. A realizao de testes automatizados, alm de possibilitar a
reduo do ciclo de testes, permite um aumento indireto da cobertura do
software e, conseqentemente, da sua qualidade, porque permite que os
testadores foquem seus esforos em outros tipos de teste ou em testes que no
possam ser automatizados.
Atualmente, existem diversas ferramentas de automao de testes
funcionais que vendem a automao de testes como apenas uma gravao da
execuo de testes manuais e a sua posterior execuo repetidas vezes.
Infelizmente, isto no funciona na prtica. Testes automatizados desta maneira
praticamente no utilizam reuso de cdigo o que gera um enorme esforo de
manuteno que inviabiliza a grande maioria dos projetos de automao
realizados utilizando essa metodologia.
A proposta apresentada neste documento o desenvolvimento de um
framework para automao de testes funcionais utilizando uma tcnica de
automao de testes e a demonstrao dos resultados obtidos na utilizao deste
em uma empresa desenvolvedora de software.
O framework sugerido permite que testes funcionais sejam automatizados
de maneira enxuta e modular, facilitando a manutenibilidade dos testes
automticos e aumentando o desempenho da execuo dos testes.

1.1.

Metodologia para realizao do trabalho

Esta seo descreve a metodologia empregada para o desenvolvimento

deste trabalho. Basicamente, a realizao do trabalho foi dividida nas seguintes

etapas:

Etapa de Estudo Inicial

Estudo sobre ferramentas de automao de testes funcionais;
Estudo sobre metodologias e tcnicas de automao de testes;
-2-

Definio do escopo do trabalho.

Etapa de Definio do Framework

Definio da ferramenta de automao de testes
Definio das funcionalidades da Ferramenta a serem melhoradas;
Definio das tecnologias utilizadas na implementao do framework;
Implementao das funcionalidades relacionadas ao framework, ou seja, dos
mdulos relacionados definio e criao de tcnicas a serem aplicadas
ao processo de automao de testes;

Etapa de Documentao do Trabalho

Redao final do trabalho de graduao
Concepo da apresentao do trabalho.

1.2.

Estrutura do Trabalho
Alm desta introduo, esta monografia est dividida em mais cinco

captulos.
O captulo 2 apresenta os conceitos sobre automao de testes, suas
principais dificuldades e, abordagens e tcnicas para super-las.
O captulo 3 descreve a ferramenta de automao de testes funcionais IBM
Rational Functional Tester, utilizada como base para criao do framework.
O captulo 4 apresenta o framework para automao de testes funcionais
que utiliza a tcnica de decomposio funcional, o qual vai criar scripts que
modelam a regra de negcio em funes e bibliotecas utilizadas pelos scripts de
teste.
O captulo 5 apresenta os resultados da utilizao do framework em uma
fbrica de software.
O captulo 6 apresenta as concluses e tendncias futuras quanto
utilizao do framework de automao proposto neste trabalho.

-3-

2. Automao de Testes Funcionais

Segundo Graham & Fewster em [1], automao de testes no uma tarefa que
trar maior qualidade aos testes. Quando um teste automatizado, ele ter a mesma
eficincia em descobrir erros do que quando executado manualmente. Se o teste em
si no acha nenhum erro, a automao deste teste tambm no vai achar nada, porm
de maneira mais rpida.
Depois de feito, um teste automatizado mais barato do que um manual, o
esforo para execut-lo automaticamente uma pequena frao do esforo de
execut-lo manualmente. Porm, o custo de criar e mant-los muito mais alto que
os testes manuais, levando em mdia dez vezes mais tempo do que um teste manual
[10]. Quanto melhor for a abordagem de automao de testes mais barato ser a sua
implementao e manuteno.
A qualidade da automao ser determinada pela habilidade do profissional
automatizador de testes que vai determinar o quo fcil ser para adicionar novos
testes automatizados, para mant-los e quais benefcios a automao trar para o
produto final.
De acordo com o mito popular, pessoas com pouca experincia de
programao podem usar ferramentas de automao de testes e criar rapidamente
sutes extensivas de teste. As ferramentas seriam fceis de usar e a manuteno das
sutes de teste no seria um grande problema. Desta forma, um gerente poderia
poupar muito dinheiro usando uma destas ferramentas para substituir alguns
testadores. Estes mitos so difundidos por vendedores de ferramentas e executivos
que no entendem de automao de testes. Porm, a automao de teste no to
simples assim.

2.1.

Dificuldades da automao de testes de software

De acordo com Cem Kaner em [6], existem alguns problemas em relao a esta
viso sobre automao de testes de software:
1. Automatizar no barato
-4-

a. Geralmente se leva entre trs e dez vezes mais tempo para criar,
verificar e documentar minimamente os testes automatizados do que
criar e executar uma vez o teste mo. Os testes que se executa apenas
uma ou duas vezes no devem ser automatizados.
2. Esta abordagem cria riscos de novos custos
a. O custo de encontrar e de reparar erros aumenta ao passar do tempo. Se
for gasto muito tempo escrevendo scripts de teste pode se atrasar a
execuo dos testes para o final do desenvolvimento, quando os erros
so mais caros.
3. Estes testes no so poderosos
a. Os testes que so automatizados so testes que j passaram pelo
sistema. Os principais erros so aqueles encontrados durante a criao
dos casos de teste, mas eles so normalmente testes manuais, no
relacionados aos testes automatizados.
4. Na prtica, muitos grupos de teste automatizam apenas os testes simples.

2.2.
Fatores de sucesso da automao de testes de
software
No mesmo artigo [6], Kaner cita estratgias para uma automao de testes de
software de sucesso:
2. Molde a expectativa da gerncia em relao ao tempo dos benefcios da
automao.
a. H um grande benefcio em automatizar uma sute de testes: executar
estes testes cinqenta ou cem vezes durante o desenvolvimento de um
release. Mesmo se levar dez vezes mais tempo para desenvolver cada
teste do que executar cada teste mo, e mais dez vezes o tempo para a
manuteno, haver ainda um ganho de tempo entre trinta e oitenta
execues manuais.
b. Provavelmente, o benefcio da automao no ser percebido no
primeiro release em que iniciada a automao. A diminuio do
esforo se dar paulatinamente nos prximos releases.
-5-

3. Desenvolvimento de uma automao de testes um desenvolvimento de

software.
a. No se pode desenvolver grandes sutes de teste que sobrevivero e
sero teis em diversos releases e que tero baixo custo de manuteno
sem um planejamento claro e realstico.
b. A automao utiliza uma linguagem de programao, mesmo que
simplificada, como todo desenvolvimento de software.
c. Cada caso de teste pode ser encarado como uma funcionalidade.
d. Os automatizadores, da mesma forma que os desenvolvedores de
software

fazem,

programao,

devem:

adotar

entender

uma

os

arquitetura

requisitos,
robusta

entender
que

de

permita

desenvolver, integrar e manter as funcionalidades, entre outras

atribuies de qualquer desenvolvedor de software.
4. Use uma arquitetura de testes orientada a dados.
a. A tcnica de testes orientados a dados armazena as entradas dos testes
em arquivos separados dos scripts de teste. Quando os scripts de teste
so executados, esses dados so lidos destes arquivos ao invs de
estarem dentro do cdigo do script. Esta separao clara aumenta
consideravelmente a manutenibilidade dos scripts de teste.
5. Use uma arquitetura baseada em um framework
a. Um framework prov uma abordagem diferente automao de testes e
geralmente utilizada com um ou mais estratgias de testes orientados
a dados.
b. Um framework isola a aplicao sob teste dos scripts de teste provendo
um conjunto de funes em bibliotecas de funes. Os scripts de teste
utilizam essas funes como se fossem comandos bsicos da linguagem
da ferramenta de automao. Ento possvel programar os scripts de
caso de teste independentemente da interface do usurio.
6. Lembre-se da Realidade da sua equipe
a. Frameworks mal projetados podem destruir o projeto.

-6-

b. Muitos testadores excelentes no tm experincia com programao.

Eles so imprescindveis para um esforo de teste, mas no para
escrever cdigos de automao.
c. No-programadores podem ser beneficiados por uma abordagem
dirigida a dados, pois eles podem desenvolver casos de testes apenas
preenchendo tabelas.
7. Considere utilizar outros tipos de automao alm da GUI
a. Automao de Regresso atravs da GUI pode trazer uma falsa idia de
cobertura que no existe. E isto pode causar uma sobrecarga na equipe
deixando os profissionais mais experientes criando e mantendo scripts
ao invs de encontrando bugs.
b. Ferramentas de automao de testes pela interface com usurio so
bastante teis, mas requerem um investimento significativo, um
planejamento detalhado, uma equipe bem treinada e bastante cuidado.
Outro fator crtico para o sucesso da automao a seleo da ferramenta
adequada. Investir dinheiro, treinamento e tempo na ferramenta errada levar,
certamente, ao fracasso automao de testes. De acordo com Hendrickson em [2],
para fazer a escolha certa necessrio estabelecer claramente os requisitos para a
ferramenta, discutindo com os stakeholders do projeto questes como:
1. Quem vai usar a ferramenta, qual o seu propsito e quais problemas essa
ferramenta vai nos ajudar a resolver?
2. Que tipo de processo a ferramenta necessita dar suporte e, havendo mudanas
no processo, a ferramenta pode facilmente ser adequada?
3. Que funcionalidades a ferramenta precisa ter; que relatrios devem ser
extrados?
4. Quem deve ter acesso ferramenta e que nvel de controle de acesso e
administrao necessrio?
5. Que tipo de interface com o usurio necessria? GUI, linha de comando?
6. Com quais plataformas a ferramenta precisa ser compatvel? Com que outras
ferramentas ela dever se integrar?
-7-

7. Qual o oramento e tempo disponveis para aquisio e manuteno?

Independente de qual seja a deciso, adquirir uma ferramenta ou desenvolver
seu prprio framework, necessrio considerar que esforo e investimento sero
necessrios no processo de seleo e implantao ou construo da ferramenta antes
de iniciar a automao de testes propriamente dita.

2.3.

Consideraes Finais

A automao de testes precisa ser bem analisada e pensada sobre a sua

necessidade e como ela ser mais bem adaptada s necessidades de cada processo de
desenvolvimento de software. Este captulo apresentou as principais questes por
trs da automao de testes.
Seguindo estas estratgias como orientao geral, este trabalho pretende
utilizar uma ferramenta de automao de testes funcionais e criar um framework de
automao de testes funcionais orientado a dados, para aumentar a produtividade da
atividade de testes, e conseqentemente do software em desenvolvimento.
O apndice A apresenta um comparativo entre ferramentas de automao de
testes funcionais a partir de certos critrios a fim de se avaliar as principais
ferramentas do mercado.

-8-

3. Ferramenta IBM Rational Functional Tester

O framework de automao de testes funcionais proposto neste trabalho foi
desenvolvido em cima da plataforma IBM Rational Functional Tester, ou RFT. Este
captulo se prope a mostrar a ferramenta RFT, utilizando o processo Record &
Playback como guia para a apresentao da ferramenta.

Figura 1 Rational Software Development Platform - Rational Functional Tester

Quando se utiliza automao de testes pela primeira vez, em geral, o primeiro

impulso de utilizar um processo Record & Playback que consiste em gravar a
utilizao da aplicao sob teste e reproduzir a gravao diversas vezes quanto
necessrio para averiguar a corretude da aplicao [1].
O IBM Rational Functional Tester d suporte a este processo atravs de
funcionalidades que sero explicadas ao longo deste captulo.

3.1.

Viso Geral

IBM Rational Functional Tester uma ferramenta de testes automatizados

orientada a objeto onde possvel rapidamente gerar scripts gravando testes em uma

-9-

aplicao Java, .NET ou Web e avaliar propriedades ou valores dos objetos da

interface do usurio [8].

Figura 2 Tela Inicial do Rational Functional Tester

O Rational Functional Tester oferece uma escolha do ambiente de

desenvolvimento e da linguagem de codificao - Java para plataforma Eclipse ou
Microsoft Visual Basic .NET no ambiente Microsoft Visual Studio .NET.
Para fins didticos, vamos apenas apresentar o IBM Rational Functional Testes
utilizando a linguagem Java na plataforma Eclipse. Porm, todas as funcionalidades
apresentadas tambm so encontradas no ambiente Visual Studio .Net.

3.2.

Processo de Automao

Todo processo de automao de testes manuais pode ser dividido em trs

grandes tarefas comuns a qualquer processo:

Gravao do Script de Teste

Execuo do Script de Teste

Reportagem da Execuo Automtica

Dentro de cada macro-tarefa acima existem diversas subtarefas que vo

realizar trabalhos especficos. Aps a realizao de todas as subtarefas, a tarefa mais
geral pode ser considerada finalizada.
-10-

A ferramenta Rational Funcional Tester pode ser utilizada seguindo o seguinte

processo:

Figura 3 Processo Record & Playback.

Este captulo ir explicar como o Rational Functional Tester oferece suporte

para execuo de cada macro-tarefa e cada uma de suas tarefas internas:

3.2.1. Gravar Script:

Esta macro-tarefa tem como objetivo gravar a execuo do teste manual
salvando as informaes sobre os dados utilizados, as navegaes e funes
utilizadas e onde devem ser avaliados os resultados esperados do teste. Esta tarefa
dividida neste processo em trs subtarefas como a seguir:
3.2.1.1.

Definir Dados de Entrada e de Sada:

A automao de testes funcionais utiliza um documento chamado projeto de

testes, ele contm todo o passo a passo a ser seguido e os dados de entradas e sadas
esperadas do teste funcional.
Desta forma, preciso definir na ferramenta quais sero os dados de entrada e
de sada para cada caso de teste do sistema a ser automatizado.
As entradas e sadas dos testes podem ser colocadas em uma estrutura j
fornecida pelo Functional Tester chamada datapool.

-11-

Figura 4 Datapool do Rational Functional Tester.

Um datapool uma srie de dados de teste, uma coleo de registros de dados

relacionados que fornece valores de dados s variveis em um script de teste durante
a sua execuo. O uso de datapools pode fornecer uma separao explcita entre dados
e funes [3].

3.2.1.2.

Filmar Execuo:

Aps definido os dados de entrada e os resultados esperados na sada,

preciso fazer uma filmagem da utilizao do software pelo usurio. Esta filmagem
vai gerar um script contendo informaes sobre os objetos e aes sobre estes. A
filmagem bastante importante para uma posterior reproduo deste script.
Quando se grava um teste de software em um script, o Functional Tester
grava todas as aes do usurio utilizando a aplicao, tais como eventos de mouse e
teclado, dados preenchidos em cada campo, etc.
Pode-se tambm introduzir pontos de verificao aos dados de teste ou s
propriedades dos objetos em sua aplicao, onde estas propriedades ou dados sero
avaliados a fim de se comprovar a corretude da aplicao. Durante a gravao, o
ponto de verificao captura a informao do objeto e a armazena em um arquivo.
Ento durante a reproduo, o ponto de verificao captura a informao do objeto e
a compara com o arquivo [3].

-12-

Figura 5 Janela mostrada durante filmagem dos scripts.

3.2.2. Executar Script:

Quando se executa um script, o Functional Tester reproduz as aes gravadas
anteriormente como a inicializao da aplicao, as aes que foram gravadas na
aplicao e os pontos de verificao adicionados.
Para reproduzir um script no Functional Tester [3]:
1. Configure a aplicao sob teste ajustando o ambiente ou o navegador
apropriado para executar a aplicao.
2. Execute o script de teste
3. O monitor do Playback inicializa e fornece informaes enquanto o script
executa.

Figura 6 Janela mostrada durante execuo dos scripts.

Para realizar o reconhecimento de objetos da aplicao sob teste o RFT utiliza

uma tcnica chamada ScriptAssure. Cada objeto em um mapa do objeto de teste tem
um conjunto de propriedades de reconhecimento que so estabelecidas durante a
gravao [3].

-13-

Por exemplo, um boto com cinco propriedades de reconhecimento: nome,

tipo, papel, classe e ndice. Para encontrar um objeto na aplicao sob teste durante a
reproduo, o Functional Tester compara o objeto na aplicao com as propriedades
de reconhecimento no mapa de objeto de teste. Cada propriedade de um objeto de
teste associada a um peso. O Functional Tester usa o valor deste peso a fim de
determinar a importncia da propriedade para o reconhecimento do objeto.

3.2.3. Reportar Execuo:

Durante a execuo dos testes funcionais, o RFT monitora os resultados de
cada ponto de verificao e as excees que ocorrem no sistema. Aps a execuo dos
scripts de teste, um log gerado contendo todas estas informaes.
3.2.3.1.

Relatar Eventos de Exceo e Parar:

Durante a execuo dos testes funcionais, o RFT fica monitorando os eventos

que ocorrem no sistema.
O teste funcional registra automaticamente os seguintes eventos:

Incio do script

Fim do script

Chamadas de outros Scripts

Chamadas ao mtodo startApplicaction

Incio do timer

Fim do timer

Excees

Resultados dos Pontos de verificao (Falha ou Erro)

Caso ocorra alguma das quatro excees abaixo, o sistema pra a execuo e
reporta o erro ocorrido no log da execuo.

ObjectNotFoundException
o Ocorre quando algum objeto gravado no encontrado na
reproduo do script

-14-

AmbiguosRecognitionException
o Ocorre quando o Functional Tester no consegue distinguir
entre os objetos da tela, qual foi usado durante a gravao
(reconhecimento ambguo)

CallScriptException
o Ocorre quando o Functional Tester no consegue inicializar
algum script.

UnhandledException
o Ocorre quando uma exceo lanada pelos scripts de teste e
no tratada.

3.2.3.2.

Gerar Log:

Depois que a execuo termina, possvel ver os resultados em um log. Os

resultados incluem todos os eventos registrados na tarefa anterior, tais como falhas
dos pontos de verificao, excees no script, alertas sobre reconhecimento dos
objetos e qualquer informao adicional da execuo.

Figura 7 Log gerado pela Execuo.

-15-

3.3.

Extenso do Rational Functional Tester

O Rational Functional Tester fornece recursos avanados que permitem

aumentar a eficincia de algumas tarefas do processo apresentado sem mudar o
processo em si. Esta seo ir explicar as modificaes tanto na tarefa Filmar
Execuo quanto Reproduzir Script.

Figura 8 Extenso do Processo Record & Playback

3.3.1. Extenso das tarefas de Gravar Script

Na macro-tarefa Gravar Script possvel refinar a tarefa Filmar Execuo em
trs novas tarefas. Mapear Objetos, Definir Aes e Definir Pontos de Verificao.
Estas tarefas so repetidas para cada objeto toda vez que eles so utilizados pelo
usurio.
Inicialmente ele mapeado juntamente com as aes efetuadas pelo usurio
clicar, digitar um texto, etc. e por fim so definidos os pontos onde sero
verificadas as propriedades ou os valores dos objetos para se atestar o funcionamento
correto da aplicao sob teste.

-16-

A seguir ser detalhado o funcionamento de cada uma das novas tarefas

refinadas:
3.3.1.1.

Mapeamento dos Objetos

Ao se gravar um script, o Functional Tester cria um mapa do objeto de teste

botes, telas ou programas para a aplicao que est sendo testada. Este mapa
funciona como uma lista esttica que descreve todos os objetos de teste reconhecidos
pelo Functional Tester na aplicao sob teste.
O mapa do objeto de teste contm propriedades de reconhecimento para cada
objeto. Estas propriedades podem ser alteradas manualmente para se obter um
melhor desempenho do reconhecimento destes objetos durante a execuo dos
scripts de teste, inclusive fazendo uso de expresses regulares para garantir o
reconhecimento mesmo com pequenas mudanas nos valores das propriedades dos
objetos.

3.3.1.2.

Definir Aes:

Aps se obter o mapeamento de um objeto, preciso definir qual a ao que

ser realizada. Cada objeto mapeado pelo Functional Tester cria um objeto em Java
que possui mtodos que representam todas as aes habilitadas para aquele tipo de
objeto. Exemplos de aes: clicar em determinado ponto do objeto, inserir texto, ler o
texto digitado no objeto, marcar como selecionado, desmarcar, etc.
3.3.1.3.

Definir Pontos de Verificao:

Os pontos de verificao verificam se alguma ao ocorreu, ou verificam o

estado de um objeto. Ao se criar um ponto de verificao, o sistema captura a
informao sobre o objeto na aplicao para estabelec-lo como referncia para a
comparao durante a reproduo do script [3].

-17-

Figura 9 Janelas mostradas durante a adio de um ponto de verificao.

3.3.2. Extenses das tarefas de Reproduzir Script

A tarefa Reproduzir Script dentro da macro-tarefa Executar Script pode ser
dividida em trs tarefas da mesma forma que a tarefa Filmar Script foi dividida.
3.3.2.1.

Encontrar Objetos

Para que o Functional Tester reconhea um objeto na aplicao sob teste, as

propriedades do objeto devem combinar matching com as propriedades gravadas
no mapa do objeto do teste. Por padro, o Functional Tester pode encontrar o objeto
se uma ou duas propriedades no combinarem, porm o RFT reportar no log de
execuo um alerta sobre o reconhecimento fraco. Se mais de trs propriedades no
combinarem, o Functional Tester no vai encontrar o objeto na aplicao.
Com a manipulao do mapeamento dos objetos, possvel executar scripts
com sucesso mesmo quando a aplicao sob teste for atualizada. Se os objetos na
aplicao mudarem, possvel usar a funcionalidade do ScriptAssure para controlar a
sensibilidade da comparao entre objetos.
3.3.2.2.

Executar Aes

Depois de identificado o objeto na tela, o Functional Tester ir tentar

reproduzir a ao filmada durante a gravao dos scripts. Se no for possvel realizar

-18-

a ao, o RFT lanar uma exceo que ser adicionada ao log da execuo dos
scripts.

3.3.2.3.

Verificar Pontos de Verificao

Os pontos de verificao definidos na gravao dos scripts de teste so

executados nesta tarefa. Caso o objeto a ser avaliado no seja encontrado uma
exceo de ObjectNotFoundException pode ser lanada. Caso contrrio, o objeto ser
avaliado e o resultado reportado no log da execuo dos scripts.

3.4.

Consideraes Finais

Este captulo descreveu as principais funcionalidades do Rational Funcional

Tester seguindo um processo Record & Playback. A ferramenta possui boas
funcionalidades

para

processo,

porm

este

processo

limita

muito

desenvolvimento de scripts de teste com fcil leitura pelo desenvolvedor e uma boa
manuteno.
Os scripts possuem muita repetio de cdigo e nenhum reuso. A gerao do
cdigo feita automaticamente pela gravao das aes do usurio pela ferramenta,
no deve ser utilizada irrestritamente.
Outros fatores limitantes da ferramenta so as formas de entrada e sadas de
dados feitas, respectivamente, pelo datapool e pelo log da execuo. Estas duas
funcionalidades limitam bastante a automao de testes que necessitam uma
facilidade de atualizao das entradas dos scripts e uma rapidez na coleta dos dados
da execuo.
Como soluo destes problemas, o prximo captulo ir propor um framework
para automao de testes que faz modificaes tanto no processo quanto nas tarefas
propostas neste captulo a fim de produzir um melhor resultado na automao de
testes funcionais.

-19-

4. Framework para automao de testes

funcionais
O framework proposto utiliza uma tcnica de construo e organizao dos
scripts de teste que faz mudanas no processo e nas tarefas do Rational Functional
Tester. A utilizao do framework prov mais reuso e independncia entre os scripts e
melhora a robustez da execuo dos casos de testes, alm de melhorar de uma
maneira geral a manutenibilidade dos scripts de teste. Este captulo falar das
melhorias feitas no processo de automao de testes e na arquitetura do sistema para
implementar tais melhorias.

4.1.

Melhorias no processo

As melhorias no processo Record & Playback foi definido tendo como base o
trabalho de Zambelich em [17], que ser explicado a seguir:

4.1.1.

Mtodo de decomposio funcional

A tcnica de criao de scripts por decomposio funcional visa reduzir todos

os casos do teste a suas tarefas mais fundamentais. Ele consiste em escrever as
funes relativas ao usurio, os scripts das regras de negcio do caso de teste e os
scripts de utilidades gerais que executam estas tarefas independentemente uma das
outras. Estas reas fundamentais incluem:
1. Navegao
2. Funes Especficas (do Negcio)
3. Verificao
4. Navegao de Retorno
Para realizar tal objetivo necessrio separar os dados das funes. Isto
permite que um script automatizado de teste seja escrito para executar uma funo

-20-

do negcio, usando arquivos para fornecer os dados de entrada e dos resultados

esperados.
O motor da execuo o Driver Script que contm uma srie de chamadas a
um ou mais scripts de teste que vo realmente executar o teste automaticamente. Os
scripts de caso de teste contm a lgica do caso do teste, mas quem vai realmente
testar a aplicao so os scripts da regra do negcio que contm todas as funes do
sistema mapeadas. Os scripts de utilidades gerais so chamados de acordo com a
necessidade dos scripts principais.
Cada script tem o seguinte objetivo:
Driver Scripts:
Executa a inicializao, se necessrio, da aplicao e chama os scripts de
caso do teste na ordem desejada.
Scripts de caso de teste:
Executa a lgica do caso de teste da aplicao, usando scripts da funo
do negcio.
Scripts da regra de negcio:
Executa funes especficas do negcio dentro da aplicao.
Scripts de utilidade geral:
Executa as tarefas especficas da aplicao requeridas por dois ou mais
scripts de teste.
Funes relativas ao Usurio:
Funes gerais, especficas da aplicao, e de acesso a telas. Estas
funes podem ser chamadas por qualquer um dos scripts acima citados.
Os prximos passos representam um caso de teste de um pagamento.
1. Acesse a tela de pagamento atravs do Menu Principal
2. Faa o pagamento
3. Verifique se o pagamento atualizou o saldo da conta
4. Retorne ao menu principal
5. Acesse a tela de extrato atravs do Menu Principal
6. Verifique a atualizao do saldo da conta
7. Acesse a tela do histrico das operaes atravs da tela de extrato
-21-

8. Verifique a atualizao do histrico das operaes

9. Retorne ao menu principal
Um script de regra de negcio e um script de utilidade geral podem ser
escritos como a seguir:

Pagamento:

Inicie no menu principal

Chame o mtodo de navegao para acessar a tela de pagamento

Leia o arquivo de dados contendo os dados especficos para o teste e

insira esses dados

Pressione o boto ou execute a funo para efetuar o pagamento

Leia o arquivo de dados contendo os dados de sada esperados

Compare esses dados com os dados mostrados na tela (sadas atuais)

Escreva qualquer discrepncia em um relatrio de erros

Pressione o boto ou o link de retorno ao menu principal, ou se

necessrio, execute a funo de navegao para faz-lo.

Verificar Conta (Verificar Extrato e Histrico das operaes):

Inicie no menu principal

Chame o mtodo de navegao para acessar a tela de extrato

Leia o arquivo de dados contendo os dados de sada esperados

Compare esses dados com os dados mostrados na tela (sadas atuais)

Escreva qualquer discrepncia em um relatrio de erros

Pressione o boto ou link para acessar o histrico das operaes

Leia o arquivo de dados contendo os dados de sada esperados

Compare esses dados com os dados mostrados na tela (sadas atuais)

Escreva qualquer discrepncia em um relatrio de erros

Pressione o boto ou o link de retorno ao menu principal ou, se

necessrio, chame a funo de navegao para faz-lo.

-22-

Os scripts da regra de negcio e de utilidade geral chamam as funes que

simulam o usurio para efetuar a navegao. O script do caso de teste deve chamar
esses dois scripts toda vez que precisar executar mtodos de regras de negcio ou de
utilidade geral.
O Driver Script, por sua vez, deve chamar o script do caso de teste pelo
nmero de vezes que for necessrio para executar todos os casos de teste deste tipo.
Para cada tipo, a nica coisa que muda so os dados contidos nos arquivos que so
lidos e processados pelos scripts da regra de negcio e das sub-rotinas. O fluxo do
teste praticamente o mesmo, s mudando os dados de entrada e os de sada,
podendo ser vrios testes de sucesso ou de erro.
Usando este mtodo, se for necessrio processar cinqenta tipos diferentes de
pagamentos para verificar todas as possibilidades, ser necessrio apenas quatro
scripts para modelar e executar todos os cinqenta casos. Os scripts so:
1. O Driver Script
2. O script do caso de teste
a. Efetuar um Pagamento e Verificar os Resultados
3. O script das regras de negcio de Pagamento
4. O script de utilidade geral
a. Verificar Extrato da Conta e Histrico das Operaes
Se fosse usado o mtodo Record & Playback, iriam ser produzidos cinqenta
scripts diferentes, cada um com diferentes dados de entrada e sada no prprio corpo
dos scripts, o que iria dificultar a manutenibilidade desses scripts.
Este mtodo, porm, requer apenas que se adicionem os arquivos com os
dados de entrada e sada de cada teste. Estes dados podem ser facilmente mantidos e
atualizados devido a sua centralizao. A atualizao pode ser feita por pessoas que
no detm conhecimento em ferramentas de automao, scripts ou programao. Isto
significa que testadores sem conhecimento tcnico podem exercer estas funes
enquanto um testador mais tcnico pode criar e manter scripts automatizados.
importante salientar tambm que os scripts de utilidades gerais, os quais
verificam o extrato da conta e o histrico das operaes, podem tambm ser
-23-

utilizados por outros scripts de caso de teste e de funes da regra de negcio. Um

estorno de pagamento, por exemplo. Se fosse necessrio testar cinqenta estornos de
pagamentos seria necessrio desenvolver apenas trs scripts adicionais:
1. O Driver Script
2. O script do caso de teste
a. Estornar Pagamentos e Verificar Resultados
3. O script da regra de negcio do Estorno de Pagamento
Considerando que j existem os quatro scripts anteriores, possvel
rapidamente desenvolver estes trs a partir dos originais. possvel utilizar o script
de utilidades gerais, Verificar Extrato da Conta e Histrico das Operaes, sem
nenhuma modificao.
Se for necessrio utilizar diferentes contas, ser preciso apenas atualizar os
arquivos de dados ao invs de atualizar o script todo. Por este e outros motivos, este
mtodo se torna mais lucrativo do que o mtodo Record & Playback.

4.1.2.

Implementao da Tcnica

Para implementao da tcnica foi usado como inicio o processo Record &
Playback mostrado anteriormente, modificando conforme a necessidade.
Em relao ao processo, as principais mudanas foram na macro-tarefa
Executar Script. A tarefa Executar Navegao, se necessrio foi adicionada para
permitir a independncia da execuo entre casos de testes. Esta tarefa pode ser
chamada depois do relato de alguma exceo ou pela prpria execuo dos casos de
teste.
Outra importante mudana no processo a redefinio da tarefa Relatar
Eventos e Exceo que no pra mais a execuo.
No inicio do processo, os dados de entrada e sada so lidos agora diretamente
das planilhas de projeto de caso de teste. Alm disto, a utilizao de planilhas
tambm ocorre na reportagem da execuo na ltima tarefa do processo: Gerar
Planilhas.
-24-

Figura 10 Processo de Decomposio Funcional

Uma importante mudana no processo foi que a filmagem dos scripts no

ocorre mais como no processo Record & Playback quando todos os scripts de teste
eram gerados a partir de gravaes. Seguindo o novo processo, as filmagens ocorrem
apenas para gerar os scripts auxiliares funes da regra de negcio e funes de
utilidades gerais que sero utilizados pelos scripts de caso de teste, como ser visto
na prxima seo.

-25-

4.2.

Arquitetura do Sistema

O framework proposto neste trabalho composto por quatro scripts principais

e dois subsistemas de acordo com a figura a seguir:

Figura 11 Arquitetura do Sistema

O primeiro script o RationalTestScript, que fornece todas as

funcionalidades bsicas para a utilizao dos scripts de teste no Functional
Tester. Este script disponibiliza para utilizao e extenso funcionalidades
bsicas de leitura e escrita em datapools, identificao e manipulao de objetos
na tela, alm de reportagem de eventos e tratamento de excees durante a
execuo.
Este script fornecido pelo Functional Tester e apresenta as
funcionalidades ainda com pouco detalhamento. As funcionalidades precisam
ser genricas o bastante para se adaptar a qualquer tipo de aplicao sob teste,
mas para o framework proposto, foi feito uma especializao desta classe para
se obter resultados mais precisos nas diversas funcionalidades oferecidas pela
ferramenta.

-26-

Um script raiz precisa ser criado para conter funcionalidades especficas

do processo de testes adotado e da aplicao sob teste. Como no estudo de
caso a aplicao a ser testada uma aplicao web, criou-se o HtmlRootScript.
Este script serve de base para todos os outros scripts de caso de teste, pois
possui funcionalidades modificadas para reconhecimento e manipulao de
objetos, tratamento de eventos e excees, etc.
Depois de criado o script raiz, o DriverScript foi criado para guiar a
execuo dos scripts de caso de testes. O DriverScript responsvel pela
chamada a todos os scripts de teste de acordo com a sute de execuo
escolhida pelo testador.
O TestCaseScript representa um script de caso de testes. Ele contm os
cdigos de fluxo da execuo dos testes automticos e toda vez que
necessrio, ele utiliza os scripts do pacote acoes que so os scripts que
realmente utilizam o software sob teste. Abaixo segue um exemplo dos scripts
disponveis neste pacote:

Figura 12 Arquitetura do pacote acoes

Dentro do pacote acoes esto os scripts de funes da regra de negcio e de

propsito geral que sero usados por scripts de caso de teste. Esta modularizao
traz benefcios para a manutenibilidade dos scripts de teste e para a robustez da
execuo dos scripts.
A manutenibilidade beneficiada pela concentrao em um nico local das
funes atreladas regra de negcio da aplicao sob teste. Operaes como
inicializao da aplicao, navegao at o menu principal, entre outras, ficam
concentradas em um nico local, deixando os scripts de teste mais auto-contidos.
-27-

J a execuo beneficiada pela independncia entre os scripts de teste. Se um

script de navegao falhar, o script de caso de teste ou at mesmo o DriverScript ser
capaz de reportar o erro e chamar as funes de inicializar aplicao e de navegao
at o menu principal para dar continuidade execuo dos prximos scripts.
Para fazer a reportagem dos eventos e excees da execuo, foi utilizado o
componente Jakarta POI [5], uma biblioteca Java para acessar arquivos no formato
Microsoft OLE 2, como arquivos Word e Excel. Este componente possibilitou o
acesso aos dados de entrada diretamente das planilhas de projeto dos casos de teste.
A classe GerarDatapool associa um datapool privado a um script de caso de teste e o
preenche com os dados da planilha de projeto de teste. Desta maneira, para alterar
algum dado de entrada basta alterar a planilha de projeto de teste e chamar as
funes da classe CopiarDados para atualizar o datapool.
O pacote POI tambm utilizado para fazer a reportagem da execuo de
teste. Aps a execuo de cada caso de teste, o HtmlRootScript utiliza a classe
ReportarExecucao para reportar todos os eventos e excees ocorridas na planilha de
execuo de teste em planilhas.

Figura 13 Arquitetura do pacote POI

4.3.

Consideraes Finais

Este captulo descreveu a tcnica de criao de scripts por decomposio

funcional que visa a criao de scripts de negcio, de utilidade geral, scripts de casos
de teste e um script para comandar a execuo. Esta arquitetura permite que se
construam scripts mais enxutos, facilitando a manuteno e provendo uma
independncia entre esses scripts durante a execuo, fundamental para uma
execuo robusta.
-28-

No prximo captulo sero apresentados os resultados da utilizao deste

framework em um projeto de desenvolvimento de software em uma fbrica de
software.

-29-

5. Resultados Obtidos
Para testar o framework proposto no captulo 4, foi realizado um experimento
em uma sute de teste selecionada. O objetivo do experimento comparar a
efetividade da automao realizada utilizando o framework com o processo de
execuo manual utilizado no passado. Neste captulo sero descritos o projeto alvo
do experimento, o experimento realizado e avaliao dos resultados encontrados.

5.1.

Contexto

O alvo deste experimento um projeto de um sistema web de uma fbrica de

software. Este projeto foi desenvolvido por vinte oito desenvolvedores e analistas,
quatro projetistas de testes e trs automatizadores de testes durante um ano.
Atualmente, praticamente 75% dos testes funcionais so realizados de forma
manual. O esforo empenhado pelos testadores em realizao de testes de regresso
representa cerca de 30% da fora de trabalho da organizao. A utilizao de testes
automticos na execuo de testes uma das propostas da organizao para reduo
deste esforo.

5.1.1.

Processo de Testes

O processo utilizado para testes funcionais feito em trs etapas:

1) Definir Plano de Testes
2) Definir Projetos de Testes
3) Executar Testes
Na primeira etapa de Definio do Plano de Testes so definidas questes
como:

Alocao de recursos

Definio dos ciclos de execuo de testes

Estratgias utilizadas para os testes de software

Escopo dos Testes

Cronograma dos Testes

-30-

Durante a segunda etapa, os projetos de testes so definidos e documentados

os casos de testes baseados nos documentos de requisitos do projeto.
Na ltima etapa, de execuo dos testes, os projetos de casos de testes so
utilizados para a execuo manual dos testes projetados.
Este tipo de abordagem pode levar a um excesso de tempo gasto na execuo
dos testes, deixando de re-executar testes passados quando novas funcionalidades
so adicionadas ao projeto.
Testes funcionais que sero executados diversas vezes podem dar maior e
melhor resultado se forem automatizados, conforme veremos no relato do
experimento realizado neste trabalho.

5.1.2.

Escopo do Experimento

O experimento usou como amostra uma sute de uma das aplicaes testadas
pela organizao. A aplicao em questo, denominada A1 possui 64 sutes de teste,
formando um conjunto de 7005 casos de teste. Os ciclos de teste so compostos,
normalmente, por aproximadamente 2200 casos de teste.
O ltimo ciclo de regresso realizado pela organizao em setembro de 2006
possua 2219 casos de teste, demandando um esforo considervel para sua execuo.
A automao de parte destes testes pode trazer um grande retorno e economia
de esforo para a organizao. Para a realizao do experimento foi necessrio
selecionar uma sute da aplicao A1. A sute de testes que foi alvo de automao,
denominadas aqui de S1, possui 791 casos de teste dos quais 732 foram
automatizados em trs meses.
A automao de testes modificou o processo utilizado pela empresa colocando
mais um passo entre as tarefas de Definir Projetos de Testes e Executar Testes. Agora,
existe uma tarefa para Automatizar os Testes, que consiste no desenvolvimento de
scripts de teste que iro executar automaticamente na tarefa de execuo dos testes.

5.2.

Anlise dos Resultados

Para avaliar resultados obtidos atravs da aplicao do framework proposto no

processo de testes da fbrica de software ser calculado o retorno do investimento,
-31-

utilizando como guia mas com algumas mudanas que sero explicadas mais
adiante o artigo de VARGHESE sobre retorno de investimentos de projetos de
automao de testes de software [16].
Para realizar uma anlise comparativa entre a abordagem manual e
automatizada alguns dados e premissas devem ser considerados:

Aps a automao de testes algum esforo deve ser considerado para

sua manuteno corretiva e evolutiva. Foi levado em conta um tempo
equivalente a 2% do esforo de automao para manuteno dos casos
de teste automatizados antes de cada ciclo de execuo quinzenal.

Esta anlise considera que o custo homem/hora de um testador

equivale ao custo homem/hora de um programador dedicado
automao de testes que de trs mil reais mensais, incluso salrio e
encargos, ou R$18,75 por hora.

O hardware usado tanto para automatizar os testes, quanto para

executar os testes manuais e automticos so os mesmo, um PC comum
de dois mil reais.

O clculo de retorno de investimento considera igual a necessidade de

espao fsico para executar testes manuais ou automticos, o que pode
no ser verdade em alguns projetos.

A seguir sero levantados todos os custos e melhorias da rea de testes devido

automao para se fazer o clculo do tempo de retorno do investimento em
automao feito na fbrica de software.

5.2.1. Custos da Automao

A automao de testes envolve custos fixos e variveis. Os componentes dos
custos fixos, os que ocorrem uma nica vez para cada esforo de automao, esto
listados na tabela 1. Na maioria das vezes, este componente ter uma participao
considervel no custo total do esforo de automao.
Os custos fixos so compostos por:

Custo da ferramenta: uma licena do Rational Functional Tester mais

doze meses de suporte incluso.

-32-

Custo para construo dos scripts: utilizao de um automatizador por

um perodo de trs meses, salrios e encargos.

Esforo tanto para testar e validar, quanto para documentar os scripts

de teste: em mdia 10% do esforo para sua construo.

Custo da infra-estrutura: um computador pessoal para ser usado pelo

automatizador de teste.

Custos Fixos
Custo da ferramenta
Esforo de script de teste
Esforo de testar e validar os scripts
Custo da infra-estrutura de automao
Esforo de documentao das sutes de teste
Total

Valores
R$ 21.150,50
R$ 9.000,00
R$ 900,00
R$ 2.000,00
R$ 900,00
R$33.950,50

Tabela 1 Custos Fixos da Automao de Testes

A tabela 2 lista os componentes do custo varivel da automao. Estes custos

aconteceram para todos os ciclos de testes que executarem os testes automatizados
durante o desenvolvimento do software em questo. Estes custos so:

Custo da manuteno dos scripts: em mdia 2% do custo de sua

criao.

Custo da infra-estrutura: o custo de manter o computador da

automao, 10% do preo inicial, onde iro rodar todos os testes
automatizados.

Custo da execuo: o custo do automatizador durante duas horas para

fazer a coleta dos dados do relatrio da execuo dos testes
automatizados.

Custos Variveis
Manuteno dos scripts e de sua documentao
Manuteno da infra-estrutura da automao
Custo da execuo
Total

Valores
R$ 180,00
R$ 200,00
R$ 37,50
R$417,50

Tabela 2 Custos Variveis da Automao de Testes

-33-

5.2.2. Custos dos Testes Manuais

Como tanto a entrada da execuo dos testes manuais quanto da automao
dos testes so os projetos dos casos de testes, os nicos custos associados aos testes
so os custo da prpria execuo manual e de sua infra-estrutura. Estes custos so:

Custo da execuo: Segundo histrico da fbrica de software onde foi

feito o experimento, o tempo mdio de uma execuo de teste manual
de 2 minutos e 18 segundos, que multiplicado pela quantidade de casos
de testes, 791, d um total de 30,32 horas com um valor de R$ 18,75 por
hora.

Custo

da

infra-estrutura:

custo

da

manuteno

de

cinco

computadores para execuo dos testes manuais.

Custos Variveis
Manuteno da infra-estrutura da execuo manual
Custo da execuo
Total

Valores
R$1.000,00
R$ 568,50
R$1.568,50

Tabela 3 Custos Variveis dos Testes Manuais

5.2.3. Melhorias na execuo dos testes

Para calculo dos benefcios da automao de testes necessrio calcular a
melhoria no custo de execuo dos testes automatizados em comparao com os
testes manuais.
O custo inicial para o desenvolvimento dos scripts de teste faz parte do custo
fixo dos testes automatizados, pois este valor ser diludo a cada novo ciclo de testes
executado.
A diminuio do custo da execuo de testes ocorrer principalmente pela
reduo do tempo da execuo dos testes.
5.2.3.1. Melhorias no tempo de execuo dos testes
Como dito anteriormente, o tempo total de execuo da sute de 30,32 horas
ou 109.158 segundos.
J o tempo mdio da execuo de um teste automatizado foi obtido a partir da
execuo de 732 casos de testes que levaram ao todo quatro horas e dez minutos para

-34-

executar. Tirando uma mdia do tempo da execuo de todos os casos de testes,

chegamos ao valor de 20,49 segundos para execuo de cada caso de testes
automatizados. Mas o valor para efeito de comparao deve ser o valor da execuo
da sute inteira. Devemos levar em considerao tambm os cinqenta e nove casos
de testes que no puderam ser automatizados.
Desta forma, o tempo total da execuo dos testes aps automao so quatro
horas e dez segundos da execuo dos testes automatizados, ou 14.410 segundos,
somado com 8.142 segundos que d um total de 23.992 segundos.
Calculando a melhoria entre a execuo manual e automtica, chegamos ao
valor de 78,02% de melhoria no tempo da execuo.
5.2.3.2. Melhorias no custo de execuo dos testes
Para calcular a melhoria nos custos da execuo dos testes, podemos
simplesmente diminuir o custo da execuo manual pela execuo automatizada e
dividir pelo custo da execuo manual.
Tendo um custo de execuo manual equivalente R$1.568,50 e o custo da
execuo automatizada de R$417,50, temos uma melhora de 73,38% de melhoria no
custo da execuo.
Este benefcio ser utilizado para calcular o retorno do investimento da
automao de testes de software.

5.2.4. Retorno do Investimento

A automao de testes uma melhoria do processo de teste. Isto no deve ser
visto apenas como uma atividade de engenharia que encaixada como parte da
atividade de teste. A eficcia e a eficincia deste processo devem ser medidas e
validadas baseadas em objetivos organizacionais.
Para se fazer tal validao ser calculado o retorno do investimento para o
projeto da automao com uma frmula um pouco diferente da apresentada no
artigo de VARGHESE [16].
A frmula descrita no artigo no leva em conta algumas variveis importantes
no clculo do ROI de um projeto de automao de testes. Para calcular o benefcio de
automao o artigo utiliza a varivel melhoria do tempo da execuo. Porm, a
-35-

varivel correta seria a melhoria no custo da execuo, porque se uma execuo

automtica leva 10% do tempo de uma execuo manual, mas utiliza um servidor
muito caro e sofisticado que custa um milho de dlares, esta varivel deveria entrar
na conta do retorno do investimento. Outro fator que refora a mudana da varivel
que o tempo da execuo j influi no seu custo, por isso a varivel custo muito
mais representativa do que o tempo.
Para se fazer tal validao ser calculado o retorno do investimento para o
projeto da automao a partir da seguinte equao:
N = F / (M * S) , onde:

Varivel

N. de ciclos para o ROI

Custo fixo da automao
Custo dos testes manuais por ciclo
% da reduo de custo da execuo dos testes

Sigla
N
F
M
S

Tabela 4 Variveis do ROI da automao de testes

Utilizando a formula acima para calcular o ROI do projeto de automao,

somente com a S1 automatizada, temos os seguintes valores:
N. de ciclos = C. fixo / (C. dos testes manuais * % da reduo de custo)
N. de ciclos = 33.950,50/ (1.568,50* 73,38%)
N. de ciclos = 33.950,50/ 1.150,96
N. de ciclos = 29,49 ciclos
O grfico abaixo mostra os custos da execuo manual em comparao com o
custo total da automao. Quando o grfico da execuo manual se encontra com o
da automao, ocorre o break-even, ou o retorno do investimento na automao. Neste
momento todo o dinheiro investido em automao foi recuperado devido economia
feita com os testes manuais, o que segundo os clculos acima ocorre com 29,49 ciclos
de execuo de testes.

-36-

Figura 14 Comparao dos custos de execuo automtica e manual por ciclo

5.3.

Consideraes Finais

Este captulo apresentou o relato do experimento realizado para comprovar a

eficincia do framework proposto na automao de casos de teste.
O experimento comparou o investimento realizado e o tempo necessrio para
retorno deste investimento ao selecionar casos de teste utilizando o mtodo proposto
com os dados relativos execuo de testes sem a aplicao da automao dos testes.
O framework mostrou-se bastante eficaz ao reduzir significativamente a
necessidade de esforo da execuo dos testes, com uma melhoria do tempo de
execuo de 78,02% e de custo da execuo de 73,38%.
Do ponto de vista do retorno do investimento em automao, possvel
visualizar claramente que o framework utilizando a ferramenta proposta foi um
investimento um pouco alto, com um retorno de investimento em aproximadamente
29 ciclos de testes. Levando em conta o histrico da fbrica de software analisada, em
um ano de desenvolvimento foram executados vinte e quatro ciclos de testes, o que
daria um retorno de investimento em aproximadamente um ano e trs meses.
-37-

Apesar de ter melhorias to expressivas nos nmeros da execuo dos testes

possvel perceber que as variveis para se decidir entre automatizar ou no um
projeto de testes devem ser bem mais elaboradas do que somente a reduo do
tempo e do custo da execuo dos testes.

-38-

6. Concluses e Trabalhos Futuros

Este trabalho possibilitou, baseado na experincia do desenvolvimento da
automao dos testes funcionais em uma fbrica de software, confirmar a
importncia da utilizao de frameworks para auxiliar na automao de testes de
software. O uso da tcnica de decomposio funcional tambm auxiliou na produo
de um conjunto de componentes enxutos e que contemplavam os requisitos dos
projetos de teste.
O framework se mostrou eficiente com a construo de scripts que utilizam
melhor o reuso de cdigo e possuem uma maior independncia de execuo, o que
permitiu executar todos os testes ininterruptamente sem que precisasse algum ficar
observando a execuo dos testes.
Este trabalho permitiu tambm fazer uma anlise detalhada da ferramenta
Rational Functional Tester e dos recursos oferecidos por ela para o desenvolvimento
de scripts para automao de testes. Mesmo com todas as deficincias, o Rational
Functional Tester mostrou-se ser uma plataforma com bastante potencial para o
desenvolvimento de scripts de teste, com suporte a vrios recursos, e a possibilidade
de extenso de diversas funcionalidades bastante interessantes.

6.1.

Dificuldades Encontradas

As principais dificuldades encontradas no desenvolvimento deste trabalho

foram com relao a grande necessidade de conhecimento da linguagem de script
utilizado pela ferramenta para se obter o mximo de benefcio dos recursos da
linguagem e da ferramenta e a fragilidade do reconhecimento de objetos na tela por
todas as ferramentas utilizadas neste trabalho.
Outro aspecto o fato de os engenheiros de teste alm de manter o plano de
teste com os todos os dados especficos de testes, devem replic-los nos vrios
arquivos de dados que sero utilizados pelos scripts de teste, isto dificultou um
pouco a manuteno dos scripts de teste.

-39-

6.2.

Trabalhos Futuros

Para dar continuidade a este trabalho, podemos identificar as seguintes

utilizaes do framework proposto:

Utilizar o framework em outros projetos de testes de software para se

analisar o impacto tanto no tempo e custo da execuo quanto no
tempo de retorno do investimento.

Melhorar a identificao dos objetos atravs de funes especficas para

o domnio da aplicao sob teste. A identificao de objetos de interface
grfica continua sendo uma tarefa muito difcil que diminui
consideravelmente a viabilidade e rentabilidade da automao de
testes.

A possibilidade de se fazer testes na fachada. Os testes funcionais dos

mtodos da fachada so testes muito fceis de automatizar e aumentam
consideravelmente a cobertura dos testes funcionais em sistemas que
utilizam tal padro de projeto.

-40-

Referncias
[1] FEWSTER, M., GRAHAM D., Software Test Automation, Addison-Wesley, 1999.
[2] HENDRICKSON,

E.,

Build

or

Buy

it?

Disponvel

em:

http://www.qualitytree.com/feature/biobi.pdf Acessado em: 25/06/2006.

[3] IBM Rational Functional Tester User's Guide, IBM Corporation.
[4] IBM Software - Rational Functional Tester Product Overview. Disponvel em:
http://www-306.ibm.com/software/awdtools/tester/functional/.

Acessado

em:

25/06/2006.
[5] JAKARTA POI - Java API To Access Microsoft Format Files. Disponvel em:
http://jakarta.apache.org/poi/. Acessado em: 11/09/2006.
[6] KANER, Cem. Improving the Maintainability of Automated Test Suites, 1997.
Disponvel em: http://www.kaner.com/lawst1.htm. Acessado em: 25/06/2006.
[7] KANER, C.; Falk, J.; Nguyen, HQ. Testing Computer Software. Second Edition,
Willey, 1999.
[8] KELLY, Michael. Introduction to IBM Rational Functional Tester 6.1. Disponvel em:
http://www-128.ibm.com/developerworks/rational/library/04/r-3228/index.html.
Acessado em: 25/06/2006
[9] MERCURY

QuickTest

Professional.

Disponvel

em:

http://www.mercury.com/us/products/quality-center/functionaltesting/quicktest-professional/ Acessado em: 22/09/2006.

[10]

PETTICHORD, Bret. Success with Test Automation, 2001. Disponvel em:

http://www.io.com/%7Ewazmo/succpap.htm. Acessado em: 25/06/2006.

[11]

PRESSMAN, Roger S. Engenharia de Software, Sexta Edio, McGraw-Hill,

2006.
[12]

QARUN

Product

Detail.

Disponvel

em:

http://www.compuware.com/products/qacenter/401_ENG_HTML.htm. Acessado
em: 20/09/2006.
[13]

ROBINSON, Ray. Automation Test Tools Comparison, 2001. Disponvel em:

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&O
bjectId=2861 Acessado em: 25/06/2006.
[14]

SOMMERVILLE, Ian. Engenharia de Software, 6 Edio, Addison Wesley,

2003.

-41-

[15]

STEP up the pace of functional & regression testing. Disponvel em:

http://www.segue.com/products/functional-regressional-testing/silktest.asp.
Acessado em: 22/09/2006.
[16]

VARGHESE, Jose. Test Automation An ROI based Approach. Disponvel

em: http://www.softwaredioxide.com/channels/Content/jose_wipro.pdf. Acessado

em: 01/10/2006.
[17]

ZAMBELICH, Keith. Totally Data-Driven Automated Testing. Disponvel em:

http://www.sqa-test.com/w_paper1.html. Acessado em: 25/06/2006.

-42-

APNDICE A - Comparao entre Ferramentas

de Automao de Testes Funcionais
notvel a variedade de opes no Mercado de ferramentas de automao de
testes tanto em termos dos tipos das ferramentas de teste que esto sendo oferecidas,
quanto do nmero de vendedores.
A melhor ferramenta para uma situao particular depende do ambiente em
que o sistema funciona e da metodologia de teste que ser usada, que por sua vez
dir como a automao ser usada para suportar o processo.
Este apndice avaliar as principais marcas de ferramentas de automao
baseado nas caractersticas de cada ferramenta, ir testar a capacidade de execuo,
qualidade do mapeamento de objetos da tela, capacidade de integrao da
ferramenta, suporte a ambiente e extensibilidade. As seguintes ferramentas sero
avaliadas Compuware QARun [12], Mercury QuickTest Professional [9], Rational
Functional Tester [4] e Borland Segue SilkTest [15].
No final deste apndice ser construda uma matriz entre cada ferramenta e as
categorias da avaliao, tirada do artigo de Ray Robinson [13]. Esta matriz prov
uma maneira rpida e fcil de consultar as caractersticas de cada ferramenta de
automao de teste. Os critrios para a escolha da ferramenta.
A descrio detalhada de cada categoria utilizada na matriz ser dada a
seguir.
1. Record & Playback
Ao automatizar, esta a primeira coisa que um profissional de teste faz. Ele
vai gravar um script, observar o seu cdigo e reproduzi-lo.
Esta categoria detalha:
a. O quo fcil gravar e reproduzir um teste
b. Se a ferramenta suporta gravao baixo-nvel (movimentos do mouse,
localizao exata na tela, etc.).
c. O quo fcil ler um arquivo de script que foi gerado pela ferramenta.
-43-

2. Testes Web
Cada vez mais a internet est presente nas aplicaes corporativas. Desta
maneira, as ferramentas de testes devem prover funcionalidades para testes de
sistemas com arquitetura cliente/servidor. Para tal, as ferramentas devem prover
suporte para tabelas HTML, frames, diversas plataformas, links, etc.
Os critrios desta categoria so:
a. Existem funes que avisam quando uma pgina acabou de carregar?
b. Existem funes que permitem esperar at carregar uma imagem?
c. Pode-se testar quando um link vlido ou no?
d. Podem-se testar os dados e as propriedades dos objetos web?
e. Existe diferenciao entre os tipos e a localizao de objetos?
f. Existe diferenciao entre os campos da pgina? Como ttulo, corpo,
etc.
3. Mapeamento de Objetos
As ferramentas de automao de testes devem saber identificar e manipular
objetos na interface com o usurio. A maioria dos objetos produzidos iro se
comportar da mesma forma de objetos padro de tela como: botes, check boxes,
botes de rdio, listas, edit boxes e combo boxes.
A ferramenta trabalha bem com estes controles padres? possvel adicionar
controles customizados com novas classes de controle? Estas so algumas questes
que sero investigadas nesta categoria ao utilizar as ferramentas.
4. Extensibilidade
Esta seo est relacionada com a possibilidade de extenso da ferramenta. Se
a ferramenta no suportar determinada funcionalidade possvel criar uma? Este
geralmente um assunto avanado e requer um bom conhecimento em linguagem
de programao.
Algumas ferramentas provem extenses permitindo criar funes mtodos e
classes, porm apenas utilizando tipos e funes j pr-definidas pela ferramenta ao
invs de permitir a extenso da ferramenta alm das suas funcionalidades.
Provavelmente um programador vai querer utilizar funcionalidade de outras
-44-

naturezas, como bibliotecas do sistema operacional ou componentes disponveis no

mercado.
5. Suporte a Ambiente
A ferramenta suporta a ltima verso de Java, Oracle, WAP, etc.? Muitas
ferramentas permitem criar classes, dll`s, etc. para se comunicar com ambientes no
suportados.
Esta uma importante parte da automao, se a ferramenta no suporta o
ambiente da aplicao sob teste isto pode ser um grande problema, e provavelmente
ser melhor utilizar testes manuais.
6. Integrao
Como as ferramentas se integram com outras ferramentas? Isto est se
tornando cada vez mais importante hoje em dia. A ferramenta permite executar
testes a partir de diversas sutes de teste? Existe alguma integrao com ferramentas
como o Word, Excel ou de gerenciamento de requisitos?
Quando se est gerenciando um projeto de automao de maior porte a
integrao com outras ferramentas se torna mais explcito. Como gerenciar os bugs
encontrados, os testes executados automaticamente e manualmente, e quais testes
foram executados e quando, sem ter informaes perdidas ou duplicadas? Possuir
um conjunto de ferramentas integradas neste momento pode ser um diferencial
competitivo para a empresa.
Matriz
Cada categoria na matriz dada uma avaliao entre 1 e 5.
1 = nenhum suporte.
2 = somente suportado por chamada de APIs ou de um plug-in.
3 = suporte bsico apenas.
4 = bom suporte, mas existe um melhor suporte.
5 = suporte satisfatrio.
A matriz foi construda usando estes conjuntos de valores para cada critrio
descrito acima. Para cada ferramenta foi somado um total de pontos para ajudar no
-45-

processo da avaliao. Quanto maior a soma de pontos melhor a ferramenta, mas

importante relatar que esta uma avaliao subjetiva e baseada na experincia do

Record &
Playback

Teste de Web

Mapeamento de
Objetos

Extensibilidade

Suporte a
ambiente

Integrao

Total

autor utilizando cada uma das ferramentas avaliadas.

QuickTest
QARun

5
5

5
5

3
3

4
4

5
5

4
4

26
26

SilkTest
Functional Tester

5
5

5
5

3
3

5
5

5
5

5
5

28
28

Tabela 5 Matriz de comparao entre Ferramentas de Automao de Testes Funcionais

-46-