FUNDAO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA
CENTRO DE CINCIAS TECNOLGICAS
MESTRADO EM INFORMTICA APLICADA

Rafael Braga de Oliveira

FRAMEWORK FUNCTEST: APLICANDO PADRES

DE SOFTWARE NA AUTOMAO DE
TESTES FUNCIONAIS

Fortaleza, CE - Brasil
Dezembro / 2007

Livros Grtis
http://www.livrosgratis.com.br
Milhares de livros grtis para download.

ii

FUNDAO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA
CENTRO DE CINCIAS TECNOLGICAS
MESTRADO EM INFORMTICA APLICADA

Rafael Braga de Oliveira

FRAMEWORK FUNCTEST: APLICANDO PADRES

DE SOFTWARE NA AUTOMAO DE
TESTES FUNCIONAIS

Dissertao apresentada ao Curso de Mestrado

em Informtica Aplicada da Universidade de
Fortaleza como requisito parcial para obteno
do Ttulo de Mestre em Informtica Aplicada.

Orientador: Prof. Dr. Pedro Porfrio Muniz Farias

Fortaleza, CE - Brasil
Dezembro / 2007

iii

Rafael Braga de Oliveira

FRAMEWORK FUNCTEST: APLICANDO PADRES

DE SOFTWARE NA AUTOMAO DE
TESTES FUNCIONAIS

Data de Aprovao: ____/____/______

Banca Examinadora:

________________________________________________________
Prof. Pedro Porfrio Muniz Farias, D. Sc.
(Prof. Orientador UNIFOR)

________________________________________________________
Prof. Nabor das Chagas Mendona, Ph. D.
(Membro da Banca Examinadora UNIFOR)

________________________________________________________
Prof. Rossana Maria de Castro Andrade, Ph. D.
(Membro da Banca Examinadora UFC)

iv

OLIVEIRA, RAFAEL BRAGA DE

Framework FUNCTEST: Aplicando Padres de Software na Automao de Testes
Funcionais [Fortaleza] 2007
109 p. 29,7 cm (MIA/UNIFOR, M.Sc., Dissertao de Mestrado, 2007)
Dissertao de Mestrado - Universidade de Fortaleza, MIA
1. Automao de Teste
2. Teste Funcional
3. Teste Caixa-preta
4. Teste de Software
5. Teste de Regresso
6. Padres de Software
I. MIA/UNIFOR

II. TTULO (srie)

minha famlia amada:

Eider, Euricla, Adriana, Leonardo e
Letcia.

vi

AGRADECIMENTOS

A Deus, pela aquisio e disseminao de conhecimento decorrentes deste trabalho.

Aos familiares e amigos, pelo carinho e incentivo sempre presentes.
Ao meu orientador, Prof. Dr. Pedro Porfrio Muniz Farias, que sempre esteve
disponvel a enriquecer a minha produo cientfica e a mostrar-me oportunidades de
crescimento acadmico, profissional e humano.
Ao Servio Federal de Processamento de Dados SERPRO, pela concesso de nus
direto e indireto, e por proporcionar-me excelente ambiente para aplicao do conhecimento
adquirido.
Ao membro externo da banca examinadora, Prof. Dr. Rossana Maria de Castro
Andrade (UFC), pela competncia e prontido com as quais acolheu a responsabilidade de
contribuir para o aprimoramento da qualidade cientfica deste trabalho.
Ao membro interno da banca examinadora, Prof. Dr. Nabor das Chagas Mendona,
pelo comprometimento em reservar um precioso espao em sua agenda para partilhar a sua
admirvel competncia em prol do meu amadurecimento acadmico.
Ao Prof. Dr. Jerffeson Teixeira de Souza (UECE), pela disponibilidade em colaborar
direta e indiretamente para o fortalecimento da proposta aqui apresentada, inclusive na coautoria de um dos artigos publicados durante esta minha experincia de pesquisa.

vii

Ao amigo, colega de trabalho e parceiro de pesquisa Francisco Nauber Bernardo Gis

(MIA / SERPRO), pela concretizao das minhas iniciativas de pesquisa, pelo envolvimento
em nossas publicaes, e por estar sempre disposto a colaborar.
Ao mestre, amigo e colega de trabalho Allan Reffson Granja Lima (SERPRO), por ter
me dado a honra de conhecer um pouco do seu potencial intelectual, e por explorar o seu
perfil de disseminador e colaborador em favor deste trabalho.
Ao amigo, pesquisador e colega de trabalho Wesley Evaristo Queiroz de Sousa (MIA /
SERPRO), por compartilhar a sua experincia profissional em meu benefcio.
A todos os que contriburam direta ou indiretamente para a realizao deste trabalho.

viii

Resumo da dissertao apresentada ao Corpo Docente do Curso de Mestrado em

Informtica Aplicada da Universidade de Fortaleza, como parte dos requisitos necessrios
para a obteno do grau de Mestre em Informtica Aplicada.

FRAMEWORK FUNCTEST: APLICANDO PADRES DE SOFTWARE NA

AUTOMAO DE TESTES FUNCIONAIS

Autor: Rafael Braga de Oliveira

Orientador: Pedro Porfrio Muniz Farias, D.Sc.

A execuo automatizada de testes funcionais tem se tornado um evidente atrativo

para empresas de desenvolvimento de software. Tal fato se deve principalmente grande
reduo de custo e ao aumento de produtividade observados a mdio e a longo prazos com o
uso desta prtica. Este trabalho prope um framework para ampliar a reusabilidade e a
manutenibilidade de sutes de teste automatizadas. A soluo foi desenvolvida no SERPRO e
utilizada em projetos reais. O framework, denominado FuncTest, utiliza padres de software e
aplica as tcnicas Data-driven e Keyword-driven na estruturao de sutes de teste
automatizadas. As iniciativas de aperfeioamento do framework visam adapt-lo para a
gerao automtica de testes usando-se a tcnica Model-based Testing.

Palavras-chave: Automao de Teste; Teste Funcional; Teste Caixa-preta; Teste de

Software, Teste de Regresso, Padres de Software.

ix

Abstract of the dissertation presented to the board of faculties of the Master Program
in Applied Informatics at the University of Fortaleza, as partial fulfillment of the requirements
for the Masters degree in Applied Informatics.

FUNCTEST FRAMEWORK: APPLYING SOFTWARE PATTERNS ON

FUNCTIONAL TEST AUTOMATION

Author: Rafael Braga de Oliveira

Advisor: Pedro Porfrio Muniz Farias, D.Sc.

Functional testing automation has become a real interest for software development
teams, mainly because of the great cost reduction and the increase in productivity observed on
medium and long terms with the use of this practice. This dissertation proposes a framework
to improve reusability and maintainability of automated test suites. The proposed solution was
developed at SERPRO and has been used in real projects. The framework, called FuncTest,
applies software patterns and the Data-driven and Keyword-driven techniques to organize
automated test suites. The efforts to improve FuncTest intend to adapt it for generating tests
automatically using the Model-based Testing technique.
Keywords: Testing Automation; Functional Testing, Black Box Testing; Software
Testing, Regression Testing, Software Patterns.

SUMRIO

1. INTRODUO .................................................................................................................... 1
1.1 MOTIVAO...................................................................................................................... 1
1.2 OBJETIVO .......................................................................................................................... 5
1.3 ORGANIZAO DO TRABALHO .......................................................................................... 6
2. AUTOMAO DE TESTES FUNCIONAIS ................................................................... 7
2.1 INTRODUO .................................................................................................................... 7
2.2 TESTE DE SOFTWARE ......................................................................................................... 7
2.2.1 Atividades de Teste ................................................................................................ 9
2.2.1.1 Identificao ............................................................................................ 10
2.2.1.2 Projeto ..................................................................................................... 10
2.2.1.3 Construo ............................................................................................... 11
2.2.1.4 Execuo ................................................................................................. 11
2.2.1.5 Comparao ............................................................................................. 12
2.2.2 Nveis de Teste ..................................................................................................... 12
2.2.2.1 Teste Unitrio .......................................................................................... 13
2.2.2.2 Teste de Integrao.................................................................................. 14
2.2.2.3 Teste de Sistema ...................................................................................... 14
2.2.2.4 Teste de Aceitao .................................................................................. 15
2.2.3 Tcnicas de Teste ................................................................................................. 15
2.2.3.1 Teste Caixa-preta (Black-box) ................................................................. 15
2.2.3.1.1 Particionamento em Classes de Equivalncia ................................. 16
2.2.3.1.2 Anlise de Valor-Limite .................................................................. 17
2.2.3.1.3 Grafo de Causa-Efeito ..................................................................... 18
2.2.3.2 Teste Caixa-branca (White-box) .............................................................. 22
2.2.3.2.1 Teste de Caminho Bsico ................................................................ 23
2.2.4 Tipos de Teste ...................................................................................................... 26
2.2.4.1 Funcionalidade ........................................................................................ 27
2.2.4.2 Usabilidade .............................................................................................. 28

xi

2.2.4.3 Confiabilidade ......................................................................................... 28

2.2.4.4 Desempenho ............................................................................................ 29
2.2.4.5 Suportabilidade........................................................................................ 29
2.2.5 Testes de Regresso ............................................................................................. 30
2.3 FERRAMENTAS PARA AUTOMAO DE TESTES ............................................................... 32
2.4 AUTOMAO DE TESTES FUNCIONAIS ............................................................................ 34
2.4.1 Rational XDE Tester ............................................................................................ 35
2.5 TCNICAS PARA CRIAO DE SCRIPTS ............................................................................. 41
2.5.1 Scripts Lineares ................................................................................................... 42
2.5.2 Scripts Estruturados ............................................................................................ 42
2.5.3 Scripts Compartilhados ....................................................................................... 43
2.5.4 Data-Driven ......................................................................................................... 44
2.5.5 Keyword-Driven .................................................................................................. 45
2.6 CONCLUSO .................................................................................................................... 46
3. O FRAMEWORK FUNCTEST ......................................................................................... 47
3.1 INTRODUO .................................................................................................................. 47
3.2 FRAMEWORKS .................................................................................................................. 50
3.3 PADRES DE SOFTWARE ................................................................................................. 51
3.3.1 Classificao de Padres de Software ................................................................ 53
3.3.2 Padres de Requisitos.......................................................................................... 53
3.3.3 Padres de Anlise .............................................................................................. 54
3.3.4 Padres de Arquitetura........................................................................................ 54
3.3.5 Padres de Projeto .............................................................................................. 55
3.3.6 Metapadres ........................................................................................................ 56
3.3.7 Idiomas (Programming Idioms) .......................................................................... 57
3.3.8 Padres de Teste .................................................................................................. 57
3.3.9 Anti-Padres ........................................................................................................ 58
3.3.10 Coletneas de Padres ...................................................................................... 59
3.4 PADRES UTILIZADOS..................................................................................................... 59
3.4.1 Padro MVC ........................................................................................................ 60

xii

3.4.2 Padro Factory Method ...................................................................................... 61

3.4.3 Padro Data Access Object (DAO) ..................................................................... 62
3.5 ARQUITETURA DO FRAMEWORK....................................................................................... 63
3.5.1 Pacotes do Framework ........................................................................................ 65
3.5.2 Arquivos de Configurao ................................................................................... 65
3.5.2.1 Suite.xml ................................................................................................. 66
3.5.2.2 <NomeDoCasoDeTeste>.xml ................................................................. 66
3.5.2.3 Scripts.xml............................................................................................... 67
3.5.2.4 Banco.xml ............................................................................................... 67
3.5.2.5 DataSource.xml ....................................................................................... 68
3.5.2.6 Erros.xml ................................................................................................. 68
3.6 FUNCIONAMENTO DO FRAMEWORK.................................................................................. 69
3.7 APLICAO DOS PADRES FACTORY METHOD E DAO .................................................... 70
3.8 EXEMPLO DE USO DO FRAMEWORK FUNCTEST ................................................................ 72
3.9 CONCLUSO .................................................................................................................... 76
4. RELATO DE EXPERINCIA E AVALIAO PRELIMINAR ................................ 77
4.1 INTRODUO .................................................................................................................. 77
4.2 PROCESSO DE TESTE DO SERPRO .................................................................................. 77
4.3 EXPERINCIA NO USO DO FRAMEWORK FUNCTEST.......................................................... 80
4.3.1 Experincia do Plo A ......................................................................................... 80
4.3.2 Experincia do Plo B ......................................................................................... 81
4.4 CONCLUSO .................................................................................................................... 83
5. CONCLUSO .................................................................................................................... 84
5.1 RESULTADOS ALCANADOS E TRABALHOS FUTUROS ..................................................... 84
6. REFERNCIAS BIBLIOGRFICAS ............................................................................. 87

xiii

FIGURAS

Figura 1 Custo de Remoo de Defeitos no Ciclo de Desenvolvimento ................................ 2

Figura 2 O Modelo V de Teste de Software (CRAIG, 2002) .................................................. 8
Figura 3 Atividades de Teste, adaptado de FEWSTER et al. (1999) .................................... 10
Figura 4 Nveis de Teste de Software.................................................................................... 12
Figura 5 Nveis de Teste versus Realidade de Ambiente. ..................................................... 13
Figura 6 Smbolos Bsicos de um Grafo de Causa-efeito ..................................................... 19
Figura 7 Exemplo de Grafo de Causa-efeito ......................................................................... 20
Figura 8 Smbolos de Restrio de um Grafo de Causa-efeito.............................................. 20
Figura 9 Exemplo do Uso de Smbolos de Restrio em Grafo de Causa-efeito .................. 21
Figura 10 Simbologia para a criao de Grafos de Fluxo ..................................................... 23
Figura 11 Exemplo de Fluxograma ....................................................................................... 24
Figura 12 Exemplo de Grafo de Fluxo .................................................................................. 24
Figura 13 Exemplo de Lao com duas condies ................................................................. 25
Figura 14 Exemplo de Regresso - Impacto na Mesma Verso ............................................ 30
Figura 15 Exemplo de Regresso - Impacto em Verso Anterior ......................................... 31
Figura 16 Tipos de Ferramentas de Suporte a Testes ............................................................ 33
Figura 17 Link mais - Google ............................................................................................ 36
Figura 18 Link Pesquisa de Livros - Google ..................................................................... 36
Figura 19 Pesquisa de Livros - Google ................................................................................. 36
Figura 20 Retorno da Pesquisa de Livros - Google ............................................................... 37
Figura 21 Exemplo de Script de Teste Rational XDE Tester ............................................. 37
Figura 22 Seleo de Objeto Rational XDE Tester ............................................................ 39
Figura 23 Mapa de Objetos Rational XDE Tester .............................................................. 39
Figura 24 Exemplo de Log de Teste Sem Erros Rational XDE Tester .............................. 40
Figura 25 Exemplo de Log de Teste Com Erros Rational XDE Tester.............................. 41
Figura 26 Exemplo de Aplicao da Tcnica Scripts Compartilhados ................................. 44
Figura 27 Exemplo de Aplicao da Tcnica Data-driven ................................................... 45
Figura 28 Exemplo de Aplicao da Tcnica Keyword-driven ............................................. 46
Figura 29 Granularidade de Scripts de Teste - FuncTest ...................................................... 49
Figura 30 Granularidade de Scripts de Teste - FuncTest ...................................................... 51

xiv

Figura 31 Classificao de Padres de Software Segundo o Ciclo Desenvolvimento .......... 53

Figura 32 Fluxo de eventos e informaes em uma arquitetura MVC .................................. 60
Figura 33 Diagrama de Classes do Padro Factory Method ................................................. 61
Figura 34 Diagrama de Classes do Padro DAO .................................................................. 62
Figura 35 Arquitetura do FuncTest ....................................................................................... 64
Figura 36 Diagrama de Classes do FuncTest ........................................................................ 65
Figura 37 Diagrama de Seqncia Simplificado do framework FuncTest ............................ 69
Figura 38 Uso do Padro DAO para selecionar os dados de teste ........................................ 70
Figura 39 Uso do Padro Factory Method para a criao de scripts de teste ....................... 71
Figura 40 Uso do Padro Factory Method para a criao dos objetos DAO ........................ 71
Figura 41 Formulrio de Criao de Minutas ........................................................................ 72
Figura 42 Macroatividade de Teste - PSDS .......................................................................... 78
Figura 43 Derivao de Casos de Teste a partir de Casos de Uso......................................... 79
Figura 44 Reutilizao de Scripts .......................................................................................... 82
Figura 45 Quantidade de Casos de Teste por Tamanho ........................................................ 83

xv

TABELAS

Tabela 1 Exemplo de Tabela de Deciso - Grafo de Causa-efeito ........................................ 22

Tabela 2 Casos de Teste derivados a partir de uma tabela de deciso .................................. 22
Tabela 3 FURPS x Tipos de Teste ........................................................................................ 27
Tabela 4 Participantes do FuncTest que implementam o Padro DAO ................................ 71
Tabela 5 Classes do FuncTest que implementam o Padro Factory Method........................ 71

xvi

LISTAGENS

Listagem 1 Exemplo de Lao com duas condies ............................................................... 25

Listagem 2 Template de Script de Teste Rational XDE Tester .......................................... 38
Listagem 3 Exemplo de Script Estruturado ........................................................................... 43
Listagem 4 Template para criao do arquivo Suite.xml ...................................................... 66
Listagem 5 Template para criao dos arquivos <NomeDoCasoDeTeste>.xml................... 67
Listagem 6 Template para criao do arquivo Scripts.xml ................................................... 67
Listagem 7 Template para criao do arquivo Banco.xml .................................................... 68
Listagem 8 Template para criao dos arquivos DataSource.xml......................................... 68
Listagem 9 Template para criao do arquivo Erros.xml...................................................... 68
Listagem 10 Trecho do arquivo Suite.xml ............................................................................ 73
Listagem 11 Trecho adaptado do arquivo CriarMinuta-C001_1.xml ................................... 74
Listagem 12 Trecho adaptado do arquivo Banco.xml ........................................................... 74
Listagem 13 Trecho adaptado do arquivo Datasource.xml ................................................... 75
Listagem 14 Trecho adaptado do arquivo Scripts.xml .......................................................... 75
Listagem 15 Trecho adaptado do arquivo Erros.xml ............................................................ 75

Captulo 1
1. Introduo

Este captulo apresenta a motivao, os objetivos e a organizao do trabalho.

1.1 Motivao
A construo de um software uma atividade que pode se tornar bastante complexa.
Dependendo das caractersticas e dimenses do sistema, muitos problemas podem ser
introduzidos. Para que estes problemas no se perpetuem at a entrega do sistema ao cliente,
essencial que o sistema seja devidamente testado. O intuito do teste de software executar
um programa ou um modelo utilizando algumas entradas em particular e verificar se seu
comportamento est de acordo com o esperado (DELAMARO et al., 2007).
Segundo PRESSMAN (2002), teste de software um elemento crtico da garantia de
qualidade de software e representa a reviso final da especificao, projeto e gerao de
cdigo. Isto decorre da falibilidade humana e refora a necessidade de uma constante
preocupao em identificar desvios desde o incio do processo de desenvolvimento. Neste
contexto, embora sejam devidamente revisados os artefatos gerados durante o processo de
desenvolvimento, no se pode garantir que sistemas entregues ao cliente no contenha
defeitos.
DELAMARO et al. (2007) definem defeito (do ingls, fault) como sendo um passo,
processo ou definio de dados incorretos. Tambm afirmam que a existncia de um
defeito pode ocasionar a ocorrncia de um erro (error) durante a execuo de um programa,
que se caracteriza por um estado inconsistente ou inesperado. Tal estado pode levar a uma
falha (failure), ou seja, pode fazer com que o resultado produzido pela execuo seja
diferente do resultado esperado. Eles ressaltam que estas definies no so unanimidades
entre os pesquisadores e engenheiros de software, e que, em particular, o termo erro
utilizado de maneira bastante flexvel, muitas vezes significando defeito ou falha.
Desta forma, durante o desenvolvimento do sistema, importante que a equipe
verifique constantemente os artefatos produzidos para evitar que defeitos se propaguem para
etapas seguintes do processo. Evidentemente, quanto mais tarde um defeito encontrado

