• Nenhum resultado encontrado

TESTANDO APLICAÇÕES DE BANCO DE DADOS COM ANÁLISE DE INSTÂNCIAS DE DADOS ALTERNATIVAS

N/A
N/A
Protected

Academic year: 2021

Share "TESTANDO APLICAÇÕES DE BANCO DE DADOS COM ANÁLISE DE INSTÂNCIAS DE DADOS ALTERNATIVAS"

Copied!
21
0
0

Texto

(1)

TESTANDO APLICAÇÕES DE BANCO DE DADOS COM ANÁLISE DE INSTÂNCIAS DE DADOS ALTERNATIVAS

TESTING DATABASE APPLICATIONS WITH THE ALTERNATIVE DATA INSTANCE ANALYSIS

João Carlos Garcia Árias Faculdade de Ciências Sociais e Aplicadas do Paraná - FACET Universidade Federal do Paraná – UFPR E-mail: {joaoc,silvia}@inf.ufpr.br

Maria Cláudia Figueiredo Pereira Emer Universidade Tecnológica Federal do Paraná - UTFPR

E-mail: mclaudia@dainf.ct.utfpr.edu.br

Silvia Regina Vergilio Universidade Federal do Paraná – UFPR E-mail: silvia@inf.ufpr.br

RESUMO

Para garantir a qualidade e confiabilidade dos dados manipulados por uma aplicação de software, a abordagem denominada Análise de Instâncias de Dados Alternativas (AIDA) foi proposta. Esta abordagem inclui um metamodelo que permite o teste de diferentes tipos de esquema de dados. As instâncias de dados alternativas são geradas modificando-se uma instância original, e são utilizadas para revelar possíveis defeitos que podem estar presentes nos esquemas em teste. Estes possíveis defeitos se presentes no esquema podem ocasionar falhas na aplicação, pois o esquema incorreto permitirá que a aplicação manipule dados inválidos e/ou incorretos. Considerando este fato, neste trabalho, é proposta a utilização da AIDA para o teste de aplicações de banco de dados em diferentes contextos. Um experimento de validação desta proposta foi conduzido com três aplicações reais de banco de dados relacional. Os resultados mostram a aplicabilidade e a capacidade de revelar defeitos da AIDA não só associados aos esquemas testados, mas também com relação à própria aplicação. Palavras-Chave: Esquemas de dados; banco de dados relacional; teste baseado em defeitos. ABSTRACT

To ensure the quality and reliability of the data manipulated by a software application, an approach, called Alternative Data Instance Analysis (ADIA) was proposed. This approach includes a metamodel, which allows the test of different kind of data schemas. The alternative data instances are generated by modifying a provided original instance and, are used to reveal faults that are possibily in the schema under test. When such possible faults are in the schemas, failures can occur in the application, since the faulty schema permit that the application manipulates invalid or incorrect data. Considering this fact, this work proposes the use of ADIA to test of database applications in different contexts. A validation experiment was conducted with three real relational database applications. The results show the applicability of the approach and its ability to reveal faults, which are not only associated to the tested schemas, but are also related to the software application.

(2)

1 INTRODUÇÃO

Aplicações de banco de dados manipulam e armazenam dados extremamente importantes para operações de negócio das empresas; dados descritos por esquemas. O esquema de dados define a estrutura lógica e os relacionamentos entre os dados, e, portanto o teste de esquema por meio de abordagens, critérios e ferramentas de teste é uma forma de assegurar a qualidade dos dados manipulados por uma aplicação de software. Se o esquema estiver incorreto, ou seja, se alguma definição referente aos dados contiver algum defeito em relação à especificação dos dados, informações inválidas podem ser aceitas pela aplicação, podendo causar falhas, ou ainda, dados válidos podem não ser aceitos, também gerando resultados inesperados no processamento da aplicação.

Para auxiliar a detectar defeitos em esquemas e para garantir a integridade dos dados por eles definidos foi proposta uma abordagem de teste baseado em defeitos, denominada, Análise de Instâncias de Dados Alternativas (AIDA) [9]. Na abordagem AIDA, uma instância de dados associada ao esquema em teste sofre alterações simples gerando instâncias de dados alternativas. Cada alternativa representa possíveis defeitos que podem estar presentes no esquema, e é gerada a partir de classes de defeitos previamente definidas a partir de um modelo genérico capaz de representar os mais variados tipos de esquemas de dados. Consultas às instâncias geradas são executadas e os resultados destas consultas, se diferentes do esperado, apontam que defeitos estão presentes no esquema, pois as instâncias consultadas foram consideradas válidas para o esquema. Para aplicação desta abordagem está disponível a ferramenta XTool (XML and Relational Database Schema Testing Tool) [16] que permite o teste de dois tipos de esquemas: esquemas XML escritos em XML Schema [23]; e esquemas de banco de dados relacional para o SGBD PostGreSQL [18].

