Análise e Aprimoramento de Uma Ferramentade Criação e Execução de Testesautomatizados para Telefones Celulares

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLGICO - CTC

DEPARTAMENTO DE INFORMTICA E ESTATSTICA
CURSO DE CINCIAS DA COMPUTAO

Thiago Schoppen Veronese

Anlise e aprimoramento de uma ferramenta
de criao e execuo de testes
automatizados para telefones celulares

Florianpolis/SC
2009



Trabalho de Concluso de Curso
apresentado como parte dos requisitos
para a obteno do grau de Bacharel em
Cincias da Computao

Florianpolis/SC
2009



Trabalho de Concluso de Curso apresentado como parte dos requisitos para a
obteno do grau de Bacharel em Cincias da Computao

Fabiano Castro Pereira, M.Sc
Orientador
Universidade Federal de Santa Catarina

Ricardo Pereira e Silva, D.Sc
Co-Orientador

J os Otvio Carlomagno Filho, M.Sc
Banca Examinadora

Agradecimentos

Ao meu orientador Fabiano Castro Pereira por ter aceitado o encargo de me
auxiliar nesta tarefa e pela orientao. Agradeo tambm ao co-orientador Ricardo
Pereira e Silva e ao membro da banca J os Otvio Carlomagno Filho por suas
imprescindveis contribuies para a realizao deste trabalho.

Aos meus colegas do LabSoft por todo o aprendizado durante o tempo que
trabalhamos juntos, especialmente ao Ademir Coelho, Fabiano Pereira e J os
Carlomagno Filho por suas colaboraes para este trabalho.

Agradeo aos meus amigos por estarem sempre ao meu lado me apoiando e
ajudando na medida do possvel.

Aos meus pais pelo apoio e incentivo incondicionais durante todos os estgios
da minha vida e por mais esse passo dado, sem vocs nada disso seria possvel.

Resumo

Na situao atual do mercado de software, a garantia de qualidade,
juntamente com a crescente competio, diminuio de prazos e oramentos e um
processo de desenvolvimento acelerado, tornam o lanamento do produto o mais
cedo possvel crucial para a sobrevivncia da empresa. Desta forma, levantada a
questo da automatizao de testes de produtos, com o intuito de diminuir o ciclo de
desenvolvimento de softwares. Porm, a atividade de criao de casos de teste
automatizados no trivial e toma boa parte do tempo no processo de teste. Tendo
isto em vista, foi estabelecida uma comparao entre modalidades de teste, onde a
abordagem automatizada mostrou-se eficiente em longo prazo. Foi ento estudada e
aprimorada uma ferramenta de automao de testes exploratrios de telefones
celulares para que tivesse a portabilidade de seus casos de teste aumentada por
meio da automao. Outro aprimoramento foi tornar a criao de tais testes mais
simples, eliminando a necessidade de diversos conhecimentos tcnicos, atravs do
uso de uma interface grfica intuitiva, diminuindo assim os custos de teste e,
conseqentemente, do ciclo de desenvolvimento de software.

Palavras-chave: Teste de software, Automatizao, Ferramenta de criao
visual de testes complexos.

Abstract

In the current software market situation the quality assurance, together with
the rising competition, shortening of deadlines and budgets and an accelerated
development process, make the shipping of the product as soon as possible crucial
to the survival of the company. This way the possibility of automating product testing
is raised, in order to lower the software development cycle. However the automated
test case design process is not trivial and takes a good amount of the time spent on
the automation test process. Taking this into consideration, a comparison between
test methods was established, where the automated approach presented itself
efficient in the long term. So an exploratory test case automation tool for cell phone
testing was studied and improved to have the portability of its test cases raised by
test automation. Another improvement was making test cases creation more simple,
avoiding the need of much technical knowledge, through the use of an intuitive
graphical interface, lowering the software testing costs and, consequently, software
development cycle costs.

Keywords: Software testing, Automation, Complex test cases visual creation
tool.

Lista de Figuras

1 Diagrama de classes simplificado do TAF (KAWAKAMI et al., 2007) ................ 12
2 Arquitetura de camadas do TAF (PETROSKI, 2006) ......................................... 13
3 Captura de tela de um caso de teste no TAFStudio ........................................... 14
4 Captura de tela da interface de definio de checkpoints .................................. 14
5 Diagrama de classes simplificado da arquitetura do TAFStudio ........................ 16
6 Grfico do Nmero de execues x Esforo ...................................................... 22
7 Grfico do Nmero de telefones x Esforo ......................................................... 23
8 Grfico do Nmero de casos de teste x Esforo ................................................ 24
9 Diagrama de casos de uso do acoplamento TAFStudio+TAF ............................ 31
10 Diagrama de classes proposto para o acoplamento TAFStudio+TAF ................ 32
11 Tela de composio dos casos de teste do TAF ................................................ 33
12 Diagrama de atividades do algoritmo de execuo de testes ............................ 34
13 Diagrama de seqncia do algoritmo de execuo de testes ............................ 35

Lista de Tabelas

1 Descrio do caso de teste 1 ............................................................................. 18
4 Resultados do ensaio dos casos de teste .......................................................... 20
5 Especificao da sute de testes para a avaliao ............................................. 21
6 Frmulas para clculo do esforo em cada modalidade .................................... 21
7 Modalidades versus situaes de melhor aplicao .......................................... 25

Sumrio
1 Introduo ............................................................................................................... 1
1.1 Objetivos ........................................................................................................... 2
1.1.1 Objetivo geral ......................................................................................... 2
1.1.2 Objetivos especficos ............................................................................. 2
1.2 Metodologia ...................................................................................................... 3
1.3 J ustificativa ....................................................................................................... 3
2 Teste de Software ................................................................................................... 4
2.1 Mtodos de teste .............................................................................................. 4
2.1.1 Testes caixa-preta .................................................................................. 5
2.1.2 Testes caixa-branca ............................................................................... 5
2.2 Nveis de teste .................................................................................................. 5
2.2.1 Teste unitrio ......................................................................................... 6
2.2.2 Teste de integrao ................................................................................ 6
2.2.3 Teste de sistema .................................................................................... 6
2.3 Casos e sutes de teste .................................................................................... 7
2.4 Teste exploratrio ............................................................................................. 7
2.5 Testes record/playback ..................................................................................... 8
2.6 Teste automatizado .......................................................................................... 8
3 TAF e TAFStudio .................................................................................................. 10
3.1 Test Automation Framework ........................................................................... 10
3.1.1 Arquitetura ............................................................................................ 11
3.2 TAFStudio ....................................................................................................... 13
3.2.1 Arquitetura ............................................................................................ 15
4 Comparao de Esforos das Diferentes Modalidades de Teste.......................... 17
4.1 Uma sute de testes fictcia e a mtrica de comparao ................................ 17
4.2 Comparando as trs modalidades .................................................................. 21
4.2.1 Avaliao dos resultados ..................................................................... 24

5 Aprimoramentos do TAFStudio ............................................................................. 27
5.1 Caracterizao do problema e soluo .......................................................... 27
5.2 Tecnologias utilizadas..................................................................................... 28
5.3 Arquitetura e implementao da soluo ........................................................ 29
5.3.1 Adaptao do framework ferramenta ................................................ 29
5.3.2 Projeto das funcionalidades TAF dentro do TAFStudio ....................... 30
5.3.3 Implementao das novas funcionalidades .......................................... 32
5.4 Resultados do aprimoramento ........................................................................ 36
6 Concluso e Trabalhos Futuros ............................................................................ 37
6.1 Consideraes finais ...................................................................................... 37
6.2 Limitaes ....................................................................................................... 38
6.3 Sugestes para trabalhos futuros ................................................................... 39
Referncias ............................................................................................................... 40
Apndice A Cdigo-fonte........................................................................................ 42
Apndice B Artigo ................................................................................................... 71

1

1 Introduo

Com base na situao atual do mercado de software, onde evidente uma
crescente necessidade de garantia de qualidade, o teste de software ganha maior
importncia tendo em vista a diminuio de bugs e falhas nos produtos. Um estudo
realizado no ano de 2002 e conduzido pelo NIST
1
concluiu que bugs ou erros de
software so to predominantes e prejudiciais que custam economia dos Estados
Unidos um valor estimado de US$59,5 bilhes anualmente, ou aproximadamente
0,6% do Produto Interno Bruto (NEWMAN, 2002).

Outros pontos a serem considerados so a crescente competio
internacional, a diminuio de prazos e de oramentos e um processo de
desenvolvimento acelerado (RAMLER, 2006), que acabam por tornar o lanamento
do produto o mais cedo possvel, crucial para a sobrevivncia da empresa.

Tendo em vista o prejuzo causado por bugs de software e a necessidade de
atingir o mercado rapidamente que se levanta a questo da automatizao de
testes de produtos, tentando diminuir o ciclo de desenvolvimento de softwares. A
criao de testes automatizados, no entanto, no trivial e toma uma boa parte de
tempo no processo de teste.

Uma parte importante do teste de softwares e que bastante utilizada
atualmente, a abordagem de testes exploratrios, onde o testador quem decide
quais caminhos devero ser tomados durante a execuo do teste, sendo assim,
cada caso de teste deve ser executado manualmente tantas quantas vezes for

1
Em ingls, National Institute of Standards and Technology (NIST)
2

necessrio, o que numa linha de produo extensa torna-se muito custoso em
termos financeiros e de tempo.

Tendo em vista que a automatizao de testes um caminho para a reduo
de custos na fase de testes da produo de um software, e tendo por base o
contexto de testes exploratrios, que se deseja com este trabalho estudar uma
ferramenta que automatiza a execuo de tais testes, analisando suas vantagens e
desvantagens em relao ao mtodo tradicional. A partir disso, propor uma soluo
para sua principal desvantagem, que a baixa portabilidade dos casos de teste
criados pela mesma.
1.1 Objetivos
1.1.1. Objetivo geral
Analisar e estudar os benefcios trazidos pelo uso de uma ferramenta de
automao de testes exploratrios buscando tambm encontrar deficincias desta
abordagem.
1.1.2. Objetivos especficos
a) Diminuir o ciclo de desenvolvimento de automao de testes atravs da
diminuio do tempo de criao de casos de teste automatizados.
b) Solucionar o problema da baixa portabilidade de casos de teste criados pela
ferramenta, implementando uma forma de criao de casos de teste com alto
nvel de abstrao;
c) Propor uma soluo para o problema das pr e ps condies encontradas na
execuo seqencial de diferentes casos de teste quando do uso da
ferramenta de automao de testes.
3

1.2 Metodologia
Para alcanar os objetivos estabelecidos ser adotada a seguinte
metodologia:
a) Analisar uma ferramenta de automao de casos de teste exploratrios
com a finalidade de avaliar seus pontos fortes e fracos em relao ao
mtodo tradicional de execuo de tais testes;
b) Propor uma soluo com alta usabilidade para o problema de portabilidade
e do estabelecimento de pr e ps condies existentes na execuo
seqencial de testes exploratrios;
1.3 Justificativa
Atualmente a presso sobre gerentes de projeto e desenvolvedores de
software vem aumentando cada vez mais no sentido de prazos de entrega e
utilizao de recursos. De acordo com Dustin, Rashka e Paul (1999), mais de 90%
dos desenvolvedores j perderam a data de entrega e, perder prazos uma prtica
comum para 67% dos desenvolvedores. Ainda, 91% deles foram forados a remover
funcionalidades durante o ciclo de desenvolvimento para poder cumprir prazos.

Tendo de enfrentar essas dificuldades impostas pelo mercado que as
empresas tm decidido partir para a utilizao de testes automatizados para que
possa ser diminudo o tempo total de desenvolvimento de software. A automatizao
dos testes diminui muito o custo e o tempo gastos com atividades que tentam
garantir qualidade e confiabilidade ao produto, dessa forma, um meio de criar
facilmente casos de teste altamente portveis teria um grande impacto positivo ao
diminuir significativamente o tempo gasto para a criao de tais testes, o que geraria
um ganho de produtividade considervel no desenvolvimento de software,
terminando por auxiliar no cumprimento das metas estabelecidas nas empresas.

4

2 Teste de Software

Teste de software uma investigao tcnica emprica conduzida para prover
os clientes com informaes sobre a qualidade do produto ou servio em teste
(KANER, 2006). Desta forma, o teste de software o processo de rod-lo mltiplas
vezes para verificar se os requisitos e as condies iniciais so satisfeitas, bem
como detectar erros, incluindo assim a funcionalidade de executar o mesmo com o
intuito de encontrar bugs de software.

O estabelecimento de um padro de preciso e correo das respostas
geradas pelo software deve seguir critrios objetivos de avaliao. Para tal, deve-se
ento, estabelecer uma comparao entre o estado e o comportamento de um
software e a sua especificao de requisitos, que podem ser definidos pelo usurio
(teste de validao) ou pelas especificaes do sistema (teste de verificao).

O teste para verificar se o software est realmente de acordo com suas
especificaes, s pode ser considerado bem sucedido caso no sejam encontradas
falhas durante sua execuo. Isso acaba indo de encontro com uma famosa citao
do cientista de computao Edsger Dijkstra: teste de software pode ser apenas
usado para mostrar a presena de bugs, mas nunca sua ausncia, fazendo uma
aluso ao fato de que testar completamente invivel em sistemas reais
(PETROSKI, 2006).
2.1 Mtodos de teste
Os mtodos de teste de software so tradicionalmente divididos em testes
caixa-preta e testes caixa-branca. Estas divises so usadas para descrever os
5

diferentes pontos de vista tomados pelo engenheiro de teste quando do
desenvolvimento de casos de teste.
2.1.1. Testes caixa-preta
Nesta metodologia, o testador encara o componente a ser testado como uma
caixa-preta, onde so desconhecidos detalhes de implementao e da estrutura
interna, sendo apenas passada uma entrada correta ou errada e definido o resultado
esperado para cada entrada (BCS SIGIST, 2001). Apesar de este mtodo poder
descobrir partes ainda no implementadas da especificao, no garantido que
todos os caminhos possveis sero testados.
2.1.2. Testes caixa-branca
Ao contrrio dos testes caixa-preta, nos testes caixa-branca h o
conhecimento da implementao e estrutura interna do componente testado,
requerendo ento o domnio de programao para a identificao de todos os
caminhos atravs do software. Desta forma os testes so escritos tendo como base
esse conhecimento, o que leva concluso de que se a implementao alterada,
tais testes provavelmente tambm tero de ser (PAREKH, 2005).

Tal como os testes de caixa-preta, este mtodo pode descobrir partes no
implementadas da especificao, tendo ainda a vantagem de garantir que quase a
totalidade dos caminhos possveis dentro da execuo do software sero
alcanados e testados.
2.2 Nveis de teste
Na aplicao de testes em um software deve-se ter a noo de que os
mesmos devem ser aplicados seguindo o contexto do software testado e os
objetivos inerentes a tais testes.

6

Para tal, foram definidos nveis de teste para sua melhor categorizao,
sendo que segundo Bourque et al. (2001), existem trs grandes estgios que podem
ser divididos: unitrio, integrao e sistema.
2.2.1. Teste unitrio
um teste que valida se unidades individuais de cdigo-fonte esto
funcionando corretamente. Uma unidade a menor parte testvel em uma
aplicao, a qual deve ser definida levando-se em conta a abordagem adotada para
um sistema computacional, podendo avaliar desde mtodos individualmente at
classes ou componentes de software inteiros.

Testes unitrios geralmente so escritos e executados por desenvolvedores
de software, seguindo geralmente o mtodo da caixa-branca. Garantindo assim que
o cdigo encontra os requisitos especificados para o software e tem seu
comportamento conforme o esperado pelo desenvolvedor.
2.2.2. Teste de integrao
Testes de integrao so realizados quando mdulos individuais de software,
que j podem ter sido testados (testes unitrios), so combinados e testados em
conjunto. Nessa fase verifica-se a existncia de erros gerados pela integrao dos
mdulos atravs de testes de uso compartilhado de dados e de comunicao inter-
processos, de tal forma que os propsitos dessa fase de teste so a verificao dos
requisitos funcionais, de desempenho e de confiana.
2.2.3. Teste de sistema
O teste de sistema tem como objetivo a busca de falhas do sistema como um
todo, quando da juno dos grupos de mdulos j testados. O teste de sistema
realizado seguindo o escopo de teste de caixa-preta, no deve ento requerer
conhecimento sobre o design ou a lgica do cdigo-fonte.

7

