Quali Rafael Oraculos

Apoio à automatização de oráculos de teste para
programas com interfaces gráficas
Rafael Alves Paes de Oliveira

SERVIÇO DE PÓS-GRADUAÇÃO DO ICMC-USP
Data de Depósito: 22 de dezembro de 2009
Assinatura:
Apoio à automatização de oráculos de teste para programas com

interfaces gráficas
Rafael Alves Paes de Oliveira
Orientador: Prof. Dr. Márcio Eduardo Delamaro
Monografia apresentada ao Instituto de Ciências Mate-

máticas e de Computação — ICMC — da Universidade
de São Paulo, para o Exame de Qualificação, como parte
dos requisitos para obtenção do tı́tulo de Mestre em Ci-
ências de Computação e Matemática Computacional.
USP - São Carlos

Dezembro/2009
Resumo
Oráculos de Teste são um dos desafios a serem enfrentados no que se

refere à automatização de teste de software. Ao contrário do teste
manual, revendo os resultados para determinar se ou não resultado
é o que deveria ser esperado, métodos automáticos só dependem de
regras de decisão especificadas. Definir um oráculo implica sintetizar
uma estrutura formal, ou até mesmo informal, automatizada, que
seja capaz de oferecer um veredicto indicativo da exatidão de uma
execução do sistema ao final das aplicações do teste. Pode ser dito
que oráculo é o mecanismo que define e dá um veredicto acerca da
correção de uma execução de um programa em teste. Para alguns
tipos de aplicação o teste manual é impraticável, entretanto testado-
res muitas vezes não contam com mecanismos de teste automatizado
competentes para a realização de tal tarefa. Nesse sentido os oráculos
automatizados são valorizados.
O interesse da indústria de software por questões de qualidade
é crescente. A aplicação de técnicas e critérios de teste de software
adequados, durante todas as fases do processo de desenvolvimento,
implica em aumento de custo para seu desenvolvedor. No entanto,
pode haver uma economia significativa quando testes são aplicados
de maneira automatizada e sistemática. Automatizar mecanismos
de teste não é um trabalho trivial. Uma negligência, muitas vezes,
pode remeter à produção de software de má qualidade. Buscando
contribuir com esta área da engenharia de software este trabalho
apresenta a proposta de uma abordagem que utiliza o conceito de
CBIR para configurar um ambiente de apoio ao teste de programas
com interfaces gráficas de usuários (GUIs) por meio da automatização
de mecanismos de oráculo. O princı́pio dos sistemas que utilizam
CBIR é pesquisar em base de imagens uma determinada quantidade
de imagens similares a uma imagem de consulta, de acordo com um
ou mais critérios fornecidos. Os critérios de similaridade de imagens
são obtidos a partir da extração de caracterı́sticas de imagem como
cor, textura e forma.
i
Sumário
1 Introdução 1
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Oráculos de Teste 6
2.1 Oráculos de Teste: Definições e Conceitos . . . . . . . . . . . . . . . . . . . 7
2.1.1 Taxonomia de Oráculos . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1.1 Oráculo Humano . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Dificuldade na Implementação de Mecanismos de oráculos . . . . . 14
2.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Revisão Bibliográfica Sistemática 19

3.1 Planejamento e Condução . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Análise de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Oráculos de Teste para GUI . . . . . . . . . . . . . . . . . . . . . . 23
4 CBIR no Apoio a Oráculos de Teste 28

4.1 CBIR - Content Based Image Retrieval . . . . . . . . . . . . . . . . . . . . 29
4.1.1 Etapas CBIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1.1 Extratores de Caracterı́sticas . . . . . . . . . . . . . . . . 31
4.1.1.2 Funções de distância ou similaridade . . . . . . . . . . . . 33
4.1.1.3 Estruturas de Indexação . . . . . . . . . . . . . . . . . . . 33
4.2 CBIR como apoio à automatização de Oráculos para programas com saı́da
Gráfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 Núcleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Gerador de Descritores de Oráculos Gráficos . . . . . . . . . . . . . 40
ii
5 Proposta de Trabalho 42
5.1 Proposta de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Objetivos do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 Atividades requisitadas pelo Programa de Pós-Graduação . . . . . . 44
5.2.2 Atividades Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.3 Cronograma de Atividades . . . . . . . . . . . . . . . . . . . . . . . 46
Referências Bibliográficas 54
iii
Lista de Figuras
5.1 Cronograma de execução. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
iv
Lista de Tabelas
2.1 Oráculos por sua Forma de Automatização . . . . . . . . . . . . . . . . . . 13
3.1 Seleção Final de artigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
v
Capı́tulo
1
Introdução
1.1 Contextualização
Software de alta qualidade é uma meta desejada por muitos desenvolvedores, por isso, eles
têm desprendido muita atenção com questões de validação, verificação e, em particular,
teste de software. Em consequência disso, pesquisadores têm concentrado esforços em
definições de técnicas, critérios e ferramentas que contribuam para que tais atividades
sejam executadas com uma maior qualidade e custo reduzido (Delamaro et al., 2007).
Em geral, o conjunto das atividades conhecidas como “V,V & T” (Verificação e Validação
e Teste de Software) caracteriza uma das atividades que mais retardam e encarecem o
processo de desenvolvimento de software, no entanto sua aplicação contribui para que
seja atingido um nı́vel adequado de qualidade dos produtos finais. Por isso, o teste de
software constitue uma área de pesquisa muito ativa e interessante da engenharia de
software, contribuindo para a garantia de que o sistema de software faz o que foi projetado
para fazer. Convencionalmente, o trabalho de teste é feito por testadores experientes em
processos de testes manuais. Trabalho exaustivo, executabilidade e escassez de tempo de
projeto são alguns dos fatores que levam pesquisas a questionarem a eficiência do teste.
A maneira como tudo isso poderia ser feito automaticamente sem interferência humana
tem sido foco debates em eventos cientı́ficos da área (Jin et al., 2008).
Nesse sentido, a automatização da atividade de teste desempenha papel fundamental,
contribuindo para a o aumento da produtividade e caracterizando a forma mais popular
1
CAPÍTULO 1. INTRODUÇÃO
para reduzir os custos do teste de software. Em linhas gerais, a automatização do teste

é o processo que busca a substituição dos esforços manuais para o teste de um sistema.
Muitas vezes são incluı́dos recursos para a geração de entradas e resultados esperados,
de modo que sejam executados diversos testes sem intervenções manuais e avaliações de
resultados (Binder, 1999). Uma questão básica do teste automatizado é o veredicto a
respeito do comportamento correto ou, não, de um programa com um determinado dado
de teste. Nem sempre é uma tarefa trivial determinar um conjunto de saı́das esperadas
para determinado teste. Um pressuposto fundamental do teste de software é que exista
um mecanismo capaz de determinar os resultados de uma execução. Na prática, isso é
feito muitas vezes comparando a saı́da, automaticamente ou manualmente, para algumas
entradas que tenham saı́das pré-caculadas de algum modo e, presumivelmente, estejam
corretas. Sendo assim, a automação completa do processo de teste, portanto, requer um
mecanismo que tenha a capacidade de fornecer resultados de referência para todos os
dados de entrada possı́veis - em suma, exige um oráculo que é funcionalmente equivalente
ao sistema em si (Hummel e Atkinson, 2005).
A geração automática de entradas de teste, dependendo do domı́nio de entrada, pode
ser uma tarefa relativamente trivial, no entanto, gerar os resultados esperados é uma
tarefa que invariavelmente exige esforços. Não se pode esperar para executar testes au-
tomatizados sem os resultados esperados. No contexto de teste, um oráculo é uma fonte
confiável a respeito dos resultados esperados. Um oráculo é o mecanismo que se utiliza
para definir a saı́da ou comportamento é o correto em uma determinada execução (Hoff-
man, 2001). Todo método de teste de software é dependente da avaliação de um oráculo.
Uma especificação formal, um programa ou, simplesmente o conhecimento do programa-
dor de como determinada aplicação, podem ser considerados mecanismos de oráculos em
um determinado ambiente de teste.
Um fator complicador da automatização de oráculos e, consequentemente, do teste de
software é quando a saı́da de uma aplicação em teste se encontra em um formato não tri-
vial como, por exemplo, a tela de uma interface gráfica ou, então, uma imagem processada
qualquer, configura um cenário delicado para a automatização de mecanismos de oráculo.
Avaliar o comportamento destas aplicações requer esforços significativos. Técnicas espe-
cı́ficas devem ser desenvolvidas para tal, e constituem, exatamente o tema central desse
trabalho que busca colaborar com esse tópico da engenharia de software por meio de téc-
nicas de Recuperação de Imagem Baseada em Conteúdo (do inglês: Content-Based Image
Retrieval ) para permitir que oráculos de teste para interfaces GUI (do inglês: Graphical
User Interface) sejam definidos de forma flexı́vel. Nesse contexto, componentes gráficos,
que têm o acerto como caracterı́stica fundamental, são considerados como aplicações cujo
formato não é trivial para o teste e, ainda assim, são cruciais em diversas aplicações da
2
vida real. Exemplos disso são as imagens médicas, gráficos baseados em entretenimento
e interfaces GUI.
1.2 Motivação
É crescente o número de setores sociais diretamente envolvidos, ou até controlados, por
sistemas computacionais. Os sistemas de software desenvolvidos hoje atingem, direta ou
indiretamente, milhões de pessoas. Diante disso a responsabilidade em escrever programas
corretos é evidente, haja vista que importantes funções e tarefas são atribuı́das a eles
(Myers e Sandler, 2004). Contudo, paradigmas intermediadores capazes de providenciar
suporte para o teste pouco evoluı́ram ao longo dos últimos anos e continuam a ser um
dos elementos mais caros da engenharia de software (Hummel e Atkinson, 2005). O
surgimento de diferentes linguagens de programação elevou a capacidade do ser humano
em termos de desenvolvimento de software. A complexidade dos sistemas requeridos
cresceu proporcionalmente a essa capacidade humana (Sommerville, 1995). Nesse sentido,
são valorizados os esforços que configuram contribuições para a qualidade dos sistemas de
software antes de sua liberação para uso.
Uma GUI é caracterizada por ser o meio que permite a interação com dispositivos
digitais por meio de elementos gráficos como ı́cones e outros indicadores visuais que con-
trastam com a interface de linha de comando fornecendo conforto e facilidade aos usuários
finais dos sistemas de software (Fischer et al., 2009). Sendo assim, GUIs configuram um
ambiente rico em recursos para várias aplicações e, a partir delas, os usuários podem fa-
cilmente trabalhar com vários aplicativos simultaneamente, sendo capazes de organizar e
organizar as janelas de aplicativos na tela de plataformas computacionais e computadores.
Os usuários podem clicar em sites da Web, copiar e colar dados de uma aplicação para
outra, e adaptar a aparência de seus desktop da forma que lhe for conveniente. Embaladas
pela evolução das linguagens de programação e dos sistemas computacionais, as interfaces
GUI são muito comuns em diversas áreas de conhecimento. Exemplos evidentes são dis-
positivos móveis como PDA’s (Personal Digital Assistant) e Smartphones que ganharam
muito conforto com interfaces sensı́veis ao toque, auto-explicativas e atrativas.
GUIs configuram o método de interface humano-computador mais popular. Em siste-
mas complexos, as GUIs chegam a representar 60% do código das aplicações. Uma abor-
dagem popular para o desenvolvimento de GUIs é uso de algum editor WYSIWYG (What
You See Is What You Get), comumente denominados editores GUI (Jigloo SWT/Swing
GUI Editor for Eclipse and WebSphere, 2009; M. Stuart., 2009; Swing Designer v7.2.0,
2009; Visual Editor V1.2, 2009). Em geral, editores GUI usam uma visão estática da
interface gráfica, chamada de exibição de design, para apoiar seu desenvolvimento (Li e
3
Wohlstadter, 2008). Apesar da crescente das ferramentas de apoio ao desenvolvimento

GUI, essa modalidade de interface constitue um sistema de software como qualquer outro
e, por isso, está sujeita a erros. Falhas ou erros na concepção destas interfaces podem
significar um custo elevado para empresas que utilizam o software. Em um ambiente de
teste para GUIs sempre é necessário gerar saı́das esperadas que possibilitem uma compa-
ração com as saı́das obtidas. Nesse contexto, mecanismos de oráculos configuram a fonte
mais segura e fiel sobre os resultados esperados de um determinado teste (Oliveira et al.,
2009b).
Infelizmente, os recursos de engenharia reversa para interfaces GUI, implementadas
manualmente ou com o auxı́lio de editores, são severamente limitados (Li e Wohlstadter,
2008). Isso ocorre porque as aplicações completas consistem no design de interface do
usuário e na colaboração dinâmica entre os objetos que implementam a essência do com-
portamento do sistema de software, ou seja, tudo o que o programa é capaz de fazer a
partir da interface GUI. Essas duas partes do programa configuram um sistema completo e
podem ser emaranhadas em conjunto de outras funcionalidades na implementação do sis-
tema de software. Assegurar uma separação completa do código entre design da interface
GUI e comportamento do programa exigiria um esforço significativo de desenvolvedores.
Diante disso, nota-se um gap de engenharia de software relacionado ao teste GUI.
Quanto mais se tem escrito sobre as provas de correção de programas de diversas áreas
de confiabilidade de software, o estado da arte continua a não satisfazer as necessidades
de validação de sistemas com interfaces GUI. É senso comum entre os desenvolvedores
que tais sistemas devem fornecer alto grau de confiança a seus usuário finais, para tanto,
é necessário que sejam implantadas técnicas de teste de software em seu processo de
desenvolvimento. Nesse contexto, uma negligência, muitas vezes, pode remeter à produção
de software de má qualidade (Oliveira et al., 2009a). A pesquisa nesta área se justifica, pois
a indústria está pedindo muito mais garantias de qualidade de software. A questão-chave
após a incorporação de uma ou todas as estratégias de teste é: como saber realmente o
que o software é confiável?
1.3 Objetivos
A meta principal desta monografia é apresentar a proposta de um projeto de mestrado
que dá continuidade a trabalhos anteriores realizados no grupo de pesquisa de Engenha-
ria de Software do ICMC/USP. A proposta é um dos trabalhos previstos pelo projeto
de pesquisa intitulado “Definição de oráculos de teste para programas com saı́da gráfica
usando recuperação baseada em conteúdo” financiado pelo Conselho Nacional de Desen-
volvimento Cientı́fico e Tecnológico (CNPQ) sob o processo 551002/2007-7. O referido
4
procura utilizar técnicas de CBIR para permitir que oráculos de teste, capazes de apoiar
o teste de sistemas de software com saı́das gráficas ou, interfaces GUI, sejam definidos
de forma flexı́vel. Dentro do cenário apontado, considerando o custo e a dificuldade ine-
rentes, pode-se afirmar que a automatização é um ponto essencial no aprimoramento da
qualidade e na diminuição do custo da atividade de teste. Assim, a contribuição deste
trabalho baseia-se na definição de técnicas e desenvolvimento de ferramentas que possi-
bilitem a automatização do mecanismo de oráculo, de vital importância no contexto de
teste de software.
Resumidamente, este trabalho tem como objetivo principal a exploração de um pro-
tótipo que emprega conceitos de CBIR para apoiar à criação de oráculos de teste, que
neste caso poderão ser chamados de “oráculos gráficos”, capazes de testar sistemas de
software com interfaces GUI. CBIR é uma técnica que, por meio de extratores de ca-
racterı́sticas de imagem e funções de similaridade, é capaz de recuperar imagens de um
banco de dados seguindo juı́zos de similaridade com uma imagem modelo. Diante disso,
o paradigma explorado deve fornecer meios para que o testador escolha as caracterı́s-
ticas a serem utilizadas, defina como as caracterı́sticas devem ser comparadas e possa
adicionar novas caracterı́sticas a serem comparadas pelo sistema. É importante salien-
tar que em trabalhos anteriores (Oliveira, 2008; Oliveira et al., 2009a) foi implementado
um núcleo responsável pelas tarefas comuns a qualquer tipo de caracterı́sticas e por uma
série de “módulos” organizados na forma de plugins, que se encarregam de implementar
o processamento necessário para cada tipo de caracterı́stica. Dessa forma, aumenta-se a
flexibilidade do oráculo e permite-se que novas caracterı́sticas possam der adicionadas de
maneira simples.
1.4 Organização
∙ Sistematização do plano geral do trabalho a ser escrito. Organização dos capı́tulos:
5
Capı́tulo
2
Oráculos de Teste
Considerações Iniciais
O processo de teste é, para a maioria dos sistemas em desenvolvimento, o meio mais
importante pelo qual uma aplicação é submetida para ter sua conformidade com especi-
ficações verificada (Hunter e Strooper, 2001). Uma verificação manual dos resultados de
execuções de teste é uma atividade demorada e, às vezes propensa a erros. Sendo assim,
diz-se que qualquer método ou técnica de teste de software depende da avaliação de um
oráculo de teste, isto é, algum método que seja capaz de julgar a corretitude do resultado
particular da execução de uma aplicação em teste (Baresi e Young, 2001). Nesse sentido,
um oráculo ideal deve prover meios para que uma execução seja classificada como bem su-
cedida ou falha. Em diversas pesquisas cujo o tema principal é o teste de software, sejam
elas uma abordagem acerca de novos métodos para a geração de casos de teste ou, então,
novos critérios de teste para diferentes domı́nios, a existência de um oráculo de teste deve
ser assumida explicita ou tacitamente. No entanto, muitas vezes as aplicabilidades dos
oráculos não são descritas nem exploradas (Oliveira et al., 2009b).
Teste de software é o processo de execução de programas com a intenção de encontrar
erros. A essência do teste de software é a de determinar um conjunto de casos de teste para
o software está sendo testado (Myers e Sandler, 2004). Uma das partes mais difı́ceis e caras
de testes é a geração de dados de teste, que tradicionalmente tem sido feito manualmente
(DeMillo e Offutt, 1991). À medida que cresce a complexidade das aplicações e, em
6
CAPÍTULO 2. ORÁCULOS DE TESTE
consequência, de seus processos de teste, aumenta a importância de se automatizarem