Na literatura são poucos os trabalhos que visam o teste de esquemas de dados. Os existentes focalizam esquemas para XML [12,15]. A AIDA é uma abordagem genérica que pode ser aplicada para testar diferentes tipos de esquema.

(3)

No contexto de bancos de dados relacional, existem alguns trabalhos que utilizam informações sobre o esquema de dados para testar a aplicação de software que utiliza o esquema. Robbert e Maryanski [19] usam informações obtidas do esquema de banco de dados para gerar um plano de teste para a aplicação de banco de dados. Chan e Cheung. [3] propõem uma abordagem baseada em defeitos para testar sentenças SQL de uma aplicação de banco de dados, usando informações capturadas do modelo de dados conceitual para gerar sentenças SQL mutantes. Embora estes trabalhos utilizem informação que podem ser derivadas do esquema, eles não visam o teste da aplicação pensando em defeitos presentes no esquema e que poderão estar refletidos na aplicação. Com o objetivo de revelar estes outros tipos de defeitos nas aplicações de software que manipulam dados descritos por um esquema, este trabalho propõe a utilização da AIDA no teste de aplicações de software.

Como mencionado a abordagem AIDA permite o teste de diferentes tipos de esquema, e portanto, o artigo procura mostrar que a abordagem também pode ser utilizada no contexto de diferentes aplicações de software, aplicações que manipulam documentos XML, serviços Web, e etc.

A proposta é avaliada por meio de um estudo de caso, no contexto de aplicações de banco de dados relacional. A idéia é verificar a aplicabilidade e a eficácia da AIDA em revelar defeitos por meio do uso das instâncias de dados alternativas, geradas a partir do esquema do banco de dados, como entradas (dados de teste) para o teste da aplicação que manipula os dados descritos pelo esquema. Assim sendo, um experimento foi conduzido para testar três aplicações de banco de dados reais. A ferramenta XTool foi utilizada para aplicar a abordagem de teste AIDA nos esquemas das aplicações de banco de dados e gerar os dados de teste utilizados no teste dessas aplicações.

O artigo é organizado como segue. A Seção 2 apresenta a abordagem de teste AIDA. A Seção 3 aborda diferentes contextos de teste nos quais a AIDA pode ser utilizada para o teste de aplicações de software que usam esquemas de dados.

(4)

A Seção 4 descreve o experimento conduzido, no qual a AIDA foi empregada no teste de aplicações de banco de dados relacional e analisa os resultados obtidos. A Seção 5 descreve trabalhos relacionados. A Seção 6 apresenta as conclusões e trabalhos futuros.

2 ANÁLISE DE INSTÂNCIAS DE DADOS ALTERNATIVAS

A Análise de Instâncias de Dados Alternativas (AIDA) foi introduzida em [9] para realizar o teste baseado em defeitos de diversos tipos de esquemas de dados: esquemas XML, esquemas para bases de dados relacionais, ou orientadas a objetos, e etc. Na verdade a AIDA permite o teste de um esquema de dados desde que ele possa ser representado por um metamodelo M, tal como o apresentado na Fig. 1. Por exemplo, considere o esquema representado pelo diagrama ER da Fig. 2a. Na Fig. 2b é apresentada sua representação de acordo com M, e a DDL correspondente é apresentada na Fig. 2c.

(5)

Figura 2 - Diagrama Entidade-Relacionamento, representação conforme M e DDL correspondente

a) Diagrama Entidade-Relacionamento

b) Representação do DER conforme M

CREATE TABLE course ( id_course int IDENTITY,

name varchar(40) NOT NULL,

id_course_type int NOT NULL, duration int NOT NULL )

go

ALTER TABLE course

ADD PRIMARY KEY NONCLUSTERED (id_course) go

c) DDL relacionada ao DER

A partir dessa representação um modelo formal é derivado, representando os componentes do esquema: atributos/elementos e restrições para eles. Um esquema S é denotado por S=(E,A,R,P), onde:

o E é um conjunto finito de entidades (elementos);

o A é um conjunto finito de atributos;

o R é um conjunto finito de restrições referentes a domínio, definição,

relacionamentos e semântica dos elementos e atributos;

o P é um conjunto de regras de associações entre elementos, atributos e

restrições.

Considerando U=EA. As regras de associações são representadas por :

o p(x,y)|x,yExy;