Esta uma fase investigatria do processo de teste, onde o foco ter quase
que uma atitude destrutiva, testando no somente o design, mas tambm o
comportamento e at as possveis expectativas do usurio final. Considera-se que
devem ser testados todos os requisitos especificados e at alm dos mesmos.
2.3 Casos e sutes de teste
Um caso de teste um conjunto de condies ou variveis sob as quais um
testador determina se um requisito ou caso de uso de uma aplicao parcialmente
ou totalmente satisfeito, sendo essencialmente constitudo por uma srie de passos
e seus resultados esperados (PETROSKI, 2006).

Uma sute de testes nada mais que um agrupamento de casos de teste que
possuem caractersticas ou objetivos em comum, podendo conter tambm
instrues detalhadas ou metas para cada coleo de testes e informao sobre o
sistema a ser usado durante o teste.
2.4 Teste exploratrio
uma tcnica de teste onde se realiza uma busca ttica por faltas e defeitos
no software testado dirigida por suposies desafiadoras. Essa abordagem de testes
normalmente envolve execuo, aprendizado e projeto de novos testes como
atividades que interagem entre si, tudo ocorrendo simultaneamente (TINKHAM;
KANER, 2003).

O teste realizado usando este conceito depende da habilidade do testador em
inventar novos casos de teste e achar defeitos, quanto maior o conhecimento do
testador sobre o software testado e sobre tcnicas de teste melhor ser o resultado
do teste. No existe uma seqncia de passos pr-definida a ser seguida, mas o
testador que decide o que vai ser verificado, investigando a correo do resultado
criticamente, ou seja, tambm no h um resultado esperado j definido. A principal
8

vantagem desse tipo de teste que uma menor preparao necessria e defeitos
importantes so encontrados rapidamente.
2.5 Testes record/playback
Esta modalidade de teste de software pode ser inserida em um contexto que
se encaixa entre o teste totalmente exploratrio e o teste automatizado. Isso
acontece devido ao fato de ser apenas uma gravao (record) de passos de teste e
conseqente execuo (playback) de tais passos gravados.

Tendo isto em mente, percebe-se que o objetivo desta modalidade , de certa
forma, automatizar as atividades do testador quando da realizao de um teste
exploratrio, reproduzindo a exata seqncia de entradas e sadas obtidas na
execuo original. Sendo assim, o ganho desta abordagem est em no ser preciso
que um operador humano realize novamente procedimentos j antes feitos,
reduzindo gastos atravs da reproduo automtica do teste.

Porm, a grande desvantagem desta tcnica encontra-se na baixa
reutilizao que ela prov, j que a execuo de um teste nesse formato ir
simplesmente repetir passos gravados, o que restringe significativamente a sua
abrangncia em relao ao produto sendo testado.
2.6 Teste automatizado
Recentemente, com o avano das tcnicas de programao, principalmente
pelo uso de ferramentas de desenvolvimento, houve um grande aumento da
produtividade dos desenvolvedores. Esse aumento leva a uma cada vez maior
quantidade de cdigo a ser testado em um tempo cada vez menor, acabando por
gerar atrasos na entrega de softwares devido ao grande tempo despendido em
testes dos mesmos.

9

Devido a tal fato, a automao de testes vem sendo utilizada como uma forma
para evitar esse problema, com a substituio parcial dos testes manuais,
diminuindo os custos de produo do software, atravs da agilidade que os testes
automatizados proporcionam.

Porm existem alguns problemas nesta abordagem, j que o custo inicial
alto, tornando o custo-benefcio favorvel somente em longo prazo. Podem-se
perder tambm as vantagens dos testes manuais se estes forem totalmente
erradicados, o que no indicado, pois ambos so complementares, j que seguem
diferentes abordagens e buscam diferentes objetivos, como por exemplo, explorar
uma nova funcionalidade versus testes de regresso de uma funcionalidade
existente (RAMLER, 2006).

10

3 TAF e TAFStudio

Nesta seo ser feito um detalhamento sobre a situao atual da ferramenta
e do framework nos quais se baseia este trabalho. Cada software apresenta uma
abordagem diferente para a automao de casos de teste, sendo ento o objetivo
deste trabalho analisar as vantagens e desvantagens de cada uma e propor
solues para os problemas encontrados, visando um possvel ganho de
desempenho e reduo de custos no teste de software.
3.1 Test Automation Framework
O Test Automation Framework (TAF) um framework projetado para suportar
a automao de testes funcionais dos softwares embutidos em telefones celulares
produzidos e desenvolvidos pela Motorola Industrial Ltda (KAWAKAMI et al., 2007).

O TAF foi concebido e desenvolvido tendo em mente a idia da reutilizao
de casos de teste em vrios modelos diferentes de telefone, sem a necessidade de
realizar adaptaes especficas para cada um, pois foi observado que muitas das
funcionalidades dos telefones so implementadas em diversos modelos, podendo
assim reutilizar o cdigo atravs do uso do framework. Essa reutilizao acaba por
agilizar muito o processo de desenvolvimento do software embutido nos telefones
celulares, pois necessrio escrever somente uma vez o teste para ento poder
execut-lo tantas vezes quanto necessrio, evitando que se tenha que executar
manualmente cada teste.

Para a realizao da comunicao com o telefone, o TAF utiliza outro
framework, o Phone Test Framework (PTF). O PTF prov uma API (Application
11

Programming Interface) que permite ao usurio simular eventos de entrada/sada do
telefone, como pressionamento de teclas e captura de tela (ESIPCHUK; VALIDOV,
2006). Mas um fator que torna invivel a utilizao do PTF para a automatizao de
casos de teste que ele somente prov funes de baixo nvel de abstrao,
tornando difcil o porte dos testes para modelos diferentes de telefones.
3.1.1. Arquitetura
Para poder obter uma viso de mais alto nvel o TAF usa as chamadas Utility
Functions (UFs), que encapsulam aes de teste de mais baixo nvel e resultados
esperados de um teste, sendo assim, UFs so entidades primitivas que isolam
hierarquicamente a funcionalidade da implementao, levando a casos de teste
automatizados de alto nvel (RECHIA et al., 2007). Uma UF , ento, a
implementao de um passo de alto nvel em um caso de teste, sendo que todas
implementam a interface Step no TAF. Segundo Rechia (2005), um caso de teste do
TAF uma lista de Steps, onde tudo que um caso de teste faz invocar o mtodo
execute definido na interface Step e implementado nas UFs concretas.

Para se portar um caso de teste j existente para outro modelo de telefone
ocorre a reutilizao de cdigo, caso a implementao de uma UF no funcione
neste modelo necessria a criao de uma implementao especfica. Supondo
que o comportamento de um modelo fictcio de celular XYZ da UF
ComposeMessage (compe uma mensagem de texto ou multimdia) difere de outros
modelos, a Figura 1 mostra a implementao dessa UF num diagrama de classes
simplificado do TAF.

Apesar de modelos de telefones diferentes apresentarem comportamentos
diferentes, um mesmo caso de teste automatizado pode ser aplicado a diversos
telefones de uma mesma famlia, j que eles implementam as mesmas
funcionalidades.

12

Figura 1: Diagrama de classes simplificado do TAF (KAWAKAMI et al., 2007)

Um caso de teste a composio de vrias chamadas a mtodos dos feature
toolkits, cuja responsabilidade criar uma instncia de uma UF especfica, passando
a ela os argumentos necessrios, anteriormente definidos na API da UF e finalmente
adicionar lista de passos, quando ento o caso de teste poder ser executado
(KAWAKAMI, 2007).

A Figura 2 mostra a hierarquia entre as diferentes camadas que compem o
TAF, partindo do mais alto nvel, onde esto os casos de teste, at o nvel mais
baixo, onde feita a comunicao com o telefone atravs do PTF.

13

Figura 2: Arquitetura de camadas do TAF (PETROSKI, 2006)
3.2 TAFStudio
O TAFStudio um software projetado para gerar e executar testes
exploratrios automatizados destinados a testar os softwares embutidos em
telefones celulares produzidos e desenvolvidos pela Motorola. Esses testes podem
ser chamados tambm de testes record/playback, que simplesmente gravam passos
de um caso de teste para futura reproduo dos mesmos.

O trabalho realizado pelo TAFStudio criar um caso de teste a partir do
armazenamento de todos os eventos produzidos pelas aes do testador no telefone
celular, sendo os principais eventos o pressionamento de teclas e a captura de telas
do telefone. Tambm so registradas notas de texto feitas pelo testador, tais como
notas de comentrio, bugs, problemas no telefone, etc. Um exemplo de caso de
teste produzido pelo TAFStudio pode ser visto na captura de tela da Figura 3, onde
na esquerda se encontra a lista de passos do caso de teste e na direita um exemplo
de uma captura de uma tela do telefone, composta por itens de cones e textos.

14

Figura 3: Captura de tela de um caso de teste no TAFStudio

Com estes registros armazenados e tendo em mente pontos chave de um
teste exploratrio, o usurio pode estabelecer pontos de checagem (em ingls,
checkpoints). A Figura 4 mostra uma captura de tela da interface grfica de definio
desses pontos de checagem, a qual feita atravs da seleo de itens que devem
ser checados, tais como, cones, textos e quaisquer outros elementos que podem
ser encontrados nas telas de telefones celulares. Sendo assim o conjunto de
pressionamento de teclas no telefone, juntamente com os pontos de checagem
estabelecidos pelo usurio formam um caso de teste exploratrio. Ento, durante a
execuo do mesmo, tais pontos de checagem sero verificados para validar os
pontos chave do teste exploratrio.

Figura 4: Captura de tela da interface de definio de checkpoints
15

Tal como no TAF, a interao realizada com o telefone atravs do PTF,
sendo que agora sua funo reportar os eventos que acontecem no telefone ao
TAFStudio (isso porque as aes neste caso so realizadas pelo testador), e
pressionar as teclas registradas quando da execuo dos passos do caso de teste
gerado pelo software.
3.2.1. Arquitetura
Considerando que, a funo do TAFStudio armazenar uma sesso de teste
exploratrio para futura reproduo, dois eventos podem ser considerados
fundamentais, so eles os pressionamentos de tecla e as telas capturadas do
telefone. Para uma melhor compreenso e organizao, tais eventos foram definidos
como passos de um caso de teste.

As informaes que so guardadas no armazenamento de um passo de
pressionamento de tecla so: identificao da tecla pressionada, tempo de
pressionamento e tempo decorrido desde o pressionamento anterior. Essas
informaes descrevem por completo a seqncia exata de pressionamento de
teclas no telefone durante a sesso de teste exploratrio.

Para o armazenamento de uma captura de tela necessrio guardar um
volume maior de informaes, sendo elas: posicionamento e tamanho de todos os
itens grficos presentes na tela (cones, textos, imagens, etc.) e lista de quais itens
compem o ponto de checagem.

Sendo assim, os casos de teste do TAFStudio so definidos por passos tal
como no TAF, porm tais passos possuem uma viso de baixo nvel, por serem
simples representaes de eventos ocorridos no telefone. Essa viso leva a uma
baixa reutilizao, devido principalmente s diferenas existentes entre cada
plataforma de telefones celulares, onde um passo de teste gravado num telefone
dificilmente pode ser portado para outro, a menos que seja da mesma plataforma e a
verso do software embutido no mesmo seja equivalente, em termos de
posicionamento de itens na tela e mapeamento de teclas.
16

Tendo em vista a separao do caso de teste em passos, pode ser vista na
Figura 5 uma viso simplificada da arquitetura do TAFStudio para o armazenamento
e execuo dos casos de teste criados pela ferramenta. As classes KeyPressStep e
ScreenStep, que representam um pressionamento de tecla e uma captura de tela
respectivamente, implementam as funes da interface Step, assim como no TAF.

Figura 5: Diagrama de classes simplificado da arquitetura do TAFStudio
17

4 Comparao de Esforos das
Diferentes Modalidades de Teste

No captulo anterior foram descritas duas ferramentas de teste de software
que apresentam duas abordagens diferentes em relao modalidade de teste
automatizada empregada pelas mesmas. Cada modalidade apresenta vantagens e
desvantagens em relao outra, e neste contexto que estabelecida uma
comparao entre ambas as modalidades automatizadas (record/playback e
automatizada) e a abordagem totalmente manual (teste exploratrio), a fim de
encontrar a quais situaes cada uma se mostra mais eficiente.

Para tanto, neste captulo exposta uma forma de comparao, levando-se
em conta uma sute de casos de teste fictcia, para se avaliar mais concretamente o
esforo necessrio para a implantao da sute em cada modalidade.
4.1 Uma sute de testes fictcia e a mtrica de comparao
Para o estabelecimento de uma sute de testes fictcia foram criados trs
casos de teste bastante simples que refletem casos de teste reais, testando
diferentes funcionalidades do telefone celular. Como nenhuma sute contaria apenas
com trs casos de teste, os mesmos so usados como base para se obter uma
mdia de esforo para a aplicao em cada modalidade de teste, estendendo esta
mdia para se obter situaes aproximadas em sutes com maior nmero de casos
de teste.

Para a descrio completa dos casos de teste necessrio que se tenha as
seguintes informaes: o nome do caso de teste; as pr-condies em que o
18

telefone deve se encontrar antes do incio da execuo; a lista de passos do caso de
teste; e as ps-condies que o telefone deve atender aps a execuo do caso de
teste. As tabelas 1, 2, e 3 descrevem cada um dos casos de teste que compem a
sute de testes fictcia.

Tabela 1: Descrio do caso de teste 1
Caso de Teste 1 Tirar uma fotografia
Pr-condies
1 Estar na tela de IDLE
Passos do caso de teste
1 Ir para a aplicao de cmera
2 Tirar uma fotografia
3 Salvar usando a opo "STORE_ONLY" (somente guardar na memria)
4 Ir para o "Media finder" e verificar se a foto foi salva com sucesso
Ps-condies
1 Remover a foto da memria do telefone

Caso de Teste 2 Realizar uma chamada telefnica
Pr-condies
1 Digitar o nmero a ser chamado
2 Pressionar a tecla SEND para iniciar a chamada
3 Terminar a chamada
Ps-condies
1 Ir para a tela de IDLE

19

Caso de Teste 3 Compor uma mensagem SMS e salv-la nos DRAFTS
Pr-condies
1 Ir para a tela de composio de mensagem e escrever "Hello world"
2 Acessar o menu "Send to" e inserir o nmero desejado
3 Salvar a mensagem nos DRAFTS
Ps-condies
1 Ir para a tela de IDLE

Para fins de avaliao da viabilidade econmica de cada modalidade de
testes, a mtrica considerada foi a quantidade de esforo humano que deve
despendida para a execuo completa da sute de testes. Essa mtrica dada em
nmero de horas de trabalho executado por um testador, sendo vlida para este
contexto por no apresentar problemas inerentes a nenhuma das metodologias de
teste.

Tendo os casos de teste descritos necessrio agora definir quais fatores
influenciam no esforo humano necessrio para criar e executar tais testes em cada
uma das modalidades. Tal descrio como segue:
Exploratrio: no h esforo para criar o caso de teste, simplesmente h o
esforo realmente manual do engenheiro de testes em executar cada um
dos casos de teste diretamente no telefone, tomando nota dos resultados
obtidos em cada sesso;
Record/playback: neste caso s existe esforo humano para a criao dos
casos de teste na ferramenta TAFStudio, sendo que para executar tais
testes o esforo pode ser considerado desprezvel, pois a mesma ocorre de
forma automatizada, necessitando pouca ateno do testador;
Automatizado: aqui existe o esforo humano para a criao do caso de
teste utilizando linguagem de programao, porm o maior esforo
concentra-se no porte das UFs utilizadas, que nada mais que a
20

adequao das UFs incompatveis a uma nova famlia de telefones.
Resultando que o esforo total a soma dessas duas atividades.

Para se obter o esforo necessrio em cada modalidade foram realizados
ensaios para cada caso de teste. Para a modalidade exploratria os ensaios foram
executados manualmente, e na modalidade record/playback foi utilizado o
TAFStudio. Os valores obtidos dos ensaios para estas duas modalidades podem ser
vistos na Tabela 4. J para o terceiro caso (testes automatizados com TAF), foram
criados os scripts dos casos de teste para obteno do tempo mdio de criao, e,
para a obteno do esforo mdio aproximado para o porte das UFs, foram
utilizados dados histricos de casos reais realizados no Laboratrio de
Desenvolvimento de Software (LabSoft) da Universidade Federal de Santa Catarina.

Tabela 4: Resultados do ensaio dos casos de teste
Modalidade
Caso de teste
Exploratria Record/Playback
Caso de teste 1 60 segundos 7 minutos
Caso de teste 2 50 segundos 4 min. e 30 seg.
Mdia 1 minuto 6 minutos

Os dados histricos obtidos demonstraram que, em mdia, levam-se
aproximadamente trs horas de trabalho para realizar o porte de um caso de teste
cuja execuo tem durao de dez minutos. Como os casos de teste deste contexto
so bem mais simples e levam aproximadamente cinco vezes menos tempo para
sua execuo, o valor da mdia de esforo foi normalizada para o caso dos testes
fictcios, resultando em 36 (trinta e seis) minutos para cada caso de teste.
21

