UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC

CENTRO DE CINCIAS TECNOLGICAS CCT

DEPARTAMENTO DE CINCIA DA COMPUTAO

ISMAEL MNCHEN

AUTOTEC: UMA FERRAMENTA DE AUTOMAO DE TESTES

PARA INTERFACES DINMICAS

JOINVILLE SC
2010

II

ISMAEL MNCHEN

AUTOTEC: UMA FERRAMENTA DE AUTOMAO DE TESTES

PARA INTERFACES DINMICAS

Trabalho de Concluso de Curso apresentado

Universidade do Estado de Santa Catarina,
como requisito para a obteno do ttulo de
Especialista em Computao Aplicada.
Orientador: Dr. Edson Murakami

JOINVILLE SC
2010

III

ISMAEL MNCHEN

AUTOTEC: UMA FERRAMENTA DE AUTOMAO DE TESTES

PARA INTERFACES DINMICAS

Trabalho de Concluso de Curso aprovado como requisito parcial para a obteno do grau de
Especialista, no curso de Especializao em Computao Aplicada na Universidade do Estado
de Santa Catarina.

Banca Examinadora:
Orientador:

___________________________________________________________
Dr. Edson Murakami
Universidade do Estado de Santa Catarina

Membro:

___________________________________________________________
Dr. Roberto Silvio Ubertino Rosso Jr.
Universidade do Estado de Santa Catarina

Membro:

___________________________________________________________
Dr. Marco Aurlio Wehrmeister
Universidade do Estado de Santa Catarina

Joinville SC, 08 de Setembro de 2010

IV
RESUMO

Organizaes desenvolvedoras de software tm cada vez mais voltado suas atenes

para a melhoria dos processos relacionados qualidade como, por exemplo, o teste de
software. A automao dos testes de regresso uma medida que vem sendo tomada com o
objetivo de melhorar esta fase do ciclo de vida do desenvolvimento, tornando os testes mais
rpidos e baratos. Para se ter um processo de automao de testes eficiente, deve-se utilizar
ferramentas compatveis com a tecnologia de desenvolvimento, caso contrrio, pequenas
modificaes na interface do usurio (GUI) podem consumir quantidades considerveis de
tempo, recursos humanos e dinheiro na tarefa de manuteno dos scripts utilizados por essas
ferramentas. Para aumentar os benefcios da automao dos testes de regresso foi
desenvolvido o AutoTec, uma ferramenta que reconhece as alteraes de interface e diminui a
necessidade de manuteno em script de teste. Atravs dos estudos de caso realizados neste
trabalho, foi possvel comprovar o sucesso do AutoTec na identificao de vrias situaes,
como alterao da disposio e retirada de componentes de interface, sem necessidade de
manuteno dos scripts de teste.

PALAVRAS-CHAVE: Qualidade de Software, Teste de Software, Teste Automatizado.

V
ABSTRACT

Software development organizations have increasingly turned their attention to the

improvement of related quality processes such as, for example, the test software. The
automation of regression testing is a measure that has been done in order to improve this
phase of the development life cycle, making testing faster and cheaper. To have a test
automation process efficient, we must use tools compatible with the technology development,
otherwise small changes in the user interface (GUI) can consume considerable amounts of
time, manpower and money on maintenance task the scripts used by these tools. To increase
the benefits of automation of regression testing has been developed AutoTec, a tool that
recognizes the changes of interface and reduces the need for maintenance in the test script.
Through case studies in this study, we demonstrate the success of AutoTec in identifying
various situations, such as changing the layout and removal of interface components without
the need for maintenance of test script.

KEYWORDS: Software Quality, Software Testing, Automated Testing.

VI
LISTA DE ILUSTRAES

Figura 1: Componentes do TOTVS Metadados. ......................................................................15

Figura 2: Paradigma bsico para os testes automatizados. .......................................................20
Figura 3: Script de teste. ...........................................................................................................22
Figura 4: Exemplo de script do AutoIt. ....................................................................................24
Figura 5: Visualizao dos componentes do Accessible Explorer. ..........................................26
Figura 6: Script de teste do Sikuli (CHANG et al., 2010). .......................................................27
Figura 7: Detalhes do processo do AutoTec. ............................................................................31
Figura 8: Diagrama de sequncia do mdulo de gravao do caso de teste. ............................32
Figura 9: Diagrama de sequncia do mdulo de execuo do caso de teste. ...........................32
Figura 10: Script gerado pelo AutoTec. ...................................................................................33
Figura 11: Captura dos dados de entrada no AutoTec. .............................................................34
Figura 12: Opes de Menu gravadas na tabela options. .........................................................35
Figura 13: Valores associados a cada componente gravados na tabela values. ........................35
Figura 14: Interface do sistema aps as modificaes no TOTVS Metadados. .......................36
Figura 15: Caso de teste de incluso executado com sucesso. .................................................37
Figura 16: Script de teste gravado no Sikuli. ............................................................................38
Figura 17: Script de teste gravado no TestComplete 8. ............................................................38
Figura 18. Script de teste gravado no Rational Robot. .............................................................39
Figura 19: Componentes similares imagem do script identificados pelo Sikuli....................41
Figura 20: O aumento do nvel de similaridade removeu componentes indesejados. ..............41
Figura 21: Cdigo interno diferente para um mesmo componente. .........................................42
Quadro 1: Comparativo entre ferramenta de teste automatizado. ............................................40

VII
LISTA DE ABREVIATURAS

AdvPL

Advanced Protheus Language

Ajax

Asynchronous JavaScript and XML

API

Application Programming Interface

CASE

Computer-Aided Software/System Engineering

CSAIL

Computer Science and Artificial Intelligence Laboratory

DVD

Digital Video Disc

ERP

Enterprise Resource Planning

GUI

Graphical User Interface

HTML

HyperText Markup Language

IDE

Integrated Development Environment

JSP

JavaServer Pages

MIT

Massachusetts Institute of Technology

RUP

Rational Unified Process

SQL

Structured Query Language

TDD

Test-Driven Development

V&V

Verificao e Validao

XML

Extensible Markup Language

WIMP

Window, Icon, Menu, Pointing Device

WYSWYG

What You See Is What You Get

VIII
SUMRIO

1 INTRODUO .....................................................................................................................9
1.1 OBJETIVOS .......................................................................................................................10
1.1.1 Objetivo Geral .................................................................................................................10
1.1.2 Objetivos Especficos ......................................................................................................10
1.2 ESTRUTURA DA MONOGRAFIA ..................................................................................11
2 MATERIAIS E MTODOS ...............................................................................................12
2.1 QUALIDADE DE SOFTWARE ........................................................................................12
2.2 VERIFICAO E VALIDAO DE SOFTWARE ........................................................12
2.3 FERRAMENTAS CASE ....................................................................................................13
2.3.1 TOTVS Metadados ..........................................................................................................14
2.3.2 GeneXus ..........................................................................................................................16
2.3.3 Maker ...............................................................................................................................16
2.4 TESTE DE SOFTWARE ...................................................................................................17
2.5 AUTOMAO DE TESTE ...............................................................................................18
2.5.1 Tcnicas de Automao para Teste de Regresso ...........................................................20
2.6 TRABALHOS RELACIONADOS ....................................................................................24
2.7 CONSIDERAES ...........................................................................................................27
3 O AUTOTEC E SUA ABORDAGEM ...............................................................................29
3.1 ESTUDO DE CASO...........................................................................................................34
3.2 COMPARATIVO ENTRE FERRAMENTAS ...................................................................37
3.3 LIMITAES DO AUTOTEC ..........................................................................................42
4 CONCLUSO ......................................................................................................................43
4.1 TRABALHOS FUTUROS .................................................................................................45
REFERNCIAS......................................................................................................................46
ANEXOS..................................................................................................................................50

9
1 INTRODUO
No propsito de melhorar a qualidade de seus sistemas, as empresas tm cada vez
mais voltado suas atenes para os processos de testes, proporcionando uma grande economia
em correes de software mal produzidos (BRUNELI, 2006). A partir da dcada de 90, com a
utilizao da Internet para a realizao de negcios, houve uma mudana na abrangncia e
complexidade das aplicaes, onde fatores como segurana e desempenho passaram a ser
relevantes, tornando a atividade de testar cada vez mais especializada (FILHO e RIOS, 2006).
Com isso, os testes precisam ser mais rigorosos em encontrar falhas e consumir o menor
tempo possvel para permitir que se entregue os produtos mais rapidamente, utilizando-se
menos recursos e com menos falhas.
Algumas medidas podem ser tomadas para obter testes melhores, mais rpidos e
baratos. Costa (2004) cita algumas:

Sistematizar as atividades de testes;

Definir os papis e responsabilidades vinculadas ao teste;

Antecipar a preparao dos testes j durante as fases de construo;

Conhecer as tcnicas relacionadas ao tema;

Testar caractersticas diferentes do software nas diferentes fases de testes;

Estimar adequadamente os esforos para os testes;

Ter um controle efetivo das falhas encontradas;

Automatizar os testes de regresso;
Pesquisas

mostram

que

os

testes

de

regresso

automatizados

aumentam