as atividades que contribuem para a qualidade dos sistemas em desenvolvimento. O
tema oráculos de teste se enquadra nesse escopo como um desafio bem conhecido pelos
pesquisadores que dedicam seus esforços a pesquisas sobre qualidade de desenvolvimento
de software. Sem meios capazes de computar automaticamente o resultado correto para
os casos de teste de determinado sistema, os testadores devem computar os resultados
manualmente ou, então, usar uma versão anterior da aplicação em teste. É sabido que
os materiais literários disponı́veis acerca de oráculos de teste são constituı́dos por uma
pequena porção das pesquisas cujo tema central é o teste de software. Esta seção busca
apresentar os principais conceitos encontrados na literatura sobre oráculos capazes de
apoiar o teste de diferentes domı́nios de aplicações.
2.1 Oráculos de Teste: Definições e Conceitos

O encarecimento e a complexidade das atividades de teste em um processo de desenvolvi-
mento de software se dão em função da grande dificuldade encontrada quando é buscada
uma definição precisa do modo de avaliar a qualidade de determinado processamento. Di-
ficuldade similar é encontrada na procura de um conjunto ideal de testes que seja completo
o bastante para revelar os mais diferentes defeitos (Delamaro et al., 2001). Nesse contexto
é inserido o conceito genérico de oráculo. O termo oráculo é originário da mitologia grega
e geralmente era conhecido por se tratar da resposta de um sacerdote ou divindade, ge-
ralmente subjetiva e obscura, dada a uma questão de um consulente qualquer (Cultural,
1998). Quando usado na área da Computação, mais precisamente na área de teste de
software, difere muito disso, sendo definido como mecanismo que se utiliza para definir a
saı́da ou comportamento esperado de uma execução qualquer (Hoffman, 2001).
Sabe-se que uma questão básica na atividade de teste é como decidir se o compor-
tamento de um programa qualquer P com um determinado dado de teste é correto ou
não. Nem sempre é uma tarefa trivial determinar um conjunto de saı́das esperadas O.
Considere-se, por exemplo, que o programa P deveria calcular o valor da constante E
com um número qualquer de casas decimais. A não ser que se suponha a existência de
um outro programa Q, correto, que execute a mesma funcionalidade, não se pode afirmar,
sempre, de maneira positiva, se o comportamento de P é o esperado ou não. Um outro
caso semelhante seria quando P é um programa não determinı́stico, em que P (ik) pode
corresponder a diversas saı́das possı́veis, todas elas corretas. Sendo assim, como já foi
introduzido, segundo Hoffman (2001) oráculo é o mecanismo que se utiliza para definir
a saı́da ou o comportamento esperado de uma execução de P está de acordo com o que
foi especificado, ou não. Em um outro ponto de vista, de acordo com (Howden, 1986),
7
oráculos são fontes externas de informações sobre as funções. O oráculo pode ser uma
especificação do programa, uma tabela de exemplos ou, simplesmente, o conhecimento do
programador de como um programa deve funcionar.
Nesse sentido, oráculos de teste devem ser uma parte integrante do processo de teste.
Para verificar a exatidão dos resultados, um oráculo deve saber quais são os resultados e
comportamentos esperados e ser capaz de apresentar os resultados da avaliação dos tes-
tes durante o teste de software. Testadores que seguem métodos sistemáticos, em geral,
devem fazer a seleção e execução de dados de teste de testes disponı́veis. O processo de
teste também inclui a criação do(s) oráculo(s), acompanhamento de execução dos testes,
e a verificação de resultados, embora esta, muitas vezes, seja feita de modo informal e im-
preciso. Com exceção dos testes que, obviamente, podem se exceder o tempo de execução
e não precisam de um oráculo, o valor de todos os outros testes dependem da presença de
resultados precisos para um veredicto acerca da corretitude de uma execução qualquer.
O esforço de instruções necessárias para gerar esses resultados de forma independente é
extremamente alta, e os erros nesses cálculos manuais invalidam a verificação. Reconhe-
cendo que tais esforços vão ser gastos, o pressuposto é haja um oráculo disponı́vel para
determinado teste. Se esta hipótese é falsa, então teste é de pouco valor (Brown et al.,
1992).
Um exemplo de aplicação são os testes funcionais que requerem um oráculo para de-
terminar a corretitude de seus casos de teste (Peters e Parnas, 1998). Resume-se que,
nesse caso, um oráculo de teste é um mecanismo para julgar se os resultados de determi-
nado caso de teste “passaram” ou “não passaram” em determinada execução da aplicação
em teste (Chan et al., 2006). Os custos desse tipo de teste, dependendo do domı́nio da
aplicação, não são baixos. Fazendo um estudo do montante de custo gerado a partir do
teste, Peters e Parnas (1998) observa que, em linhas gerais, despesas com pessoal são um
fator limitante. O mesmo autor ainda discutiu a necessidade de oráculos, afirmando que
os oráculos configuram fontes de preciosas informações sobre as funções em teste. Supos-
tamente, estes constituem as respostas corretas, sem dúvida contra as quais os resultados
dos testes podem ser medidos. Diante disso, infere-se que embora a automatização por
completa do teste de software seja um problema indecidı́vel, a parcial ou condicional au-
tomatização do teste é algo muito viável (Peters e Parnas, 1994). No que se refere à
automatização do teste de software, métodos de geração automática de oráculos de teste
é o primeiro de todos a considerar. Certamente, se testadores desejarem julgar a regulari-
dade de um programa, eles devem saber claramente quais os resultados esperados a cada
execução (Jin et al., 2008).
Infere-se que códigos de teste e oráculos para teste de integração constituem parte
da arquitetura geral do sistema. Oráculos para componentes e unidades individuais são
8
projetados e implementados por programadores usando ferramentas de anotação de có-

digo com condições invariantes. Diante dessa premissa, Andrews et al. (2002) têm uma
outra visão acerca de oráculos de teste, para eles esses mecanismos são configurados por
programas que verificam a saı́da de casos de teste executados em outros programas. Di-
ferente é a visão de Rapps e Weyuker (1985) que julgam o oráculo perfeito como sendo
algo equivalente à pedra filosofal para o software. Os referidos autores ainda afirma que
não se pode garantir a capacidade um algoritmo para decidir que um outro algoritmo
qualquer é correto para todos os casos possı́veis. Diante desse cenário introdutório, é pos-
sı́vel notar que pode haver uma variança muito grande de oráculos em função do domı́nio
das aplicações. Sendo assim, diferentes aspectos influenciam no modo de obtenção de um
oráculo para determinado sistema. As seções seguintes buscam apresentar as diferentes
taxonomias e as classificações de oráculos de teste encontradas na literatura.
2.1.1 Taxonomia de Oráculos

A automatização de um oráculo, mesmo quando se dispõe do conjunto de saı́das esperadas,
nem sempre é uma tarefa trivial. Muitas vezes é difı́cil decidir quais caracterı́sticas devem
ser consideradas para se comparar saı́das obtidas e saı́das esperadas. Um exemplo extremo
desse fato é quando se tem a saı́da esperada ok e um programa P executando um laço
infinito. Nesse caso, não se poderia, a princı́pio, apenas considerando ok, dizer que P difere
do comportamento esperado. Para isso, outros fatores deveriam ser levados em conta,
como, por exemplo, o tempo de execução de P e o tempo de execução do programa que
produziu ok, se for esse o caso. Tais classificações são explicitadas na seção seguinte. Outro
exemplo pode ser elucidado da seguinte maneira: Supondo que os resultados esperados
da execução de um programa devem situar-se no intervalo entre 22,5 e 23,5 e o resultado
de uma execução em teste é 1987. Claramente, esse erro pode ser facilmente detectado,
ou seja, o testador pode servir como oráculo. No entanto, e se o resultado da execução
está entre 22,5 e 23,5 ? Esta seria a resposta correta? Embora possa ser difı́cil determinar
se o resultado da execução é o correto, ele está próximo do correto. Nessas situações,
normalmente, o usuário-testador deve ser responsável por decidir se o resultado do teste
está correto ou não, dependendo dos resultados esperados. Os custos desse esforço estão
bem documentados.
Baseando-se nesses fatores, é possı́vel notar que há a possibilidade de existirem diversos
tipos de mecanismos de oráculos capazes de apoiar diferentes domı́nios de aplicações.
Oráculo é parte essencial do teste de software. Muitos trabalhos da área vêm para abordar
exatamente a subjetividade de se decidir sobre a correção, ou não, de um programa em
teste. Nesse sentido, alguns autores propuseram algumas classificações para oráculos de
teste. Hoffman e Strooper (1991) definem diversos tipos de oráculos de teste. Segundo os
9
autores, há uma divisão global comum entre os pesquisadores que dedicam esforços nesse
nicho de pesquisa. A referida divide os oráculos em:
∙ ativos: responsáveis por diretamente dirigir ou coordenar as atividades de testes.

Em geral, um oráculo ativo imita o comportamento do componente de software sob
teste. Sendo assim, oráculos ativos produzem um resultado esperado para uma en-
trada e usam uma comparação para verificar os resultados reais contra os resultados
esperados;
∙ passivos: oráculos menos complexos e que apenas recebem como entrada o par
comportamento desejado, comportamento produzido. Em outras palavras, um orá-
culo passivo é capaz apenas de verificar o comportamento de um componente, mas
não reproduzı́-lo. Nesse contexto, testes com oráculos passivos têm apenas um ele-
mento comparador que é capaz de confrontar ou, então, verificar uma determinada
propriedade, entre dois objetos, e produzir um veredicto entre a igualdade dos dois.
(vou criar uma figura que diferencie os dois tipos de oráculos. OK !?)
Como pode-se perceber, num determinado ambiente de desenvolvimento e teste, o orá-

culo pode assumir diversas formas e deve basear-se na especificação do programa sendo
testado. Se essa especificação for, por exemplo, uma definição de requisitos feita infor-
malmente, de maneira textual, provavelmente caberá ao testador desempenhar o papel de
oráculo e decidir sobre o comportamento do programa em teste. Sneed e Mérey (1985)
indicam que a correção requer a verificação contra alguma coisa. Além disso, não pode
haver uma verdade sobre uma execução qualquer sem um oráculo. Baseados nesse tema,
os autores alegam que oráculos podem ser configurados em forma de:
1. axiomas ou premissas de teste;
2. outro programa (teste duplo), ou
3. uma especificação formal.
O que é observado na maioria das abordagens sobre oráculos de teste é que a auto-
matização da interpretação correta dos resultados do teste parece ser um ponto crucial.
Quando uma figura humana faz o papel de oráculo, os teste são geralmente imprecisos,
propenso a erros e consomem muito tempo do projeto de desenvolvimento dos sistemas.
Enquanto oráculos automatizados, de uma forma ou de outra configuram fontes que con-
duzem à eficiência, viabilidade e confiabilidade no processo de testes (Fenkam et al., 2002).
A automatização dos mecanismos de oráculos configura um componente essencial para as
atividades de testes de software. Em linhas gerais, um oráculo pode ser automatizado das
10
mais diferentes maneiras em função do domı́nio da aplicação em teste. A seguir são expli-
citados alguns métodos firmados que contribuem para a automatização dos mecanismos
de teste e, assim, podem apoiar o teste de diferentes domı́nios de sistemas:
∙ Oráculos Baseados em Modelos Formais: Se existe para um programa qualquer um

modelo formal a partir do qual pode-se extrair seu comportamento, é possı́vel auto-
matizar a função de oráculo construindo-se um comparador entre a saı́da produzida
e o comportamento definido no modelo. Em outras palavras, caso seja possı́vel ex-
trair o comportamento de determinado processamento usando um modelo formal,
como um autômato, é possı́vel automatizar uma função de oráculo. Satisfazer re-
quisitos não é o mesmo que estar conforme uma especificação de requisitos. Uma
especificação eh uma declaração sobre uma solução particular proposta para um
problema, e esta solução pode ou não atingir seus objetivos. Além disso, especi-
ficações são escritas por pessoas e portanto, podem conter erros. Um sistema que
atende a seus objetivos reais é útil, enquanto um sistema que está consistente com
sua especificação é confiável.
∙ Oráculos Baseados em Documentação/Especificação: A capacidade de testar um

programa usando a suas especificações como um oráculo aumenta o valor da docu-
mentação formal, reduzindo o custo do teste e ajudando a garantir que os erros que
ocorrem durante o teste sejam detectados. O gerador de oráculo de teste nesse con-
texto também pode ser usado para garantir que a documentação seja mantida até
sua implementação. Sendo assim, se um programa é sempre testado com base em
sua documentação, então isso contribui para a certeza de que o comportamento do
sistema em teste é coerente com o que foi especificado pelos processos de engenha-
ria de software(Peters e Parnas, 1994). Oráculos, incluindo os oráculos humanos,
muitas vezes usam a especificação do software como orientação para resultados es-
perados. Uma questão importante na concepção do oráculo de teste automático é o
não-determinismo apresentando nas especificações. Embora muitas pesquisas acerca
da geração e execução de casos de teste lidam com a questão do não-determinismo,
poucos esforços abordam a questão da verificação automática do resultado de teste
na presença de não-determinismo. Um exemplo disso são as interfaces GUI (Li et
al., 1997). Exemplos da aplicação de especificações formais como oráculo de teste
são abordadas com mais detalhes na seção 2.2.
∙ Oráculos Baseados na execução de outros programas: Em algumas situações um

oráculo pode basear-se na execução de um outro programa Q, para que se decida
sobre o resultado da execução de um dado programa P. É o caso do teste de regressão.
Ao alterar-se um dado programa Q, produzindo-se uma versão atualizada P, pode-se
11
decidir sobre a aceitação de P por meio da comparação do comportamento P(T)

com Q(T), onde T é um conjunto de teste sobre o qual Q já tenha sido testado e
para o qual esteja correto.
∙ Oráculos para o Teste de Mutação: Na aplicação do teste de mutação (DeMillo et

al., 1978), em que o programa sob teste é executado com o conjunto I = i1, i2, ..., in,
produzindo o conjunto de saı́das O = o1, o2, ..., on. Caso decida-se (por exemplo
por meio da intervenção do testador-oráculo) que o conjunto O é o esperado, esse
passa a servir de base para que um oráculo possa decidir sobre o comportamento de
cada mutante. No caso, considerando o conjunto de teste T, se o oráculo decidir que,
para o mutante M, M(T) = O, então o mutante é considerado vivo. Caso contrário,
o mutante está morto. De um modo geral, a automatização de um comparador,
isto é, um oráculo passivo, capaz de comparar resultados de execuções do código
original com resultados de execuções de código mutado é suficiente no que se refere
a oráculos para abordagens cujo o tema principal é o teste de mutação.
Ainda na linha dos esforços dedicados à identificação e classificação dos diferentes ti-
pos de oráculos, é destacado o trabalho de Hoffman (2006). O referido trabalho trata
especificamente dos benefı́cios que a utilização de um oráculo automatizado pode trazer
ao processo de desenvolvimento de um programa e apresenta um resumo de uma série
de trabalhos cientı́ficos que visam a descrever as diferentes finalidades e utilizações dos
oráculos automatizados de verificação e validação de software. A Tabela 2.1 é baseada
na pesquisa realizada por Hoffman (2006). Ela exibe vários tipos de oráculos, algumas
de suas caracterı́sticas mais relevantes, as vantagens, desvantagens, e as implicações em
que estão incluı́dos para automatização de testes. Segundo as ideias do autor, os orácu-
los automatizados podem ser classificados classes bem distintas quanto à sua forma de
automatização.
Como pode ser notado na Tabela 2.1, a abordagem de Hoffman (2006) deixa claro que
o processo de teste de uma aplicação pode, simplesmente, não ter a disponibilidade de
um oráculo automatizado, fato que dificulta a identificação de erros complexos. Existem,
ainda, os casos em que o oráculo existe apenas de maneira aproximada ou parcial. A
abordagem também revela que é possı́vel que seja automatizado um tipo de oráculo refe-
renciado pelo autor como “verdadeiro”. Esta modalidade de oráculo automatizado é capaz
de gerar resultados de teste de maneira independente do programa a ser testado e devem
prever saı́das apenas para as entradas utilizadas no teste. Outra modalidade de oráculo
automatizado identificado é conhecido como oráculo (estratégia) de “consistência”, que é
aquele que baseia-se na execução de um programa para avaliar a correção de outras execu-
ções. Um oráculo de “referência própria” pode ser configurado a partir da soma de dados
12
Tabela 2.1: Oráculos por sua Forma de Automatização