4.2 Comparando as trs modalidades
Com o intuito de ilustrar claramente a diferena de esforo humano exigido
em cada modalidade foram estabelecidos valores para a sute de testes descrita
anteriormente.

Os valores atribuidos podem ser vistos na Tabela 5 e dizem respeito ao
nmero de casos de teste, nmero de execues e nmero de telefones para os
quais ela deve ser aplicada. Ser observado ento o comportamento do esforo
exigido pelas modalidades perante a variao desses valores.

Tabela 5: Especificao da sute de testes para a avaliao
Varivel Quantidade
Casos de teste 5
Execues 10
Telefones 10

Como as variveis que influenciam no problema so em nmero de trs,
sero feitas trs abordagens diferentes para a avaliao do desempenho de cada
modalidade de testes. Em cada abordagem sero mantidas duas variveis com valor
constante enquanto a outra varia. O esforo resultante da combinao dos valores
para cada modalidade de testes pode ser calculado conforme as frmulas
apresentadas na Tabela 6.

Tabela 6: Frmulas para clculo do esforo em cada modalidade
Modalidade Frmula para clculo do esforo
Exploratria E N
t
= H
c
N
c
N
c

Record/playback E = N
t
H
p
N
c

Automatizada E = H
u
N
c
N
c
=Nmero de execues N = mero de casos de teste
c
N N
t
=Nmero de telefones
H
c
= Mdia de esforo para
exploratrio
H
p
record/playback
H
u
automatizado

22

O objetivo desta anlise ento, avaliar por quais valores cada modalidade
mais afetada e qual tem um melhor desempenho. Isso feito pois podem existir
sutes de teste onde uma das variveis tem maior valor que a outra, influenciando
com maior intensidade o esforo necessrio a uma certa modalidade.

No primeiro caso manteve-se fixo o nmero de casos de teste e de telefones,
variando-se o nmero de execues. O resultado pode ser visto no grfico da Figura
6, onde o eixo x mostra o nmero de execues e o eixo y o esforo humano. Ao se
analisar o grfico pode se constatar facilmente que o impacto do nmero de
execues recai fortemente sobre a modalidade exploratria, sendo que a partir de
seis repeties o esforo gerado maior que a de record/playback, ponto onde ela
j no a mais recomendada. O mesmo no acontece para as outras duas
modalidades, onde suas linhas se mantm constantes por todo o eixo x, isso ocorre
porque aqui o esforo necessrio para executar um caso de teste foi considerado
desprezvel, havendo somente ento o esforo inicial para a criao dos casos de
teste.

Figura 6: Grfico do Nmero de execues x Esforo

J o segundo caso pode ser considerado o mais importante dentro do
contexto de teste de softwares embutidos em celulares, pois aqui o esforo medido
23

conforme a variao do nmero de telefones a que a sute deve ser aplicada, e em
um caso real quanto maior o nmero de telefones cobertos pelos casos de teste,
melhor ser o custo/benefcio da sute de testes.

O resultado do segundo caso pode ser visto no grfico da Figura 7, onde se
observa a superioridade da abordagem automatizada para este caso, pois a mesma
no afetada pela quantidade de telefones a que se destina a sute de testes,
devido ao reuso de software aplicado nesta modalidade, mantendo novamente valor
constante por todo o eixo x. Aqui, mais uma vez, a modalidade exploratria
apresentou um grande e constante aumento progressivo do esforo com o aumento
do nmero de telefones, tal qual a modalidade de record/playback, pois o esforo de
ambas afetado fortemente pelo nmero de telefones.

Figura 7: Grfico do Nmero de telefones x Esforo

No ltimo caso considera-se a variao de nmeros de casos de teste, o
grfico resultante pode ser visto na Figura 8. Nesse caso pode ser visto com clareza
o impacto que o nmero de casos de teste tem sobre a abordagem automatizada,
por ter seu esforo baseado fortemente no porting das UFs para cada caso de teste,
tendo sido este seu pior desempenho em relao s outras abordagens em todos os
casos.
24

Figura 8: Grfico do Nmero de casos de teste x Esforo

Finalmente avaliando de uma forma geral todos os casos expostos, chega-se
concluso de que a escolha de uma modalidade de teste de software depende
muito do contexto em que deve ser aplicado, ou seja, a escolha deve se basear nas
vantagens e desvantagens apresentadas por cada modalidade e nas variveis que
mais as afetam, o que dependente da sute de testes em questo.

Esta dependncia das variveis impostas pelas sutes de teste pode tornar a
escolha de uma modalidade invivel, como o caso da modalidade exploratria
quando, por exemplo, h um grande nmero de execues a ser efetuado. O efeito
contrrio acontece para a escolha da modalidade automatizada, onde o esforo
gerado independe do nmero de execues e de telefones que os casos de teste
devem ser portados.
4.2.1. Avaliao dos resultados
Levando-se em conta as caractersticas inerentes a cada modalidade e,
principalmente, a forma em que so afetadas pelas variveis analisadas
anteriormente, apresentada na Tabela 7 a relao das modalidades versus as
situaes em que cada uma melhor se aplica.
25

Tabela 7: Modalidades versus situaes de melhor aplicao
Modalidade Situaes
Exploratria Por ser caracteristicamente uma modalidade de rpida
aplicao e exigir pouqussimo esforo inicial,
recomendada para casos de curto prazo, onde a sute
de testes a ser possui um baixo nmero de casos de
teste, telefones e, principalmente, de execues, pois
cada execuo exige um grande esforo por parte do
engenheiro de testes, tornando-se facilmente custosa
quando do aumento desses valores.
Record/Playback Sendo uma modalidade de abordagem automatizada,
recomendada para casos onde h um grande nmero
de execues dos casos de teste da sute, porm que
possua um baixo nmero de casos de teste e de
telefones a que deve ser aplicada.
Automatizada Recomendada para situaes em que o longo prazo
pode compensar o alto custo inicial, ou seja, onde a
relao entre o nmero de execues, casos de teste e
de telefones que deve-se aplicar acaba superando o
custo inicial da criao dos casos de teste. O custo
inicial envolve o esforo exigido para se escrever o caso
de teste propriamente dito atravs de uma linguagem de
programao e, principalmente, o tempo de porting das
UFs para a famlia de telefones a que a sute ser
aplicada.

Numa viso geral pode-se concluir que a modalidade que sofre menor
impacto da variao dos valores da sute de testes a automatizada, isso acontece
porque ela depende somente do tempo mdio de esforo e do nmero de casos de
teste, tendo um aumento linear de esforo conforme aumenta o nmero de casos de
teste.

26

Porm esse esforo de porte dos casos de teste um esforo inicial para a
automatizao que, apesar de ser custoso, pode ser facilmente compensado no
longo prazo. Isso no acontece para as outras modalidades, pois nessas o aumento
ocorre de forma exponencial justamente por depender de mais de uma varivel,
tendo assim um melhor desempenho em relao ao custo inicial, o que ideal para
casos de curto prazo.

A concluso a que se chega, ento, que a modalidade automatizada tem
grande campo de aplicao em longo prazo, que o caso geral da indstria e, como
o TAFStudio no apresenta esta abordagem, decidiu-se aprimorar a ferramenta
atravs da implantao da mesma, o que aliaria a ferramenta a todos os benefcios
oferecidos por esta modalidade. Esta implantao descrita no captulo seguinte.

27

5 Aprimoramentos do TAFStudio

A modalidade de testes record/playback empregada pelo TAFStudio
apresenta alguns problemas inerentes sua metodologia, os quais acabam
tornando sua aplicao restrita em muitos casos como pde ser visto no captulo
anterior. A seguir sero caracterizados estes problemas e em seguida proposta uma
soluo para os mesmos.
5.1 Caracterizao do problema e soluo
O principal problema da modalidade de testes record/playback em relao
baixssima reutilizao dos casos de teste que so gerados. Isso se deve ao fato
dos passos de teste apresentarem um nvel de abstrao muito baixo, que so
simples representaes dos pressionamentos de tecla e capturas de tela realizados
durante a criao do teste, e que simplesmente so reproduzidos durante a
execuo exatamente da forma que foram capturados.

Essa viso de baixo nvel dos testes acaba por dificultar muito a portabilidade
dos casos de teste, pois um teste criado para um telefone celular dificilmente pode
ser aplicado a outro aparelho ou at mesmo a outra verso de software do mesmo
telefone celular. Isso ocorre pois os cdigos de pressionamentos de tecla e as telas
dos telefones alteram muito de um aparelho para outro.

Assim a soluo bvia para este problema aumentar o nvel de abstrao
de tais passos de teste. Para isso ento foi proposta a utilizao do framework TAF,
por apresentar um alto nvel de abstrao dos testes, provido pela utilizao das
Utility Functions j descritas anteriormente.
28

Porm o TAF apresenta um problema de longa data relacionado dificuldade
da criao dos casos de teste, imposta pelo alto grau de conhecimento exigido para
tal. Para criar um caso de teste no TAF o engenheiro deve ter conhecimento de uma
variada gama de ferramentas e de programao, os quais so listados abaixo:
Linguagem de programao J ava
Arquitetura do TAF (estrutura dos toolkits e UFs)
Ferramenta Eclipse (IDE
1
de programao J ava)
Framework PTF

Este problema da dificuldade de utilizao do TAF pode ser solucionado
parcialmente atravs de uma abordagem de criao visual de casos de teste, tal
qual a empregada na ferramenta TAFStudio. Essa soluo parcial, pois os
conhecimentos exigidos ainda seriam necessrios para a realizao do porte das
UFs, porm ficaria restrito somente ao programador que realiza essa tarefa,
removendo a complexidade no momento da criao do caso de teste.

Finalmente, percebe-se que o TAF supre a necessidade de elevao do nvel
de abstrao dos casos de teste do TAFStudio, atravs da implantao da
modalidade de testes automatizada e o TAFStudio, sendo aprimorado pelo uso do
TAF, pode prover um meio simples de criao dos casos de teste automatizados
com sua abordagem visual. Desta forma, decidiu-se implementar esse
aprimoramento no TAFStudio, o que descrito nas sees a seguir.
5.2 Tecnologias utilizadas
Para a implementao deste trabalho foi utilizada a linguagem de
programao orientada a objetos J ava. Esta escolha se deve ao fato de o framework
TAF e a ferramenta TAFStudio j serem implementados em J ava.

1
Do ingls, Integrated Development Environment: Ambiente Integrado de Desenvolvimento
29

Vale fazer uma referncia em especial API reflection do J ava que foi
utilizada. Essa API implementa o conceito de reflexo computacional na linguagem
de programao J ava. A reflexo computacional definida pelo paradigma da
programao reflexiva e pode ser entendida como uma extenso funcional do
paradigma de programao orientada a objetos, sendo sua nfase a modificao
dinmica do programa, que pode ser determinada e executada durante o tempo de
execuo (SOBEL; FRIEDMAN, 1996).

Tambm foi utilizada a plataforma RCP (Rich Client Platform), que um
conjunto mnimo de plug-ins necessrios para construir uma aplicao com interface
grfica (ECLIPSEPEDIA, 2009), portadora de uma noo de plug-ins que
proporciona baixo acoplamento entre os mesmos.
5.3 Arquitetura e implementao da soluo
5.3.1. Adaptao do framework ferramenta
Para cumprir o propsito de juntar o melhor de cada abordagem de testes em
um s software a soluo tomada foi de que o framework TAF seria adaptado ao
TAFStudio como um plug-in, ou seja, um mdulo extra que pode ser acoplado ou
desacoplado mais facilmente, evitando assim uma grande dependncia entre os dois
softwares. Isso facilitado pelo fato do TAFStudio ser implementado usando a
noo de plug-ins do RCP.

Depois ento de ter adaptado o TAF a um plug-in foi necessrio adequar o
TAFStudio para que o TAF pudesse se comunicar com os telefones celulares. Para
tal o TAF requer alguns valores que so definidos com a utilizao de tags. Essas
tags carregam variados tipos de informao, tais como, locais de arquivos de
configurao dos telefones celulares, dados para os casos de teste, etc.

Normalmente essas tags so descritas nos arquivos de configurao
passados como parmetro quando da invocao do TAF, porm isso no possvel
30

nesta abordagem devido necessidade de uso do mesmo meio de comunicao
com os telefones, ou seja, a mesma instncia do PTF.

Outra possvel forma que o TAF utiliza para reconhecer tais tags atravs da
busca das mesmas pelas variveis de ambiente do sistema operacional. Algumas
dessas tags, quando no encontradas nos arquivos de configurao, so
automaticamente buscadas nas variveis de ambiente do sistema. Foi necessrio
ento somente alterar o TAF para que buscasse tambm as tags restantes e que,
quando da conexo de algum telefone celular, o TAFStudio estabelecesse os
valores corretos das tags para que o TAF automaticamente as encontrasse.
5.3.2. Projeto das funcionalidades TAF dentro do TAFStudio
Para que o TAF fosse utilizado de maneira efetiva dentro do TAFStudio para
criar casos de teste de alto nvel atravs das chamadas de UFs, foram estabelecidos
alguns casos de uso conforme mostra o diagrama de casos de uso da Figura 9.

No diagrama de casos de uso estabelecido foram contempladas as principais
funcionalidades esperadas do acoplamento entre TAF e TAFStudio, descritas mais
detalhadamente abaixo:
Criar um novo caso de teste do TAF: cria um novo caso de teste em branco
pronto para receber UFs e mostra a tela de edio de casos de teste do
TAF;
Editar um caso de teste: edita um caso de teste, sendo composto pelos trs
casos de uso seguintes;
Adicionar UF a um caso de teste: adiciona uma UF selecionada pelo
usurio lista de passos de um caso de teste sendo editado;
Remover UF de um caso de teste: remove um passo de teste de UF
selecionado pelo usurio na lista de passos do caso de teste sendo
editado;
Editar um passo de teste: edita um passo de teste alterando os atributos de
usurio necessrios pela UF em questo;
31

Exec
criado
de te
cutar um c
o pelo usu
ste.
caso de te
urio cham
este do TA
mando as U
AF: execut
UFs conform
ta um cas
me definid
so de test
do na lista
te de TAF
de passos
F
s

pode
poss
qual
usu
mes
sepa
com
car
cham
toda
poss
exec

Com ba
e ser visto

A class
sui uma lis
carrega i
rio sero
ma num e

Como o
arado por d
plexidade,
ter mais t
mada TAF
as as UFs
suem os
cuo de u

Figura 9: Dia
ase nos ca
na Figura
e TAFTes
sta de pass
nformae
passados
nsaio de te
o nmero
diversos to
, utilizada
trivial seria
FUtilityFunc
do TAF. D
parmetro
um caso de
agrama de ca
asos de us
10.
stCase rep
sos de test
es sobre q
s para a U
estes.
de UFs
oolkits, foi
como pro
am mapea
ction, que
Dessa form
s necess
e teste.
asos de uso d
so acima f
presenta u
te represe
ual UF de
UF e o va
contido n
proposta u
ova de con
adas direta
dentro do
ma as UFs
rios para
do acoplamen
foi propost
um novo fo
ntados pel
eve ser exe
lor de reto
no framew
uma abstra
nceito, ond
amente pa
o TAFStud
s foram m
a a invoca
nto TAFStudi
to o diagra
ormato de
la classe T
ecutada, q
orno quan
work TAF
ao com o
de somen
ara seus m
dio repres
apeadas p
ao das
io+TAF
ama de cla asses quee
e caso de
TAFTestCa
quais par
do da exe
teste que
aseStep, a
metros do
ecuo da
e
a
o
a
muito
o intuito de
te alguma
mtodos pe
senta o co
para const
mesmas
grande e
e reduzir a
as UFs de
ela classe
onjunto de
tantes que
durante a
e
a
e
e
e
e
a
322

5.3.3
idia
inter
pois
conh
caso
adic
exec
Figu

3. Implem
Com ba
a de fcil e
rfaces grf
estende a
hecimento

A nova
o de teste
ionando-a
cutar o cas

ura 10: Diagra
mentao
ase nos ca
e simples c
ficas para c
a possibilid
de linguag
interface
e de TAF
lista de
so de teste
ama de class
o das nov
asos de u
criao de
contempla
dade de cri
gem de pro
pode ser v
simplesm
passos do
e o usurio
ses proposto
as funcio
uso descrit
e um caso
ar tais requ
ao de co
ogramao
vista na F
ente selec
o caso de t
simplesm
para o acopl
onalidade
tos anterio
de teste fo
uisitos. Ess
omplexos
o.
igura 11, e
cionando
teste sendo
ente acion
amento TAFS
es
ormente e
oram ento
se requisito
casos de t
e permite
numa lista
o editado c
na um bot
Studio+TAF
tendo em
o impleme
o muito i
teste a usu
m mente a
entadas as
mportante
urios sem
a
s
e
m
ao usurio
a a UF d
correnteme
o na interf
o criar um
esejada e
ente. Para
face.
m
e
a