consideravelmente a qualidade do software por serem executados muito mais rapidamente que
os testes manuais (DUSTIN, 1999; FEWSTER, 1999), e pelo aumento da frequncia com que
podem ser testados sem a necessidade de aumento de recursos humanos (GRECHANIK et al.,
2009).
Para se ter um processo de automao de testes eficiente, a ferramenta a ser utilizada
deve ser bem avaliada, pois muito comum que ela no corresponda s expectativas em
relao aos ganhos que se espera com a sua implantao. Embora acene com a possibilidade
de nos levar a uma situao extremamente produtiva, a implementao de testes
automatizados pode criar tantos problemas quanto resolv-los (PETTICHORD, 2001).
Vrias ferramentas de automao de testes disponveis no mercado utilizam script de
teste, que um arquivo que contm uma lista de instrues que diz como elas devem simular

10
o teste de regresso da mesma forma que feita por um testador. Um recurso muito
importante nessas ferramentas conseguir localizar na GUI (Graphical User Interface) o
componente especificado no script de teste de forma automtica. Ferramentas que no
possuem este recurso so chamadas de capture/replay, e fazem com que o teste automatizado
para de funcionar caso ocorra alguma alterao na GUI (Graphical User Interface) e no seja
feita as devidas manuteno no script (CHANG et al., 2010; GRECHANIK et al., 2009;
JIANYI e ZHENGQIU, 2008; KANER, 2002).
Com o objetivo de evitar ou reduzir a manuteno em script, foi desenvolvido o
AutoTec, uma ferramenta que reconhece as mudanas na interface e altera o script
automaticamente. Este reconhecimento ocorre atravs de uma integrao entre o AutoTec e a
ferramenta CASE (Computer-Aided Software/System Engineering) TOTVS Metadados. Esta
ferramenta de desenvolvimento possui a caracterstica de armazenar todas as informaes
necessrias para a construo da GUI em um banco de dados. Isto permite que o AutoTec
realize leituras nesses dados para identificar as definies atuais da interface e adaptar o script
de teste.
Anlises demonstraram que o AutoTec identificou vrias alteraes na GUI como, por
exemplo, a alterao da ordem dos campos, a retirada de campos, se o campo est habilitado
para edio e a incluso de novos campos, sem a necessidade de alterao do script de teste.
1.1 OBJETIVOS
O objetivo geral e os objetivos especficos para o desenvolvimento deste trabalho
esto descritos na sequncia.
1.1.1 Objetivo Geral
Desenvolver uma ferramenta de automao de teste de regresso, visando evitar ou
reduzir a manuteno em script atravs de uma nova abordagem para a identificao dos
componentes da interface.
1.1.2 Objetivos Especficos
Para alcanar o objetivo geral, os seguintes objetivos especficos devem ser realizados:

Identificar as alteraes na interface do sistema evitando ou reduzindo a
necessidade de manuteno do script de teste.

Compatibilidade com a tecnologia TOTVS Metadados.

11

Capturar os dados de entrada que sero usados no caso de teste de forma
automtica.

Repetir um teste simulando as interaes do usurio.
1.2 ESTRUTURA DA MONOGRAFIA
Inicialmente, feita uma introduo sobre o trabalho realizado, que aborda objetivo e
justificativa. No segundo captulo so apresentadas as bases tericas necessrias para dar
fundamentao pesquisa.
No terceiro captulo o AutoTec tem seu funcionamento detalhado, exemplificado
atravs de um estudo de caso e comparado com trs ferramentas. Por ltimo, as concluses e
trabalhos futuros.

12
2 MATERIAIS E MTODOS
Neste captulo so apresentadas as bases tericas necessrias para dar fundamentao
pesquisa. Ela inicia-se com uma introduo a qualidade de software e atividade de validao e
verificao. Em seguida feita uma introduo sobre ferramentas CASE e apresentada
algumas ferramentas que podero se beneficiar com esta pesquisa como, por exemplo, o
TOTVS Metadados que ser objeto do nosso estudo de caso.
Apresentaremos tambm definies de teste de software, automao de testes, tcnicas
de automao e contribuies relevantes j realizadas que se propem a resolver o mesmo
problema.
2.1 QUALIDADE DE SOFTWARE
Cada vez mais as organizaes tm voltado suas atenes para o propsito de melhorar
a qualidade de seus sistemas e um dos grandes objetivos da engenharia de software a busca
da qualidade. A engenharia de software uma rea da engenharia que trata das caractersticas
de produo de software, desde as etapas iniciais, onde o sistema especificado, at a sua
manuteno (SOMMERVILLE, 2003). Quanto antes o defeito for revelado, menor o custo de
correo e maior a probabilidade de corrigi-lo corretamente. Os custos de descobrir e corrigir
defeitos no software aumentam exponencialmente na proporo em que o trabalho evolui
atravs das fases do projeto (FILHO e RIOS, 2006).
Analisando as metodologias de desenvolvimento existentes, possvel notar um
aumento significativo do tempo destinado ao processo de qualidade de software e a forma
como este processo vem iniciando cada vez mais cedo no ciclo de vida do desenvolvimento.
Nas metodologias clssicas, como a cascata, a qualidade verificada apenas no fim de todo o
processo. No Rational Unified Process (RUP) este processo j ocorre paralelamente com
outros processos desde o projeto lgico. Em metodologias geis so utilizadas tcnicas de
desenvolvimento orientado a testes (Test-Driven Development TDD) onde os testes
unitrios so criados antes mesmo da codificao. J se defende inclusive que o processo de
qualidade de software deve ser tratado como um projeto independente (FILHO e RIOS,
2006).
2.2 VERIFICAO E VALIDAO DE SOFTWARE
A Verificao e Validao (V&V) est associada a cada uma das atividades do
processo de software. Um dos seus objetivos assegurar que o software funcione de acordo

13
com o que foi especificado pelos interessados. Essas atividades constituem um processo
iniciado com as revises dos requisitos, passando pelas revises dos modelos de anlise do
projeto de software e as inspees do cdigo at chegar aos testes (SOMMERVILLE, 2003).
A validao de um software consiste em controlar se o mesmo est de acordo com os
requisitos do sistema. A verificao de um software consiste em controlar se o mesmo est
sendo construdo de acordo com os padres definidos (PETERS e PEDRYCZ, 2001).
A diferena entre verificao e validao explicada de forma sucinta com as
seguintes perguntas (BOEHM, 1979):

Validao: estamos construindo o produto correto?

Verificao: estamos construindo certo o produto?

As tcnicas de V&V podem ser estticas ou dinmicas. As revises so consideradas

tcnicas estticas por no envolverem a execuo do sistema. Elas analisam e verificam as

diversas fases do processo de desenvolvimento. Abrangem os documentos de requisitos, os
diagramas de anlise e de projeto e o prprio cdigo fonte. As tcnicas dinmicas de V&V
utilizam a execuo do software para se obter informaes (PETERS e PEDRYCZ, 2001). O
teste de regresso um exemplo de tcnica dinmica.
2.3 FERRAMENTAS CASE
Vrias metodologias, tcnicas e ferramentas vm sendo desenvolvidas e aprimoradas
para garantir qualidade e produtividade do software. O aumento da complexidade dos
sistemas vem exigindo cada vez mais esse apoio durante as fases do ciclo de vida do software.
Neste cenrio surgem s ferramentas CASE que auxiliam o desenvolvimento atravs da
automatizao de vrias tarefas, que muitas vezes so repetitivas, diminuindo os erros e
aumentando a produtividade.
Segundo o padro ISO/IEC 14102 ferramenta CASE um produto de software que
pode auxiliar engenheiros de software atravs do apoio automatizado para atividades do ciclo
de vida de software conforme definido na ISO/IEC 12207 (ISO, 1995, p. 3). A ISO/IEC
14102 um padro que lista as funes e caractersticas das ferramentas CASE.
Muitas organizaes de desenvolvimento de software tm adotado ferramentas CASE
na tentativa de melhorar a maneira como o software desenvolvido (LARA e FORTES,
2004). Essas ferramentas podem ser classificadas de acordo com as etapas do processo de
desenvolvimento em que atuam. As ferramentas que atuam nas primeiras fases do ciclo de