Classificação Definição Vantagens Desvantagens
Sem Abordagem sem apuração de - Pode rodar qualquer - Apenas erros notáveis
Oráculo resultados quantidade de dados são percebidos
Oráculo - Todos os erros são
Verda- Geração independente de todos os encontrados na área de - Implementação cara e
deiro resultados esperados avaliação complexa
- Método mais rápido
- Simples Verificação
Estratégia - Capaz de verificar
de Consis- Compara resultados correntes com grandes quantidades de - Pode não detectar
tência resultados anteriores dados erros originais
- Permite extensa
análise pós-teste
- A confirmação se
confirma no conteúdo
Estratégia das mensagens
de - Pode gerar grandes - Deve definir respostas,
Referência Incrementa respostas aos dados nas quantidades de dados logo tem gerar
Própria mensagens complexos mensagens
- Mais rápido e simples
que o oráculo - Pode não capturar
verdadeiro erros
Estratégia Verifica algumas caracterı́sticas - Barato na maioria das - Pode gerar alarmes
Heurı́stica úteis de valores vezes falsos
ao resultado esperado juntamente com a própria estrutura e com os dados do teste. Para
finalizar, Hoffman (2006) caracteriza um oráculo “heurı́stico” como uma abordagem muito
simples que consiste da verificação de algumas caracterı́sticas que relatem se a execução
está correta ou não. Cabe ressaltar que a implementação de um oráculo heurı́stico para
apoiar o teste de sistemas que tenham interfaces GUI é proposta no Capı́tulo 5.
2.1.1.1 Oráculo Humano
Ressalta-se que na indústria de desenvolvimento de software, muitas vezes, o papel de

oráculo de teste é desempenhado por uma figura humana. Sendo assim, um oráculo
de teste, nesses casos, consiste em uma observação manual das entradas e saı́das dos
testes. Além de elevar os custos do projeto, esse processo pode ser demorado, tedioso, e
sujeito a erros. O conhecimento real sobre o comportamento do sistema pode ser perdido
se a verificação humana for feita de forma descuidada ou incompleta, muitas vezes por
motivos fisiológicos como cansaço ou desatenção. Infelizmente, os resultados desse tipo de
verificação geralmente são inadequados, devido à sua natureza dispendiosa e complexa.
Assim, o objetivo principal do teste - revelar falha na aplicação ou oferecer garantias
de correção do sistema - nem sempre é alcançado. Diante disso, apesar da despesa, os
esforços do teste são em vão.
Claramente, uma alternativa para uma verificação manual é desenvolver um oráculo
de teste que verifica automaticamente os resultados de execuções de teste. No entanto, o
custo de desenvolvimento de um oráculo, quando feito de maneira manual, do projeto à
implementação, pode aproximar-se do custo da aplicação do sistema em si. Além disso,
13
embora o oráculo resultante geralmente seja menos complexo que o sistema real, o que
muitas vezes acontece é que os erros detectados pelo oráculo são devido a uma falha na
implementação do próprio oráculo e não uma falha na implementação do sistema real.
Um caso adverso a tudo isso é quando a documentação do sistema de software em teste é
matemática. Nesse caso particular, é possı́vel derivar um oráculo automatizado a partir
de tais especificações. Sendo assim, um oráculo, em forma de um programa, pode fazer a
avaliação dos resultados do teste de uma forma barata e confiável (Peters e Parnas, 1998).
2.1.2 Dificuldade na Implementação de Mecanismos de oráculos

Muitos estudos primários enaltecem os benefı́cios e facilidades trazidos quando se tem um
oráculo automatizado implementado de maneira correta para apoiar o teste de determi-
nado domı́nio de aplicação. No entanto, é importante salientar que diversas pesquisas
apresentam fatores que podem ser considerados como complicadores da implementação
de oráculos de teste automatizados. De um modo bem simplório foram identificados e são
explorados a seguir os fatores que tornam a implementação de oráculo uma tarefa nada
trivial:
∙ Resultados Oculto. Em projetos de engenharia, mesmo quando estão presentes os
oráculos, os resultados de execução de um software podem durar apenas uma fração
de segundo, ou, então, serem distorcidos ou escondidos atrás de uma arquitetura
de hardware-software, por isso, muitas vezes eles não são facilmente observados ou
registrados. Em adição a isso, a observação ou processo de captura dessas saı́das
pode introduzir novos erros ou incertezas sobre os resultados da execução (Tse et
al., 2007);
∙ Como determinar o sucesso ou fracasso de casos de teste a partir de Especificações.

Abordagens acerca de oráculos de teste configuram um mecanismo utilizado para
julgar o resultado obtido de uma execução do software em teste, permitindo que
os testadores verifiquem se determinado teste foi bem ou mal sucedido (Weyuker,
1982). Muitas dessas abordagens são determinados a partir da especificação do
software. Na prática, porém, uma especificação pode fornecer descrições de alto
nı́vel apenas do sistema e não pode incluir todos os detalhes de implementação.
Assim, testadores de software também devem contar com o domı́nio do conhecimento
acerca do comportamento do software em teste para não só avaliar os resultados,
bem como, para implementar oráculos automatizados. Tais esforços manuais são
frequentemente sujeitos a erros (Peters e Parnas, 1998).
∙ Como determinar o sucesso ou fracasso de casos de teste a partir de Heurı́sticas

ou Oráculo Verdadeiros. Automatizar um oráculo verdadeiro que seja capaz de
14
gerar e comparar os resultados das execuções de um sistema qualquer pode exigir

muito conhecimento e tempo por parte do testador. Em linhas gerais, um tempo
precioso de projeto pode ser gasto com a realização dessas atividades. É complexo
implementar um sistema que, na teoria, é mais simples que o sistema em teste e
está correto para todos, ou parte, dos valores do domı́nio de entrada. No caso da
utilização de oráculos heurı́sticos, a automatização de um mecanismo que seja capaz
de julgar as saı́das de um sistema depende de um testador que tenha conhecimento
completo da aplicação em teste. Mais uma vez pode ser gasto um tempo precioso
na elaboração e implementação das heurı́sticas do oráculo durante seu processo de
automatização (Hummel e Atkinson, 2005).
∙ Custo de Implementação. O problema configurado quando se deseja verificar a regu-

laridade de execuções de uma aplicação em teste é bem conhecido pelos testadores.
Como já foi visto a verificação manual é demorada e sujeita a erros. Diante disso,
é notado que o desenvolvimento de um oráculo para verificar automaticamente as
execuções de testes pode ser tão caro como a implementação do programa original,
fato que desencoraja a implementação de mecanismos de oráculos para apoiarem
determinados testes.
Algumas abordagens relatam a implementação de oráculos automatizados para dife-

rentes domı́nios de aplicações. A subseção 2.2 mostra algumas delas que podem ser de
alta relevância e assim, são diretamente relacionadas à proposta de trabalho apresenta no
Capı́tulo 5.
2.2 Trabalhos Relacionados

Brown et al. (1992) defendem que a única maneira de saber que um produto de software
está correto é executar as especificações do programa de forma independente. Nesse caso
particular, é indispensável a presença de um oráculo que seja capaz de julgar as saı́das
diante de cada uma das especificações. Nesse sentido, a presença de um verificador de
resultados de teste é valorizado. A avaliação dos resultados de teste por meio de meca-
nismos de oráculos é um tema amplamente reconhecido de debatido em pesquisas cujo
o tema principal é o teste de software. Pode-se afirmar que, segundo a literatura, o ve-
redicto acerca da correção de uma execução é um aspecto crı́tico no processo de teste.
Diante disso, muitos pesquisadores têm dedicado seus esforços em contribuições para esse
nicho da pesquisa em engenharia de software. A geração automática de oráculos de teste
pode ser implementada de vários maneiras diferentes e com propósitos diferentes, um de-
les especificação formal, é um método mais frequentemente utilizado. Sendo assim, vários
15
métodos para o desenvolvimento de oráculos de teste, como os que utilizam especificações

(McDonald e Strooper, 1998; Richardson et al., 1992; Zhu, 2003), a documentação (Peters
e Parnas, 1998), e implementações em paralelo (Binder, 1999), têm sido relatados. Infe-
lizmente, o desenvolvimento e a utilização de tais recursos (especificações, documentação
e implementações paralelas) podem requerer um esforço considerável. Tais mecanismos
podem ser caros em aspectos tanto de desenvolvimento, quanto de manutenção. Uma
limitação do uso de um recurso para obter um oráculo de teste é que o oráculo de teste é
tão sujeito a erros quanto o recurso a partir do qual ele foi derivado. Outra desvantagem
de alguns desses métodos é exatamente a limitação da aplicabilidade, haja vista que os
documentações, tais como especificações formais raramente são usados na prática.
Jin et al. (2008) explica que por meio de uma modalidade de um compilador simples
para analisar as especificações formais, os requisitos de teste de um sistema poderiam ser
executado automaticamente e os, assim, os oráculos de teste poderiam ser derivados de
forma independente. Os autores utilizam Inteligência Artificial para configurar oráculos
de teste que servem como uma solução importante para o apoio ao teste de alguns domı́nio
especı́ficos de software. Resumidamente, os autores utilizam Redes Neurais Artificiais para
a geração direta e automática oráculos. Peters e Parnas (1998) apresenta uma abordagem
que usa especificações de software para gerar oráculos de teste. O autor descreve um
arcabouço (framework ) capaz de configurar oráculos de teste a partir da avaliação de
predicados caracterı́sticos da aplicação em teste por meio de sua especificação. Assim,
o autor desenvolve um algoritmo que pode ser usado para gerar um oráculo de teste
a partir da documentação de um programa. Para apresentar os resultados do uso da
ferramenta, os autores se embasam no arcabouço para configurarem uma ferramenta capaz
de apoiar os testes de uma aplicação comercial de gerenciamento de rede. Em Bloomfield
e Froome (1986), os oráculos de teste são construı́dos manualmente, por meio da tradução
de pós-condições em Prolog.
A geração automática de casos de teste a partir de especificações formais tem recebido
atenção considerável (Fenkam et al., 2002). Isso tem impulsionado diversas abordagens
que derivam oráculos de teste automaticamente a partir desse tipo de especificações. Ou-
tras abordagens (Agerholm et al., 1998; Treharne et al., 1998) têm sido apresentadas para
a construção de oráculos baseados em especificações formais capazes de apoiar o teste
caixa-preta de determinados domı́nios de aplicações. No entanto, estas abordagens são
baseadas em especificações explı́citas. Resumidamente, a ideia por trás delas é compa-
rar os resultados das especificações explı́citas com resultados de implementações. Essas
abordagens, infelizmente, não são capazes de manipular resultados não-determinı́sticos.
Segundo Coppit e Haddox-Schatz (2005), algumas abordagens tradicionais sobre oráculos
de teste utilizam uma versão anterior do software, reimplementam uma parte crı́tica da
16
funcionalidade geral de uma maneira confiável, ou, então, calculam o resultado correto
manualmente. Para o autor essas abordagens são insatisfatórias no sentido de que elas são
caras ou de validade duvidosa. De fato, para sistemas de software sem uma especificação
independente e documentada, o único padrão para a correção é uma aplicação alternativa
ou um conjunto de teste em si. Esta é uma alternativa atraente para oráculos de teste,
haja vista que a verificação de um resultado geralmente é mais simples e barata do que
uma computação de resultado. Coppit e Haddox-Schatz (2005) defende que a computação
dos fatores de um número é mais difı́cil do que o simples fato de verificar dois objetos
qualquer.
Ainda na linha das abordagens que utilizam especificação formal, Peters e Parnas
(1998) desenvolveram um TOG (Test Oracle Generator ) que é capaz de produzir um
oráculo de teste pra um sistema qualquer a partir de sua documentação. Esta abordagem,
segundo o autores, é precisa, relativamente legı́vel, requer uma declaração mı́nimo de
requisitos, pode ser escrita em termos da estrutura de dados ou, então, por meio de uma
notação relativamente expressivo. Como vantagens da abordagem os autores destacam
que a abordagem enaltece o valor da documentação do programa, uma vez que vai ser
usada no apoio ao teste do programa. Outro ponto positivo da abordagem é que ela
disponibiliza uma análise de testes mais rápidos, por conseguinte, reduz custos. Quanto
às desvantagens da abordagem, Peters e Parnas (1998) destacam que a documentação
utilizada para gerar o oráculo pode ser tão complexa quanto o gerados de oráculo e, por
isso, deve ser verificada com cuidado. Outro gargalho identificado na pesquisa é que,
dependendo do domı́nio da aplicação em teste, o TOG pode se mostrar um programa não
trivial, o que também exige verificações cuidadosas. Por fim, o último ponto negativo
notado na abordagem é que certas classes de comportamento de um programa podem não
ser facilmente especificado e, assim, avaliados por meio destes métodos.
Concluı́-se que o software é um dos mais complexos e variáveis artefatos construı́dos
de forma regular. Requisitos de qualidade de software usados em um ambiente podem ser
muito diferentes e incompatı́veis para outro ambiente ou domı́nio de aplicação (Oliveira,
2008). Um exemplo disso é que enquanto os métodos para a geração automática de orá-
culos de teste de especificações formais têm sido descritas na literatura, tais especificações
formais raramente são usados na indústria, o que limita a aplicabilidade desses métodos.
A respeito das abordagens analisadas, foi possı́vel notar que a grande maioria utiliza espe-
cificações formais como fonte para derivação de oráculos de teste. Nesse sentido, nota-se
que especificações formais normalmente não têm alguns detalhes algorı́tmicos. Isso difi-
culta a geração de oráculos ativos, pois a especificação contém construções que não podem
ser traduzidas diretamente para linguagem de implementação. Isto coloca uma restrição
17
severa na classe de especificações para que oráculos ativos possam ser utilizados de forma
eficaz (McDonald e Strooper, 1998).
2.3 Considerações Finais

Oráculos atualmente configuram um ramo muito importante para o controle automático
de software, mas ainda falta de compreensão plena. Mecanismos para julgar as saı́das
de execuções de aplicações em teste têm sido tradicionalmente um desafio caro para tes-
tadores de software. É sabido que um oráculo perfeito deve ser comportamentalmente
equivalente à aplicação em teste e completamente confiável. Várias abordagens têm sido
propostas para resolver este problema, como inferir especificações parciais a partir do
código ou o seu comportamento, decorrentes oráculos das especificações, ou utilizando a
especificação de ferramentas de análise orientada. Essas abordagens são, ou caras para
usar, ou tem capacidade limitada para revelar defeitos. Como resultado, os testadores
normalmente dependem de cálculo manual das saı́das de teste esperado, o que limita se-
veramente o número de casos de teste que podem ser desenvolvidas e impede o uso de
testes automatizados (Oliveira et al., 2009a). Claramente, a maioria das pesquisas atuais
sobre a geração automática de oráculos de teste esforçam-se, sobretudo, com a utilização
de métodos formais para a verificação (Jin et al., 2008).
É, portanto, impraticável para os testadores de projetos de engenharia de software
esperar por terem, à disposição, oráculos de teste precisos oráculos em todas as aplicações
do mundo real. Formas de capturar e avaliar os resultados dos testes representam um outro
problema. Automatizar processos de testes diante de tantas incertezas é especialmente
difı́cil. A verificação se torna mais difı́cil com a variação e complexidade dos produtos
finais para serem testados, transpondo isso para o universo do software, quanto mais
complexa a saı́da produzida, mais trabalhosa é a verificação. É por isso que o custo da
verificação do software geralmente corresponde a geralmente a mais da metade do custo
total do desenvolvimento e da manutenção (Myers e Sandler, 2004). A próxima seção
mostra o protocolo e os resultados de uma revisão bibliográfica sistemática cujo o tema
principal é a confecção de mecanismos de oráculos de teste para sistemas de software com
interfaces GUI.
18
Capı́tulo
3
Revisão Bibliográfica Sistemática
Quando se conduz uma revisão de literatura sem o pré-estabelecimento de um protocolo
de revisão há um direcionamento por interesses pessoais, o que leva a resultados pouco
confiáveis. No que diz respeito à Engenharia de Software, as pesquisas conduzida com
a negligência de protocolos caracterizam por serem pouco abrangentes, não passı́veis de
repetição, pouco confiáveis e dependente de revisores (Mafra e Travassos, 2006). Uma
Revisão Sistemática (RS) é caracterizada por ser um meio de avaliar e interpretar todas
as pesquisas disponı́veis, referentes a uma questão de pesquisa particular, tema, área ou
fenômeno de interesse. As revisões sistemáticas têm por objetivo apresentar uma avaliação
justa de um tema de pesquisa, utilizando uma metodologia confiável, rigorosa e auditável
(Kitchenham, 2004).
Em linhas gerais, uma RS é um método de pesquisa cientı́fica, planejado para responder
a uma, ou mais, pergunta especı́fica e que utiliza métodos explı́citos e sistemáticos para
identificar, selecionar e avaliar criticamente os estudos e para coletar e analisar os dados
destes estudos incluı́dos na revisão. Em outras palavras, uma RS implica na forma mais
adequada para se identificar, avaliar e interpretar toda pesquisa importante para um tema
em particular (Biolchini et al., 2005). Resume-se que uma revisão sistemática configura
um alicerce para novas atividades de pesquisa acerca de determinado tema. Realizou-se
uma RS com intuito de aferir o estado da arte acerca de oráculos que apoiem o teste de
19
CAPÍTULO 3. REVISÃO BIBLIOGRÁFICA SISTEMÁTICA
programas cuja interação se dá por meio de GUIs. Neste cenário, o objetivo da RS é
efetuar um levantamento bibliográfico para caracterizar quais oráculos de teste têm sido
utilizados para apoiar o teste de sistemas de software com GUIs. Para atingir este objetivo,
foi realizada uma revisão sistemática, cujos resultados são apresentados nessa seção. Esta
Seção configura uma sı́ntese da pesquisa desenvolvida. Definições são formalizadas a partir
dos resultado da RS adicionados a alguns trabalhos já conhecidos pelos autores. Com
isso, firmam-se alguns pontos de fundamental importância para a confecção de oráculos
no contexto de GUIs.
3.1 Planejamento e Condução