33

Figura 11: Tela de composio dos casos de teste do TAF

Para a implementao do caso de uso de execuo de casos de teste do TAF
foi criada a classe TAFTestCaseRunner, que utiliza o padro de projetos Singleton,
ou seja, existe apenas uma instncia desta classe durante o tempo de execuo.
Isto feito para permitir que somente um caso de teste seja executado por vez,
evitando problemas de comunicao com os telefones conectados. Esta classe
efetivamente faz todo o trabalho de processar a lista de passos de teste e invocar os
mtodos apropriados das UFs definidas pelo usurio durante a edio do caso de
teste.

Para que pudessem ser chamadas as UFs adequadamente esta classe
possui como atributo uma classe do TAF chamada GenericPhoneBundle, que
representa um telefone celular com todos os toolkits e UFs pertencentes ao mesmo,
conforme a plataforma de tal telefone, definida pelos valores das tags do TAF
anteriormente descritas. Na Figura 12 pode ser visto o diagrama de atividades do
algoritmo de execuo dos casos de teste do TAF, refinado pelo diagrama de
seqncia da Figura 13 e descrito pelo mtodo startTestCase.

344

Figura 12: Diiagrama de atti vidades do algoritmo dee execuo dee testes

resp
ele
exce
inter
class
exec
cham
class
aps
verif
pega
O mto
ponsvel p
verifica se
eo conte
rface grfic
se estend
cuo. As
mado auto
se Job a
s ser esca
fica se o G
ando-se a
odo startT
or controla
e h algu
endo uma
ca fique co
e a class
classes q
maticamen
agendado
lonada, a
GenericPho
instncia c
TestCase d
ar a execu
uma execu
a mensage
ongelada d
e Job do
que a este
nte pelo es
para exec
thread inic
oneBundle
correta pel
da classe
uo de um
uo corre
em inform
durante um
RCP, que
endem dev
scalonador
cuo atra
cia a execu
e j foi inic
o TAF.
e TAFTest
m caso de
entemente
mando o p
ma execu
e define u
vem imple
r de thread
vs do m
uo do m
cializado, s
itera
invo
toolk
par
refle
UF d

Tendo a
ar sobre o
cadas. Pa
kit que pos
metros. T
exo comp
desejada.
agora a co
os passos
ara tanto s
ssui a UF,
Todo esse
utacional p
omunica
do caso
so obtido
o nome d
e processo
para a obte
o com o
de teste
os todos o
do mtodo
o feito
eno do
telefone c
para que
os objetos
da UF, se
porque n
toolkit e m
tCaseRunn
e teste do
e, caso ha
problema.
o de um
uma nova
ementar o
ds do RCP
todo sche
mtodo run
se no o m
ner o v
TAF. Prim
aja lan
Para evit
caso de t
thread pa
mtodo r
P quando o
edule. Sen
, que prim
mesmo in
verdadeiro
meiramente
ada uma
tar que a
teste, esta
ara a sua
run, que
o objeto da
ndo assim,
meiramente
nicializado
o
e
a
a
a
a

a

e
o
celular esta
as UFs
s necessr
eus parm
esse mom
mtodo corr
abelecida
sejam efe
rios como
etros e os
mento u
retos que i
hora de
etivamente
nome do
s tipos dos
utilizada a
invocar a
e
e
o
s
a
a

355

Figura 13: Diiagrama de seeqncia do algoritmo dee execuo dee testes

36

Com o mtodo agora encontrado feita sua invocao utilizando a chamada
invoke, passando como entrada os parmetros e o objeto toolkit que ser o
responsvel pela invocao do mesmo. A execuo da UF realizada normalmente
e ento o valor de retorno armazenado no passo de teste, para futura utilizao
como parmetro de outro passo da lista de passos do caso de teste.
5.4 Resultados do aprimoramento
As melhorias obtidas pelo aprimoramento do TAFStudio so relacionadas aos
problemas aos quais o aprimoramento destinou-se a solucionar. Agora os testes
gerados pela nova modalidade de testes so fceis de serem criados, utilizando a
nova interface, e altamente portveis.

Ao se utilizar a ferramenta aprimorada para a criao e execuo dos testes
do captulo anterior notou-se que no h aparente ganho de esforo. O tempo
exigido para a construo da lista de passos aproximadamente igual ao de criao
do script de teste ao se utilizar diretamente o TAF, e o tempo de porte das UFs ainda
est presente por ser inerente a esta metodologia de testes.

Porm o ganho real do aprimoramento no est no esforo humano
necessrio, mas sim na eliminao da complexidade exigida para a criao e
execuo dos casos de teste, que agora fica restrita ao programador que ir fazer o
porte das UFs. E como os testes agora so altamente portveis, qualquer usurio
pode criar casos de teste complexos simplesmente utilizando a nova modalidade de
testes do TAFStudio podendo port-los para qualquer famlia de telefones celulares,
desde que os mesmos tenham implementaes de UFs compatveis.

Ento, com a eliminao desta complexidade, que se obtm o ganho, pois
muito custoso treinar um engenheiro de testes para que o mesmo seja capaz de
criar casos de teste utilizando somente o TAF. Essa reduo de gastos vem por
diminuir o custo da etapa de teste de software, diminuindo assim o custo total do
ciclo de desenvolvimento.
37

6 Concluso e Trabalhos Futuros

6.1 Consideraes finais
Teste de software uma atividade crucial no atual processo de
desenvolvimento de softwares de alta qualidade. Tambm contribui com uma grande
parcela do custo total do desenvolvimento de software freqentemente cerca de
50% (CHERNONOZHKIN, 2001).

Existem diferentes modalidades de execuo de casos de teste, sendo a
manual a mais difundida pela sua simplicidade, porm ela pode tornar-se suscetvel
a erros e altamente custosa. Neste contexto que entra a ferramenta TAFStudio
para a gerao de casos de teste automatizados atravs da gravao e repetio de
passos, evitando a necessidade de maiores custos com a execuo de tais testes.
Porm essa tcnica possui uma grande limitao no tocante ao reuso dos casos de
teste, onde quase sempre necessria a criao do caso de teste para cada
telefone celular diferente testado, resultando em uma portabilidade muito baixa dos
casos de teste.

Ento foram realizadas medies de esforo para cada modalidade
disponvel, para verificar a viabilidade de cada uma em diferentes sutes de teste de
software, resultando em um bom desempenho da abordagem automatizada provida
pelo framework de testes de software TAF, ao se considerar um grande nmero de
casos de teste e de execues de sutes de teste, que o caso geral da indstria de
software. Este bom desempenho apresentado, quando aplicado ao caso real de
testes de telefones celulares, diminuir o ciclo de desenvolvimento de software,
38

diminuindo o custo com o desenvolvimento do mesmo e, conseqentemente, o
tempo necessrio para lanar o produto no mercado.

Tendo em vista a soluo do problema da portabilidade dos casos de teste
que se recorreu ao framework TAF. Este framework baseia-se fortemente sobre o
princpio da reutilizao de software para a criao dos casos de teste, porm sua
utilizao restrita devido ao alto grau de conhecimento exigido. Sendo assim a
proposta desse trabalho foi aprimorar a ferramenta TAFStudio para que pudessem
ser criados casos de teste altamente portveis utilizando o TAF para tal, e com a
facilidade provida por uma interface simples e intuitiva com o usurio. Isto se
demonstrou muito interessante por permitir um ganho real na reduo da
complexidade, onde agora qualquer usurio pode criar casos de teste complexos,
sendo que o conhecimento de linguagens de programao e de ferramentas
especficas como antes era exigido ficou restrito somente ao programador que ir
realizar o porte das UFs.

Outro problema da abordagem do TAFStudio que tambm foi resolvido com o
acoplamento do TAF a possibilidade do estabelecimento bem definido e de forma
simples de pr e ps condies para os casos de teste, garantindo que o telefone
esteja em determinado estado antes e depois da execuo dos passos de teste.
Esta funcionalidade torna muito eficiente a execuo de sutes de teste por evitar
que procedimentos desempenhados no telefone por um caso de teste afete o
resultado de outros casos de teste.
6.2 Limitaes
A implementao feita neste trabalho para o aprimoramento da ferramenta
TAFStudio apresenta algumas limitaes, que dizem respeito principalmente
complexidade envolvida para contornar as mesmas, no tendo sido solucionadas
por fugirem do escopo deste trabalho.

39

Uma das limitaes tem relao com o mapeamento de todas as UFs
existentes no TAF. Neste trabalho foi realizado um mapeamento simples das UFs
que foram utilizadas ligando o nome da UF ao toolkit, parmetros e mtodos
corretos para sua chamada, acabando por restringir a criao de testes apenas s
UFs que foram mapeadas.

Outra limitao com relao criao de objetos que devem ser passados
como parmetros para as UFs. Tais objetos geralmente so criados chamando-se
uma UF e guardados, o que possvel na implementao realizada, porm o que
no contemplado que esses objetos tm alguns valores modificados pela
invocao de mtodos nos mesmos, e.g., criao de uma entrada da agenda de
contatos e insero do nome e nmero que devem ser guardados na mesma.
6.3 Sugestes para trabalhos futuros
So sugestes para trabalhos futuros:
Estudar uma forma vivel de se ter acesso todas as UFs presentes no
TAF, possivelmente pelo uso de reflexo sobre as classes dos toolkits ou
utilizando uma forma mais simples de mapeamento das UFs do que a
atualmente implementada;
Implementar um sistema de variveis internas, para que possam ser
criados objetos contendo valores desejados pelo usurio e que sejam
usados como parmetros para as UFs;
Adicionar a funcionalidade de converso automtica dos casos de teste do
TAF, criados utilizando o TAFStudio, para scripts em linguagem de
programao, que podem ser executados utilizando somente o TAF.

40

Referncias

BCS SIGIST (British Computer Society Specialist Interest Group in Software
Testing). Standard for Software Component Testing. Working Draft 3.4, 27 Abril
2001.

BOURQUE, P. et al. Guide to the software engineering body of knowledge. Los
Alamitos, CA, USA: IEEE Computer Society Press, 2001. Dsponivel em:
<http://www.swebok.org/ironman/pdf/SWEBOK_Guide_2004.pdf>. Acesso em: 26
Agosto 2008.

CHERNONOZHKIN, S.K. Automated test generation and static analysis.
Programming and Computer Software, v. 27, n. 2, p. 86-84, 2001.

DUSTIN,E.;RASHKA,J .;PAUL,J . Automated Software Testing. [S.l.]:Addison-
Wesley Professional,1999.

ELDTH, S. et al. Component Testing Is Not Enough A Study of Software Faults In
Telecom Middleware. TestCom/FATES 2007. Tallin, Estonia. 2007.

ECLIPSEPEDIA. Rich Client Platform. 2009. Disponvel em:
<http://wiki.eclipse.org/index.php/Rich_Client_Platform>. Acesso em: 5 Maio 2009.

EPSICHUK, I.; VALIDOV, D. Ptf-based test automation for java applications on
mobile phones. IEEE 10
th
International Symposium on Consumer Electronics.
[S.l.: s.n.], 2006. p. 1 3.

KANER, C. Exploratory Testing. Quality Assurance Institute Worldwide Annual
Software Testing Conference. Orlando, FL, USA, 2006.

41

KAWAKAMI, L. et al. A test automation framework for mobile phones. VIII IEEE
Latin-American Test WorkShop. [S.l.: s.n.], 2007.

NEWMAN, M. Software Errors Cost U.S. Economy $59.5 Billion Annually. NIST. [S.l.:
s.n.], 28 junho 2002. Disponvel em: <http://www.nist.gov/public_affairs/releases/n02-
10.htm>. Acesso em: 25 junho 2008.

PAREKH, N. White box testing strategy. [S.I.:s.n.], 04 novembro 2005. Dsponivel
em: <http://www.buzzle.com/editorials/4-10-2005-68350.asp>. Acesso em: 26 agosto
2008.

PETROSKI, B. M. Gerao automtica de casos de teste automatizados no
contexto de uma sute de testes em telefones celulares. Trabalho de Concluso
de Curso. Universidade Federal de Santa Catarina. Florianpolis, 2006.

RAMLER, R.; WOLFMAIER, K. Economic Perspectives in Test Automation:
Balancing Automated and Manual Testing with Opportunity Cost. Proc. International
Workshop on Automation of Software Test. Shanghai, China. 2006.

RECHIA, D. N. et al. An Object-Oriented Framework for Improving Software Reuse
on Automated Testing of Mobile Phones. TestCom/FATES 2007. Tallin, Estonia.
2007.

SOBEL, J .; FRIEDMAN, D. An Introduction to Reflection-Oriented Programming.
[S.I.:s.n.]. 1996.

TINKHAM, A.; KANER C. Learning Styles and Exploratory Testing. Pacific
Northwest Software Quality Conference. [S.l.: s.n.], 2003.

42

Apndice A Cdigo-fonte

/ *
* VTSTI L - Ver onese TAFSt udi o TAF I nt egr at i on Li br ar y
* Copyr i ght ( C) 2009 Thi ago Schoppen Ver onese <t ver onese@gmai l . com>
*
* Thi s l i br ar y i s f r ee sof t war e; you can r edi st r i but e i t and/ or
* modi f y i t under t he t er ms of t he GNU Lesser Gener al Publ i c
* Li cense as publ i shed by t he Fr ee Sof t war e Foundat i on; ei t her
* ver si on 2. 1 of t he Li cense, or ( at your opt i on) any l at er ver si on.
*
* Thi s l i br ar y i s di st r i but ed i n t he hope t hat i t wi l l be usef ul ,
* but WI THOUT ANY WARRANTY; wi t hout even t he i mpl i ed war r ant y of
* MERCHANTABI LI TY or FI TNESS FOR A PARTI CULAR PURPOSE. See t he GNU
* Lesser Gener al Publ i c Li cense f or mor e det ai l s.
*
* You shoul d have r ecei ved a copy of t he GNU Lesser Gener al Publ i c
* Li cense al ong wi t h t hi s l i br ar y; I f not , see
<ht t p: / / www. gnu. or g/ l i censes/ >.
*/
package com.mot or ol a.t af st udi o.t cdevel opment .vt st i l ;

import j ava.ut i l .Ar r ayLi st ;
import j ava.ut i l .Li st ;

/ **
* Descr i bes a TAFSt udi o t est case cont ai ni ng onl y TAF Ut i l i t y Funct i ons
cal l s.
*/
publ i c cl ass TAFTest Case
{
/ **
* The name of t he TAF t est case.
*/
pr i vat e St r i ng t est CaseName;

/ **
* The l i st of t est case st eps.
*/
pr i vat e Li st <TAFTest CaseSt ep> st epLi st ;

/ **
* Const r uct or .
*
* @param t est CaseName The name of t he t est case.
*/
ubl i c TAFTest Case(St r i ng t est CaseName) p
{
this.t est CaseName = t est CaseName;
43

this.st epLi st = new Ar r ayLi st <TAFTest CaseSt ep>();
}

/ **
* Get s t he val ue of f i el d " t est CaseName" .
*
* @return Ret ur ns t he val ue of f i el d " t est CaseName" .
*/
publ i c St r i ng get Name()
{
return t est CaseName;
}

/ **
* Get s t he val ue of f i el d " st eps" .
*
* @return Ret ur ns t he val ue of f i el d " st eps" .
*/
publ i c Li st <TAFTest CaseSt ep> get St epsLi st ()
{
return st epLi st ;
}

/ **
* Add a TAFTest CaseSt ep t o t est case st eps l i st .
*
* @param st ep The st ep t o be added.
*/
publ i c voi d addSt epToLi st (TAFTest CaseSt ep st ep)
{
st epLi st .add(st ep);
}

/ **
* Remove a TAFTest CaseSt ep f r omt est case st ep l i st .
*
* @param st ep The st ep t o be r emoved.
*/
ubl i c voi d r emoveSt epFr omLi st (TAFTest CaseSt ep st ep) p
{
st epLi st .r emove(st ep);
}

/ *
* ( non- J avadoc)
* @see j ava. l ang. Obj ect #t oSt r i ng( )
*/
@Over r i de
publ i c St r i ng t oSt r i ng()
{
return " TAF Test Case: " + t est CaseName;
}

}

/ *
44

*
*
*
*/