maior o custo de sua correo (MYERS, 2004), podendo, em casos extremos, causar danos
irreparveis. Assim, o custo de correo pode ser significativamente minimizado quando
defeitos so encontrados precocemente.
O desafio, ento, encontrar o maior nmero de defeitos possvel nas etapas iniciais
do desenvolvimento, pois quanto mais cedo um erro identificado menor o seu custo de
correo. A Figura 1, adaptada de CRISTALLI (2006), ilustra o custo relativo para remoo
de defeitos durante etapas de um ciclo de desenvolvimento de software. No grfico, o custo de
remoo aumenta medida que se avana no ciclo de desenvolvimento. Por exemplo, a
remoo de um defeito aps o sistema ter sido disponibilizado em Produo pode custar at
80 vezes mais do que custaria se este fosse removido ainda na etapa de definio de
requisitos.

Figura 1 Custo de Remoo de Defeitos no Ciclo de Desenvolvimento

Inmeros estudos ressaltam a importncia de um processo de teste efetivo para

minimizar o custo e proporcionar maior qualidade no desenvolvimento de software. Segundo
DUSTIN (2003), os processos de teste mais efetivos iniciam muito antes de qualquer
programa ser escrito. Neste contexto, testes podem ser planejados desde a etapa de Requisitos.
Testar um software uma tarefa meticulosa e pode se tornar cansativa e pouco
eficiente. Isto motiva a criao de testes que possam ser executados de maneira gil e eficaz.
Portanto, a automao de testes tem se tornado uma alternativa promissora para viabilizar
maior cobertura e maior eficincia durante a execuo de casos de testes. Segundo FEWSTER
et al. (1999), testes manuais que levariam horas para serem concludos, podem ser executados
em minutos, quando automatizados.

Um caso de teste um conjunto de testes executados em seqncia e relacionados a

um objetivo de teste. Um caso de teste produzir um nmero de testes compreendendo valores
de entrada, sadas esperadas e qualquer outra informao necessria para a execuo dos
testes, como pr-requisitos de ambiente (FEWSTER et al., 1999).
Automatizar a execuo de testes significa desenvolver um novo cdigo, portanto
exige um esforo adicional em relao a testes manuais. A principal vantagem desta
abordagem que a execuo automatizada de sutes de teste (conjunto de casos de teste)
bastante gil, tornando possvel repetir a realizao dos testes a um baixo custo e a uma
velocidade significativamente maior.
De acordo com BINDER (1999), a automatizao permite a identificao rpida de
defeitos, agiliza o processo de depurao, permite a captura e anlise dos resultados de teste
de forma consistente e facilita a execuo de testes de regresso, que tm o propsito de
reavaliar o comportamento do software aps modificaes.
Este trabalho enfoca a automao de testes funcionais realizada atravs de ferramentas
Record and Playback. Tais ferramentas recebem este nome por permitirem a realizao de
testes utilizando-se a tcnica Record and Playback, tambm conhecida como Capture and
Replay. Neste caso, os testes seguem uma abordagem caixa-preta, segundo a qual o sistema
testado sob uma perspectiva de usurio final, no sendo considerada a estrutura interna do
programa, como ocorre na abordagem caixa-branca (FEWSTER et al., 1999).
Ferramentas Record and Playback permitem a criao e a execuo de scripts de teste.
Estes scripts codificam aes sobre a interface grfica de usurio (GUI - Graphical User
Interface). Normalmente, os scripts so gerados gravando-se (Record) operaes de um
usurio frente interface da aplicao sob teste, podendo ser alterados ou inteiramente criados
programaticamente. A inteno que estes scripts possam ser executados (Playback), fazendo
a ferramenta simular um usurio realizando as aes codificadas.
De fato, automatizar teste de software significa desenvolver uma aplicao para
verificar o comportamento de outra aplicao, evidentemente mais complexa. Assim, como
qualquer outra aplicao, uma sute de teste de GUI automatizada deve atender a critrios de
qualidade. Segundo FEWSTER et al. (1999), uma sute deve ser:

Manutenvel: a prxima verso da aplicao sob teste tornar alguns scripts

obsoletos, requerendo alteraes em scripts existentes ou criao de novos scripts.

No somente alteraes funcionais na aplicao sob teste como tambm alteraes

em sua interface grfica podem implicar em mudanas nos scripts de teste;

Modular: importante que uma alterao em uma parte da sute de teste no

interfira no comportamento de outra parte;

Robusta: pequenas alteraes na aplicao sob teste no devem requerer um

esforo maior para alterar a sute de teste;

Bem documentada: nem sempre o profissional que mantm a sute o mesmo que
a criou. Mant-la bem documentada facilita a sua manuteno por outro
profissional;

Extensvel: seus componentes devem ser reusveis, para evitar retrabalhos.

As tcnicas Data-driven e Keyword-driven (FEWSTER et al., 1999) tm sido

aplicadas em frameworks (KELLY, 2005; FANTINATO et al., 2004) a fim de tornar as sutes
de teste mais reutilizveis e manutenveis. A aplicao dessas tcnicas certamente contribui
para o reuso e manuteno de scripts de teste, especialmente devido estruturao modular
dos scripts e possibilidade de um mesmo script ser utilizado para diferentes dados. A seo
2.5 apresentar estas tcnicas em maiores detalhes.
A principal diferena entre estes frameworks e o framework aqui apresentado,
denominado FuncTest (OLIVEIRA, 2007a), o uso de padres para ampliar a flexibilidade
das sutes. O FuncTest aplica o padro arquitetural MVC (Model-View-Controller)
(BUSCHMANN, 1996) e os padres de projeto DAO (Data Access Object) (ALUR, 2003) e
Factory Method (GAMMA et al., 1995).
O framework apresentado em Kelly (2005) aplica somente a tcnica Data-driven e est
inteiramente limitado ao mecanismo de persistncia dos dados (denominado datapool) da
prpria ferramenta Record and Playback na qual foi desenvolvido.
O framework AutoTest (FANTINATO et al., 2004) aplica as tcnicas Data-driven e
Keyword-driven por meio de um interpretador de planilhas eletrnicas, inclusive persistindo
dados de teste nas prprias planilhas. Isto, por um lado, traz como benefcio a facilidade de
manuteno do procedimento de teste (fluxo de aes durante a execuo dos testes) e dos
dados

de

teste

por

profissionais

sem

nenhum

conhecimento

especializado

em

desenvolvimento. Por outro lado, possibilita transtorno por permitir a incluso de informaes

desestruturadas nas planilhas, causa um retardo no acesso aos procedimentos de teste e limita
a persistncia dos dados de teste a esta tecnologia.
RYBALOV (2004) prope alguns padres de projeto para estruturar scripts de teste,
que podem ser adaptados tambm para testes de unidade. Esta abordagem complementar
abordagem aqui apresentada. Neste caso, preciso um conhecimento bastante especializado
em programao orientada a objetos para a criao das classes que implementam os scripts ou
que estruturam a implementao dos padres.
MESZAROS (2007) prope padres de projeto no contexto de testes unitrios.

1.2 Objetivo
Este trabalho apresenta um framework, denominado FuncTest, que implementa uma
arquitetura baseada na aplicao de padres de software e das tcnicas Data-driven e
Keyword-driven. O framework foi desenvolvido usando-se a ferramenta IBM Rational XDE
Tester (FUREY, 2004; IBM, 2004), portanto, se necessrio, precisa ser adaptado a outras
ferramentas Record and Playback orientadas a objetos.
O framework FuncTest promove, atravs da aplicao dos padres, a independncia
do SGBD onde os dados de teste so persistidos; a facilidade de incluso e excluso dos casos
de teste que iro compor a sute; a abstrao no acesso aos dados de teste e aos scripts de
teste; e um melhor reuso dos scripts de teste, devido granuralidade dos scripts e devido aos
dados de teste estarem associados aos passos de um caso de teste.
Antecipando-se necessidade de manuteno das sutes de teste automatizadas, a
arquitetura do framework desenvolvido foi essencialmente baseada em padres de software,
visando proporcionar maior flexibilidade. Com este objeto, aplicou-se o padro arquitetural
MVC (Model-View-Controller) e os padres de projeto Factory Method e Data Access Object
(DAO).
O padro arquitetural MVC (BUSCHMANN, 1996) foi utilizado para projetar a
arquitetura num nvel mais alto de abstrao. O padro DAO (ALUR, 2003) foi aplicado para
garantir transparncia de acesso aos dados de teste persistidos, tanto dados de entrada quanto
dados de sada esperados. O padro Factory Method (GAMMA, 1995), foi usado em duas

situaes: (1) para garantir independncia na obteno dos scripts de teste da sute; (2) para
fornecer transparncia no acesso aos objetos DAO.
Outro grande benefcio do uso do FuncTest o tratamento de erros centralizado, que
alm de minimizar os custos de manuteno do projeto de automao, possibilita, na maioria
dos casos, a execuo ininterrupta de sutes de teste.
O framework se encontra em uso por especialistas de teste do SERPRO (Servio
Federal de Processamento de Dados) (OLIVEIRA, 2007b). O processo de desenvolvimento
padro utilizado na equipe corresponde a uma customizao do RUP (Rational Unified
Process) (RUP, 2001) aderente ao nvel 3 do modelo CMMI (Capability Maturity Model
Integration) (CMMI, 2002). Uma verso preliminar do framework foi premiada
nacionalmente em congresso promovido pela empresa em 2006.

1.3 Organizao do Trabalho

Este trabalho est organizado em 5 captulos, incluindo esta introduo, descritos
resumidamente a seguir:
No Captulo 2, Automao de Testes Funcionais, ser apresentada uma viso geral
sobre testes de software, seguida de uma abordagem em torno das ferramentas e tcnicas para
automao de testes funcionais.
No Captulo 3, O Framework FuncTest, ser apresentada uma viso geral sobre
frameworks e padres de software, e, em seguida, a arquitetura e funcionamento do
framework sero detalhados.
No Captulo 4, Relato de Experincia, ser discutida a experincia no uso do
framework em projetos reais, destacando-se algumas dificuldades identificadas e ressaltandose benefcios de se utilizar o framework FuncTest.
No Captulo 5, sero apresentados resultados alcanados e trabalhos futuros.

Captulo 2
2. Automao de Testes Funcionais

Este captulo apresenta uma viso geral sobre teste de software com destaque
para a automao de testes funcionais.

2.1 Introduo
Testar um software uma tarefa meticulosa que pode se tornar cansativa. Uma
alternativa para proporcionar a entrega de produtos confiveis em menor tempo a realizao
de teste de software de maneira automatizada (DUSTIN, 2003). No contexto deste trabalho, a
automao restringe-se execuo de testes funcionais (caixa-preta).
Automatizar a execuo de testes funcionais consiste na construo de scripts de teste
capazes de simular o comportamento de um usurio sobre a interface da aplicao em teste.
Para enquadrar este processo de automao num contexto mais amplo, ser primeiramente
apresentada uma viso geral sobre Teste de Software, destacando-se importantes fatores que
direcionam este trabalho para a soluo proposta.

2.2 Teste de Software

Em (MYERS, 2004), teste de software definido como um processo, ou uma srie de
processos, projetado para garantir que o cdigo desenvolvido faa exclusivamente o que
pretendido, devendo tambm ser previsvel e consistente, evitando surpresas aos usurios.
Um processo de teste deve ser realizado com o objetivo de encontrar erros.
importante que sejam escolhidas entradas e aes que ofeream maior probabilidade de
provocar um comportamento inadequado da aplicao. Do contrrio, se o teste realizado
para provar que o sistema funciona corretamente, certamente as entradas e as aes escolhidas
podero mascarar alguns erros do sistema. Isto pode ser mais evidente quando os testes so
realizados pelo prprio programador, pois o conhecimento do cdigo do programa muitas
vezes pode condicionar a execuo dos testes, e, em alguns casos, o programador pode evitar,
mesmo inconscientemente, a identificao de erros em seu programa.

Quanto mais erros um caso de teste detectar, mais ele pode ser considerado um caso de
teste de sucesso, embora algumas pessoas considerem um caso de teste de sucesso aquele que
no apresenta nenhum erro durante a sua execuo (MYERS, 2004).
Testar um software no uma tarefa trivial. Mesmo quando se trata de um programa
simples, como um sistema de controle bibliotecrio, o nmero de entradas e de combinaes
possveis pode ser expressivo o suficiente para tornar os testes insuficientes e enfadonhos.
Desta forma, a criao de casos de teste para todas as entradas possveis seria impraticvel.
Neste contexto, no se pode aferir que um programa est livre de erros. No h
garantia de que qualquer conjunto de entradas possvel resultar num comportamento
adequado da aplicao.
O desafio, ento, tratar teste de software como um processo integrado ao processo de
desenvolvimento, e no como uma fase ao final do ciclo de vida (DUSTIN, 2003). Isto
minimizar as chances de repercutir erros para etapas seguintes, reduzindo os custos do
projeto. A Figura 2 ilustra uma abordagem do processo de teste atravs de um Modelo V
simplificado, adaptado de CRAIG (2002).

Figura 2 O Modelo V de Teste de Software (CRAIG, 2002)

O Modelo V de Teste de Software ilustra a relao entre atividades do ciclo de

desenvolvimento (Requisitos, Projeto Lgico, Projeto Fsico e Implementao) e nveis de
teste (Teste Unitrio, Teste de integrao, Teste de Sistema e Teste de Aceitao).

O Teste de Aceitao, apesar de ser normalmente o ltimo realizado, deve ser o

primeiro a ser planejado, desde que os requisitos estejam devidamente documentados. Da
mesma forma, os testes de Sistema sero planejados com base nas etapas de Projeto Lgico e
Requisitos; os testes de Integrao sero planejados com base nas etapas de Projeto Fsico,
Projeto Lgico e Requisitos; e os testes de Unidade sero planejados com base nas etapas de
Implementao, Projeto Fsico, Projeto Lgico e Requisitos (CRAIG, 2002).
Aps a fase de Implementao, os testes devero ser realizados na ordem inversa
qual eles foram planejados, respeitando, ento, a seguinte seqncia: teste unitrio, teste de
integrao, teste de sistema e teste de aceitao. A seo 2.2.2 detalhar o propsito de cada
um desses testes.
Para o planejamento adequado dos testes, necessrio escolher, dentre inmeros casos
de teste, aqueles mais provveis de apresentarem erros durante suas execues. Mesmo com
toda cautela e bom senso durante esta escolha, no se saber nunca se o ltimo erro foi
encontrado.
Para que os casos de teste projetados ofeream maior probabilidade de encontrar erros
com uma quantidade mnima de tempo e esforo, algumas tcnicas podem ser utilizadas na
definio de condies de teste apropriadas. Este trabalho destaca as tcnicas Particionamento
em Classes de Equivalncia, Anlise de Valor-Limite e Grafo de Causa-Efeito para testes
caixa-preta (Seo 2.2.3.1), e Teste de Caminho Bsico para testes caixa-branca (Seo
2.2.3.2).

2.2.1 Atividades de Teste

Nesta seo, sero apresentadas as atividades de testes descritas em Fewster et al.
(1999). A Figura 3 ilustra o processo atravs de 5 atividades, as quais podem ser realizadas
formal ou informalmente.

10

Figura 3 Atividades de Teste, adaptado de FEWSTER et al. (1999)

2.2.1.1 Identificao
Nesta atividade, identificado o qu pode ser testado, preferencialmente priorizando
as condies de teste (itens ou eventos que podem ser verificados pelo teste). Esta atividade
preferencialmente realizada durante as etapas que compem o lado esquerdo do Modelo V de
Teste de Software ilustrado na Figura 2 (FEWSTER et al., 1999).
Segundo FEWSTER et al. (1999), condies de teste so descries de
circunstncias que poderiam ser examinadas. Elas podem ser documentadas sob diferentes
maneiras, incluindo sentenas simples, entradas em tabelas ou diagramas, como grafos de
fluxo.

2.2.1.2 Projeto
Esta atividade tem por objetivo definir como os testes sero realizados, incluindo prrequisitos para realizao de cada caso de teste, como variveis do ambiente de execuo ou
estado da base de dados. O projeto de casos de teste produz testes que abrangem entradas
especficas, sadas esperadas e outras informaes importantes para a execuo do teste, como
pr-requisitos de ambiente. Esta atividade preferencialmente realizada durante as etapas que
compem o lado esquerdo do Modelo V de Teste de Software ilustrado na Figura 2
(FEWSTER et al., 1999).

11

Durante esta atividade, os casos de teste podem ser associados s condies de teste
definidas, para garantir que elas so exercitadas pelos casos de teste projetados. Fewster et al.
(1999) apresenta um exemplo de caso de teste com cinco passos (steps), onde cada passo
associado a uma ou mais condies de teste. No exemplo, o caso de teste exercita trs
condies de teste, sendo uma delas derivada usando-se a tcnica Particionamento em Classes
de Equivalncia e as outras duas derivadas usando-se a tcnica Anlise do Valor Limite.

2.2.1.3 Construo
Nesta atividade, os casos de teste so implementados pela preparao dos scripts de
teste, manuais ou automatizados, as entradas e as sadas esperadas. Para testes automatizados,
as entradas e as sadas esperadas podem ser organizadas em arquivos separados ou como parte
dos scripts. Para testes manuais, estas sadas podem ser simplesmente anotadas. Configurar as
sadas esperadas para serem comparadas atravs de testes automatizados pode ser
significativamente mais complexo do que a configurao equivalente para testes manuais. A
atividades de construo de casos de teste preferencialmente realizada durante as etapas que
compem o lado esquerdo do Modelo V de Teste de Software ilustrado na Figura 2
(FEWSTER et al., 1999).

2.2.1.4 Execuo
Para testes manuais, a execuo normalmente realizada seguindo-se um
procedimento manual impresso. So ento fornecidas entradas, observadas as sadas e
registrados os problemas encontrados. Para testes automatizados, a execuo consiste na
utilizao de ferramenta apropriada, especificando-se os casos de teste que deve ser
executados, os quais podem corresponder a um ou mais scripts. Esta atividade
necessariamente realizada durante os nveis de teste que compem o lado direito do Modelo V
de Teste de Software ilustrado na Figura 2 (FEWSTER et al., 1999), pois a existncia do
software essencial para a execuo dos testes.

12

2.2.1.5 Comparao
Para se verificar o comportamento do software frente ao esperado, as sadas devem ser
comparadas, de maneira formal (investigando-se rigorosamente as diferenas entre as sadas
exatas as sadas esperadas) ou informal (baseando-se nas sadas que o testador esperava ver).
Algumas sadas normalmente so comparadas durante a execuo do sistema, como
mensagens ou validao de campos da tela. Outras sadas somente podem ser comparadas
aps a execuo completa do caso de teste, como mudanas de registros de banco de dados.
Um teste automatizado precisa combinar essas duas abordagens (FEWSTER et al., 1999).
Caso as sadas esperadas no correspondam s sadas dos casos de teste, de acordo
com a comparao realizada, supe-se que o teste tenha falhado. No entanto, o que se pode
dizer neste momento que estas diferenas precisam ser investigadas, ou sejam verificadas.
H casos em que estas diferenas so causadas por erro na seqncia de execuo do script,
erros de configurao do sistema ou por falhas na especificao do teste (FEWSTER et al.,
1999).

2.2.2 Nveis de Teste

Testes so executados em diferentes nveis (ou estgios) do desenvolvimento de um
software. A Figura 4 ilustra os quatro nveis tpicos de teste de software. Estes nveis vo
desde testar elementos menores de um sistema a testar sistemas completos.

Figura 4 Nveis de Teste de Software

13

A Figura 5, adaptada de CRAIG (2002), ilustra os quatro nveis de teste numa relao
entre o escopo do software sob teste e a realidade de ambiente existente. CRAIG (2002)
afirma que cada nvel definido por um ambiente particular, que pode incluir configurao
de hardware, configurao de software, interfaces, testadores etc. Note que medida em que
voc se move para nveis mais altos de teste o ambiente se torna mais realstico.

Figura 5 Nveis de Teste versus Realidade de Ambiente.

importante perceber que a realizao de testes em nveis mais altos exige um