o p(x,r)|xErR;

o p(x,r,SU)|xUrRSU={u1,u2,...,um}⊂U,uix,1≤im,m≥1, onde m é o número de

(6)

A seguir é apresentado um fragmento de uma representação formal S para

o esquema de um banco de dados relacional considerando o exemplo da Fig. 2.

P) R, A, (E, = S

{course,course type}

=

E _

{ID course,name,duration,ID course type,description}

=

A _ _ _

{type,key,use,length,uniqueness,association}

= R                                 ) uniqueness on, (descripti p length), on, (descripti p use), on, (descripti p type), on, (descripti p key), type, course (ID p type), type, course (ID p course), e, associativ type, (course p n), descriptio type, (course p type), course ID type, (course p use), (duration, p type), (duration, p length), (name, p use), (name, p type), (name, p key), course, (ID p type), course, (ID p type), course key, (course, p type), course n, associatio (course, p duration), (course, p name), (course, p course), ID (course, p = P 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 _ _ _ _ _ _ _ _ _ _ _ _ _ _

De acordo com a representação formal, os componentes do esquema são associados a defeitos que eles podem conter, formando as associações de defeitos. Os defeitos usualmente introduzidos em esquemas de dados durante seu desenvolvimento ou evolução foram agrupados em quatro classes de acordo com o tipo de restrição aos dados de elementos (entidades) ou atributos: domínio, definição, relacionamento e semântica. A abordagem revela os defeitos identificados nas classes de defeitos, com respeito à definição incorreta ou ausente de restrições aos dados no esquema. A Tabela 1 apresenta as classes de defeitos que podem estar presente em um esquema.

Considerando as classes de defeitos, o esquema S, e que na especificação

de S foi prevista uma restrição de tamanho para o atributo name, uma possível

associação de defeito é a relação entre o atributo name e a classe de defeito TI (Tamanho Incorreto), indicando que o elemento name pode conter um defeito relacionado a uma definição incorreta de tamanho.

(7)

As associações de defeitos estão relacionadas a padrões de alteração, que são aplicados a uma instância original de dados, que quando modificada gera uma instância de dados alternativa. A Tabela 2 apresenta um exemplo de uma instância original de dados para o exemplo da Fig. 2.

Diferentes instâncias alternativas são geradas, representando os possíveis defeitos no esquema de acordo com as classes de defeito. As associações de defeito também estão associadas a padrões de consultas que serão executadas nas instâncias alternativas e cujos resultados poderão indicar um defeito no esquema. Um exemplo de instância alternativa para a instância de dados original seria, por exemplo, trocar o valor do atributo name de “Computer science” para “Computer science xxxxxxxxxxxxxxxxxxx”. Um exemplo de consulta em SQL a ser realizada nesta instância de dados alternativa é apresentado a seguir:

select name from course

Esta consulta produzirá como resultado um elemento cujo número de caracteres é maior que o número máximo constante em sua especificação, que quando analisado indicará que o esquema possui um defeito, pois validou um nome com um tamanho muito superior ao desejado, de acordo com a especificação.

(8)

Tabela 1 - Classes de defeito para esquemas

Classe de defeito Descrição

Grupo 1 – Restrições de domínio

TDI - Tipo de Dado Incorreto Definição incorreta do tipo de dado

VI - Valor Incorreto Valor padrão ou fixo definido incorretamente

VEI - Valores Enumerados Incorretos

Definição incorreta do conjunto de valores permitidos

VMMI - Valores Máximos e

Mínimos Incorretos Definição incorreta de valores limites TI - Tamanho Incorreto Número de caracteres máximos e mínimos

permitidos definidos incorretamente CEBI - Caracteres de Espaço em

Branco Incorreto

Definição incorreta de tipos especiais de espaços em branco permitidos

Grupo 2 - Restrições de definição

UI - Uso Incorreto Definição incorreta de uso (opcional ou obrigatório)

UNI- Unicidade Incorreta Definição incorreta do número de ocorrências permitidas

II - Identificador Incorreto Definição incorreta de um identificador Grupo 3 - Restrições de relacionamento

OI - Ocorrência Incorreta Número máximo e mínimo de repetições definido incorretamente

AI - Associação Incorreta

Definição incorreta de cardinalidade (número de ocorrências de um elemento em relação a outro elemento em um relacionamento),

generalização/especialização (um ou mais elementos herdam propriedades de um outro elemento), agregação (um elemento é parte ou está contido em outro elemento), elemento associativo (relacionamento que possui atributos e sua existência depende da existência do relacionamento)

Grupo 4 - Restrições semânticas

COI - Condição Incorreta Definição incorreta de uma condição, que deve ser satisfeita pelos dados

(9)

Tabela 2 - Exemplo de uma instância original de dados Course

ID_course Name ID_course_type duration

1 Computer science 1 4

2 Computation Engineering 1 5

3 Database 3 2

4 Images Processing 4 2

Para apoiar a utilização da abordagem AIDA, a ferramenta XTool [16] foi implementada. Essa ferramenta permite o teste de esquemas XML escritos em XML Schema e o teste de esquemas de banco de dados relacionais para o SGBD (Sistema de Gerenciamento de Banco de Dados) PostGreSQL [18].

A ferramenta usa JDBC (Java Database Connectivity [21]) para manipular e consultar informações no banco de dados. A XTool implementa os passos necessários para a aplicação da AIDA conforme ilustrado na Fig. 3.

O teste é executado pela XTool independentemente da aplicação que utiliza os esquemas; porém, é necessário que a especificação dos dados da aplicação esteja disponível para que os resultados do teste possam ser analisados pelo testador.

A seguir uma breve descrição das principais funções da XTool é apresentada.

a. Gerar representação formal – o esquema em teste é representado por elementos, atributos, restrições e regras de associação entre os elementos, atributos e restrições. A ferramenta processa o teste com base nessa representação, gerando as associações, as instâncias alternativas de dados e as consultas;

b. Identificar/Selecionar associações – o conjunto de associações de defeito relaciona elementos ou atributos do esquema às classes de defeitos, por meio da representação formal ou manualmente pelo testador. As associações que

(10)

serão exploradas para revelar defeitos devem ser selecionadas para que as instâncias de dados alternativas e as consultas sejam geradas;

c. Gerar instâncias alternativas – as instâncias de dados alternativas são obtidas com base no conjunto de associações de defeito e no padrão de alterações, definido para cada classe de defeito;

d. Gerar consultas – as consultas às instâncias de dados alternativas geradas são obtidas de acordo com as associações selecionadas, segundo um padrão de consultas pré-estabelecido em cada classe de defeito;

e. Executar dados de teste – os dados de teste, formados pelas consultas e instâncias de dados alternativas segundo as associações, são executados pela ferramenta;

f. Gerar resultados – os resultados obtidos com a execução dos dados de teste são gerados e disponibilizados ao testador por meio de um relatório. Dessa forma, o testador verifica se os resultados obtidos estão em concordância com os resultados esperados, de acordo com a especificação dos dados.

(11)

3 TESTANDO APLICAÇÕES COM AIDA

A AIDA pode ser aplicada no teste de diferentes tipos de esquema desde que estes sejam representados formalmente de acordo com o modelo e notação apresentados na seção anterior [9]. A abordagem foi explorada para o teste de esquemas XML [8], e no teste de esquemas de banco de dados relacional [10,11].

Este trabalho entretanto, explora o uso da abordagem AIDA no teste das aplicações que utilizam o esquema em teste e propõe uma abordagem que pode também ser utilizada em diferentes contextos, ilustrados esquematicamente na Fig. 4. Nesta proposta, os dados de teste são as instâncias alternativas geradas pela abordagem de teste de esquemas AIDA, que ao invés de serem utilizados para o teste do esquema, são também utilizados como entradas (dados de teste) para as aplicações de software que manipulam estes dados.

• Caso A: A partir de um esquema XML: as alternativas geradas são documentos XML, que podem ser utilizados para o teste de aplicações Web, teste de componentes que trocam mensagens XML, e etc.

• Caso B: A partir de um esquema ER: as alternativas de dados são bases de dados relacionais que são utilizadas para o teste da aplicação que utiliza o banco de dados relacional.

• Caso C: A partir de um documento WSDL: as interações entre Web Services geralmente acontecem utilizando SOAP e WSDL, que são documentos no formato XML. Neste caso, pode-se considerar o WSDL um esquema. O teste do Web Service pode acontecer a partir de mensagens SOAP modificadas.

(12)

Figura 4 - Utilização da AIDA para o teste de aplicações

4 EXPERIMENTO CONDUZIDO

Para avaliar a proposta de utilizar a abordagem AIDA no teste de aplicações foi realizado um experimento no contexto do teste de aplicações que lidam com banco de dados relacional e esquemas ER (Caso B da Fig. 4). Nesta seção, a metodologia utilizada na avaliação é descrita e os resultados obtidos são analisados.

4.1 Sistemas Utilizados

Três sistemas desenvolvidos por uma empresa pública foram utilizados, que por questões de sigilo são identificados por S1, S2 e S3. S1 é uma solução para o registro de informações referentes a realizações governamentais, integrada a sistemas operacionais de planejamento orçamentário e execução financeira, sendo que estes registros são consolidados em um banco de dados único, objetivando a visualização integrada e consistente das realizações de governo por meio de ferramentas de Inteligência de Negócio e de Georeferenciamento.

(13)

S2 é uma solução para o controle de atendimentos (solicitações, sugestões, reclamações, elogios e denúncias a respeito de ações governamentais), permitindo o acompanhamento das solicitações abertas pelo cidadão e comunicação direta com os servidores cadastrados no sistema. S3 tem por objetivo permitir o acompanhamento físico e o controle financeiro de programas de desenvolvimento sustentável, permitindo a consolidação das informações em demonstrativos com propósito de auditoria externa.

4.2 Passos Executados

Dois tipos de teste foram executados nos sistemas utilizados para o experimento. Primeiramente, os esquemas usados pelos sistemas foram testados. Após isto, as instâncias de dados alternativas geradas no teste dos esquemas foram utilizadas no teste das aplicações. O objetivo foi avaliar a aplicabilidade e eficácia da abordagem AIDA.

Para verificar a eficácia da estratégia, foram inseridos defeitos nas aplicações relacionados aos esquemas em teste. Os defeitos foram revelados durante o desenvolvimento das aplicações e estavam registrados na documentação associada a cada sistema. Estes defeitos foram re-implantados gerando assim uma versão incorreta da aplicação contendo todos os defeitos. Os defeitos são bastante variados, mas foram divididos em defeitos do esquema em teste e defeitos da aplicação.

As informações sobre os esquemas, entidades e tipos de defeitos inseridos são apresentadas na Tabela 3, podendo-se ter também uma noção da complexidade de cada esquema.

(14)

Tabela 3 - Programas/esquemas testados sistema esquemas

testados/total

entidades testadas/total

atributos restrições registros defeitos inseridos esquema aplicação

S1 1/2 7/70 89 16 46 3 8

S2 1/1 5/40 122 18 37 1 7

S3 1/1 5/55 27 3 54 0 5

O teste de apenas um esquema de cada aplicação foi realizado, de modo que o esquema selecionado foi o esquema considerado principal com relação à importância dos dados descritos. Para simplificar o processo de teste, nos sistemas S1 e S2 foram testadas apenas as entidades de cada esquema relacionadas aos defeitos semeados. No sistema S3 foi realizado o teste considerando todas as entidades relacionadas ao único esquema contido na aplicação, tendo em vista que as entidades deste esquema possuem uma complexidade relativamente baixa.

Em uma primeira etapa, a abordagem de teste AIDA foi aplicada para o teste de cada esquema utilizado no experimento, por meio da ferramenta XTool.

Todas as associações de defeito identificadas nos esquemas pela XTool por meio do modelo formal gerado foram usadas no teste. As instâncias originais foram obtidas a partir de registros existentes em cada entidade. As instâncias de dados alternativas e as consultas foram geradas com base nas associações identificadas nos esquemas. As consultas foram automaticamente executadas sobre as instâncias de dados alternativas, e o teste do esquema foi realizado com a análise dos resultados obtidos. Os dados gerados nesta etapa do experimento são apresentados na Tabela 4.

Tabela 4 - Resultados do teste de esquemas

sistema associações de defeito número de instâncias número de consultas válidas inválidas

S1 71 88 79 159

S2 165 131 264 254

(15)

Na segunda etapa do experimento, as instâncias de dados alternativas válidas (bases de dados) geradas pela XTool foram utilizadas como dados de teste para o teste da aplicação, conforme Caso B descrito na seção anterior.

O número de defeitos revelados na primeira e na segunda etapa é apresentado na Tabela 5, bem como, o número de defeitos semeados em cada sistema.

Tabela 5 - Número de defeitos semeados e revelados

sistema defeitos semeados defeitos revelados

esquema aplicação esquema aplicação

S1 3 8 3 5

S2 1 7 1 2

S3 0 5 0 1

4.3 Análise dos Resultados

O número de instâncias alternativas (dados de teste) e de consultas geradas pela XTool cresce com relação ao número de associações de defeito estabelecidas, como esperado. Entretanto, parece não haver uma relação observável entre este número e o número de elementos no esquema. A semântica do mesmo parece influenciar além da estrutura. Isto também ocorre no caso do teste de programas durante a aplicação de alguns critérios de teste, no qual LOC ou mesmo a complexidade ciclomática V(G) parecem não influenciar tanto no número de elementos requeridos/e ou dados de teste necessários [22]. Isto deverá ser explorado em trabalhos futuros. Similarmente ao teste de mutação utilizando-se operadores essenciais [2], poderá ser introduzido o conceito de associações de defeito essenciais.

Vale a pena ressaltar que a ferramenta XTool apresenta um mecanismo para que o usuário selecione as associações identificadas automaticamente, ou que estabeleça outras, caso seja necessário.

(16)

Isto poderá diminuir o custo da aplicação da AIDA, permitindo a seleção de algumas associações específicas para o tipo de aplicação que está sendo testada.

Com relação à eficácia, observa-se que a abordagem foi capaz de revelar todos os defeitos de esquema em teste. Com relação ao teste das aplicações, a abordagem foi capaz de revelar defeitos relacionados exclusivamente ao funcionamento da aplicação, apesar de não ser este o seu objetivo, sendo que 62,5% dos defeitos foram revelados no S1, 28,6% no S2 e 20% no S3. Isto mostra que os dados gerados pela abordagem AIDA podem ser utilizados de maneira complementar aos dados gerados por outros tipos de teste nestas aplicações.

É interessante observar que a maior eficácia está no sistema S1, para o qual foram gerados menos testes. Este sistema tem uma característica diferente dos demais, que é o fato de lidar com dois esquemas de dados, que manipulam diferentes tipos de dados em diferentes funcionalidades. Este fato parece apontar que a utilização de dados de teste, no teste da aplicação, gerados por uma abordagem de teste de esquema, se justifica quando o sistema manipular não uma grande quantidade de dados, mas quando os tipos dos dados manipulados forem também bastante diversificados.

Uma vantagem da abordagem, que foi observada, está associada ao tempo ganho para obtenção de uma massa de dados de teste de forma automatizada, e com boas possibilidades de detectar defeitos, o que certamente auxilia na agilidade do planejamento do processo de teste. Dessa forma, observou-se que a utilização da abordagem contribuiu significativamente para o processo de teste existente na empresa, que contava com um processo manual de seleção de dados de teste que consumia bastante tempo e esforço do testador.

5 TRABALHOS RELACIONADOS

Existem poucas abordagens na literatura que têm como objetivo testar o esquema de uma aplicação. No contexto de XML, destacam-se os trabalhos [12,15], que são baseados no teste de mutação. Estes trabalhos, entretanto, geram esquemas mutantes e

(17)

não instâncias de dados e não possuem uma aplicação direta no teste de aplicações.

Ainda neste contexto, alguns trabalhos têm como objetivo utilizar mensagens XML (ou SOAP) para o teste baseado em perturbação de serviços Web [1, 14, 17]. Estes trabalhos diferem dos Casos A e C ilustrados na Fig. 4 pois na maioria das vezes não utilizam o esquema (tal como um documento WSDL) em suas abordagens.

No contexto de banco de dados relacional, os trabalhos existentes se dedicam ao teste de aplicações de banco de dados. Esses trabalhos envolvem a geração de dados, o teste do projeto e da aplicação de banco de dados [4, 5, 6, 7, 13, 20, 24]. Eles não incluem o teste de esquemas.

Os trabalhos existentes, mais similares à proposta explorada neste artigo (Caso B da Fig. 4), exploram o uso de informações do esquema para o teste da aplicação de banco de dados [3, 19]. Robbert e Maryanski [19] usam informações obtidas do esquema de banco de dados para gerar um plano de teste para a aplicação de banco de dados. Chan e Cheung. [3] propõem uma abordagem baseada em defeitos para testar sentenças SQL de uma aplicação de banco de dados, usando informações capturadas do modelo de dados conceitual para gerar sentenças SQL mutantes.

Na abordagem de teste proposta neste artigo e avaliada no contexto de banco de dados relacional, os dados de teste são gerados a partir do esquema pensando em defeitos que este pode conter e que poderão estar refletidos na aplicação. Esta abordagem pode ser utilizada de maneira complementar aos trabalhos mencionados, pois auxilia a revelar outros tipos de defeitos, diferentes dos revelados pelas abordagens existentes.

6 CONCLUSÕES

Este artigo investigou o uso da abordagem de teste de esquemas AIDA para o teste de aplicações de banco de dados. As instâncias de dados geradas para o

(18)

teste dos esquemas podem ser: documentos XML, mensagens SOAP, ou bases de dados relacionais que podem ser utilizadas no teste de aplicações Web, de componentes que interagem via mensagens XML, e etc. O objetivo é detectar defeitos inseridos na implementação das aplicações, em termos de definições e de regras implementadas incorretamente, como por exemplo, defeitos em validações e em regras de negócio.

A proposta foi avaliada em um experimento no contexto de três aplicações reais de banco de dados relacional, utilizando a ferramenta XTool.

Os resultados mostram a aplicabilidade da estratégia. A AIDA foi capaz de revelar todos os defeitos relacionados aos esquemas e também outros defeitos relacionados à aplicação e mais a erros de lógica, mostrando melhores resultados para as aplicações que manipulam diferentes tipos de informação. A principal vantagem da abordagem é a geração automática dos dados de teste, que pode diminuir o esforço e o tempo gastos pelo testador. Uma desvantagem é que pode ser gerado um grande número de dados. Por isto foi observada a necessidade de se investigar, similarmente ao que acontece no teste de mutação de programas, estratégias para redução de custos através da determinação de classes de defeitos essenciais, talvez considerando o tipo específico da aplicação sendo testada.

Como trabalhos futuros, pretende-se investigar quais são as características da aplicação e dos dados que ela manipula, que tornam mais relevante a utilização da AIDA. Pretende-se também conduzir experimentos com os outros contextos de aplicação, ilustrados e propostos neste trabalho.

7 AGRADECIMENTOS

Os autores gostariam de agradecer ao CNPq pelo apoio financeiro recebido, a Marco Aurélio Cordeiro, Danillo Bazello e Rafael Demétrio Benvenutti por terem cedido os sistemas para realização dos experimentos, e a Fernanda Koppe, Luiz Gonzaga Moreira Correia Junior e Paulo Eduardo Schmitz que auxiliaram na seleção

(19)

dos defeitos e na reimplantação dos mesmos nos sistemas testados.

REFERÊNCIAS

ALMEIDA, L.; VERGILIO, S.R. Exploring perturbation based testing for web services. In: IEEE INTERNATIONAL CONFERENCE ON WEB SERVICES, 2006, Salt Lake City. Proceedings... Salt Lake City: IEEE, p. 717-726, 2006.

BARBOSA, E.F.; MALDONADO, J.C.; VINCENZI, A.R. Toward the determination of sufficient mutant operators for C software. John Wiley & Sons, 2001.

CHAN, M.; CHEUNG, S. Testing database applications with SQL semantics. In: INTERNATIONAL SYMPOSIUM ON COOPERATIVE DATABASE SYSTEMS FOR ADVANCED APPLICATIONS, 2., Wollongong. Proceedings... Singapore: Springer. p. 364-375, 1999.

CHAN, W. K.; CHEUNG, S. C.; TSE, T. H. Fault-based testing of database application programs with conceptual data model. In: INTERNATIONAL CONFERENCE ON QUALITY SOFTWARE, 5., 2005, Melbourne. Proceedings... Melbourne: IEEE, p. 187-196, 2005.

CHAYS, D.; DENG, Y. Demonstration of the agenda tool set for testing relational database applications. In: INTERNATIONAL SOFTWARE ENGINEERING CONFERENCE, 25., 2003, Montreal. Proceedings... Montreal: IEEE, p. 802–803, 2003.

CHAYS, David; DAN, Saikat; FRANKL, Phyllis G.; VOKOLOS, Filippos, I.; WEYUKER, Elaine J. A framework for testing database applications. In: ACM SIGSOFT INTERNATIONAL SYMPOSIUM ON SOFTWARE TESTING AND ANALYSIS, 2000, Portland. Proceedings... Portland: ACM, 2000.

DENG, Yuetang; FRANKL, Phyllis; CHAYS, David. Testing database transactions with agenda. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 27., 2005, St. Louis. Proceedings... St. Louis: ACM, 2005.

(20)

EMER, M.C.F.P.; VERGILIO, S.R.; JINO, M. A testing approach for xml schemas. In: ANNUAL INTERNATIONAL COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE. WORKSHOP ON QUALITY ASSURANCE AND TESTING OF WEB-BASED APPLICATIONS COMPSAC, 29., 2005, Edinburgh. Proceedings... Edinburgh: IEEE, 2005.

EMER, M. C. F. P.; VERGILIO, S. R.; JINO, M. A fault-based testing of data schemas. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING (SEKE 2007), 19., 2007, Boston. Proceedings... Skokie: Knowledge Systems Institute, 2007.

EMER, M. C. F. P.; VERGILIO, S. R.; JINO, M. Testing relational database schemas with alternative instance analysis. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING (SEKE 2008), 20., 2008, San Francisco. Proceedings... Skokie: Knowledge Systems Institute, 2007.

FRANZOTTE, L; VERGILIO, S.R. Applying mutation testing to xml schemas. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING (SEKE 2007), 18., 2006, San Francisco. Proceedings... Skokie: Knowledge Systems Institute, 2006.

KAPFHAMMER, Gregory M.; SOFFA, Mary Lou. A family of test adequacy criteria for database-driven applications. In: EUROPEAN SOFTWARE ENGINEERING CONFERENCE, 9. , 2003, Helsinki. Proceedings... Helsinki: ACM, 2003.

LEE, S.C.; OFFUTT, J. Generating test cases for xml-based web component interactions using mutation analysis. In: INTERNATIONAL SYMPOSIUM ON SOFTWARE RELIABILITY ENGINEERING, 12., Hong Kong, 2001. Proceedings... Hong Kong: IEEE, p. 200–209, 2001.

LI, J. B.; MILLER, J. Testing the semantics of W3C xml schema. In: ANNUAL INTL. COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE (COMPSAC-2005), 29., 2005, Edinburgh. Proceedings... Edinburgh: IEEE, 2005.

NAZAR, I. F.; EMER, M. C. F. P.; VERGILIO, S. R.; JINO, M. XTool: uma ferramenta de teste baseado em defeitos para esquemas de dados. In: WORKSHOP DE

(21)

TESTES E TOLERÂNCIA A FALHAS (WTF 2008), 9., 2008, Rio de Janeiro. Anais... Rio de Janeiro: SBS, 2008.

OFFUTT, J.; XU, W. Generating test cases for web services using data perturbation. In: WORKSHOP ON TESTING, ANALYSIS AND VERIFICATION OF WEB SERVICES (TAV-WEB), 2004, Boston. Proceedings... Boston: ACM SIGSOFT SEN, 2004.

Postgresql. Disponível em <http://www.postgresql.org/docs/> Acesso em: 03 jan. 2006.

ROBBERT, M. A.; MARYANSKI, F. J. Automated test plan generator for database application systems. In: ACM SIGSAMLL/PC SYMPOSIUM ON SMALL SYSTEMS, 1991, Canada. Proceedings... Canada: ACM, 1991. p. 100-106.

SUÁREZ-CABAL, M. J.; TUYA, J. Using a SQL coverage measurement for testing database applications. In: INTERNATIONAL SYMPOSIUM ON THE FOUNDATIONS OF ENGINEERING, 12., Newport beach, 2004. Proceedings... USA: ACM, 2004.

SUN. Java database connectivity (JDBC). Disponível em: <http://java.sun.com /javase/technologies/database/> Acesso em 03 fev. 2006.

VERGILIO, S.R.; MALDONADO. J.C.; JINO, M; CHAIM, M. L. Critérios potenciais usos: análise da aplicação de um benchmark. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 6., 1992, Rio de Janeiro. Anais... Rio de Janeiro: SBC, p.357-371, 1992.

W3C. XML Schema. Disponível em: <http://www.w3c.org/XML/Schema/> . Acesso em: 03 fev. 2006.

ZHANG, J.; XU, C.; CHEUNG, S.C. Automatic generation of database instances for white-box Testing. In: ANNUAL INTERNATIONAL COMPUTER SOFTWARE AND APPLICATIONS CONFERENCE, 25., 2001, Chicago. Proceedings... Chicago: IEEE, p. 161–165, 2001.

Referências

Documentos relacionados

Este presente artigo é o resultado de um estudo de caso que buscou apresentar o surgimento da atividade turística dentro da favela de Paraisópolis, uma

seria usada para o parafuso M6, foram utilizadas as equações 14 e 15, referentes aos parafusos de 8 mm de diâmetro e folga entre parafuso e furo de 0,5 mm, que definem,

No entanto, os resultados apresentados pelo --linalol não foram semelhantes, em parte, aos do linalol racêmico, uma vez que este apresenta um efeito vasorelaxante em anéis de

Resumo: O presente trabalho corresponde a um estudo empírico descritivo e exploratório que aborda comportamentos e falas de atores políticos que participaram do processo legislativo

A interação treinamento de natação aeróbico e dieta rica em carboidratos simples mostraram que só treinamento não é totalmente eficiente para manter abundância

Estes resultados apontam para melhor capacidade de estabelecimento inicial do siratro, apresentando maior velocidade de emergência e percentual de cobertura do solo até os 60

Entendendo, então, como posto acima, propõe-se, com este trabalho, primeiramente estudar a Lei de Busca e Apreensão para dá-la a conhecer da melhor forma, fazendo o mesmo com o

A variação do pH da fase móvel, utilizando uma coluna C8 e o fluxo de 1,2 mL/min, permitiu o ajuste do tempo de retenção do lupeol em aproximadamente 6,2 minutos contribuindo para