/ **
* Repr esent s a t est case st ep i n a TAFTest Case.
*/
publ i c cl ass TAFTest CaseSt ep
{

/ **
* The UF t o be execut ed by t hi s st ep
*/
pr i vat e TAFUt i l i t yFunct i on uf ;

/ **
* The user par amet er of t hi s st ep.
*/
pr i vat e Li st <Obj ect > user Par ams;

/ **
* The r et ur n val ue of t he execut i on of t he UF of t hi s st ep.
*/
pr i vat e Obj ect execRet ur nVal ue;

/ **
* Const r uct or .
*
* @param uf The UF t o be execut ed by t hi s st ep
*/
ubl i c TAFTest CaseSt ep(TAFUt i l i t yFunct i on uf ) p
{
this.uf = uf ;
this.user Par ams = new A i st <Obj ect >(); r r ayL
this.execRet ur nVal ue = null;
}

/ **
* Get s t he val ue of f i el d " uf " .
*
* @return Ret ur ns t he val ue of f i el d " uf " .
*/
publ i c TAFUt i l i t yFunct i on get Uf ()
45

{
return uf ;
}

/ **
* Get s t he val ue of f i el d " execRet ur nVal ue" .
*
* @return Ret ur ns t he val ue of f i el d " execRet ur nVal ue" .
*/
publ i c Obj ect get ExecRet ur nVal ue()
{
return execRet ur nVal ue;
}

/ **
* Set s t he val ue of f i el d " execRet ur nVal ue" .
*
* @param execRet ur nVal ue The val ue of f i el d " execRet ur nVal ue" t o set .
*/
publ i c voi d set ExecRet ur nVal ue(Obj ect execRet ur nVal ue)
{
this.execRet ur nVal ue = execRet ur nVal ue;
}

/ **
* Get s t he val ue of f i el d " user Par ams" .
*
* @return Ret ur ns t he val ue of f i el d " user Par ams" .
*/
ubl i c Li st <Obj ect > get User Par ams() p
{
return user Par ams;
}
}

/ *
*
*
*
*/

import com.mot or ol a.t af .f r ont end.composedopt i ons.messages.Message;
import com.mot or ol a.t af .f r ont end.opt i on.*;
import com.mot or ol a.t af .f r ont end.opt i on.messagi ng.SmsEmsMmsScr een;
46

import com.mot or ol a.t af .f r ont end.opt i on.mul t i medi a.Pi ct ur eFi l e;
import com.mot or ol a.t af st udi o.t cdevel opment .vt st i l .r unner .TAFRunner Suppor t ;

/ **
* Enumer at i on t hat maps t o TAF Ut i l i t y Funct i ons.
*/
@Suppr essWar ni ngs(" unchecked" )
publ i c enumTAFUt i l i t yFunct i on
{
/ **
* Go t o i dl e UF. Same as: pb. navi gat i onTk. goToI dl e( ) ;
*/
GO_TO_I DLE(" Navi gat i on Tool ki t - Go t o i dl e" , " navi gat i onTk" ,
" goToI dl e" , 0, null),

/ **
* Launch Camer a UF. Same as:
pb. navi gat i onTk. l aunchApp( PhoneAppl i cat i on. get ( " CAMERA" ) ) ;
*/
LAUNCH_CAMERA(" Navi gat i on Tool ki t - Launch camer a" , " navi gat i onTk" ,
" l aunchApp" , 0,
new Cl ass[] { PhoneAppl i cat i on.cl ass },
PhoneAppl i cat i on.get (" CAMERA" )),

/ **
* Capt ur e pi ct ur e f r omcamer a UF. Same as:
pb. mul t i medi aTk. capt ur ePi ct ur eFr omCamer a( ) ;
*/
CAPTURE_PI CTURE_FROM_CAMERA(" Mul t i medi a Tool ki t - Capt ur e pi ct ur e f r om
camer a" , " mul t i medi aTk" ,
" capt ur ePi ct ur eFr omCamer a" , 0, null),

/ **
* St or e onl y capt ur ed pi ct ur e f r omcamer a UF. Same as:
*
pb. mul t i medi aTk. st or eCapt ur edPi ct ur eAs( Mul t i medi aI t em. get ( " STORE_ONLY" ) ) ;
*/
STORE_ONLY_CAPTURED_PI CTURE(" Mul t i medi a Tool ki t - St or e onl y capt ur ed
pi ct ur e" , " mul t i medi aTk" ,
" st or eCapt ur edPi ct ur eAs" , 0, new Cl ass[] { Mul t i medi aI t em.cl ass },
Mul t i medi aI t em
.get (" STORE_ONLY" )),

/ **
* Launch Medi a Fi nder UF. Same as:
pb. navi gat i onTk. l aunchApp( PhoneAppl i cat i on. get ( " PI CTURES" ) ) ;
*/
LAUNCH_PI CTURES_VI EW(" Navi gat i on Tool ki t - Launch pi ct ur es vi ewer " ,
" navi gat i onTk" ,
" l aunchApp" , 0, new Cl ass[] { PhoneAppl i cat i on.cl ass },
PhoneAppl i cat i on.get (" PI CTURES" )),

/ **
* Check scr een PI CTURES UF. Same as:
pb. phoneTk. checkScr een( Mul t i medi aScr een. get ( " PI CTURES" ) ) ;
*/
CHECK_SCREEN_PI CTURES(" Phone Tool ki t - Check scr een PI CTURES" ,
" phoneTk" , " checkScr een" , 0,
new Cl ass[] { Appl i cat i onScr een.cl ass },
Mul t i medi aScr een.get (" PI CTURES" )),
47

/ **
* Scr ol l t o and sel ect al l pi ct ur es menu i t emUF. Same as:
*
pb. navi gat i onTk. scr ol l ToAndSel ect ( Mul t i medi aI t em. get ( " ALL_PI CTURES" ) ) ;
*/
SCROLL_TO_AND_SELECT_ALL_PI CTURES(" Navi gat i on Tool ki t - Scr ol l t o and
sel ect al l pi ct ur es" ,
" navi gat i onTk" , " scr ol l ToAndSel ect " , 0, new Cl ass[] {
Appl i cat i onI t em.cl ass },
Mul t i medi aI t em.get (" ALL_PI CTURES" )),

/ **
* Pr ess CENTER phone key UF. Same as:
pb. phoneTk. pr essKey( PhoneHar dKey. get ( " CENTER" ) ) ;
*/
PRESS_CENTER_PHONEKEY(" Phone Tool ki t - Pr ess CENTER phone key" ,
" phoneTk" , " pr essKey" , 0,
new Cl ass[] { PhoneHar dKey.cl ass }, PhoneHar dKey.get (" CENTER" )),

/ **
* Del et e pi ct ur e f i l e UF. Same as:
pb. mul t i medi aTk. del et ePi ct ur e( pi ct ur e) ;
*/
DELETE_PI CTURE_FI LE(" Mul t i medi a Tool ki t - Del et e pi ct ur e f i l e" ,
" mul t i medi aTk" ,
" del et ePi ct ur e" , 1, new Cl ass[] { Pi ct ur eFi l e.cl ass }),

/ **
* Cal l J ohn number UF. Same as:
pb. phoneTk. cal l ( PhonebookCont ent . get ( " NUMBER_J OHN" ) ) ;
*/
CALL_J OHN_NUMBER(" Phone Tool ki t - Cal l Davi d number " , " phoneTk" ,
" cal l " , 0,
new Cl ass[] { PhonebookCont ent .cl ass },
PhonebookCont ent .get (" NUMBER_J OHN" )),

/ **
* End cal l UF. Same as: pb. phoneTk. endCal l ( ) ;
*/
END_CALL(" Phone Tool ki t - End cal l " , " phoneTk" , " endCal l " , 0, null),

/ **
* Compose " Hel l o wor l d" SMS message UF. Same as:
* pb. msgTk. composeMessage( TAFRunner Suppor t . bui l dHel l oWor l dSMS( ) ) ;
*/
COMPOSE_SMS_MESSAGE(" Message Tool ki t - Compose a SMS message" , " msgTk" ,
" composeMessage" , , 0
new Cl ass[] { Message.cl ass },
TAFRunner Suppor t .bui l dHel l oWor l dSMS()),

/ **
* Check scr een MESSAGE_COMPOSER UF. Same as:
* pb. phoneTk. checkScr een( SmsEmsMmsScr een. get ( " MESSAGE_COMPOSER" ) ) ;
*/
CHECK_SCREEN_MSG_COMPOSER(" Phone Tool ki t - Check scr een MESSAGE
COMPOSER" , " phoneTk" ,
" checkScr een" , 0, new Cl ass[] { Appl i cat i onScr een.cl ass },
SmsEmsMmsScr een
.get (" MESSAGE_COMPOSER" )),
48

/ **
* Same as: pb. msgTk. saveComposedMsgToDr af t s( ) ;
*/
SAVE_MSG_TO_DRAFTS(" Message Tool ki t - Save composed message t o dr af t s" ,
" msgTk" ,
" saveComposedMsgToDr af t s" , 0, null);

/ **
* The f r i endl y name of t he UF.
*/
pr i vat e St r i ng f r i endl yName;

/ **
* The name of t he Tool ki t .
*/
pr i vat e St r i ng t ool ki t ;

/ **
* The name of t he met hod of t he Tool ki t .
*/
pr i vat e St r i ng met hod;

/ **
* The number of user par amet er s r equi r ed by t he UF.
*/
pr i vat e I nt eger number Of User Par ams;

/ **
* The par amet er t ypes f or t he UF.
*/
pr i vat e Cl ass<Obj ect >[] par amTypes;

/ **
* The par amet er s t o t he UF cal l .
*/
pr i vat e Obj ect [] par amet er s;

/ **
* Const r uct or .
*
* @param f r i endl yName The f r i endl y name of t he UF.
* @param t ool ki t The name of t he Tool ki t .
* @param met hod The name of t he met hod of t he Tool ki t .
* @param number Of User Par ams The number of user par amet er s r equi r ed by
t he UF.
* @param par amTypes
* @param par amet er s The par amet er s t o t he UF cal l .
*/
pr i vat e TAFUt i l i t yFunct i on(St r i ng f r i endl yName, St r i ng t ool ki t , St r i ng
met hod,
I nt eger number Of User Par ams, Cl ass<Obj ect >[] par amTypes, Obj ect ...
par amet er s)
{
this.f r i endl yName = f r i endl yName;
this.t ool ki t = t ool ki t ;
this.met hod = met hod;
this.number Of User Par ams = number Of User Par ams;
this.par amTypes = par amTypes;
this.par amet er s = par amet er s;
49

}

/ **
* Get s t he val ue of f i el d " f r i endl yName" .
*
* @return Ret ur ns t he val ue of f i el d " f r i endl yName" .
*/
publ i c St r i ng get Fr i endl yName()
{
return f r i endl yName;
}

/ **
* Get s t he val ue of f i el d " t ool ki t " .
*
* @return Ret ur ns t he val ue of f i el d " t ool ki t " .
*/
publ i c St r i ng get Tool ki t ()
{
return t ool ki t ;
}

/ **
* Get s t he val ue of f i el d " met hod" .
*
* @return Ret ur ns t he val ue of f i el d " met hod" .
*/
publ i c St r i ng get Met hod()
{
return met hod;
}

/ **
* Get s t he val ue of f i el d " par amet er s" .
*
* @return Ret ur ns t he val ue of f i el d " par amet er s" .
*/
publ i c Obj ect [] get Par amet er s()
{
return par amet er s;
}

/ **
* Get s t he val ue of f i el d " number Of User Par ams" .
*
* @return Ret ur ns t he val ue of f i el d " number Of User Par ams" .
*/
ubl i c I nt eger get Number Of User Par ams() p
{
return number Of User Par ams;
}

/ **
* Get s t he val ue of f i el d " par amTypes" .
*
* @return Ret ur ns t he val ue of f i el d " par amTypes" .
*/
publ i c Cl ass<Obj ect >[] get Par amTypes()
{
return par amTypes;
50

}

}

/ *
*
*
*
*/
package com.mot or ol a.t af st udi o.t cdevel opment .vt st i l .r unner ;

import com.mot or ol a.t af .f r ont end.composedopt i ons.messages.SMS;
import com.mot or ol a.t af .f r ont end.opt i on.PhonebookCont ent ;
import com.mot or ol a.t af .f r ont end.opt i on.messagi ng.SmsEmsMmsCont ent ;

/ **
* Suppor t f or execut i on of TAF UFs on TAFSt udi o.
*/
publ i c f i nal cl ass TAFRunner Suppor t
{

/ **
* Bui l ds a SMS " Hel l o Wor l d" message t o addr ess " NUMBER_DAVI D" .
*
* @return The cr eat ed SMS.
*/
publ i c st at i c SMS bui l dHel l oWor l dSMS()
{
SMS sms = new SMS();
sms.set Message(SmsEmsMmsCont ent .get (" HELLO_WORLD" ));
. dAdd ess(PhonebookCont ent .get (" NUMBER_DAVI D" )); sms ad r
return sms;
}
}

/ *
*
51

*
*
*/
package com.mot or ol a.t af st udi o.t cdevel opment .vt st i l .r unner ;

import j ava.l ang.r ef l ect .I nvocat i onTar get Except i on;
import j ava.l ang.r ef l ect .Met hod;

import or g.ecl i pse.cor e.r unt i me.I Pr ogr essMoni t or ;
import or g.ecl i pse.cor e.r unt i me.I St at us;
import or g.ecl i pse.cor e.r unt i me.St at us;
import or g.ecl i pse.cor e.r unt i me.j obs.I J obChangeLi st ener ;
import or g.ecl i pse.cor e.r unt i me.j obs.J ob;

import com.mot or ol a.t af .f r ont end.Gener i cPhoneBundl e;
import com.mot or ol a.t af .f r ont end.Tool ki t ;
import com.mot or ol a.t af st udi o.har dwar e.PhoneCat al og;
import com.mot or ol a.t af st udi o.har dwar e.PhoneWr apper ;
import com.mot or ol a.t af st udi o.t cdevel opment .vt st i l .TAFTest Case;
import com.mot or ol a.t af st udi o.t cdevel opment .vt st i l .TAFTest CaseSt ep;
import com.mot or ol a.t af st udi o.t cdevel opment .vt st i l .TAFUt i l i t yFunct i on;

/ **
* J ob t hat r uns a TAFTest Case.
*/
publ i c cl ass TAFTest CaseRunner extends J ob
{
/ **
* Cur r ent j ob r unni ng a t est case.
*/
pr i vat e st at i c TAFTest CaseRunner cur r ent Run;

/ **
* The t est case bei ng r un.
*/
pr i vat e TAFTest Case t est Case;

/ **
* Phone bundl e t hat wi l l r un t he UFs.
*/
pr i vat e Gener i cPhoneBundl e pb0;

/ **
* Const r uct or .
*
* @param t est Case The {@l i nk TAFTest Case} t o be r un.
*/
publ i c TAFTest CaseRunner (TAFTest Case t est Case)
{
super(" TAFTest CaseRunner : " + t est Case.get Name());
52

this.t est Case = t est Case;
}

/ **
* St ar t s r unni ng desi r ed t est case.
*
* @param t est Case Test case t o r un.
* @param j obLi st ener Opt i onal j ob change l i st ener t o be not i f i ed about
t he r un.
* @param user J ob Whet her or not t hi s j ob must be shown t o t he user .
* @throws I l l egal St at eExcept i on I f t her e i s a t est case r unni ng. Onl y
one t est case can r un at
* a t i me.
*/
publ i c st at i c voi d st ar t Test Case(TAFTest Case t est Case,
I J obChangeLi st ener j obLi st ener ,
bool ean user J ob) throws I l l egal St at eExcept i on
{
if (i sRunni ng())
{
throw new I l l egal St at eExcept i on(" Ther e i s a t est case
r unni ng. " );
}
cur r ent Run = new TAFTest CaseRunner (t est Case);
if (j obLi st ener != null)
{
cur r ent Run.addJ obChangeLi st ener (j obLi st ener );
}
cur r ent Run.set User (user J ob);
cur r ent Run.schedul e();
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. cor e. r unt i me. j obs. J ob#r un( or g. ecl i pse. cor e. r unt i me. I Pr ogr essMon
i t or )
*/
@Over r i de
pr ot ect ed I St at us r un(I Pr ogr essMoni t or moni t or )
{
/ / Suspend scr een capt ur e f r omTAFSt udi o
Li st <PhoneWr apper > phones =
PhoneCat al og.get I nst ance().get Connect edPhones();
for (PhoneWr apper phone : phones)
{
phone.suspendDi spl ayCapt ur e();
}

/ / I ni t i al i ze phone bundl es
if (pb0 == null)
{
moni t or .begi nTask(" I ni t i al i zi ng phone bundl e" ,
I Pr ogr essMon .UNKNOWN); i t or
this.pb0 = Gener i cPhoneBundl e.get I nst ance(0);
}

moni t or .begi nTask(" Runni ng t est case: " + t est Case.get Name(),
I Pr ogr essMoni t or .UNKNOWN);
I St at us r esul t = St at us.OK_STATUS;
53

Li st <TAFTest CaseSt ep> st epLi st = t est Case.get St epsLi st ();

try
{
for (TAFTest CaseSt ep st ep : st epLi st )
{
TAFUt i l i t yFunct i on uf = st ep.get Uf ();

moni t or .begi nTask(" Runni ng UF: " + uf .get Fr i endl yName(),
I Pr ogr essMoni t or .UNKNOWN);

/ / Get t ool ki t usi ng r ef l ect i on
Tool ki t t ool ki t = (Tool ki t )
pb0.get Cl ass().get Fi el d(uf .get Tool ki t ()).get (pb0);

/ / Get et hod par ame e m t r s
Obj ect [] par amet er s = null;
if (uf .get Number Of User Par ams() > 0)
{
Li st <Obj ect > user Par ams = st ep.get User Par ams();
Li st <Obj ect > par ams = new Ar r ayLi st <Obj ect >();
for (Obj ect par am: user Par ams)
{
/ / I f par ami s a st ep, t hen i t i s i t ' s r et ur n val ue
if (par aminstanceof TAFTest CaseSt ep)
{
par ams.add(((TAFTest CaseSt ep)
par am).get ExecRet ur nVal ue());
}
else
{
par ams.add(par am);
}
}
par amet er s = par ams.t oAr r ay();
}
else
{
par amet er s = uf .get Par amet er s();
}

/ / Cr eat e met hod i nst ance and i nvoke i t
Met hod met hod =
t ool ki t .get Cl ass().get Met hod(uf .get Met hod(), uf .get Par amTypes());
Obj ect r et ur nVal ue = met hod.i nvoke(t ool ki t , par amet er s);

/ / St or e t he r et ur ned val ue f r omt he UF
st ep.set ExecRet ur nVal ue(r et ur nVal ue);
}
}
catch (NoSuchMet hodExcept i on e)
{
r esul t = St at us.CANCEL_STATUS;
e.pr i nt St ackTr ace();
}
catch (Secur i t yExcept i on e)
{
54

}
catch (I l l egal Ar gument Except i on e)
{
}
catch (I l l egal AccessExcept i on e)
{
}
catch (I nvocat i onTar get Except i on e)
{
}
catch (NoSuchFi el dExcept i on e)
{
}
finally
{
for (PhoneWr apper phone : phones)
{
phone.r esumeDi spl ayCapt ur e();
}

moni t or .done();
}

return r esul t ;
}

/ **
* I ndi cat es i f t her e i s a t est case r unni ng so no ot her t est case can
st ar t .
*
* @return Fl ag i ndi cat i ng i f t her e i s a t est case r unni ng.
*/
publ i c st at i c bool ean i sRunni ng()
{
return (cur r ent Run != null) && (cur r ent Run.get St at e() != J ob.NONE);
}

}

/ *
*
*
55

*
*/
package com.mot or ol a.t af st udi o.ui .act i on.vt st i l ;

import or g.ecl i pse.j f ace.act i on.Act i on;
import or g.ecl i pse.j f ace.di al ogs.I nput Di al og;
import or g.ecl i pse.j f ace.wi ndow.Wi ndow;
import or g.ecl i pse.ui .I Wor kbenchWi ndow;
import or g.ecl i pse.ui .act i ons.Act i onFact or y.I Wor kbenchAct i on;

import com.mot or ol a.t af st udi o.t cdevel opment .Test CaseCat al og;
import com.mot or ol a.t af st udi o.ui .di al ogs.Test CaseNameVal i dat or ;
import com.mot or ol a.t af st udi o.ui .edi t or s.Edi t or sManager ;
import com.mot or ol a.t af st udi o.ui .r esour ces.I mages;

/ **
* Cr eat es a new TAF t est case.
*/
publ i c cl ass NewTAFTest CaseAct i on extends Act i on implements
I Wor kbenchAct i on
{

/ **
* I D t o al l ow r ef er enci ng t hi s act i on i n RCP.
*/
publ i c st at i c f i nal St r i ng I D =
" t af st udi o. act i ons. vt st i l . newTAFTest Case" ;

/ **
* Wor kbench wi ndow r ef er ence t o al l ow showi ng di al ogs.
*/
pr i vat e I Wor kbenchWi ndow wi ndow;

/ **
* Const r uct or .
*
* @param wi ndow Mai n wi ndow.
*/
ubl i c NewTAFTest CaseAct i on(I Wor kbenchWi ndow wi ndow) p
{
super(" New TAF t est case" );
this. i n w = wi ndow; w do
set I d(I D);
set I mageDescr i pt or (I mages.TAF.descr i pt or ());
set Tool Ti pText (" Cr eat es a new TAF t est case" );
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . act i ons. Act i onFact or y. I Wor kbenchAct i on#di spose( )
*/
@Over r i de
publ i c voi d di spose()
{
56

/ / not hi ng t o di spose i nt er nal l y
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. j f ace. act i on. Act i on#get I d( )
*/
@Over r i de
publ i c St r i ng get I d()
{
return I D;
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. j f ace. act i on. Act i on#get Text ( )
*/
@Over r i de
publ i c St r i ng get Text ()
{
return " New TAF t est case" ;
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. j f ace. act i on. Act i on#r un( )
*/
@Over r i de
publ i c voi d r un()
{
I nput Di al og t cNameDi al og = new I nput Di al og(wi ndow.get Shel l (), " New
TAF t est case" ,
" Type t he name of t he new TAF t est case" , null, new
Test CaseNameVal i dat or ());
i nt st at us = t cNameDi al og.open();
if (st at us == Wi ndow.OK)
{
St r i ng t cName = t cNameDi al og.get Val ue();
TAFTest Case t est Case =
Test CaseCat al og.get I nst ance().cr eat eTAFTest Case(t cName);
Edi t or sManager .openTAFTest CaseEdi t or (t est Case);
}
}

}

/ *
*
*
57

*
*/
package com.mot or ol a.t af st udi o.ui .di al ogs;

import or g.ecl i pse.j f ace.di al ogs.Tr ayDi al og;
import or g.ecl i pse.j f ace.vi ewer s.I St r uct ur edSel ect i on;
import or g.ecl i pse.j f ace.vi ewer s.Tr eeVi ewer ;
import or g.ecl i pse.swt .SWT;
import or g.ecl i pse.swt .event s.Sel ect i onEvent ;
import or g.ecl i pse.swt .event s.Sel ect i onLi st ener ;
import or g.ecl i pse.swt .l ayout .Gr i dLayout ;
import or g.ecl i pse.swt .wi dget s.*;

import com.mot or ol a.r cput i l s.ui .di al ogs.Di al ogUt i l ;
import com.mot or ol a.t af st udi o.ui .edi t or s.vt st i l .TAFSt epsCont ent Pr ovi der ;
import com.mot or ol a.t af st udi o.ui .edi t or s.vt st i l .TAFSt epsLabel Pr ovi der ;

/ **
* Di al og t o edi t a TAFTest CaseSt ep.
*/
publ i c cl ass Edi t TAFTest CaseSt epDi al og extends Tr ayDi al og
{

/ **
* The st ep bei ng edi t ed.
*/
pr i vat e TAFTest CaseSt ep st ep;

/ **
* The t est case t hat has t he st ep.
*/

/ **
* The t est case st eps t r ee.
*/
pr i vat e Tr eeVi ewer st epsTr ee;

/ **
* Const r uct or .
*
* @param st ep The st ep t o be edi t ed.
* @param t est Case The t est case t hat has t he st ep.
*/
publ i c Edi t TAFTest CaseSt epDi al og(TAFTest CaseSt ep st ep, TAFTest Case
t est Case)
{
super(Di al ogUt i l .get Shel l (null));
this.st ep = st ep;
}

/ *
58

* ( non- J avadoc)
* @see
or g. ecl i pse. j f ace. wi ndow. Wi ndow#conf i gur eShel l ( or g. ecl i pse. swt . wi dget s. Shel
l )
*/
@Over r i de
pr ot ect ed voi d conf i gur eShel l (Shel l newShel l )
{
super.conf i gur eShel l (newShel l );
newShel l .set Text (" Edi t TAF t est case st ep" );
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. j f ace. di al ogs. Di al og#cr eat eDi al ogAr ea( or g. ecl i pse. swt . wi dget s. C
omposi t e)
*/
@Over r i de
pr ot ect ed Cont r ol cr eat eDi al ogAr ea(Composi t e par ent )
{
Composi t e composi t e = (Composi t e) super.cr eat eDi al ogAr ea(par ent );

composi t e.set Layout (new Gr i dLayout (1, false));

st epsTr ee = new Tr eeVi ewer (composi t e, SWT.SI NGLE | SWT.BORDER |
SWT.VI RTUAL
| SWT.FULL_SELECTI ON);
st epsTr ee.set Label Pr ovi der (new TAFSt epsLabel Pr ovi der ());
st epsTr ee.set Cont e t Pr ovi de (new TAFSt epsCont ent Pr ovi der ()); n r
st epsTr ee.set I nput (t est Case.get St epsLi st ().t oAr r ay());

TAFUt i l i t yFunct i on uf = st ep.get Uf ();

Composi t e par amsComp = new Composi t e(composi t e, SWT.NONE);
amsCom.set Layout (new Gr i dLayout (2, false)); par p
new Label (par amsComp, SWT.NONE).set Text (" St ep: " );
new Label (par amsComp, SWT.NONE).set Text (uf .get Fr i endl yName());

i nt nbr Par ams = uf .get Number Of User Par ams();

for (i nt i = 0; i < nbr Par ams; i ++)
{
new Label (par amsComp, SWT.NONE).set Text (" Par am" + i + " : " );
But t on b = new But t on(par amsComp, S .NONE); WT
b.set Text (" Ret ur n of sel ect ed st ep" );

.addSel ect i onLi st ener (new Sel ect i onLi st ener () b
{
/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. swt . event s. Sel ect i onLi st ener #wi dget Sel ect ed( or g. ecl i pse. swt .
* event s. Sel ect i onEvent )
*/
@Over r i de
ubl i c voi d wi dget Sel ect ed(Sel ect i onEvent e) p
{
Obj ect sel = ((I St r uct ur edSel ect i on)
st epsTr ee.get Sel ect i on())
59

.get Fi r st El ement ();
if (sel instanceof TAFTest CaseSt ep)
{
TAFTest CaseSt ep cur r ent = (TAFTest CaseSt ep) sel ;
st ep.get User Par ams().add(cur r ent );
}
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. swt . event s. Sel ect i onLi st ener #wi dget Def aul t Sel ect ed( or g.
* ecl i pse. swt . event s. Sel ect i onEvent )
*/
@Over r i de
publ i c voi d wi dget Def aul t Sel ect ed(Sel ect i onEvent e)
{
/ / Empt y
}
});
}

return composi t e;
}

}

/ *
*
*
*
*/
package com.mot or ol a.t af st udi o.ui .edi t or s.vt st i l ;

import or g.ecl i pse.j f ace.vi ewer s.I Tr eeCont ent Pr ovi der ;
import or g.ecl i pse.j f ace.vi ewer s.Vi ewer ;

/ **
* TAF t est case st eps cont ent pr ovi der .
*/
publ i c cl ass TAFSt epsCont ent Pr ovi der implements I Tr eeCont ent Pr ovi der
{

/ **
* TAFTest CaseSt ep l i st t hat t hi s pr ovi der adapt s.
60

*/
pr i vat e Obj ect [] l i st ;

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. j f ace. vi ewer s. I Tr eeCont ent Pr ovi der #get Chi l dr en( j ava. l ang. Obj ect
)
*/
@Over r i de
publ i c Obj ect [] get Chi l dr en(Obj ect par ent El ement )
{
return null;
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. j f ace. vi ewer s. I Tr eeCont ent Pr ovi der #get Par ent ( j ava. l ang. Obj ect )
*/
@Over r i de
publ i c Obj ect get Par ent (Obj ect el ement )
{
return null;
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. j f ace. vi ewer s. I Tr eeCont ent Pr ovi der #hasChi l dr en( j ava. l ang. Obj ect
)
*/
@Over r i de
publ i c bool ean hasChi l dr en(Obj ect el ement )
{
return false;
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. j f ace. vi ewer s. I St r uct ur edCont ent Pr ovi der #get El ement s( j ava. l ang.
Obj ect )
*/
@Over r i de
publ i c Obj ect [] get El ement s(Obj ect i nput El ement )
{
return l i st ;
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. j f ace. vi ewer s. I Cont ent Pr ovi der #di spose( )
*/
@Over r i de
publ i c voi d di spose()
{
/ / empt y
}

61

/ *
* ( non- J avadoc)
* @see
*
or g. ecl i pse. j f ace. vi ewer s. I Cont ent Pr ovi der #i nput Changed( or g. ecl i pse. j f ace. v
i ewer s. Vi ewer ,
* j ava. l ang. Obj ect , j ava. l ang. Obj ect )
*/
@Over r i de
publ i c voi d i nput Changed(Vi ewer vi ewer , Obj ect ol dI nput , Obj ect
newI nput )
{
if (newI nput instanceof Obj ect [])
{
this.l i st = (Obj ect []) newI nput ;
}
}

}

/ *
*
*
*
*/

import or g.ecl i pse.j f ace.vi ewer s.I BaseLabel Pr ovi der ;
import or g.ecl i pse.j f ace.vi ewer s.Label Pr ovi der ;
import or g.ecl i pse.swt .gr aphi cs.I mage;


/ **
* TAF t est case st eps l abel pr ovi der .
*/
publ i c cl ass TAFSt epsLabel Pr ovi der extends Label Pr ovi der implements
I BaseLabel Pr ovi der
{

/ *
* ( non- J avadoc)
62

* @see
or g. ecl i pse. j f ace. vi ewer s. Label Pr ovi der #get I mage( j ava. l ang. Obj ect )
*/
@Over r i de
publ i c I mage get I mage(Obj ect el ement )
{
return I mages.KEYPRESS_I CON.i mg();
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. j f ace. vi ewer s. Label Pr ovi der #get Text ( j ava. l ang. Obj ect )
*/
@Over r i de
publ i c St r i ng get Text (Obj ect el ement )
{
if (el ement instanceof TAFTest CaseSt ep)
{
return ((TAFTest CaseSt ep) el ement ).get Uf ().get Fr i endl yName();
}
else if (el ement instanceof TAFUt i l i t yFunct i on)
{
return ((TAFUt i l i t yFunct i on) el ement ).get Fr i endl yName();
}

return " Er r or ! " ;
}

}

/ *
*
*
*
*/

import or g.ecl i pse.cor e.r unt i me.I Pr ogr essMoni t or ;
import or g.ecl i pse.cor e. unt i me. obs.J obChangeAdapt er ; r j
import or g.ecl i pse.j f ace.vi ewer s.I St r uct ur edSel ect i on;
import or g.ecl i pse.j f ace.vi ewer s.Tr eeVi ewer ;
import or g.ecl i pse.swt .SWT;
import or g.ecl i pse.swt .event s.Sel ect i onEvent ;
import or g.ecl i pse.swt .event s.Sel ect i onLi st ener ;
63

import or g.ecl i pse.swt .l ayout .Fi l l Layout ;
import or g.ecl i pse.swt .l ayout .Gr i dDat a;
import or g.ecl i pse.swt .l ayout .Gr i dLayout ;
import or g.ecl i pse.swt .wi dget s.But t on;
import or g.ecl i pse.swt .wi dget s.Composi t e;
import or g.ecl i pse.swt .wi dget s.Gr oup;
import or g.ecl i pse.ui .I Edi t or I nput ;
import or g.ecl i pse.ui .I Edi t or Si t e;
import or g.ecl i pse.ui .Par t I ni t Except i on;
import or g.ecl i pse.ui .par t .Edi t or Par t ;

import com.mot or ol a.r cput i l s.ui .di al ogs.Di al ogUt i l ;
import
com.mot or ol a.t af st udi o.t cdevel opment .vt st i l .r unner .TAFTest CaseRunner ;
import com.mot or ol a.t af st udi o.ui .di al ogs.Edi t TAFTest CaseSt epDi al og;

/ **
* Edi t or f or a {@l i nk TAFTest Case}.
*/
publ i c cl ass TAFTest CaseEdi t or extends Edi t or Par t implements
Sel ect i onLi st ener
{
/ **
* TAF t est case edi t or RCP I D.
*/
publ i c st at i c f i nal St r i ng I D = " t af st udi o. edi t or s. edi t TAFTest Case" ;

/ **
* Test case bei ng adapt ed by t hi s edi t or .
*/

/ **
* The vi ewer f or t he t est case st eps.
*/
pr i vat e Tr eeVi ewer st epsTr ee;

/ **
* The vi ewer f or t he TAF UFs.
*/
pr i vat e Tr eeVi ewer uf sTr ee;

/ **
* But t on t o add sel ect ed UF t o t est case.
*/
pr i vat e But t on addUFBt n;

/ **
* But t on t o r emove sel ect ed UF t o t est case.
*/
pr i vat e But t on r emoveUFBt n;

/ **
* But t on t o execut e t est case.
*/
pr i vat e But t on execBt n;
64

/ **
* But t on t o edi t a t est case st ep.
*/
pr i vat e But t on edi t Sel ect edSt ep;

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. ui . par t . Edi t or Par t #doSave( or g. ecl i pse. cor e. r unt i me. I Pr ogr essMon
i t or )
*/
@Over r i de
publ i c voi d doSave(I Pr ogr essMoni t or moni t or )
{
/ / Empt y
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . par t . Edi t or Par t #doSaveAs( )
*/
@Over r i de
publ i c voi d doSaveAs()
{
/ / Empt y
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . par t . Edi t or Par t #i ni t ( or g. ecl i pse. ui . I Edi t or Si t e,
* or g. ecl i pse. ui . I Edi t or I nput )
*/
@Over r i de
publ i c voi d i ni t (I Edi t or Si t e si t e, I Edi t or I nput i nput ) throws
Par t I ni t Except i on
{
set Si t e(si t e);
set I nput (i nput );
this.t est Case = ((TAFTest CaseEdi t or I nput ) i nput ).get Test Case();
set Par t Name(t est Case.get Name());
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . par t . Edi t or Par t #i sDi r t y( )
*/
@Over r i de
publ i c bool ean i sDi r t y()
{
return false;
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . par t . Edi t or Par t #i sSaveAsAl l owed( )
*/
@Over r i de
publ i c bool ean i sSaveAsAl l owed()
{
65

return false;
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. ui . par t . Wor kbenchPar t #cr eat ePar t Cont r ol ( or g. ecl i pse. swt . wi dget s
. Composi t e)
*/
@Over r i de
publ i c voi d cr eat ePar t Cont r ol (Composi t e par ent )
{
par ent .set Layout (new Gr i dLayout (2, false));
cr eat eTest Gr oup(par ent );
cr eat eEdi t Test Gr oup(par ent );
}

/ **
* Gr oup f or t he t est case t r ee vi ewer .
*
* @param par ent The par ent composi t e.
*/
pr i vat e voi d cr eat eTest Gr oup(Composi t e par ent )
{
Gr oup t est Gr oup = new Gr oup(par ent , SWT.NONE);
t est Gr oup.set Text (" Test case st eps: " );
Gr i dDat a gd = new Gr i dDat a(SWT.FI LL, SWT.FI LL, true, true);
t est Gr oup.set Layout Dat a(gd);

Fi l l Layout f l = new Fi l l Layout ();
f l .mar gi nHei ght = 3;
f l .mar gi nWi dt h = 3;
t est Gr oup.set Layout (f l );

st epsTr ee = new Tr eeVi ewer (t est Gr oup, SWT.SI NGLE | SWT.BORDER |
SWT.VI RTUAL
st epsTr ee.set Label Pr ovi der (new TAFSt epsLabel Pr ovi der ());
st epsTr ee.set Cont e t Pr ovi de (new TAFSt epsCont ent Pr ovi der ()); n r
}

/ **
* Cr eat e t est edi t i on gr oup.
*
* @param par ent The par ent composi t e.
*/
r i vat e voi d cr eat eEdi t Test Gr oup(Composi t e par ent ) p
{
Composi t e comp = new Composi t e(par ent , SWT.NONE);
comp.set Layout (new Gr i dLayout ( , false)); 1
Gr i dDat a gd = new Gr i dDat a(SWT.CENTER, SWT.BEGI NNI NG, false, true);
comp.set Layout Dat a(gd);

Gr oup uf Li st Gr oup = new Gr oup(comp, SWT.NONE);
uf Li st Gr oup.set Text (" Test case edi t i on: " );

uf Li st Gr oup.set Layout (new Gr i dLayout (1, false));

66

uf sTr ee = new Tr eeVi ewer (uf Li st Gr oup, SWT.MULTI | SWT.BORDER |
SWT.VI RTUAL
uf sTr ee.set Label Pr ovi der (new TAFSt epsLabel Pr ovi der ());
uf sTr ee.set Cont ent Pr ovi der (new TAFSt epsCont ent Pr ovi der ());
uf sTr ee.set I nput (TAFUt i l i t yFunct i on.val ues());

addUFBt n = new But t on(uf Li st Gr oup, SWT.PUSH);
addUFBt n.set Text (" Add UF t o t est " );
addUFBt n.set I mage(I mages.GREEN_ARROW.i mg());
addUFBt n.addSel ect i onLi st ener (this);

r emoveUFBt n = new But t on(uf Li st Gr oup, SWT.PUSH);
r emoveUFBt n.set Text (" Remove UF f r omt est " );
r emoveUFBt n.set I mage(I mages.DELETE.i mg());
r emoveUFBt n.addSel ect i onLi st ener (this);

edi t Sel ect edSt ep = new But t on(uf Li st Gr oup, SWT.PUSH);
edi t Sel ect edSt ep.set Text (" Edi t cur r ent sel ect ed st ep" );
edi t Sel ect edSt ep.addSel ect i onLi st ener (this);

Gr oup execGr oup = new Gr oup(comp, SWT.NONE);
execGr oup.set Text (" Test case execut i on: " );
execGr oup.set Layout (new Gr i dLayout (1, false));

execBt n = new But t on(execGr oup, SWT.PUSH);
execBt n.set Text (" Run t est case" );
execBt n.set I mage(I mages.RUN.i mg());
execBt n.addSel ect i onLi st ener (this);
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . par t . Wor kbenchPar t #set Focus( )
*/
@Over r i de
publ i c voi d set Focus()
{
/ / Empt y
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. swt . event s. Sel ect i onLi st ener #wi dget Def aul t Sel ect ed( or g. ecl i pse.
swt . event s.
* Sel ect i onEvent )
*/
@Over r i de
publ i c voi d wi dget Def aul t Sel ect ed(Sel ect i onEvent e)
{
/ / Not hi ng t o do
}

/ *
* ( non- J avadoc)
* @see
or g. ecl i pse. swt . event s. Sel ect i onLi st ener #wi dget Sel ect ed( or g. ecl i pse. swt . eve
nt s.
* Sel ect i onEvent )
67

*/
@Over r i de
publ i c voi d wi dget Sel ect ed(Sel ect i onEvent e)
{
Obj ect sour ce = e.get Sour ce();

if (sour ce.equal s(addUFBt n))
{
Obj ect el ement = ((I St r uct ur edSel ect i on)
uf sTr ee.get Sel ect i on()).get Fi r st El ement ();

if (el ement instanceof TAFUt i l i t yFunct i on)
{
TAFTest CaseSt ep st ep = new
TAFTest CaseSt ep((TAFUt i l i t yFunct i on) el ement );
t est Case.addSt epToLi st (st ep);
st epsTr ee.r ef r esh();
}
}
else if (sour ce.equal s(r emoveUFBt n))
{
st epsTr ee.get Sel ect i on()).get Fi r st El ement ();

{
t est Case.r emoveSt epFr omLi st ((TAFTest CaseSt ep) el ement );
st epsTr ee.r ef r esh();
}

}
else if (sour ce.equal s(execBt n))
{
if (TAFTest CaseRunner .i sRunni ng())
{
Di al ogUt i l .showI nf or mat i onMessage(" Unabl e t o r un" ,
" Ther e i s a t est case al r eady r unni ng. Onl y one t est
case can r un at a t i me. " );
}
else
{
TAFTest CaseRunner .st ar t Test Case(t est Case, new
J obChangeAdapt er (), true);
}
}
else if (sour ce.equal s(edi t Sel ect edSt ep))
{
st epsTr ee.get Sel ect i on()).get Fi r st El ement ();

{
new Edi t TAFTest CaseSt epDi al og((TAFTest CaseSt ep) el ement ,
t est Case).open();
}
}
}

68

}

/ *
*
*
*
*/

import or g.ecl i pse.j f ace.r esour ce.I mageDescr i pt or ;
import or g.ecl i pse.ui .I Edi t or I nput ;
import or g.ecl i pse.ui .I Per si st abl eEl ement ;


/ **
* Adapt s a {@l i nk TAFTest Case} t o be shown i n a {@l i nk TAFTest CaseEdi t or }.
*/
publ i c cl ass TAFTest CaseEdi t or I nput implements I Edi t or I nput
{

/ **
* Test case bei ng adapt ed by t hi s edi t or i nput .
*/

/ **
* Const r uct or .
*
* @param t est Case The t est case t o be adapt ed.
*/
publ i c TAFTest CaseEdi t or I nput (TAFTest Case t est Case)
{
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . I Edi t or I nput #exi st s( )
*/
@Over r i de
ubl i c bool ean exi st s() p
{
return true;
69

}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . I Edi t or I nput #get I mageDescr i pt or ( )
*/
@Over r i de
publ i c I mageDescr i pt or get I mageDescr i pt or ()
{
return I mages.TEST_CASE.descr i pt or ();
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . I Edi t or I nput #get Name( )
*/
@Over r i de
publ i c St r i ng get Name()
{
return t est Case.get Name();
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . I Edi t or I nput #get Per si st abl e( )
*/
@Over r i de
publ i c I Per si st abl eEl ement get Per si st abl e()
{
return null;
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. ui . I Edi t or I nput #get Tool Ti pText ( )
*/
@Over r i de
publ i c St r i ng get Tool Ti pText ()
{
return t est Case.get Name();
}

/ *
* ( non- J avadoc)
* @see or g. ecl i pse. cor e. r unt i me. I Adapt abl e#get Adapt er ( j ava. l ang. Cl ass)
*/
@Suppr essWar ni ngs(" unchecked" )
@Over r i de
publ i c Obj ect get Adapt er (Cl ass adapt er )
{
return null;
}

/ **
* Get s t he val ue of f i el d " t est Case" .
*
* @return Ret ur ns t he val ue of f i el d " t est Case" .
*/
publ i c TAFTest Case get Test Case()
{
70

return t est Case;
}

/ **
* Set s t he val ue of f i el d " t est Case" .
*
* @param t est Case The val ue of f i el d " t est Case" t o set .
*/
publ i c voi d set Test Case(TAFTest Case t est Case)
{
}

/ *
* ( non- J avadoc)
* @see j ava. l ang. Obj ect #equal s( j ava. l ang. Obj ect )
*/
@Over r i de
publ i c bool ean equal s(Obj ect obj )
{
bool ean r es = false;

if (obj instanceof TAFTest CaseEdi t or I nput )
{
r es = t est Case.get Name().equal s(
((TAFTest CaseEdi t or I nput ) obj ).get Test Case().get Name());
}

return r es;
}

/ *
* ( non- J avadoc)
* @see j ava. l ang. Obj ect #hashCode( )
*/
@Over r i de
publ i c i nt hashCode()
{
return t est Case.get Name().hashCode();
}

}

71

Apndice B Artigo

de criao e execuo de testes automatizados
para telefones celulares
Thiago S. Veronese
Departamento de Informtica e Estatstica Universidade Federal de Santa Catarina
Florianpolis SC Brasil
t ver onese@i nf . uf sc. br
Abstract. Today in the software market due to many factors, including the
rising competition, shipping the product as soon as possible has become
crucial to the survival of the company. This way the possibility of automating
product testing is raised. Taking this into consideration, this paper describes
the study and improvement of an exploratory test case automation tool for cell
phone testing, through a test automation framework, in order to make its test
cases more portable. Another improvement is making the creation of such tests
simpler, eliminating the need of much technical knowledge, lowering software
testing costs.
Resumo. Atualmente no mercado de software devido a diversos fatores,
incluindo a crescente competio, o lanamento do produto o mais cedo
possvel no mercado torna-se crucial para a sobrevivncia da empresa. Desta
forma levantada a questo da automatizao de testes de produtos. nesse
contexto que este artigo descreve o estudo e aprimoramento de uma
ferramenta de criao e execuo de testes automatizados para telefones
celulares, por meio de um framework de automao de testes, a fim de tornar
seus casos de teste mais portveis. Outro aprimoramento tornar a criao
de tais testes mais simples, eliminando a necessidade de vrios conhecimentos
tcnicos, diminuindo assim os custos de teste de software.
1. Introduo
Com base na situao atual do mercado de software, onde evidente uma crescente
necessidade de garantia de qualidade, o teste de software ganha maior importncia
tendo em vista a diminuio de bugs e falhas nos produtos. Isto somado necessidade
de atingir o mercado rapidamente leva questo da automatizao de testes de
produtos, tentando diminuir o ciclo de desenvolvimento de softwares.
Tendo em vista que a automatizao de testes um caminho para a reduo de
custos na fase de testes da produo de um software, e tendo por base o contexto de
testes exploratrios, que se deseja com este artigo estudar uma ferramenta que
automatiza a execuo de tais testes, analisando suas vantagens e desvantagens em
relao ao mtodo tradicional. A partir disso, propor uma soluo para sua principal
desvantagem, que a baixa portabilidade dos casos de teste criados pela mesma.
Este artigo est organizado da seguinte maneira: as sees 2 e 3 apresentam a
fundamentao terica; uma comparao das modalidades de teste de software

descrita na seo 4; os aprimoramentos da ferramenta e resultados so apresentados na
seo 5 e finalmente as concluses so apresentadas na seo 6.
2. Teste de Software
Teste de software uma investigao tcnica emprica conduzida para prover os
clientes com informaes sobre a qualidade do produto ou servio em teste [KANER
2006]. Desta forma, o teste de software uma comparao entre o estado e o
comportamento de um software e a sua especificao de requisitos, que podem ser
definidos pelo usurio (teste de validao) ou pelas especificaes do sistema (teste de
verificao).
O teste para verificar se o software est realmente de acordo com suas
especificaes, s pode ser considerado bem sucedido caso no sejam encontradas
falhas durante sua execuo. Isso acaba indo de encontro com uma famosa citao do
cientista de computao Edsger Dijkstra: teste de software pode ser apenas usado para
mostrar a presena de bugs, mas nunca sua ausncia, fazendo uma aluso ao fato de
que testar completamente invivel em sistemas reais [Petroski 2006].
2.1. Casos e sutes de teste
Um caso de teste um conjunto de condies ou variveis sob as quais um testador
determina se um requisito ou caso de uso de uma aplicao parcialmente ou
totalmente satisfeito, sendo essencialmente constitudo por uma srie de passos e seus
resultados esperados [Petroski 2006].
Uma sute de testes nada mais que um agrupamento de casos de teste que
possuem caractersticas ou objetivos em comum, podendo conter tambm instrues
detalhadas ou metas para cada coleo de testes e informao sobre o sistema a ser
usado durante o teste.
2.2. Teste exploratrio
uma tcnica de teste onde se realiza uma busca ttica por faltas e defeitos no software
testado dirigida por suposies desafiadoras. Essa abordagem de testes normalmente
envolve execuo, aprendizado e projeto de novos testes como atividades que interagem
entre si, tudo ocorrendo simultaneamente [Tinkham e Kaner 2003].
No existe uma seqncia de passos pr-definida a ser seguida, mas o testador
que decide o que vai ser verificado, investigando a correo do resultado criticamente,
ou seja, tambm no h um resultado esperado j definido. A principal vantagem desse
tipo de teste que uma menor preparao necessria e defeitos importantes so
encontrados rapidamente.
2.3. Testes record/playback
Esta modalidade de teste de software pode ser inserida em um contexto que se encaixa
entre o teste totalmente exploratrio e o teste automatizado. Isso acontece devido ao
fato de ser apenas uma gravao (record) de passos de teste e conseqente execuo
(playback) de tais passos gravados.
Desta forma, percebe-se que o objetivo desta modalidade automatizar a
seqncia de aes do testador, reproduzindo-a automaticamente conforme a execuo

original. Porm essa tcnica leva a uma baixa reutilizao de seus casos de teste,
restringindo sua abrangncia em relao ao produto testado.
2.3. Teste automatizado
Recentemente, com o avano das tcnicas de programao, h uma cada vez maior
quantidade de cdigo a ser testado em um tempo cada vez menor, acabando por gerar
atrasos na entrega de softwares devido ao grande tempo despendido em testes.
Devido a tal fato, a automao de testes vem sendo utilizada como uma forma
para evitar esse problema, com a substituio parcial dos testes manuais, diminuindo os
custos de produo do software, atravs da agilidade que os testes automatizados
proporcionam.
Porm existem alguns problemas nesta abordagem, j que o custo inicial alto,
tornando o custo-benefcio favorvel somente em longo prazo. Podem-se perder
tambm as vantagens dos testes manuais se estes forem totalmente erradicados, o que
no indicado, pois ambos so complementares [Ramler 2006].
3. TAF e TAFStudio
Nesta seo feito um detalhamento sobre a ferramenta e framework nos quais se
baseia este artigo. Cada software apresenta uma abordagem diferente para a automao
de casos de teste, sendo ento o objetivo analisar as vantagens e desvantagens de cada
uma e propor solues para os problemas encontrados, visando um possvel ganho de
desempenho e reduo de custos no teste de software.
3.1 Test Automation Framework
O Test Automation Framework (TAF) um framework projetado para suportar a
automao de testes funcionais dos softwares embutidos em telefones celulares
produzidos e desenvolvidos pela Motorola Industrial Ltda [KAWAKAMI et al. 2007].
O TAF foi concebido e desenvolvido tendo em mente a idia da reutilizao de
casos de teste em vrios modelos diferentes de telefone, pois foi observado que muitas
das funcionalidades dos telefones so implementadas em diversos modelos.
Para a realizao da comunicao com o telefone, o TAF utiliza o Phone Test
Framework (PTF). O PTF prov uma API (Application Programming Interface) que
permite ao usurio simular eventos de entrada/sada do telefone, como pressionamento
de teclas e captura de tela [Esipchuk e Validov 2006].
3.1.1 Arquitetura
Para poder obter uma viso de mais alto nvel o TAF usa as chamadas Utility Functions
(UFs), que so implementaes de um passo de alto nvel, isolando hierarquicamente a
funcionalidade da implementao, levando a casos de teste automatizados de alto nvel
[Rechia et al. 2007].
Sendo assim os casos de teste automatizados so escritos em termos de UFs de
alto nvel de abstrao, promovendo a reutilizao de cdigo. Para se portar um caso de
teste j existente para outro modelo de telefone ocorre a reutilizao de cdigo, caso a

implementao de uma UF no funcione neste modelo, simplesmente necessria a
criao de uma implementao especfica.
3.2. TAFStudio
O TAFStudio um software projetado para gerar e executar testes exploratrios
automatizados destinados a testar os softwares embutidos em telefones celulares
produzidos e desenvolvidos pela Motorola. A modalidade de testes empregada a
record/playback, assim a criao de um teste feita a partir do armazenamento de todos
os eventos produzidos pelas aes do testador no telefone celular durante uma sesso de
testes, sendo os principais eventos o pressionamento de teclas e a captura de telas do
telefone.
Com estes registros armazenados e tendo em mente pontos chave de um teste
exploratrio, o usurio pode estabelecer pontos de checagem (em ingls, checkpoints)
atravs da seleo de itens que devem ser checados, durante a execuo do teste, nas
telas de telefones celulares.
3.2.1 Arquitetura
Considerando que, a funo do TAFStudio armazenar uma sesso de teste
exploratrio para futura reproduo, dois eventos podem ser considerados
fundamentais, so eles os pressionamentos de tecla e as telas capturadas do telefone.
Para uma melhor compreenso e organizao, tais eventos foram definidos como passos
de um caso de teste.
Sendo assim, os casos de teste do TAFStudio so definidos por passos tal como
no TAF, porm tais passos possuem uma viso de baixo nvel, por serem simples
representaes de eventos ocorridos no telefone. Essa viso leva a uma baixa
reutilizao, devido principalmente s diferenas existentes entre cada plataforma de
telefones celulares.
4. Comparao de Esforos das Diferentes Modalidades de Teste
Nesta seo estabelecida uma comparao entre ambas as modalidades automatizadas
(record/playback e automatizada) e a abordagem totalmente manual (teste exploratrio),
a fim de encontrar a quais situaes cada uma se mostra mais eficiente.
4.1. Uma sute de testes fictcia e a mtrica de comparao
A fim de estabelecer uma comparao entre as modalidades de teste, foi proposta uma
sute de testes fictcia que se aproximasse o mximo possvel do caso real, testando
diferentes funcionalidades dos telefones.
Para se aferir a viabilidade econmica de cada modalidade de testes, a mtrica
considerada foi a quantidade de esforo humano que deve despendida para a execuo
completa de uma sute de testes. Essa mtrica dada em nmero de horas de trabalho
executado por um testador, sendo vlida para este contexto por no apresentar
problemas inerentes a nenhuma das metodologias de teste.

Diferentes fatores afetam o esforo necessrio por cada modalidade para a
criao e execuo dos casos de teste. Tal descrio como segue:
Exploratrio: no h esforo para criar o caso de teste, simplesmente h o
esforo realmente manual do engenheiro de testes em executar cada um dos
casos de teste diretamente no telefone;
Record/playback: neste caso s existe esforo humano para a criao dos casos
de teste na ferramenta TAFStudio, sendo que para executar tais testes o esforo
pode ser considerado desprezvel, pois a mesma ocorre de forma automatizada;
Automatizado: aqui existe o esforo humano para a criao do caso de teste
utilizando linguagem de programao, porm o maior esforo concentra-se no
porte das UFs utilizadas. Assim o esforo total a soma dessas duas atividades.
Para se obter o esforo necessrio em cada modalidade foram realizados ensaios
para cada caso de teste. Para a modalidade exploratria os ensaios foram executados
manualmente, e na modalidade record/playback foi utilizado o TAFStudio. Os valores
obtidos dos ensaios para estas duas modalidades podem ser vistos na Tabela 1. J para o
terceiro caso (testes automatizados com TAF), foram criados os scripts dos casos de
teste para obteno do tempo mdio de criao, e, para a obteno do esforo mdio
aproximado para o porte das UFs, foram utilizados dados histricos de casos reais.
Tabela 1. Resultados do ensaio dos casos de teste
Exploratria Record/Playback
Caso de teste 1 60 segundos 7 minutos
Mdia 1 minuto 6 minutos
Os dados histricos obtidos foram ento normalizados para o caso dos testes
fictcios, resultando em 36 (trinta e seis) minutos para cada caso de teste.
4.2. Comparando as trs modalidades
Como as variveis que influenciam no esforo so em nmero de trs (nmero de casos
de teste, de telefones e de execues), sero feitas trs abordagens diferentes para a
avaliao do desempenho de cada modalidade de testes. Em cada abordagem sero
mantidas duas variveis com valor constante enquanto a outra varia. O esforo
resultante da combinao dos valores para cada modalidade de testes calculado
seguindo-se os fatores que afetam o esforo necessrio em cada modalidade.
O objetivo desta anlise ento, avaliar por quais valores cada modalidade
mais afetada e qual tem um melhor desempenho. Isso feito pois podem existir sutes
de teste onde uma das variveis tem maior valor que a outra, influenciando com maior
intensidade o esforo necessrio a uma certa modalidade.
No primeiro caso variou-se o nmero de execues, mantendo-se fixos os outros
dois valores. O resultado pode ser visto no grfico da Figura 1, onde o eixo x mostra o
nmero de execues e o eixo y o esforo humano. Ao se analisar o grfico pode se
constatar facilmente que o impacto do nmero de execues recai fortemente sobre a

modalidade exploratria. O mesmo no acontece para as outras duas modalidades, pois
aqui o esforo necessrio para executar um caso de teste foi considerado desprezvel,
havendo somente ento o esforo inicial para a criao dos casos de teste.

Figura 1. Grfico do Nmero de execues x Esforo
O resultado do segundo caso pode ser visto no grfico da Figura 2, onde se
observa a superioridade da abordagem automatizada para este caso, pois a mesma no
afetada pela quantidade de telefones a que se destina a sute de testes, devido ao reuso
de software, mantendo novamente valor constante por todo o eixo x.

Figura 2. Grfico do Nmero de telefones x Esforo
No ltimo caso considera-se a variao de nmeros de casos de teste, o grfico
resultante pode ser visto na Figura 3. Nesse caso pode ser visto com clareza o impacto
que o nmero de casos de teste tem sobre a abordagem automatizada, por ter seu
esforo baseado fortemente no porte das UFs para cada caso de teste.
Finalmente avaliando de uma forma geral todos os casos expostos, chega-se
concluso de que a escolha de uma modalidade de teste de software depende muito do
contexto em que deve ser aplicado, ou seja, a escolha deve se basear nas vantagens e
desvantagens apresentadas por cada modalidade e nas variveis que mais as afetam, o
que dependente da sute de testes em questo.
Porm a modalidade automatizada apresenta um bom desempenho quando se
trata de casos de longo prazo, o que torna a idia de adicion-la ao TAFStudio
interessante, sendo este o tema da prxima seo.

Figura 3. Grfico do Nmero de casos de teste x Esforo
5. Aprimoramentos do TAFStudio
A modalidade de testes record/playback empregada pelo TAFStudio apresenta alguns
problemas inerentes sua metodologia, os quais acabam tornando sua aplicao restrita.
A seguir sero caracterizados estes problemas e em seguida proposta uma soluo para
os mesmos.
5.1. Caracterizao do problema e soluo
O principal problema da modalidade de testes record/playback em relao
baixssima reutilizao dos casos de teste que so gerados, devido aos passos de teste
apresentarem um nvel de abstrao muito baixo. Assim a soluo bvia para este
problema aumentar o nvel de abstrao de tais passos de teste. Para isso ento foi
proposta a utilizao do framework TAF, por apresentar um alto nvel de abstrao dos
testes, provido pelo uso das UFs descritas anteriormente.
Porm o TAF apresenta um problema de longa data relacionado dificuldade da
criao dos casos de teste, imposta pela necessidade do conhecimento de uma variada
gama de ferramentas e de programao. A soluo foi utilizar a abordagem visual de
criao de testes do TAFStudio, provendo um meio simples de criao dos casos de
teste automatizados.
5.2. Implementao do acoplamento entre TAF e TAFStudio
Para o acoplamento do framework TAF ferramenta utilizou-se a noo de plug-ins j
existente no TAFStudio, permitindo um baixo acoplamento. Chegou-se ento ao
diagrama de classes exposto na Figura 4, onde so mostradas as classes responsveis
pela criao e execuo dos casos de teste.
Foram criadas classes para representar um caso de teste automatizado
(TAFTestCase), um passo de teste (TAFTestCaseStep), executar um caso de teste
(TAFTestCaseRunner) e, para se evitar uma complexidade muito grande, foram
mapeadas somente algumas UFs no enum TAFUtilityFunction, utilizando as mesmas
apenas como prova de conceito.
Foi concebida tambm uma interface grfica para fcil criao dos casos de
teste, apenas construindo a lista de passos de teste partir das UFs disponveis.

Figura 4. Diagrama de classes proposto para o acoplamento TAFStudio+TAF
5.3. Resultados do aprimoramento
Com os aprimoramentos implementados foi possvel criar casos de teste complexos e
altamente portveis utilizando somente a nova interface grfica. Isso acabou por
eliminar a necessidade dos variados conhecimentos tcnicos por parte do engenheiro de
testes, ficando restrito somente ao programador que ir realizar o porte das UFs.
Ao se utilizar a ferramenta para a criao e execuo dos testes da sute fictcia
exposta anteriormente, no se observou um ganho significativo em relao ao esforo
exigido, porm neste caso o ganho reside na reduo da complexidade da criao e
execuo dos testes, onde no mais necessrio ter custos para o treinamento de
engenheiros de teste para realizar tal tarefa.
6. Concluses
Teste de software uma atividade crucial no atual processo de desenvolvimento de
softwares de alta qualidade. Tambm contribui com uma grande parcela do custo total
do desenvolvimento de software freqentemente cerca de 50% [Chernonozhkin 2001].
Existem diferentes modalidades de execuo de casos de teste, sendo a manual a
mais difundida pela sua simplicidade, porm ela pode tornar-se suscetvel a erros e
altamente custosa. Neste contexto que entra a ferramenta TAFStudio para a gerao
de casos de teste automatizados atravs da gravao e repetio de passos, evitando a
necessidade de maiores custos com a execuo de tais testes. Porm essa tcnica possui
uma grande limitao devido a portabilidade muito baixa dos casos de teste.
Ento foram realizadas medies de esforo para cada modalidade disponvel,
para verificar a viabilidade de cada uma em diferentes sutes de teste de software,
resultando em um bom desempenho em longo prazo da abordagem automatizada
provida pelo framework de testes de software TAF. Este bom desempenho apresentado,
quando aplicado ao caso real de testes de telefones celulares, diminuir o ciclo de

desenvolvimento de software, diminuindo o custo com o desenvolvimento do mesmo e,
conseqentemente, o tempo necessrio para lanar o produto no mercado.
Tendo em vista a soluo do problema da portabilidade dos casos de teste que
se recorreu ao framework TAF. Este framework baseia-se fortemente sobre o princpio
da reutilizao de software para a criao dos casos de teste, porm sua utilizao
restrita devido ao alto grau de conhecimento exigido. Sendo assim a proposta desse
trabalho foi aprimorar a ferramenta TAFStudio para que pudessem ser criados casos de
teste altamente portveis utilizando o TAF para tal, e com a facilidade provida por uma
interface simples e intuitiva com o usurio. Isto se demonstrou muito interessante por
permitir um ganho real na reduo da complexidade, onde agora qualquer usurio pode
criar casos de teste complexos, sendo que o conhecimento de linguagens de
programao e de ferramentas especficas como antes era exigido ficou restrito somente
ao programador que ir realizar o porte das UFs.
Referncias
British Computer Society Specialist Interest Group in Software Testing (2001).
Standard for Software Component Testing. Working Draft 3.4.
P. Bourque et al. (2001). Guide to the software engineering body of knowledge. Los
Alamitos, CA, USA: IEEE Computer Society Press, 2001. Dsponivel em:
<http://www.swebok.org/ironman/pdf/SWEBOK_Guide_2004.pdf>. Acesso em
2008.
S. Chernonozhkin (2001). Automated test generation and static analysis. Programming
and Computer Software, v. 27, n. 2, p. 86-84.
E. Dustin; J . Rashka; J . Paul (1999). Automated Software Testing. Addison-Wesley
Professional.
S. Eldth et al. (2007). Component Testing Is Not Enough A Study of Software Faults
In Telecom Middleware. In: TestCom/FATES 2007. Tallin, Estonia.
Eclipsepedia (2009). Rich Client Platform. Disponvel em:
<http://wiki.eclipse.org/index.php/Rich_Client_Platform>. Acesso em: 5 Maio 2009.
I. Epsichuk; D. Validov (2006). Ptf-based test automation for java applications on
mobile phones. In: IEEE 10
th
International Symposium on Consumer Electronics.
p. 1 3.
Cem Kaner (2006). Exploratory Testing. In: Quality Assurance Institute Worldwide
Annual Software Testing Conference. Orlando, FL, USA.
Luiz Kawakami et al (2007). A test automation framework for mobile phones. In:
VIII IEEE Latin-American Test WorkShop.
M. Newman (2002). Software Errors Cost U.S. Economy $59.5 Billion Annually.
Disponvel em: <http://www.nist.gov/public_affairs/releases/n02-10.htm>. Acesso
em: 25 junho 2008.
N. Parekh (2005). White box testing strategy. Dsponivel em:
<http://www.buzzle.com/editorials/4-10-2005-68350.asp>. Acesso em: 26 agosto
2008.

Bruno Petroski (2006). Gerao automtica de casos de teste automatizados no
contexto de uma sute de testes em telefones celulares. Trabalho de Concluso de
Curso. Universidade Federal de Santa Catarina. Florianpolis.
R. Ramler e K. Wolfmaier (2006). Economic Perspectives in Test Automation:
Balancing Automated and Manual Testing with Opportunity Cost. In: Proc.
International Workshop on Automation of Software Test. Shanghai, China.
Douglas Rechia et al. (2007). An Object-Oriented Framework for Improving Software
Reuse on Automated Testing of Mobile Phones. In: TestCom/FATES 2007. Tallin,
Estonia.
J . Sobel e D. Friedman (1996). An Introduction to Reflection-Oriented Programming.
Andy Tinkham e Cem Kaner (2003). Learning Styles and Exploratory Testing. In:
Pacific Northwest Software Quality Conference.

Análise e Aprimoramento de Uma Ferramentade Criação e Execução de Testesautomatizados para Telefones Celulares

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Análise e Aprimoramento de Uma Ferramentade Criação e Execução de Testesautomatizados para Telefones Celulares

Enviado por

Direitos autorais:

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CENTRO TECNOLGICO - CTC

Você também pode gostar