amadurecimento do software. Desta forma, os primeiros testes possveis de serem realizados
em um software so os testes unitrios. medida em que as unidades so verificadas e
integradas, os testes de integrao tornam-se possveis. Num momento posterior, a equipe de
testes, no necessariamente formada por desenvolvedores, pode realizar os testes de sistema,
que avaliam o comportamento do software numa perspectiva de usurio final. Por fim, os
prprios usurios do sistema (ou representantes) faro os testes de aceitao, validando a
implementao.

2.2.2.1 Teste Unitrio

Neste nvel, cada unidade de cdigo de um sistema testada individualmente.
Copeland (2004) define uma unidade como o menor pedao de software que um
desenvolvedor cria. Segundo TIAN (2005), uma unidade pode corresponder a uma funo,
um procedimento ou uma sub-rotina para linguagens de programao estruturadas

14

tradicionais como C, PASCAL ou FORTRAN, ou corresponder a um mtodo numa linguagem

orientada a objeto como C++, Java e Smalltalk.
Os testes unitrios so normalmente executados pelo prprio desenvolvedor do
cdigo, portanto so considerados parte da implementao. Desta forma, a execuo de testes
unitrios predominantemente feita usando-se tcnicas caixa-branca. Entretanto, segundo
TIAN (2005), tcnicas caixa-preta poderiam ser utilizadas para testar unidades de cdigo.

2.2.2.2 Teste de Integrao

Neste nvel, o teste ainda normalmente realizado por desenvolvedores, que focam
prioritariamente na colaborao de um conjunto de unidades, ao invs de concentrarem-se no
comportamento de uma unidade especfica (RAINSBERGER, 2005). Assim, so testadas as
unidades integradas, que podem corresponder a componentes ou a mdulos/subsistemas. Para
este nvel de teste, tambm predomina-se o uso de tcnicas caixa-branca.
Poder-se-ia imaginar que testes de integrao no seriam necessrios quando as
unidades isoladas foram criteriosamente testadas. Entretanto, o teste isolado de uma unidade
no garante que a sua combinao com outras unidades ir se comportar adequadamente.
Alm disso, importante que testes de integrao sejam realizados somente aps os testes de
suas unidades terem passado (BURNSTEIN, 2003).

2.2.2.3 Teste de Sistema

Enquanto os testes unitrios e os testes de integrao so normalmente realizados por
desenvolvedores, testes de sistema e testes de aceitao so preferencialmente executados em
um ambiente separado, que possua configurao idntica ou similar ao ambiente de produo
(DUSTIN, 2003). Neste nvel, espera-se que as unidades tenham sido integradas com sucesso
(BURNSTEIN, 2003) e o sistema (ou mdulo/subsistema) esteja pronto para ser testado por
uma equipe que desconhea seus aspectos tcnicos (caixa-preta).
tipicamente durante este nvel que os testes de carga, de performance, de
confiabilidade e outros so realizados, caso no haja um esforo ou uma equipe especficos
para estas atividades (DUSTIN, 2003). Neste sentido, tambm durante este nvel que so
realizados os testes funcionais, dos quais so selecionados os que iro compor as sutes de

15

teste de regresso. Portanto, o framework FuncTest apropriadamente utilizado durante testes

de sistema.
Segundo BURNSTEIN (2003), os testes de sistema servem como um bom ensaio para
os testes de aceitao.

2.2.2.4 Teste de Aceitao

Teste de aceitao o processo de comparar o programa com os requisitos iniciais e
necessidades atuais do cliente. usualmente realizado por um grupo de usurios finais e
normalmente no considerado como uma responsabilidade da equipe de desenvolvimento. O
teste de aceitao realizado para determinar se o produto satisfaz as necessidades do cliente
(MYERS, 2004).
Segundo BURNSTEIN (2003), os usurios finais podem desempenhar um importante
papel durante vrias atividades de teste, especialmente no planejamento dos testes de
aceitao, neste caso apoiando o projeto dos casos de teste que sero executados.

2.2.3 Tcnicas de Teste

Nesta seo, sero apresentadas algumas tcnicas usadas para projetar casos de teste
efetivos. Elas definem critrios para a criao de testes com maior probabilidade de encontrar
erros. So elas: Particionamento em Classes de Equivalncia; Anlise de Valor-Limite e
Grafo de Causa-Efeito para apoiar o projeto de testes caixa-preta; e a tcnica Teste de
Caminho Bsico para apoiar o projeto de testes caixa-branca. A apresentao das referidas
tcnicas compe as sees 2.2.3.1 (Teste Caixa-preta) e 2.2.3.2 (Teste Caixa-branca).

2.2.3.1 Teste Caixa-preta (Black-box)

Nesta abordagem de teste, o programa visto como uma caixa-preta. Portanto, o
executor dos testes no tem acesso ao cdigo fonte. O propsito descobrir situaes em que
o comportamento do programa no est de acordo com o especificado (MYERS, 2004).

16

2.2.3.1.1 Particionamento em Classes de Equivalncia

A tcnica Particionamento em Classes de Equivalncia preconiza a diviso do domnio
de entrada do programa em classes de dados. Cada classe, vlida ou invlida, representa um
conjunto de elementos que repercutem num mesmo comportamento do sistema,
independentemente de qual dos elementos da classe foi escolhido como entrada. Por isso,
subentende-se que qualquer um dos elementos de uma classe de equivalncia pode ser
utilizado para testar o comportamento do sistema para todos os elementos da classe.
Segundo MYERS (2004), o particionamento do domnio de entrada deve resultar em
classes de equivalncia que permitam considerar que o comportamento do sistema para um
valor de entrada representativo da classe equivalente ao comportamento para todos os outros
valores da classe. Desta forma, se um caso de teste de uma classe de equivalncia detecta um
erro, todos os outros casos de teste da classe devem encontrar o mesmo erro.
As seguintes diretrizes apresentadas em MYERS (2004) apiam a definio de classes
de equivalncia para cada condio de entrada:

Se uma condio de entrada especifica um intervalo de valores, define-se uma

classe de equivalncia vlida e duas invlidas. Por exemplo, se a regra define que
um valor de entrada deve estar entre 1 e 99, define-se uma classe para representar
os valores vlidos (de 1 a 99), uma classe para representar valores invlidos
menores que 1 e uma classe para representar valores invlidos maiores que 99;

Se uma condio de entrada exige uma certa quantidade de valores de entrada,

define-se uma classe de equivalncia vlida e duas invlidas. Por exemplo, se a
entrada corresponder a um conjunto de 1 a 3 itens informados, pode-se definir uma
classe de equivalncia vlida (quantidade de itens entre 1 e 3) e as duas classes
invlidas nenhum item e quantidade de itens maior que 3;

Se uma condio de entrada especifica um conjunto de valores que recebam

tratamento diferente pelo programa, define-se uma classe vlida para cada
elemento do conjunto e uma classe invlida para elementos no contidos no
conjunto. Por exemplo, caso os tipo de logradouro aceitveis sejam rua,
avenida e travessa, define-se trs classes vlidas, uma para cada tipo de
logradouro vlido, e uma classe invlida qualquer;

17

Se uma condio de entrada especifica uma situao do tipo deve ser, define-se
uma classe de equivalncia vlida e uma invlida. Por exemplo, se o nome de um
funcionrio deve ser iniciado com uma letra, define-se uma classe de equivalncia
vlida inicia com letra e uma invlida no inicia com letra.

Aps definir as classes de equivalncia para cada condio de entrada, casos de teste
devem ser criados primeiramente para as classes de equivalncia vlidas, at que todas sejam
cobertas. Em seguida, deve ser criado um caso de teste para cada classe de equivalncia
invlida, pois o comportamento do sistema para cada uma dessas classes deve ser verificado
individualmente (MYERS, 2004).

2.2.3.1.2 Anlise de Valor-Limite

Segundo PRESSMAN (2002), experincias mostram que muitos erros tendem a
ocorrer quando se utiliza valores da fronteira do domnio de entrada, porm a tcnica
Particionamento em Classes de Equivalncia no impe a escolha destes valores. Para
considerar estes casos, criou-se outra tcnica, denominada Anlise de Valor Limite, que
preconiza a escolha de valores limtrofes na definio de casos de teste.
CRAIG (2002) afirma que, normalmente, quando se aplica esta tcnica, so testados
os limites exatos, o valor imediatamente acima do limite superior e o valor imediatamente
abaixo do limite inferior. Alguns testadores tambm selecionam o valor imediatamente acima
do limite inferior e o valor imediatamente abaixo do limite superior.
MYERS (2004) apresenta algumas diretrizes para apoiar o uso desta tcnica:

Se uma condio de entrada especifica uma faixa de valores, devem ser definidos
casos de teste para os extremos da faixa e para os valores imediatamente alm dos
extremos. Por exemplo, se a faixa corresponder os inteiros de 3 e 10, devem ser
criados casos de teste para os valores 3, 10, 2 e 11. Esta diretriz tambm pode ser
utilizada para cada condio de sada. Por exemplo, caso o programa gere como
sada um nmero real que esteja entre 0,00 e 10,00, pode-se tentar criar casos de
teste para estes dois extremos e para os valores -0,01 e 10,01;

Se uma condio de entrada especifica certa quantidade de valores, deve ser

desenvolvido um caso de teste para a quantidade mnima, um para a quantidade

18

mxima, um para cada valor imediatamente inferior quantidade mnima e um

imediatamente superior quantidade mxima. Por exemplo, se a condio de
entrada permitir de 1 a 50 valores inteiros, devem ser escritos casos de teste para
os valores 1, 50, 0 e 51. Esta diretriz pode ser utilizada para cada condio de
sada. Por exemplo, caso o programa gere como sada de 1 a 4 nmeros inteiros,
pode-se tentar criar casos de teste que gerem como sada 1, 4, 0 e 5 nmeros
inteiros.
A importante diferena entre as tcnicas Anlise de Valor-Limite e Particionamento
em Classes de Equivalncia que a primeira explora situaes considerando valores limites
ou prximos aos limites das parties de equivalncia (MYERS, 2004).

2.2.3.1.3 Grafo de Causa-Efeito

BURNSTEIN (2003) afirma que a maior deficincia da tcnica Particionamento em
Classes de Equivalncia no permitir combinar condies. Neste contexto, a tcnica Grafo
de Causa-Efeito pode ser utilizada para complementar as tcnicas Particionamento em Classes
de Equivalncia e Anlise de Valor-Limite. Ela prope a combinao de condies de entrada
para a gerao de casos de teste (MYERS, 2004) e utiliza grafos derivados de uma
especificao para representar de maneira concisa o relacionamento lgico entre causas e
efeitos (DUSTIN 2003).
Como o nmero de combinaes entre as condies pode ser muito grande, o grafo
auxilia na escolha das combinaes devidas. Myers (2004) afirma que esta tcnica apia na
seleo sistemtica de um conjunto de casos de teste efetivos.
Uma causa uma condio de entrada ou uma classe de equivalncia das condies de
entrada, um efeito uma condio de sada ou uma mudana de estado do sistema, e os
operadores lgicos so: AND (V), OR ("V") e NOT ("~") (PARADKAR, 1994; MYERS,
2004).
MYERS (2004) apresenta o seguinte processo para a derivao de casos de teste
usando-se a tcnica Grafo de Causa-Efeito:

Para tornar mais cmodo o uso de grafos de causa-efeito, deve-se dividir a

especificao em unidades menores;

19

Para cada unidade de especificao, as causas e efeitos so identificadas e recebem

uma numerao nica;

Baseando-se nas causas, nos efeitos e em suas combinaes, um grafo de causaefeito desenvolvido para cada unidade de especificao. As causas so os ns
posicionados no lado esquerdo de um relacionamento e os efeitos so os ns
posicionados no lado direito. Cada n pode assumir um valor booleano (0 ou
1, representando, respectivamente, a ausncia ou a presena de uma causa ou de
um efeito). A Figura 6 ilustra a notao bsica para a criao dos grafos;

Figura 6 Smbolos Bsicos de um Grafo de Causa-efeito

Um exemplo de grafo, adaptado de BURNSTEIN (2003), ilustrado na Figura 7.

Trata-se de uma aplicao que permite pesquisar a posio de um determinado caractere
dentro de uma string existente. O usurio dever informar duas entradas: (1) o tamanho da
string e (2) o caractere a ser pesquisado. As condies de entrada so C1 (o tamanho da string
deve ser um inteiro positivo de 1 a 80) e C2 (o caractere informado deve pertencer string).
As condies de sada (efeitos) so E1 (exibir mensagem Inteiro fora da faixa), E2 (exibir a
posio do caractere na string) e E3 (exibir mensagem Caractere no encontrado na string).
As combinaes so: (a) se C1 e C2, ento E2; (b) se C1 e no C2, ento E3; (c) se no C1,
ento E1.

20

Figura 7 Exemplo de Grafo de Causa-efeito

Algumas restries devem ser especificadas no grafo para informar que algumas
combinaes so impossveis devido a restries sintticas ou de ambiente. A
Figura 8 ilustra os seis smbolos de restrio utilizados (E = No mximo um
elemento pode ter valor 1; I = Pelo menos um elemento deve ter o valor 1; O =
Apenas um dos elementos pode ter valor 1; R = se o valor de a 1, o valor de b
tem que ser 1; M = se o efeito a tem valor 1, o efeito b forado a valer 0).

Figura 8 Smbolos de Restrio de um Grafo de Causa-efeito

21

A Figura 9, adaptada de MYERS (2004), ilustra o uso dos smbolos de restrio E e

R.

Figura 9 Exemplo do Uso de Smbolos de Restrio em Grafo de Causa-efeito

O grafo deve ser convertido numa tabela de deciso.

Esta tabela deve possuir uma linha para cada causa e uma linha para cada efeito. As
entradas possveis para a tabela so as mesmas para um n no grafo: 0 ou 1. Segundo
BURNSTEIN (2003), a tabela deve refletir os relacionamentos e o grafo, e mostra os efeitos
para todas as possveis combinaes de causas. Caso um campo da tabela no seja preenchido
ou possua o smbolo -, significa que aquela entrada no influir na condio de sada.
A Tabela 1 representa a tabela de deciso do exemplo da Figura 7. Neste exemplo, so
apresentadas somente 3 colunas porque o valor de entrada para a causa C2 (o caractere
informado deve pertencer string) no influi na condio de sada quando o valor da causa
C1 (o tamanho da string deve ser um inteiro positivo de 1 a 80) 0.

22

Tabela 1 Exemplo de Tabela de Deciso - Grafo de Causa-efeito

As regras da tabela de deciso so convertidas em casos de teste.

As colunas da tabela sero utilizadas para gerar os casos de teste. A Tabela 2, adaptada
de BURNSTEIN (2003), exemplifica um conjunto de 3 casos de teste gerados atravs da
Tabela 1. No exemplo, considera-se que os caracteres sero pesquisados dentro da seguinte
string: abcde.
Entradas Tamanho da string
5
1
2

90

Caractere para pesquisa

c
w

Sadas
3
Caractere no encontrado na
string
Inteiro fora da faixa

Tabela 2 Casos de Teste derivados a partir de uma tabela de deciso

2.2.3.2 Teste Caixa-branca (White-box)

Nesta abordagem de teste, o executor dos testes tem acesso ao cdigo fonte da
aplicao sob teste. O propsito avaliar o cdigo programa, a fim de encontrar erros em sua
estrutura interna, devendo-se garantir (PRESSMAN, 2002):

que cada caminho do cdigo seja exercitado pelo menos uma vez;

que os estados verdadeiro e falso de todas as decises lgicas sejam exercitados;

que todas as estruturas de dados utilizadas internamente sejam exercitadas.

23

A seguir, ser apresentada a tcnica Teste de Caminho Bsico descrita em

(PRESSMAN, 2002) para a realizao de testes caixa-branca.

2.2.3.2.1 Teste de Caminho Bsico

Esta tcnica de teste de estrutura de controle consiste, basicamente, em criar casos de
teste que forcem a execuo de cada caminho possvel no fluxo de controle do programa a ser
testado. Para facilitar o entendimento do fluxo, importante primeiramente represent-lo num
grafo, onde cada n simbolizar um ou mais comandos procedimentais e cada seta, chamada
de aresta ou ligao, indicar o sentido do fluxo de controle lgico. Cada n que possui
condio associada denominado n predicado e se caracteriza por possuir duas ou mais
arestas nele originadas (PRESSMAN, 2002). A Figura 10 ilustra a simbologia utilizada para
cada construo estruturada.

Figura 10 Simbologia para a criao de Grafos de Fluxo

As Figuras 11 e 12 (PRESSMAN, 2002) exemplificam, respectivamente, um

fluxograma e o grafo de fluxo (G) correspondente. Cada n do grafo pode representar mais de
um comando procedimental. Isto ocorre quando estes comandos so executados sempre em
conjunto, no havendo possibilidade de um deles ser executado independentemente dos
demais.

24

Figura 11 Exemplo de Fluxograma

Figura 12 Exemplo de Grafo de Fluxo

Neste exemplo, cada losango corresponde a uma condio simples. Caso existam
condies compostas, torna-se mais complexa a representao do grafo. A Listagem 1 mostra

25

um trecho de cdigo ilustrando um lao (comando estruturado Enquanto) que possui duas
condies a ele associadas.
Linha
1
...
5
...
10
...

Cdigo
...
...
Enquanto (x < 1) e (y < 1) faa
...
Fim Enquanto;
...

Listagem 1 Exemplo de Lao com duas condies

A Figura 13 ilustra um grafo de fluxo para o exemplo da Listagem 1. As linhas de 1 a
4 correspondem ao n 1, a linha 5 corresponde aos ns 2 (representando a condio x < 1) e
3 (representando a condio y < 1), as linhas de 6 a 9 esto representadas pelo n 4 e a linha
10 corresponde ao n 5. O n 6 corresponde s demais linhas do programa. Para cada
condio existente, cria-se um n correspondente.

Figura 13 Exemplo de Lao com duas condies

O prximo passo identificar o nmero de caminhos linearmente independentes para

o grafo. Esta mtrica denominada complexidade ciclomtica. Ela fornece uma medida
quantitativa da complexidade lgica do programa. H trs maneiras de calcul-la
(PRESSMAN, 2002):

26

V(G) = quantidade de regies do grafo;

V(G) = nmero de arestas nmero de ns + 2;

V(G) = nmero de ns predicados + 1;

Usando uma dessas trs maneiras para calcular a complexidade ciclomtica do grafo G
da Figura 13, obtm-se as seguintes expresses:

4 regies = 4;

11 arestas 9 ns + 2 = 4;

3 ns predicados + 1 = 4.

Portanto, a complexidade ciclomtica do grafo G 4. Assim, devero ser identificados

4 caminhos independentes. Por exemplo:

1-11;

1-2-3-4-5-10-1-11;

1-2-3-6-8-9-10-1-11;

1-2-3-6-7-9-10-1-11.

Neste caso, o caminho 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 no deveria ser inserido

porque no introduziria nenhuma nova aresta, mas corresponderia apenas a uma combinao
de outros caminhos (PRESSMAN, 2002).
Por fim, para cada caminho independente identificado, deve ser criado pelo menos um
caso de teste. Isto garantir que todos os comandos do programa sero executados pelo menos
uma vez e que cada condio ter sido executada quando satisfeita (verdadeira) e quando no
satisfeita (falsa).

2.2.4 Tipos de Teste

Esta seo apresenta os tipos de teste descritos em RUP (2001). O RUP classifica
testes sob os cinco fatores de qualidade do modelo FURPS (GRADY, 1987): Functionality
(Funcionalidade),

Usability (Usabilidade),

Reliability (Confiabilidade),

Performance

(Desempenho) e Supportability (Suportabilidade). Para cada uma desses fatores, ou

27

dimenses de qualidade, como denomina o referido processo, existe um ou mais tipos de teste
associado(s) (Tabela 3):
Dimenses
de Qualidade
Funcionalidade
Usabilidade
Confiabilidade
Desempenho

Suportabilidade

Tipos de teste
Teste Funcional
Teste de Segurana
Teste de Volume
Teste de Usabilidade
Teste de Integridade
Teste de Estrutura
Teste de Stress
Teste de Avaliao de Desempenho
Teste de Conteno
Teste de Carga
Teste de Perfil de Desempenho
Teste de Configurao
Teste de Instalao

Tabela 3 FURPS x Tipos de Teste

2.2.4.1 Funcionalidade
Seguem os tipos de teste associados dimenso Funcionalidade:

Teste Funcional: Myers (2004) define teste funcional como um processo de tentar
encontrar discrepncias entre o programa e sua especificao externa. Uma
especificao externa uma descrio precisa do comportamento do programa
do ponto de vista do usurio. Segundo RUP (2001), esse tipo de teste pode ser
implementado e executado em diferentes nveis de teste (unitrio, integrao,
sistema). Burnstein (2003) afirma que testes funcionais so caixa-preta por
natureza, uma vez que o foco est nas entradas e sadas apropriadas para cada
funo;

Teste de Segurana: Testes destinados a garantir que o objetivo do teste e os dados

(ou sistemas) possam ser acessados apenas por determinados atores;

Teste de Volume: Um teste de volume visa verificar o comportamento do software

quando submetido a grandes volumes de dados. Estes dados podem corresponder a
entradas ou sadas, ou mesmo serem persistidos no banco de dados. Este tipo de
teste pode ser realizado de diferentes maneiras, como, por exemplo, atravs da

28

entrada de um grande volume de dados para cada campo e de consultas capazes de

retornar grande parte do contedo do banco de dados, ou atravs de consultas com
grande nmero de restries.

2.2.4.2 Usabilidade
Segue o nico tipo de teste associado dimenso Usabilidade de acordo com RUP
(2001):

Teste de usabilidade: O teste de usabilidade corresponde facilidade de uso do

software. Podem ser enfatizados diversos fatores, como legibilidade, esttica,
consistncia na interface do usurio e documentao do usurio.

2.2.4.3 Confiabilidade
Seguem os tipos de teste associados dimenso Confiabilidade de acordo com RUP
(2001):

Teste de Integridade: Testes destinados a avaliar a resistncia do software a falhas

e a compatibilidade tcnica em relao linguagem, sintaxe e utilizao de
recursos;

Teste de Estrutura: Este conceito utilizado em dois contextos principais. O

primeiro, geralmente feito por desenvolvedores (caixa-branca), est relacionado a
testar a estrutura de itens internos do cdigo procura de pontos fracos e erros
estruturais. O segundo est relacionado a testar a estrutura de sites da Web para
verificar se todos os links (estticos ou ativos) esto conectados corretamente;

Teste de Stress: O teste de stress objetiva avaliar o comportamento do sistema em

condies anormais, como cargas de trabalho extremas, memria insuficiente,
hardware e servios indisponveis, ou recursos compartilhados limitados. Estes
testes auxiliam a desenvolver planos de contingncia e a planejar a manuteno de
atualizaes.

29

2.2.4.4 Desempenho
Seguem os tipos de teste associados dimenso Desempenho de acordo com RUP
(2001):

Teste de Avaliao de Desempenho: Este tipo de teste procura avaliar o

desempenho do software mediante uma carga de trabalho conhecida;

Teste de Conteno: O teste de conteno tem o objetivo de avaliar se o software

lida de forma aceitvel quando recursos compartilhados recebem demandas de
diferentes atores;

Teste de Carga: Este tipo de teste visa avaliar os limites operacionais de um

sistema mediante cargas de trabalho variveis. H casos em que o teste de carga
mantm a carga de trabalho, mas varia a configurao do sistema. As medies
baseiam-se normalmente na taxa de transferncia de dados da carga de trabalho e
no tempo de resposta da transao. A carga de trabalho alterada de modo a
simular variaes entre as cargas mdia e mxima ocorridas em condies
operacionais normais;

Teste de Perfil de Desempenho: O perfil de desempenho um tipo de teste que

visa identificar gargalos de desempenho, a partir do monitoramento do software,
incluindo fluxo de execuo, acesso a dados e chamadas de funes.

2.2.4.5 Suportabilidade
Seguem os tipos de teste associados dimenso Suportabilidade de acordo com RUP
(2001):

Teste de Configurao: O teste de configurao tem o propsito de garantir que o

software funcione de maneira aceitvel quando submetido a diferentes
configuraes de hardware ou software. Este tipo de teste tambm pode ser
implementado como um teste de desempenho do sistema;

Teste de Instalao: Este tipo de teste visa a garantir que o sistema seja instalado
conforme o esperado, mesmo em condies anormais, como espao insuficiente
em disco e interrupo de energia. So simuladas diferentes configuraes de

30

hardware e software durante a instalao, a fim de evitar possveis fatores

limitadores durante a instalao em ambiente de produo.

2.2.5 Testes de Regresso

Um teste de regresso corresponde re-execuo de um teste outrora realizado com
sucesso sob um conjunto de funcionalidades do sistema. Isto feito aps alteraes sofridas
pelo sistema, a fim de assegurar que o seu funcionamento permanece de acordo com o
especificado. Segundo PRESSMAN (2002), testes de regresso so realizados para verificar
se manutenes realizadas no sistema introduziram efeitos colaterais indesejveis. O
framework FuncTest tem sido utilizado exclusivamente para testes de regresso.
Regresso o comportamento inadequado de funes, atributos ou caractersticas
previamente corretos. Podem ser de trs tipos (BLACK, 2007):

Regresso Local: a mudana ou a correo de um bug cria um novo bug;

Regresso Exposta: a mudana ou a correo de um bug revela um bug existente;

Regresso Remota: a mudana ou a correo de um bug numa determinada rea do

sistema afeta outra rea. Este tipo normalmente o mais difcil de ser detectado.

Uma regresso pode afetar novas caractersticas, conforme ilustrado na Figura 14, ou
caractersticas existentes, como ilustra a Figura 15. As duas figuras foram adaptadas de
BLACK (2007).

Figura 14 Exemplo de Regresso - Impacto na Mesma Verso

No exemplo da Figura 14, foram introduzidas n caractersticas verso 1.0 de um

determinado projeto de desenvolvimento. Ao se introduzir a caracterstica C3, a caracterstica
C1 foi afetada, ambas pertencentes mesma verso do projeto (1.0).

31

Figura 15 Exemplo de Regresso - Impacto em Verso Anterior

No exemplo da Figura 15, a caracterstica Cn+3, introduzida na verso 1.1 do projeto,

afetou as caractersticas C2 e C3 introduzidas na verso anterior (1.0). Evidentemente, quando
a introduo de uma caracterstica afeta o comportamento de outra caracterstica presente em
verso anterior, o prejuzo para o projeto maior, especialmente quando o bug no
identificado pela equipe de desenvolvimento antes da verso entrar em produo. Um
stakeholder normalmente fica insatisfeito quando o comportamento de uma nova
caracterstica lhe frustra as expectativa, mas, neste caso, no h perda de nenhuma
potencialidade em torno de seu trabalho dirio (BLACK, 2007).
Normalmente, a automao de todos os testes de regresso impossvel, impraticvel
ou no apoiada pela gerncia. Desta forma, preciso selecionar um subconjunto dos testes
para automatiz-lo. As seguintes tcnicas podem ser utilizadas (BLACK, 2007):
Uso de Rastreabilidade: identificar testes relacionados a descries do
comportamento do sistema, como elementos de especificao de requisitos,
elementos de especificao de projeto ou anlise de riscos;
Uso de Anlise de Mudana: neste caso, devem ser analisadas descries
estruturadas do sistema para descobrir como os efeitos de mudana se propagariam
atravs do sistema;
Uso de Anlise de Risco de Qualidade: priorizar testes que verificam reas de
maior risco.
Dustin (2003) afirma que as sutes de teste de regresso precisam ser automatizadas e
executadas em ambiente estvel, que permita a execuo rpida sem a necessidade de muitos
recursos. Caso os testes no sejam automatizados, os testes de regresso podem se tornar um

32

processo longo e tedioso. Alm disso, muitas ferramentas permitem que os testes
automatizados se iniciem em diferentes perodos, como, por exemplo, durante a madrugada,
desde que seja feita a devida configurao.
A automao dever refletir fielmente o teste especificado. Portanto, a qualidade do
teste automatizado depender diretamente da qualidade de sua especificao. Alm disso, a
deciso de se automatizar um teste precisa ser feita com base na anlise entre o seu custo e o
benefcio que ela oferece.
Evidentemente, quando se decide automatizar uma sute de teste de regresso,
importante que a sute seja projetada de maneira a possibilitar a sua fcil manuteno, para
que o custo de mant-la viabilize a sua utilizao.
Uma sute de teste de regresso pode compreender testes caixa-branca ou testes caixapreta. Apesar de ser mais comum a realizao de testes de regresso caixa-preta, algumas
equipes de desenvolvimento automatizam testes caixa-branca para garantir maior
confiabilidade ao cdigo desenvolvido. Esta uma prtica comum quando se trabalha com
Integrao Contnua (GOIS, 2007).

2.3 Ferramentas para Automao de Testes

A fim de tornar o processo de teste mais efetivo, diversos tipos de ferramentas de
testes esto disponveis para dar suporte em diferentes etapas de desenvolvimento de software
(DUSTIN, 2003). Em FEWSTER et al. (1999) so descritos alguns tipos (Figura 16):

Ferramentas de Projeto de Testes (Test Design Tolls): usadas para derivar dados de
teste a partir de uma especificao;

Ferramentas de Projeto Lgico (Logical Design Tools): utilizadas para gerar casos
de teste;

Ferramentas de Projeto Fsico (Physical Design Tools): usadas para manipular

dados existentes ou gerar dados de teste;

Ferramentas de Gerenciamento (Test Management Tools): suportam o plano de

testes, possibilitando manter a relao dos testes que sero executados.
Ferramentas para ajudar na rastreabilidade de testes e ferramentas de rastreamento
de defeitos tambm esto includas nesta categoria;

33

Ferramentas de Anlise Esttica (Static Analysis Tools): usadas na deteco de

defeitos em cdigo fonte, sem a necessidade de execuo do cdigo;

Ferramentas de Cobertura (Coverage Tools): usadas para avaliar o quanto a

aplicao sob teste tem sido exercitada nos testes;

Ferramentas de Depurao de Cdigo (Debugging Tools): usadas na depurao de

cdigo, portanto, no so consideradas, a rigor, ferramentas de teste. No entanto,
oferecem suporte eficiente para a correo de defeitos encontrados em testes;

Ferramentas de Anlise Dinmica (Dynamic Analysis Tools): usadas para avaliar o

comportamento do sistema enquanto o software executado;

Simuladores (Simulators): simulam condies que permitem a execuo de partes

de um sistema;

Ferramentas de Teste de Desempenho (Performance Testing Tools): usadas para

medir o tempo de resposta do software;

Ferramentas de Execuo e Comparao (Test Execution and Comparison Tools):

usadas para automatizar a execuo de testes, comparando as sadas do teste com
as sadas esperadas. So utilizadas em todos os estgios (testes unitrios, testes de
integrao, testes de sistema e testes de aceitao). Ferramentas Record and
Playback so ferramentas de execuo e comparao;

Figura 16 Tipos de Ferramentas de Suporte a Testes

34

2.4 Automao de Testes Funcionais

A automao da execuo de testes funcionais de sistema, neste trabalho denominada
automao de testes funcionais, realizada atravs da criao e da execuo de scripts de
teste a partir de ferramentas Record and Playback. Estas ferramentas permitem que os scripts
sejam programados ou simplesmente gravados durante a realizao de um teste manual,
podendo ser alterados programaticamente. Para program-los, evidentemente, necessrio
conhecer a linguagem de script utilizada pela ferramenta. Uma vez criados, os scripts podero
ser executados, em substituio ao teste manual correspondente.
A criao destes scripts normalmente s realizada quando a interface grfica da
aplicao sob teste considerada estvel. De outra forma, os scripts poderiam facilmente se
tornar obsoletos.
Scripts gravados por ferramentas Record and Playback conservam praticamente todos
os comandos realizados durante a gravao, incluindo muitas vezes aes desnecessrias ao
teste. Uma vantagem de simplesmente gravar a execuo manual do teste, ao invs de se
programar o script ou parte dele, que no se necessita conhecer a linguagem de
programao na qual o cdigo gerado. Entretanto, o uso desta tcnica pode limitar o reuso e
a manuteno dos scripts.
Para reduzir a forte dependncia entre os scripts e a interface da aplicao sob teste, as
ferramentas Record and Playback possuem mecanismos flexveis de reconhecimento de itens
de uma interface grfica. Tais mecanismos permitem que determinadas alteraes na interface
no exijam alterao nos scripts que lidam com a interface modificada.
Essas ferramentas tambm permitem a incluso de pontos de verificao
(comparaes) durante ou aps a criao de cada script. Isto possibilita comparar o
comportamento esperado com o comportamento real da aplicao. De outra forma, no
haveria teste, e sim apenas uma robotizao da interao sobre a interface de usurio.
Somente aps serem includas todas as comparaes e excludos os erros que
porventura ocorram durante a execuo automtica dos testes, os scripts estaro prontos para
serem utilizados em testes de regresso.
O esforo para a construo e manuteno de um teste funcional automatizado se
justifica principalmente com a economia gerada aps sucessivas execues dos scripts

35

criados. Normalmente, o tempo de execuo de uma sute de teste automatizada

insignificante frente ao tempo necessrio realizao de testes manuais equivalentes.
A execuo automatizada de testes funcionais, alm de ser realizada num tempo
drasticamente inferior, viabiliza uma cobertura de testes de regresso que, de outra forma, no
seria realizada em tempo compatvel com a necessidade do cliente.
Os scripts gravados por ferramentas Record and Playback para a execuo dos testes
de regresso normalmente so difceis de serem mantidos e reutilizados, bem como
apresentam em sua estrutura dados hard-coded e comandos desnecessrios. Normalmente
estes scripts so alterados ou, at mesmo, inteiramente criados programaticamente. Por
exemplo, o programador poder excluir comandos desnecessrios inseridos durante a
gravao automtica dos scripts ou aplicar as tcnicas apropriadas para ampliar o reuso dos
mesmos. As tcnicas Data-driven e Keyword-driven sero descritas em sees posteriores.
Alm da ferramenta IBM Rational XDE Tester, utilizada na construo do framework
FuncTest, outras ferramentas Record and Playback podem ser citadas como exemplo: IBM
Rational Functional Tester (KELLY, 2006), Selenium (OPENQA, 2007), SilkTest
(BORLAND, 1994), TestComplete (AUTOMATEDQA, 1999), SPACES (BARBOSA, 2004),
Jtest (PARASOFT, 1996) etc.

2.4.1 Rational XDE Tester

A ferramenta IBM Rational XDE Tester, aqui referenciada como XDE Tester, uma
ferramenta para automao de testes funcionais de aplicaes Java e Web. Ela permite gravar
e executar scripts de teste nas plataformas Windows NT, Windows 2000 e Windows XP
Professional, e permite a execuo, mas no a gravao, nas plataformas Red Hat Linux,
Windows 98 e Windows ME (IBM, 2004).
Na ferramenta XDE Tester, cada script gravado ou programado como uma classe
Java. A Figura 17 apresenta um exemplo simples de script criado nesta ferramenta. O
propsito do script implementar o caso de teste Pesquisa_Livros_Google, que tem o
finalidade efetuar a busca de um livro existente no acervo de livros do Google. Escolheu-se o
o livro The Art of Software Testing com item de busca existente, sabendo-se que a consulta
deve apresentar o livro na primeira pgina retornada. Este caso de teste ilustrativo possui os
seguintes passos:

36

(1) Acessar a aplicao ( www.google.com);

(2) Acessar o link mais (Figura 17);

Figura 17 Link mais - Google

(3) Acessar o link Pesquisa de Livros (Figura 18);

Figura 18 Link Pesquisa de Livros - Google

(4) Digitar o ttulo de um livro existente (The Art of Software Testing) (Figura
19);

Figura 19 Pesquisa de Livros - Google

(5) Clicar no boto Pesquisar livros;

37

(6) Verificar se a consulta retornou o link esperado (Figura 20).

Figura 20 Retorno da Pesquisa de Livros - Google

A Figura 21 ilustra o script criado com a ferramenta XDE Tester para a execuo do
caso de teste Pesquisa_Livros_Google. Este script foi gravado e alterado em seguida.
Somente o cdigo contido no mtodo testMain foi alterado. O restante do cdigo foi gerado
automaticamente, incluindo os comandos import e os comentrios. importante ressaltar
que este trabalho no prope apresentar detalhes de ambiente, configurao ou uso da
ferramenta.

Figura 21 Exemplo de Script de Teste Rational XDE Tester

38

O script da Figura 21 foi gerado com base no template de script de teste da ferramenta
(Listagem 2), o qual pode ser facilmente customizado.
%script:packageDeclaration%
import %helper:fullName%;
import
import
import
import
import

com.rational.test.ft.*;
com.rational.test.ft.object.interfaces.*;
com.rational.test.ft.script.*;
com.rational.test.ft.value.*;
com.rational.test.ft.vp.*;

/**
* Description
: XDE Tester Script
* @author %system:user.name%
*/
public class %script:name% extends %helper:name%
{
/**
* Script Name
: <b>%script:name%</b>
* Generated
: <b>%date% %time%</b>
* Description
: XDE Tester Script
* Original Host : %static:com.rational.test.ft.sys.OperatingSystem.getVersion%
*
* @since %date:yyyy/MM/dd%
* @author %system:user.name%
*/
public void testMain (Object[] args)
{
%script:insertBefore% this entire line will be deleted during initial script
generation
}
}

Listagem 2 Template de Script de Teste Rational XDE Tester

A ferramenta XDE Tester cria um mapa de objetos durante a gravao dos scripts, o
qual pode ser facilmente customizado. Este mapa registra uma pontuao para cada objeto do
browser, baseado em suas caractersticas. Isto permite que a ferramenta identifique os objetos
durante a execuo de um script.
Para a incluso de cada ponto de verificao, o responsvel pela automao deve
destacar o objeto que ser verificado, como uma caixa de texto ou um link, e especificar o
valor esperado para uma determinada propriedade do objeto. No script da Figura 22, aps a
realizao da consulta, inseriu-se um ponto de verificao para conferir se foi retornado o
livro esperado. Para tanto, conforme ilustra a Figura 22, durante a gravao do script, foi
destacado o link de retorno da consulta referente ao ttulo do livro usando-se o recurso Object
Finder (

).

39

Figura 22 Seleo de Objeto Rational XDE Tester

Com

seleo

deste

link,

ferramenta

adicionou

item

Link_TheArtofSoftwareTesting ao Mapa de Objetos (Object Map), incluindo suas

propriedades e pesos a elas associados (Figura 23). Por exemplo, o valor da propriedade
text registrado durante a gravao do script era The Art of Software Testing.

Figura 23 Mapa de Objetos Rational XDE Tester

Desta forma, o XDE Tester consegue reconhecer objetos de interface e o valor de suas
propriedades. importante perceber que cada objeto da tela pertence a uma hierarquia, na
qual o primeiro elemento o prprio browser.

40

Durante a execuo de cada script, as interaes de usurio podem ser assistidas por
um expectador externo, embora a velocidade de algumas operaes seja quase imperceptvel
devido rapidez da ferramenta. Em outras palavras, aes como a conduo do mouse, os
cliques de boto e os preenchimentos de caixa de texto podem ser visualizadas
automaticamente durante a execuo do teste automatizado.
Ao final da execuo, gerado um relatrio de log contendo o registro de algumas
aes realizadas pela ferramenta, indicando se houve sucesso ou falha durante a execuo. A
Figura 24 ilustra o log apresentado via browser aps a execuo do script da Figura 21.

Figura 24 Exemplo de Log de Teste Sem Erros Rational XDE Tester

Para cada seo registrada no log, associado o termo PASS para as aes que
passaram no teste e o termo FAIL para as aes que falharam. A Figura 25 ilustra um log de
execuo do caso de teste Pesquisa_Livros_Google simulando o caso de no ter sido
localizado o link de retorno da consulta.

41

Figura 25 Exemplo de Log de Teste Com Erros Rational XDE Tester

Com o uso framework, uma sute de teste pode ser inteiramente executada, sem
intervenes humanas, pois o seu mecanismo de tratamento de exceo evita a interrupo
dos testes, definindo uma estratgia distinta para cada exceo ocorrida.

2.5 Tcnicas para Criao de Scripts

Em FEWSTER et al. (1999), so apresentadas as seguintes tcnicas par construo de
scripts:

Scripts Lineares;

Scripts Estruturados;