14
desenvolvimento de um projeto de software (ex.: requisitos e projeto) chamadas de Front End
ou Upper CASE. As que so utilizadas nas ltimas fases do ciclo, como por exemplo,
compiladores, ferramentas de teste, so chamadas de Back End ou Lower CASE. Ferramentas
que cobrem todo o ciclo de vida do software so chamadas de I-CASE ou Integrated CASE
(MCMURTREY et al., 2000).
Uma das caractersticas que algumas ferramentas CASE possuem a gerao
automtica da interface do usurio atravs de atributos e regras. Essas interfaces normalmente
podem ser alteradas atravs de ambientes visuais que permitem arrastar e agrupar os
componentes. Todas as informaes de como a interface grfica deve ser criada ficam
armazenadas em bases de dados ou em arquivos. Isso possibilita a escolha da linguagem de
programao (JAVA ou .NET) e o ambiente (Web ou WIMP - Window, Icon, Menu, Pointing
Device) que o sistema ser gerado mantendo os mesmos componentes da interface. A seguir
citaremos algumas ferramentas que possuem estas caractersticas.
2.3.1 TOTVS Metadados
O TOTVS Metadados uma ferramenta proprietria da TOTVS do tipo Back End que
apia o desenvolvimento de seus sistemas ERP (Enterprise Resource Planning). Suas
principais caractersticas so a gerao automtica das interfaces do software; a
implementao de funcionalidades bsicas como, por exemplo, incluso de dados, excluso
de dados, modificao de dados e relatrios; criao automtica das tabelas no banco de dados
e gerenciamento de integridade.
Esta ferramenta composta por uma srie de cadastros que so alimentados pelos
analistas e que sero utilizados para gerar as interfaces dos sistemas e algumas
funcionalidades de forma automtica. Os cadastros mais utilizados so o de tabelas, que
contm as informaes sobre uma tabela fsica do banco de dados. O cadastro de formulrio e
de processamento, onde so definidas as caractersticas das interfaces. O cadastro de barra de
ferramenta, onde so cadastrados os botes e seus eventos. As barras de ferramentas so
associadas a uma interface de formulrio ou de processamento. Por ltimo, o cadastro de
Zoom, onde so criadas interfaces de seleo para campos associados a uma chave
estrangeira.
Todas as informaes necessrias para gerar a interface do sistema como, por
exemplo, o tipo dos campos (edit, checkbox, combobox), os tamanhos, a ordem, as descries,
as propriedades como visibilidade e editabilidade, esto disponveis em uma base de dados.
Durante a execuo do sistema o prprio TOTVS Metadados se encarrega de instanciar e

15
organizar os componentes na interface. Caso seja necessrio alterar a ordem de um campo na
interface ou torn-lo invisvel, basta alterar o cadastro e na prxima execuo do sistema essas
mudanas j sero visveis sem a necessidade de compilao.
Na Figura 1 possvel visualizar os componentes que compes o TOTVS Metadados.
Na camada mais baixa (bloco azul da Figura 1) existe um servidor de aplicao chamado de
TOTVSTEC que tem a finalidade de interpretar os programas a exemplo da mquina virtual
do Java. Este servidor interpreta programas desenvolvidos em duas linguagens: Informix 4GL
(bloco verde da Figura 1) e AdvPL (Advanced Protheus Language) (bloco laranja da Figura
1). O mecanismo principal do TOTVS Metadados (bloco roxo da Figura 1) desenvolvido
nessas duas linguagens e possui recursos de persistncia de dados, tratamento de eventos e
construo da interface grfica. Todas as regras de negcios so implementas em funes com
a linguagem Informix 4GL (bloco vermelho da Figura 1). Estas funes so ento chamadas
pelo TOTVS Metadados, pois tem suas chamadas registradas em seus cadastros.

Figura 1: Componentes do TOTVS Metadados.

A ferramenta de automao de teste de regresso desenvolvida neste trabalho, utiliza

recursos do TOTVS Metadados para implementar uma abordagem de reconhecimento de
componentes da interface que reduz as manutenes nos scripts de teste. Esta abordagem ser
detalhada no captulo 3.

16

2.3.2 GeneXus
GeneXus uma ferramenta desenvolvida pela Artech em 1984. Ela orientada a
eventos e regras onde o principal objetivo do analista focar-se nas regras de negcios que
sero incorporados nos sistemas, pois grande parte das tarefas destinadas a um desenvolvedor
ou administrador de banco de dados feita pela prpria ferramenta como, por exemplo,
normalizao do banco de dados, controle de integridade e gerao de cdigo fonte
(GXTECHNICAL, 2010).
Nesta ferramenta todas as informaes so reunidas em um projeto chamado de base
de conhecimento (Knowledge Base) e so armazenadas em arquivos de texto em pastas do
Windows. A base de conhecimento contm as especificaes dos sistemas e das tabelas do
banco de dados. Em uma base de conhecimento existe o ambiente de especificao, onde o
analista cria as tabelas do sistema. O ambiente de prottipo, onde o desenvolvedor poder
criar prottipos de sistemas usando as tabelas criadas na especificao. E o ambiente de
produo, onde ser gerado o sistema a ser liberado para o cliente (GXTECHNICAL, 2010).
possvel criar vrios ambientes de Prototype ou Production, porm, s poder existir
um ambiente de Design. O motivo que o GeneXus tem a facilidade de gerar seus objetos em
diferentes linguagens como, por exemplo, Java, .NET, Cobol, Fox Pro, entre outras. Algumas
linguagens como Java e .NET permitem gerar sistemas para ambiente Web. em cada
modelo de Prototype ou Production que se define em qual linguagem que os sistemas sero
gerados. Para uma nica base de conhecimento possvel gerar os sistemas para vrias
linguagens e plataformas (Web ou WIMP) diferentes.
Com relao a banco de dados, GeneXus fornece a opo de poder gerar os sistemas
para vrios tipos, como Microsoft SQL Server, DB2, Informix, Oracle, PostgreSQL e MySql
(GXTECHNICAL, 2010).
2.3.3 Maker
O Maker uma ferramenta comercial criada pela Softwell Solutions para o
desenvolvimento de aplicaes Web. Atravs do Maker possvel desenvolver aplicaes
corporativas de forma totalmente visual atravs de fluxogramas e editores WYSWYG (What
You See Is What You Get) (SOFTWELL, 2010).
O Maker composto de uma IDE (Integrated Development Environment), chamada de
Maker, e de um ambiente de execuo, chamado de Webrun. A IDE grava todas as
especificaes do sistema dentro de tabelas especficas criadas num banco de dados. Ela

17
composta por um editor de formulrios utilizado para desenvolver os formulrios da
aplicao; um editor de relatrios que permite construir de forma visual os relatrios; e de um
editor de fluxogramas utilizado para a especificao de regras de negcios e aes. O Webrun
uma mquina virtual sobre a qual as aplicaes so executadas. O Webrun est disponvel
para a plataforma .NET e Java. Ele responsvel por interpretar as especificaes e
disponibilizar a aplicao final para o cliente. Com relao a banco de dados, o Maker suporta
o Microsoft SQL Server, Firebird, PostgreSQL, Oracle e MySQL (SOFTWELL, 2010).
Assim como no GeneXus, ao utilizar o Maker pode-se dar um foco maior nas regras
de negcios da aplicao, ou seja, no necessrio um domnio de vrias tecnologias como,
por exemplo, HTML, JavaScript, Ajax, Java, WebService e SQL, pois a ferramenta se
encarrega em traduzir as especificaes para estas tecnologias.
Com o passar do tempo novas tecnologias so incorporadas no GeneXus e no Maker e
todas as especificaes existentes podero ser convertidas rapidamente para uma nova
linguagem ou banco de dados, sem a necessidade de reescrever os cdigos ou alterar objetos.
2.4 TESTE DE SOFTWARE
Como ferramenta para aumento da qualidade dos produtos, o teste de software uma
atividade que merece destaque pelos resultados alcanados. O principal objetivo do teste de
software revelar a presena de erros no produto. Portanto, o teste bem sucedido aquele que
consegue determinar casos de teste para os quais o sistema em teste falhe (MYERS, 1979).
Outra definio importante diz que o teste o processo de avaliar um sistema ou um
componente de um sistema, por meios manuais ou automticos, para verificar se ele satisfaz
os requisitos especificados ou identificar diferenas entre os resultados esperados e obtidos
(ANSI/IEEE Standard 729, 1983).
A fase de teste, em qualquer metodologia, deve ser tratada como uma das etapas mais
importantes para uma empresa desenvolvedora de software. Ela aumenta consideravelmente a
probabilidade do software funcionar corretamente e atender as necessidades do cliente, pois
diversas falhas podem ocorrer durante o ciclo de vida do desenvolvimento de software como,
por exemplo, no especificar corretamente os requisitos ou no ter mtricas adequadas para a
definio dos prazos (MOLINARI, 2008).
Uma das tcnicas de teste muito utilizada na fase de validao do software o teste de
regresso. Os testes de regresso so utilizados para confirmar se as mudanas realizadas no
software no afetaram outra parte do mesmo, ou seja, todos os testes relacionados so refeitos
novamente. Este tipo de teste muito importante e necessrio, pois a experincia tem

18
mostrado que o percentual de novas falhas introduzidas ou defeitos no completamente
corrigidos durante a manuteno do software alto (SOMMERVILLE, 2003; REPASI,
2009).
Sem uma ferramenta, o custo para realizar o teste de regresso cresce
consideravelmente e pode torn-lo invivel. Com uma ferramenta, o custo de dois ou trs
meses de trabalho pode cair para um ou dois dias, ou at mesmo horas ou minutos,
dependendo do volume de testes e da ferramenta (MOLINARI, 2008). Uma vez que o teste de
software frequentemente responsvel por at 40% de todo o esforo despendido num projeto
de desenvolvimento de software, as ferramentas que podem reduzir o tempo de teste (sem
reduzir a eficcia) so muito valiosas (PRESSMAN, 1995).
2.5 AUTOMAO DE TESTE
A automao de testes tem ganhado uma enorme importncia em decorrncia do
crescimento e do aumento da complexidade dos sistemas. Vrios tipos de testes como, por
exemplo, testes de regresso, testes de desempenho e estresse, s se tornam viveis atravs da
automao dos testes. O custo necessrio para se testar o desempenho de uma aplicao sob o
funcionamento de centenas de usurios, ou se testar um conjunto de milhares de casos de teste
ao lanar uma nova verso muito alto. Mesmo sendo possvel executar o teste utilizando um
grande nmero de usurios isso no garante um bom teste, pois necessrio que um mesmo
recurso seja acessado por todos os usurios ao mesmo tempo.
Alm das ferramentas de automao de teste de regresso, existem vrios outros tipos
que auxiliam a execuo e automao de testes. Molinari (2008), apresenta algumas
categorias destas ferramentas:

Test Design ou Planejamento de Teste: ajudam a projetar os testes permitindo criar
requisitos para o incio do projeto de teste e escrever os casos de teste;

GUI Test Drivers com Command Script: automatizam os testes de regresso com a
utilizao de script de teste. Estas ferramentas so utilizadas para repetir as aes de
um testador na GUI do software. O script criado comando a comando de forma
manual;

GUI Test Driven com Visual Script: idntico ao anterior, porm, existe o auxilio de
uma ferramenta que dispensando a codificao manual dos scripts. Eles so gerados
automaticamente capturando as aes realizadas no software;

19

Load & Performance: esta ferramenta auxilia no aumenta da demanda do sistema para
avaliar o seu comportamento em condies extremas. Este tipo de teste pode ser
realizado para avaliar um processamento atravs da gerao de um grande volume de
dados, ou para avaliar um site atravs do acesso de uma grande quantidade de usurio
ou para avaliar a opo de carregamento de arquivo de um editor de texto atravs da
criao de um grande arquivo;

Code Coverage: ajudam a monitorar a cobertura dos testes no nvel de cdigo fonte,
mostrando quais partes do cdigo ainda no foram testadas;

Static Analysis: ajudam na anlise do cdigo fonte sem execut-lo. Pode ser usado
para validar padres e mtricas de codificao como, por exemplo, quantidade de
linhas por mtodo, quantidade de condies (IF) aninhadas, padro de declarao de
variveis, etc;

Defect Tracking: ajudam no gerenciamento de defeitos encontrados;

Unit Test: ajudam nos testes unitrios permitindo, por exemplo, testar uma nica
funo verificando se ela retorna os valores corretos a partir de uma entrada de dados;
Os testes de regresso exigem a execuo do software, e normalmente requerem uma
quantidade considervel de recursos humanos que interagem com o sistema e verificam se o
seu comportamento est de acordo com os requisitos. Esta tarefa acaba se tornando cansativa
e repetitiva, o que torna este tipo de teste um timo candidato a automao (CHANG et al.,
2010; GRECHANIK et al., 2009).
Kaner (2002) define as seguintes etapas como paradigma bsico para os testes
automatizados que tambm est exemplificada atravs de um fluxograma na Figura 2:

Especificar um caso de teste e execut-lo manualmente;

Se o sistema falhar no teste, gere um relatrio sobre o problema. Quando o problema

for corrigido refaa o teste;

Se o sistema passar no teste, automatize com uma ferramenta para este fim e capture
as sadas e telas. Salve o caso de teste e as sadas;

Na prxima vez, execute o teste automatizado nas mesmas condies e compare sua
sada com as salva. Se as sadas forem iguais o sistema passou no teste;

20

Figura 2: Paradigma bsico para os testes automatizados.

A ferramenta de automao de testes de regresso deve ser uma escolha importante,

porm, outros fatores podem influncias para o fracasso do processo de automao. Seguir
uma metodologia de automao essencial para que o teste automatizado no se torne mais
um fardo a ser sustentado. O teste automatizado um processo complexo e exige
planejamento similar ao de um projeto de software. A falta de uma reflexo e pesquisa a
respeito do processo de automao, normalmente o leva ao fracasso. Alguns enganos comuns
a respeito do processo de automao j foram documentados como, por exemplo, subestimar
o custo da automao, subestimar a necessidade de formao de pessoal, esperar ser mais
produtivo a curto prazo, tentar automatizar 100% do sistema, no documentar, delegar os
testes apenas aos programadores (KANER, 2002).
2.5.1 Tcnicas de Automao para Teste de Regresso
Um dos recursos muito utilizado por ferramentas de automao de testes de regresso
a utilizao de script de testes (CHANG et al., 2010; GRECHANIK et al., 2009; JIANYI e

21
ZHENGQIU, 2008; FENG e ZHUANG, 2007). Os scripts so uma traduo dos casos de
teste para uma linguagem compreensvel pelas ferramentas e compreendem uma serie de
comandos como, por exemplo, opes do software a serem executadas, cliques do mouse a
serem dados em certa posio da interface, dados a serem digitados nos campos de entrada,
etc. O scripts ir dizer de que forma o software ser testado.
Com a utilizao do script de teste, surge um problema que est relacionado com a
identificao dos componentes da interface durante um novo ciclo de teste, ou seja, a
ferramenta deve ser capaz de localizar o componente da interface para saber qual valor dever
inserir. Caso a ferramenta de automao utilize uma tcnica onde as sequncias dos eventos a
serem disparados estejam de forma fixa (tcnica de capture/replay), e ocorram alteraes na
interface do sistema a ser testado, o script de teste relacionado a este sistema dever ser
adaptados.
A Figura 3 mostra um exemplo de script de teste criado na ferramenta AutoIt (2010)
que executa um software hipottico com os campos Empresa, Lista de preo e Data de
validade. Neste teste o script est preparado para digitar 01 no campo Empresa, 01 no
campo Lista de preo e 31/12/2010 no campo Data de validade. Em seguida ele d um
comando de confirmar para finalizar um teste de incluso de um registro.
Se no decorrer da vida deste software o campo Cliente for includo antes do campo
Data de validade, este script de teste ir falhar, pois ir digitar o contedo 31/12/2010 no
campo Cliente e deixar em branco o campo Data de validade. Este script de teste dever
ser alterado para prever o novo campo. Se a ferramenta de teste for capaz de identificar cada
componente da interface ela ento pularia o novo campo e continuaria com o teste.

22

Figura 3: Script de teste.

Memon et al. (2003), relatou casos onde 74% dos casos de testes exigiam manuteno
dos scripts aps alteraes de interface (do total de 400 casos de teste, 296 no puderam ser
reutilizados). Grechanik et al. (2009), tambm relatou casos onde simples modificaes na
interface exigiam que cerca de 30% a 70% dos scripts sofressem manuteno. Sua pesquisa
tambm aponta custos em torno de $50 a $120 milhes por ano com manutenes em script
realizadas por uma empresa de tecnologia. Por estes motivos, no recomendada a utilizao
de ferramentas que utilizam tcnicas de capture/replay para a automao de teste de regresso
(KANER, 2002).
Uma tcnica que possibilita a identificao automtica dos componentes da interface
um recurso essencial numa ferramenta de automao de teste de regresso. Vrias ferramentas
atuais j possuem estas caractersticas, porm, o script de teste continua sendo esttico. Se no
exemplo anterior fosse retirado um campo da interface, o script estaria preparado para digitar

23
dados em um campo que no existe. Esta operao poderia causar problemas, a menos que o
script fosse todo preparado para prever ou no a existncia dos componentes, e tambm se o
componente est ou no habilitado.
As principais tcnicas utilizadas pelas ferramentas de automao para interagir com os
componentes da interface so as seguintes:

Comandos de script: nesta tcnica um script criado para ser interpretado por um
motor que ter a funo de simular as interaes do usurio. A criao deste script se
assemelha com a codificao de um software onde necessrio o conhecimento da sua
sintaxe. Isso aumenta a complexidade da tcnica, exigindo um grande conhecimento
do testador para desenvolver esse script (CHANG et al., 2010);

Gerao automtica de script (capture/replay): uma evoluo da tcnica anterior.

Nesta tcnica o usurio no precisa criar o script comando a comando. A ferramenta
de teste fica responsvel em identificar as interaes do usurio com o sistema e ento
gera o script automaticamente (GRECHANIK et al., 2009);

Accessibility Technologies: esta tcnica utiliza recursos do Sistema Operacional

(Application Programming Interface - API) que permitem identificar os atributos dos
componentes da interface (identificao, tipo, valor, estado, localizao) e tambm
disparar eventos sobre eles (GRECHANIK et al., 2009). As ferramentas de teste
utilizam esta tcnica para localizar os componentes atravs da sua identificao. Esta
identificao armazenada no script de teste possibilitando a localizao do
componente na prxima execuo;

Parse do cdigo fonte: nesta tcnica feita uma anlise do cdigo fonte para
identificar os componentes da interface facilitando assim a reproduo dos testes
(JIANYI e ZHENGQIU, 2008);

Customizaes especficas: nesta abordagem feita customizaes nas bibliotecas da

tecnologia de desenvolvimento. Estas alteraes possibilitam a identificao dos
componentes da interface e a captura dos dados que sero utilizados em um novo ciclo
de teste (STEVEN et al., 2000);