Diferentemente de revisões de literatura tradicionais, a revisão sistemática tem um método
de pesquisa explı́cito e rigoroso que procura identificar o conhecimento cientı́fico em uma
determinada área por meio da coleta, combinação e avaliação crı́tica de descobertas de
diversas abordagens já realizadas (Biolchini et al., 2005). O protocolo que foi seguido
durante a configuração deste trabalho consiste em uma mescla dos modelos propostos por
Biolchini et al. (2005) e Kitchenham (2004). Os referidos modelos apresentam um conjunto
de regras para o desenvolvimento de uma avaliação justa e auditável a respeito de um
tópico de pesquisa qualquer relacionado à engenharia de software. Este plano de pesquisa
foi montado e revisado na fase de planejamento e aplicado na fase de execução e análise
de resultados da revisão. A seguir são apresentados os principais tópicos pertinentes para
a explicitação do protocolo de pesquisa seguido durante a condução da RS.
Objetivo: Identificar trabalhos que apresentem estudos relacionados com as ativida-
des de teste de software, mais precisamente oráculos de teste, direcionadas para GUIs.
Infere-se que não foram encontradas na literatura revisões formais com o mesmo objetivo.
Questão de Pesquisa: O que há na literatura a respeito de oráculos de teste para
GUIs?
Itens relacionados ao escopo e especificidade da questão: os objetivos desta RS são
metodologias para a geração de oráculos de teste para interfaces GUI ou componentes
gráficos. Por meio de artigos e relatórios encontrados em bases de dados indexadas será
feito o controle da RS. Pesquisadores que dedicam seus esforços no teste e na utilização de
métodos de configuração de oráculos para interfaces GUI são a população desejada. Diante
desse cenário, os resultados esperados são métodos de geração e utilização de oráculos de
teste para interfaces GUI.
Busca e seleção das fontes: o método utilizado para a busca dos trabalhos e seleção
de fontes é descrito a seguir:
20
∙ critério de seleção de fontes: disponibilidade de consulta de artigos por meio ele-

trônico, presença de mecanismos de busca por meio de palavras chave;
∙ palavras-chave:
– “testing oracle” ou “automated oracle”; relacionados com os termos

– “graphical user interface” ou “gui” ou “guis”;
∙ data dos trabalhos: É importante salientar que foram buscadas apenas abordagens
novas, sendo assim, apenas trabalhos publicados a partir do ano 2000 foram anali-
sados.
∙ fontes de busca: foram selecionadas bases de dados eletrônicas indexadas. As fontes

IEEE e Scopus foram selecionadas como fontes de busca da pesquisa. É importante
salientar que a fonte Scopus endereça a maioria dos trabalhos armazenados nos
repositórios ACM e IEEE.
∙ tipos de estudos primários: artigos contemplando métodos de geração ou utilização

de oráculos de teste que apoiem o teste de sistemas de software com interfaces GUI.
∙ idioma dos trabalhos: Inglês. É sabido que o inglês pode ser considerado o idioma
mais aceito internacionalmente para trabalhos cientı́ficos, sendo assim pode ser con-
siderada a lı́ngua ideal para que o trabalho possa ser repetido em diversos contextos
sem nenhum prejuı́zo.
Critérios e Procedimentos para Seleção dos Estudos Primários: o critério de inclusão

definido foi a apresentação de alguma abordagem de técnicas ou critérios que impliquem
na forma de desenvolver oráculos de teste para GUIs. Foram excluı́dos oráculos para
outros tipos de sistemas de software.
Processo de Seleção dos Estudos Primários:
String de Busca: “(((testing oracle) or (automated oracle)) and ((graphical user inter-
face) or (gui) or (guis)))”
Condução da Revisão: A condução da RS foi dividida em duas fases:
∙ Seleção Preliminar : Foi confeccionada e executada uma string de busca em cada

uma das fontes selecionadas. Os trabalhos recuperados foram documentados em um
formulário de condução da revisão e selecionados com base nos critérios previamente
definidos. É importante salientar que essa verificação foi executada mediante a
leitura do resumo das obras. Obras repetidas foram documentadas uma única vez.
21
∙ Seleção Final e Extração de Resultados: O processo de seleção final consiste na

leitura minuciosa e completa das obras incluı́das ao final do processo de seleção pre-
liminar. Os resultados são apresentados de uma forma global, ou seja, são feitas uma
sı́ntese geral e algumas considerações sobre os resultados observados nos trabalhos
selecionados.
Condução da Revisão: Seguindo o protocolo acima apresentado, a revisão foi conduzida

por um perı́odo de três meses (Fevereiro/2009 a Abril/2009).
Ao todo, com a exclusão de trabalhos repetidos e trabalhos que, pelos seus resumos,
não satisfazizeeram o contexto da pesquisa, foram pré-selecionados 17 abordagens. Após a
leitura completa de todas as obras, 11 trabalhos foram escolhidos para comporem a sı́ntese
da pesquisa. Sendo assim, por meio dos critérios de inclusão e exclusão definiram-se os
trabalhos incluı́dos e excluı́dos da revisão. A Tabela 3.1 exibe todas as obras retornadas
após a realização das buscas, ou seja, após o processo de seleção preliminar. As obras
de ı́ndices 1 a 11 foram pré-selecionadas a partir da busca na fonte Scopus e as obras de
ı́ndices 12 a 17 foram pré-selecionadas por meio da busca na fonte IEEE. As situações dos
artigos depois de sua análise também são apresentadas na tabela.
3.2 Análise de Resultados

O uso de complexas interfaces nos mais diferentes tipos de sistemas de software tem au-
mentado muito. Pesquisas revelam que, na atmosfera atual, GUIs chegam a representar
60% do código das aplicações (Memon et al., 2003b). Dentro deste cenário, é possı́vel afir-
mar que elas são consideradas uma vertente de software e, como consequência disso, estão
sujeitas aos mais diversos erros. Por isso, diversos pesquisadores têm voltado suas pesqui-
sas para a criação e exercı́cios de técnicas e critérios de testes nestas partes integrantes
de módulos de sistemas que são as GUIs.
É senso comum entre os desenvolvedores e testadores que GUIs têm caracterı́sticas di-
ferentes das vertentes tradicionais da computação. Em linhas gerais, um estado GUI pode
ser resumido em uma tripla S = { (W𝑖 , P𝑗 , V𝑘 ) }, na qual W𝑖 representa seu widget atual,
P𝑗 representa suas propriedades e V𝑘 representa os valores das propriedades do widget
corrente (Memon et al., 2003b). Toda e qualquer mudança que altere esses estados po-
dem causar algum erro à aplicação. GUIs utilizam eventos para interagir com os usuários,
estes eventos são acionados por meio de entradas do teclado, cliques, posicionamento do
mouse, seleções de menus ou até por meio de contatos fı́sicos em telas sensı́veis ao toque.
Sendo assim, pode-se afirmar que os eventos alteram os estados GUI, ou seja, o conjunto
widget, propriedades e valores de propriedades, se alteram conforme acontecem os eventos
e, em seguida, são exibidos para o usuário.
22
Tabela 3.1: Seleção Final de artigos

id Nome do Trabalho Autores Comentários Status
An event-flow model of
GUI-based applications for Interessante abordagem acerca do uso de
1 testing Memon (2007) oráculos em testes GUI Incluı́do
Piping Classification to
Metamorphic Testing: An
Empirical Study towards
Better Effectiveness for the
Identification of Failures in Aborda novos métodos de geração de casos
2 Mesh Simplification Programs Chan et al. (2007) de teste para GUIs Excluı́do
Towards the Integration of
Visual and Formal Models for
3 GUI Testing Paiva et al. (2007) Abordagem de Teste Baseado em Modelos Excluı́do
Persistent Code Caching:
Exploiting Code Reuse Across Reddi et al. Abordagem de uso de oráculos em base de
4 Executions and Applications (2007) dados Excluı́do
Automated oracle based on
Multi-Weighted Neural Abordagem de oráculos para teste GUI
5 Networks for GUI testing Ye et al. (2007) por meio de Inteligência Artificial Incluı́do
Designing and comparing
automated test oracles for
GUI-based software Xie e Memon Abordagem comparativa de oráculos para
6 applications (2007) o apoio ao teste GUI Incluı́do
Employing user profiles to test
a new version of a GUI Relata dificuldades encontradas no
7 component in its context of use Memon (2006) desenvolvimento de oráculos para GUIs Incluı́do
Developing cost-effective
model-based techniques for gui Abordagem do uso de oráculos para
8 testing Xie (2006a) interfaces GUI Incluı́do
Using score distributions for
query-time fusion in Wilkins et al.
9 multimediaretrieval (2006) Abordagem de recuperação multimı́dia Excluı́do
Automating regression testing Memon et al. Abordagem que utiliza oráculos para o
10 for evolving GUI software (2005) teste GUI Incluı́do
Chen e
Specification-based Testing for Subramaniam Utiliza máquinas de estados finitos para o
11 Gui-based Applications (2002) apoio ao teste GUI Excluı́do
DART: A Framework for
Regression Testing
”Nightly/daily Builds”of GUI Memon et al. Ferramenta que aborda oráculos de para o
12 Applications (2003a) domı́nio GUI Excluı́do
What Test Oracle Should I Memon et al. Abordagem comparativa da efetividade do
13 Use for Effective GUI Testing? (2003b) uso de oráculos no teste de GUIs Incluı́do
Studying the Fault-Detection
Effectiveness of GUI Test
Cases for Rapidly Evolving Memon e Xie Apresenta resultados quantitativos do uso
14 Software (2005) de oráculos no teste GUI Incluı́do
Empirical Evaluation of the
Fault-Detection Effectiveness
of Smoke Regression Test Memon e Xie Abordagem que utiliza oráculos prontos
15 Cases for GUI-Based Software (2004b) para o teste GUI Excluı́do
On Random Testing of Image Mayer e Guderlei Abordagem quantitativa acerca de
16 Processing Applications (2006) oráculos para o teste GUI Incluı́do
Using transient/persistent
errors to develop automated
test oracles for event-driven Memon e Xie Abordagem um método diferente de
17 software (2004a) configuração de oráculos para o teste GUI Incluı́do
Um exemplo prático disso pode ser elucidado por meio de uma GUI hipotética “X”
que contenha um componente principal “M”. Esse, por sua vez, contém um botão “B”
que quando acionado por meio de um clique do mouse faz com que o background (plano
de fundo) de “M” seja pintado da cor preta. Em outras palavras, isso implica dizer que
quando “B” for clicado, ou seja, quando determinado evento for iniciado a partir de “B”,
o valor da propriedade Cor do widget “M” será alterado para preto.
3.2.1 Oráculos de Teste para GUI

A partir da pesquisa realizada foi possı́vel constatar que a literatura revela diversas abor-
dagens de teste por meio de métodos que geram casos de teste e utilizam oráculos para
23
testar GUIs baseando-se em definições de sequência de eventos, widgets, propriedades,

valores de propriedades e estados GUI. O testador GUI deve ter em mente que seu domı́-
nio de teste é sujeitado a dois tipos distintos de erros comuns: erros persistentes e erros
transientes (Xie, 2006b; Xie e Memon, 2007). Erros transientes são aqueles que ocorrem
durante a execução de um caso de teste, mas não são notados após a execução do último
evento na GUI. Erros persistentes são aqueles que ocorrem durante a execução de um caso
de teste e podem ser notados após a realização de todos os eventos do caso de teste. Logo,
erros persistentes podem ser detectados com chamadas a um oráculo depois do último
evento do caso de teste e erros transientes somente são detectados quando a chamada de
um oráculo ocorre depois de cada evento da GUI. Em outras palavras, erros persisten-
tes são mantidos até o final do último evento ser executado, enquanto erros transientes
desaparecem com o desenrolar dos eventos (Xie, 2006b; Xie e Memon, 2007).
Os casos de teste GUIS consistem em uma sequência de eventos que são executados
na GUI. Em geral, os casos de teste devem ser gerados e executados rapidamente; os
casos de teste devem providenciar uma cobertura adequada das funcionalidades da GUI
e devem alertar o desenvolvedor de possı́veis erros; os casos de teste não devem ser sen-
sı́veis a mudanças nas GUIs (Memon e Xie, 2005). Intuitivamente, um erro GUI é uma
incompatibilidade entre o estado real GUI e Oracle informação. Temos agora briefly des-
crever a representação de um estado GUI. Temos um modelo de interface gráfica como
um conjunto de widgets W = (w1, w2, ..., WL) (por exemplo, botões, painéis, campos de
texto) que constituem a interface gráfica, um conjunto de propriedades P = (p1, p2 ... ,
pm) (por exemplo, a cor, tamanho, fonte) destes widgets, e um conjunto de valores V =
(v1, v2,. . . , Vn) (por exemplo, vermelho, negrito, 16pt) associado com as propriedades.
Cada GUI irá conter certos tipos de widgets com propriedades associadas. Em qualquer
ponto durante a sua execução, a interface gráfica pode ser descrito em termos dos ele-
mentos especı́ficos que atualmente dispõe e os valores de suas propriedades. O conjunto
de elementos e suas propriedades é usada para criar um modelo de estado da GUI.
Diversas abordagens inferem que os testes GUIs e, por consequência, os oráculos para
esse domı́nio, diferem dos moldes de sistemas tradicionais (Mayer e Guderlei, 2006; Memon
e Xie, 2004a; Memon et al., 2003b). Quando técnicas e critério de teste de sistemas de
software tradicionais são comparadas ou aplicadas ao teste de GUIs, diversos pontos
incomuns são notados. Entre esses pontos destacam-se: testes e oráculos GUIs endereçam
a novas dificuldades, critérios de cobertura de teste tradicionais não funcionam bem com
interfaces, o mapeamento entre eventos é muito complexo, GUIs diferem muito dos códigos
tradicionais em seu nı́vel de abstração. Focando-se em oráculos, a RS como um todo
revelou que há grande dificuldade de especificação exata dos resultados esperados, haja
vista que apenas parte deles podem ser representados quantitativamente. Um exemplo
24
disso são coordenadas em uma tela, tamanho de widgets ou cores de componentes e o

grande número de estados nos quais uma GUI pode estar é fator complicador do teste
(Memon et al., 2003a; Memon, 2007; Memon et al., 2003b).
Em contrapartida, ainda explorando a comparação das duas abordagens de teste, ou
seja, teste de GUIs e teste de sistemas tradicionais, algumas abras incluı́das na pesquisa
revelam semelhanças. Nesse contexto, algumas obras selecionadas pela RS revelam que
as duas abordagens exigem determinação de critérios de cobertura e geram entradas de
casos de teste de especificações de software e estruturas (Memon et al., 2003b). Para GUI,
em que entradas podem ser cliques do mouse ou seleções em menus, sempre é necessário
gerar saı́das esperadas com o objetivo de compará-las com saı́das obtidas após a execução
de casos de teste. Por fim, o último fator comum notado é que nas duas modalidades é
necessário determinar um momento no qual a aplicação GUI foi testada o suficiente e, a
partir desse ponto, analisar os eventos GUI e os estados resultantes (Memon, 2007; Ye et
al., 2007).
Em linhas gerais, a pesquisa apontou que oráculos que apoiam o teste de GUIs diferem
de oráculos para o teste de aplicações tradicionais. Sendo assim, no domı́nio GUI, oráculos
de teste podem ser usados para comparar estados durante a execução de determinado caso
de teste (Memon, 2006; Xie e Memon, 2007). A literatura traz diversas abordagens que
tocam exatamente nesse ponto. Em geral, os exemplos mais comuns de oráculos para GUIs
aproveitam a composição e transitoriedade de estados para confeccionar uma arquitetura
(Memon et al., 2003b). Nesse contexto, um oráculo pode lançar mão de um caso de
teste, executar todos seus eventos, computar o estado esperado, obter o estado atual da
interface, comparar os dois estado e configurar um veredicto. Em diferentes abordagens,
o estado esperado é obtido por meio de especificações formais de uma GUI (conjunto de
elementos e suas propriedades) (Memon et al., 2003a,b; Memon e Xie, 2005).
Quando é levado em consideração o fato de que GUIs podem ter erros persistentes e
transientes, pode-se afirmar que se um oráculo não verificar a interface depois de cada
etapa de execução em um caso de teste, estados errados da GUI, não detectados, podem se
tornar uma dificuldade principalmente se o estado final for esperado pelo oráculo. Logo,
saı́das intermediárias podem estar incorretas (Memon et al., 2005; Xie, 2006b).
A partir do trabalho realizado pode-se fazer uma análise da pesquisa de uma forma
global, a partir da qual algumas conclusões são obtidas. Numericamente, observou-se que
cerca de 73% das obras (id 5, 6, 8, 10, 12, 13, 14 e 17) apresentam uma nova abordagem
de oráculos para GUIs. Enquanto 27% das obras (id 6, 8 e 17) fazem considerações e
apresentam resultados sobre a problemática que é a criação de oráculos para o teste de
GUIs. As obras que revelam resultados quantitativos acerca dos oráculos representam
82% (id 1, 5, 6, 10, 12, 13, 14, 16 e 17) dos resultados. 90% dos trabalhos (id 1, 6, 7, 8,
25
10, 12, 13, 14, 16 e 17) apresentam resultados qualitativos. Por fim, 9% das obras (id 12)
configuram ferramentas para a confecção automatizada de oráculos para interfaces GUIs.
Ainda é possı́vel fazer outras afirmações embasadas nos resultados da RS realizada.
Uma delas é que a maioria dos trabalhos com abordagens acerca de oráculos para GUI
incluı́am os autores Atif Memon e Qing Xie. Entre obras selecionadas, 63% tinham
um desses dois pesquisadores como primeiro autor. Outra constatação é que não foram
encontradas abordagens que utilizem técnicas de processamento de imagem para apoiar
a construção dos oráculos, ou seja, não há nada na literatura que faça abordagens de
oráculos para GUIs utilizando a aparência das interfaces. Sendo assim, concluı́-se que
todos os oráculos aplicavam-se aos eventos das interfaces GUI. Resume-se que, na grande
maioria das abordagens, o estado esperado é obtido por meio de especificações formais
de uma GUI. Ou seja, a partir do conjunto de elementos GUI e suas propriedades, é
possı́vel que oráculos sejam ajustados. (Pretendo atualizar este subcapı́tulo inserindo
umas análises, já prontas, de mais uns 3 ou 4 trabalhos)