Scripts Compartilhados;

Data-driven;

Keyword-driven.

42

2.5.1 Scripts Lineares

Os scripts lineares so aqueles que implementam suas instrues seqencialmente, no
havendo, portanto, comandos de seleo ou interao. O script apresentado na seo 2.4.1
(Rational XDE Tester) um exemplo de script linear, pois todos os seus comandos so
realizados em seqncia. Em muitos casos, estes scripts so criados simplesmente usando-se a
tcnica Record & Playback, a qual somente implementa scripts lineares. FEWSTER et al.
(1999) afirmam que, usando-se esta tcnica, cada caso de teste ser inteiramente executado
por um nico script.
Existem situaes em que esta a melhor tcnica a ser utilizada, como, por exemplo,
quando o caso de teste ser executado uma nica vez, somente para verificar se o sistema
funciona bem numa determinada plataforma. Em contrapartida, algumas desvantagens so
destacadas em FEWSTER et al. (1999):

Para produzir um teste automatizado, normalmente se necessita de 2 a 10 vezes

mais tempo do que o necessrio para executar o teste manualmente;

As entradas e comparaes so hard-coded;

Um script no compartilhado para compor outros testes;

Scripts lineares so muito vulnerveis a mudanas do software sob teste. Assim,

mais testes automatizados precisam ser comumente recriados ou mantidos quando
o sistema sob teste alterado;

Scripts lineares demandam um alto custo para serem mantidos;

Se algum comportamento que no ocorreu durante a gravao de um script linear

ocorrer durante a sua execuo, como uma mensagem de erro da rede, a execuo
do script pode facilmente ser comprometida, fazendo com que o teste falhe
completamente.

2.5.2 Scripts Estruturados

Scripts estruturados so scripts que implementam estruturas de controle especiais
(seleo ou interao) ou estrutura de chamada a outros scripts, portanto, estes scripts so
programados, mesmo que parcialmente.

43

A estrutura seleo avalia condies que determinam se um conjunto especfico de

instrues ser executado. A estrutura interao possibilita repetir um conjunto de instrues
uma determinada quantidade de vezes. Esta estrutura utilizada, por exemplo, para a leitura
de uma seqncia de registros num arquivo de dados. Neste caso, a seqncia pode ser
executada at que seja concluda a leitura de todos os registros.
Alm disso, um script pode chamar outro script. Este tcnica pode ser usada para
dividir scripts grandes em scripts menores e mais gerenciveis, melhorando o seu reuso.
Embora estes scripts sejam mais flexveis, no esto isentos de dados hard-coded e
as chamadas entre os scripts trazem uma dependncia (acoplamento) que desfavorece o reuso
dos mesmos.
A Listagem 3, adaptada de FEWSTER et al. (1999), ilustra um trecho de script
estruturado para testar se a mensagem Substituir arquivo existente? exibida quando feita
a tentativa de se salvar um arquivo com o mesmo nome de outro existente em diretrio
especfico.

Listagem 3 Exemplo de Script Estruturado

2.5.3 Scripts Compartilhados

Scripts compartilhados so scripts utilizados por mais de um caso de teste. O uso desta
tcnica visa identificar tarefas repetitivas que possam ser reutilizadas por mais de um caso de
teste. Neste caso, so criados scripts que realizam tais tarefas, para que sejam chamados num
ponto especfico de um caso de teste.
O compartilhamento destes scripts pode ser feito entre casos de teste de um mesmo
sistema ou de diferentes sistemas. Entre as vantagens desta tcnica, destaca-se principalmente
a melhoria do reuso de scripts. Entre as desvantagens, destaca-se a existncia de um nmero
maior de scripts para serem mantidos.

44

Embora esta tcnica aumente o reuso dos scripts, os mesmos ainda podem apresentar
dados hard-coded ou chamadas a outros scripts, tornando-os dependentes entre si.
A Figura 26, adaptada de FEWSTER et al. (1999), ilustra o diviso de um script linear
(IncluirFuncionario) em outros trs scripts. O primeiro (AbrirArquivo) abre o arquivo que lhe
passado como parmetro. O segundo (SalvarComo) salva o arquivo com o nome recebido
como parmetro em sua chamada. O terceiro (IncluirFuncionrio) ir chamar os dois outros
scripts, um no incio e outro ao final de sua execuo.

Figura 26 Exemplo de Aplicao da Tcnica Scripts Compartilhados

2.5.4 Data-Driven
A tcnica Data-driven consiste em eliminar dados de teste do corpo do script e inserilos em arquivos de dados independentes ou tabelas. A principal vantagem desta
independncia entre o cdigo dos scripts e os dados de teste permitir que o script seja
reutilizado para vrios conjuntos de dados de entrada. Alm disso, novos testes podem ser
adicionados sem o conhecimento da linguagem de programao de script correspondente.
A Figura 27, adaptada de FEWSTER et al. (1999), apresenta um exemplo simplificado
do uso desta tcnica.

45

Figura 27 Exemplo de Aplicao da Tcnica Data-driven

Como principais desvantagens, esta tcnica exige um esforo de configurao inicial e

experincia na respectiva linguagem de programao, devido necessidade de manuteno do
cdigo dos scripts.

2.5.5 Keyword-Driven
A tcnica Keyword-driven prope separar o desenvolvimento dos casos de teste do
desenvolvimento dos scripts de teste. Isto possibilita que testadores experientes no domnio da
aplicao concentrem-se na criao dos arquivos de teste, enquanto que profissionais com
conhecimento tcnico concentrem-se nos scripts de suporte.
O uso da tcnica Keyword-driven diminui a complexidade dos scripts, pois, assim
como ocorre quando descrevemos um teste manual, permite que os casos de teste sejam
especificados de maneira menos detalhada.
A Figura 28, adaptada de FEWSTER et al. (1999), ilustra como esta tcnica pode ser
aplicada.

46

Figura 28 Exemplo de Aplicao da Tcnica Keyword-driven

Neste exemplo, destacam-se as seguintes palavras-chave (keywords): Loggin,

FazerMatricula,

CancelarMatricula,

IncluirDisciplina,

ExcluirDisciplina,

IncluirProfessor e ExcluirProfessor. Para cada keyword, existe um script de suporte

especifico, o qual ser responsvel por realizar suas aes correspondentes.
As keywords tanto podem representar eventos simples, como um clique num boto, a
eventos mais complexos, como, por exemplo, o processamento de uma opo do sistema que
envolva navegar em vrias telas. Independente da complexidade do mdulo, as keywords
representam aes, de maior ou menor complexidade, sobre a interface do sistema.
O framework FuncTest possibilita utilizar as tcnicas Data-driven e Keyword-driven
na estruturao de testes reusveis e manutenveis.

2.6 Concluso
Neste captulo, foi apresentada uma viso sobre teste de software e sobre automao
de testes funcionais, contextualizando a soluo desenvolvida. Foram apresentadas algumas
limitaes do uso de ferramentas Record and Playback, as quais podem comprometer a
criao, o reuso e a manutenibilidade dos scripts de teste. Em seguida, foram abordadas
algumas tcnicas para otimizar a criao dos scripts de teste.

Captulo 4
3. O Framework FuncTest

Este captulo aborda o framework FuncTest, descrevendo os relacionamentos

entre os elementos que compem a sua estrutura e detalhando o seu
funcionamento.

3.1 Introduo
O framework FuncTest foi construdo e validado no SERPRO (Servio Federal de
Processamento de Dados) com o intuito de melhorar a produtividade da automatizao de
testes funcionais executados por ferramentas Record and Playback. Ele foi desenvolvido na
ferramenta Rational XDE Tester, mas poder ser adaptado para uso em ferramentas similares,
que tambm trabalhem com scripts desenvolvidos em linguagem Java.
A arquitetura do framework, alm de possibilitar o desenvolvimento eficiente de sutes
de teste flexveis, garante um estratgico avano de equipes que iniciam as suas experincias
em automao de testes funcionais.
A principal vantagem de utilizar o framework minimizar o esforo de implementao
e, principalmente, de manuteno de testes automatizados. Portanto, sua arquitetura foi
idealizada para proporcionar maior reuso de cdigo e melhorar a manutenibilidade das sutes
de teste. Com este objetivo, foram aplicados padres de software para estruturar a arquitetura
do FuncTest. Alm disso, o framework favorece a aplicao das tcnicas Data-driven e
Keyword-driven, apresentadas anteriormente.
Dentre as caractersticas do framework, destacam-se:

o controle centralizado de chamadas aos scripts, evitando a dependncia entre eles;

a associao entre os casos de teste e os scripts criados para a execuo de seus

steps;

o acesso aos dados de teste, permitindo mais reuso dos scripts;

48

o tratamento de erros centralizado, evitando interrupes durante a execuo dos

testes.

Estas responsabilidades possibilitam preservar no corpo dos scripts somente aes de

interao com interface de usurio. Desta forma, a chamada entre os scripts, o acesso aos
dados de teste e o controle de erros so desvinculados dos scripts, favorecendo o reuso e a
manuteno dos mesmos.
A proposta promove a estruturao de sutes de teste que contenham um nmero
arbitrrio de casos de teste. As aes de um caso de teste, aqui denominadas de steps, muitas
vezes so comuns a outros casos de teste. importante ento que o cdigo relativo a estas
aes seja compartilhado, para que o esforo de criao e de manuteno dos testes
automatizados possa ser minimizado. Desta forma, o framework proporciona a criao de um
script para cada step de um caso de teste. Assim, os scripts gravados (ou programados)
representam, portanto, aes bastante especficas, como, por exemplo, escolher uma opo de
menu do sistema.
Nos projetos em que o framework foi utilizado, cada caso de teste corresponde a um
cenrio de um caso de uso. A metodologia de derivao dos casos de teste a partir dos casos
de uso est definida no processo padro de desenvolvimento de software do SERPRO. A
Figura 29 apresenta esta relao, ilustrando tambm a correspondncia entre scripts e steps de
um caso de teste.

49

Figura 29 Granularidade de Scripts de Teste - FuncTest

O reuso de testes se d tanto pelo compartilhamento de scripts de teste entre os casos
de teste quanto pelo reuso de casos de teste que precedem a execuo de outros casos de teste.
Neste caso, o framework permite configurar um ou mais casos de teste como composio de
um outro.
Este captulo ir detalhar a arquitetura do FuncTest, descrevendo o seu funcionamento
e evidenciando a aplicao dos padres referidos. Na seo 3.2, ser apresentada uma viso
resumida sobre frameworks. A seo 3.3 apresentada uma viso geral sobre padres de
software. A seo 3.4 apresenta os padres utilizados na composio da arquitetura do
framework. A seo 3.5 apresenta a arquitetura do framework. A seo 3.6 apresenta o
funcionamento do framework. A seo 3.7 evidencia a aplicao dos padres de projeto no
framework. Por fim, a seo 3.8 apresenta um exemplo de uso do framework.

50

3.2 Frameworks
Segundo VILJAMAA (2001), framework um conjunto de objetos reutilizveis que
engloba conhecimento de determinadas reas e se aplica a um domnio especfico.
Diferentemente dos componentes de uma biblioteca de classes, os quais so utilizados
individualmente, as classes de um framework so reutilizadas como um todo para resolver
uma instncia de um certo problema (LAJOIE, 2003). Portanto, o uso de frameworks pode
acelerar o desenvolvimento de novos projetos e garantir uma arquitetura padronizada,
permitindo que a equipe de desenvolvimento possa se concentrar em detalhes especficos das
aplicaes.
O conceito de frameworks na literatura heterogneo. Segundo GOMES (2002), h
os que o classificam como uma aplicao inacabada, como uma arquitetura de software,
como uma meta-aplicao, como um template de grau mais elevado, ou at como um
componente. Tambm ressalta que, independentemente do conceito que seja dado aos
frameworks, os seguintes fatores devem ser levados em conta: um modelo de aplicao
orientado ao objeto; est incompleto; pode ser estendido, portanto flexvel; reutilizvel;
pertence a um domnio especfico de aplicaes; constitudo principalmente por um
conjunto de classes e suas interconexes; disponibiliza um padro a ser seguido e uma srie
de funcionalidades pr-definidas; tem o propsito de gerar aplicaes completas atravs da
personalizao de suas instncias.
Existe um estreito relacionamento entre frameworks e padres de projeto,
especialmente porque os padres de projeto tipicamente promovem flexibilidade de software,
caracterstica essencial para possibilitar a especializao de frameworks em projetos reais.
Neste contexto, padres de projeto podem ser utilizados (BRINGEL FILHO, 2004).
Os frameworks so divididos em frozen spots e hot spots. Os frozen spots so partes
invariveis de um framework, as quais definem uma arquitetura genrica de um software. Os
hot spots representam as partes flexveis de um framework, sob a qual os desenvolvedores
adicionam seu prprio cdigo para incorporar funcionalidades especficas do projeto.
(VILJAMAA, 2001; PREE, 1994).
A Figura 30, adaptada de GOMES (2002), ilustra pontos em comum entre aplicaes
que instanciam um framework.

51

Figura 30 Granularidade de Scripts de Teste - FuncTest

Os frozen spots e os hot spots do FuncTest esto destacados na seo 3.5 (Arquitetura
do Framework).
Dentre as diversas classificaes existentes, os frameworks enquadram-se em um dos
seguintes tipos (FAYAD, 1999):

frameworks caixa-branca (whitebox frameworks): so frameworks cujos cdigos

fonte podem ser acessados e customizados. O FuncTest um exemplo de
framework caixa-preta;

frameworks caixa-preta (blackbox frameworks): so frameworks cujos cdigos

fonte no esto totalmente disponveis, tornando necessria a criao de novos
componentes para fazer as devidas adaptaes.

3.3 Padres de Software

Frente aos desafios da indstria de software, profissionais da rea comumente se
deparam com problemas cujas solues precisam ser cuidadosamente idealizadas. No entanto,
para os mesmos problemas, normalmente existem solues comprovadamente boas e
possveis de serem reutilizadas. Neste sentido, padres de software tornam acessveis as
solues mais utilizadas na rea de software para problemas recorrentes de diferentes
domnios (organizacional, de anlise, de projeto, de implementao etc).
O termo Padro (Pattern) usado em diversas reas para designar uma boa soluo
para um problema recorrente num determinado contexto. Os primeiros padres surgiram na

52

dcada de 70, quando o arquiteto Christopher Alexander publicou a obra A Pattern

Language (ALEXANDER, 1977) abordando 253 padres no contexto de arquitetura urbana.
Segundo Christopher Alexander, cada padro descreve um problema que ocorre
repetidas vezes em nosso ambiente, e descreve a soluo para este problema, de modo que
possamos usar esta soluo milhes de vezes sem precisarmos faz-lo de uma mesma
maneira (ALEXANDER, 1977). Em seu livro The Timeless Way of Building
(ALEXANDER, 1979), Christopher Alexander define padro como uma relao entre um
certo contexto, um problema e uma soluo.
Aps alguns anos, em 1987, foram propostos os primeiros padres para a rea da
computao, quando os programadores Kent Beck e Ward Cunningham publicaram o trabalho
Using Pattern Languages for Object-Oriented Programs na conferncia OOPSLA (ObjectOriented Programming, Systems, Languages & Applications) promovida pela ACM
(Association for Computing Machinery) no referido ano. Este trabalho apresenta alguns
padres para projetar janelas usando a linguagem de programao Smalltalk.
O uso de padres na computao ganhou mais popularidade quando Erich Gamma,
Richard Helm, Ralph Johnson e John Vlissides, em1995, publicaram a obra Design Patterns:
Elements of Reusable Object-Oriented Software (GAMMA, 1995). Os autores ficaram
conhecidos como Gang of Four GoF (Gangue dos Quatro). Os padres propostos no livro
so popularmente conhecidos como Padres GoF. Neste livro, so apresentados 23 padres
de projeto (design patterns), ou seja, 23 solues de projeto, para sistemas orientados a
objetos (OO).
A utilizao de padres permite que grupos comuniquem idias amplas e solues
complexas de maneira eficiente (LAPLANTE, 2005). De acordo com SOUZA (2007), alm
de fornecer um vocabulrio comum para expressar solues e uma linguagem para
relacion-las, os padres permitem a criao de uma biblioteca de solues para ajudar na
resoluo de problemas recorrentes, incentivando uma cultura de documentao e reuso de
boas prticas no processo de desenvolvimento de sistemas computacionais.
A seguir, alguns definies de padro encontradas na literatura so apresentadas:

Uma relao entre um certo contexto, um certo sistema de foras que ocorrem
repetidamente naquele contexto, e uma certa configurao espacial que permite
que estas foras se solucionem por si s (ALEXANDER, 1979);

53

Uma configurao estrutural recorrente que resolve um problema em um

contexto (COPLIEN, 2004);

Uma regra de trs partes, que expressa a relao entre um certo contexto, um
certo sistema de foras que ocorre repetidamente naquele contexto, e uma certa
configurao de software que permite solucionar as foras (GABRIEL, 2002);

Uma pea de literatura que descreve um problema de projeto e uma soluo

genrica para o problema num contexto particular (COPLIEN, 2006).

H diversos tipos de padro, incluindo padres organizacionais, de processo etc. A

seo 3.3.1 apresenta alguns tipos.

3.3.1 Classificao de Padres de Software

Padres de Software so classificados sob diferentes critrios. Nesta seo, ser
apresentada uma classificao segundo o estgio de desenvolvimento de software no qual o
padro utilizado, conforme ilustrado na Figura 31 (Santos, 2004).

Figura 31 Classificao de Padres de Software Segundo o Ciclo Desenvolvimento

3.3.2 Padres de Requisitos

Padres de requisitos documentam as necessidades de usurios e o comportamento
genrico de sistemas num alto nvel de abstrao (ANDRADE, 2001). Eles capturam a

54

poltica de processamento de um negcio especfico e so usados no incio de um projeto para

ajudar a especificar requisitos de software (ROBERTSON, 1996).
Konrad et al. (2002) explora o uso de notaes de modelagem orientada a objetos,
assim como a UML (Unified Modeling Language), para representar padres de requisitos
funcionais e no-funcionais, com foco em padres para sistemas embarcados (embedded
systems).
Robertson (1996) discute o uso de modelagem de evento/caso de uso (event/use case)
para identificar, definir e acessar padres de processo de requisitos. Withall (2007) detalha 30
padres de requisitos para a construo de requisitos de software efetivos, oferecendo
exemplos realistas para situaes especficas. Andrade (2001) prope uma linguagem de
padres, denominada MoRar (Mobility and Radio Resource), que possibilita a gerao de
diferentes modelos de requisitos para sistemas mveis.

3.3.3 Padres de Anlise

So grupos de conceitos que representam uma construo comum em modelagem de
negcio, podendo ser relevantes para um determinado domnio ou para muitos domnios. Eles
refletem estruturas conceituais de processos de negcio, ajudando a entender como as pessoas
pensam sobre o negcio (FOWLER, 1997). Evidentemente, os padres de anlise independem
da tecnologia que ser utilizada na construo do software.
Em Fowler (1997), so apresentados padres de anlise para vrios domnios de
negcio, como, por exemplo, padres para planejamento e padres relacionados rea
financeira e rea de contabilidade.

3.3.4 Padres de Arquitetura

Padres de Arquitetura so padres que expressam esquemas fundamentais para
organizao estrutural de sistemas de software. Eles provem um conjunto de subsistemas
predefinidos, especifica suas responsabilidades, e incluem regras e guias para os
relacionamentos entre as eles (BUSCHMANN, 1996).
Estes padres definem templates para arquiteturas de software concretas. Eles
especificam propriedades estruturais de uma aplicao em um alto nvel de abstrao. A

55

seleo de um padro arquitetural uma deciso de projeto fundamental quando se

desenvolve um software (BUSCHMANN, 1996).
Este trabalho descreve o padro de arquitetura Model-View-Controller (MVC) de
acordo com BUSCHMANN (1996). Este padro foi utilizado para definir a arquitetura do
framework desenvolvido, em seu nvel mais alto de abstrao.

3.3.5 Padres de Projeto