Viso computacional: nesta tcnica so includas figuras dos componentes diretamente

no script, ou seja, ao invs de gravar a identificao do componente como na tcnica
de Accessibility Technologies, so gravadas as imagens dos componentes. Ao realizar

24
um novo ciclo de teste a ferramenta procura na interface por uma figura semelhante ao
do script (CHANG et al., 2010).
Na prxima seo sero apresentados alguns trabalhos que utilizaram estas tcnicas no
desenvolvimento de ferramentas para teste de regresso.

2.6 TRABALHOS RELACIONADOS

A ferramenta AutoIt (2010) utiliza a tcnica de comandos de script. uma ferramenta
de linguagem de script gratuita para o sistema operacional Microsoft Windows que simula
comandos, eventos do mouse, eventos do teclado, etc. Com o AutoIt possvel criar um script
que simula diversas tarefas que so executadas pelos usurios e possui uma linguagem prpria
para criao de script para automao (Figura 4). Sua utilizao complexa pela necessidade
do conhecimento da sua sintaxe, se assemelhando assim as tarefas de programao. Apesar de
ser utilizada para fazer testes de software, seu foco automatizar tarefas do dia-a-dia como
gravar um DVD ou fazer um backup do sistema (CHANG et al., 2010; BRAND e
BALVANZ, 2005). Neste trabalho foi utilizado funcionalidades do AutoIt para simular as
aes do usurio na interface que est sendo testada como, por exemplo, acionar as opes do
Menu e digitar os valores de entrada.

Figura 4: Exemplo de script do AutoIt.

Jianyi e Zhengqiu (2008) desenvolveram uma ferramenta para realizar testes

funcionais em aplicaes Web baseadas em Apache Struts (2010). O Apache Struts um
framework para desenvolvimento de aplicaes Web com Java Enterprise Edition. A
ferramenta de testes possui quatro mdulos: mdulo de parser das pginas, mdulo de
gerao de casos de teste, mdulo de gerao de cdigo de teste e mdulo de execuo de
teste. O mdulo de parser encarregado de ler os cdigos HTML e JSP para procurar pelos
campos e botes da interface. O mdulo de gerao de casos de teste responsvel por gerar
um arquivo XML com os dados de entrada de cada campo. Os dados de entrada e os

25
resultados esperados ficam armazenados em uma base de dados e so alimentadas pelos
testadores. O mdulo de gerao de cdigo de teste converte o arquivo de caso de teste para o
formato do Cactus (2010). Cactus uma extenso do framework de testes JUnit (2010) para
testes unitrios em aplicaes Java Enterprise Edition. Por ltimo, o mdulo de execuo
executa o cdigo Cactus que envia requisies para a aplicao Web. As respostas so
comparadas com os resultados esperados.
Sun et al. (2004) e Steven et al. (2000), utilizam tcnicas de capture/replay como
forma de automatizar os teste em aplicaes Java. Sun et al. (2004) desenvolveram uma
linguagem para a criao de script de teste que depois convertida para ser utilizada com a
biblioteca Jemmy (2010). A biblioteca Jemmy possui recursos para reproduzir aes do
usurio sobre os componentes da linguagem Java. O objetivo evitar que se programe
diretamente com a biblioteca introduzindo uma linguagem de mais alto nvel, diminuindo a
complexidade da criao do script. J Steven et al. (2000) substituem bibliotecas padres do
Java para criar uma ferramenta chamada jRapture. Uma das alteraes responsvel por
gravar as interaes do usurio realizadas no software. Outra alterao responsvel por
repetir a execuo realizando as mesmas interaes e usando os mesmos dados.
Grechanik et al. (2009), estudaram uma abordagem universal para o desenvolvimento
de ferramentas de automao. Eles abordam o uso de Accessibility Technologies para
identificar os componentes da interface (identificador, tipo, valor, estado, localizao) e
tambm disparar eventos sobre eles. Um exemplo a API do Microsoft Windows chamada de
Microsoft Active Accessibility (MSDN, 2010) que pode ser utilizada para este propsito. A
Figura 5 mostra a utilizao da ferramenta Accessible Explorer que acessa esta API para
identificar os componentes do aplicativo Calculadora. Note que quando selecionado um
componente no Accessible Explorer, o mesmo localizado na aplicao Calculadora (neste
caso o boto oito). Caso o boto oito mude de posio na interface no ser necessrio realizar
manutenes nos scripts de teste das ferramentas que utilizam esta tcnica, porm, se o boto
for retirado da interface podero ocorrer erros durante a reproduo do teste se esta situao
no for prevista.

26

Figura 5: Visualizao dos componentes do Accessible Explorer.

Chang et al. (2010), desenvolveram uma ferramenta chamada Sikuli que utiliza viso
computacional para localizar os componentes da interface e ento disparar eventos sobre eles.
Nesta ferramenta o script criado utilizando imagens para especificar quais componentes da
interface sero acionados e qual o efeito visual que ser esperado como resposta. No script da
Figura 6 testado um aplicativo de media player para verificar se os botes play e pause se
alternam corretamente. Neste script existe uma instruo para clicar no boto play, seguida de
uma verificao se o boto play est ausente, uma instruo para clicar no boto pause,
seguida de uma verificao se o boto pause est ausente e seguida de uma verificao se o
boto play est presente.

27

Figura 6: Script de teste do Sikuli (CHANG et al., 2010).

Esta ferramenta possui tambm um mdulo que auxilia a criao do script permitindo
selecionar reas da tela onde ficam os componentes que sero acionados na reproduo. Estas
reas com as imagens dos componentes vo sendo inseridos automaticamente no script de
teste.
2.7 CONSIDERAES
A utilizao das tcnicas de comando de script e gerao automtica de script,
chamadas de capture/replay, ir exigir manutenes no script de teste caso ocorram alteraes
na interface do software. Esta tcnica no possui nenhum recurso para identificar os
componentes da interface (CHANG et al., 2010).
O uso de Accessibility Technologies vem sendo muito utilizado pelas ferramentas
comerciais, porm, nem sempre so compatveis com a tecnologia de desenvolvimento
utilizada. Para que esta tcnica funcione corretamente os compiladores precisam
disponibilizar as informaes dos componentes da interface num determinado padro.
Atualmente o TOTVS Metadados no tem este recurso. A utilizao desta tcnica em
conjunto como TOTVS Metadados ir exigir manutenes no script de teste sempre que a
interface sofrer alterao.
A anlise do cdigo fonte para identificar os componentes da interface no poder ser
utilizada com o TOTVS Metadados porque as definies da interface no esto em arquivos.
O uso da tcnica de viso computacional necessita de uma interface que mantenha as
mesmas caractersticas de tamanhos e distncias entre os componentes da interface. Isto
necessrio para no haver diferenas entre a tela fotografada e a nova tela aps as alteraes.
Como o TOTVS Metadados possui a caracterstica de arranjar os componentes de forma

28
automtica de acordo com o tamanho dos componentes, algumas alteraes exigiriam
manutenes no script de teste.
A incompatibilidade entre as tcnicas de automao pesquisadas e o TOTVS
Metadados motivou a utilizao de uma nova abordagem atravs de customizaes
especificas. Est escolha se deve pela disponibilidade do cdigo fonte do TOTVS Metadados
e pela sua caracterstica de manter as informaes da interface em uma base de dados o que
facilita sua leitura e interpretao.

29
3 O AUTOTEC E SUA ABORDAGEM
Algumas ferramentas de desenvolvimento possuem a caracterstica de converter os
objetos criados para vrias plataformas (Web e WIMP) e tecnologias (Java e .Net) diferentes.
Outras tornam possvel alterar o formato da interface atravs de simples parametrizaes. Se a
ferramenta de teste automatizado no for flexvel no reconhecimento dos componentes da
interface o script de teste precisar ser alterados com frequncia. Essas ferramentas de
desenvolvimento so includas na categoria de Ferramentas CASE, pois apiam a fase de
desenvolvimento com a automatizao de vrias tarefas.
Este trabalho desenvolveu uma ferramenta de automao de teste de regresso, que
minimiza a necessidade de manutenes em script de teste. A idia principal da abordagem do
AutoTec foi utilizar as informaes disponveis em uma ferramenta CASE para poder gerar os
scripts de forma automtica e dinmica. Automtica pelo fato do script ser gerado sem a
necessidade de codificao por parte dos usurios. Dinmico pelo fato do script se adaptar de
acordo com os componentes que esto na interface.
Como o TOTVS Metadados possibilita alteraes na interface de forma dinmica,
essencial que a ferramenta de teste seja flexvel na identificao dos componentes. Isto
possvel para o AutoTec porque ele est lendo a mesma base de dados que o TOTVS
Metadados utiliza para construir as interfaces. Assim, possvel saber se algum componente
teve sua ordem alterada, ou se algum componente passou a ficar desabilitado ou invisvel, ou
at mesmo reconhecer a incluso de um novo componente.
O AutoTec composto por dois mdulos: o primeiro mdulo grava os dados de
entrada do caso de teste; o segundo mdulo l a interface do programa na base do TOTVS
Metadados e juntamente com os dados de entrada gera o script de teste. Este script
interpretados pelos recursos do AutoIt, que se encarrega de simular as interaes do usurio.
Para a captura dos dados de entrada foram feitas duas modificaes nas bibliotecas do
TOTVS Metadados. Uma na funo que controla a execuo das opes do Menu, onde so
gravados os nomes das opes executadas e a ordem em que foram executadas. Esses dados
so gravados na tabela options (Anexo A). A outra modificao foi feita na funo que
controla a sada do cursor nos componentes, onde so gravados os valores digitados e o nome
do componente. Esses dados so gravados na tabela values (Anexo B).
O processo detalhado na Figura 7. Em uma opo do AutoTec (1) aberta uma caixa
de dilogo onde possvel informar o cdigo do programa que ser executado. O prprio
AutoTec se encarrega em executar o programa a ser testado. Este programa carregado na