Diante do importante papel das GUIs e da imaturidade das técnicas e critérios de teste
nelas aplicados, uma revisão sistemática sobre oráculos de teste GUIs foi executada. A
leitura das obras possibilitou a identificação de trabalhos relevantes para o objetivo da
revisão, ou seja, encontrar as obras que contribuı́ssem para que as perguntas estabele-
cidas no foco de pesquisa fossem respondidas. De uma forma geral, buscaram-se obras
que relatassem experiências acerca da problemática que é a definição de mecanismos de
oráculos para o teste de GUIs. A partir da revisão realizada, pode-se afirmar que o teste
de GUI e a geração de oráculos para esse tipo de interface, talvez por se tratarem de
segmentos novos do contexto de teste, está longe de ser um tópico de pesquisa maduro
e toda contribuição de pesquisadores, desenvolvedores e profissionais testadores é bem
vinda (Memon et al., 2003b). Diante do que foi apresentado, é reforçada a ideia que
graphical user interfaces são itens crı́ticos nos sistemas de software atuais, assim como
a automatização da atividade de teste para esse tipo de sistema também constitui um
tópico pouco explorado.
Pretende-se evoluir e atualizar o trabalho aqui apresentado durante o perı́odo de um
ano. Além da inclusão de novas fontes de busca, há a possibilidade do aperfeiçoamento da
pesquisa de modo que o domı́nio Processamento de Imagem seja adicionado ao domı́nio
GUI, haja vista que são linhas de desenvolvimento paralelas. Há a possibilidade de que,
em trabalhos futuros, a revisão aqui descrita sirva de base para que uma nova ou mais
ampla pesquisa seja realizada em busca de modelos de oráculos de teste para GUIs e
26
software de Processamento de Imagem, ou seja, que tenham algum tipo de saı́da gráfica.
Uma das dificuldades encontradas durante a realização da pesquisa é o fato de ser notável
que as pesquisas na área de teste de programas do meio gráfico são escassas. Por isso, é
valorizado todo documento que faça um levantamento do estado da arte relacionado ao
estabelecimento de qualidade desse tipo de aplicações, ou seja, sistemas do meio gráfico,
dentre os quais está o domı́nio GUI. A RS apresentada é valorizada por configurar o
armazenamento contı́nuo das informações e a garantia de abrangência da pesquisa por
partes de pesquisadores interessados no tema, o que constitui sólida contribuição. A
seção seguinte busca aprofundar os conceito de CBIR, bem como elucidar a forma com
que essa tecnologia será pode ser empregada na configuração de oráculos de teste para
interfaces GUI.
27
Capı́tulo
4
CBIR no Apoio a Oráculos de Teste
É notável o aumento do uso de documentos digitalizados por parte de diversas organiza-
ções no contexto atual. Seu uso está em constante crescimento, sendo armazenados em
diferentes bases de dados que podem ser acessadas por meio de redes de comunicação
como a internet. O uso em larga escala deste tipo de documento levou à necessidade de
criação de eficientes algoritmos de recuperação, indexação e técnicas de classificação de
imagens. Cabe ainda citar que diversas áreas da ciência foram amplamente beneficiadas
por tal evolução, com destaque especial para a área das ciências médicas. No diagnós-
tico auxiliado por computador, conhecido como esquema CAD, o médico sintetizará um
diagnóstico levando em consideração o resultado de processamento de um sistema com-
putadorizado, que pode executar baseando-se em processamentos e análises de imagens
ou até em dados clı́nicos de pacientes (GATO et al., 2004).
Esse cenário favorável forçou o aprimoramento da tecnologia e o barateamento das
operações digitalizadas, como exemplo, os exames médicos. Naturalmente isso fez com
que fossem criados sistemas computacionais que suportassem a demanda das tarefas de
análise de imagens (TRAINA, 2006). Em paralelo, muitos pesquisadores voltaram suas
pesquisas para a área do processamento de imagens e da computação gráfica como um
todo, fazendo com que novas tecnologias e métodos de trabalho surgissem na área. O
CBIR foi um deles. Este capı́tulo busca aprofundar os conceitos de CBIR e introduzir
28
CAPÍTULO 4. CBIR NO APOIO A ORÁCULOS DE TESTE
a maneira que esta tecnologia será explorada para a configuração de oráculos de teste
capazes de apoiar o teste de sistemas com interfaces GUI.
4.1 CBIR - Content Based Image Retrieval

Antes de apresentar os conceitos e componentes de um sistema de CBIR é interessante
abordar, de forma breve, os fundamentos que envolvem a formação de uma imagem digi-
tal. Ballard e Brown (1982) definem que a formação da imagem ocorre quando um sensor
registra a radiação que interagiu com objetos fı́sicos. A imagem é uma representação do
objeto fı́sico que pode ser armazenada, manipulada e interpretada de acordo com as neces-
sidades do interessado A maioria das imagens digitais considera o espaço bidimensional,
sendo definida como 𝑓 (𝑥,𝑦), onde 𝑥 e 𝑦 são as coordenadas espaciais. O valor de 𝑓 na co-
ordenada espacial (𝑥,𝑦) fornece a intensidade, ou seja, o brilho da imagem no ponto. Para
aplicações práticas, a imagem é uma função contı́nua, representada por medidas obtidas
em intervalos regularmente espaçados. Os valores assumidos em cada ponto medido são
quantificados em um número pertencente a uma escala de valores que representam cores.
Em grande parte das aplicações computacionais essas cores são relacionadas a nı́veis de
cinza, sendo atribuı́do o valor zero à cor mais escura (preto) e o valor máximo 𝑀 à cor
mais clara da escala (branco). Dessa forma, pode-se representar uma imagem como uma
matriz na qual cada ponto é um valor discreto, conforme é mostrado na Equação 1, em
que 𝑛 e 𝑚 correspondem à quantidade de colunas e linhas, respectivamente. Cada ponto
ou elemento constituinte da matriz-imagem é chamado de pixel, que constitui a menor
unidade sobre a qual é possı́vel realizar operações.
⎡ ⎤
𝑓 (0, 0) 𝑓 (0, 1) ... 𝑓 (0, 𝑛)
⎢ .
⎢ ⎥
⎥
⎢ ⎥
𝑓 (𝑥, 𝑦) = ⎢
⎢ . ⎥
⎥
⎣ .
⎢ ⎥
⎦
𝑓 (𝑛, 0) 𝑓 (𝑛, 1) ... 𝑓 (𝑛, 𝑚)
Equação 1
Tradicionalmente as pesquisas em bases de imagens utilizam palavras-chaves Lieber-

man et al. (2001); Ogle e Stonebraker (1995) que consistem em atributos textuais, numéri-
cos, ou similares. Para tanto, deve-se previamente cadastrar descritores capazes de definir
uma imagem para, então, viabilizar consultas a partir dos mesmos. Por exemplo, em uma
saı́da de um programa que resulta em uma imagem, esta pode ser descrita textualmente
com as palavras “clara”, “escura”, “baixo contraste” para representar caracterı́sticas glo-
bais ou, ainda, “cı́rculo com raio 3”, “triângulo retângulo”, “borda muito irregular” para
29
representar aspectos de estruturas contidas na imagem gerada pelo programa em teste.

No entanto, esta forma tradicional torna difı́cil a pesquisa quando deseja-se comparar, por
exemplo, uma imagem fornecida pela saı́da de um programa com outra já conhecida. O
conceito de CBIR vem suprir esta necessidade. As pesquisas em CBIR foram iniciadas na
segunda metade da década de 1990 (Datta et al., 2008), proporcionando um diferencial
na recuperação de informação quando o assunto a ser pesquisado envolve imagens.
Em outras perspectivas CBIR é definido como qualquer tecnologia que ajude a orga-
nizar arquivos digitais de imagens por meio do seu conteúdo visual (Datta et al., 2008).
De forma geral, os sistemas de CBIR são sistemas computacionais que visam a localizar
em uma base de imagens aquelas mais similares a uma imagem de consulta, de acordo
com um ou mais critérios fornecidos. Os critérios de similaridade são obtidos a partir da
extração de caracterı́sticas da imagem como cor, textura e forma. Os sistemas automati-
zados de CBIR envolvem várias áreas da Computação, sendo as principais Processamento
de Imagens e Banco de Dados. O CBIR é uma técnica de recuperação de imagem que
tem como princı́pio básico a realização de uma consulta em um banco de dados com uma
determinada quantidade de imagens similares a uma imagem de referência, baseando-se
em um ou mais critérios fornecidos (SANTOS, 2006; (Oliveira et al., 2008)). Tais critérios
se resumem nas caracterı́sticas das imagens e podem tanto ser obtidas por especialistas
como ser extraı́das das imagens por algoritmos automáticos alcançando melhores resul-
tados (SANTOS, 2006, p.21; ARAUJO et al., 2002). São exemplos de caracterı́sticas de
imagens: forma, textura, borda, cor etc.
O propósito do CBIR nem sempre é buscar a imagem exatamente igual à imagem de
consulta, o que poderia acontecer por uma comparação pixel a pixel, e sim buscar a ima-
gem mais parecida ou similar. A consulta por distância recupera objetos dentro de certo
grau de similaridade, um número fixo de objetos similares. A comparação de objetos por
similaridade é essencial para tratar dados complexos e capturar o que é mais representa-
tivo a fim de extrair informações que os representem de modo mais fiel (FILARDI, 2007,
p5). Pode-se classificar CBIR como um processo que exige muito tempo de processamento,
por isso a comparação entre as imagens é feita utilizando um conjunto de caracterı́sticas
extraı́das das imagens que as descrevem (SANTOS, 2006). Esse conjunto de caracterı́sti-
cas extraı́das de uma imagem forma o seu vetor de caracterı́sticas, que é utilizado na sua
indexação e recuperação. Pode-se concluir que as caracterı́sticas extraı́das representam a
imagem no momento de sua busca, pois é a partir delas que uma determinada imagem
é recuperada do banco de imagens (DELAMARO, 2007a). O conjunto de caracterı́sticas
em si não é suficiente para determinar o resultado da recuperação, visto que a escolha da
medida de similaridade entre as imagens vai, também, ter influência nele. (falta fazer o
acerto das referencias em maiusculo)
30
Conclui-se que sistemas CBIR permitem a recuperação de um conjunto finito de ima-

gens similares a uma imagem exemplo. Para isso é feito o uso de informações inerentes
à própria imagem. Tais similaridades devem ter o nı́vel de semelhança pré-determinado
pelo usuário. As comparações entre as imagens podem ser realizadas por meio de carac-
terı́sticas extraı́das e automaticamente agrupadas em um vetor de caracterı́sticas que tem
por finalidade armazenar a essência da imagem.
4.1.1 Etapas CBIR

Outra classificação de etapas de CBIR:
Existem diversas classificações de etapas de processamento para sistemas CBIR. Se-
gundo (ARAUJO et al., 2002; SANTOS, 2006, p.22), são etapas básicas para sistemas
CBIR:
∙ Aquisição: consiste em, por algum meio fı́sico, obter as imagens digitais a serem
utilizadas.
∙ Pré-processamento: baseia-se em melhorar a imagem, por meio de técnicas para

realce de contraste, remoção de ruı́do, isolamento de regiões e etc. Esta etapa tem,
indiretamente e como objetivo maior, aumentar as chances de sucesso dos processos
seguintes.
∙ Extração de caracterı́sticas: tem por meta extrair informações ou dados particulares

da imagem, as quais serão utilizadas na busca na base de dados.
∙ Indexação: consiste em aperfeiçoar e facilitar a consulta à base de dados de imagens.
∙ Recuperação: consiste da varredura de toda a base de dados, de forma a recuperar

as imagens mais similares à imagem exemplo.
De forma simplificada e dentro do contexto deste artigo, um sistema de CBIR é com-

posto basicamente por três partes: extratores, funções de similaridades e estruturas de
indexação (Smeulders et al., 2000), conforme o esquema apresentado na Figura 1 (falta
fazer ajustes na figura, por isso nao foi inserida).
4.1.1.1 Extratores de Caracterı́sticas
Os extratores são métodos computacionais que extraem caracterı́sticas das imagens a

partir de algoritmos que analisam cores, formas, texturas ou outros aspectos relacionados
à imagem como um todo ou à parte dela. Quando as imagens são consideradas como um
conjunto de pixels, esses extratores podem referir-se a relações existentes entre os pixels em
31
um determinado trecho da imagem, considerando uma classe particular de caracterı́sticas.

Por exemplo, definindo-se as cores como uma classe particular de interesse, um extrator
especı́fico poderia retornar o valor do contraste de um determinado trecho da imagem,
que poderia ser medido calculando-se a média de cores de tal objeto dividida pela média
de cores do fundo da imagem – composto pelos pixels que circundam o trecho em questão.
As caracterı́sticas extraı́das são, em geral, transformadas em um valor que, posteri-
ormente, pode ser comparado com o valor obtido para a mesma caracterı́stica de outra
imagem (El-Naqa et al., 2004). Comumente vários extratores são desenvolvidos em um
sistema CBIR, sendo que cada um deles refere-se a um aspecto da imagem. Por exemplo,
em um sistema simples de CBIR, o extrator que calcula o contraste de um determinado
trecho da imagem, exemplificado anteriormente, pode retornar o valor zero quando o
contraste é nulo ou outro valor no intervalo entre zero e um, representando o nı́vel de
contraste entre a estrutura considerada e o fundo da imagem. No processo de extração
de caracterı́sticas deve ser levando em conta o foco da aplicação, pois dependendo do tipo
de imagem e aplicação, as caracterı́sticas de interesse podem variar e até mesmo serem
muito especı́ficas. No entanto, é possı́vel definir-se extratores aplicáveis a diversas classes
de imagens. O processo de extração de caracterı́sticas geralmente ocorre depois de uma
etapa de pré-processamento e segmentação da imagem, no qual o objeto de interesse é
localizado e rotulado de forma que fique isolado. Na segmentação o objeto é separado
do fundo gerando uma região ou apenas identificando a borda (Gonzalez e Woods, 2006).
A partir daı́ o processo de extração de caracterı́sticas fica responsável por obter aspec-
tos inerentes ao objeto segmentado ou região de interesse, de acordo com algum critério
pré-estabelecido.
Uma região pode ser representada com base em suas caracterı́sticas internas (os ele-
mentos contidos dentro da região) ou em suas caracterı́sticas externas (sua fronteira ou
borda) (Gonzalez e Woods, 2006). A representação externa é mais adequada quando o
foco está nas caracterı́sticas de forma e a representação interna é usada para representar
as caracterı́sticas refletivas como cor e textura. As caracterı́sticas que descrevem as ima-
gens devem ser insensı́veis às variações de tamanho, translação e rotação. O conjunto de
caracterı́sticas extraı́das de uma imagem forma o seu vetor de caracterı́sticas, que é utili-
zado na sua indexação e recuperação. As caracterı́sticas extraı́das representam a imagem
no momento de sua busca, pois é a partir delas que uma determinada imagem é recu-
perada do banco de imagens. O conjunto de caracterı́sticas em si não é suficiente para
determinar o resultado da recuperação. Outro elemento que vai influenciar nos resulta-
dos da busca é a escolha de medidas de similaridade entre as imagens, conforme descrito
a seguir. Conforme explicado, os atributos de uma imagem são geralmente obtidos por
meio de técnicas de processamento de imagens que medem uma caracterı́stica da imagem
32
e a representa por um número. Esses números formam um vetor de caracterı́sticas da

imagem. Para aplicar uma consulta por similaridade sobre os vetores de caracterı́sticas
é necessário usar uma função de distância para o cálculo da similaridade, definindo-se a
função de similaridade (Vasconcelos, 2004).
4.1.1.2 Funções de distância ou similaridade
Uma função de distância ou, similaridade, é um algoritmo que compara dois vetores de
caracterı́sticas e retorna um valor não negativo. Quanto menor o valor retornado, maior
é a semelhança entre a imagem modelo e a imagem procurada. Existem várias funções
de distância disponı́veis para comparar vetores de caracterı́sticas. Alguns exemplos são
a distância Euclidiana entre histogramas (Hafner et al., 1995; Swain e Ballard, 1991), a
distância de Mahalanobis entre o valor médio das caracterı́sticas da imagem (Manjunath
e Ma, 1996; Smith, 1997), ou métricas derivadas de critérios de otimização relacionados
(Rubner et al., 1998). Vasconcelos (2004) faz uma profunda análise sobre a eficiência
da avaliação de sistemas de CBIR usando funções de similaridade probabilı́sticas. A
partir da composição do vetor de caracterı́sticas e da definição da função de similaridade
a ser empregada, o sistema está pronto para realizar as consultas. A recuperação por
similaridade pode ser por abrangência (usa a distância a partir de um ponto de referência
para a recuperação da imagem) ou pelos 𝑘 − 𝑣𝑖𝑧𝑖𝑛ℎ𝑜𝑠 mais próximos (a partir de um
ponto de referência recupera as 𝑘 imagens mais similares a imagem de consulta) (Ciaccia
et al., 1997).
4.1.1.3 Estruturas de Indexação
O processo de busca envolve a comparação de vetores de alta dimensionalidade. Assim, é