Padres de projeto so descries de objetos que se comunicam e classes que so
customizadas para resolver um problema de projeto genrico em um contexto especfico
(GAMMA, 1995).
Os padres de projeto fornecem um vocabulrio compartilhado entre desenvolvedores.
Isto possibilita uma comunicao fcil, incentiva outros desenvolvedores a conhecer os
padres e eleva o raciocnio sobre as arquiteturas, permitindo que as discusses se dem em
nvel de padres e no em nvel de objetos. Dentre os benefcios de se usar um vocabulrio
compartilhado de padres, destacam-se (FREEMAN, 2004):

Os vocabulrios so eficazes: quando se usa um vocabulrio de padres, um

conjunto inteiro de qualidades, caractersticas e restries pode ser comunicado
usando-se simplesmente o nome dos padres;

Permitem dizer mais com menos: quando se utiliza um padro em uma descrio,
outros desenvolvedores identificam precisamente o design que se tem em mente;

Permitem que se permanea em nvel de projeto por mais tempo: falar sobre
sistemas de software usando padres permite manter a discusso em nvel de
projeto, sem necessariamente entrar em detalhes de implementao;

Aumentam o desempenho da equipe: uma equipe que domina padres de projeto

pode produzir mais rpido e com menor probabilidade de entendimentos
equivocados.

Em Gamma et al. (1995), os padres de projeto so classificados sob dois critrios:

Propsito: reflete o que o padro faz;

Escopo: especifica se o padro se aplica primariamente a classes ou a objetos.

56

Quanto ao propsito, os padres so subdivididos em:

Padres Criacionais: documentam solues relacionadas ao processo de criao de

objetos;

Padres Estruturais: documentam solues relacionadas composio de classe e

objetos;

Padres Comportamentais: caracterizam a forma da qual classes ou objetos

interagem e distribuem responsabilidade.

Quanto ao escopo, os padres so subdivididos em:

Padres de Classe: aplicam-se primariamente a classes;

Padres de Objetos: aplicam-se primariamente a objetos.

Este trabalho utiliza os padres de projeto Factory Method e DAO na composio da

arquitetura proposta.

3.3.6 Metapadres
Um metapadro um conjunto de padres de projeto que descreve como construir
frameworks independentes de um domnio especfico. Eles constituem uma abordagem
elegante e poderosa para classificar e descrever padres em um metanvel (PREE, 1995). Eles
descrevem blocos de construo prontos para uso ou semi-acabados.
Em estgios de projeto e implementao, metapadres provem as principais
construes para o desenvolvimento de um framework bem projetado. Um framework
considerado bem projetado quando a composio e a interao entre os blocos de construo
que constituem toda a arquitetura do sistema so bem definidos (ANDRADE, 2001).
Em Souza (2005), o conceito inicial definido por Pree (1995) no contexto de padres
de projeto ampliado para metapadres no contexto de padres de requisitos e padres de
teste. No mesmo trabalho, proposto um catlogo de padres para auxiliar o processo de
desenvolvimento de sistemas de informao.

57

3.3.7 Idiomas (Programming Idioms)

Mais conhecidos como Idiomas, padres de implementao descrevem construes de
cdigo para uma ou mais linguagens de programao. Isto inclui, por exemplo, cdigos para a
realizao de loops em vetores, incremento de contadores, troca de valores entre variveis,
expresses condicionais etc. Em COPLIEN (2000), so apresentados padres especficos para
a linguagem C++.

3.3.8 Padres de Teste

Padres de teste so orientaes para as atividades de teste, incluindo documentao,
execuo e divulgao de resultados (RISING, 2000).
Souza et al. (2005) apresenta os seguintes padres de teste:

Padro Teste CRUD: utilizado para especificar os casos de teste das operaes de
Incluso, Consulta, Alterao e Excluso (CRUD). Este padro indica idias de
teste tpicas e cenrios de falha recorrentes para as quatro operaes citadas
(CRUD), os quais facilitam e agilizam a execuo dos testes. Como exemplos de
idias tpicas para testar operaes CRUD, so citados: inserir entidade j existente
e verificar resultado; inserir nova entidade e verificar se os dados so iguais aos
fornecidos na insero;

Padro Teste Relatrio: utilizado para especificar casos de teste de relatrios. Este
padro apresenta testes tpicos e cenrios de falhas recorrentes na visualizao,
exportao ou impresso dados de entidades de acordo com filtros especificados,
agrupamentos, totalizaes e informaes a serem apresentadas. Como exemplos
de idias tpicas para testes de relatrios, so citados: verificar resultados em
combinaes de filtros de relatrio; verificar visualizao e impresso; verificar
totalizaes, clculos e agrupamentos; verificar formato; verificar formato e dados
em arquivos exportados;

Padro Teste Assistente: utilizado para especificar os casos de teste de operaes

complexas, na qual diversas decises devem ser tomadas antes que a operao
possa ser concluda completamente. Este padro indica idias de testes tpicas e
cenrios de falhas recorrentes na seqncia de passos, retorno, parametrizao e

58

decises. Como exemplos de idias tpicas para testes para este tipo de operao,
so citados: verificar seqncia correta dos passos; verificar mensagens e
explicaes dos passos; verificar se as informaes dos passos anteriores so
passadas de forma correta entre os contextos; verificar resultado final da transao;

Padro Teste Transao: utilizado para especificar os casos de teste de operaes

que possuem execuo de longa durao ou que so executadas em formato de
comando atmico. Este padro indica idias de testes tpicas e cenrios de falhas
recorrentes na parametrizao, no tratamento de falhas e na recuperao de
transaes. Como exemplos de idias de testes tpicas para transaes, so citados:
verificar se a parametrizao da transao requerida de acordo com
especificao; solicitar execuo da transao sem informar os parmetros
necessrios; verificar resultado final da transao de acordo com a parametrizao;
executar a transao e provocar falha durante processamento (interromper
aplicao, por exemplo) e verificar a consistncia do resultado.

Em BINDER (1999), THOMAS et al. (2004) e MESZAROS (2007) so apresentados

alguns padres de teste para testes unitrios.
Neste trabalho, no so aplicados ou propostos padres de teste, pois a presente
problemtica

restringe-se

criao

de

uma

arquitetura

flexvel

para

aumentar

manutenibilidade de sutes de teste automatizadas. Tambm no foram encontrados na

literatura padres de teste especficos para solucionar problemas advindos do uso de
ferramentas Record and Playback.

3.3.9 Anti-Padres
certamente til estudar maneiras bem sucedidas de resolver problemas. tambm
proveitoso aprender com erros cometidos. Este o conceito por trs de anti-padres.
Enquanto padres descrevem boas solues para problemas recorrentes, anti-padres
(AntiPatterns) descrevem solues que trazem mais conseqncias negativas do que
benefcios (LAPLANTE et al., 2005). Segundo APPLETON (2000), se um padro
representa uma melhor prtica, ento um anti-padro representa uma lio aprendida.
H dois tipos de anti-padro (KOENIG, 1995):

59

Aqueles que descrevem soluo ruim para um problema que resultou em uma
situao ruim;

Aqueles que descrevem como se livrar de uma situao ruim e como proceder para
uma boa soluo a partir dela.

3.3.10 Coletneas de Padres

So agrupamentos que possibilitam expor relacionamentos, dependncias ou
combinaes entre padres, se houver (SOUZA, 2007).

Coleo de Padres: uma coletnea de padres onde os padres no possuem

relacionamento entre si, ou seja, eles funcionam de maneira isolada;

Catlogo de Padres: uma coletnea de padres relacionados fracamente ou

isoladamente;

Sistema de Padres: uma coletnea de padres co-relacionados que apia a

construo e evoluo de arquiteturas completas;

Linguagem de Padres: O termo linguagem de padro utilizado para designar

uma coleo de padres e um conjunto de regras para combin-los num estilo
arquitetural (COPLIEN, 2007). Uma linguagem de padro no s apresenta regras
para a gerao de combinaes, como tambm mostra como construir combinaes
que satisfaam a essas regras (ALEXANDER, 1979).

3.4 Padres Utilizados

Os padres MVC, Factory Method e DAO, os quais sero descritos a seguir, foram
escolhidos para compor o framework FuncTest no intuito de fornecer, respectivamente:

Independncia entre o mecanismo de entrada de dados (View), a lgica da

aplicao (Controller) e os scripts e dados de teste (Model);

Transparncia na obteno dos scripts de teste e objetos DAO;

Transparncia no acesso aos dados de teste.

60

3.4.1 Padro MVC

O padro Model-View-Controller (BUSCHMANN, 1996) um padro de arquitetura
que prope a separao das classes de um sistema em trs grupos: Model, View e Controller.
O componente Model o objeto da aplicao, o qual contm os seus principais dados e as
suas principais funcionalidades. O Model tambm prov funes para acessar seus dados. O
objeto View recebe e apresenta informaes para o usurio, mantendo a consistncia com o
respectivo modelo, e o Controller define a maneira com que a interface grfica reage s aes
de usurio (GAMMA, 1995; BUSCHMANN, 1996).
O objetivo principal do padro MVC separar dados e lgica de negcio (Model) da
interface de usurio (View) e do fluxo da aplicao (Controller). Desta forma, os trs
componentes podem sofrer alteraes sem impactar nos demais.
Este padro separa vises e modelos estabelecendo um protocolo entre eles. Uma view
precisa garantir que sua aparncia reflita o estado do modelo. Esta flexibilidade permite que
sejam criadas diferentes vises para um modelo, sem precisar reescrev-lo (GAMMA, 1995).
O MVC tambm permite modificar a maneira com que o sistema responde s entradas
de usurio, sem necessidade de alterao na camada viso. Isto se torna possvel porque este
padro encapsula o mecanismo de resposta num objeto Controller. Pode haver uma hierarquia
de controlles, tornando fcil a criao de um novo controller como uma variao de uma j
existente (GAMMA, 1995).
A Figura 32 (ALMEIDA, 2007) ilustra o fluxo de eventos entre os componentes de
uma arquitetura MVC.

Figura 32 Fluxo de eventos e informaes em uma arquitetura MVC

A seo 3.5 esclarece o uso do padro MVC na estruturao do framework FuncTest.

61

3.4.2 Padro Factory Method

O padro criacional Factory Method (GAMMA et al., 1995), tambm conhecido como
Virtual Constructor, lida com o problema de se trabalhar com objetos de uma classe
desconhecida, eliminando a necessidade do Cliente conhecer o nome classe que ir trabalhar.
Este padro prope a definio de uma interface (Product) que especifica um modelo
para classes (ConcreteProduct) que sero utilizadas pela classe cliente. Assim, cria-se na
classe Cliente um objeto da interface Product e atribui a ele a chamada a um mtodo fbrica
(Factory Method) da classe ConcreteCreator, a qual implementa a classe abstrata Creator.
Este mtodo ir retornar um objeto da classe ConcreteProduct correspondente.
Para tanto, o padro prope que seja definido, na classe abstrata Creator, um mtodo
fbrica abstrato, que retorna um objeto da interface Product. Este mtodo ser implementado
em uma classe concreta (ConcreteCreator), a qual sobrescreve o mtodo fbrica da classe
abstrata

Creator.

classe

ConcreteCreator

ento

decidir

objeto

concreto

(ConcreteProduct) a ser criado e retornado (GAMMA et al., 1995). Portanto, a classe Cliente
chamar o mtodo fbrica implementado na classe ConcreteCreator e atribuir o retorno
deste mtodo ao seu objeto da interface Product.
A Figura 33 (GAMMA et al., 1995) ilustra o diagrama de classes do padro Factory
Method.

Figura 33 Diagrama de Classes do Padro Factory Method

Segue o escopo de cada participante do padro:

Product: define a interface de objetos que sero criados por um Factory Method;

62

ConcreteProduct implementa a interface Product;

ConcreteProduct:

Creator:: declara o Factory Method,, o qual retorna um objeto do tipo Product.

Pode definir uma implementao default do referido mtodo que retorna um objeto
ConcreteProduct default.

ConcreteCreator implementa o construtor virtual atravs do mtodo concreto

ConcreteCreator:
FactoryMethod,, que retorna uma instncia de uma classe ConcreteProduct.
ConcreteProduct

3.4.3 Padro Data

ata Access Object (DAO)
O padro DAO (ALUR, 2003) utilizado quando se deseja encapsular o modo de
acesso a dados. Ele permite a utilizao de fontes de dados distintas, tornando a obteno dos
dados transparente para a classe de negcio. A Figura 34 (SUN, 2007),, ilustra o diagrama de
classes do padro DAO.

Figura 34 Diagrama de Classes do Padro DAO

