Descrição do Experimento

O primeiro aspecto é a busca por regras representativas da população de regras escritas em SQL. Observou-se que empresas relutam em disponibilizar suas regras ativas, pois estas

incorporam a tecnologia do negócio em questão; mesmo assim, o contato com algumas empresas foi positivo, pois foi reforçada a importância do uso de triggers em aplicações de banco de dados, e que esforços adicionais eram alocados ao teste de regras que possuíam alguma interação.

O experimento foi conduzido utilizando o sistema gerenciador de banco de dados Oracle; tal sistema tem sido usado pela comunidade acadêmica em seus experimentos (Daou et al., 2001) e suporta o modelo adotado pela tese para a interação de regras ativas, conforme descrito na Seção 4.3. O sistema Oracle utilizado no experimento possui um banco de dados exemplo, o qual é comumente mencionado na documentação deste sistema; o Apêndice B ilustra um modelo conceitual inspirado neste banco de dados. As regras presentes no banco de dados foram estendidas para compor o conjunto de regras Rx, o qual possui aspectos de interação e semântica

compatível com o esquema da base de dados. A Figura 5.18 apresenta os grafos de interação para o conjunto Rx. O Apêndice A apresenta o código fonte de tais regras, acrescido de comandos de

instrumentação, conforme os modelos de implementação introduzidos no Capítulo 6.

rx1 rx4 rx2 rx3 rx1 rx2 rx3 rx4 (a) (b)

Figura 5.18 – Grafos de interação para o conjunto de regras Rx = { rx1, rx2, rx3, rx4 }, cuja denominação implementada é Rx= { TRG_COMMIT_ITEMS, TRG_INVENTORY_QUANTITY,

TRG_PRODUCT_PENDING, TRG_PRODUCT_QUANTITY }: (a) grafo AE; (b) grafo AA.

A abordagem para a geração de bases para teste utilizada no experimento é inspirada em Ostrand e Balcer (1988) e em Chays et al. (2000). Basicamente, são atribuídos valores para cada

Critérios de Teste Baseados na Interação entre Regras Ativas 125

domínio, que são combinados para compor relações de entrada, garantindo que restrições de integridade dessas relações sejam satisfeitas, ou seja, são produzidos estados válidos do banco de dados. A partir das ocorrências dos comandos de manipulação e da descrição de esquema da base de dados, é possível abstrair os atributos pertinentes à execução dos comandos; tais atributos, definidos no Capítulo 3 como atributos manipulados, são os atributos da(s) relação(ões) de entrada referenciados explicitamente ou implicitamente no comando de manipulação ou listados diretamente como atributos do conjunto de saída. O testador deve fornecer uma coleção de valores para cada atributo, usando a premissa de que é mais significativo ao teste conferir resultados a partir de dados ligados a situações típicas de uso. Os valores são usados para gerar dados que cobrem uma variedade de combinações e que satisfazem as regras de integridade da base de dados.

O experimento é conduzido para o teste das regras do conjunto Rx, conforme descrito a seguir.

(1) Criar novas versões do conjunto de regras Rx, pela introdução de um defeito para caracterizar

cada versão criada. A introdução de defeitos ocorrerá de forma aleatória:

(1a) identificar todas as ocorrências de manipulação determinantes de associações de interação entre regras do conjunto Rx; ou seja, tomar as ocorrências de manipulação

atribuídas à definição e ao uso persistentes em cada associação de interação em Rx; (1b) para cada tipo de defeito de manipulação τ, do elenco de tipos de defeito explorado no

Capítulo 3, proceder conforme abaixo:

(1b)-1 selecionar aleatoriamente uma ocorrência de manipulação dentre as identificadas em (1a);

(1b)-2 introduzir um defeito do tipo τ na ocorrência de manipulação selecionada em

(1b)-1; se não for possível introduzir o defeito nesta ocorrência (por exemplo, o

defeito se refere à cláusula de ordenação incorreta e o comando não possui cláusula de ordenação), retornar ao passo (1b)-1 para a seleção de outra ocorrência de manipulação.

(1c) Deverá ser garantido que em toda ocorrência de definição e de uso de dados persistentes determinante de associações de interação seja introduzido pelo menos um defeito de manipulação; contudo, os tipos de defeito listados no Capítulo 3 referenciam

as construções sintáticas básicas dos comandos de manipulação, o que poderá resultar na impossibilidade de se inserir algum defeito devido à inexistência de comandos que suportem o seu tipo.

Cada versão defeituosa κ do conjunto Rx é caracterizada pela presença de um defeito em algum

comando de manipulação determinante de associação de interação entre regras. A aleatoriedade na seleção de ocorrências é usada para evitar a parcialidade na inserção de defeitos.

(2) Executar as versões instituídas a partir do conjunto Rx, segundo as diretrizes a seguir. Em

cada versão defeituosa κ do conjunto de regras, para toda associação de interação α determinada pelo comando defeituoso nesta versão e para cada granularidade β de análise de fluxo de dados:

(2a) gerar base de teste, inspirando-se na abordagem descrita por Chays et al. (2000); a Seção 2.4 descreve esta abordagem;

(2b) elaborar comandos de manipulação para o disparo das regras do conjunto Rx, de modo

que cubra todos os tipos de operação que disparam as regras cuja execução envolve a cobertura de α;

(2c) aplicar os dados de teste para cobrir α em β; se a associação não foi coberta para esta granularidade, repetir os passos (2a) e (2b) para gerar novos dados de teste até que se cubra α em β, ou se conclua que a associação é não exercitável nesta granularidade; a idéia é buscar dados de teste adequados às granularidades relação, tupla, atributo e

valor de atributo;

(2d) se α foi coberta em β, avaliar se uma falha foi manifestada devido à presença do defeito.

Note que toda versão defeituosa κ do conjunto de regras Rx é testada para cada granularidade de

fluxo de dados. Isto permite capturar a influência da granularidade na descoberta de defeitos de interação entre regras.

Critérios de Teste Baseados na Interação entre Regras Ativas 127