necessária a otimização do desempenho aplicando-se estruturas de indexação adequadas,
envolvendo pesquisas nas áreas de bancos de dados e estruturas de dados. Muitas vezes
procura-se diminuir a dimensão dos vetores para, em seguida, construir ı́ndices adequados
(Böhm et al., 2001; Gaede e Günther, 1998). Estruturas de indexação que consideram ape-
nas a distância existente entre os dados, perfeitamente adequadas ao contexto de CBIR,
têm sido objeto de pesquisas há algumas décadas e aperfeiçoadas em trabalhos recentes.
Neste contexto, é interessante citar o trabalho pioneiro de Burkhard e Keller (1973) e os
trabalhos mais recentes que definem árvores de busca de formas mais otimizadas, direci-
onadas para aplicações CBIR (Böhm et al., 2001; Gaede e Günther, 1998; Petrakis et al.,
2002; Traina et al., 2002).
33
4.2 CBIR como apoio à automatização de Oráculos para

programas com saı́da Gráfica
A automatização da atividade de teste é essencial no aumento da produtividade das equi-
pes de desenvolvimento. Sendo essa atividade responsável por grande parte do custo de
desenvolvimento de um produto, permitir que processos automatizados sejam utilizados,
diminuindo a interação necessária com o testador, eleva a produtividade e a qualidade,
reduzindo a ocorrência de enganos.
Um dos aspectos difı́ceis de se automatizar é a criação de oráculos, principalmente
quando a saı́da ou o comportamento que define a correção de uma execução é não tri-
vial. É também, possivelmente, um dos aspectos menos explorados na literatura. Quando
a saı́da da execução de um programa é textual, verificar sua correção é uma atividade
simples, principalmente quando se tem um “modelo” que possa ser usado numa compa-
ração caractere-a-caractere. Por outro lado quando a decisão sobre a correção é feita
analisando-se uma imagem ou uma interface gráfica apresentada ao testador, essa auto-
matização torna-se sensivelmente mais difı́cil. Um exemplo notável deste fato é a aplicação
do teste de mutação (Delamaro e Maldonado, 1996) em que o resultado da execução de
cada mutante deve ser decidido comparando sua execução com a execução do programa
original, considerada como modelo para essa decisão.
Ferramentas de suporte ao teste de mutação como a Proteum (Delamaro e Maldonado,
1996) limitam sua análise a saı́das textuais, dada a dificuldade em tratar-se outros tipos
de saı́das, consequentemente, limitando o tipo de programas suscetı́veis de teste nesse
ambiente. Quando tem-se uma saı́da gráfica a ser analisada como resultado da execução
de um programa, pode-se empregar também a abordagem de utilizar uma imagem como
referência para a comparação. Existem porém diversos aspectos que precisam ser consi-
derados neste caso. O mais notável deles é que uma comparação pixel-a-pixel pode não
produzir o resultado correto, uma vez que a imagem de referência pode não representar
exatamente a saı́da esperada ou pode-se ter diferentes resultados que devem ser conside-
rados corretos, ainda que não exatamente iguais à imagem de referência. Em seguida são
apresentados dois exemplos em que essa situação se aplica.
O primeiro é no tratamento de imagens médicas como o feito no artigo de Bellotti et al.
(2006). Os autores avaliam um sistema CAD (Computer Aided Diagnosis ou diagnóstico
auxiliado por computador) para localização de massas em imagens mamográficas e para
isso usam imagens “anotadas” por um médico que são depois comparadas com o resultado
do processamento. A anotação usada pelos pesquisadores é um cı́rculo cujo centro indica
o ponto onde a massa foi localizada pelo médico especialista e cujo raio inclui a massa
completamente. Embora sirva como parâmetro para que os pesquisadores possam avaliar
34
o grau de acerto do sistema CAD, essa abordagem está distante de ser precisa, no sentido
que a forma identificada pelo sistema pode ser bastante diversa da massa indicada na
mamografia e ainda assim ser considerada como correta.
A área médica é, de fato, rica em exemplos como esse, no qual um oráculo gráfico
com certo grau de precisão poderia ser muito útil. O trabalho de Paquerault et al. (2004)
compara três métodos de segmentação, também aplicados em imagens mamográficas para
a identificação de microcalcificações. Nesse caso, o resultado dos algoritmos de segmenta-
ção, que identificam regiões de interesse na imagem são sobrepostas à imagem original e
fica por conta de um “oráculo humano” avaliar qual deles produziu o resultado mais exato.
O uso de um oráculo automatizado nesse caso seria de grande importância, adicionando
parâmetros objetivos de comparação e com isso diminuindo a probabilidade de enganos.
Um segundo exemplo é quando a saı́da do programa é dada através de uma interface
gráfica. Suponha-se que o resultado esperado é dado por uma imagem, resultado de uma
execução anterior do programa ou de outro programa como no caso do teste de regressão ou
da aplicação do teste de mutação. Como mostra a Figura X (sera criada e inserida),
uma GUI é composta de diversos componentes cujo comportamento, conhecido pelos
usuários, indica a correção ou não da execução do programa. Por exemplo, uma área
preenchida numa barra de “progresso” ou um um “checkbox” marcado ou não determinam
se o resultado esperado foi ou não alcançado.
Existem, porém, diversos fatores que podem fazer com que a representação gráfica
de duas execuções com o mesmo resultado não seja exatamente a mesma. Por exemplo,
quando as duas execuções – que produz a imagem de referência e a que se deseja analisar –
são executados em ambientes diferentes, com look-and-feel diversos. Tal situação torna-se
cada vez mais comum, dada a portabilidade alcançada por meio de algumas linguagens
de programação ou se considerarmos aplicações WEB cuja aparência para o usuário final
depende, também, do cliente (WEB browser) utilizado. A Figura Y (será criada e
inserida) mostra o resultado de duas execuções que apresentam o mesmo comportamento
e portanto deveriam ser consideradas “iguais” do ponto de vista de um oráculo de teste.
No detalhe, pode-se notar que a comparação pixel-a-pixel para os componentes checkbox
no lado esquerdo da figura produziria o resultado incorreto sob essa perspectiva.
Nos dois casos, o problema que se tem é o de utilizar uma imagem de referência que
pode não corresponder exatamente ao resultado esperado. Ou, ainda, de se ter apenas
uma aproximação do resultado (imagem) esperado. A utilização dos conceitos de CBIR
pode ajudar nesse contexto à medida que permite que sejam extraı́das das imagens as
caracterı́sticas relevantes para a comparação. Por exemplo, a área e o perı́metro de uma
região de interesse podem ser comparadas com as mesmas caracterı́sticas da imagem de
referência na qual o médico especialista marcou manualmente. Embora o resultado da
35
comparação não seja, em geral, exatamente igual, resultados muitos próximos devem
indicar que a execução do sistema CAD acertou na identificação da região de interesse.
O uso de CBIR não tem como objetivo indicar quando duas imagens são iguais ou não
mas sim apontar o quão próximas elas estão, fato que pode ser positivamente explorado
na construção de oráculos de teste. Para permitir que CBIR possa ser utilizada de forma
eficiente, este artigo propõe uma arquitetura que permite ao testador criar seus oráculos
gráficos de forma flexı́vel e simples, independentemente do domı́nio a que se destine. O
trabalho do testador é definir os extratores, a função de de similaridade e as regiões da
imagem em que devem ser aplicados.
4.2.1 Arquitetura
Para que se possa utilizar os conceitos de CBIR, conforme descrito anteriormente, foi
desenvolvido um framework chamado O-FIm (Oracle for Images) que tem como obje-
tivo permitir ao testador construir um oráculo de teste, procurando atender os seguinte
requisitos:
∙ flexibilidade: o testador deve ser capaz de criar oráculos para diversas aplicações
em diversos domı́nios distintos. Tudo o que ele precisa fazer é definir e implementar
os extratores de caracterı́sticas e funções de similaridade que pretende usar no seu
oráculo;
∙ simplicidade: o framework provê uma API simples, que o testador pode rapidamente
aprender e utilizar;
∙ facilidade de uso: uma ferramenta de geração permite ainda maior facilidade na

criação de um oráculo.
Como resultado da utilização desse framework, o testador obtém um programa Java

que é capaz de comparar duas imagens (em geral armazenadas em arquivos) respondendo
se são ou não similares, de acordo com as caracterı́sticas por ele definidas. A arquitetura
do O-FIm é descrita na Figura W.(A figura será refeita e introduzida)
4.2.2 Plugins
Os plugins representados na Figura W são as contribuições do testador para a criação do
oráculo. Eles são adicionados ao framework através de chamadas ao núcleo e podem ser
de dois tipos: extrator ou função de similaridade.
O primeiro tipo de plugin representa um extrator de caracterı́sticas. Nele o testador
deve implementar os seus algoritmos de processamento de imagem que irão identificar
uma caracterı́stica presente numa imagem e quantificá-la.
36
Para permitir que o testador implemente um extrator e que o framework reconheça-o

como tal, o núcleo disponibiliza uma interface chamada IExtractor. Assim, é requisito que
ao desenvolver um extrator o testador crie uma classe Java que implementa essa interface.
A Figura K (pretendo-se colocar o código da interfaces IExtractor e ISimilarity)
sumariza os seus métodos. Destacam-se:
∙ void setName(String) – atribui um nome ao extrator. Na Seção 5.2 comenta-se como

o nome é atribuı́do a cada extrator;
∙ String getName() – retorna o nome atribuı́do ao extrator;
∙ setProperty(String, Object) – cada extrator pode possuir um conjunto próprio de

atributos que define seu comportamento. Por exemplo, se o extrator deve ser apli-
cado a uma região da imagem e não à imagem como um todo, a classe que im-
plementa o extrator pode definir uma propriedade “rectangle” que deve receber um
valor antes que o extrator seja usado. Como esse é um método genérico para qual-
quer que seja o tipo do atributo, a chamada no caso de “rectangle” recebe como
segundo argumento um array de quatro números inteiros. É obrigação do método
setProperty verificar a validade do nome e do tipo dos argumentos;
∙ String[] getProperties() – retorna os nomes das propriedades utilizadas pelo extrator;
∙ double computeValue(PlannarImage) – calcula o valor relativo à propriedade que o

extrator implementa, em uma determinada imagem;
O segundo tipo de plugin que o testador pode adicionar ao framework representa, na

estrutura de CBIR, uma função de similaridade, já que diferentes formas de combinar
os resultados produzidos pelos extratores podem ser utilizadas. Para uma função de
similaridade ser utilizada deve-se “adicionar” a ela um ou mais extratores.
Para esse tipo de plugin define-se também uma interface que o testador deve imple-
mentar em suas funções de similaridade. A API desse tipo de plugin é a seguinte (vou
colocar o código da interface atualizado):
∙ void setName(String) – atribui um nome à função de similaridade;
∙ String getName() – retorna o nome atribuı́do à função de similaridade;
∙ void addExtractor(IExtractor extractor) – uma função de similaridade usa um ou

alguns extratores. Esse método permite adicionar um extrator à função;
∙ IExtractor[] getExtractors() – retorna a lista de extratores que fazem parte da função

de similaridade;
37
∙ double[] computeValues(PlanarImage) – calcula o valor de cada um dos extratores

para uma dada imagem;
∙ double computeSimilarity(double[], double[] – computa o valor da função de simi-

laridade aplicada a dois vetores de números, em geral, retornados da aplicação dos
extratores em duas imagens distintas;
Pode-se perceber que, propositadamente, a API fornecida por essas duas interfaces
são bastante simples, mas suficientes para permitir sua utilização no O-FIm. A Figura Q
(a figura será refeita ) sumariza essas duas classes e o relacionamento entre elas. Deve-se
notar que na criação de um oráculos faz-se a instanciação de um objeto ISimilarity que,
por sua vez, agrega um ou mais extratores.
4.2.3 Núcleo
O núcleo do O-FIm permite que o testador instale e remova plugins e provê uma API
sobre a qual o testador pode construir seus oráculos. Para instalar e remover plugins, o
núcleo provê um programa que pode ser invocado diretamente na linha de comando. Por
exemplo, para instalar um plugin pode-se executar:
java br.oraculos.Main install MyExtractor /home/delamaro/myextractor

br.extractors.MyExtractor
Nesse casso, os argumentos representam:
∙ install: A operação a ser realizada.
∙ MyExtractor: o nome a ser dado ao plugin. O núcleo irá associar esse nome às
classes que representam o plugin. Este será o nome que deve ser utilizado pelo
usuário quando oráculos forem configurados com esse plugin
∙ /home/delamaro/myextractor: é o nome do diretório do jar ou das classes que

contem o extrator;
∙ br.extractors.MyExtractor: o nome da classe que implementa a interface no plugin.

núcleo que identifica qual o tipo de plugin a classe está verificando quais interfaces
ele implementa, o que determina a forma como a classe pode ser usada: como um
exaustor, como uma função de semelhança ou de ambos. Essa classe será usada para
instanciar o plugin quando um oráculo é criado.
Com a instalação de plugins permite-se que eles possam ser reutilizados na construção
de diferentes oráculos.
38
O núcleo provê, também, uma API que permite, de forma pragramática, a criação de
um oráculo. Na Figura 3 esse tipo de interação é representada pela aplicação do testador
que acessa os métodos da API do núcleo. As principais funções fornecidas pelo núcleo
estão na classe br.oraculos. Oracle que implementa:
∙ static Oracle createOracle() – cria um oráculo vazio;
∙ static Oracle createOracle(InputStream) – cria um oráculo baseado numa descrição

completa dada pelo InputStream. Seção 5.3 fornece mais informaçao sobre essa
descrição;
∙ void setSimilarityFunction(ISimilarity) – determina qual função de similaridade é

usada pelo oráculo;
∙ ISimilarity getSimilarityFunction() – retorna qual função de similaridade está sendo

utilizada no oráculo;
∙ void setPrecision(double) – determina qual é a precisão (threshold) usada pelo orá-

culo, ou seja, qual é o valor a partir do qual a comparação entre duas imagens é con-
siderada diferente. Se o valor retornado pelo método computeDistance for inferior a
esse valor as imagens são consideradas similares. Caso contrário, são consideradas
diferentes;
∙ double getPrecision() – retorna o valor da precisão sendo utilizada;
∙ double computeDistance(PlanarImage, PlanarImage) – calcula a diferença entre

duas imagens usando a função de similaridade definida e os extratores por ela utili-
zada;
∙ boolean compare(PlanarImage, PlanarImage) – retorna verdadeiro se a distância

entre as imagens é inferior ou igual à precisão definida. Retorna falso caso contrário.
4.3 Contexto
Com a finalidade de demonstrar a aplicabilidade da estrutura construı́da apresentada na
Seção anterior e enfatizar a viabilidade da utilização de CBIR para a construção de orá-
culos, foi implementada uma interface gráfica capaz de viabilizar todas as funcionalidades
do núcleo de um modo prático e rápido. Esta interface já foi utilizada com sucesso em
alguns estudos de caso que se resumiam no teste de alguns esquemas CAD. Esta subseção
visa a apresentar os principais aspectos relacionados à interface que servirá de base para
a realização da proposta de trabalho contida no Capı́tulo ??
39
4.3.1 Gerador de Descritores de Oráculos Gráficos

Para facilitar a criação de um oráculo totalmente através de um programa, o testador
precisaria executar alguns passos como: 1) criar os extratores e definir suas propriedades;
2) criar uma função de similaridade; 3) adicionar os extratores à função de similaridade;
4) criar um oráculo; 5) adicionar a função de similaridade ao oráculo; 6) estabelecer o
valor da precisão a ser utilizada.
Para simplificar essa tarefa, o testador pode definir a estrutura de um oráculo através
de um arquivo texto simples. Nele podem ser definidas todas as caracterı́sticas desejadas
como extratores e suas propriedades, função de similaridade e precisão. A Figura 5 mostra
um exemplo de definição de oráculo. Nele, um oráculo é criado usando os extratores
MyExtractor e OurExtractor. O primeiro possui uma propriedade chamada “color” que
será definida com o valor (um string) “red” e uma propriedade “alpha” cujo valor é um
inteiro longo, 78. O segundo possui uma propriedade “scale” cujo valor será inicializado
com o valor double, 1.33. Ambos possuem uma propriedade chamada “rectangle” para a
qual um vetor de inteiros deve ser usado. A BNF do formato de uma descrição de oráculo
é apresentada na figura Z (falta criar a figura com a gramática e inserir).
Para utilizar o parser o testador deve chamar o método createOracle(InputStream)
passando como argumento, por exemplo, um FileInputStream que contenha a descrição
do oráculo, como aquela da Figura Z.
Ainda para facilitar a criação de um oráculo, o framework O-FIm possui um “wizard”
de descrição de oráculo. É uma interface gráfica que permite a interação do testador para
criar uma descrição conforme descrita acima. A Figura 6 apresenta a janela principal
dessa ferramenta. Pode-se ver que na interface o testador pode selecionar quais são os
extratores que deseja utilizar, assim como o valor de suas propriedades. Pode selecionar
também a função de similaridade e a precisão. Na imagem que aparece à direita, pode
selecionar qual è a região na qual deve ser aplicado o extrator selecionado. Isso faz com
que a propriedade “rectangle” seja configurada de acordo com a região selecionada.(serão
capturadas algumas telas d anova interface e alguns exemplos serão mais bem
ilustrados)
O testador seleciona a opção “Save” para gerar um arquivo de configuração como o
mostrado na seção anterior. Com este framework o testador possui todas as ferramentas
necessárias para construir oráculos de teste para diferentes tipos de programas ou domı́-
nios. Para tanto, deve definir através de plugins quais caracterı́sticas serão utilizadas e
qual função de similaridade deve ser empregada na comparação das imagens produzidas
pelo seu programa. Os plugins são combinados numa descrição textual que pode, en-
tão, ser transformada de maneira bastante simples num oráculo. Na próxima seção, um
exemplo de utilização desse framework é apresentado e discutido.
40
∙ Será explicada e demostrada a opção My oracles
∙ Exemplo de instalação e Remoção de Plugins via interface gráfica

Os oráculos são baseados no armazenamento dos resultados da execução de outros progra-
mas. Observa-se que a complexidade de sua automatização é diretamente proporcional à
complexidade de sua saı́da. Dessa forma, quando a saı́da de processamento é complexa,
em particular, no formato gráfico, sua automatização também será complexa. Em relação
ao framework O-FIm, esperam-se contribuições, uma vez que é utilizado um conceito re-
lativamente novo na Computação (recuperação baseada em conteúdo) para realizar testes
em programas com saı́das gráficas, que são pouco explorados na literatura.
Novas atividades de automatização podem ser inseridas no contexto do framework,
bem como atividades experimentais tal qual a avaliação da efetividade do ambiente na
automatização de teste. Enfim, por se tratar de um trabalho que engloba duas áreas de
pesquisa, ou seja, é multidisciplinar, ele tem muitas faces que permitem ser exploradas,
tanto no que tange a teste de software quanto a processamento de imagens. No Capı́tulo
5 é apresentada uma proposta de trabalho que utiliza os conceitos aqui explicitados para
a construção de oráculos gráficos capazes de apoiar o teste de sistemas de software com
interfaces GUI.
41
Capı́tulo
5
Proposta de Trabalho
Um ponto particularmente delicado na automatização de um oráculo aparece quando as
saı́das a serem comparadas se encontram num formato não trivial, como, por exemplo, a
tela de uma interface gráfica ou uma outra imagem produzida pelo programa sendo con-
siderado. Neste caso, pode-se optar por construir oráculos definindo-se anotações sobre a
saı́da considerada correta. É possı́vel, por exemplo, criar um banco de dados que armazene
caracterı́sticas convencionais (textos ou números) sobre a saı́da esperada. Em seguida,
analisa-se a saı́da do programa em teste e gera-se, também, caracterı́sticas convencionais
que poderão ser comparadas com o oráculo previamente definido. Como é possı́vel inferir,
esta tarefa é árdua e exige intensa participação do usuário que, provavelmente, pode ser
variável e inexata. Fatores relacionados à fadiga, experiência do usuário sobre a imagem
e até mesmo nı́vel de exigência na interpretação podem inviabilizar esta abordagem.
Uma abordagem inovadora é a utilização dos conceitos de CBIR, que vêm sendo desen-
volvidos nas últimas décadas como ferramenta para consultar bancos de imagens, parti-
cularmente para facilitar a recuperação de imagens similares a uma determinada imagem
modelo. A similaridade entre imagens é definida por meio da comparação de caracterı́sti-
cas extraı́das geralmente por técnicas de processamento de imagens, referentes a aspectos
de cor, textura e forma. Este tipo de recuperação de informação pode ser utilizado nos
mais diversos campos de conhecimento, tendo sido bastante explorado na área médica. A
42
CAPÍTULO 5. PROPOSTA DE TRABALHO
comparação é implementada utilizando-se funções que medem a distância entre conjuntos

de caracterı́sticas de duas imagens distintas, denominadas funções de similaridade. Nesse
sentido, este capı́tulo tem por objetivo apresentar uma proposta e um cronograma de ati-
vidades que devem ser desenvolvidas em uma pesquisa que busca contribuir com o estado
da arte no que se refere à automatização de oráculos de teste para programas cuja saı́da
se encontra em algum formato gráfico. Nesse caso particular, no formato de interfaces
GUI.
5.1 Proposta de Trabalho

O teste é uma atividade essencial para avaliar o comportamento ea qualidade de um
componente de software. O estado da arte em teste de software durante os últimos 30 anos
tem desenvolvido numerosos, muitas vezes se sobrepõem, testando métodos e práticas:
testes funcionais, testes estatı́sticos, análise de caixa branca, testes de caixa-preta, teste de
unidade, teste de sistema e muitos outros. Em suma, como foi apresentado, há uma certa
dificuldade na definição de oráculos de teste automatizados para sistemas de software do
meio gráfico. Nesse contexto, é desafiador e útil encontrar um oráculo de teste automático
e conveniente para tal tarefa.
Tais oráculos são exatamente o argumento que norteia a pesquisa aqui apresentada.
Em linhas gerais, uma dificuldade na manutenção do software é que a relação entre o com-
portamento observado, muitas vezes por meio de uma interface, e programa nem sempre
é clara. Neste trabalho preocupa-se especificamente com a manutenção de interfaces grá-
ficas do usuário (GUI). Deste modo, é proposto o estudo e desenvolvimento de artifı́cios
que sejam capazes de representar oráculos que apoiem o teste de sistemas de software cuja
interação se dá por meio de interfaces GUI.
5.1.1 Objetivos do Trabalho

É cada dia mais comum a utilização de interfaces gráficas nos mais diferentes sistemas
computacionais. Isso faz com que estes programas, sejam eles crı́ticos, ou não, necessitem
que sejam implantadas atividades de teste nas interfaces de seus produtos finais. Exata-
mente nesse aspecto, todo conceito de um oráculo se manifesta mais negativamente do
que positivamente. O objetivo deste trabalho é apresentar um método conceitualmente
simples e comprovado, que é a tecnologia CBIR, para a automatização de oráculos de teste
para domı́nio GUI. Para isso pretende-se investigar os métodos de geração de oráculos para
domı́nios GUI, observando como eles se comportam e qual é sua eficácia. Pretende-se tam-
bém prover métodos de execução monitorada de sistemas de software com interfaces GUI
43
de um modo que sejam capturados screenshots para que neles sejam realizados os testes.
É importante salientar que para isso serão estados os componentes do toolkit Swing, que
é uma famosa biblioteca de desenvolvimento de interfaces GUI em linguagem Java. Parte
fundamental do trabalho será a implementação de extratores de caracterı́sticas de ima-
gem, funções de similaridades, filtros de pré-processamento imagens e heurı́sticas capazes
de avaliar interfaces GUI implementadas a partir da biblioteca Swing.
Para que os objetivos identificados sejam cumpridos, são previstas duas grandes etapas
no desenvolvimento do projeto. A primeira é a de estudar e determinar as caracterı́sticas
que podem ser extraı́das das interfaces GUI para comparação. A segunda é a concretiza-
ção do oráculo gráfico propriamente dito, na qual técnicas de processamento de imagens
devem ser estudadas e implementadas, para que se possa extrair e comparar as carac-
terı́sticas de interesses especı́ficos para domı́nios GUI. Sumarizando, o objetivo principal
deste projeto é a construção de um ambiente batizado de “oráculo gráfico” que utiliza
técnicas de recuperação de imagem baseada em conteúdo para comparar o resultado da
execução de determinada GUI em teste, com o resultado esperado, também na forma
gráfica. Objetiva-se ainda a criação de um protótipo de uma ferramenta que permita
ao testador definir e parametrizar oráculos de teste para GUI em seu ambiente. Sendo
assim, o trabalho proposto segue a tendência do uso da automação para apoio ao teste
e, por isso, pretende-se apresentar um estudo de viabilidade de aplicação industrial do
teste de software automatizado para GUIs. Em resumo, o objetivo principal do trabalho
é a implementação de um oráculo passivo e heurı́stico capaz de apoiar o teste de sistemas
cuja a interação se dá por meio de interfaces GUI.
Ao final do projeto pretende-se ter uma visão mais aprimorada sobre os problemas
relacionados com a automatização de oráculos que utilizem informações na forma de ima-
gens, em lugar de informações convencionais como texto ou sinais. Deve-se disponibilizar
um protótipo de uma ferramenta de automatização de oráculo que emprega as técnicas
de recuperação de imagem baseada em conteúdo, o que constitui sólida contribuição.
5.2 Atividades
As atividades apresentadas nesta seção são divididas entre atividades requisitadas pelo
Programa de Pós-Graduação do ICMC e atividades técnicas propriamente ditas para o
desenvolvimento do trabalho proposto, o cronograma completo das atividades a serem
desenvolvidas é apresentado na Figura 5.1 sendo descritas a seguir:
5.2.1 Atividades requisitadas pelo Programa de Pós-Graduação

1 - disciplinas regulares do curso de mestrado do ICMC;
44
2 - elaboração e apresentação do exame de qualificação;
8 elaboração e defesa da dissertação.
5.2.2 Atividades Técnicas

Após o amadurecimento do projeto a partir das disciplinas cursadas, trabalhos apresen-
tados em Congressos e artigos publicados (devo anexar o artigo do SBES ??). Serão
mais bem elucidadas e desenvolvidas as atividades técnicas:
3 - estudo sobre definição e implementação de oráculos de teste, em particular aqueles

que tratam de programas com saı́das gráficas;
∙ Verificação na literatura a respeito de ferramentas que possam ser úteis no

contexto de oráculos para interfaces GUI.
∙ Investigação de métodos de monitoramento de execução de GUIs e métodos de
instrumentação de códigos.
4 estudo sobre recuperação de imagens baseada em conteúdo e tipos de caracterı́sticas

que podem interessar para a automatização de oráculos;
∙ Estudo de componentes Swing.

∙ Estudo de filtros de processamento de imagem capazes fazer pré-processamentos
úteis para o propósito do teste GUI.
∙ Definição de caracterı́sticas importante em interfaces GUI implementadas com
o toolkit Swing
5 avaliação da arquitetura originalmente proposta para possı́veis alterações e melhorias

que facilitem sua utilização;
∙ Incremento da arquitetura de acordo com as necessidades encontradas em eta-

pas anteriores da pesquisa.
6 implementação do protótipo do oráculo gráfico, extratores e funções de similaridade;
∙ Implementação de extratores, funções de similaridade, monitores de execução

e filtros de imagem para pré-processamento.
7 estudos de casos. Nesta atividade serão avaliadas a efetividade de utilização do

oráculo gráfico e a sua integração com a ferramenta de teste Proteum (Delamaro e
Maldonado, 1996) que apoia o teste de mutação.
45
∙ Implementação de sistemas cuja interação se dá por meio de GUI que utilizam
Swing como biblioteca
∙ Pesquisa sobre a aplicação do oráculo gráfico em sistemas prontos
∙ Estudo e integração dos experimentos com a ferramenta Proteum
9 elaboração de artigos.
∙ Escrita e Submissão de artigos para eventos nacionais e internacionais inte-

ressados em produção de software com qualidade ou diferentes abordagens de
Engenharia de Software.
5.2.3 Cronograma de Atividades
Figura 5.1: Cronograma de execução.
46
Referências Bibliográficas
Agerholm, S.; jean Lecoeur, P.; Reichert, E.; Electronique, D. Formal specification and
validation at work: A case study using vdm-sl. In: Proceedings of Second Workshop
on Formal Methods in Software Practice, ACM, 1998.
Andrews, J.; Fu, R.; Liu, V. Adding value to formal test oracles. In: Automated Software
Engineering, 2002. Proceedings. ASE 2002. 17th IEEE International Conference on,
2002, p. 275–278.
Ballard, D. H.; Brown, C. M. Computer vision. New Jersey: Prentice-Hall Inc, 1982.
Baresi, L.; Young, M. Test oracles. Technical Report CIS-TR-01-02, University of

Oregon, Dept. of Computer and Information Science, Eugene, Oregon, U.S.A., http:
//www.cs.uoregon.edu/˜michal/pubs/oracles.html, 2001.
Bellotti, R.; Carlo, F. D.; Tangaro, S.; Gargano, G.; Maggipinto, G.; Castellano, M.; Mas-
safra, R.; Cascio, D.; Fauci, F.; Magro, R.; Raso, G.; Lauria, A.; Forni, G.; Bagnasco,
S.; Cerello, P.; Zanon, E.; Cheran, S. C.; Torres, E. L.; Bottigli, U.; Masala, G. L.;
Oliva, P.; Retico, A.; Fantacci, M. E.; Cataldo, R.; Mitri, I. D.; Nunzio, G. D. A com-
pletely automated cad system for mass detection in a large mammographic database.
Medical Physics, v. 33, n. 8, p. 3066–3075, 2006.
Disponı́vel em http://link.aip.org/link/?MPH/33/3066/1
Binder, R. V. Testing object-oriented systems: models, patterns, and tools. Boston,

MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1999.
Biolchini, J.; Mian, P. G.; Natali, A. C. C.; Travassos, G. H. Sytematic review in software
engineering. Relatório Técnico, RT–ES 679/05 System Engineering and Computer Sci-
ence Dept., COOPE/UFRJ, 2005.
47
REFERÊNCIAS BIBLIOGRÁFICAS
Disponı́vel em http://alarcos.inf-cr.uclm.es/doc/MetoTecInfInf/Articulos/
es67905.pdf
Bloomfield, R. E.; Froome, P. K. D. The application of formal methods to the assessment

of high integrity software. IEEE Trans. Softw. Eng., v. 12, n. 9, p. 988–993, 1986.
Böhm, C.; Berchtold, S.; Keim, D. A. Searching in high-dimensional spaces: Index

structures for improving the performance of multimedia databases. ACM Comput.
Surv., v. 33, n. 3, p. 322–373, 2001.
Brown, D.; Roggio, R.; Cross, J.H., I.; McCreary, C. An automated oracle for software
testing. Reliability, IEEE Transactions on, v. 41, n. 2, p. 272–280, 1992.
Burkhard, W. A.; Keller, R. M. Some approaches to best-match file searching. Commun.

ACM, v. 16, n. 4, p. 230–236, 1973.
Chan, W.; Cheung, S.; Ho, J.; Tse, T. Reference models and automatic oracles for the
testing of mesh simplification software for graphics rendering. In: Computer Software
and Applications Conference, 2006. COMPSAC ’06. 30th Annual International, 2006,
p. 429–438.
Chan, W. K.; Ho, J. C. F.; Tse, T. H. Piping classification to metamorphic testing: An

empirical study towards better effectiveness for the identification of failures in mesh
simplification programs. In: COMPSAC (1), 2007, p. 397–404.
Chen, J.; Subramaniam, S. Specification-based testing for gui-based applications. Soft-

ware Quality Control, v. 10, n. 3, p. 205–224, 2002.
Ciaccia, P.; Patella, M.; Zezula, P. M-tree: An efficient access method for similarity se-
arch in metric spaces. In: VLDB ’97: Proceedings of the 23rd International Conference
on Very Large Data Bases, San Francisco, CA, USA: Morgan Kaufmann Publishers Inc.,
1997, p. 426–435.
Coppit, D.; Haddox-Schatz, J. On the use of specification-based assertions as test oracles.