Conforme representado no diagrama, a classe de negcio (BusinessObject
(BusinessObject) acessa a
fonte de dados atravs de uma classe DataAccessObject especfica, a qual gerencia a conexo
com a respectiva fonte. Os dados trocados entre objetos BusinessObject e DataAccessObject
so mantidos num objeto da classe TransferObject.
Segue o escopo de cada participante do padro (SUN, 2007):

BusinessObject:: representa
representa o cliente dos dados. o objeto que requer acesso
fonte de dados.

DataAccessObject: o objeto principal do padro. Ele torna a implementao de

DataAccessObject:
acesso aos dados transparente para o objeto BusinessObject;

63

DataSource: representa uma implementao da fonte dados. Uma fonte de dados

pode ser um banco de dados, um sistema, um servio, ou outro tipo de persistncia.

TransferObject: representa um objeto de transferncia que comporta os dados do

cliente. O DataAccessObject pode usar o TransferObject tanto para retornar dados
ao cliente quando para receber dados do cliente.

3.5 Arquitetura do Framework

A arquitetura do FuncTest implementa o padro de arquitetura Model-View-Controller
(MVC) e os padres de projeto Factory Method e DAO (Data Access Object). O MVC define
a arquitetura do framework em seu nvel mais alto de abstrao. O padro Factory Method
utilizado em duas situaes. Na primeira, ele abstrai a criao de objetos DAO. Na segunda,
ele abstrai a instanciao de scripts de teste. O padro DAO utilizado para fornecer
transparncia no acesso aos dados de teste a serem utilizados pelos scripts de teste
correspondentes.
Utilizando o padro arquitetural MVC, os participantes do framework so distribudos
entre as trs camadas do padro (Figura 35). A camada View, no presente contexto,
responsvel por receber as entradas dos testes, que correspondem aos casos de teste da sute.
A camada Controller responsvel por atender s requisies da camada View; portanto, ir
prover a execuo dos scripts correspondentes aos casos de teste da sute. Para isto, a camada
Controller ir solicitar camada Model os scripts e os dados de teste necessrios execuo
da sute. A aplicao dos padres Factory Method e DAO ser detalhada na seo 3.7.

64

Figura 35 Arquitetura do FuncTest

O FuncTest acessa diversos arquivos XML. Estes arquivos precisam ser configurados
para o devido funcionamento das sutes de teste que instanciam o framework. Isto minimiza a
manuteno de cdigo dos scripts, e pode diminuir a necessidade de conhecimento
especializado em programao.
A configurao do framework realizada, basicamente, atravs destes arquivos XML.
Dentre as informaes contidas nestes arquivos, destacam-se a relao dos casos de teste que
iro compor a sute de teste e a relao dos steps correspondentes. Estes e outros arquivos
sero detalhados na seo 3.5.2.
Como todo framework, o FuncTest possui partes fixas, denominadas frozen spots, e
partes variveis, denominadas hot spots. As classes que compem as camadas View e
Controller do framework correspondem aos frozen spots da soluo. O conjunto de arquivos
XML e os scripts que compem a camada Model correspondem aos hot spots do framework.

65

3.5.1 Pacotes do Framework

As classes do framework esto distribudas entre os pacotes Model, View e Controller.
O diagrama de classes da Figura 36 mostra uma viso resumida de seus pacotes,
contemplando as suas classes mais importantes.

Figura 36 Diagrama de Classes do FuncTest

A classe Principal responsvel por promover a entrada dos casos de teste que iro
ser executados. Ela solicita classe Controlador a execuo de cada caso de teste da sute. De
posse de cada caso de teste, a classe Controlador solicita s classes FabricaScript e
FabricaDAO os scripts e os dados de teste (quando houver) referentes a cada step do caso de
teste. Para cada step, a classe Controlador executa um script correspondente. Caso ocorra erro
durante a execuo de um script, a classe ControladorErro trata a exceo para evitar que os
testes sejam interrompidos.

3.5.2 Arquivos de Configurao

Para cada sute de teste criada com o uso do FuncTest, os seguintes arquivos XML
precisam ser configurados: Suite.xml, <NomeDoCasoDeTeste>.xml, Scripts.xml, Erros.xml,
Banco.xml e DataSource.xml. Estes arquivos sero brevemente descritos a seguir.

66

3.5.2.1 Suite.xml
O arquivo Suite.xml indica ao framework os casos de teste que pertencem sute. Este
arquivo acessado pela classe Principal. Ele formado por um conjunto de elementos
CasoTeste (Listagem 4), os quais se subdividem em:

Nome: nome do caso de teste;

Arquivo: nome do arquivo XML com a descrio do caso de teste.

TEMPLATE SUITE.XML

<CasoTeste>
<Nome>NomeDoCasoDeTeste1</Nome>
<Arquivo>NomeDoCasoDeTeste1.xml</Arquivo>
</CasoTeste>
<CasoTeste>
<Nome>NomeDoCasoDeTeste2</Nome>
<Arquivo>NomeDoCasoDeTeste2.xml</Arquivo>
</CasoTeste>

Listagem 4 Template para criao do arquivo Suite.xml

3.5.2.2 <NomeDoCasoDeTeste>.xml
Para cada caso de teste da sute, dever ser criado um arquivo XML composto por
elementos Step (Listagem 5), que se subdividem em:
Nome: nome do step;
DataSource: este marcador opcional. Ela define um datasource para casos em que o
script manipula dados.

TEMPLATE <NOMEDOCASODETESTE>.XML

<step>
<Nome>Step01</Nome>
</step>

67

<step>
<Nome>Step02</Nome>
<DataSource>NomeDataSource</DataSource>
</step>

Listagem 5 Template para criao dos arquivos <NomeDoCasoDeTeste>.xml

3.5.2.3 Scripts.xml
Este arquivo representa a associao entre cada step da sute e seu script
correspondente (Listagem 6). Cada elemento do arquivo corresponde a um step.

TEMPLATE SCRIPTS.XML

<NomeStep01>Script01</Step01>
<NomeStep02>Script02</Step02>

Listagem 6 Template para criao do arquivo Scripts.xml

3.5.2.4 Banco.xml
Este arquivo associa classes DAO aos SGBDs utilizados. Para cada SGBD, deve ser
criado um elemento que contm o nome da classe DAO correspondente (Listagem 7).

TEMPLATE BANCO.XML

<ORACLE>DAOOracle</ORACLE>
<SQLSERVER>DAOSQLServer</SQLSERVER>
<DB2>DAODB2</DB2>
<ACCESS>DAOAccess</ACCESS>
<INTERBASE>DAOInterbase</INTERBASE>
<MYSQL>DAOMySQL</MYSQL>
<SYBASE>DAOSybase</SYBASE>

68

Listagem 7 Template para criao do arquivo Banco.xml

3.5.2.5 DataSource.xml
Este arquivo contm informaes das diversas fontes de dados utilizadas pela sute
(Listagem 8). Para cada step que possua um datasource a ele associado, as informaes do
datasource so capturadas pela classe Controlador e enviadas para a classe DAO. A classe
DAO ento retorna os dados de teste.

TEMPLATE DATASOURCE.XML

<NomeDataSource01>
<Conexao>StringConexao</Conexao>
<Driver>NomeDriver</Driver>
<Tabela>NomeTabela</Tabela>
<Login>Login</Login>
<Senha>Senha</Senha>
<Banco>Banco01</Banco>
</NomeDataSource01>

Listagem 8 Template para criao dos arquivos DataSource.xml

3.5.2.6 Erros.xml
Para cada exceo que possa ocorrer durante a execuo da sute de teste, poder ser
criada uma classe que ir trat-la, a qual dever ter seu nome associado ao nome da exceo
correspondente no arquivo Erros.xml (Listagem 9).

TEMPLATE ERROS.XML

<Excecao1>Nome.do.Script.que.trata.a.Excecao1</Excecao1>
<Excecao2>Nome.do.Script.que.trata.a.Excecao2</Excecao2>

Listagem 9 Template para criao do arquivo Erros.xml

69

A seo 3.6 apresenta o funcionamento do framework.

3.6 Funcionamento do Framework

O diagrama de seqncia da Figura 37 resume o fluxo de mensagens entre as classes
do framework.

Figura 37 Diagrama de Seqncia Simplificado do framework FuncTest

A classe Principal responsvel por iniciar o processo de automao. Ela ir solicitar
classe Util, responsvel pela deserializao de todos os arquivos XML, os casos de teste
contidos no arquivo Suite.xml.
Para cada caso de teste, a classe Principal ir criar um objeto da classe CasoTeste e
solicitar classe Controlador a sua execuo.
A classe Controlador, aps receber um objeto casoTeste da classe Principal, ir obter
da classe Util os steps do caso de teste correspondente contidos no arquivo
<NomeDoCasoDeTeste>.xml.
Para cada objeto step criado, caso exista dado de teste a ser recuperado na base de
dados, a classe Controlador solicita FabricaDAO a criao de um objeto concreteDAO,

70

correspondente ao SGBD que passado como parmetro. Em seguida, o objeto concreteDAO

recupera para a classe Controlador os respectivos dados de teste, os quais so retornados sob
a forma de um vetor de objetos. Em seguida, a classe FabricaScript ir retornar para a classe
Controlador o script correspondente ao step que lhe passado como parmetro.
Por fim, a classe Controlador ir providenciar uma chamada ao script de teste,
passando-lhe como parmetro o vetor de objetos correspondente aos dados de teste. Para que
os scripts possam facilmente manipular os dados contidos no vetor, foi desenvolvido um
mtodo na classe Util que recebe o nome do vetor e o nome do campo desejado, e retorna o
valor deste campo.
Caso ocorra um erro durante a execuo da sute, a classe Controlador ir chamar a
classe ControladorErro para o devido tratamento.

3.7 Aplicao dos Padres Factory Method e DAO

Esta seo evidencia a aplicao dos padres Factory Method e Data Access Object
(DAO). O Factory Method utilizado em duas situaes. Na primeira, criado um mtodo
fbrica para a instanciao de objetos DAO. Na segunda utilizao, temos uma Factory para
instanciao de scripts de teste. O padro DAO utilizado para abstrair o acesso aos dados de
teste persistidos.
O diagrama de classes da Figura 38 destaca os participantes do framework que
implementam o padro DAO.

Figura 38 Uso do Padro DAO para selecionar os dados de teste

Na Tabela 4, apresentada a correspondncia entre os participantes do padro DAO e
os participantes do framework que implementam este padro.

71

Participantes do Padro DAO

BusinessObject
DataAccessObject
DataSource
TransferObject

Participantes Correspondentes no FuncTest

Controlador
ConcreteDAO
DataSource
Object[]

Tabela 4 Participantes do FuncTest que implementam o Padro DAO

O diagramas de classes da figuras 39 e 40 destacam os participantes do framework que
implementam o padro Factory Method para instanciar, respectivamente, os scripts de teste e
os objetos DAO para acesso aos dados de teste persistidos.

Figura 39 Uso do Padro Factory Method para a criao de scripts de teste

Figura 40 Uso do Padro Factory Method para a criao dos objetos DAO
Na Tabela 5, apresentada a correspondncia entre os participantes do padro Factory
Method e os participantes do framework que implementam este padro.
Participantes do Padro
Factory Method
Product
ConcreteProduct
Creator
ConcreteCreator

Participantes Correspondentes no FuncTest

Factory Script
RationalTestScript
ConcreteScript
AbstractFabricaScript
FabricaScript

Factory DAO
IDAO
ConcreteDAO
AbstractFabricaDAO
FabricaDAO

Tabela 5 Classes do FuncTest que implementam o Padro Factory Method

72

3.8 Exemplo de Uso do Framework FuncTest

Esta seo apresenta de forma sucinta um exemplo parcial de uso do FuncTest. Os
artefatos aqui apresentados foram extrados da segunda instanciao do framework. A sute
foi criada para testar um workflow para a gerao de documentos.
Numa viso bastante simplificada, estes documentos so inicialmente criados em
forma de minutas, e, aps aprovao, estas minutas so convertidas em arquivos do
OppenOffice.
Os casos de teste utilizados para exemplificar a utilizao do FuncTest tm o propsito
de criar minutas sob diferentes circunstncias (ver seo 4.3.2). No propsito deste
trabalho apresentar detalhes sobre os casos de teste da aplicao. Portanto, dar-se- uma viso
tcnica somente relacionada a artefatos referentes ao uso do framework.
Os 5 casos de teste que compem o presente exemplo executam aes sobre um
formulrio de criao de minutas parcialmente ilustrado na Figura 41. So eles: CriarMinutaC001_1,

CriarMinuta-C001_2,

CriarMinuta-C002_1,

CriarMinuta-C003_1

CriarMinuta-C004_1.

Figura 41 Formulrio de Criao de Minutas

73

Os casos de teste CriarMinuta-C001_1 e CriarMinuta-C001_2 pertencem ao

cenrio C001 do caso de uso Criar Minuta. Os casos de teste CriarMinuta-C002_1,
CriarMinuta-C003_1 e CriarMinuta-C004_1 pertencem, respectivamente, aos cenrios
C002, C003 e C004 que tambm compem o caso de uso Criar Minuta.
Para a incluso destes casos de teste sute, alm da criao de cada script
compartilhado entre eles, os arquivos de configurao precisaro ser devidamente
preenchidos.
A viso parcial do arquivo Suite.xml mostrada na Listagem 10 ilustra o trecho
necessrio incluso dos 5 casos de teste restritos ao exemplo aqui apresentado.
...
<CasoTeste>
<Nome>CriarMinuta-C001_1</Nome>
<Arquivo>CriarMinuta-C001_1.xml</Arquivo>
</CasoTeste>
<CasoTeste>
<Nome>CriarMinuta-C001_2</Nome>
<Arquivo>CriarMinuta-C001_2.xml</Arquivo>
</CasoTeste>
<CasoTeste>
<Nome>CriarMinuta-C002_1</Nome>
<Arquivo>CriarMinuta-C002.xml</Arquivo>
</CasoTeste>
<CasoTeste>
<Nome>CriarMinuta-C003_1</Nome>
<Arquivo>CriarMinuta-C003_1.xml</Arquivo>
</CasoTeste>
<CasoTeste>
<Nome>CriarMinuta-C004_1</Nome>
<Arquivo>CriarMinuta-C004_1.xml</Arquivo>
</CasoTeste>
...

Listagem 10 Trecho do arquivo Suite.xml

A classe Principal do framework ir recuperar estes casos de teste e solicitar a
execuo de cada um deles classe Controlador.

74

Da mesma forma, foi criado um arquivo XML para cada um destes casos de teste
contendo os seus steps. Para fins de exemplo, apresentado apenas um trecho de um destes
arquivos, correspondente ao primeiro caso de teste do cenrio C001 (Listagem 11). O
trecho sofreu pequenas adaptaes para facilitar o entendimento do propsito dos steps
destacados. So eles: IniciarSistema, Logar e PreencherMinutaC001.
...
<step>
<Nome>IniciarSistema</Nome>
</step>
<step>
<Nome>Logar</Nome>
<Dados>DadosLogin</Dados>
</step>
<step>
<Nome>PreencherMinutaC001</Nome>
<Dados>PreencherMinuta</Dados>
</step>
...

Listagem 11 Trecho adaptado do arquivo CriarMinuta-C001_1.xml

A classe Controlador ir, para cada step que possua dado de teste associado, solicitar
fbrica DAO a criao do objeto DAO correspondente e solicitar ao objeto DAO os dados de
teste. Para isto, os arquivos Banco.xml e Datasource.xml precisam estar devidamente
preenchidos.
A Listagem 12 destaca o trecho do arquivo Banco.xml referente associao entre o
SGBD utilizado para armazenar os dados de teste do step e a classe DAO correspondente.
Neste caso, o SGBD utilizado foi o SQL Server.
...
<SQLSERVER>br.gov.serpro.projetoB.testes.modelo.dao.DAOSQLServer</SQLSERVER>

...

Listagem 12 Trecho adaptado do arquivo Banco.xml

Dentre os trs steps apresentados na Listagem 11, dois deles incluem dados na
interface da aplicao sob teste. So eles: Logar e PreencherMinuta. Para exemplificar a
configurao do arquivo Datasource.xml para o step PreencherMinuta, um trecho deste
arquivo apresentado na Listagem 13.

75

...
<PreencherMinuta>
<Conexao>jdbc:jtds:sqlserver://00.000.000.000:0000;DatabaseName=ProjetoBDadosTeste</Conexao>
<Driver>net.sourceforge.jtds.jdbc.Driver</Driver>
<Tabela>CT_PreencherMinuta</Tabela>
<Login>usuario</Login>
<Senha>senha</Senha>
<Banco>SQLSERVER</Banco>
</PreencherMinuta>
...

Listagem 13 Trecho adaptado do arquivo Datasource.xml

A tabela CT_PreencherMinuta foi criada para registrar os dados de teste dos cinco
casos de teste referidos. Uma de suas colunas identifica para qual step o registro foi criado.
Aps receber os dados de teste (se houver), o Controlador solicita fbrica de scripts
o script correspondente ao step corrente. Para isto, o arquivo Scripts.xml dever ser
devidamente configurado. Para exemplificar, apresentado na Listagem 14 o trecho do
arquivo Scripts.xml correspondente associao entre o step PreencherMinuta e o
respectivo script criado.
...
<PreencherMinuta>br.gov.serpro.projetoB.testes.modelo.script.criarMinuta.Pr
eencherMinuta</CriarMinuta>
...

Listagem 14 Trecho adaptado do arquivo Scripts.xml

Por fim, apresentado um trecho do arquivo Erros.xml para exemplificar a associao
entre uma exceo (RationalTestScriptException) e a classe criada para tratar esta exceo
(Listagem 15).
...
<RationalTestScriptException>
<Classe>br.gov.serpro.projetoB.testes.modelo.script.apoio.trataErros.TrataRat
ionalTestScritptException</Classe>
</RationalTestScriptException>
...

Listagem 15 Trecho adaptado do arquivo Erros.xml

76

3.9 Concluso
Este captulo apresentou primeiramente uma viso geral sobre de padres de software,
detalhando alguns formatos e tipos de padro encontrados na literatura, bem como
apresentando os padres que foram utilizados na composio do framework FuncTest. Em
seguida, o framework foi apresentado, descrevendo os relacionamentos entre os elementos
que compem sua arquitetura e detalhando o seu funcionamento. Um exemplo extrado de um
caso prtico foi exibido para ilustrar a utilizao do framework. Por fim, foram destacados os
elementos de sua arquitetura que implementam o padres de software descritos.

Captulo 4
4. Relato de Experincia e Avaliao Preliminar

Este captulo aborda um relato de experincia e uma avaliao preliminar da

utilizao do framework em projetos realizados no SERPRO (Servio Federal
de Processamento de Dados).

4.1 Introduo
Este captulo relata a experincia de uso do framework FuncTest em dois plos de
desenvolvimento do SERPRO (www.serpro.gov.br), a maior empresa pblica de prestao de
servios em tecnologia da informao do Brasil. Os dois plos (A e B) onde o framework foi
utilizado pertencem regional de Fortaleza.
Embora as duas equipes que utilizam o framework tenham adotado o uso de
automao como forma de garantir maior produtividade na execuo de testes funcionais, o
processo de desenvolvimento da empresa no exige o uso desta abordagem.
Primeiramente, ser brevemente abordada a disciplina (macroatividade) de testes
pertencente ao processo de desenvolvimento da empresa. Em seguida, so relatadas as
experincias das duas equipes, destacando-se uma anlise de dados coletados na experincia
da segunda equipe. Por fim, so listados alguns benefcios observados durante as experincias
vivenciadas na empresa.

4.2 Processo de Teste do SERPRO

A Macroatividade de Testes (Figura 42) descrita no Processo Serpro de
Desenvolvimento de Solues (PSDS) tem como propsito fornecer aos projetos de software
desenvolvidos na empresa um conjunto de atividades para planejamento e execuo de testes
dos produtos ou componentes de software desenvolvidos. Esta macroatividade corresponde a
uma customizao da disciplina de testes do RUP e apia as atividades de planejamento,
projeto, implementao, execuo e avaliao dos resultados dos testes.

78

Figura 42 Macroatividade de Teste - PSDS

A atividade Planejar Testes responsvel por definir o escopo dos testes, recursos a
serem utilizados, estimativas, estratgias e tcnicas de testes que serviro de controle e
acompanhamento para as demais atividades. O principal artefato de sada produzido nesta fase
o Plano de Teste.
Na atividade Projetar Testes, os casos de teste planejados so elaborados, ou seja,
criados e documentados. Esta elaborao normalmente feita com base nos casos de uso do
sistema sob teste. Cada caso de uso formado por fluxos de evento (principal e alternativos),
os quais determinam diferentes caminhos para a realizao do caso de uso. Estes caminhos
so denominados cenrios. Para cada cenrio produzido um ou mais casos de teste. Cada
caso de teste pode ser executado para conjuntos diferentes de dados de teste. Em paralelo,
iniciada a preparao do ambiente de testes.
importante lembrar que este trabalho est focado em testes em nvel de sistema, que
seguem uma abordagem caixa-preta. O primeiro plo (A) que utilizou o FuncTest inclusive
no tem acesso algum ao cdigo fonte de grande parte das aplicaes para as quais realizam
testes, o que possibilita unicamente a execuo de testes sob uma perspectiva de usurio final.
A abordagem do processo utilizado para projetar os casos de teste prope a derivao
de casos de teste a partir dos casos de uso. Portanto, cada cenrio corresponde a um ou mais
casos de teste derivados. A Figura 43 ilustra esta abordagem.

79

Figura 43 Derivao de Casos de Teste a partir de Casos de Uso

A atividade Implementar Testes tem como propsito a implementao de scripts de

testes (automticos ou manuais), programas, stubs (implementaes parciais de componentes)
e massas de dados. Para a criao de scripts manuais, utilizada a ferramenta IBM Rational
Manual Tester. Os scripts manuais representam passos a serem seguidos por um testador
durante a execuo do teste. Para a criao de scripts automatizados, utiliza-se o framework
FuncTest atravs da ferramenta IBM Rational XDE Tester.
Na atividade Executar Testes, os testes so executados e os resultados so registrados
em ferramenta de registro de ocorrncias. No caso de execuo manual, os registros
normalmente so feitos durante os testes. No caso de execuo automatizada, os registros so
feitos aps anlise do log de execuo gerado pela ferramenta.
A atividade Avaliar Resultados centraliza os resultados dos testes para a gerao de
um relatrio consolidado. A partir deste relatrio, o lder de projeto toma conhecimento do
nvel de qualidade do produto, obtendo informaes suficientes para as tomadas de deciso
necessrias.
Como fora destacado na Figura 42, o framework FuncTest utilizado durante as
atividades Implementar Testes, Executar Testes e Avaliar Resultados, pois as etapas
anteriores no subentendem a existncia de testes funcionais automatizados.

80

4.3 Experincia no Uso do Framework FuncTest

Esta seo relata a experincia de uso do FuncTest em dois plos (A e B) de
desenvolvimento da empresa.
O plo A, onde o framework foi primeiramente instanciado, mantm uma equipe de
testes independente, a qual atende a diversos projetos da empresa. O processo de
desenvolvimento utilizado no plo uma adaptao do RUP (2001) aderente ao nvel 3 do
CMMI (CMMI, 2002). O FuncTest foi utilizado para automatizar parte dos casos de teste de
um projeto de construo de um sistema de grande porte desenvolvido neste plo.
O plo B no mantm uma equipe independente de testes e o seu processo aderente
ao nvel 2 do CMMI. Durante o uso do FuncTest neste plo, houve dedicao exclusiva de
dois projetistas de teste na automao de testes funcionais do projeto.

4.3.1 Experincia do Plo A

H mais de trs anos, a primeira equipe independente de testes do SERPRO
(pertencente ao plo A) adotou a execuo automtica de testes funcionais como forma de
agilizar a execuo de testes de regresso. Durante este perodo, houve um aperfeioamento
contnuo na criao e na execuo de testes funcionais automatizados.
A princpio, os scripts de teste eram criados unicamente gravando-se aes de usurio
para posterior execuo (tcnica Record and Playback). Isto era mais comum quando se
utilizava a ferramenta IBM Rational Robot, na qual os scripts eram criados em linguagem
SQABasic. Este esforo era pouco produtivo e todo o cdigo gerado pela automao era de
difcil reuso. Em muitos casos, tornava-se mais produtivo gravar um novo script do que
manter um script existente.
Aps adquirir a ferramenta IBM Rational XDE Tester, na qual os scripts so criados
em linguagem Java, foi possvel desenvolver o framework proposto nesta dissertao, capaz
de racionalizar a criao e a organizao dos scripts de teste. Atravs do uso de padres de
software, a arquitetura do framework tornou-se flexvel e bastante adequada para uso na
empresa.
A equipe formada por 8 profissionais, 3 dos quais dedicaram-se prioritariamente
programao dos scripts durante o uso e evoluo do framework. Durante este perodo, a

81

principal preocupao era de encontrar oportunidades de melhoria da proposta; portanto, no

houve rigor em manter uma padronizao do uso do framework.
O FuncTest foi aplicado por esta equipe para automatizar testes de um sistema de
grande porte, formado por 176 casos de teste. Dentre eles, 74 foram automatizados,
totalizando 2.415 scripts.
A deciso de se automatizar somente parte da sute de testes deveu-se limitao de
tempo e priorizao de casos de teste mais crticos ou que precisassem ser re-testados com
maior freqncia.
A execuo da sute automatizada demora cerca de 6 horas para ser finalizada e
depende de uma nica mquina em processamento, enquanto que a execuo dos testes
manuais equivalentes demoraria mais de um ms e ocuparia a fora de trabalho de muitos
testadores.

4.3.2 Experincia do Plo B

A equipe de desenvolvimento do projeto desenvolvido no plo B formada por 1 lder
de projeto, 1 analista de negcios, 2 analistas de requisitos, 1 gestor de configurao, 7
desenvolvedores e 2 projetistas de teste. Neste plo, no se mantm uma equipe independente
de testes, apesar dos dois projetistas de teste da equipe terem se envolvido durante
aproximadamente 11 semanas quase que exclusivamente na produo da sute automatizada.
O sistema desenvolvido no plo B possui 57 casos de uso e tamanho funcional de 309
pontos por funo. Foi desenvolvido em linguagem Java/JSP para acesso via WEB. Utiliza
SGBD SQL Server e faz o uso de Applets e Javascript. O exemplo mostrado na seo 3.8
refere-se a este sistema.
Dentre os 57 casos de uso que compem o sistema, 9 foram automatizados. A sute
automatizada composta por 69 casos de teste, totalizando 151 scripts de teste. A execuo
completa desta sute dura em torno de 40 minutos, e o tempo de anlise do log de execuo
para registro de ocorrncias varia entre 5 e 40 minutos. Esta variao depender da quantidade
de ocorrncias encontradas. Normalmente, a execuo da sute realizada em um computador
exclusivamente dedicado para os testes automatizados.

82

Foi realizada uma anlise do reuso de scripts nesta sute. Concluiu-se que cada script
foi utilizado em mdia 5,4 vezes (Figura 44). Subtraindo-se deste valor o primeiro uso dos
scripts, conclui-se que cada script foi reutilizado em mdia 4,4 vezes. importante considerar
que esta anlise no leva em considerao o tamanho e a complexidade dos scripts.

Figura 44 Reutilizao de Scripts

A possibilidade de reuso dos scripts est diretamente condicionada ao propsito dos
mesmos. Por exemplo, os scripts mais reutilizados lidavam diretamente com aes bastante
genricas, como fazer login, chegando a ser reutilizados em at 32 casos de teste.
Os scripts com menor freqncia de uso foram utilizados apenas 1 vez. Certamente,
eles lidam com aes bastante especficas, que dizem respeito no a um caso de uso, mas a
um nico caso de teste, ou seja, a um cenrio de um caso de uso.
O grfico da Figura 45 relaciona a quantidade de casos de teste pelo seu tamanho (em
nmero de scripts). Observa-se que, em mdia, cada caso de teste da sute possui
aproximadamente 11 scripts. O maior caso de teste da sute possui 32 scripts, e o menor
possui apenas 1. A quantidade mais comum de scripts por caso de teste 6. Neste caso, 20
casos de teste se enquadram neste tamanho (em scripts).

83

Figura 45 Quantidade de Casos de Teste por Tamanho

4.4 Concluso
Este captulo relatou a experincia do Servio Federal de Processamento de Dados
(SERPRO) no uso do framework FuncTest para a realizao de testes funcionais de regresso.
Tambm foram apresentados alguns dados que indicam uma viso parcial do reuso de scripts
obtido com o framework em um dos projetos.

Captulo 5
5. Concluso

Este captulo apresenta a concluso do trabalho, destacando

contribuies, resultados obtidos e sugestes para trabalhos futuros.

Scripts gerados a partir de ferramentas Record and Playback normalmente so

pouco reutilizveis e pouco manutenveis, e, medida que aumenta a quantidade de
casos de teste automatizados de uma sute, torna-se cada vez mais difcil manter os
scripts criados. De forma a minorar este problema, frameworks utilizando as tcnicas
Data-driven e Keyword-driven tm sido propostos para automatizao de testes
funcionais.
Neste trabalho, foi apresentado um framework para a automao de testes
sistmicos funcionais, denominado FuncTest, que, alm das tcnicas tradicionais,
utiliza a arquitetura MVC e os padres Factory Method e DAO para aprimorar a
manutenibilidade de sutes de teste automatizadas. O uso de padres em frameworks
para automao de testes funcionais conduzidos atravs de ferramentas Record and
Playback representou um enfoque inovador da utilizao de padres.
O framework foi aplicado em dois projetos reais desenvolvidos no SERPRO,
mostrando-se bastante adequado para uso na empresa. A segunda experincia de uso
do FuncTest possibilitou coletar dados referentes ao reuso de scripts obtido com a
utilizao do framework. A anlise mostrou que cada script foi utilizado em mdia
aproximadamente 4 vezes na sute; no entanto, no foram considerados o tamanho e a
complexidade dos scripts.

5.1 Resultados Alcanados e Trabalhos Futuros

Um dos principais benefcios observados com o uso de testes automatizados foi
a ampliao da cobertura dos testes durante a execuo dos testes de regresso, que

85

antes de se desenvolver o framework possuam escopo bastante restrito e tempo de

execuo significativamente superior.
Os estudos e aplicaes das tcnicas e padres utilizados neste trabalho
sugerem muitos benefcios. Partindo-se deste pressuposto, as seguintes caractersticas
do framework desenvolvido podem ser destacadas:

desacoplamento, atravs da arquitetura MVC, entre passos de um caso de

caso de teste e scripts correspondentes;

independncia entre scripts e dados de teste, segundo a tcnica Datadriven;

modularizao dos scripts, atravs da tcnica Keyword-driven, com o

controle independente de suas chamadas e conseqente reduo do
acoplamento entre eles;

facilidade de incluso de novos casos de teste nas sutes de teste;

transparncia no acesso aos dados e independncia em relao ao SGBD

utilizado, obtidas atravs do padro DAO;

melhoria no controle de erros, evitando interrupes durante a execuo das

sutes;

configurao do framework atravs de um conjunto de arquivos XML,

tornando necessria a manipulao de cdigo Java apenas na elaborao
dos scripts;

melhoria da reusabilidade e da manutenibilidade de scripts;

melhor legibilidade de cdigo.

Uma dificuldade relatada pela primeira equipe que utilizou o framework diz
respeito dificuldade de manuteno dos arquivos XML, por no ter sido criada uma
ferramenta que facilite a configurao dos mesmos.
Como trabalhos futuros, pretende-se adaptar o framework para a utilizao da
tcnica Model-based Testing (DALAL, 1999; EL-FAR, 2001), possibilitando a
gerao automtica de casos de teste. Alm disso, pretende-se realizar medies que

86

indiquem o ganho de produtividade e o retorno de investimento obtidos com a

utilizao do framework.

6. Referncias Bibliogrficas

(ALEXANDER, 1977) ALEXANDER, Christopher, ISHIKAWA, S., SILVERSTEIN, M.,

JACOBSON, M., FIKSDAHL-KING, I., Angel, S. A Pattern Language: Towns, Buildings,
Construction. Oxford University Press, New York.
(ALEXANDER, 1979) ALEXANDER, Christopher. The Timeless Way of Building. Oxford
University Press, New York, 1979.
(ALMEIDA, 2007) ALMEIDA, Rodrigo Rebouas de. Model-View-Controller (MVC).
Disponvel em: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm.
Acessado em agosto de 2007.
(ALUR, 2003) ALUR, Deepak, MALKS, Dan, CRUPI, John. Core J2EE Patterns: Best
Practices and Design Strategies, 2 Ed. California: Sun Microsystems, 2003.
(ANDRADE, 2001) ANDRADE, Rossana. Capture, Reuse, and Validation of Requirements
and Analysis Patterns for Mobile Systems. Ph.D. Thesis, School of Information
Technology and Engineering (SITE), University of Ottawa, Ottawa, Ontario, Canada, May
2001.
(APPLETON, 2000) APPLETON, Brad. Patterns and Software: Essential Concepts and
Terminology.

Disponvel

em

http://www.cmcrossroads.com/bradapp/docs/patterns-

intro.html. Acessado em julho de 2007.

(AUTOMATEDQA, 1999) AUTOMATEDQA, Corp. TestComplete 5 - Stop Bugs Ruining
Your Day. Disponvel em http://www.automatedqa.com/products/testcomplete/index.asp.
Acessado em julho de 2007.
(BARBOSA, 2004) BARBOSA, D. L., ANDRADE, W. L., MACHADO, P. D. L.,
FIGUEREDO, J. C. A. SPACES Uma Ferramenta para Teste Funcional de
Componentes. Anais da XI Sesso de Ferramentas XVIII Simpsio Brasileiro de
Engenharia de Software.

88

(BECK, 1987) BECK, Kent, CUNNINGHAM, Ward. Using Pattern Languages for ObjectOriented

Programs.

Technical

Report

CR-87-43,

1987.

Disponvel

em

http://c2.com/doc/oopsla87.html.
(BINDER, 1999) BINDER, R. V. Testing Object-Oriented Systems: Models, Patterns and
Tools, Addison-Wesley.
(BINDER, 1999) BINDER, R. V. Testing Object-Oriented Systems: Models, Patterns, and
Tools. 1 Ed. Massachusetts: Addison Wesley.
(BLACK, 2007) BLACK, Rex. Pragmatic Software Testing: Becoming an Effective and
Efficient Test Professional. John Wiley & Sons.
(BORLAND, 1994) Borland Software Corporation. Borland SilkTest: An Automated
Regression

and

Functional

Software

Testing

Tool.

Disponvel

em

http://www.borland.com/us/products/silk/silktest/index.html. Acessado em julho de 2007.

(BRINGEL FILHO, 2004) BRINGEL FILHO, Jos de Ribamar Martins. FRAMESEC: Um
Framework para a Proviso de Segurana Fim-A-Fim para Aplicaes no Ambiente de
Computao Mvel. Dissertao de Mestrado, Universidade Federal do Cear.
(BURNSTEIN, 2003) BURNSTEIN, Ilene. Practical Software Testing: A Process-oriented
Approach. Springer-Verlag. Nova York.
(BUSCHMANN, 1996) BUSCHMANN, Frank, MEUNIER, Regine, ROHNERT, Hans,
SOMMERLAD, Peter, STAL, Michael. Pattern-Oriented Software Architecture: A System
of Patterns. New York: John Wiley & Sons.
(CMMI, 2002) Capability Maturity Model Integration (CMMISM), Version 1.1: CMMISM
for Systems Engineering, Software Engineering, Integrated Product and Process
Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS, V1.1).
(COPELAND, 2004) COPELAND, Lee. A Practitioner's Guide to Software Test Design.
Artech House.
(COPLIEN, 2000) COPLIEN, J. O. C++ Idioms Patterns. In Brian Foote, Neil Harrison, and
Hans Rohnert, editors, Pattern Languages of Program Design. Addison Wesley, Reading,
MA.