30
regio branca (2) do AutoTec. Durante a execuo, os dados que so informados pelo usurio
e as opes de Menu utilizadas so armazenadas numa base de dados (3). Isso ocorre devido
s alteraes especficas que realizam inseres nas tabelas utilizadas pelo AutoTec. Nestas
tabelas so gravadas informaes como, por exemplo, o nome do programa, o nome da opo
de Menu, o nome do componente e o seu valor informado. A execuo e a finalizao do
programa em teste identificam o incio e o fim de um caso de teste.
Por outra opo do AutoTec possvel solicitar a execuo do caso de teste (4). Est
opo faz a leitura dos programas executados (2) e em seguida faz a leitura das opes de
Menu acionadas durante este caso de teste. Se a opo de Menu possuir a caracterstica de
habilitar os componentes da interface para a digitao, inicia-se o processo de leitura dos
componentes que pertencem interface. Estas informaes so lidas diretamente na base do
TOTVS Metadados (5). Nesta etapa vrios atributos dos componentes da interface so
levados em considerao como, por exemplo, a ordem dos componentes, se o componente
est visvel e se est habilitado. Para cada componente feita uma consulta do seu dado de
entrada nas tabelas do AutoTec (6).
Caso seja encontrado um componente que no possui um valor de entrada, ou seja, um
componente que foi recm includo no sistema, ser automaticamente utilizado o valor padro
deste componente cadastrado no TOTVS Metadados. Se o valor deste componente for
relevante para o teste ser necessrio associar um valor de entrada para este componente antes
da execuo do caso de teste.
Com as informaes do TOTVS Metadados e dos dados de entrada o AutoTec gera
um arquivo com vrios comandos para construir o script de teste na linguagem do AutoIt (7).

31

2
1

Dados de
Entrada

AutoTec

Gerao de
Script de Teste

7
Script de Teste

5
Base
TOTVS
Metadados

Figura 7: Detalhes do processo do AutoTec.

Na Figura 8 possvel visualizar o diagrama de sequncia que representa a fase de

gravao do caso de teste. Na Figura 9 possvel visualizar o diagrama de sequncia que
representa a fase de execuo do caso teste.

32

Figura 8: Diagrama de sequncia do mdulo de gravao do caso de teste.

Figura 9: Diagrama de sequncia do mdulo de execuo do caso de teste.

33
Na Figura 10 possvel visualizar o script gerado pelo AutoTec. Nas linhas de 1 at 6
so includos comandos para executar o sistema que ser testado. O comando Send utilizado
para simular a utilizao do teclado onde possvel acionar opes do Menu e a digitao de
informaes nos componentes. O comando Send(^i) da linha 11 equivalente ao comando
CTRL + I. Durante a execuo do script, o sistema em teste interpreta este comando e ento
aciona o boto de Incluso.
Quando os componentes da interface so habilitados, o TOTVS Metadados joga o
cursor automaticamente para o primeiro componente do software. Como se sabe previamente
a ordem dos componentes da interface atravs da leitura do banco de dados, basta digitar o
seu valor e em seguida usar o comando de TAB para ir ao prximo componente. Este
processo se repete at o ltimo componente e em seguida procurado pelo prximo comando
de Menu executado.
O comando Send(01) na linha 17 utilizado para digitar a informao 01 no campo
Empresa. O comando Send({TAB}) na linha 18 utilizado para ir para o prximo
componente. O comando Sleep(1000) na linha 19 diz para o AutoIt aguardar 1 segundos antes
de executar o prximo comando. Este tempo necessrio para aguardar algum processamento
de regra de negcio aps a sada de algum componente.

Figura 10: Script gerado pelo AutoTec.

34
Aps o script ser gerados feito uma chamada para o AutoIt repetir as aes na
interface. A cada teste ser gerado um novo script com as definies mais recentes
disponveis na base do TOTVS Metadados. Ou seja, se a ordem dos componentes da interface
for alterada o script ser criado respeitando esta nova ordem ou se um componente for
retirado da interface ele ser ignorado durante a gerao do script.
3.1 ESTUDO DE CASO
Para validar as funcionalidades do AutoTec foi gravado um caso de teste para testar a
funcionalidade de incluso de um cadastro de embalagens desenvolvido pela ferramenta
CASE TOTVS Metadados. Este cadastro foi executado atravs do AutoTec para capturar os
dados de entrada deste caso de teste (Figura 11). No cadastro de embalagens foi utilizada a
opo Incluir para habilitar os componentes da interface para a digitao dos valores do
novo registro. Aps a digitao foi utilizada a opo Confirmar para gravar o novo registro
em seguida o sistema foi finalizado pela opo Sair.

Figura 11: Captura dos dados de entrada no AutoTec.

Na Figura 12 possvel observar as opes de Menu gravadas para o caso de teste e na

Figura 13 os valores associados a cada componente da interface.

35

Figura 12: Opes de Menu gravadas na tabela options.

Figura 13: Valores associados a cada componente gravados na tabela values.

Aps a gravao dos dados de entrada foi utilizada a opo para executar o caso de
teste do AutoTec que gerou o script e reproduziu as aes do usurio atravs do AutoIt. Para
testar a capacidade do AutoTec em reconhecer as alteraes de interface foram feitas algumas
alteraes na interface do cadastro de embalagens atravs do TOTVS Metadados. Neste teste
dois campos foram alterados para ficar invisveis e um terceiro para ficar desabilitado (Figura
14).

36

Figura 14: Interface do sistema aps as modificaes no TOTVS Metadados.

Aps estas alteraes o caso de teste foi executado novamente sem realizar nenhuma
alterao onde foi possvel observar que os componentes que no estavam na interface ou
estavam desabilitados foram ignorados durante a reproduo do script pelo AutoTec, que
efetuou a incluso do registro com sucesso (Figura 15).
Se outras modificaes forem feitas nos cadastros do TOTVS Metadados, quando for
executado o teste pelo AutoTec um novo script ser gerado com as definies mais atuais da
interface. No necessrio guardar o script de teste gerado pelo AutoTec da mesma forma
que ocorre nas demais ferramentas de automao de teste. A cada nova execuo o script do
AutoTec sempre gerado novamente.

37

Figura 15: Caso de teste de incluso executado com sucesso.

3.2 COMPARATIVO ENTRE FERRAMENTAS

Para verificar a eficincia da abordagem utilizada no desenvolvimento do AutoTec foi
realizado um comparativo com outras trs ferramentas de teste automatizado. Neste
comparativo foi observada a capacidade da identificao dos componentes em sistemas
desenvolvidos com o TOTVS Metadados.
As ferramentas utilizadas no comparativo com o AutoTec foram :

Sikuli 0.10.2: ferramenta que utiliza a tcnica de viso computacional para a
identificao dos componentes do sistema a ser testado (Figura 16). uma ferramenta
open-source desenvolvida pelo MIT Computer Science and Artificial Intelligence
Laboratory (CSAIL) (SIKULI, 2010).

38

Figura 16: Script de teste gravado no Sikuli.

TestComplete 8: ferramenta que utiliza a tcnica de Accessibility Technologies para a

identificao dos componentes do sistema a ser testado (Figura 17). uma ferramenta
comercial desenvolvida pela AutomatedQA (2010).

Figura 17: Script de teste gravado no TestComplete 8.

Rational Robot 7.0.3: ferramenta que utiliza a tcnica de Accessibility Technologies

para a identificao dos componentes do sistema a ser testado (Figura 18). uma
ferramenta comercial desenvolvida pela IBM (2010).

39

Figura 18. Script de teste gravado no Rational Robot.

Os testes realizados neste comparativo foram os seguintes:

Verificar se a ferramenta dispe de recursos para auxiliar na criao dos casos de teste
automatizados.

Verificar se a ferramenta capaz de reproduzir o caso de teste de um sistema
desenvolvido em TOTVS Metadados. o teste mais importante onde observada a
capacidade da identificao dos componentes sem alterar a interface original.

Verificar se a ferramenta capaz de reproduzir o caso de teste reconhecendo
alteraes na ordem dos componentes. Neste teste foi alterada a ordem de seis
componentes.

Verificar se a ferramenta capaz de reproduzir o caso de teste reconhecendo
componentes desabilitados. Neste teste foram desabilitados dois componentes.

Verificar se a ferramenta capaz de reproduzir o caso de teste reconhecendo a retirada
de componentes. Neste teste dois componentes foram retirados.

Verificar se a ferramenta capaz de reproduzir o caso de teste reconhecendo a
incluso de componentes. Neste teste dois componentes foram includos.
No Quadro 1 possvel analisar os resultados da comparao. O indicador verde
indica que a ferramenta passou pelo teste com sucesso. O indicador amarelo indica que

40
podero ser feitas adaptaes no script original para prever a situao. O indicador vermelho
indica que ser necessrio regravar o script.
AutoTec

Sikuli

TestComplete

Rational

1
2
2

4
3
4
4

4
5
4
4

Auxilia na criao dos casos de teste

Reproduz o teste sem alterao na interface
Reconhece alteraes na ordem
Reconhece componentes desabilitados
Reconhece a retirada de componentes
Reconhece a incluso de componentes

Quadro 1: Comparativo entre ferramenta de teste automatizado.

Os problemas identificados nas ferramentas, conforme nmeros nos indicadores do

Quadro 1, so listados a seguir:
1. Ao desabilitar um componente da interface a sua cor de fundo alterada para o usurio
poder identificar que seu valor no poder ser alterado. Como o Sikuli trabalha com
imagens o componente do script no ser mais reconhecido, necessitando assim a
utilizao de condies (IF) para prever a falta deste componente. O Sikuli pode
tambm se confundir com componentes parecidos causando a digitao dos dados no
componente errado. Isso pode ocorrer quando o componente de maior similaridade
ficar desabilitado. Para resolver necessrio ajustar similaridade para que o Sikuli no
encontre outro componente similar. Na Figura 19 possvel visualizar os possveis
componentes identificados pelo Sikuli. A cor mais escura indica maior similaridade.
Aps aumentar o nvel de similaridade os componentes menos similares so
ignorados, eliminando assim a possibilidade do Sikuli inserir dados em um
componente incorreto (Figura 20).

41

Figura 19: Componentes similares imagem do script identificados pelo Sikuli.

Figura 20: O aumento do nvel de similaridade removeu componentes indesejados.

42
2. Se a retirada ou a incluso do componente alterar a distncia entre os componentes e
suas descries, ser necessrio regravar o script, pois afetar o reconhecimento da
imagem.
3. Necessita de condio (IF) para prever se o componente est habilitado em tela.
4. A ferramenta no consegue mais reconhecer os componentes porque sua identificao
interna alterada. Isso ocorre porque o TOTVS Metadados no cria os componentes
atribuindo sempre o mesmo identificador a cada execuo. Isto um requisito para os
componentes serem reconhecidos pela Accessibility Technologies. A Figura 21 mostra
a diferena no identificador de um determinado componente (destacado em vermelho).
No script originar foi gravado o identificador da primeira linha. Aps alteraes na
interface o mesmo componente recebeu o identificador da linha dois, causando um
problema na localizao do componente, pois o script de teste tem gravado um
identificador que no existe mais.
Item12.Item.Item.Item
Item3.Item1.Item.Item

Aliases.TotvsSmartClient.wndQWidget.Item.Item.qt_tabwidget_stackedwidget.Item.QWidget.qt_workspacechild.Embalagens.Item1.Item.Item.Item.Item.
Aliases.TotvsSmartClient.wndQWidget.Item.Item.qt_tabwidget_stackedwidget.Item.QWidget.qt_workspacechild.Embalagens.Item1.Item.Item.Item.Item.

Figura 21: Cdigo interno diferente para um mesmo componente.

5. A ferramenta no consegue reconhecer os componentes da interface. Neste caso o

nome interno dos componentes no sofreu alterao.

3.3 LIMITAES DO AUTOTEC

O grande objetivo deste trabalho foi implementar no AutoTec uma abordagem para o
reconhecimento das alteraes da interface, minimizando as alteraes no script de teste.
Apesar de ter atingido este objetivo, o AutoTec possui duas limitaes. A primeira
est relacionada com a validao do caso de teste. O AutoTec ainda no possui recursos para
validar se o caso de teste passou com sucesso como, por exemplo, verificar se um registro
realmente foi includo no banco de dados ou verificar se o calculo de algum campo est
correto.
A segunda est relacionada com a interao dos componentes da interface. O AutoTec
consegue interagir com a interface utilizando apenas os recursos do teclado, o que impede
acessar recursos sem tecla de atalho dificultando o teste de interfaces muito complexas. Para
resolver este problema essencial que se inclua a funcionalidade de interao atravs do
mouse.

43
4 CONCLUSO
A automao de testes, se bem utilizada, uma ferramenta que melhora a qualidade do
software porque diminui o tempo do ciclo de teste e por poder ser utilizada com maior
intensidade sem a necessidade de aumento de recursos humanos. Para a automao de testes
corresponder s expectativas em relao aos ganhos que se espera com a sua implantao, a
escolha da ferramenta de teste deve ser bem avaliada. Ferramentas incompatveis com a
tecnologia de desenvolvimento podem criar tantos problemas quanto resolv-los.
Relatos apresentados demonstraram que ferramentas que no utilizam uma tcnica
capaz de identificar os componentes da interface ou se a interface no fornece as informaes
necessrias para est identificao, iro exigir uma demanda em manuteno de script de
teste. Uma simples modificao da interface pode consumir uma quantia considervel de
tempo, de recursos humanos e dinheiro.
As caractersticas que permitem a adaptabilidade das interfaces em sistemas
desenvolvidos com o TOTVS Metadados, e a incompatibilidade com as ferramentas de teste
disponveis no mercado motivaram o desenvolvimento do AutoTec. Esta ferramenta utiliza
uma nova abordagem para a identificao de componentes de interface para serem utilizados
em teste automatizados. Entre as tcnicas de automao de teste levantadas neste trabalho,
optou-se em realizar customizaes especificas no TOTVS Metadados para a identificao
dos componentes da interface. A escolha desta tcnica se deve pela disponibilidade do cdigo
fonte e pelos dados da composio da interface estar disponvel num banco de dados e,
portanto, serem de fcil acesso. As customizaes nas funes do TOTVS Metadados afetam
apenas a fase de gravao do caso de teste, porm, outras solues poderiam ser dadas como,
por exemplo, elaborar uma matriz onde fosse possvel informar os dados de entrada de cada
componente e as operaes do Menu a serem acionadas sem a necessidade de executar o
sistema a ser testado.
Foi possvel observar atravs de testes a propriedade dinmica do AutoTec pelo fato
do script se adaptar de acordo com os componentes que esto na interface. Vrias alteraes
da interface foram identificadas como, por exemplo, reconhecer alteraes na ordem dos
componentes, reconhecer componentes desabilitados, reconhecer a retirada de componentes e
reconhecer a incluso de componentes. Quando um novo componente identificado o
AutoTec utiliza seu valor padro cadastrado no TOTVS Metadados, necessitando de uma
manuteno no caso de teste apenas se o valor do componente for relevante.

44
Outra vantagem do AutoTec em relao as demais ferramentas est relacionada a
gerao do script de teste. Enquanto para o AutoTec esta etapa imperceptvel para o usurio,
nas demais ferramentas houve a necessidade de interagir diretamente com o script para prever
mudanas na interface como no caso onde houve a necessidade de incluso de condies de
existncia de componentes (IF). Em algumas ferramentas est tarefa pode ser comparada ao
desenvolvimento de um sistema, necessitando de conhecimento em lgica de programao.
Com o AutoTec, em nenhum momento do experimento houve a necessidade de contato com
os scripts de teste para visualizao ou para manuteno, demonstrando assim sua
propriedade automtica.
A limitao do AutoTec em validar se o caso de teste foi executado com sucesso ainda
o impedem de ser um ferramenta utilizvel para a automao de testes de regresso. Outra
deficincia importante, mas no impeditiva, a falta do recurso do mouse na interao dos
componentes da interface. Isto impede o AutoTec de acessar alguns componentes que no so
acessveis com o teclado, como por exemplo, botes do Menu que no possuem tecla de
atalho.
O Sikuli obteve bons resultados no nosso experimento, porm, a caracterstica do
TOTVS Metadados de organizar a interface de acordo com as propriedades de seus
componentes como, por exemplo, seu tamanho e descrio, podem invalidar a imagem
original capturada pelo Sikuli ao adicionar ou retirar algum componente da interface.
Para os sistemas desenvolvidos em TOTVS Metadados serem compatveis com as
ferramentas de automao que utilizam a tcnica de Accessibility Technologies, seria
necessrio adaptar seu compilador para disponibilizar estas informaes, porm, a integrao
do AutoTec com o TOTVS Metadados ainda tem a vantagem da possibilidade de inferir um
valor padro quando um novo componente includo na interface. Ferramentas como o
TestComplete e Rational Robot esto preparados para interagir apenas com os componentes
gravados no script de teste, no sendo capaz de identificar a incluso de um novo componente
na interface e incluir estas instrues de forma automtica no script.
A abordagem utilizada no desenvolvimento do AutoTec pode ser utilizada em outras
ferramentas CASE destinadas ao desenvolvimento de sistemas como, por exemplo, GeneXus
e Maker, pois tambm mantm informaes sobre a disposio dos componentes de tela.

45

4.1 TRABALHOS FUTUROS

O AutoTec foi projetado para resolver um problema especfico e est completamente
integrado com o TOTVS Metadados, porm, a sua abordagem pode ser utilizada para
beneficiar outras ferramentas CASE destinadas ao desenvolvimento de sistemas. Uma soluo
seria elaborar um padro de comunicao para saber como testar um determinado sistema.
Este padro poderia utilizar troca de mensagens em XML onde seriam passadas informaes
dos componentes e seus dados de entrada. Desta forma o AutoTec ser uma soluo
independente. Qualquer ferramenta poder enviar um conjunto de informaes que ser
interpretada para a execuo do teste automatizado.
Vale ressaltar tambm a necessidade de implementar as limitaes do AutoTec quanto
a validao dos casos de teste e a utilizao do recurso do mouse para interagir com os
componentes da GUI. Para esta, pode-se estudar a possibilidade de adaptar a ferramenta
Sikuli com o objetivo de utilizar os seus recursos de interao, unindo assim um timo
recurso do Sikuli e a capacidade do AutoTec em reconhecer as alteraes da GUI.

46
REFERNCIAS

IEEE Std 729-1983. Standard Glossary of Software Engineering Terminology. IEEE,

1983.
APACHE STRUTS. Disponvel em: < http://struts.apache.org > Acesso em: 25 out. 2010.
AUTOIT. Disponvel em: < http://www.autoitscript.com > Acesso em: 25 out. 2010.
AUTOMATEDQA. Disponvel em: < http://www.automatedqa.com > Acesso em: 25 out.
2010.
BOEHM, Barry W. Software Engineering. Yourdon Press, 1979.
BRAND, Jason; BALVANZ, Jeff. Automation is a breeze with AutoIt. In: User Services
Conference, 2005, Monterey. Proceedings... New York: Association for Computing
Machinery, 2005. p. 12-15.
BRUNELI, Marcos V. Q. A utilizao de uma metodologia de teste no processo de
melhoria da qualidade de software. 2006. 64 f. Dissertao (Mestrado Profissional em
Computao) Instituto de Computao, Universidade Estadual de Campinas, Campinas.
2006.
CACTUS. Disponvel em: < http://jakarta.apache.org/cactus > Acesso em: 25 out. 2010.
CHANG, Tsung-Hsiang et al. GUI testing using computer vision. In: Conference on Human
Factors in Computing Systems, 2010, Atlanta. Proceedings New York: Association for
Computing Machinery, 2010. p. 1535-1544.
COSTA, Mozart Guerra. Estratgia de automao em testes: requisitos, arquitetura e
acompanhamento de sua implantao. 2004.102 f. Dissertao (Mestrado Profissional em
Computao) Instituto de Computao, Universidade Estadual de Campinas, Campinas.
2004.
DUSTIN, Elfriede et al. Automated Software Testing: Introduction, Management, and
Performance. Addison-Wesley Professional, New York, 1999.
FENG, Li; ZHUANG, Sheng. Action-driven automation test framework for Graphical User
Interface (GUI) software testing. In: IEEE Systems Readiness Technology Conference
(AUTOTESTCON), 2007, Baltimore. Proceedings Washington: IEEE Computer Society,
2007. p. 22-27.

47
FEWSTER, Mark; GRAHAM, Dorothy. Software Test Automation. Addison-Wesley
Professional, New York, 1999.
FILHO, Trayah R. Moreira; RIOS, Emerson. Teste de Software. Alta Books, Rio de
Janeiro, 2006.
GRECHANIK, Mark et al. Creating GUI Testing Tools Using Accessibility Technologies. In:
International Conference on Software Testing, Verification and Validation Workshops, 2009,
Washington. Proceedings Washington: IEEE Computer Society, 2009. p. 243-250.
GRECHANIK, Mark et al. Maintaining And Evolving GUI-Directed Test Scripts. In:
International Conference on Software Engineering, 2009, Vancouver. Proceedings
Washington: IEEE Computer Society. p. 408-418.
GRECHANIK, Mark et al. Experimental Assessment of Manual Versus Tool-Based
Maintenance of GUI-Directed Test Scripts. In: International Conference on Software
Maintenance, 2009, Edmonton. Proceedings Washington: IEEE Computer Society, 2009.
p. 9-18.
GRECHANIK, Mark et al. GUIDE: A GUI Comparison Tool. In: International Conference on
Software Maintenance, 2009, Edmonton. Proceedings Washington: IEEE Computer
Society, 2009.
GRECHANIK, Mark et al. Inferring Types Of References To GUI Objects In Test Scripts. In:
International Conference on Software Testing Verification and Validation (ICST), 2009,
Denver. Proceedings Washington: IEEE Computer Society, 2009. p. 1-10.
GXTECHNICAL. Disponvel em: < http://www.gxtechnical.com > Acesso em: 25 out.
2010.
HWANG, Sun Myung; CHAE, Hyeon Cheol. Design & Implementation of Mobile GUI
Testing Tool. In: International Conference on Convergence and Hybrid Information
Technology, 2008, Daejeon. Proceedings Washington: IEEE Computer Society, 2008.
p.704-707.
IBM. Disponvel em: < http://www.ibm.com > Acesso em: 25 out. 2010.
International Organization for Standardization. ISO/IEC 14102 Guideline for the evaluation
and selection of CASE tools. Sua, 2008.
JEMMY. Disponvel em: < http://jemmy.dev.java.net > Acesso em: 25 out. 2010.

48
JIANYI, Niu; ZHENGQIU, Yang. An Automated Test Tool of Web Application Based on
Struts. In: International Symposium on Computer Science and Computational Technology,
2008, Shanghai. Proceedings Washington: IEEE Computer Society, 2008. p. 488-490.
JIN, Zhenyi; OFFUTT, Jeff. Integrating Testing with the Software Development Process.
Technical Report ISSE-TR-95-112. 1995.
JUNIT. Disponvel em: < http://www.junit.org > Acesso em: 25 out. 2010.
KANER, Cem. Avoiding Shelfware: A Managers' View of Automated GUI Testing.
Copyright Cem Kaner, 2002.
LARA, S. M. A. Um Suporte captura Informal de Design Rationale. 2005. 135 f.
Dissertao (Mestrado em Cincias da Computao) Instituto de Cincias Matemticas e de
Computao, Universidade de So Paulo, Ribeiro Preto, 2004.
LEWIS, Willian E. Software testing and continuous quality improvement. Auerbach, 2000.
MCMURTREY, Mark E. et al. Current utilization of CASE technology: lessons from the
field. Industrial Management & Data Systems. p. 22 30, 2000.
MEMON, A. M; SOFFA, M. L. Regression testing of GUIs. In: Foundations of Software
Engineering, 2003, New York. Proceedings New York: Association for Computing
Machinery, 2003. p. 118-127.
MOLINARI, Leonardo. Testes Funcionais de Software. Visual Books, Florianpolis, 2008.
MSDN. Disponvel em: < http://msdn.microsoft.com> Acesso em: 25 out. 2010.
MYERS, G. J. The Art of Software Testing. John Wiley & Sons, New York, 1979.
PETERS, James F.; PEDRYCZ, Witold. Engenharia de Software. Campus, Rio de Janeiro,
2001.
PETTICHORD, Bret. Seven Steps to Test Automation Success. STAR West, San Jose,
2001.
PRESSMAN, Roger S. Engenharia de Software. Makron Books, So Paulo, 1995.
REPASI, T. Software testing - State of the art and current research challenges. In:
International Symposium on Applied Computational Intelligence and Informatics, 2009,
Timisoara. Proceedings Washington: IEEE Computer Society, 2009. p. 47-50.
SIKULI. Disponvel em: < http://sikuli.org > Acesso em: 25 out. 2010.

49

SOFTWELL. Disponvel em: < http://www.softwell.com.br > Acesso em: 10 ago. 2010.
SOMMERVILLE, Ian. Engenharia de Software. Pearson Addison Wesley, So Paulo, 2003.
STEVEN, John et al. jRapture: A capture/replay tool for observation-based testing. ACM
SIGSOFT Software Engineering Notes. New York , v. 25, n. 5, p. 158-167, 2000.
SUN, Yanhong; JONES, Edward L. Specification-driven automated testing of GUI-based
Java programs. In: ACM Southeast Regional Conference, 2004, Huntsville. Proceedings
New York: Association for Computing Machinery, 2004. p.140-145.
VIANA, V. M. A. Um Mtodo para Seleo de Testes de Regresso para Automao.
2007.128 f. Dissertao (Mestrado em Cincias da Computao) Centro de Informtica,
Universidade Federal de Pernambuco, Recife 2007.

50
ANEXOS
Anexo A Tabela options
Nome do campo

Tipo de Dado

session_id

Caractere 20

option_id

Inteiro

form_name

Caractere 50

option_name

Caractere 50

Observao
Auto incremento

Anexo B Tabela values

Nome do campo

Tipo de Dado

session_id

Caractere 20

option_id

Inteiro

form_name

Caractere 50

table_name

Caractere 50

column_name

Caractere 50

value

Caractere 500

Observao