In: Software Engineering Workshop, 2005. 29th Annual IEEE/NASA, 2005, p. 305–314.
Cultural, L. Grande enciclopédia larousse cultural. N. 18. São Paulo: Nova Cultural,
1998.
Datta, R.; Joshi, D.; Li, J.; Wang, J. Z. Image retrieval: Ideas, influences, and trends of
the new age. ACM Comput. Surv., v. 40, n. 2, p. 1–60, 2008.
Disponı́vel em http://dx.doi.org/10.1145/1348246.1348248
48
Delamaro, M. E.; Maldonado, J. C. Proteum - a tool for the assessment of test adequacy
for c programs: User’s guide. In: In Proceedings of the Conference on Performability
in Computing Systems (PCS 96, 1996, p. 79–95.
Delamaro, M. E.; Maldonado, J. C.; Jino, M. Introdução ao teste de software, v. 394 de

Campus. Elsevier, 2007.
Delamaro, M. E.; Maldonado, J. C.; Marthur, A. P. Interface mutation: An appro-

ach for integration testing. IEEE Transactions on Software Engineering, v. 27, n. 3,
p. 228–247, 2001.
DeMillo, R.; Offutt, A. Constraint-based automatic test data generation. Software

Engineering, IEEE Transactions on, v. 17, n. 9, p. 900–910, 1991.
DeMillo, R. A.; Lipton, R. J.; Sayward, F. G. Hints on test data selection: Help for the
practicing programmer. Computer, v. 11, n. 4, p. 34–41, 1978.
El-Naqa, I.; Yang, Y.; Galatsanos, N.; Nishikawa, R.; Wernick, M. A similarity lear-
ning approach to content-based image retrieval: application to digital mammography.
Medical Imaging, IEEE Transactions on, v. 23, n. 10, p. 1233–1244, 2004.
Fenkam, P.; Gall, H.; Jazayeri, M. Constructing corba-supported oracles for testing: a
case study in automated software testing. In: Automated Software Engineering, 2002.
Proceedings. ASE 2002. 17th IEEE International Conference on, 2002, p. 129–138.
Fischer, T.; Sadeghi, A.-R.; Winandy, M. A pattern for secure graphical user inter-
face systems. In: Database and Expert Systems Application, 2009. DEXA ’09. 20th
International Workshop on, 2009, p. 186–190.
Gaede, V.; Günther, O. Multidimensional access methods. ACM Comput. Surv., v. 30,
n. 2, p. 170–231, 1998.
Gonzalez, R. C.; Woods, R. E. Digital image processing (3rd edition). Upper Saddle
River, NJ, USA: Prentice-Hall, Inc., 2006.
Hafner, J.; Sawhney, H. S.; Equitz, W.; Flickner, M.; Niblack, W. Efficient color his-
togram indexing for quadratic form distance functions. IEEE Trans. Pattern Anal.
Mach. Intell., v. 17, n. 7, p. 729–736, 1995.
Hoffman, D. Using oracles in testing automation. In: Pacific Northwest Software

Quality Conference (PNSQC 2001), 2001.
49
Hoffman, D. Using oracles in testing and test automation. (1-3), 2006.

Disponı́vel em http://www.logigear.com/newsletter/using_oracles_in_
testing_and_test_automation_part1.asp
Hoffman, D.; Strooper, P. Automated module testing in prolog. Software Engineering,

IEEE Transactions on, v. 17, n. 9, p. 934–943, 1991.
Howden, W. E. A functional approach to program testing and analysis. IEEE Trans.

Softw. Eng., v. 12, n. 10, p. 997–1005, 1986.
Hummel, O.; Atkinson, C. Automated harvesting of test oracles for reliability testing.
In: COMPSAC ’05: Proceedings of the 29th Annual International Computer Software
and Applications Conference, Washington, DC, USA: IEEE Computer Society, 2005, p.
196–202.
Hunter, C.; Strooper, P. Systematically deriving partial oracles for testing concurrent
programs. In: ACSC ’01: Proceedings of the 24th Australasian conference on Computer
science, Washington, DC, USA: IEEE Computer Society, 2001, p. 83–91.
Jigloo SWT/Swing GUI Editor for Eclipse and WebSphere Cloudgarden v4.5.3. Online,
http://www.cloudgarden.com/jigloo/ - (accessado em 10/12/2009), 2009.
Jin, H.; Wang, Y.; Chen, N.-W.; Gou, Z.-J.; Wang, S. Artificial neural network for
automatic test oracles generation. In: Computer Science and Software Engineering,
2008 International Conference on, 2008, p. 727–730.
Kitchenham, B. Procedures for performing systematic reviews. Relatório Técnico, Keele

University and NICTA, 2004.
Disponı́vel em http://www.idi.ntnu.no/emner/empse/papers/kitchenham_2004.
pdf
Li, J.; Liu, H.; Seviora, R. Constructing automated protocol testing oracles to accom-
modate specification nondeterminism. In: Computer Communications and Networks,
1997. Proceedings., Sixth International Conference on, 1997, p. 532–537.
Li, P.; Wohlstadter, E. View-based maintenance of graphical user interfaces. In: AOSD
’08: Proceedings of the 7th international conference on Aspect-oriented software deve-
lopment, New York, NY, USA: ACM, 2008, p. 156–167.
Lieberman, H.; Rozenweig, E.; Singh, P. Aria: An agent for annotating and retrieving
images. Computer, v. 34, n. 7, p. 57–62, 2001.
50
M. Stuart. Java gui builders. Online, http://www.fullspan.com/articles/

java-gui-builders.html - (accessado em 10/12/2009), 2009.
Mafra, S. N.; Travassos, G. H. Estudos primários e secundários apoiando a busca

por evidência em engenharia de software. Relatório Técnico, PESC - Programa de
Engenharia de Sistemas de Computação - COOPE/UFRJ, Rio de Janeiro - RJ, 2006.
Disponı́vel em http://lens.cos.ufrj.br:8080/ESEWEB/materials/Mafra_
Travassos_RT68706.pdf
Manjunath, B.; Ma, W. Texture features for browsing and retrieval of image data. Pat-
tern Analysis and Machine Intelligence, IEEE Transactions on, v. 18, n. 8, p. 837–842,
1996.
Mayer, J.; Guderlei, R. On random testing of image processing applications. In: QSIC
’06: Proceedings of the Sixth International Conference on Quality Software, Washing-
ton, DC, USA: IEEE Computer Society, 2006, p. 85–92.
McDonald, J.; Strooper, P. Translating object-z specifications to passive test oracles.

In: Formal Engineering Methods, 1998. Proceedings. Second International Conference
on, 1998, p. 165–174.
Memon, A.; Banerjee, I.; Hashmi, N.; Nagarajan, A. Dart: A framework for regres-
sion testing ”nightly/daily builds”of gui applications. In: ICSM ’03: Proceedings of
the International Conference on Software Maintenance, Washington, DC, USA: IEEE
Computer Society, 2003a, p. 410.
Memon, A.; Nagarajan, A.; Xie, Q. Automating regression testing for evolving gui
software. Journal of Software Maintenance, v. 17, n. 1, p. 27–64, 2005.
Memon, A.; Xie, Q. Using transient/persistent errors to develop automated test oracles
for event-driven software. In: Automated Software Engineering, 2004. Proceedings.
19th International Conference on, 2004a, p. 186–195.
Memon, A. M. Employing user profiles to test a new version of a gui component in its
context of use. Software Quality Control, v. 14, n. 4, p. 359–377, 2006.
Memon, A. M. An event-flow model of gui-based applications for testing: Research

articles. Softw. Test. Verif. Reliab., v. 17, n. 3, p. 137–157, 2007.
Memon, A. M.; Banerjee, I.; Nagarajan, A. What test oracle should I use for effective
GUI testing? In: Proceedings of the IEEE International Conference on Automated
Software Engineering, IEEE Computer Society, 2003b, p. 164–173.
51
Memon, A. M.; Xie, Q. Empirical evaluation of the fault-detection effectiveness of

smoke regression test cases for gui-based software. In: ICSM ’04: Proceedings of the
20th IEEE International Conference on Software Maintenance, Washington, DC, USA:
IEEE Computer Society, 2004b, p. 8–17.
Memon, A. M.; Xie, Q. Studying the fault-detection effectiveness of GUI test cases for
rapidly evolving software. IEEE Trans. Softw. Eng., v. 31, n. 10, p. 884–896, 2005.
Myers, G. J.; Sandler, C. The art of software testing. 2 ed. John Wiley & Sons, Inc.,
Hoboken, New Jersey, 234 p., 2004.
Ogle, V. E.; Stonebraker, M. Chabot: Retrieval from a relational database of images.

Computer, v. 28, n. 9, p. 40–48, 1995.
Oliveira, R. A. P. Estrutura para utilização de cbir em oráculos gráficos. Trabalho de

conclusão de curso apresentado ao curso de ciência da computação, Centro Universitário
Eurı́pides de Marı́lia – UNIVEM, Marı́lia - SP, 2008.
Oliveira, R. A. P.; Delamaro, M. E.; Nunes, F. L. S. Estrutura para utilização de

Recuperação de Imagem Baseada em Conteúdo em oráculos de teste de software com
saı́da gráfica. In: Anais do WVC’08 - Workshop de Visão Computacional (WVC
2008), Bauru – SP – Brasil, 2008, p. 205–210.
Oliveira, R. A. P.; Delamaro, M. E.; Nunes, F. L. S. O-FIm - Oracle for Images. In:
Sessão de Ferramentas 2009 - XVI Sessão de Ferramentas - SBES (Simpósio Brasileiro
de Engenharia de Software), Fortaleza – CE – Brasil, 2009a, p. 1 – 6.
Oliveira, R. A. P.; Delamaro, M. E.; Nunes, F. L. S. Oráculos de Teste para Domı́-

nios GUI: Uma Revisão Sistemática. In: SAST 2009 - Workshop Brasileiro de Teste
de Software Sistemático e Automatizado - SBMF‘09(Simpósio Brasileiro de Métodos
Formais), Gramado – RS – Brasil, 2009b, p. 22 – 32.
Paiva, A.; Faria, J. C. P.; Vidal, R. F. A. M. Towards the integration of visual and formal
models for gui testing. Electr. Notes Theor. Comput. Sci., v. 190, n. 2, p. 99–111, 2007.
Paquerault, S.; Yarusso, L. M.; Papaioannou, J.; Jiang, Y.; Nishikawa, R. M. Radial
gradient-based segmentation of mammographic microcalcifications: observer evaluation
and effect on cad performance. Med Phys, v. 31, n. 9, p. 2648 – 2657., 2004.
Peters, D.; Parnas, D. L. Generating a test oracle from program documentation: work
in progress. In: ISSTA ’94: Proceedings of the 1994 ACM SIGSOFT international
symposium on Software testing and analysis, New York, NY, USA: ACM, 1994, p.
58–65.
52
Peters, D. K.; Parnas, D. L. Using test oracles generated from program documentation.
IEEE Transactions on Software Engineering, v. 24, n. 3, p. 161–173, 1998.
Petrakis, E.; Faloutsos, C.; Lin, K.-I. Imagemap: an image indexing method based on
spatial similarity. Knowledge and Data Engineering, IEEE Transactions on, v. 14,
n. 5, p. 979–987, 2002.
Rapps, S.; Weyuker, E. Selecting software test data using data flow information. Soft-
ware Engineering, IEEE Transactions on, v. SE-11, n. 4, p. 367–375, 1985.
Reddi, V. J.; Connors, D.; Cohn, R.; Smith, M. D. Persistent code caching: Exploiting
code reuse across executions and applications. In: CGO ’07: Proceedings of the In-
ternational Symposium on Code Generation and Optimization, Washington, DC, USA:
IEEE Computer Society, 2007, p. 74–88.
Richardson, D.; Aha, S.; O’Malley, T. Specification-based test oracles for reactive sys-
tems. In: Software Engineering, 1992. International Conference on, 1992, p. 105–118.
Rubner, Y.; Tomasi, C.; Guibas, L. A metric for distributions with applications to image
databases. In: Computer Vision, 1998. Sixth International Conference on, 1998, p.
59–66.
Smeulders, A.; Worring, M.; Santini, S.; Gupta, A.; Jain, R. Content-based image
retrieval at the end of the early years. Pattern Analysis and Machine Intelligence,
IEEE Transactions on, v. 22, n. 12, p. 1349–1380, 2000.
Smith, J. Integrated spatial and feature image systems: Retrieval. Tese de Doutora-
mento, School of Arts and Sciences - Columbia University, New York City -New York
- USA, 1997.
Disponı́vel em citeseer.ist.psu.edu/smith97integrated.html
Sneed, H. M.; Mérey, A. Automated software quality assurance. IEEE Trans. Softw.
Eng., v. 11, n. 9, p. 909–916, 1985.
Sommerville, I. Software engineering. 5 ed. Redwood City, CA, USA: Addison Wesley
Longman Publishing Co., Inc., 1995.
Swain, M. J.; Ballard, D. H. Color indexing. Int. J. Comput. Vision, v. 7, n. 1, p. 11–32,

1991.
Swing Designer v7.2.0 Instantiations. Online, http://www.instantiations.com/

windowbuilder/swingdesigner/index.html - (accessado em 10/12/2009), 2009.
53
Traina, C., J.; Traina, A.; Faloutsos, C.; Seeger, B. Fast indexing and visualization of
metric data sets using slim-trees. Knowledge and Data Engineering, IEEE Transactions
on, v. 14, n. 2, p. 244–260, 2002.
Treharne, H.; Draper, J.; Schneider, S. Test case preparation using a prototype. In: B
’98: Proceedings of the Second International B Conference on Recent Advances in the
Development and Use of the B Method, London, UK: Springer-Verlag, 1998, p. 293–311.
Tse, T. H.; Lau, F. C. M.; Chan, W. K.; Liu, P. C. K.; Luk, C. K. F. Testing
object-oriented industrial software without precise oracles or results. Commun. ACM,
v. 50, n. 8, p. 78–85, 2007.
Vasconcelos, N. On the efficient evaluation of probabilistic similarity functions for image

retrieval. Information Theory, IEEE Transactions on, v. 50, n. 7, p. 1482–1496, 2004.
Visual Editor V1.2 Ibm. Online, http://www.eclipse.org/vep/WebContent/main.

php - (accessado em 10/12/2009), 2009.
Weyuker, E. J. On Testing Non-Testable Programs. The Computer Journal, v. 25, n. 4,

p. 465–470, 1982.
Disponı́vel em http://comjnl.oxfordjournals.org/cgi/content/abstract/25/4/
465
Wilkins, P.; Ferguson, P.; Smeaton, A. F. Using score distributions for query-time
fusion in multimediaretrieval. In: MIR ’06: Proceedings of the 8th ACM international
workshop on Multimedia information retrieval, New York, NY, USA: ACM, 2006, p.
51–60.
Xie, Q. Developing cost-effective model-based techniques for gui testing. Tese de Dou-
toramento, College Park, MD, USA, adviser-Memon, Atif, 2006a.
Xie, Q. Developing cost-effective model-based techniques for gui testing. In: ICSE ’06:
Proceedings of the 28th international conference on Software engineering, New York,
NY, USA: ACM, 2006b, p. 997–1000.
Xie, Q.; Memon, A. M. Designing and comparing automated test oracles for gui-based
software applications. ACM Trans. Softw. Eng. Methodol., v. 16, n. 1, p. 4, 2007.
Ye, M.; Feng, B.; Zhu, L. Automated oracle based on multi-weighted neural networks
for gui testing. Information Technology Journal 6, v. 3, p. 370–375, 2007.
Zhu, H. A note on test oracles and semantics of algebraic specifications. In: Quality
Software, 2003. Proceedings. Third International Conference on, 2003, p. 91–98.
54

Quali Rafael Oraculos

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Quali Rafael Oraculos

Enviado por

Direitos autorais:

Formatos disponíveis

Apoio à automatização de oráculos de teste para

programas com interfaces gráﬁcas

Rafael Alves Paes de Oliveira

Data de Depósito: 22 de dezembro de 2009

Apoio à automatização de oráculos de teste para programas com

Rafael Alves Paes de Oliveira

Orientador: Prof. Dr. Márcio Eduardo Delamaro

Monograﬁa apresentada ao Instituto de Ciências Mate-

USP - São Carlos

Oráculos de Teste são um dos desaﬁos a serem enfrentados no que se

3 Revisão Bibliográﬁca Sistemática 19

4 CBIR no Apoio a Oráculos de Teste 28

5.1 Cronograma de execução. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.1 Oráculos por sua Forma de Automatização . . . . . . . . . . . . . . . . . . 13

3.1 Seleção Final de artigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

para reduzir os custos do teste de software. Em linhas gerais, a automatização do teste

Wohlstadter, 2008). Apesar da crescente das ferramentas de apoio ao desenvolvimento

consequência, de seus processos de teste, aumenta a importância de se automatizarem

2.1 Oráculos de Teste: Deﬁnições e Conceitos

projetados e implementados por programadores usando ferramentas de anotação de có-

2.1.1 Taxonomia de Oráculos

∙ ativos: responsáveis por diretamente dirigir ou coordenar as atividades de testes.

Como pode-se perceber, num determinado ambiente de desenvolvimento e teste, o orá-

1. axiomas ou premissas de teste;

2. outro programa (teste duplo), ou

3. uma especiﬁcação formal.

∙ Oráculos Baseados em Modelos Formais: Se existe para um programa qualquer um

∙ Oráculos Baseados em Documentação/Especiﬁcação: A capacidade de testar um

∙ Oráculos Baseados na execução de outros programas: Em algumas situações um

decidir sobre a aceitação de P por meio da comparação do comportamento P(T)

∙ Oráculos para o Teste de Mutação: Na aplicação do teste de mutação (DeMillo et

Tabela 2.1: Oráculos por sua Forma de Automatização

2.1.1.1 Oráculo Humano

Ressalta-se que na indústria de desenvolvimento de software, muitas vezes, o papel de

2.1.2 Diﬁculdade na Implementação de Mecanismos de oráculos

∙ Como determinar o sucesso ou fracasso de casos de teste a partir de Especiﬁcações.

∙ Como determinar o sucesso ou fracasso de casos de teste a partir de Heurı́sticas

gerar e comparar os resultados das execuções de um sistema qualquer pode exigir

∙ Custo de Implementação. O problema conﬁgurado quando se deseja veriﬁcar a regu-

Algumas abordagens relatam a implementação de oráculos automatizados para dife-

2.2 Trabalhos Relacionados

métodos para o desenvolvimento de oráculos de teste, como os que utilizam especiﬁcações

2.3 Considerações Finais

3.1 Planejamento e Condução

∙ critério de seleção de fontes: disponibilidade de consulta de artigos por meio ele-

– “testing oracle” ou “automated oracle”; relacionados com os termos

∙ fontes de busca: foram selecionadas bases de dados eletrônicas indexadas. As fontes

∙ tipos de estudos primários: artigos contemplando métodos de geração ou utilização

Critérios e Procedimentos para Seleção dos Estudos Primários: o critério de inclusão

∙ Seleção Preliminar : Foi confeccionada e executada uma string de busca em cada

∙ Seleção Final e Extração de Resultados: O processo de seleção ﬁnal consiste na

Condução da Revisão: Seguindo o protocolo acima apresentado, a revisão foi conduzida

3.2 Análise de Resultados

Tabela 3.1: Seleção Final de artigos

3.2.1 Oráculos de Teste para GUI

testar GUIs baseando-se em deﬁnições de sequência de eventos, widgets, propriedades,

disso são coordenadas em uma tela, tamanho de widgets ou cores de componentes e o

3.3 Considerações Finais

4.1 CBIR - Content Based Image Retrieval

Tradicionalmente as pesquisas em bases de imagens utilizam palavras-chaves Lieber-

representar aspectos de estruturas contidas na imagem gerada pelo programa em teste.

Conclui-se que sistemas CBIR permitem a recuperação de um conjunto ﬁnito de ima-