89

(COPLIEN, 2004) COPLIEN, J. and Harrison, N. Organizational Patterns of Agile Software

Development. Prentice Hall.
(COPLIEN, 2006) COPLIEN, J. O. Software Patterns. SIGS books and Multimedia.
(COPLIEN,

2007)

COPLIEN,

James

O.

Pattern

Definition.

Disponvel

em

http://hillside.net/patterns/definition.html. Acessado em julho de 2007.

(CRAIG, 2002) CRAIG, Rick D., JASKIEL, Stefan P. Systematic Software Testing. Artech
House Publishers, 2002.
(CRISTALLI, 2006) CRISTALLI, Ricardo. Fbrica de Teste: Uso das Melhores Prticas.
Insituto de Teste de Software. Disponvel em: http://www.iteste.com.br/. ltimo acesso em
agosto de 2007.
(DALAL, 1999) DALAL, S. R., JAIN, A., KARUNANITHI, N., BELLCORE, N., LEATON,
J. M., LOTT, C. M., PATTON, G. C., HOROWITZ, B. M. Model-Based Testing in
Practice. International Conference on Software Engineering, 1999.
(DELAMARO et al., 2007) DELAMARO, Mrcio Eduardo, MALDONADO, Jos Carlos,
JINO, Mario. Introduo ao Teste de Software. Rio de Janeiro: Elsevier.
(DUSTIN, 1999) DUSTIN, Elfriede, RASHKA, Jeff, PAUL, John. Automated Software
Testing: Introduction, Management, and Performance. Addison-Wesley Professional;
Bk&CD Rom edition, 1999.
(DUSTIN, 2003) DUSTIN, Elfriede. Effective Software Testing: 50 Specific Ways to
Improve Your Testing. Addison-Wesley Professional; 1st edition, 2002.
(EL-FAR, 2001) EL-FAR, I. K. and WHITTAKER, J. A. Model-Based Software Testing.
Encyclopedia of Software Engineering (edited by J. J. Marciniak). Wiley.
(FANTINATO et al., 2004) FANTINATO, Marcelo, et al. AutoTest Um Framework
Reutilizvel para a Automao de Teste Funcional de Software. Simpsio Brasileiro de
Qualidade de Software, 2004.
(FAYAD, 1999) FAYAD, Mohamed; Schmidt, Douglas C. Implementing Application
Frameworks: Object-Oriented Frameworks at Work.
(FEWSTER et al., 1999) FEWSTER, Mark, GRAHAM, Dorothy. Software Test Automation.
Addison-Wesley Professional; 1st edition, 1999.

90

(FOWLER, 1997) FOWLER, M. Analysis Patterns: Reusable Object Models, AddisonWesley.

(FREEMAN, 2004) FREEMAN, Eric, FREEMAN, Elisabeth, SIERRA, Kathy e BATES,
Bert. Head First: Design Patterns. O'Reilly.
(FUREY, 2004) FUREY, Brendan e WALSH, Liam. Testing IBM Workplace with IBM
Rational

XDE

Tester.

Disponvel

em:

http://www.ibm.com/developerworks/lotus/library/xde-tester/. IBM Corporation.

(GABRIEL, 2002) GABRIEL, Richard P. Writers' Workshops & the Work of Making
Things: Patterns, Poetry Pearson Education; 1st edition.
(GAMMA, 1995) GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. Design Patterns:
Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
(GOIS, 2007) GIS, Francisco Nauber Bernardo, OLIVEIRA, Rafael Braga de, FARIAS,
Pedro Porfrio Muniz. Desenvolvimento de Software Utilizando Integrao Contnua.
ERCEMAPI 2007 - Escola Regional de Computao - Cear Maranho Piau.
(GOMES, 2002) GOMES, Andr Luiz Pereira. FLEXFRAME: Framework para
Desenvolvimento de Sistemas de Informao Flexveis, que Parametrizem Regras De
Negcios. Dissertao de Mestrado, Universidade de Fortaleza.
(GRADY, 1987) GRADY, R.B., CASWELL, D.L.. Software Metrics: Establishing a
Company-Wide Program. Prentice-Hall.
(IBM, 2004) IBM Corporation. Rational XDE Tester Release Notes. Disponvel em:
ftp://ftp.software.ibm.com/software/rational/xde/eng/XDETester_readme.html.
(IEEE, 1998) IEEE Standards for Software Test Documentation, IEEE-Std-829, Software
Engineering Technical Committee of the IEEE Computer Society, 1998.
(KELLY, 2005) KELLY, Michael. Framework automation with IBM Rational Functional
Tester:

Data-driven.

Disponvel

em:

http://www-

128.ibm.com/developerworks/rational/library/05/1108_kelly/.
(KELLY, 2006) KELLY, Michael. Introduction to IBM Rational Functional Tester 7.0.
Disponvel em: http://www.ibm.com/developerworks/rational/library/06/1205_kelly/.

91

(KOENIG, 1995) KOENIG, Andrew. Patterns and Antipatterns. Journal of Object-Oriented

Programming, 1995.
(KONRAD, 2002) KONRAD, Sascha and CHENG, Betty H.C. Requirements Patterns for
Embedded Systems. Proceedings of the IEEE Joint International Conference on
Requirements Engineering.
(LAJOIE, 2003) LAJOIE, R., KELLER, R. K. Design and Reuse in Object-Oriented
Frameworks: Patterns, Contracts and Motifs in Concert; In: Proceedings of the 62nd
Congress of the Association Canadienne Francaise pour l'Avancement des Sciences,
Montreal, Canada, 1994 Disponvel em: ftp://st.cs.uiuc.edu/pub/patterns/papers/acfas.ps.
Acesso em: 23 de abril de 2008.
(LAPLANTE, 2005) LAPLANTE, Phillip A., NEILL, Colin J. Antipatterns: Identification,
Refactoring, and Management. Auerbach Publications, 2005.
(MESZAROS, 1997) MESZAROS, G., DOBLE, J., A Pattern Language for Pattern
Writing, Pattern Language of Program Design 3, edited by Robert C. Martin, Dirk Riehle,
and Frank Buschmann, Addison-Wesley (Software Patterns Series), 1997.
(MESZAROS, 2007) MESZAROS, Gerard. XUnit Test Patterns: Refactoring Test Code.
Addison-Wesley.
(MYERS, 2004) MYERS, Glenford J. The Art of Software Testing. New York: John Wiley &
Sons, Second Edition, 2004.
(NAGLE,

2000)

NAGLE,

C.,

Test

Automation

Frameworks,

disponvel

em

http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm.
(OLIVEIRA, 2007a) OLIVEIRA, Rafael Braga de, GIS, Francisco Nauber Bernardo,
FARIAS, Pedro Porfrio Muniz, SOUZA, Jerffeson Teixeira de. Utilizao de Padres para
Otimizar a Automao de Testes Funcionais de Software. Sexta Conferncia Latinoamericana em Linguagem de Padres para Programao - SugarLoafPloP 2007.
(OLIVEIRA, 2007b) OLIVEIRA, Rafael Braga de, GIS, Francisco Nauber Bernardo,
FARIAS, Pedro Porfrio Muniz. Automao de Testes Funcionais: Uma Experincia do
SERPRO. 1st Brazilian Workshop on Systematic and Automated Software Testing (SAST
2007).

92

(OPENQA, 2007) OpenQA. Selenium IDE. Disponvel em: http://www.openqa.org/seleniumide/. Acessado em setembro de 2007.
(PARADKAR, 1994) PARADKAR, Amit. On the Experience of Using Cause-Effect Graphs
for Software Specification and Test Generation. Conference of the Centre for Advanced
Studies on Collaborative research - CASCON '94.
(PARASOFT, 1996) PARASOFT CORPORATION. Parasoft Jtest. 1997. Disponvel em:
http://www.parasoft.com/jtest. Acessado em julho de 2007.
(PREE, 1994). PREE, W. Meta patterns - a means for capturing the essentials of reusable
object-oriented design. in M. Tokoro and R. Pareschi (eds), Springer-Verlag, Proceedings
of the ECOOP, Bologna, Italy.
(PREE, 1995) PREE, W. Design Patterns for Object-Oriented Software Development.
Addison-Wesley Longman.
(PRESSMAN, 2002) PRESSMAN, Roger S. Engenharia de Software. McGraw Hill, 5 dio,
2002.
(RAINSBERGER, 2005) RAINSBERGER, J.B. and STIRLING, Scott. JUnit Recipes:
Practical Methods for Programmer Testing. Manning Publications Co.
(RISING, 2000) Linda Rising. The Pattern Almanac 2000. Addison-Wesley.
(ROBERTS, 1998) ROBERTS, Don, JOHNSON, Ralph E. Evolving Frameworks: A Pattern
Language for Developing Object-Oriented Frameworks, In "Martin, R. C.; Riehle, D. and
Buschmann, F. Pattern Languages of Program Design 3", Addison-Wesley, 1998,
Disponvel em: http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/evolve.html.
(ROBERTSON, 1996) ROBERTSON, Suzanne. Requirements Patterns via Events / Use
Cases.

The

Atlantic

Systems

Guild.

Disponvel

em:

http://www.systemsguild.com/GuildSite/SQR/Requirements_Patterns.html. Acessado em
julho de 2007.
(RUP, 2001) Rational Software Corporation. Rational Unified Process, RUP. Disponvel em
http://www.wthreex.com/rup/. Acessado em agosto de 2007.
(RYBALOV, 2004) RYBALOV, Misha. Design Patterns for Customer Testing. Automated
Testing Guy. Disponvel em http://www.autotestguy.com/.

93

(SANTOS, 2004) SANTOS, Misael S. Uma Proposta para a Integrao de Modelos de

Padres de Software com Ferramentas de Apoio ao Desenvolvimento de Sistemas.
Dissertao de Mestrado, Universidade Federal do Cear.
(SOUZA, 2005) SOUZA, Gabriela, Pires, Carlo Giovano, Marinho, Fabiana e Belchior,
Arnaldo Dias. Padres de Requisitos para Especificao de Casos de Uso em Sistemas de
Informao. 5th Latin American Conference on Pattern Languages of Programming SugarLoafPloP.
(SOUZA, 2007) SOUZA, Jerffeson Teixeira de, Andrade, Tarciane de Castro. Introduo aos
Padres de Software. ERCEMAPI 2007 - Escola Regional de Computao - Cear
Maranho Piau.
(SUN, 2002) Sun Microsystems. Java BluePrints: Model-View-Controller. Disponvel em
http://java.sun.com/blueprints/patterns/MVC-detailed.html. Acessado em agosto de 2007.
(SUN, 2007) Sun Microsystems. Core J2EE Patterns - Data Access Object. Disponvel em:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html. Acessado
em maio de 2007.
(THOMAS, 2004) THOMAS, Jon , YOUNG, Matthew, BROWN, Kyle, GLOVER, Andrew.
Java Testing Patterns. Wiley.
(TIAN, 2005) TIAN, Jeff. Software Quality Engineering: Testing, Quality Assurance, and
Quantifiable Improvement. John Wiley & Sons.
(VILJAMAA, 2001) VILJAMAA, A. Pattern-Based Framework Annotation and Adaptation
A systematic Approach. Thesis (Licenciate Thesis in Computer Science) University of
Helsinki, Finland.
(WITHALL, 2007) WITHALL, Stephen J. Software Requirement Patterns: Best Practices.
Microsoft Press, U.S. Wesley Publishing Company, ACM Press.

Livros Grtis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administrao
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Cincia da Computao
Baixar livros de Cincia da Informao
Baixar livros de Cincia Poltica
Baixar livros de Cincias da Sade
Baixar livros de Comunicao
Baixar livros do Conselho Nacional de Educao - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Domstica
Baixar livros de Educao
Baixar livros de Educao - Trnsito
Baixar livros de Educao Fsica
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmcia
Baixar livros de Filosofia
Baixar livros de Fsica
Baixar livros de Geocincias
Baixar livros de Geografia
Baixar livros de Histria
Baixar livros de Lnguas

Baixar livros de Literatura

Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemtica
Baixar livros de Medicina
Baixar livros de Medicina Veterinria
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Msica
Baixar livros de Psicologia
Baixar livros de Qumica
Baixar livros de Sade Coletiva
Baixar livros de Servio Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo