Spoto, Edmundo Sergio

UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELTRICA E DE COMPUTAO DEPARTAMENTO DE ENGENHARIA DE COMPUTAO E AUTOMAO INDUSTRIAL
TESTE ESTRUTURAL DE PROGRAMAS DE APLICAO DE BANCO DE DADOS RELACIONAL
Edmundo Srgio Spoto
Orientador: Prof. Dr. Mario Jino Co-orientador: Prof. Dr. Jos Carlos Maldonado
Tese submetida Faculdade de Engenharia Eltrica e de Computao da Universidade Estadual de Campinas como parte dos requisitos exigidos para a obteno do ttulo de Doutor em Engenharia Eltrica. rea de concentrao: Engenharia de Computao.
Campinas SP Brasil 2000
FICHA CATALOGRFICA ELABORADA PELA BIBLIOTECA DA REA DE ENGENHARIA - BAE - UNICAMP
Sp68t
Spoto, Edmundo Srgio Teste estrutural de programas de aplicao de banco de dados relacional / Edmundo Srgio Spoto.--Campinas, SP: [s.n.], 2000. Orientadores: Mario Jino, Jos Carlos Maldonado. Tese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Eltrica e de Computao. 1. Banco de dados relacionais. 2. SQL (Linguagem de programao de computador). 3. Software Testes. 4. Engenharia de software. 5. Software Desenvolvimento. I. Jino, Mario. II. Maldonado, Jos Carlos. III. Universidade Estadual de Campinas. Faculdade de Engenharia Eltrica e de Computao. IV. Ttulo.
UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELTRICA E DE COMPUTAO DEPARTAMENTO DE ENGENHARIA DE COMPUTAO E AUTOMAO INDUSTRIAL
TESTE ESTRUTURAL DE PROGRAMAS DE APLICAO DE BANCO DE DADOS RELACIONAL

Edmundo Srgio Spoto
Tese de Doutorado defendida e aprovada, em 20 de dezembro de 2000, pela Banca Examinadora constituda pelos Professores:
Prof. Dr. Mario Jino, Presidente DCA/FEEC/UNICAMP Prof. Dr. Ivan Luis Marques Ricarte DCA/FEEC/UNICAMP Prof. Dr. Lo Pini Magalhes DCA/FEEC/UNICAMP Prof. Dr. Ricardo Ribeiro Gudwin FEEC/UNICAMP Prof. Dr. Antonio Francisco Prado UFSCAR Profa. Dra. Silvia Regina Virgilio UFPR Dr. Plnio Souza Vilela TELCORDIA/EUA
Campinas SP Brasil 2000
Resumo
Uma abordagem proposta para o teste estrutural de programas de Aplicao de Banco de Dados Relacional (ABDR) com SQL embutida. Uma aplicao vista como um conjunto de programas e cada programa como um conjunto de unidades. Devido natureza da ABDR, dois modelos de fluxo de dados so propostos: intra-modular e inter-modular. O modelo de fluxo de dados intra-modular aplica-se ao teste de unidade e ao teste de integrao das unidades de um programa. O inter-modular aplica-se integrao dos programas que compem uma aplicao. O teste de unidade pode ser apoiado por qualquer critrio de teste estrutural de unidade de programas procedimentais. Duas abordagens so propostas para o teste de integrao intra-modular: teste baseado no grafo de chamadas e teste baseado em dependncia de dados. Critrios baseados nos modelos intra-modular e inter-modular so apresentados e discutidos com exemplos de sua aplicao; so tambm apresentados e discutidos resultados de experimentos. A anlise da complexidade dos critrios mostra que ela de ordem exponencial, para o pior caso. Contudo, os resultados de sua aplicao, em programas reais, indicam que eles demandam um nmero pequeno de casos de teste.
Abstract
An approach is proposed for structural testing of programs of Relational Database Applications (RDA) with embedded SQL. An application is regarded as a set of programs and each program as a set of units. Due to the nature of RDA two data-flow models are proposed: intra-modular and inter-modular. The intra-modular data flow model addresses the unit testing and the integration testing of each program. The inter-modular data flow model addresses the integration testing of RDAs programs. Unit testing can be supported by any structural unit testing criterion of procedural programs. Two approaches are proposed for the intra-modular integration testing: testing based on the call-graph and testing based on data dependence. Criteria based on the intra-modular and inter-modular data flow models are presented and discussed with examples of their application; results from experiments are also presented and discussed. Analyses of the complexity of those
criteria show them to be of exponential order, in the worst case. However, results from their application indicate that they demand a small number of test cases.
vi
Agradecimentos
Agradeo aos meus orientadores Prof. Dr. Mario Jino e Prof. Dr. Jos Carlos Maldonado, pela orientao segura e a confiana que me passaram ao longo da elaborao desta tese. Aos amigos e companheiros do grupo de teste do LCA: Ana, Adalberto, Chaim, Claudia, Cristina, Daniela, Ins, Ivan, Letcia, Nelson, Paulo, Plnio e Silvia, pelas sugestes e companheirismo ao longo desses anos, a todos vocs meu sincero agradecimento. Agradeo tambm a Mitie e Priscila pela amizade. Aos Professores do DCA: Eleri, Ivan Ricarte, Leo Pini, Mario Jino, Maurcio e Ting por todo aprendizado ao longo dos anos e pela amizade. Aos membros da banca: Ivan Ricarte, Leo Pini, Plnio Vilela, Prado, Ricardo Gudwin e Silvia Verglio agradeo as contribuies. Aos demais amigos do LCA: Adela, Galo, Gonzaga, Jos, Luis, Lizet, Mrcio Leandro, Miriam, Rodrigo, Viviane e a todos os demais que passaram por l e deixaram lembranas pela amizade; valeu a fora de todos. A Famlia Tambascia que foi minha segunda famlia: Sr. Cludio, Dna. Vanda, Claudia, Luciana, Rafael, Sr. Bilu e Dna. Guiomar pelo carinho que sempre me acolheram. A todos os demais amigos e colegas de Campinas que de maneira direta ou indireta contriburam com a realizao deste trabalho. A minha esposa Rosana pelo amor, carinho e dedicao que tem me dado. Aos meus pais Yeda e Angelo e todos irmos. A todos tios, tias, primos e primas meu muito obrigado pela fora e ajuda que vocs sempre deram. A todos os professores do DIN, de modo especial aos Professores: Delamaro e Sandra pela contribuio; e aos demais Professores Airton, Carniel, Elisa, Flvio, Itana, Jose Roberto, Maurcio, Olguin, Osvaldo, Sica, Tarso, Xavier pela fora no dia a dia. Aos funcionrios e alunos pela amizade e compreenso. Ao Professor Doherty Andrade do DMA pela ajuda. Aos rgos de apoio a pesquisa: Capes e CNPq, bem como as Universidades UEM e UNICAMP.
vii
viii
SUMRIO
RESUMO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ABSTRACT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AGRADECIMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SUMRIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LISTA DE TABELAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introduo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Objetivos da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Organizao da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conceitos Bsicos e Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Teste Estrutural Baseado em Fluxo de Dados . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Teste de Unidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Teste de Integrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Trabalhos Relacionados ao Teste Estrutural . . . . . . . . . . . . . . . . . . . 2.2 Banco de Dados Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Modelo de Dados Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Aplicao de Banco de Dados Relacional (ABDR) . . . . . . . . . . . . . 2.2.2.1 Linguagem de Banco de Dados Relacional SQL . . . . . . . 2.2.2.2 Comandos da Linguagem SQL embutida . . . . . . . . . . . . . . 2.3 Trabalhos Relacionados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Consideraes Finais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Teste Estrutural de Aplicao de Banco de Dados Relacional:Conceitos e Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Teste Estrutural de ABDR: Conceitos Bsicos e Terminologia . . . . . . . . . . 037 037 v v vii ix xiii xvii 001 001 003 004 005 007 007 011 012 013 021 021 024 026 028 032 034
3.1.1 Teste de Unidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 041 3.1.2 Teste de Integrao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 050
ix
3.1.2.1 Teste de integrao baseado no grafo de chamadas. . . . . . . 051 3.1.2.2 Teste de integrao baseado na dependncia de dados . . . . 053
3.2 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 057 4 Critrios de Testes: Definio e Anlise de Propriedades. . . . . . . . . . . . . . . . . . . . 061 4.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 061 4.2 Tipos de Fluxos de Dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 061 4.2.1 Fluxo Intra-Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 062 4.2.2 Fluxo Inter-Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 064 4.3 Os Critrios Intra-Modulares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 065 4.3.1 Critrios aplicados ao teste de unidade . . . . . . . . . . . . . . . . . . . . . . . . 066 4.3.2 Critrios aplicados ao teste de integrao intra-modular. . . . . . . . . . . 068 4.3.2.1 Critrios de Teste de Integrao baseados no grafo de chamadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2.2 Critrios de teste de integrao baseados na dependncia de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 072 4.4 Critrios de integrao inter-modular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 075 4.5 Anlise de Propriedades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 076 069
4.5.1 Anlise de Incluso entre os critrios. . . . . . . . . . . . . . . . . . . 076 4.5.2 Anlise de Complexidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 084 4.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 088 5 Os Modelos de Implementao dos Critrios de Teste. . . . . . . . . . . . . . . . . . . . . . 091
5.1 Consideraes Iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 091 5.2 O Modelo de Fluxo de Controle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 092 5.3 Os Modelos de Instrumentao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Instrumentando o programa original . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Identificando as Tuplas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Modelo de Fluxo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 099 101 103 107
5.4.1 Modelo de Fluxo de Dados Intra-Modular. . . . . . . . . . . . . . . . . . . . . 108 5.4.2 Modelo de Fluxo de Dados Inter-Modular. . . . . . . . . . . . . . . . . . . . . 112 5.5 Modelo de Descrio dos Elementos Requeridos . . . . . . . . . . . . . . . . . . . . . 113
5.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 x
6 Exemplos de Utilizao dos Critrios de Teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1 6.2 6.3 Consideraes Iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Descrio das Tabelas, Dependncias e Fluxos de Dados . . . . . . . . . . . . . . 118
Resultados dos Exemplos de Utilizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.3.1 Teste Intra-Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.3.1.1 Teste de Unidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.3.1.2 Teste de Integrao baseado na dependncia de dados. . . . . 126 6.3.2 Teste de Integrao Inter-Modular. . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.4 Comparao da utilizao dos critrios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.5 Consideraes Finais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7 Concluses e Trabalhos Futuros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.1 Concluses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.2 Contribuies da Tese. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 7.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Referncias Bibliogrficas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Apndices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 A: A Ferramenta POKE-TOOL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 B: Comandos de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 C: Um Exemplo Completo das etapas de integrao: intra-modular e intermodular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 ndice Remissivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
xi
xii
Lista de Figuras
2.1 2.2 Ambiente para o teste de unidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 011 Representao grfica do fluxo de controle dos comandos executveis da SQL gerados pelas aes do comando WHENEVER <condio> <ao> . . . . . . . . 3.1 3.2 Uma Aplicao de Banco de Dados Relacional. . . . . . . . . . . . . . . . . . . . . . . . . Grafo de Programa da Unidade de Programa Selemp do Mdulo de Programa Mod3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 040 3.3 Exemplo de um grafo de programa com SQL embutida. . . . . . . . . . . . . . . . . . . 043 3.4 Funo com os principais comandos de manipulao da SQL para uma tabela t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 046 3.5 Exemplo de um grafo de chamada entre duas UPs (C e R) . . . . . . . . . . . . . . . . . 051 3.6a Grafo de Dependncia interna de Dados c.r.a. DEPARTMENT GDPA(InsdepMOD3 SeldepMOD3)DEPARTMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 056 3.6b Grafo de Dependncia externa de Dados c.r.a. CUSTOMER entre as UPs Inscus(Mod2) e Relcli(Mod4). GDPA(InscusMOD2 RelcliMOD4)CUSTOMER . . . . . . 057 3.7 Grafo de Dependncia de Dados interna entre as unidades do Mdulo de Programa Mod3 ilustrada com os grafos de programas das UPs . . . . . . . . . . . . . 058 4.1 Exemplo do Fluxo de Dados Intra-Modular completo. . . . . . . . . . . . . . . . . . . . . 063 4.2 Fluxo de Dados inter-modular de uma ABDR composta por 4 Mdulos de Programas e 8 tabelas que constituem a base de dados. . . . . . . . . . . . . . . . . . . . . . 065 4.3 4.4 4.5 4.6 4.7 Exemplo de um Procedimento que contm todas operaes da SQL. . . . . . . . . . 067 Exemplo 1 para anlise de incluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 080 Exemplo 2 para anlise de incluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 081 rvore de incluso parcial dos critrios de teste de unidade de ABDR. . . . . . . . 082 rvore de incluso dos critrios de teste de unidade de ABDR para caminhos executveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 082 4.8 Exemplo para Anlise de Incluso dos Critrios (Todos os t-usos-intra ou inter) (Todos os dtu-caminhos-intra ou inter). . . . . . . . . . . . . . . . . . . . . . . . . . . 083 030 038
xiii
4.9 rvores de Incluso dos Critrios de integrao. O Critrio todos os dtucaminhos (intra ou inter) inclui parcialmente o critrio todos os t-usos (intra ou inter). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 084 4.10 Grafo de fluxo de controle que maximiza o nmero de combinaes do critrio todos os t-usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 085 4.11 Grafo de fluxo de controle com estrutura que maximiza o critrio todos os tusos, onde a o nmero de ns em cada estrutura e k o nmero de comandos if-then-else. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 087 5.1 Modelo de fluxo de controle e instrumentao associado aos comandos da SQL comando declarativo de controle de erros WHENEVER. . . . . . . . . . . . . . . . . . . 093 5.2 O modelo de fluxo de controle para os comandos executveis da SQL gerado pela ao do comando declarativo WHENEVER. Na descrio apresentado o Modelo de instrumentao referente a cada ao nos comandos executveis da SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 094 5.3 5.4 5.5 5.6 5.7 Sintaxe parcial e LI para o comando INSERT . . . . . . . . . . . . . . . . . . . . . . . . . . . 096 Sintaxe parcial e LI para o comando DELETE. . . . . . . . . . . . . . . . . . . . . . . . . . . 097 Sintaxe parcial e LI para o comando UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 098 Sintaxe parcial e LI para o comando SELECT. . . . . . . . . . . . . . . . . . . . . . . . . . . 099 Instrumentao dos comandos de manipulao da SQL para a ao DO <funo> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.8 Arquivo de auxlio instrumentao das tuplas para as tabelas: EMPLOYEE, DEPARTMENT, CUSTOMER e SALES_ORDER . . . . . . . . . . . . . . . . . . . . . . 104 5.9 Arquivo tab_ch_pr.tes: chaves primrias das tabelas usadas no programa Mod3.pc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.10a Programa original para teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.10b Programa instrumentado para o teste de Unidade. . . . . . . . . . . . . . . . . . . . . . . . 106 5.10c Programa instrumentado para os critrios de integrao intra-modulares e intermodulares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.11 Diretrizes para a Expanso do Grafo de Programa para Obteno do Grafo def: Comandos de Manipulao da Base de Dados (SQL). . . . . . . . . . . . . . . . . . . . . 109
xiv
5.12 Diretrizes para a Expanso do Grafo de Programa para Obteno do Grafo def: Comandos de Seleo da Base de Dados (SQL) . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.13 Arquivo tabdeftuso.tes para a tabela EMPLOYEE no mdulo Mod3.pc . . . . . . . 111 5.14 Arquivo tabidtu.tes para a tabela EMPLOYEE nos mdulos Mod3.pc e Mod6.pc 112 6.1a Diagrama de Entidades e Relacionamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.1b Tabelas da base de dados e fluxo de dependncia . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2 Fluxo de dados inter-modular da ABDR composta por 4 Mdulos de Programa e 8 tabelas que constituem a base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.3 6.4 6.5 Visualizao do teste de unidade Insemp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Organizao dos arquivos utilizados para o teste de integrao intra-modular . 128 Arquivos Pathint.tes e Keyint.tes informaes sobre a execuo do teste de integrao intra-modular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 6.6 Teste de integrao inter-modular: Unidades Insemp do Mdulo Mod3 e Unidade RelGer do Mdulo Mod6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 6.7 A1 A2 Arquivos Pathint.tes - caminhos executados e Keyint.tes - seqncia de tuplas . 135 Projeto da Ferramenta POKE-TOOL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Apresenta uma proposta de modificao do projeto da ferramenta POKETOOL para atender programas de ABDR na etapa de teste de unidade . . . . . . . . . . . . . 158 B1 Comandos da SQL embutida, agrupados por tipos. Os comandos com * no existem no modo interativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 C1 Quadro geral do programa Mod3.pc utilizado no exemplo . . . . . . . . . . . . . . . . . 173
xv
xvi
Lista de Tabelas
4.1 Mapa de definio e uso das variveis tabela mostradas nos Mdulos de Programas da Figura 4.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 065 6.1 Ocorrncias de definio persistente e uso das variveis tabela nos Mdulos de Programas (D: definio, U: uso). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.2 6.3 Quadro geral dos Mdulos de Programas executados no teste de unidade . . . . . 137 Testes para o critrio de integrao todos os t-usos-ciclo1-intra para o Mdulo Mod3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 6.4 Elementos requeridos pelo critrio todos os t-usos-inter para os mdulos Mod2, Mod3 e Mod6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6.6 Associaes entre os comandos da SQL c.r.a. t . . . . . . . . . . . . . . . . . . . . . . . . . . 140
xvii
xviii
Captulo 1 - Introduo
1 Introduo
Neste captulo so apresentados brevemente o contexto, a motivao e os objetivos deste trabalho Teste Estrutural de Software de Aplicao de Banco de Dados Relacional. A organizao da tese apresentada na ltima seo deste captulo.
1.1 Teste de Software

Nas ltimas duas dcadas os profissionais da rea de Engenharia de Software tm demonstrado uma grande preocupao em incorporar qualidade no processo de desenvolvimento de seus produtos de software. Pressman [PRE97] apresenta vrias formas de tratar essa qualidade ao longo do processo de desenvolvimento do produto, relacionando requisitos tanto funcionais como de desempenho, documentaes padronizadas e caractersticas que permitam um planejamento do software desenvolvido profissionalmente como um todo. Segundo o mesmo autor, o processo de desenvolvimento de software se divide em trs fases genricas: definio, desenvolvimento e manuteno. A fase de definio caracterizada pela identificao dos requisitos bsicos do sistema e do software. A fase de desenvolvimento tem por objetivo definir como os requisitos do sistema sero satisfeitos; nela ocorrem trs etapas distintas: projeto, codificao e teste de software. Este trabalho concentra-se na etapa de teste de software. A fase de manuteno concentra-se nas modificaes feitas sobre o software devido s atividades como: correo, melhoria e adaptao. Os termos: defeito, erro e falha correspondem aos termos em ingls: fault, error e failure, respectivamente. Seus significados so: i) Defeito: uma deficincia mecnica ou algortmica que, se ativada, pode levar a uma falha; diz-se que o defeito inerente ao programa e geralmente inserido por um engano(mistake) do programador ou do analista; ii) Erro: um item de informao ou estado inconsistente do programa; considerado como um item dinmico que geralmente surge aps a ativao de um defeito; iii) Falha: o evento notvel no qual o programa viola suas especificaes; uma condio indispensvel para a ocorrncia de uma falha que pelo menos um defeito seja ativado (neste caso dizemos que a execuo exercitou um ou mais defeitos) [VIL98].
Teste de Software uma das atividades de garantia de qualidade e, segundo Chusho [CHU87], a chave para melhorar sua produtividade e sua confiabilidade. Fazer o teste de modo exaustivo em geral impraticvel. Por exemplo, um programa cujas entradas sejam duas variveis inteiras X e Y em um computador com registradores de 32 bits, teria 264 pares de entradas (X, Y), tornando assim impraticvel o teste com cada par [HUA75]. O teste o processo de executar um programa ou sistema com a finalidade de detectar defeitos. O teste pode tambm ser usado para avaliar o quanto o sistema atende s necessidades especificadas [MYE79]. As atividades de teste consomem em mdia 50% do tempo e do custo de desenvolvimento de um produto de software [GOD75, MYE79, PRE97]. Esse gasto em parte resultante da escassez de ferramentas de auxlio ao teste que permitam uma forma planejada e segura para sua execuo e para a avaliao de seus resultados. De uma forma geral o teste de software envolve as seguintes atividades: planejamento, projeto de casos de teste1, execuo e avaliao dos resultados dos testes. Os mtodos utilizados para testar software so baseados essencialmente nas tcnicas funcional, estrutural e baseada em defeitos. A tcnica funcional de teste visa a estabelecer requisitos de teste derivados da especificao funcional do software (teste caixa preta) enquanto a tcnica estrutural de teste apia-se em informaes derivadas diretamente da implementao (teste caixa branca) [WHI87]. Cumpre observar que este trabalho concentra-se em teste de software baseado na tcnica estrutural. Hetzel [HET87] observa que a tcnica funcional de teste enfoca apenas as respostas obtidas para cada dado de teste. Esta tcnica ignora os detalhes de implementao. A tcnica baseada em defeitos (e.g., semeadura de erros e anlise de mutantes) [BUD81, DeM78, NTA84] utiliza informaes sobre os defeitos tpicos de desenvolvimento para derivar os requisitos de teste. Usualmente, caracterizam-se trs fases (ou nveis) de teste em uma estratgia de teste: teste de unidade, teste de integrao e teste de sistema. O teste de unidade concentra
Um caso de teste o conjunto formado por: i) um dado de entrada para um programa e ii) a sada esperada para esse dado de entrada. Em geral, procura-se projetar casos de teste que tenham a maior probabilidade de encontrar a maioria dos defeitos com um mnimo de tempo e esforo.
esforos na menor parte executvel do programa, conhecida como mdulo2, visa a identificao de defeitos de lgica e de implementao. O teste de integrao uma tcnica sistemtica utilizada para integrar as unidades que compem o programa, visa a detectar defeitos de integrao entre elas. O teste de sistema conduzido aps a integrao do sistema, visa a identificar defeitos de funo e/ou caractersticas de desempenho. A grande maioria dos critrios estruturais de teste aplicada na fase do teste de unidade [MAL91, VIL98]. Existem vrios tipos de aplicao que carecem de tcnicas apropriadas para o teste de software. Uma delas o desenvolvimento de programas de Aplicaes de Banco de Dados Relacional (ABDR) que utilizam a linguagem de consulta SQL embutida em linguagens procedimentais tais como: C, Pascal, PL/I, etc. Em levantamentos bibliogrficos realizados observou-se que o mais comum utilizar a tcnica de teste funcional, na qual ocorrem vrias etapas de testes de usabilidade e das principais funcionalidades do programa. Existem casos que aplicam um conjunto de operaes de comandos SQL, explorando as principais consultas existentes no programa.
1.2 Motivao
Nos ltimos anos as grandes empresas tm investido maciamente na elaborao de novas tcnicas de desenvolvimento de software em busca da qualidade de seus produtos de software. Contudo, existem muitas reas de desenvolvimento de software em que as iniciativas e o esforo tm sido muito incipientes. Em particular, muito pouco existe no que se refere ao suporte de teste de programas de ABDR, mesmo no mbito internacional. Em geral, a aplicao de Banco de Dados Relacional pode ser composta por vrios Programas codificados nas linguagens C, Pascal (Delphi), Fortran, Ada, PL/I, Cobol, etc. A caracterstica principal a manipulao de dados atravs de comandos de linguagem de consulta SQL bases de dados controladas por um Sistema Gerenciador de Banco de Dados Relacional (SGBDR). Existem no mercado vrios ambientes Gerenciadores de Banco de Dados que so usados dos pequenos aos grandes centros de desenvolvimento de sistemas. Apesar da existncia de diferentes dialetos SQL, um esforo de padronizao
2
Muito usado na literatura para representar a unidade em teste, podendo ser qualquer procedimento ou funo do programa em teste.
dessa linguagem resultou no padro SQL [ISO92]. Considerando essa padronizao, a construo de uma ferramenta de apoio ao teste de programas de ABDR deve inicialmente atender os comandos padres de SQL. Defeitos esto presentes na maioria dos produtos de software produzidos e liberados, apesar dos avanos significativos obtidos na rea de Engenharia de Software; o teste de software uma das tcnicas utilizada para revelar defeitos, pois cobre classes distintas de defeitos [MAL91]. Tcnicas especficas para tratar de ABDR respondem a uma necessidade emergente. A partir dessas tcnicas ser possvel criar suporte automatizado para dar apoio obteno de qualidade durante o desenvolvimento de programas de ABDR. Neste caso, estudar os principais problemas existentes em programas de ABDR com SQL embutida como, por exemplo, o fluxo de informaes existentes entre a base dados ocasionado pelos diferentes programas que compem uma ABDR e como testar todo o sistema tendo em vista sua complexidade devido a grande quantidade de informaes que so armazenadas e consultadas. Porm, defeitos de implementao, defeitos de lgica de programao e outros provenientes de falha humana durante a fase de desenvolvimento do programa s podero ser tratados com as tcnicas de teste estrutural para programas de ABDR. A idia, portanto, adaptar as principais tcnicas de teste estrutural de software para aplic-las em programas de ABDR com SQL embutida em linguagens hospedeiras, visando a atender essas necessidades.
1.3 Objetivos da Tese

Este trabalho tem como objetivo principal estudar mtodos de teste estrutural e adapt-los para programas de ABDR. Esses estudos englobam o teste de unidade e o teste de integrao de modo a atender s condies especficas de uma aplicao de banco de dados relacional envolvendo comandos mais comuns de SQL usados para manipular bases de dados. A partir desses estudos visa-se a estabelecer uma abordagem para o teste estrutural de programas de ABDR. Essa abordagem deve incorporar mtodos de teste baseados em fluxo de dados e mtodos de teste estrutural que exercitem os tipos especficos de variveis de programas de ABDR (variveis utilizadas em programas de aplicao). Objetiva-se
tambm propor a implementao desses mtodos de teste em uma ferramenta automatizada para apoiar a sua aplicao no teste de programas de ABDR. Especificamente, critrios de teste, baseados em anlise de fluxo de dados, so a base dos mtodos de teste estrutural. Estudar novas estratgias de teste estrutural para programas de ABDR o principal alvo deste trabalho e anlise. Atravs do estudo e anlises pretende-se desenvolver critrios que tornam efetivo o teste estrutural de programas de ABDR visando a explorar os diferentes tipos de fluxo de dados que ocorrem entre as tabelas da base de dados a partir dos diferentes programas que compem a aplicao. Nestes estudos pretende-se apresentar uma proposta completa que atenda todas as etapas de teste de um programa at atingir toda a ABDR. A proposta de teste estrutural para programas de ABDR apresentada nesta tese uma importante contribuio para a rea de desenvolvimento de software para Sistemas que manipulam grandes volumes de dados armazenados em arquivos especficos ou at mesmo em Sistemas Gerenciadores de Banco de Dados Relacional. Abrindo assim novas pesquisas e condies de auxiliar na obteno da qualidade de software na etapa de desenvolvimento.
1.4 Organizao da tese

Neste captulo so apresentados o contexto, a motivao e os objetivos principais deste trabalho. No Captulo 2 so apresentados terminologia e os conceitos bsicos utilizados nos Critrios de Teste Estrutural baseados em anlise de Fluxo de Controle e anlise de Fluxo Dados. Em seguida so apresentados os conceitos bsicos de Banco de Dados Relacional. No Captulo 3 so apresentados os conceitos bsicos e a terminologia adotada para o teste de programas de ABDR, segundo duas fases de teste: teste de unidade e teste de integrao. O teste de integrao engloba duas abordagens distintas: integrao baseada no grafo de chamada (idntica abordagem para programas convencionais) e integrao baseada em dependncia de dados das variveis tabela da Base de Dados. Tambm so apresentados os tipos de fluxo de dados intra-modular e inter-modular de programas de ABDR. No Captulo 4 so apresentados os critrios propostos e a anlise de suas propriedades; so descritos os tipos de fluxo de dados dos programas de aplicao: intra-
modular e inter-modular; so descritos os critrios de teste intra-modular e os critrios de integrao inter-modular e apresentada a anlise de propriedades dos critrios. No Captulo 5 so abordados os vrios aspectos relacionados ao projeto da ferramenta de suporte aplicao dos critrios de teste em ABDR; so descritos o modelo de fluxo de controle, os modelos de instrumentao e os modelos de fluxo de dados; discutida a descrio dos elementos requeridos. O Captulo 6 ilustra a utilizao dos critrios propostos para o teste de programas de ABDR. Inicialmente so apresentados a descrio das tabelas, as dependncias e o fluxo de dados para o exemplo de aplicao. Em seguida so apresentados resultados obtidos nos exemplos de utilizao dos critrios. A partir do exemplo so apresentadas algumas comparaes referentes utilizao dos critrios e so feitas algumas observaes quanto aos resultados do teste dos programas do exemplo de aplicao. No Captulo 7 so apresentadas as concluses desta tese; so discutidas as principais contribuies e as sugestes de trabalhos futuros. Trs apndices completam este trabalho: Apndice A contm uma breve descrio da ferramenta POKE-TOOL; Apndice B contm uma descrio de comandos da linguagem SQL; e Apndice C contm exemplos de ilustrao da aplicao dos critrios de teste propostos.
2 Conceitos Bsicos e Terminologia

Na primeira parte deste captulo so apresentados os conceitos bsicos e terminologia usados para definir os critrios de teste estrutural baseados em anlise de Fluxo de Dados. Na segunda parte so apresentados conceitos bsicos de Banco de Dados Relacional.
2.1 Teste Estrutural Baseado em Fluxo de Dados

A tcnica estrutural de teste de programas baseada no conhecimento da estrutura interna da implementao do software e visa a caracterizar um conjunto de componentes elementares do software que devem ser exercitados pelo teste (tambm conhecido como teste de caixa branca). Diz-se que um programa P correto com respeito a uma especificao S se, para qualquer item de dado d pertencente ao domnio de entrada D do programa P, o comportamento do programa estiver de acordo com o especificado em S [PRE97]. Para o teste de um programa pressupe-se que existe um orculo (mecanismo automtico ou manual) que possa determinar, para qualquer dado de entrada, se a sada do programa a sada esperada conforme a especificao. Um caso de teste composto por uma entrada de dados e a correspondente especificao da sada esperada. Apesar das desvantagens decorrentes das limitaes inerentes s atividades de teste estrutural de programas levantadas por vrios autores [FRA88, HOW87, LAS83, MAL91, NTA88, RAP85], a tcnica estrutural de teste vista como complementar tcnica funcional, uma vez que cobre classes distintas de erros [HOW87, LAS83, MYE79, MAL91, PRE97]. Ainda, as informaes obtidas com a aplicao da tcnica estrutural de teste tm sido consideradas relevantes para as atividades de manuteno e depurao de software [MAL91]. No teste estrutural, um programa P pode ser decomposto em um conjunto de blocos disjuntos de comandos. Um bloco de comandos a seqncia de um ou mais comandos com a propriedade de que, sempre que o primeiro comando do bloco executado, todos os demais comandos do bloco tambm so executados e no existem desvios para o meio do bloco [HUA75].
Captulo 2 Conceitos Bsicos e Terminologia
Um programa P representado por um grafo de fluxo de controle (ou grafo de programa) G=(N, A, e, s) onde N o conjunto de ns, A o conjunto de arcos (ou arestas), e o nico n de entrada e s o nico n de sada. Todo grafo de programa um grafo dirigido conexo. Um n n
N representa uma instruo simples (comando) ou uma
seqncia de instrues executadas como um bloco de comandos. Cada arco a
A um
par ordenado (n, m) de ns de N que representa uma possvel transferncia de controle do n n para o n m [HER76, LAS83, WHI87]. Um caminho do programa representado por uma seqncia finita de ns (n1, n2, .., nk ), k 2, tal que, para todo n ni, 1 i k-1, existe um arco (ni, ni+1) para i = 1, 2, .., k-1. Um caminho completo um caminho cujo n inicial o n de entrada e cujo n final o n de sada. Um caminho simples um caminho cujos ns, exceto possivelmente o primeiro e o ltimo, so distintos. Um caminho livre de lao se todos os ns pertencentes a ele so distintos [RAP85]. Vrios critrios de teste estrutural de programas foram propostos ao longo dos ltimos 20 anos; os primeiros critrios propostos so baseados unicamente no fluxo de controle de programas, sendo os mais conhecidos: o critrio todos-ns; o critrio todosarcos; e o critrio todos-caminhos. O critrio todos-ns requer que cada comando do programa seja executado pelo menos uma vez; o critrio todos-arcos, um dos critrios mais utilizados, requer que toda transferncia de controle seja exercitada pelo menos uma vez. O critrio todos-caminhos requer que todos os caminhos do programa sejam exercitados [HOW87, LAS83, NTA84]. Enquanto os critrios todos-ns e todos-arcos so considerados pouco exigentes, o critrio todos-caminhos em geral impraticvel na presena de laos no programa, criando assim uma distncia (lacuna) muito grande entre os critrios todos-arcos e todos-caminhos [RAP82, NTA84]; novos critrios foram introduzidos com o intuito de estabelecer uma hierarquia de critrios capaz de preencher a lacuna existente entre os critrios todos-arcos e todos-caminhos [LAS83, RAP82, NTA84, RAP85, MAL91]. Surgiram ento os critrios de teste estrutural baseados em anlise de fluxo de dados do programa. A anlise esttica do programa fornece informaes sobre as aes 8
executadas a respeito das variveis do programa e efeitos de tais aes nos vrios pontos do programa [HEC77]. Em geral uma varivel pode sofrer as seguintes aes no programa: (d) definio, (i) indefinio; ou (u) uso. Uma definio de varivel ocorre quando um valor armazenado em uma posio de memria. Uma ocorrncia de varivel uma definio se ela est: i) no lado esquerdo de um comando de atribuio; ii) em um comando de entrada; ou iii) em chamadas de procedimentos como parmetro de sada [MAL91]. A ocorrncia de uma varivel como uso se d quando a referncia a esta varivel, em um comando executvel, no a estiver definindo, ou seja, h uma recuperao de um valor em uma posio de memria associada a esta varivel. Dois tipos de usos so distinguidos c-uso e p-uso. O c-uso (uso computacional) afeta diretamente uma computao que est sendo realizada ou permite observar o valor de uma varivel que tenha sido definida anteriormente - nestes casos o uso est associado a um n do grafo do programa; o p-uso (uso predicativo) afeta diretamente o fluxo de controle do programa - este uso est associado a um arco do grafo. Uma varivel est indefinida quando, ou no se tem acesso ao seu valor, ou sua localizao deixa de estar definida na memria. Um caminho (i, n1, ..,nm, j), m 0 com uma definio da varivel x no n i e que no contenha nenhuma redefinio de x nos ns n1, ..,nm chamado de caminho livre de definio com respeito a (c.r.a.) x do n i ao n j e do n i ao arco (nm, j). Neste caso, pode existir uma redefinio de x no n j. Um n i possui uma definio global de uma varivel x se ocorre uma definio de x no n i e existe um caminho livre de definio de i para algum n ou para algum arco que contm um c-uso ou um p-uso, respectivamente, da varivel x. Um c-uso da varivel x em um n j um c-uso global se no existir uma definio de x no mesmo n j precedendo este c-uso; caso contrrio, um c-uso local. Vrios conceitos e definies foram introduzidos por Rapps e Weyuker [RAP82, RAP85] para estabelecer a Famlia de Critrios de Fluxo de Dados (FCFD); um deles o grafo def-uso (def-use graph) que consiste em uma extenso do grafo de programa, incorporando-se informaes semnticas do programa a este grafo. O grafo def-uso obtido a partir do grafo de programa associando-se a cada n i os conjuntos c-uso(i) = 9
{variveis com c-uso global no n i} e def(i) = {variveis com definies globais no n i }, e a cada arco (i, j) o conjunto p-uso(i,j) = {variveis com p-usos no arco (i, j)}. Dois conjuntos foram definidos: dcu(x,i) = {ns j tal que x c-uso (j) e existe um caminho livre de definio c.r.a. x do n i para o n j} e dpu(x,i) = {arcos (j, k) tal que x p-uso (j, k) e existe um caminho livre de definio c.r.a. x do n i para o arco (j, k)}. Adicionalmente, foram definidos os elementos requeridos de um programa: du-caminho, associao-c-uso, associao-p-uso e associao. Um caminho (n1, n2, .., nk) um du-caminho c.r.a. varivel x se n1 tiver uma definio global de x e: (1) ou nk tem um c-uso de x e (n1, n2, .., nj, nk) um caminho simples livre de definio c.r.a. x; ou (2) (nj, nk) tem um p-uso de x e (n1, n2, .., nj, nk) um caminho livre de definio c.r.a. x e n1, n2, ..., nj um caminho livre de lao [MAL91]. Uma associao definio-c-uso uma tripla (i, j, x) onde i um n que contm uma definio global de x e j dcu(x,i). Uma associao definio-p-uso uma tripla (i, (j,k), x) onde i um n que contm uma definio global de x e (j, k) dpu(x,i). Uma associao uma associao definio-c-uso, uma associao definio-p-uso ou um ducaminho [RAP82, RAP85]. A Famlia de Critrios de Fluxo de Dados (FCFD), proposta por Rapps e Weyuker, exige a ocorrncia explcita de um uso de varivel nos elementos requeridos; j a Famlia de Critrios Potenciais Usos (FCPU), proposta por Maldonado, Chaim e Jino [MAL88, MAL91], no exige a ocorrncia explcita de um uso de varivel; esta uma pequena, mas fundamental, modificao nos conceitos apresentados por Rapps e Weyuker. Os elementos requeridos pela Famlia de Critrios Potenciais Usos so decorrentes dos caminhos livres de definio alcanados para cada varivel definida no programa. No importa o uso real desta varivel mas os pontos onde pode existir um uso; se uma varivel x definida em um n i e pode existir um uso em um n j ou em um arco (j, k), ento existe uma potencial associao com respeito varivel x. Os critrios baseados em fluxo de dados utilizam informaes decorrentes das seqncias de aes executadas sobre as variveis ao longo de um caminho percorrido [NTA84], auxiliando na deteco de classes de defeitos decorrentes dos usos indevidos das variveis nos comandos ao longo do programa. A caracterstica comum desses critrios a 10
de requerer interaes que envolvam definies de variveis e seus subseqentes usos em outros pontos do programa [HER76, LAS83, RAP82, RAP85, NTA84, MAL91]. Os critrios baseados em anlise de fluxo de dados baseiam-se na idia de que no se deve confiar em um resultado de uma computao se o ponto onde ela foi realizada e o subseqente ponto onde seu valor usado nunca foram executados conjuntamente [RAP85, MAL91].
2.1.1 Teste de Unidade

O teste de unidade concentra-se na execuo e exame da menor parte do software, que pode ser uma funo de uma linguagem de programao procedimental. Os resultados baseados na especificao (resultados esperados) so confrontados com os resultados obtidos durante a execuo de um caso de teste para saber se algum defeito foi revelado. Isso feito para cada unidade testada isoladamente. Muitas vezes, para executar cada unidade isoladamente, necessria a construo de drivers e stubs de testes. O driver recebe os dados de teste, passa-os como parmetros para a unidade de programa em teste e apresenta os resultados produzidos para que o testador possa avali-los. O stub serve para substituir as partes subordinadas s unidades em teste. Esses stubs so, em geral, unidades que simulam o comportamento de unidades reais de programas atravs de um mnimo de computao ou manipulao de dados [VIL98]. A Figura 2.1 mostra uma unidade em teste.
Dado de Teste Driver Sada
Unidade de Programa em Teste
Stub 1
Stub 2
Figura 2.1 Ambiente para o teste de unidade
A criao desses stubs e drivers geralmente uma tarefa que merece muita ateno 11
e muitas vezes demorada, dificultando ainda mais a fase de teste. Mas uma tarefa importante para o teste de unidade. No teste de unidade o programa pode ser avaliado segundo a viso funcional do software e a viso da estrutura da implementao (viso estrutural). importante notar que as duas tcnicas mencionadas no so alternativas, isto , no se utiliza apenas uma ou outra tcnica: elas so complementares. Geralmente, uma tcnica proporciona a descoberta de classes de defeitos diferentes das que a outra proporciona. Por isso, para que o teste seja o mais completo possvel, deve-se utilizar as duas tcnicas. Historicamente o teste estrutural vem sendo aplicado principalmente no teste de unidade. Vrios trabalhos propem sua aplicao no teste de integrao [HAR91, CLA89, VIL98].
2.1.2 Teste de Integrao

O teste de integrao usualmente aplicado depois que todas as unidades que compem um programa foram devidamente testadas isoladamente (teste de unidade). O teste de integrao pode ser visto como uma tcnica sistemtica para a construo da estrutura do software, procurando revelar defeitos associados interao entre os procedimentos testados na etapa anterior. A integrao das unidades pode ser feita de maneira no incremental, numa abordagem conhecida como integrao big-bang [PRE97]. Neste caso todas as unidades so colocadas para interagir juntas, de uma s vez, e o programa testado como um todo. Geralmente, o resultado uma situao catica, onde um nmero grande de problemas identificado tornando a sua correo mais difcil. Muitos autores recomendam que se utilizem abordagens incrementais para o teste de integrao. Pressman [PRE97] diz que as estratgias incrementais para o teste de integrao so melhores, devido ao fato de que o programa construdo e testado em partes, onde os defeitos so facilmente isolados e corrigidos, as interfaces so exercitadas de maneira completa e uma abordagem sistemtica aplicada de maneira mais controlada. No modo incremental, a integrao denominada top-down inicia-se a partir do mdulo principal de controle do programa (procedimento principal) e prossegue em 12
direo aos mdulos inferiores na hierarquia de controle. Uma das vantagens desta estratgia de integrao testar os principais pontos de deciso da hierarquia de controle antes dos demais, visando a detectar problemas srios de controle. Uma terceira estratgia de integrao denominada de integrao Bottom-Up que consiste em integrar as unidades do programa a partir da base da estrutura do software em direo ao seu topo. Nesse caso, como as unidades so integradas de baixo para cima, ao integrar um determinado nvel, as unidades subordinadas (do nvel inferior) esto devidamente testadas e disponveis, eliminando assim a necessidade de elaborao de stubs. Existem dois tipos de integrao Bottom-Up: a) integrao por grupos de unidades ou clusters; b) integrao por pares de unidades (duas-a-duas ou pairwise).
2.1.3 Trabalhos Relacionados ao Teste Estrutural

Vrios trabalhos propem critrios baseados em anlise de fluxo de dados e em fluxo de controle, contribuindo para o avano tecnolgico na obteno da qualidade de software atravs do teste estrutural. Os critrios baseados em fluxo de dados tiveram como motivao preencher a lacuna entre o critrio todos os ramos e o critrio todos os caminhos. O principal problema do teste de caminhos reside principalmente no fato de que, para muitos programas, o nmero de caminhos extremamente grande devido ocorrncia de estruturas de iterao no programa. Vrios critrios tm sido propostos para a seleo de caminhos com o objetivo de introduzir critrios mais rigorosos do que o critrio todos os ramos, porm menos restritivos e dispendiosos que o critrio todos os caminhos. Os critrios baseados em anlise de fluxo de dados utilizam a informao de fluxo de dados para derivar os requisitos de teste e requerem que as interaes que envolvem definies de variveis de programa e subseqentes referncias a essas variveis sejam exercitadas. Esses critrios baseiam-se, portanto, para a derivao de casos de teste, nas associaes entre a definio de uma varivel e seus possveis usos subseqentes. Segundo Frankl e Weyuker [FRA86], uma das propriedades que deve ser satisfeita por um bom critrio de teste a aplicabilidade [FRA88, FRA93]; diz-se que um critrio C satisfaz a propriedade de aplicabilidade se para todo programa P existe um conjunto de 13
Captulo 2 Conceitos Bsicos e Terminologia casos de teste T que seja C-adequado para P, ou seja, o conjunto de caminhos executados por T inclui cada elemento requerido pelo critrio C. Estudos comparativos entre os critrios baseados em fluxo de dados tm sido conduzidos, apoiados principalmente por uma relao de incluso e pelo estudo da complexidade dos critrios [CLA85, RAP85, WEY84, NAT88]. Maldonado [MAL91] define a complexidade de um critrio C como o nmero de casos de teste requerido pelo critrio no pior caso; ou seja, dado um programa P qualquer, se existir um conjunto de casos de teste T que seja Cadequado para P, ento existe um conjunto de casos de teste T1, tal que a cardinalidade de T1 menor ou igual complexidade do critrio C. Vrios resultados apresentados indicam que a maioria dos critrios de teste baseados em fluxo de dados tem complexidade de ordem exponencial e que alguns deles tm complexidade polinomial [WEY84]; no entanto, Maldonado [MAL91] provou que todos tm complexidade de ordem exponencial, O(2n). A relao de incluso estabelece uma ordem parcial entre os diversos critrios. Dizse que um critrio de teste c1 inclui um critrio de teste c2 se, para qualquer grafo de fluxo de controle G (qualquer programa P), qualquer conjunto de caminhos completos T que seja c1 adequado para P c2 adequado para P; ou seja, se T satisfaz c1 tambm satisfaz c2. O critrio c1 inclui estritamente um critrio c2, denotado por c1 c2, se c1 inclui c2 e para algum grafo G existe um conjunto de caminhos completos T de G que inclui c2 mas no satisfaz c1. Se c1 no inclui c2 (c1 c2) nem c2 inclui c1 (c2 c1) diz-se que c1 e c2 so incomparveis. A seguir apresentaremos alguns trabalhos relacionados fase de teste de unidade e outros trabalhos relativos ao teste de integrao, segundo a estratgia de teste estrutural de programas.
Teste de Unidade
Huang [HUA75] realizou um estudo de gerao de dados de teste a partir da anlise de predicados que ocorrem nos arcos de um grafo de programa, abordando os predicados isoladamente e atravs de combinaes entre eles; tais critrios estabelecem a necessidade de tornar os critrios mais exigentes, isto , mais exigentes do que o critrio todos os ramos. 14
Herman [HER76] apresenta vrias definies baseadas em anlise de fluxo de dados aplicadas em teste de programas; seus critrios requerem que toda referncia de uma varivel seja exercitada pelo menos uma vez, a partir de pontos do programa em que essa varivel foi definida. Essas definies deram incio estratgia de teste estrutural baseada na anlise de fluxo de dados. Laski e Korel apresentam outros critrios de teste que usam informaes de fluxo de dados: o critrio ambiente de dados (data environment), o critrio contexto elementar de dados (elementary data context) e o critrio contexto ordenado de dados (ordered data context) [LAS83]. Ntafos [NTA84] introduz uma famlia de critrios denominada k-tuplas requeridas (required K-tuples); essa famlia de critrios requer que todas as seqncias de (K-1) ou menos interaes definio-uso (2-dr interactions) sejam exercitadas. Rapps e Weyuker [RAP82, RAP85] definem as propriedades apresentadas na Seo 2.1, com informaes semnticas da programao procedimental. Para considerar a existncia de caminhos no executveis, Frankl e Weyuker [FRA86, FRA88] propem modificaes em suas definies originais. Um caminho completo executvel ou factvel se existir um conjunto de valores que possam ser atribudos s variveis de entrada do programa que causa a execuo desse caminho. Caso contrrio, diz-se que ele no executvel. Um sub-caminho executvel se estiver contido em um caminho completo executvel. Uma associao def-uso executvel se existir um caminho livre de definio executvel que cubra essa associao; caso contrrio, no executvel. Frankl e Weyuker [FRA88] definem os seguintes conjuntos factveis: (a) (b) fdcu (x,i)= {j dcu(x,i) | a associao [i, j, x] executvel}; fdpu(x,i) = {(j, k) dpu(x,i) | a associao [i, (j, k), x] executvel}.
A Famlia de Critrios Baseados em Fluxo de Dados (FCFD) composta pelos seguintes critrios: o todas-definies: requer que cada definio de uma varivel x seja exercitada pelo menos uma vez, associando-a por pelo menos um c-uso ou um p-uso, atravs de um caminho livre de definio c.r.a x do n onde ocorre a definio ao n ou arco onde ocorre um uso; 15
o todos-usos: requer que todas as associaes entre cada definio de varivel e subseqentes c-usos e p-usos dessa definio sejam exercitadas pelo menos uma vez; o todos-p-usos: requer que todas as associaes entre cada definio de varivel e subseqentes p-usos dessa definio sejam exercitadas pelo menos uma vez; o todos-c-usos: requer que todas as associaes entre cada definio de varivel e subseqentes c-usos dessa definio sejam exercitadas pelo menos uma vez; o todos-p-usos/algum-c-uso: requer que todas as associaes entre cada definio de varivel e subseqentes p-usos sejam exercitadas; caso no haja p-uso, que pelo menos um c-uso associado a essa definio seja exercitado; o todos-c-usos/algum-p-uso: requer que todas as associaes entre cada definio de varivel e subseqentes c-usos sejam exercitadas; caso no haja c-uso, que pelo menos um p-uso associado a essa definio seja exercitado. o todos-du-caminhos: requer que todas as associaes entre cada definio de varivel e subseqentes p-usos ou c-usos dessa definio sejam exercitadas por todos os caminhos livres de definio e livres de laos que cubram essas associaes; ou seja, requer que todos-du-caminhos sejam exercitados. Frankl e Weyuker [FRA88] fazem uma anlise de incluso entre os critrios FCFD, concluindo que os critrios da FCFD estabelecem uma hierarquia entre os critrios todosramos e todos-caminhos. Ntafos [NTA88] tambm apresenta uma anlise de critrios fazendo uma comparao mais abrangente, envolvendo vrios outros critrios baseados essencialmente em fluxo de controle. Ntafos [NTA88] prova que os critrios de Laski e Korel incluem o critrio todos os usos e so incomparveis com o critrio todos-du-caminhos e que o critrio de Herman (dr interation) [HER76] no cobre o critrio todos-ramos. Os critrios todos-usos da FCFD [RAP85], um dos critrios de Ntafos [NTA84] e um dos critrios de Laski e Korel [LAS83] so similares ao critrio de Herman. Uma das exigncias mnimas de um bom critrio de teste cobrir o critrio todos os arcos. Maldonado, Chaim e Jino [MAL88, MAL88b, MAL91] introduzem a Famlia de Critrios Potenciais Usos e para isso usam as seguintes definies: 16
(i) (ii)
defg(i) = {varivel x | x definida no n i}; pdcu(v,i) = {ns j N | existe um caminho livre de definio c.r.a. x do n i para o n j e x defg(i)};
(iii)
pdpu(v,i) = {arcos (j,k) | existe um caminho livre de definio c.r.a x do n i para o arco (j,k) e x defg(i)};
(iv)
potencial-du-caminho c.r.a. x um caminho livre de definio (n1, n2, ...,nj, nk) c.r.a. x do n n1 para o n nk e para o arco (nj, nk), onde o caminho (n1, n2, ..., nj) um caminho livre de lao e no n n1 ocorre uma definio de x; associao potencial-definio-c-uso uma tripla [i, j, x] onde x defg(i) e j pdcu(x,i); associao potencial-definio-p-uso uma tripla [i,(j,k),x] onde x defg(i) e (j, k) pdpu(x,i);
(v)
(vi)
(vii)
associao potencial-uso uma associao potencial-definio-c-uso, uma associao potencial-definio-p-uso ou um potencial-du-caminho.
Maldonado [MAL91] define como conjuntos factveis: (viii) (ix) fpdcu(x,i)={j pdcu(x,i) | a potencial-associao [i, j, x] executvel}; fpdpu(x,i) = {(j, k) pdpu(x,i) | a potencial-associao [i, (j, k), x] executvel}. A famlia de critrios de teste estrutural proposta por Maldonado et al [MAL88, MAL88b, MAL91] est baseada na potencial associao que uma varivel x pode ter a partir de um n do grafo de programa G em que ocorre uma definio global dessa varivel: (i) todos-potenciais-usos: para todo n i
G tal que defg(i) (onde o
conjunto vazio) e para toda varivel x tal que x defg(i) requer que todas as associaes potenciais-definio-p-uso e todas as associaes potenciaisdefinio-c-uso sejam exercitadas pelo menos uma vez (ii) todos-potenciais-du-caminhos: para todo n i toda varivel x tal que x
G tal que defg(i) e para
defg(i) requer que todos os potenciais du-
caminho c.r.a. x sejam exercitados pelo menos uma vez;
17
Captulo 2 Conceitos Bsicos e Terminologia todos-potenciais-usos/DU: para todo n i G tal que defg(i) e para toda varivel x tal que x
(iii)
defg(i) requer o exerccio das mesmas potenciais
associaes de fluxo de dados c.r.a. x, mas colocando a restrio de que tal associao dever ser exercitada por um du-caminho, a partir do ponto onde ocorreu a definio at o ponto onde poder ocorrer um possvel uso. Maldonado et al. [MAL92] apresentam uma relao de incluso entre os critrios da FCPU e os critrios da FCFD de Frankl e Weyuker. Nesse mesmo artigo foi demonstrado que os critrios da famlia Potenciais Usos mantm uma hierarquia entre os critrios todosramos e o critrio todos-caminhos, mesmo na presena de caminhos no executveis; e que nenhum outro critrio baseado em anlise de Fluxo de Dados inclui os critrios da FCPU. A aplicao dos critrios baseados em anlise de fluxo de dados, sem o apoio de ferramentas automatizadas, fica limitada a programas muito simples [KOR85]. A importncia de tais ferramentas tem sido discutida por vrios autores [DEM80, NTA88, FRA87, WEY84, PRI87, LAS83, MAL91, MAR96] e tem sido feito algum esforo para implementar tal classe de ferramentas [FRA85a, FRA85b, KOR85, WHI85, CHA91, OST91, HOR91, DEL99, CRU99]. Os critrios de teste estrutural tratados em [LAS83, RAP82, NTA84, RAP85, MAL91] foram desenvolvidos com o intuito de serem aplicados no teste de unidade; contudo, seus conceitos e terminologias podem ser usados tanto para o teste de unidade como para o teste de integrao.
Teste de Integrao
Linnenkugel e Mllerburg [LIN90] propem adaptaes de critrios do teste de
unidade para o teste de integrao de programas. O modelo de integrao proposto representa um programa por um grafo de chamada. A abordagem concentra-se em analisar relaes e interfaces entre as unidades. As relaes so determinadas pelos comandos de chamada dentro dos procedimentos e as interfaces so determinadas pelos dados usados nos procedimentos (chamador e chamado). Os critrios baseados em fluxo de controle (todosns, todos-ramos e todos-caminhos) foram adaptados para testar as relaes entre os procedimentos; os critrios baseados em fluxo de dados de Rapps e Weyuker [RAP85] e 18
outros, foram adaptados para testar interfaces. Para o teste de integrao definido um conjunto de critrios baseados no grafo de chamada do programa, idnticos aos critrios baseados em fluxo de controle para o teste de unidade. Os critrios de integrao baseados no grafo de chamada so denominados: i) todos os mdulos: requer que cada procedimento seja executado pelo menos uma vez (equivale ao critrio todos os ns); ii) todas as relaes: requer que cada relao de chamada entre procedimentos seja exercitada pelo menos uma vez; iii) todas relaes mltiplas: requer que cada chamada entre procedimentos seja exercitada pelo menos uma vez (equivale ao critrio todos os arcos); iv) todas seqncias simples descendentes: requer que cada seqncia descendente de chamada sem repetio de chamadas, seja exercitada pelo menos uma vez; v) todas seqncias simples descendentes sem lao: requer que cada seqncia descendente sem lao seja executada pelo menos uma vez; vi) todas seqncias de chamadas: requer que cada seqncia descendente de chamadas seja executada pelo menos uma vez. Considerando as vrias argumentaes de que esses critrios no eram suficientes j que eles no requerem mais do que a execuo de chamadas, insuficiente para testar a interface entre os procedimentos, e que as interfaces entre os dois procedimentos so determinadas pelos dados usados entre elas, Linnernkugel e Mllerburg aplicam os conceitos do teste baseado em anlise de fluxo de dados para definir critrios para o teste de integrao. Esses critrios de teste de integrao so semelhantes aos da Famlia de Critrios de Rapps e Weyuker (int-all-defs, int-all-c-uses/some-p-uses, int-all-puses/some-c-uses, int-all-uses, int-all-du-paths). Harrold e Soffa [HAR91] apresentam uma abordagem para o teste de integrao que estende critrios de teste estrutural baseado em anlise de fluxo de dados para o teste interprocedimental. Os procedimentos so analisados separadamente, de modo a determinar as posies de definies e usos das variveis globais e das variveis passadas por referncia atravs de parmetros, que podem possuir um efeito interprocedimental. proposta uma tcnica de anlise que computa as associaes definio-uso
interprocedimentais requeridas (para dependncia direta e indireta) e um critrio de teste que usa essa informao para selecionar e executar sub-caminhos atravs das interfaces dos procedimentos. 19
Nesta mesma linha, Vilela [VIL98] define um programa como uma coleo de unidades, que pode ser representada por um multi-grafo direcionado denominado grafo de chamada GC(P) = (, , s), onde as unidades de programas (UPs) so representadas pelos ns e os possveis fluxos de controle entre as unidades esto associados a arcos a
. Como GC(P) um multi-grafo, podem existir mais de um arco entre dois ns;
se existir pelo menos um arco entre duas unidades (C e R), existe uma conexo entre essas duas unidades e o arco representado pelo par (C, R ), onde C a unidade chamadora (superior) e R a unidade chamada (subordinada). Assume-se que qualquer n do grafo pode ser executado a partir do n s, chamado de n raiz. Vilela [VIL98] define o caminho de integrao entre duas unidades de programa como sendo formado pela concatenao pin. q. pout, onde pin o subcaminho inicial da unidade chamadora (que vai do n de entrada da unidade C at o n que contm o comando de chamada da unidade R), q o caminho que vai do n inicial da unidade R at o n de sada de R (quando as unidades forem analisadas duas a duas), e pout o subcaminho final de C que vai do n seguinte3 ao n que contm o ponto de chamada de R at o n de sada do grafo de programa da unidade chamadora (C). O conjunto de todos os caminhos de integrao entre duas unidades de programa representado por:
iPath(C,
R) = {iP1, iP2,..., iPn}C,R
onde i significa integrao entre as unidades C e R. O conjunto de todos os caminhos no grafo de chamada GC(P) denotado por GCPath(P) [VIL98]. Vilela [VIL98] prope uma Famlia de Critrios Potenciais Usos de Integrao adaptados dos critrios bsicos e dos critrios executveis da Famlia de Critrios Potenciais Usos aplicados ao teste de unidade. Os critrios propostos em [VIL98] consideram a integrao das unidades feita dois a dois (pairwise) e seus requisitos de teste so derivados para cada par de unidades envolvidas. Os critrios propostos so: i) critrio INT-Todos-Potenciais-Usos; ii) critrio INT-Todos-Potenciais-DU-Caminhos; e iii) critrio INT-Todos-Potenciais-Usos/DU.
Todo bloco de comandos que tiver um comando de chamada dever ser encerrado logo aps o comando de chamada, incluindo ai um novo bloco.
20
A partir da equivalncia de classes de objetos de um programa, Harrold e Rothermel [HAR94] apresentam uma abordagem de teste de integrao entre os mtodos e classes de um programa orientado a objetos. Essa abordagem testa os mtodos e classes segundo trs nveis: i) teste intra-mtodo: testa os mtodos (operaes) individualmente (equivalente ao teste de unidade); ii) teste inter-mtodos: testa um mtodo pblico junto com outro mtodo em sua classe que o chama direta ou indiretamente (equivale ao teste de integrao interprocedimental); iii) teste intra-classe: testa as interaes de mtodos pblicos quando so chamados em vrias seqncias. Este trabalho motivou a abordagem aqui proposta para o teste de programas de ABDR, discutida no prximo captulo. A seguir so apresentados os conceitos bsicos e a terminologia necessria para o entendimento deste trabalho no que se refere rea de Banco de Dados Relacional (BDR).
2.2 Banco de Dados Relacional

O Modelo de Dados Relacional foi introduzido por Codd em 1970 [COD70]. O modelo baseado em uma estrutura de dados simples e uniforme denominada relao e tem uma fundamentao terica apoiada na lgebra relacional (conjunto de operaes para manipular as relaes e especificar as consultas) [DAT90, ELM94]. Esta seo contm uma breve introduo das principais caractersticas e conceitos bsicos do modelo relacional que sero utilizados no teste estrutural de programas de Aplicao de Banco de Dados Relacional (ABDR). Na Seo 2.2.1 so definidos os principais conceitos do modelo relacional. A Seo 2.2.2 define Aplicao de Banco de Dados Relacional (ABDR). Os Sistemas Gerenciadores de Banco de Dados Relacionais usam comandos de SQL (Structured Query Language) para manipular os dados armazenados na relao da base de dados, cujos conceitos so apresentados na Seo 2.2.2.1. Na Seo 2.2.2.2 so discutidos os principais comandos da linguagem SQL usados em programas de ABDR. Finalizando, na Seo 2.2.3 so discutidos alguns trabalhos relacionados ao teste em BDR.
2.2.1 Modelo de Dados Relacional

O modelo relacional representa uma base de dados como uma coleo de relaes. 21
Informalmente, cada relao pode ser considerada como uma tabela. Existem importantes diferenas entre relaes e arquivos; a principal delas a formao estruturada de seus componentes. Quando uma relao tratada como uma tabela de valores, cada linha na tabela representa uma coleo de valores de dados relacionados. Esses valores podem ser interpretados como fatos que representam uma entidade do mundo real ou um relacionamento. O nome da tabela e os nomes das colunas so usados para ajudar a interpretar os valores em cada linha da tabela. Por exemplo, uma tabela com nome EMPLOYEE armazena valores relacionados aos empregados de uma empresa, onde cada linha contm os dados sobre um determinado empregado. Os nomes das colunas emp_id, emp_fname, emp_lname interpretam os valores de dados especficos para cada linha, baseados nos valores de cada coluna. Todos os valores de uma coluna devem ser do mesmo tipo de dados. Na terminologia do modelo relacional formal, uma linha denominada de uma tupla, um ttulo de uma coluna na tabela um atributo e a tabela pode representar uma relao [KRO98]. Os tipos de dados descrevem os tipos de valores de cada coluna e esses tipos de valores so chamados de domnios dos atributos. Um domnio D um conjunto de valores atmicos4. Um domnio uma descrio lgica e fsica dos valores permitidos do atributo. Ele pode ser especificado por um tipo de dado cujos valores condizem com sua representao. Um domnio estabelecido por um nome, um tipo de dado e um formato. Um esquema de relao R, denotado por R(A1, A2, ..., An), formado pelo nome da relao R e um conjunto de atributos A1, A2, ..., An. Cada atributo Ai o nome de um papel exercido por algum domnio Di no esquema relacional R. Di chamado o domnio de Ai e denotado por dom(Ai). Um esquema de relao usado para descrever uma relao. R o nome dessa relao. O grau de uma relao o nmero de atributos n desse esquema de relao. Uma relao (ou instncia da relao) r do esquema de relao R(A1, A2, ..., An), tambm denotado por r(R), um conjunto de n-tuplas r = {1, 2, ..., n}. Cada n-tupla uma lista ordenada de n valores = <v1, v2, ..., vn>, onde cada valor vi, para 1 i n, um
22
elemento do domnio de Ai (dom(Ai)) ou um valor nulo especial. Cada tupla na relao representa uma entidade particular do esquema de relao. Os valores nulos representam atributos cujos valores so desconhecidos ou no existentes para alguma tupla individual da relao. Uma relao r(R) um subconjunto do produto cartesiano dos domnios que definem R: r(R) (dom(A1) dom(A2) ... dom(An)) O produto cartesiano especifica todas as possveis combinaes de valores dos domnios subjacentes. Assim, se denotarmos o nmero de valores ou a cardinalidade de um domnio D por |D|, e assumirmos que todos os domnios so finitos, o nmero total de tuplas resultante do produto Cartesiano : |dom(A1)| * |dom(A2)|*...*|dom(An)| Alm de todas essas possveis combinaes, uma instncia de relao em um dado tempo representa o estado atual da relao e reflete somente as tuplas vlidas que representam um estado particular do mundo real. Em geral, como o estado do mundo real se altera, a relao tambm transformada para outro estado de relao. Entretanto, o esquema R relativamente esttico e no se altera, exceto muito esporadicamente [ELM94]. Um esquema da base de dados relacional S um conjunto de esquemas de relao S={R1, R2, .., Rm} acompanhado de suas restries de integridade. Uma instncia da base de dados relacional DB de S um conjunto de instncias de relaes DB = {r1, r2, ...,rm} tal que cada ri uma instncia de Ri e tal que a relao ri satisfaa s suas restries de integridade. Geralmente, uma aplicao de BDR possui vrios esquemas, e cada esquema S pode possuir vrias relaes sendo algumas comuns a diferentes usurios e outras no. No exemplo apresentado no Captulo 6, adota-se um esquema da base de dados relacional formado pelos seguintes esquemas de relao (tabelas): S = {EMPLOYEE, DEPARTMENT, SALES_ORDER, SALES_ORDER_ITEMS, FIN_CODE, FIN_DATE, CUSTOMER, PRODUCT, CONTACT}
O termo atmico significa que cada valor no domnio indivisvel. No modelo relacional os valores em uma tupla so considerados atmicos.
23
Cada esquema de relao ou tabela possui seus atributos e as respectivas restries, de modo a estabelecer as regras de integridade entre as relaes. Nem sempre a palavra Relacional bem aplicada aos produtos existentes no mercado. Para qualificar um SGBD relacional genuno, o sistema deve possuir pelo menos as seguintes propriedades [ELM94]: 1. Armazenar os dados como relaes de tal maneira que cada coluna seja identificada independentemente de seus nomes sem que a ordenao das linhas seja importante; 2. As operaes disponveis para o usurio e as operaes usadas internamente pelo sistema devem ser operaes relacionais verdadeiras (disponveis para gerar novas relaes a partir de relaes existentes); 3. Suportar pelo menos uma variante de operao de juno (JOIN). Algumas vezes uma relao comparada com uma varivel composta (ex.:um vetor). Uma tupla tambm pode ser considerada como um registro. Tais variveis, quando usadas no teste estrutural, exigem um tratamento especial que veremos com mais detalhes na Seo 2.2.2.2. A seguir apresentaremos os conceitos bsicos de Aplicao de BDR e da linguagem SQL.
2.2.2 Aplicao de Banco de Dados Relacional (ABDR)

As aplicaes de Banco de Dados Relacional so formadas por programas de linguagens convencionais como C, Pascal, Fortran, Cobol, ADA, PL/I e outras mais, que permitem o uso de comandos de SQL embutidos em seu cdigo. O processo de projeto de banco de dados possui vrios passos que precedem a fase de gerao da ABDR. Elmasri e Navathe [ELM94] descrevem as seguintes fases do projeto de banco de dados: (i) coleta e anlise de requisitos: os projetistas fazem vrias reunies com os usurios do Banco de Dados para entender e documentar seus requisitos de dados. Todos os requisitos dos usurios so escritos e posteriormente especificados e detalhados; (ii) projeto de banco de dados conceitual: com os requisitos coletados e analisados, cria-se um esquema conceitual para a base de dados usando o 24
modelo de dados conceitual de alto nvel. O esquema conceitual uma descrio concisa dos requisitos de dados dos usurios e descries detalhadas dos tipos de dados, relacionamentos e restries (utilizando os conceitos fornecidos pelo modelo de dados de alto nvel); (iii) projeto de banco de dados lgico ou mapeamento do modelo de dados: o projeto de banco de dados a implementao da base de dados usando um SGBD comercial. Seus resultados so os esquemas da base de dados a serem usados na implementao do modelo de dados do SGBD; (iv) projeto de banco de dados fsico: as estruturas de armazenamento internas e organizaes de arquivos so especificadas. Vrias fases so definidas em paralelo s fases apresentadas acima. Em paralelo fase de especificao dos requisitos de dados til especificar os requisitos funcionais da aplicao. Esses requisitos so extrados das transaes ou operaes definidas pelos usurios, que sero aplicadas sobre a base de dados e que incluem recuperao e atualizao da base de dados. comum o uso de tcnicas tais como diagramas de fluxo de dados para especificar os requisitos funcionais. Paralelamente ao projeto fsico do banco de dados so projetados os programas de aplicao de Banco de Dados e, a partir da, o projeto implementado na forma de transaes sobre a base de dados, gerando assim, cada programa da Aplicao. Uma aplicao de Banco de Dados composta por um ou vrios programas (descritos em linguagens de programao procedimental) que suportam comandos da linguagem SQL. Para isso, o SGBD deve possuir um pr-compilador que processa o programa fonte gerando um novo programa modificado que ser, ento, submetido compilao e gerao do programa executvel. As linguagens de programao mais comuns como C, Pascal, Fortran, Cobol, e PL/I so aceitas pela maioria dos SGBDs relacionais. O termo linguagem hospedeira usado aqui para representar a linguagem existente nos SGBDs que possibilita o uso de comandos de SQL; programas hospedeiros so os programas da aplicao que hospedam a linguagem SQL.
25
2.2.2.1 Linguagem de Banco de Dados Relacional SQL

A linguagem SQL foi projetada e implementada como uma interface para um sistema de banco de dados relacional denominado sistema R. Atualmente, SQL a linguagem mais usada pelos SGBDRs comerciais e tem sido bastante modificada pelos diversos fornecedores, o que resultou em diferentes tipos de comandos, muitas vezes incompatveis. Houve, ento, a necessidade de se gerar um padro para a linguagem SQL atravs da unio de esforos entre o ANSI e a ISO [DAT84, ISO92, ELM94]. A SQL usa os termos tabela, linha e coluna para representar uma relao, tupla e atributo, respectivamente. Essa distino entre SQL e o modelo relacional formal discutido na seo anterior caracterizada pelo fato de que SQL usa o termo tabela para possibilitar a existncia de duas ou mais tuplas idnticas, pois no modelo relacional isso no permitido. Portanto, uma tabela no , em geral, um conjunto de tuplas, porque o conjunto de tuplas no permite dois membros idnticos [ELM94]. Desta forma, adotaremos os termos tabela, linha e coluna quando estivermos tratando dos comandos da SQL e relao, tupla e atributo quando estivermos referenciando o modelo relacional. Existem vrios SGBDRs tais como o ORACLE, o DB2 da IBM, o INGRES, INFORMIX e outros. Em geral, os SGBDRs permitem o uso de comandos SQL em programas de aplicao (embutidos em linguagens de programao), em mdulos interativos e em programao a partir de uma linguagem de programao procedimental especfica de cada SGBDR. Os comandos da SQL so classificados em dois tipos: declarativos e executveis. Tais comandos so utilizados pelos sistemas que suportam o uso de aplicaes da SQL em linguagens hospedeiras. Existem vrios comandos considerados declarativos; o sistema da ORACLE utiliza o comando DECLARE para declarar os objetos utilizados na prcompilao; o comando INCLUDE utilizado para declarar reas de ligao entre as duas linguagens; e o comando WHENEVER <condio> <ao> declara variveis de controle, colocadas em uma rea de comunicao denominada de SQLCA (no caso do Oracle e DB2); esse comando responsvel pelo fluxo de controle dos comandos executveis da SQL, a partir da <condio> e <ao> adotadas no comando. Os comandos executveis so subdivididos em dois blocos de comandos: Comandos 26
de Definio e Comandos de Manipulao de Dados. Os Comandos de Definio so compostos por: a) (ALTER, CREATE, DROP, RENAME) que definem dados das relaes; e b) (CONNECT, GRANT, LOCK TABLE, REVOKE) que controlam o acesso aos dados dos esquemas da base de dados. Comandos de Manipulao de Dados so compostos por: a) (DELETE, INSERT, UPDATE) usados para manipular os dados das relaes, tambm considerados como comandos de alterao das relaes; b) (CLOSE, FETCH, OPEN, SELECT) usados para recuperar os dados das relaes da base de dados; c) (COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION) usados para processar as transaes das relaes da base de dados; e d) (DESCRIBE, EXECUTE, PREPARE) usados para aplicao com SQL dinmico (que permitem criar consultas em tempo de execuo) [ORA90, ISO92]. A SQL tem um comando bsico que recupera as informaes de uma base de dados: o comando SELECT. O comando SELECT possui comandos de consultas (queries) variados que so apresentados no Apndice B na figura que mostra a gramtica do comando SELECT padro. Existem muitas opes para o comando SELECT na SQL. A base de dados de um SGBDR est disponvel para os usurios e programas de aplicaes atravs de um sistema de controle de permisso. Todos os dados so vistos como tabelas. H dois tipos de Tabelas: Tabelas Bsicas que existem fisicamente como dados armazenados5; e Tabelas de Viso, que so tabelas virtuais sem uma identidade fsica de armazenamento, derivadas de outras tabelas e que s existiro durante a execuo do programa. As Tabelas Bsicas so usualmente geradas em fases que precedem a fase de implementao. Essas tabelas, quando devidamente autorizadas para seus usurios, so consideradas variveis globais a todos os programas da ABDR [ELM94]. As Tabelas de Viso so consideradas variveis locais ao programa que as criou. Elas so criadas atravs do comando CREATE VIEW e so definidas pelo comando SELECT, podendo ser manipuladas por qualquer procedimento pertencente ao Programa; so destrudas pelo comando DROP VIEW [ORA90].
Os dados armazenados como relao ou Tabelas possuem mecanismos prprios do SGBD que gerenciam e controlam as permisses de acesso base de dados. Atravs do gerenciador de dados, do gerenciador de buffer e do gerenciador lgico, o sistema capaz de fornecer todas as funes necessrias para a manipulao dos dados armazenados (pesquisar, recuperar e atualizar).
27
O comando CREATE TABLE <nome-da-tabela> usado para especificar uma nova tabela bsica dando a ela um nome e especificando seus atributos e restries. Os atributos so inicialmente especificados e a cada atributo atribudo um nome, um tipo de dado para especificar o seu domnio de valores e possivelmente algumas restries como chaves primrias, estrangeiras, no nulas etc., usadas para reforar a consistncia e integridade das relaes. O comando ALTER TABLE <nome-da-tabela> possibilita a alterao da estrutura de uma tabela bsica existente. Sempre que uma alterao afetar uma ou mais colunas de uma tabela cujos atributos foram designados com alguma restrio de integridade referencial, pode-se requerer a opo CASCADE para fazer uma alterao de todas as demais tabelas e vises relacionadas a esse atributo. Se a opo escolhida for RESTRICT o comando somente ser efetuado se nenhuma viso ou restrio de integridade referencial fizer referncia a este atributo. Da mesma forma como se pode criar ou alterar uma tabela bsica, pode-se destruir a tabela atravs do comando DROP TABLE <nome-da-tabela>. esperado, portanto, que esses comandos no sejam utilizados com freqncia como ocorre com os demais comandos executveis da SQL. Durante a fase de desenvolvimento de um sistema esses comandos so geralmente aplicados em etapas de implantao das bases de dados de acordo com o projeto lgico do sistema. Apesar de no ser prtica comum o uso desses comandos nos programas de uma aplicao de banco de dados relacional, eles no sero excludos em nosso trabalho. Na prxima seo so apresentados os principais comandos da SQL em programas hospedeiros e os efeitos ocasionados pelas clusulas de comandos de controle dos SGBDRs.
2.2.2.2 Comandos da Linguagem SQL embutida

O termo SQL embutida refere-se a comandos da SQL que podem ser colocados em linguagens de programas procedimentais (como PL/SQL no caso do SGBD da Oracle ou em programas escritos em linguagem C que existe em vrios SGBD) [ELM00]. Como os programas alojam os comandos da SQL, os programas da aplicao so denominados de programas host (hospedeiro), e as linguagens nas quais eles so escritos so denominadas 28
de linguagens host. Por exemplo, o Pro*C o pr-compilador fornecido pelo SGBDR da Oracle e que permite embutir comandos SQL em um programa C denominado de programa host [ORA90]. Geralmente, os comandos SQL so colocados aps a diretiva EXEC SQL, ou &SQL ( e terminada com um ; ou ), respectivamente. No Sistema Gerenciador de Banco de Dados da Oracle, um comando SQL em uma linguagem host apresentado da seguinte forma:
EXEC SQL <comando da SQL>;
Os SGBDRs pesquisados possuem algumas diferenas com relao maneira de tratar os comandos de SQL. Em geral, os SGBDRs que dispem de pr-compiladores de linguagens que hospedam comandos da SQL fornecem mecanismos para manipulao de erros possveis de ocorrer durante uma execuo de comandos da SQL. Tais mecanismos so gerenciados pelo comando declarativo:
WHENEVER <condio> <ao>;
onde as aes estabelecem uma regra de controle de fluxo para os comandos executveis da SQL sempre que a condio for satisfeita. Tambm so gerados valores de controle (cdigos) e armazenados em uma rea de comunicao da SQL, denominada SQLCA. Essa rea de acesso comum serve para a recuperao de informao tanto pelo programa de aplicao como pelo SGBDR. Cada SGBDR define suas prprias condies e aes aplicadas ao comando WHENEVER. O DB2 da IBM, por exemplo, possui as clusulas NOTFOUND PERFORM X e SQLERROR GOTO y; PERFORM X e GOTO y so aes possveis de serem executadas no caso da condio ser satisfeita. Os SGBDRs possuem em geral os seguintes tratamentos de excees: SQLWARNING, SQLERROR, NOT FOUND; e as seguintes aes: CONTINUE, STOP, GOTO<statement_label> e DO<funo>. So as aes que definem os fluxos de controle para os comandos executveis da SQL, encontrados na seqncia esttica (de cima para baixo) a partir do comando WHENEVER, quando a condio for estabelecida. A Figura 2.2 mostra os fluxos de controle dos comandos executveis da SQL.
29
A principal caracterstica do programa de ABDR com comandos de SQL que os valores das relaes da base de dados podem ser manipulados por diferentes usurios, controlados pelo SGBDR que dispe de recursos prprios para garantir a segurana e estabilidade de transao dos dados armazenados nas relaes. Como qualquer programa, podem possuir cdigos mal formulados durante a implementao ou at consultas mal formuladas derivando dados incorretos aos usurios.
CONTINUE STOP GOTO <rtulo> DO <A>;
SQL
SQL
SQL
comando executvel !condio condio !condio
SQL
condio condio
condio
!condio
rtulo
fim
Figura 2.2 : Representao grfica do fluxo de controle dos comandos executveis da SQL gerados pelas aes do comando: WHENEVER <condio> <ao>
Quando utilizado o comando SELECT, entretanto, deve-se definir quantas linhas de dados da tabela queremos que ele retorne. As consultas podem ser classificadas como segue: consultas que no retornam nenhuma linha; consultas que retornam somente uma linha; consultas que retornam mais do que uma linha.
Quando houver necessidade de recuperar mais de uma linha ser necessrio o uso de cursores declarados explicitamente ou o uso de variveis host (conhecidas como variveis de ligao) do tipo vetor para controlar o resultado da consulta. Para manipular os cursores explicitamente nos comandos de SQL, pode-se utilizar: DECLARE <nome_cursor> Nomeia um cursor e associa a uma consulta. OPEN FETCH Executa a consulta e identifica o conjunto ativo. Avana o cursor, recuperando cada linha no conjunto ativo apontado pelo cursor, um a um. 30
CLOSE
Desabilita o cursor.
As variveis hosts so fundamentais para estabelecer a comunicao entre as duas linguagens. Elas so o veculo de dados entre as relaes da base de dados e as variveis do programa hospedeiro e vice-versa. Elas podem ser declaradas como um tipo de dados escalar ou vetor. A varivel host pode ser usada em qualquer expresso no programa hospedeiro; e nos comandos da SQL, elas devem ser prefixadas com um : (dois pontos) para os objetos do SGBDR. Para declarar essas variveis no incio do programa (varivel global) ou no incio de cada procedimento (varivel local) deve-se usar as diretivas EXEC SQL BEGIN DECLARE SECTION; aps declaradas todas as variveis, a seo deve ser encerrada com a linha de comando EXEC SQL END DECLARE SECTION; Nos Exemplos 1 e 2, a seguir, considerem-se as variveis host [dept_num_value, e_emp_name, e_emp_number, e_salary], cujos valores foram recuperados pelo cursor emp_cursor no Exemplo1 e passados para as variveis host aps a clusula INTO no Exemplo2. Exemplo 1: EXEC SQL OPEN emp_cursor; EXEC SQL DECLARE emp_cursor CURSOR FOR SELECT FROM WHERE Exemplo 2: EXEC SQL FETCH emp_cursor INTO :e_emp_name, :e_emp_number, :e_salary; Os recursos de tratamento de erros ajudam a evitar que alguma operao de manipulao da base de dados seja validada de maneira inconsistente. Outros pontos importantes tratados nessa abordagem so as variveis tabela que possuem armazenamento em memria secundria. Essas so tratadas como variveis persistentes que possuem vrias propriedades definidas pelos sistemas de Banco de Dados. Uma varivel dita persistente quando sua definio se mantm viva alm da execuo do programa que a definiu, podendo ser usada na execuo de outra unidade de programa. 31 emp_fname, emp_id, emp_sal EMPLOYEE dept_id = :dept_num_value;
Uma linguagem de programao possui tipicamente estruturas de dados complexas tais como registros, vetores e outros tipos como os oferecidos pela linguagem Pascal ou nas definies de classes em C++. Os valores dessas variveis so em geral descartados quando termina a execuo do programa. Isso no ocorre com as variveis persistentes; seus valores ficam armazenados em memrias secundrias (disco, fitas, etc) podendo ser acessados por qualquer outro programa da ABDR [ELM94]. Os dados na base de dados em um momento particular no tempo so chamados de um estado da base de dados (ou conjunto de ocorrncias ou instncias). Cada vez que se insere ou se remove ou se alteram os valores de uma tupla, est-se alterando o estado da base de dados para outro estado. O SGBDR particularmente responsvel por assegurar que cada estado da base de dados seja um estado vlido, isto , que satisfaa a estrutura e as restries especificadas no esquema da Base de Dados.
2.3
Trabalhos Relacionados
Na rea de desenvolvimento de Banco de Dados existem poucos trabalhos
divulgados que tratam de testes, especificamente teste estrutural. Acredita-se que essa deficincia ocasionada pela falta de ferramentas e tcnicas apropriadas para esse tipo de aplicao. A seguir so apresentados alguns trabalhos que tratam de testes em sistemas de Banco de Dados. Algumas empresas governamentais e institucionais vm investindo, nos ltimos anos, em testes de aplicaes de Banco de Dados com o uso de SQL. A Universidade de Cornell -EUA desenvolveu uma ferramenta denominada SQLBench que utiliza um conjunto de testes Benckmark AS3AP (ANSI SQL Standard Scalable and Portable) para sistemas de BDR com SQL. Essa ferramenta exercita uma bateria de testes de desempenho para plataformas cruzadas, abrangendo um espectro de operaes tpicas de banco de dados e pode ser aplicada em sistemas desenvolvidos nas linguagens C, C++, Cobol e SQL na plataforma Windows [BUT93]. Alguns fatores como demanda de dados da aplicao em tempo real e dependncia de elementos relacionada ao local de trabalho (como nmero de usurios, freqncia de transaes e quantidade de dados envolvidos) so considerados na fase de teste pelo 32
SQLBench. O SQLBench trabalha sob a hiptese de que determinar o desempenho de um sistema de aplicao de BDR em estgios mais fceis (incio de projeto), que precedem a implementao, ajuda a corrigir fraquezas detectadas antes da implementao, evitando maiores desgastes no futuro. Isso possvel se estimarmos as condies de carga de dados esperadas durante uma operao real, visando a resolver possveis problemas de gargalos, resultantes do modelo estrutural de dados ou da estrutura de acesso base de dados provocados, por exemplo, pela execuo de transaes. Na Universidade da Califrnia (EUA) [DAV97] foi desenvolvido um projeto que detalha o processo de desenvolvimento de um sistema de Banco de Dados, envolvendo as fases de planejamento, anlise, projeto, construo e manuteno. Apesar de ser um trabalho completo, no foram divulgadas informaes detalhadas sobre a realizao dos testes durante o desenvolvimento do sistema de Banco de Dados. Yan [YAN91] trata de teste declarativo de banco de dados lgico composto por fatos e regras. No teste de programa, os dados de teste so considerados corretos, bastando apenas verificar a corretitude do programa; j no teste de Banco de Dados necessrio verificar a corretitude de ambos, do Banco de Dados e dos predicados usados nas consultas. Yan parte do princpio de que tanto a base de dados como as consultas podem estar incorretas. O intuito verificar se a base de dados ou as consultas esto inconsistentes ou incompletas, atravs da interpretao da base de dados refletida pela especificao. Tais verificaes tambm so aplicadas na fase de elaborao do projeto da aplicao do BD lgico. Os dados de teste utilizados durante a fase de teste declarativo do BD lgico contribuem para a gerao de dados de testes baseados nas consultas e na base de dados lgica. Mannila [MAN89] descreve uma tcnica que possibilita criar uma amostra simplificada da base de dados real. Em alguns casos, quando as relaes da base de dados de uma ABDR so muito grandes, pode-se ter alguma dificuldade para aplicar os testes. Uma forma de contornar esse problema gerar uma base de dados para o teste, considerada completa, utilizando as prprias consultas existentes no programa [MAN89]. Isso possvel, utilizando operaes de Select Project Join (SPJ) extradas das consultas do programa para gerar uma base de dados pequena que represente a base de dados total. Essa 33
gerao da base de dados para teste um mecanismo que depende do conhecimento de toda a base de dados necessria para cada programa da aplicao, bem como das consultas envolvidas no programa. Chays et al. [CHA00] apresentam uma proposta de como testar sistemas de Banco de Dados e como testar programas de Aplicao de Banco de Dados Relacional. Eles apresentam um framework para teste de Aplicao de Banco de Dados analisando os principais aspectos para a correo de um sistema de Banco de Dados. Nesse artigo tambm so apresentados alguns tipos de restries que podem ser avaliadas: domnio, unicidade, valores de atributos, integridade referencial e integridade semntica. Tambm levantada a importncia da linguagem SQL como linguagem de definio de dados (DDL) e linguagem de manipulao de dados (DML) em aplicaes de Banco de Dados Relacional. Uma das observaes apresentadas est relacionada ao estado da Base de Dados, que no pode ser ignorado, alm dos aspectos do ambiente e da aplicao. Assim, o ideal controlar o estado da base de dados antes e depois da execuo de cada caso de teste. O trabalho desenvolvido por Aranha [ARA00] tem como objetivo testar o esquema da base de dados que ser usado em uma ABDR. Os elementos da base de dados a serem testados so os atributos e as restries de integridade; os critrios propostos no trabalho requerem o exerccio desses elementos atravs de operaes da linguagem SQL. Vrias Famlias de Critrios de testes foram propostas nesse trabalho, visando a exercitar as diferentes ocorrncias relacionadas aos atributos da base de dados. Foram definidas as seguintes famlias de critrios: Atributos sem Restries Explcitas, Atributos com Restries Explcitas, Atributos com Restries de Integridade Referencial (como chave primria e como chave estrangeira), Atributos com Potenciais Restries de Integridade Referencial (como chaves primrias e como chaves estrangeiras). Esse trabalho complementar ao trabalho que ser apresentado nos prximos captulos. A aplicao desses critrios propostos antecede a aplicao dos critrios de teste que sero apresentados neste trabalho.
34
2.4
Consideraes Finais
Neste captulo, so apresentados as tcnicas e os conceitos bsicos de teste
estrutural de programas. A partir dessas tcnicas e desses conceitos so definidos a terminologia e conceitos para o teste estrutural de programas de Aplicao de Banco de Dados Relacionais. Tambm so apresentados os conceitos bsicos de Banco de Dados Relacionais usados no restante desta tese. Os trabalhos relacionados indicam que existem poucas publicaes sobre teste em ABDR e que, apesar de existirem vrias tcnicas de teste estrutural j desenvolvidas elas no contemplam totalmente as necessidades do teste de Programas de ABDR. No prximo captulo so apresentados os conceitos bsicos e a terminologia adotados neste trabalho.
35
36
3 Teste Estrutural de Aplicaes de Banco de Dados Relacional: Conceitos e Terminologia

Neste captulo so apresentados os conceitos bsicos e a terminologia adotada para o teste de programas de ABDR, segundo duas fases de teste: teste de unidade e teste de integrao. O teste de integrao engloba duas abordagens distintas: integrao baseada no grafo de chamada (idntica abordagem para programas convencionais) e integrao baseada na dependncia de dados existente entre as variveis tabela da Base de Dados; a segunda abordagem uma das contribuies deste trabalho ao teste estrutural de programas de ABDR. A abordagem de teste proposta para programas de ABDR considera dois tipos de fluxo de dados denominados intra-modular e inter-modular.
3.1 Teste estrutural de ABDR: conceitos bsicos e terminologia

O teste estrutural de programas de ABDR com SQL embutida6 apresenta caractersticas similares as do teste de programas convencionais. Assim, as tcnicas convencionais de teste podem ser aplicadas em programas de aplicao a partir de algumas adaptaes necessrias, tendo em vista a presena de comandos SQL e variveis tabela e variveis host, no existentes em programas convencionais. Os conceitos bsicos apresentados nesta seo so os relativos aos critrios estruturais de teste de programas convencionais, modificados e estendidos para os critrios estruturais de testes utilizados em aplicaes de Banco de Dados Relacionais. Na elaborao da abordagem de teste para programas de aplicao foi necessrio: i) adaptar os conceitos e critrios de testes de unidade e de integrao de programas convencionais para programas de ABDR; e ii) criar novos critrios de teste estrutural especficos para o escopo de Banco de Dados Relacional (BDR). Uma Aplicao de Banco de Dados Relacional (ABDR) composta por um ou mais Mdulos de programa, onde cada Mdulo7 composto por um conjunto de Unidades de Programa (UP) que so os procedimentos e funes do programa. Para no confundir com
6 7
A partir deste ponto, programa de ABDR com SQL embutida passa-se a chamar de programas de aplicao. A palavra Mdulo usada nesta abordagem no tem o mesmo significado de [MAL91], onde significa a menor unidade de teste; aqui um Mdulo representa um programa de aplicao de BDR.
37
Captulo 3 Teste Estrutural de Aplicaes de Banco de Dados Relacional: Conceitos e Terminologia
a terminologia adotada na literatura o mdulo que representa a menor parte executvel de um programa ser denominado, no contexto desta tese, de unidade de programa ou simplesmente unidade. Os Mdulos geralmente podem ser codificados em diferentes linguagens procedimentais com SQL embutida, dependendo do Sistema Gerenciador de Banco de Dados (SGBD) adotado. A Figura 3.1 apresenta uma idia geral de uma aplicao de BDR.
Aplicao
Unidades de Programa Mdulos de Programa
Mod1
Mod2
Mod3 ...
Modm
Cada Mod. representa um programa: C, Pascal , ADA, PL/I, etc.
... t1 t2
... t3 ...
... tn
Cada t representa uma tabela das Relaes da base de dados.
Figura 3.1. Uma Aplicao de Banco de Dados Relacional
Devido existncia dos comandos de SQL em programas hospedeiros de aplicaes de Banco de Dados relacional, a definio de grafo de programa foi alterada para acomodar os comandos executveis da SQL em ns especiais, um em cada n. A representao grfica de uma unidade de programa a mesma adotada em [CLA89, MAL91], estendida para ABDR com uso de SQL. O Mdulo Modi pode ser decomposto em vrias UPs que representam as funes ou subrotinas de Modi, onde 1 i m. Cada UP uma seqncia finita de comandos da linguagem hospedeira e comandos da linguagem SQL. Na representao grfica, os comandos da linguagem hospedeira e os comandos declarativos da SQL podem ser acomodados em blocos de comandos, tal como foi definido no Captulo 2. Os comandos executveis da linguagem SQL (INSERT, DELETE, UPDATE, SELECT, COMMIT, ROLLBACK, entre outros) [ORA90] so acomodados isoladamente. Como notao grfica adota-se ns circulares para representar os blocos de comandos (linguagem 38
hospedeira e comandos declarativos da SQL) e ns retangulares para representar os comandos executveis da SQL. As setas, denominadas de arcos, representam possveis transferncias de controle entre os ns. O grafo de programa para representar uma UP de uma ABDR denotado por G(UP)=(NBD, , nin, nout) onde NBD = Nh NS, onde Nh o conjunto de ns provenientes da linguagem hospedeira e NS o conjunto de ns provenientes da linguagem SQL; o conjunto de arcos onde E NBD NBD. O n nin Nh o n de entrada e nout NBD o n de sada do grafo de programa. O grafo de programa estabelece uma correspondncia entre os comandos do programa representados pelos conjuntos de ns Nh e NS, indicando os possveis fluxos de controle entre os ns atravs dos arcos [SPO97]. Os conjuntos Arcin(i) e Arcout(i) representam os conjuntos de arcos que respectivamente chegam e saem do n i. O exemplo da Figura 3.2 mostra o grafo de programa para a UPSelemp, extrada do Mdulo Mod3 (usado no exemplo de aplicao, descrito no Apndice C). Os arcos (4,15), (7,15), (10,15) e (13,15) Arcin(15) e os arcos (3,4) e (3,18) Arcout(3). Um caminho uma seqncia finita de ns (n1, n2,..,nk), k 2, tal que, para todo i, 1 i k-1, existe um arco (ni, ni+1) . Um caminho completo quando o primeiro n o n nin de entrada (n 1 no exemplo da Figura 3.2) e o ltimo n o n nout de sada (n 19 no exemplo da Figura 3.2). Um caminho simples se todos os ns que o compem, exceto possivelmente o primeiro e o ltimo, so distintos. Se todos os ns so distintos, diz-se que o caminho um caminho livre de lao. O comando declarativo EXEC SQL WHENEVER SQLERROR GOTO end16; utilizado para tratamento de erro nos comandos SQL foi colocado no n 1 (junto com os comandos da linguagem C) e ele ocasiona a ocorrncia dos arcos (3, 18), (6, 18), (9,18) e (12,18) com a condio de um desvio condicional para o rtulo end16 colocado no n 18. A abordagem de teste estrutural para programas de ABDR considera dois tipos de fluxos de dados: i) fluxo de dados intra-modular; e ii) fluxo de dados inter-modular. O fluxo intra-modular usado para o teste estrutural de cada Mdulo de Programa da aplicao. O fluxo intra-modular usado no teste de unidade e no teste de integrao intramodular; este ltimo efetuado para a integrao das unidades de programa.
39
int selemp (line) RECORD *line; /* 1 */ { FILE * path = fopen("selemp/path.tes","a"); static int printed_nodes = 0; /* 1 */ char string[10], strfield[4]; /* 1 */ int field; /* 1 */ EXEC SQL BEGIN DECLARE SECTION; int cod_value; VARCHAR lname_value [20], address_value [40], rg_value [11]; EXEC SQL END DECLARE SECTION; ponta_de_prova(1); /* 1 */ EXEC SQL WHENEVER SQLERROR GOTO end16; /* 1 */ printf(" \n 1-Codigo Empregado 2- Sobrenome 3- Endereco 4-RG "); /* 1 */ gets (strfield); /* 1 */ field = atoi (strfield); /* 1 */ switch(field) /* 1 */ { /* 2 */ case 1 : /* 2 */ { ponta_de_prova(2); /* 2 */ printf ("\n Digite o codigo do Empregado: "); /* 2 */ gets (line->e_emp_id); /* 2 */ cod_value = atoi (line->e_emp_id); ponta_de_prova(3); /* 3 */ EXEC SQL SELECT TO_CHAR(emp_id), TO_CHAR(manager_id), emp_fname, emp_lname INTO :he1, :he2, :he3, :he4 FROM EMPLOYEE WHERE emp_id = :cod_value; ponta_de_prova(4); /* 4 */ break; /* 4 */ } /* 5 */ case 2 : /* 5 */ { ponta_de_prova(5); /* 5 */ printf ("\n Digite o Sobrenome do Empregado:"); /* 5 */ gets (line->e_emp_lname); /* 5 */ strcpy (lname_value.arr, line->e_emp_lname); /* 5 */ lname_value.len = strlen (lname_value.arr); ponta_de_prova(6); /* 6 */ EXEC SQL SELECT TO_CHAR(emp_id), TO_CHAR(manager_id), emp_fname, emp_lname INTO :he1, :he2, :he3, :he4 FROM EMPLOYEE WHERE emp_lname = :lname_value; /* /* /* /* /* /* /* /* /* /* 7 */ 7 7 8 8 8 8 8 8 */ */ */ */ */ */ */ */ printf("\n Sem erro: "); ponta_de_prova(7); break; } case 3 : { ponta_de_prova(8); printf ("\n Digite o Endereco do Empregado:"); gets (line->e_street); strcpy (address_value.arr, line->e_street); address_value.len = strlen (address_value.arr); ponta_de_prova(9); EXEC SQL SELECT TO_CHAR(emp_id), emp_fname, emp_lname INTO :he1, :he2, :he3, :he4 FROM EMPLOYEE WHERE street = :address_value; printf("\n Sem erro:"); ponta_de_prova(10); break; } case 4 : { ponta_de_prova(11);
/* 11 */ Empregado:"); /* 11 */ /* 11 */ /* 11 */ /* 12 */
printf ("\n Digite o Numero do RG do gets (line->e_ss_number); strcpy(rg_value.arr, line->e_ss_number); rg_value.len = strlen (rg_value.arr); ponta_de_prova(12); EXEC SQL SELECT TO_CHAR(emp_id), TO_CHAR(manager_id), emp_fname, emp_lname INTO :he1, :he2, :he3, :he4 FROM EMPLOYEE WHERE ss_number = :rg_value; printf("\n Sem erro:"); ponta_de_prova(13); break; } default: { ponta_de_prova(14); sqlca.sqlcode=-1; } } /* switch */ ponta_de_prova(15); printf ("code = %d\n", sqlca.sqlcode); if(sqlca.sqlcode == 0) { ponta_de_prova(16); if(sqlca.sqlerrd[2] == 1) { ponta_de_prova(17); itoa(he1, line->e_emp_id); itoa(he2, line->e_manager_id); he3.arr [he3.len] = \0; strcpy (line->e_emp_fname, he3.arr); he4.arr [he4.len] = \0; strcpy (line->e_emp_lname, he4.arr); } } ponta_de_prova(18); ponta_de_prova(19); fclose(path); return (sqlca.sqlcode); }
/* 13 */
/* /* /* /*
13 13 14 14
*/ */ */ */
/* 14 */ /* 14 */ /* 15 */ /* 15 */ /* 15 */ /* 16 */ /* 16 */ /* 17 */ /* /* /* /* /* /* /* /* /* 17 17 17 17 17 17 17 18 18 */ */ */ */ */ */ */ */ */ end16:
/* 18 */ /* 19 */
G (Selemp)
9 */
/* 10 */ /* /* /* /* 10 10 11 11 */ */ */ */
Figura 3.2: Grafo de Programa da Unidade de Programa Selemp do Mdulo de Programa Mod3.
O fluxo inter-modular utilizado para o teste estrutural considerando o fluxo de dados entre os Mdulos de Programas que compem a ABDR. Esse fluxo de dados envolve as variveis tabela da base de dados. O teste baseado neste tipo de fluxo de dados foi
40
denominado de teste de integrao inter-modular, efetuado para integrar os diferentes Mdulos de Programas existentes na aplicao. Qualquer critrio de teste estrutural apresentado no Captulo 2 pode ser aplicado no teste de unidade dos programas de aplicao. Em particular, neste trabalho utiliza-se como exemplos os critrios da FCPU. O teste de integrao intra-modular compe-se de duas abordagens distintas: teste de integrao baseado no grafo de chamada e teste de integrao baseado no fluxo de dados das variveis tabela da base de dados. As definies dos critrios de teste baseados nos fluxos intra-modular e inter-modular so apresentadas no Captulo 4. A seguir so apresentados os conceitos bsicos de teste estrutural para programas de aplicao e a terminologia adotada neste trabalho.
3.1.1 Teste de unidade

Numa aplicao de Banco de Dados Relacional so usados trs tipos de variveis: variveis de programa, P = {p1,p2,..,pm}, (variveis da linguagem hospedeira); variveis de ligao ou variveis host, H = {h1, h2, ..,hn}, (que guardam os valores da base de dados); e as variveis tabela, T = {t1, t2, ..,tk}, que so as tabelas da base de dados relacional manipuladas pelo programa. As variveis tabela de viso so extradas das variveis tabela da base de dados da aplicao. A ocorrncia de uma varivel host ou de uma varivel de programa pode ser: uma definio de varivel, um uso de varivel ou uma indefinio. As variveis tabela so variveis globais para todos os Mdulos de Programas Modi de uma ABDR. As variveis tabela so criadas pelo comando CREATE TABLE <tabela> e essa criao feita uma nica vez durante o projeto do banco de dados. A partir de sua criao, o SGBD passa a controlar os acessos s tabelas da ABDR, permitindo que seus usurios possam modific-las e/ou atualiz-las a partir dos programas da aplicao. Assim, as variveis tabela no so declaradas como as variveis host e variveis de programa nos programas de aplicao. Desse modo, adota-se a ocorrncia de uma varivel tabela t como sendo definio ou uso e considera-se que toda varivel tabela referenciada por algum programa implica a ocorrncia de uma definio anterior (at por outro mdulo de programa). No h, portanto, nenhuma exigncia sinttica em declar-la antes de uma 41
definio ou antes de um uso; para as demais variveis pode ocorrer um erro de compilao ou uma anomalia [ORA90, ELM94]. Uma varivel considerada definida quando um valor armazenado em uma posio de memria. No caso das variveis de programa e variveis host, quando estiver nos comandos na linguagem hospedeira, uma ocorrncia de varivel uma definio se ela estiver: i) ii) iii) no lado esquerdo de um comando de atribuio8; em um comando de entrada; ou em chamadas de procedimento como parmetro de sada.
Nos comandos da SQL, uma ocorrncia das variveis host uma definio se ela estiver: iv) dentro da clusula INTO de um comando SELECT ou FETCH.
Uma varivel tabela considerada definida quando um valor armazenado em memria secundria modificando assim o estado da varivel tabela de e0 para e1. Uma ocorrncia de varivel tabela em um programa uma definio se ela estiver: I. II. III. IV. em uma clusula INTO do comando INSERT; em uma clusula FROM do comando DELETE; do lado esquerdo da clusula SET do comando UPDATE; e no caso de uma viso, quando estiver no lado direito da clusula CREATE VIEW. Apesar de esses comandos da SQL caracterizarem a ocorrncia de definio da varivel tabela, as ocorrncias I, II e III s so efetivadas quando so executadas juntas com o comando COMMIT, quando o valor armazenado em memria secundria. Para distingui-la das demais definies (em memria interna), denomina-se de definio persistente de t sempre que ocorre uma alterao em seu estado fsico (em memria secundria). Isto s possvel se houver um comando de manipulao da SQL seguido do comando COMMIT.
8
Em caso de variveis do tipo array, x[i]=0, implicam na definio apenas da varivel x e no do ndice i. O mesmo ocorre com variveis do tipo registro. No caso de C++ e Java, que permitem comandos do tipo y++ que implica no uso de y seguido de uma definio de y e outros comandos que so tratados de maneira especial.
42
Por exemplo, na Figura 3.3 existe a definio da varivel DEP somente se a seqncia <2, 4> faz parte do caminho. Assim, para o caminho (1, 2, 5, 6) no existe a definio persistente de DEP. Como conseqncia, para estabelecer uma associao definio-uso atravs de uma definio persistente requer-se que os dois ns que caracterizam a definio persistente faam parte do caminho; para isso adotou-se a notao <l,i> para denotar o par de ns que caracteriza a definio persistente. Caso contrrio, dizemos que o n l possui a definio por referncia (a varivel foi referenciada) e o n i possui a definio por valor (um valor foi atribudo a ela) da varivel tabela. Em geral, o comando COMMIT deveria seguir cada um dos comandos que caracterizam uma definio da varivel tabela durante a manipulao de dados (INSERT, DELETE, UPDATE), mas no podemos garantir que isso sempre acontece. No caso de no existir pode-se adotar a abordagem de associar ao n de sada do grafo (nout) o comando COMMIT esperado. No Exemplo da Figura 3.3 seria o n 6.
1 2
INSERT INTO DEP
COMMIT
5 6 Figura 3.3 - Exemplo de um grafo de programa com SQL embutida.
Devido existncia de tratamento de erro, comum a existncia de dois arcos de sada dos ns da SQL que contm um comando de execuo. No caso de tratamento de erros, dizemos que uma definio de t em um n i NS s ser efetivada, na prtica, quando a execuo tomar o caminho que incluir o arco de sada pertencente a ARCout(i), cujo
43
predicado contm um erro nulo (SQLERROR=0) e que leva execuo do comando COMMIT. A ocorrncia de uma varivel um uso quando a referncia a essa varivel no a estiver definindo, ou seja, h a recuperao de um valor em uma posio de memria associada a esta varivel [NTA84]. Em geral, uma ocorrncia de varivel de programa ou varivel host nos comandos da linguagem hospedeira um uso se ela estiver: i) ii) iii) iv) no lado direito de um comando de atribuio; em um comando de sada; em chamada de procedimento como parmetro de entrada; em um predicado de um comando condicional.
Para uma varivel host, nos comandos da SQL, uma ocorrncia da varivel um uso se ela estiver: v) vi) na condio da clusula WHERE dos comandos SELECT, DELETE e UPDATE; do lado direito do comando de atribuio da clusula SET do comando UPDATE; vii) I. II. III. IV. na clusula VALUE do comando INSERT. na clusula FROM dos comandos SELECT e DELETE; em uma clusula INTO do comando INSERT; do lado esquerdo da clusula SET do comando UPDATE; na clusula WHERE dos comandos executveis DELETE, UPDATE e SELECT. Quando se tratar de uma varivel tabela de viso, a ocorrncia ser um uso quando estiver: V. no operando do comando DROP VIEW.
Uma ocorrncia de uma varivel tabela um uso quando ela estiver:
Para distinguir os tipos de usos definidos na Seo 2.1, so introduzidos os seguintes conceitos: a) Uma referncia a uma varivel v um s-uso (uso SQL) se v afeta o resultado de uma consulta ou de uma computao em um comando executvel da SQL (este uso est associado ao n da SQL); b) O uso de uma varivel tabela t (persistente) ocorre quando estiver em algum n j NS com um dos comandos executveis da SQL que
44
caracterizam o uso da varivel t (SELECT, INSERT, UPDATE ou DELETE), o uso persistente ser associado aos arcos ARCout(j) e ser denominado de t-uso. O s-uso ocorre dentro de algum n n NS e pode influenciar o fluxo de controle nos arcos de sada (t-uso) dos ns pertencentes ao conjunto de NS quando houver tratamento de erros; um s-uso pode envolver as variveis host e variveis tabela e o t-uso envolve apenas o uso persistente da varivel tabela t. O tratamento da definio e uso de vetores, registros e apontares merecem uma ateno especial. Em geral, diz-se que um tratamento proposto conservador [MAL91] se ele no deixa de requerer nenhum fluxo de dados que possa existir; ou seja, a seleo de caminhos e associaes a mais rigorosa dentre as possveis. No programa de aplicao, um caminho (i, n1, n2, ..., nm, j) para m 0, com definio da varivel v no n i e que no contm nenhuma redefinio de v nos ns n1, n2, ..., nm chamado de caminho livre de definio com respeito a (c.r.a) v do n i ao n j e do n i ao arco (nm, j). Essa definio vlida para: todos os ns em NBD, todos os arcos de e todas as variveis de uma ABDR. Um n i NBD possui uma definio global de uma varivel v se toda vez que ocorre uma definio de v no n i existe um caminho livre de definio de i para algum n ou para algum arco que contm um uso c.r.a. v. Um c-uso da varivel v em um n j um cuso global se no existir uma definio de v no n j precedendo este c-uso; caso contrrio, um c-uso local. Geralmente, todo s-uso um s-uso global. Dizemos que o caminho (nl,...,ni, ..., nj, nk) um caminho livre de definio persistente de <nl, ni> at o n k, se no existe outro par de ns <nq, nm> onde ocorre uma redefinio persistente de t em <nq, nm> do n ni at o n nk onde o par <nl, ni> antecede o par <nq, nm>. Lembrando que na ausncia de um comando COMMIT, aps um comando executvel da SQL at o ltimo n de um grafo, adota-se que o COMMIT estar no ltimo n do grafo. Rapps e Weyuker [RAP85] definem que os comandos podem possuir sucessores e antecessores fsicos (seqncia de escrita) ou de execuo (fluxo de execuo). Um comando sintaticamente alcanvel se existe uma seqncia de comandos s1, ..., sn tal que
45
s1 o comando de partida e sn o comando de chegada e cada si precede a execuo de si+1, para i = 1, ..., n-1. Requer-se, portanto, que cada comando no programa seja sintaticamente alcanvel. A partir dos conjuntos definidos por Rapps e Weyuker [RAP82, RAP85], apresentados na Seo 2.1, so definidos os conjuntos a seguir, utilizados para descrever os conceitos bsicos dos critrios de testes para programas de aplicao: (i) s-uso(i)={variveis com s-uso no n i Ns}; (ii) defT<l,i> = {Varivel t | t possui uma definio persistente pela concatenao dos ns l e i, representado por <l, i> onde l e i NS .} (iii) dsu(v,i)={ns j NS | v s-uso(j), existe um caminho livre de definio c.r.a. v do n i para o n j e v defg(i) (onde defg(i) representa o conjunto de todas variveis com definio global no n i)}.
2 3 5 7 10
INSERT
UPDATE
DELETE
11
SELECT
COMMIT
12
16 18
13 14 15
17
19
Figura 3.4: Funo com os principais comandos de manipulao da SQL para uma tabela t.
Em (ii) observa-se que existe a definio persistente em variveis tabela t em um caminho se e somente se ambos os ns l e i NS pertencem ao caminho. No exemplo da Figura 3.4 o caminho (1, 2, 3, 4, 13, 14, 17, 2, 7, 8) no contm definio persistente da varivel tabela t visto que, apesar de o n 4 conter o comando INSERT, o comando
46
COMMIT no faz parte do caminho. Somente os caminhos contendo os pares de ns <4, 9>, <6, 9> ou <8, 9> contm definio persistente da varivel t (conjuntos defT<4,9>, defT<6,9>, defT<8,9>). Em geral, o n de sada de um grafo no pertence ao conjunto NS. Na ausncia sinttica do comando COMMIT em um procedimento que contm um comando de manipulao da SQL (INSERT, DELETE, UPDATE), considera-se que o comando COMMIT ocorre no n de sada do grafo (por default). Se o grafo da Figura 3.4 no tivesse um n com o comando COMMIT, as definies persistentes de t seriam, por exemplo: defT<4,19> e defT<6,19> e defT<8,19>. Para efeito de implementao dos critrios da FCPU para o teste de unidade foi considerado que existe uma definio de t (na memria interna) nos ns que contm um comando de manipulao da SQL (INSERT, UPDADE ou DELETE) (ns 4, 6 e 8 da Figura 3.4) e que existe uma definio persistente de t no n da SQL que contm o comando COMMIT (no grafo da Figura 3.4 o n 9). Para os programas de aplicao, um caminho (n1, n2, ..., nj, nk) um du-caminho c.r.a v se n1 tiver uma definio global de v e: i) nk tem um c-uso ou s-uso de v e (n1, n2, ...,nj, nk) um caminho simples livre de definio c.r.a v; ou ii) o arco (nj, nk) tem um p-uso de v e (n1, n2, ...,nj, nk) um caminho livre de definio c.r.a v e n1, n2, ...,nj um caminho livre de lao. Uma associao definio-c-uso uma tripla [i, j, v] onde i um n que contm uma definio global de v e j dcu(v,i). Uma associao definio-p-uso uma tripla [i,(j,k),v] onde i um n que contm uma definio global de v e o arco (j, k) dpu(v, i). Uma associao uma associao-c-uso, uma associao-p-uso ou um ducaminho. As definies apresentadas na Seo 2.1.3 (teste de unidade) podem ser estendidas para programas de aplicao no que se refere s variveis host e variveis tabela. Considere-se que toda varivel host e varivel tabela pode ter uma definio global em um n i, isto , defg(i) = {varivel v | v uma varivel do conjunto de todas as variveis usadas em programas de aplicao}. Considerando que as variveis host e variveis tabela possuem uma definio global no n i, os critrios da FCPU ou da FCFD podem ser aplicados no teste de unidade. As seguintes definies complementam os conceitos bsicos para a definio dos critrios de teste de programas de ABDR:
47
(a) Associao definio-s-uso uma tripla [i, j, v] onde v defg(i) e j dsu(v,i); (b) Associao definio-t-uso uma tripla [<l,i>, (j,k), t] onde t defT<l,i>, j dsu(t,i), o arco (j,k) o arco de sada do n j. (c) dtu-caminho um caminho livre de definio persistente (nl , ..., ni, ..., nj, nk) c.r.a. t dos ns <nl , ni> at o n nk ou at o arco (nj, nk ) onde ocorre um uso de t e o caminho (nl , ..., ni, ..., nj, nk), onde ni < nj e ni < nk um caminho livre de lao e no par de ns <nl , ni> ocorre uma definio persistente de t. Um dtu-caminho um du-caminho com relao a varivel tabela no enfoque de varivel persistente. Uma associao pode ser uma associao definio-c-uso, uma associao definio-p-uso, uma associao definio-s-uso, uma associao definio-tuso, um du-caminho ou um dtu-caminho. Toda associao uma potencial associao no enfoque de Potencial Uso [MAL91]. Observao: o conceito de potencial associao, alm de possibilitar a identificao de defeitos devido ao uso incorreto de variveis, inclui tambm a possibilidade de identificar defeitos devido ausncia do uso, que tambm um defeito [MAL91]. Partindo dessa premissa, as variveis tabela jamais iro requerer associaes com os ns pertencentes ao conjunto de ns Nh, isto , ns da linguagem hospedeira, pelo fato de ser impossvel o uso de uma tabela nestes ns. Essa situao verdadeira tendo em vista que tanto a definio como o uso de uma varivel tabela s possvel ocorrer em um comando executvel da SQL, conforme foi especificado no incio desta seo. O grafo de fluxo de dados definido por Maldonado [MAL91] no necessita referenciar os pontos onde h ocorrncia de um uso de uma varivel, mas apenas os pontos onde existe uma definio global de uma varivel; da a denominao de grafo-def9. O grafo-def pode ser facilmente adaptado para: 1) programas de aplicao, acrescentando as informaes especficas de comandos de SQL e observando as operaes de controle do SGBDR (responsveis pelos fluxos aps os comandos SQL) e, 2) os trs tipos de variveis existentes nos programas de aplicao (programa, host e tabela) para o teste de unidade.
9
Os autores [RAP82, NTA84, RAP85] definem o grafo de fluxo de dados como grafo def-uso, que contm informaes de ocorrncias de c-uso, p-uso e definies.
48
Desta forma, para cada n i tal que defg(i) associado um grafo denominado grafo(i) que contm todos os potenciais-du-caminhos com incio no n i. Cada n k do grafo(i) completamente identificado pelo nmero do n do grafo de programa que lhe deu origem e pelo conjunto deff(k) o conjunto de variveis definidas no n i, mas no redefinidas num caminho do n i para o n k [MAL91]. Maldonado [MAL88b] props um algoritmo para a obteno desses grafos. A partir desses grafos e do conceito de arco primitivo apresentado em [MAL91], estabelece-se a base para o Modelo de Descrio dos Elementos Requeridos para os critrios da FCPU [MAL91, CHA91]. Adotou-se a FCPU para exemplificar o teste de unidade neste trabalho por causa da disponibilidade da ferramenta POKE-TOOL que apia a aplicao desses critrios. Uma associao denotada por [i, (j,k),{v1, ...,vn}], onde i o n onde ocorre a definio das variveis v1, ...,vn e existe um caminho livre de definio c.r.a v1, ...,vn do n i ao arco (j,k). Cada grafo(i) contm todos os caminhos livres de definio c.r.a as variveis v definidas em i que podem satisfazer a potencial associao do n i com os demais arcos alcanveis com caminhos livres de definio c.r.a v. As variveis v representam o conjunto de todas as variveis P H de uma aplicao de BDR. As definies defg(i) (definio lgica) e defT<l,i> (definio fsica) so tratadas de maneira distinta nos critrios de teste propostos nesta tese. O conjunto defg(i) usado apenas no teste de unidade e no teste de integrao baseado no grafo de chamada. O conjunto defT<l,i> pode ser usado em todos os tipos de testes estruturais propostos nesta tese, mas ser dada nfase para o seu uso no teste de integrao baseado na dependncia de dados (intra-modular e inter-modular). A cobertura de uma associao por um caminho completo ocorre se incluir um caminho livre de definio c.r.a v do n i (onde ocorre a definio de v) ao n j ou arco (j,k) onde se estabeleceu a associao. Um conjunto de caminhos completos cobre uma associao se algum dos elementos do conjunto o fizer. Essa definio vlida para todos os critrios de teste estrutural baseados em anlise de fluxo de dados. A partir do conceito de caminho executvel estabelecido em [FRA88] pode-se dizer que uma associao executvel se existir um caminho completo executvel que cubra essa associao; caso contrrio, ela no executvel. Definimos como conjunto factvel: 49
(d) fdsu(v, i) = {j dsu(v,i) | a associao [i, j, v] onde j NS, executvel}; Observe que nas definies apresentadas na Seo 2.1.3 (teste de unidade), o n j pertence ao conjunto Nh onde NS Nh = NBD. Alguns conceitos vistos em [NTA84, RAP85, FRA88, MAL91, CHA91, HAR91] foram aproveitados e adaptados para a proposta de teste estrutural de programas de aplicao apresentados nesta tese. Ao teste de unidade pode ser aplicado qualquer critrio de teste estrutural, ou seja, o teste de programas de ABDR pode ser suportado por ferramentas, adequadamente modificadas, que implementem a utilizao desses critrios. A ferramenta de teste POKE-TOOL e a ferramenta de visualizao ViewGraph v.2.0 foram utilizadas na realizao de um exemplo de aplicao para ilustrao de nossa proposta. A ferramenta POKE-TOOL, que apia o Teste de Unidade para programas convencionais, foi modificada para o teste dos programas de aplicao. A ferramenta ViewGraph (v.2.0) [VIL94, VIL97, CRU99] permite a visualizao grfica e de informaes dos resultados obtidos do teste de cada UP dos Mdulos de Programas de uma ABDR.
3.1.2
Teste de Integrao
O teste de integrao aplicado depois que todas as unidades que compem um
programa foram devidamente testadas isoladamente (teste de unidade). O teste de integrao pode ser visto como uma tcnica sistemtica para a construo da estrutura do software, procurando revelar defeitos associados interao entre as Unidades do Programa (UP) ou entre os Mdulos de programas (Mod). A dependncia de dados um aspecto fundamental associado interao entre Unidades de Programas e Mdulos de Programas. As dependncias de dados existentes entre as UPs de programas convencionais so ocasionadas pelas variveis globais ou por variveis passadas por parmetros atravs de comandos de chamadas. Os programas de aplicao possuem dependncias de dados baseadas nos comandos de chamada, como acontece nos programas convencionais, e dependncias de dados baseadas nas tabelas da base de dados. As dependncias de dados entre as UPs e os Mdulos de Programas de uma ABDR do ensejo a novas abordagens de integrao, descritas na Seo 3.1.2.2.
50
A seguir so apresentados os conceitos bsicos do teste de integrao baseado nas chamadas de procedimentos em programas de aplicao.
3.1.2.1 Teste de integrao baseado no grafo de chamadas

Algumas caractersticas do teste de unidade podem ser aproveitadas e adaptadas para o teste de integrao. Assim como no teste de unidade, tambm podemos utilizar qualquer critrio de teste de integrao estrutural para exercitar as variveis v existentes nos programas de aplicao que tenham uma definio global em algum n do grafo da unidade chamadora C e que alcancem um n que contm um comando de chamada para a unidade
R, por um caminho livre de definio c.r.a. v; pode existir uma associao com relao a
qualquer ponto da unidade chamada.
C R insert t1 commit select t1 call R() select t1
GC(P)
G(C)
G(R)
Figura 3.5: Exemplo de um grafo de chamada entre duas UPs (C e R)
Para as definies de Vilela [VIL98], a Figura 3.5 mostra duas unidades de programa que so relacionadas por um ponto de chamada e apresenta um grafo de chamada contendo apenas dois ns (C e R). O conjunto iPath(C,R), definido na Seo 2.1.3, contm os seguintes caminhos:
iP1 iP2 iP3 iP4
= (1C, 2C, 3C, 4C , 6C), (1R, 2R, 3R, 5R, 6R, 7R), (7C, 8C); = (1C, 2C, 4C , 6C), (1R, 2R, 3R, 5R, 6R, 7R), (7C, 8C); = (1C, 2C, 3C, 4C , 6C), (1R, 2R, 3R, 6R, 7R), (7C, 8C); = (1C, 2C, 4C , 6C), (1R, 2R, 3R, 6R, 7R), (7C, 8C); 51
iP5 iP6 iP7 iP8
= (1C, 2C, 3C, 4C , 6C), (1R, 2R, 4R, 5R, 6R, 7R), (7C, 8C); = (1C, 2C, 4C , 6C), (1R, 2R, 4R, 5R, 6R, 7R), (7C, 8C); = (1C, 2C, 3C, 4C , 6C), (1R, 2R, 4R, 6R, 7R), (7C, 8C); = (1C, 2C, 4C , 6C), (1R, 2R, 4R, 6R, 7R), (7C, 8C);
Vrios conceitos tratados em [CLA89, VIL98], destacando-se a das associaes definio-uso, aplicadas para variveis globais e variveis passadas por parmetros, podem ser adaptados para programas de aplicao. As variveis de interesse particular de um programa de aplicao (variveis host e as variveis tabela) ocorrem nos ns que contm comandos da SQL. As variveis tabela so globais para todos os Mdulos de Programa, enquanto as variveis host e variveis de programa so locais ou globais dependendo do escopo em que so declaradas. O conjunto de variveis usadas como entrada ou sada de uma chamada c da unidade de programa UP1 para UP2, denotado inc, o conjunto de parmetros reais, ou variveis globais, usados como entrada na chamada c da UP1; outc o conjunto de parmetros reais ou variveis globais usadas como sada na chamada c da UP1 UP2; o conjunto de todas as variveis, inc outc, denominado de variveis de comunicao [VIL98] entre as unidades de programas. Vilela [VIL98] define que um parmetro formal correspondente a um parmetro real x de uma chamada c denotado por formalc(x); no caso de uma varivel global x, formalc(x) mapeia a varivel x para ela mesma; formalc(x) = x. Cabe lembrar que no vamos tratar das variveis aliases (ponteiros). Visando a englobar todas as variveis de um Programa de ABDR, estendemos as notaes tratadas em Vilela [VIL98], acrescentando: i) associao-definio-s-uso interprocedimental de chamada: uma
qudrupla [i, j, v, c] onde c uma chamada de uma unidade UP1 para outra UP2; v inc; i NBD um n de UP1 que contm definies globais de variveis de v; j NS um n de UP2 que contm um s-uso global de formalc(v) e existe um sub-caminho livre de definio c.r.a v de i para nc e c.r.a formalc(v) de nin(UP2) para j. ii) associao-definio-s-uso interprocedimental de retorno: uma qudrupla [i, j, v, c] onde c uma chamada de uma unidade UP1 para outra UP2; v outc; i NBD um n de UP2 que contm uma definio global de formalc 52
(v); j NS um n de UP1 que contm um s-uso global de v e existe um sub-caminho livre de definio c.r.a formalc(v) de i para nout(UP2) e c.r.a v de nc para j em UP1. iii) associao-definio-t-uso interprocedimental de chamada: uma
qudrupla [<l, i>, (j, k), t, c] onde c uma chamada de uma unidade de programa UP1 para a UP2 no n nc do G(UP1); t inc; l e i NS so ns de G(UP1) que contm uma definio persistente de t, na concatenao <l,i>; (j, k) um arco de sada do n j NS em UP2 que contm um uso de t (tuso) e contm um sub-caminho livre de definio persistente c.r.a t de i para nc e c.r.a t de nin(UP2) at (j, k). iv) associao-definio-t-uso interprocedimental de retorno: uma qudrupla [<l, i>, (j, k), t, c] onde c uma chamada de uma unidade de programa UP1 para outra UP2 no n nc de G(UP1); t outc; l e i NS so ns de G(UP2) que contm uma definio persistente de t em <l, i>; j NS e um n de G(UP1) que contm um t-uso e contm um sub-caminho livre de definio persistente c.r.a t de i para outc e c.r.a t de nc at j. As associaes i) e ii) tratam das variveis host que podem ser exercitadas por qualquer critrio estrutural de teste de integrao [CLA89, VIL98], por serem variveis que podem ser definidas e usadas em quaisquer ns dos grafos G(UP1) e G(UP2) quando da chamada de uma Unidade de Programa UP1 por outra UP2. O mesmo no ocorre com as variveis tabela que possuem um tratamento exclusivo e diferente das demais variveis (host e programa). Uma associao-definio-t-uso interprocedimental baseada no grafo de chamadas formada pela quntupla [UPA, <l, i>, UPB , (j, k), { t }], onde <l, i> representa o par de ns de NS que caracterizam uma definio persistente de t e so ns da UPA, isto , t defT<l,i> e (j, k) um arco da UPB cujo n j contm um uso de t e o arco (j,k) Arcout(j). O exemplo mostrado na Figura 3.6a contm as seguintes associaes def-t-uso interprocedimental ou inter-unidade:
53
<Insdep,<2,3>, Seldep,(3,4), {DEPARTMENT}>; <Insdep,<2,3>, Seldep,(3,16),{DEPARTMENT}>; <Insdep,<2,3>, Seldep,(6,7),{DEPARTMENT}>; <Insdep,<2,3>, Seldep,(6,16),{DEPARTMENT}>; <Insdep,<2,3>, Seldep,(9,10),{DEPARTMENT}>; <Insdep,<2,3>, Seldep,(9,16),{DEPARTMENT}>;
O caminho de integrao interprocedimental iPath(A, B) composto pela composio dos caminhos completos pA e pB, onde pA o caminho completo da unidade A que contm o ponto de definio persistente de t e o caminho pB o caminho completo da unidade B que contm o ponto onde ocorre o uso de t a partir da definio persistente em pA. No exemplo dado na Figura 3.6a temos: iPath(Insdep, Seldep) = {(1, 2, 3, 4, 5)Insdep || (1, 2, 3, 4, 12, ..., 17)Seldep, (1, 2, 3, 4, 5)Insdep || (1, 2, 3, 16, 17)Seldep, ..., (1, 2, 3, 4, 5)Insdep || (1, 2, 9, 16, 17)Seldep }onde (1, 2, ...,n)A || (1,2, ...,m)B representa um caminho de integrao entre as unidades UPA e UPB , ou seja, || a concatenao do caminho completo percorrido na UPA com o caminho completo percorrido na UPB. Observao: o caminho (1, 2, 3, 4, 12, ..., 17) implica que qualquer trajeto de 12 a 17 satisfaz a associao. Uma associao inter-unidade <A,<l, i>,B,(j,k),{t}> ser satisfeita se e somente se existe um caminho iPath(A, B) = pA || pB tal que pA contm a definio persistente de t em <l, i>, pB contm um uso de t no arco (j, k) e existe um caminho livre de definio persistente de <l, i> at nout de UPA e de nin de UPB at cada arco ARCout(j) de UPB. Desta forma, ser mapeado o conjunto de associaes definio-t-uso para cada varivel t envolvida na integrao a partir do grafo de chamada do Mdulo de Programa. Uma observao feita neste caso quando ocorrer a ausncia do comando COMMIT em uma Unidade UP1 onde contem um comando de SQL que define a varivel tabela t, e existe um n que contem um comando de chamada, o comando COMMIT ser considerado neste n, visando assim possibilitar a ocorrncia de uma associao definiot-uso interprocedimental de chamada, o mesmo ocorre no retorno para o ltimo n do grafo.
54
3.1.2.2 Teste de integrao baseado na dependncia de dados

A principal caracterstica de programas de aplicao, que os distingue dos programas convencionais a persistncia dos dados da base de dados. As unidades de programas e os mdulos de programa, se autorizados, podem ter acesso a esses dados a qualquer momento. A persistncia uma propriedade que no depende exclusivamente de Banco de Dados Relacional (BDR), podendo ser estendido para outros programas com as mesmas caractersticas. No caso de BDR, a mesma tabela da base de dados pode estar disponvel para diferentes mdulos de programa da aplicao e, conseqentemente, para diferentes UPs de um mesmo mdulo. Neste caso, duas unidades de programas podem possuir uma dependncia de dados entre elas, mesmo no existindo chamadas entre elas. Duas unidades de programa A e B possuem uma dependncia de dados de A para B com relao varivel tabela t, se a unidade A possuir um ponto no programa que define a varivel tabela t (isto , altera o estado da tabela de ei para ei+1) e a unidade de programa B possuir um ponto no programa que usa a varivel tabela t (com o estado de t idntico a ei+1). Para uma varivel tabela t com uma definio persistente em uma unidade UPA (passando a varivel t para um estado eA) estar em um estado consistente de A (representado por eA) se e somente se no existir nenhuma redefinio persistente de t em pelo menos um subprograma UPA no n de sada. Existe uma dependncia de dados c.r.a. varivel tabela t se t tem uma definio persistente em uma unidade UPA e existe um caminho livre de definio c.r.a. t incluindo o sub-caminho de UPA a partir da definio persistente at o n de sada e um sub-caminho do n de entrada de uma unidade UPB at um s-uso de t. Observao: notar que por esta definio, UPA e UPB podem ser a mesma unidade de programa, ou seja, a dependncia de dados entre a definio persistente (par de ns) at a sada da Unidade que a definiu (UPA) e o t-uso precedente a qualquer definio persistente a partir da entrada na Unidade que usa (UPB). So considerados dois tipos de dependncia de dados c.r.a t: i) Dependncia interna ou intra-modular: ocorre quando existir uma dependncia de dados entre unidades de programa de um mesmo Mdulo de
55
Programa, com relao a uma ou mais tabelas, mesmo quando no existir um ponto de chamada entre elas, (Figura 3.6a). ii) Dependncia externa ou inter-modular: ocorre quando existir uma dependncia de dados entre duas ou mais UPs de Mdulos de Programas diferentes c.r.a t . Isto , t deve estar disponvel para os dois Mdulos de Programa, (Figura 3.6b).
Mod3
Seldep
INSERT SELECT
COMMIT
Insdep
DEPARTMENT
dep_id 10 20 30 d_name Sales Deposit Market manager_id 1232 3443 4565
...
...
40 50
DPC Medical
6677 2344
Figura 3.6a: Grafo de dependncia Interna de dados c.r.a DEPARTMENT. GDPA(InsdepMod3 SeldepMod3)DEPARTMENT
Considere o grafo de dependncia de dados de um programa de ABDR, GDPA(AModi BModj)T =([G(Ai) G(Bj)], Eint, T)= ([(1%', (, nin, nout)A (1%', (, nin, nout)B], Eint, T]), onde G(Ai) G(Bj) representa a unio dos conjuntos de arcos e ns do grafo de programa da unidade A do mdulo de programa i e do grafo de programa da unidade B do mdulo de programa j; E o conjunto de arcos (setas pontilhadas) que mostram o fluxo de dados das unidades de programa para a tabela e vice-versa, e T o conjunto de tabelas envolvidas na dependncia de dados. GDPA(AModiBModj)T um multi-grafo direcionado
56
que representa o fluxo de dados baseado na dependncia de dados extrada da associao def-uso c.r.a. t. Um exemplo desse grafo apresentado na Figura 3.6b. Uma seta (pontilhada) direcionada da UP para a tabela caracteriza a ocorrncia de uma definio da varivel tabela t pela UP. Uma seta direcionada no sentido da tabela t para a UP, caracteriza a ocorrncia de um uso da tabela t pela UP. O Exemplo mostrado na Figura 3.6a. um grafo de dependncia Interna, mas se as UPs A e B pertencerem a Mdulos de Programas distintos tratar-se- de grafo de dependncia Externa (Figura 3.6.b). No exemplo da Figura 3.6.a. a UP Insdep define a varivel tabela DEPARTMENT (n 3) e a UP Seldep usa a varivel tabela DEPARTMENT em vrios pontos do programa (ns 3, 6 e 9). J no exemplo da Figura 3.6.b. a UP Inscus do Mdulo de Programa Mod2 define a varivel tabela CUSTOMER no n 3 e a UP Relcli do Mdulo de Programa Mod4 usa essa mesma varivel no n 2.
Mod2
id
101 102 103 104 105 106 107 108 109 110
t
fname
Michaels Beth Erin Meghan Laura Paul Kelly Matthew Jessie Michael
Mod4
lnam
Devlin Reiser Niedring Mason McCarthy Phillips Colburn Goforth Gagliard Agliori
Inscus
CUSTOMER
Relcli
Figura 3.6b: Grafo de dependncia Externa de dados c.r.a CUSTOMER entre as UPs Inscus (Mod2) e Relcli (Mod4). GDPA(InscusMod2 RelcliMod4)CUSTOMER
O Grafo geral de dependncia de dados um multi-grafo composto por todos os grafos de programas das UPs que possuem uma dependncia de dados c.r.a alguma varivel tabela t. Assim, o grafo de dependncia geral denotado por GDG = (GUP, Eint, TBD), onde GUP so os grafos das Unidades de Programa, Eint so os arcos de integrao que indicam o fluxo de dados entre as Unidades de Programas e as Tabelas da base de dados e TBD so as tabelas da base de dados pontilhadas, que caracterizam as dependncias de dados. O grafo geral tem o objetivo de dar um panorama completo das UPs que definem e/ou usam alguma 57
varivel tabela, ajudando a visualizar os grafos de dependncia de dados GPA(AModi BModj)t, para o teste de integrao intra-modular. A Figura 3.7 mostra o grafo geral de dependncia de dados, para o Mdulo de Programa Mod3. Um grafo de dependncia externa de dados geral pode ser tambm construdo para cada varivel tabela permitindo, assim, organizar melhor todas as relaes existentes entre as UPs contidas nos mdulos de programas da aplicao. Para simplificar a Figura 3.7, foram colocadas as trs unidades que contm uma definio persistente em uma mesma representao grfica relacionada a
Mod3 Insdep, Deldep, Upddep. Insemp, Delemp, Updemp Insfinc, Delfinc, Updfinc
Insfind, Delfind, Updfind.
Inssal, Delsal, Updsal.
...
Department Employee Fin_code Fin_date Sales_order Customer
Mod3 Seldep Selemp Selfin Selsal
Figura 3.7: Grafo de Dependncia de dados interna entre as Unidades do Mdulo de Programa Mod3 . Ilustrada com os grafos de programas das UPs.
58
cada varivel tabela. Podemos observar tambm que a varivel tabela CUSTOMER no possui nenhum relacionamento com as Unidades deste programa. O teste de integrao baseado na dependncia de dados existente entre as Unidades de Programa um teste caracterizado por exercitar as associaes definio-uso c.r.a. varivel t, entre duas ou mais Unidades de Programas (internas ou externas). Essa tcnica de teste complementar tcnica de teste de unidade; sua finalidade detectar defeitos associados a variveis tabela atravs das dependncias de dados entre as UPs (classes de defeitos no tratadas nos outros tipos de tcnicas de teste).
3.2 Consideraes Finais

Neste captulo foram introduzidos os conceitos de teste estrutural aplicado em programas de aplicao. Os trabalhos apresentados em [RAP85, WEY86, FRA88, LIN90, MAL91, VIL98] foram estendidos para a abordagem de teste estrutural de Banco de Dados Relacional, adaptando alguns conceitos aos programas de aplicao e criando novos conceitos, especficos para programas de aplicao. A caracterstica essencial de uma ABDR a existncia de comandos da SQL que manipulam as variveis tabela, tratadas como variveis persistentes, e que possibilitam a criao de novas abordagens de teste estrutural. Foram propostos novos conceitos que relacionam a ocorrncia de uso de variveis dentro dos comandos de manipulao da SQL (denominados de s-usos). Prope-se uma nova tcnica de teste de integrao baseada na dependncia de dados, que associa uma varivel definida em uma unidade com unidades que usam a mesma varivel. Esses conceitos formam uma base para a definio dos critrios de teste estrutural baseados em fluxo de dados intra-modular e inter-modular que so propostos no prximo captulo.
59
60
4 Critrios de Teste: Definio e Anlise de Propriedades

Neste captulo so apresentados os critrios propostos e a anlise de suas propriedades. Na Seo 4.2 so descritos os tipos de fluxo de dados dos programas de aplicao: intra-modular e inter-modular; na Seo 4.3 so descritos os critrios de teste intra-modular; na Seo 4.4 so descritos os critrios de integrao inter-modular; a Seo 4.5 contm a anlise de propriedades dos critrios.
4.1 Consideraes iniciais

Foram propostos para o teste de unidade somente os critrios de teste que exercitam as variveis persistentes (tabelas), tendo em vista que qualquer critrio estrutural baseado em fluxo de dados pode ser usado para exercitar as variveis de programa e variveis host. O teste de integrao intra-modular considera duas abordagens: i) teste de integrao baseado no grafo de chamadas, segundo as definies de Vilela [VIL98]; e ii) teste de integrao baseado na dependncia de dados (da varivel tabela). Esta segunda abordagem visa a exercitar associaes definio-t-uso derivadas do fluxo de dados entre as unidades com comandos que caracterizam ocorrncia de definio e as unidades com comandos que caracterizam ocorrncia de uso.
4.2 Tipos de Fluxos de Dados

A anlise do fluxo de dados baseia-se nos tipos de ocorrncia das variveis de um programa de aplicao. Conforme foi discutido no captulo anterior, existem trs tipos de variveis: i) variveis de programa: so as variveis do programa hospedeiro; ii) variveis host: so as variveis que estabelecem os fluxos de dados entre a base de dados e o programa; e iii) variveis tabela: so as variveis tabela bsicas (variveis persistentes que compem a base de dados) e as variveis tabela de viso (tabelas virtuais derivadas das tabelas bsicas e tratadas como variveis locais ao Mdulo de Programa). Cada tipo de varivel tem o seu escopo de validade. Uma varivel de programa processada apenas no mbito da linguagem hospedeira, uma varivel host processada tanto na linguagem
61
Captulo 4 Critrios de Teste: Definio e Anlise de Propriedades
hospedeira como na linguagem SQL e uma varivel tabela processada apenas na linguagem SQL. Considera-se que o projeto lgico das tabelas da aplicao est correto e que elas foram definidas e testadas anteriormente implementao dos programas de aplicao.
4.2.1 Fluxo Intra-modular

O fluxo de dados intra-modular utilizado para o teste de cada Mdulo de Programa. Inicialmente feito o teste de cada UP que compe o Mdulo de Programa (teste intra-unidade ou teste de unidade). Depois que todas as Unidades foram devidamente testadas, realiza-se o teste de integrao para as UPs do Mdulo de Programa (teste interunidades ou teste de integrao intra-modular). A partir do grafo de programa G(UP) de cada UP do Mdulo construdo o grafo de dependncia de dados que representa os fluxos de dados entre as UPs que compem o Mdulo. O grafo de dependncia pode ser construdo baseado na hierarquia de chamada entre as UPs ou baseado na dependncia de dados entre as UPs determinada pelas variveis tabela presentes no Mdulo. A Figura 4.1 apresenta um exemplo de dependncia de dados entre as unidades de um mesmo mdulo (Mod3). O Mdulo Mod3 possui comandos de SQL com definies e usos persistentes de cinco das oito variveis tabela mostradas na figura. Toda seta direcionada da varivel tabela t para o n de um grafo representa um uso de t naquele n e toda seta apontada do n para a varivel tabela t representa uma definio persistente de t naquele n. Toda unidade que tem um uso de uma varivel t possui uma dependncia de dados com as unidades que tm uma definio persistente da mesma varivel t.
62

Mdulo de Programa Mod3
CUSTOMER
EMPLOYEE
PRODUCT
DEPARTMENT
FIN_CODE
FIN_DATE
SALES_ORDER
SALES_O_T
Insfind
Delfind
Updfind
Selfin
Insfinc
Delfinc
Updfinc
Figura 4.1: Exemplo do Fluxo de Dados Intra-Modular completo.
63
4.2.2 Fluxo Inter-modular

O fluxo de dados inter-modular determinado a partir das dependncias de dados ocasionadas pelas tabelas da base de dados comuns aos Mdulos da ABDR. Uma UPi de um Mdulo Modk pode estar definindo uma varivel tabela t enquanto outra UPj contida em outro Mdulo ModW pode estar usando a mesma varivel tabela t, determinando assim, um fluxo de dados entre os mdulos Modk e Modw. Assim, possvel definir associaes definio-uso c.r.a t (denominada de associao definio-t-uso-inter) entre os mdulos de programas criando um grafo de dependncia externa de dados entre a UPi do Mdulo Modk que possui uma definio persistente da varivel t e a UPj do Mdulo Modw que possui um uso persistente da varivel t. O modelo de fluxo de dados inter-modular composto por ns retangulares contnuos que representam os Mdulos de Programa e ns retangulares pontilhados representando as variveis tabela que compem a base de dados da aplicao. As setas indicam os fluxos de dado entre os ns. Tendo em vista que um Mdulo de Programa visto como um conjunto de Unidades de Programa Moda = {UP1, .., UPm}, temos: a) Seta do Mdulo de Programa (Modi) para tabela t: indica que existe uma UP Modi tal que UP tem uma definio persistente da tabela t; b) Seta da tabela t para o Mdulo de Programa Modi: indica que existe uma UP Modi tal que UP tem um uso persistente da tabela t. A execuo de cada mdulo de programa feita isoladamente no havendo, portanto, rotinas de controle entre eles. De acordo com o exemplo apresentado na Figura 4.2, o mdulo de programa Mod2 define as tabelas CUSTOMER e SALES_ORDER. Da mesma forma, o mdulo Mod2 usa as tabelas CUSTOMER e SALES_ORDER. Deste modo, possvel formar todas as relaes que determinam associaes definio-uso para cada Mdulo de Programa (Mod); essas informaes so extradas das UPs pertencentes a cada Mdulo de Programa que possurem um par <l, i>, da definio persistente de t, com as UPs que possurem um comando da SQL que usa a tabela t.
64
Para entendermos melhor a Figura 4.2 apresentado um mapa que relaciona para cada Mdulo de Programa, as aes de ocorrncia (definio e uso) para cada varivel tabela (numeradas da esquerda para a direita).
Mdulos de Programa
Mdulo1
Mdulo2
Mdulo3
Mdulo6
Tabelas
Customer
Employee Sales_order Department Fin_Code Fin_Date
Product
Sales_O_I
t1 t2 t5 t6 t7 t8 t4 t3 Figura 4.2: Fluxo de dados inter-modular de uma ABDR composta por 4 Mdulos de Programa e 8 tabelas que constituem a base de dados
Tabela 4.1:Mapa de definio e uso das variveis tabela mostradas nos Mdulos de Programa da Figura 4.2. Mdulos de Programa t1 Modulo1 Modulo2 Modulo3 Modulo6 t2 Tabelas definidas t3 t4 t5 t6 t7 t8 t1 t2 Tabelas usadas t3 t4 t5 t6 t7 t8
X X X X X X X X X X X X X X X X X X X X X X X X X X X
4.3 Os critrios intra-modulares

Os critrios de teste intra-modulares so aplicados no teste de cada UP do Mdulo (teste de unidade) e no teste de integrao das UPs do Mdulo. Para o teste de unidade podemos utilizar qualquer critrio de teste estrutural apresentado no Captulo 2; os critrios para o teste de integrao so divididos em dois subgrupos: critrios de testes baseados no grafo de chamada e critrios de testes baseados na dependncia de dados das tabelas. Os critrios de teste propostos para associar as variveis persistentes devem ser satisfeitos com a mesma tupla, forando o testador a gerar casos de testes especficos para exercit-la. Deste modo, o teste deve ser executado de maneira controlada, no sendo suficiente usar qualquer tupla de t. Por outro lado, com a exigncia do uso da mesma tupla para satisfazer uma associao definio-t-uso, pode aumentar o nmero de elementos requeridos no factveis (isto , no executveis com a mesma tupla). 65
4.3.1
Critrios aplicados ao teste de unidade

No teste de unidade pode ser aplicado qualquer critrio de teste estrutural. Neste
trabalho usou-se a Famlia de Critrios Potenciais Usos [MAL91] por razes j apresentadas. Entretanto, os critrios para o teste de unidade no contemplam o teste de variveis persistentes. Para tratar as variveis persistentes, so propostos os critrios descritos a seguir. Considere os conceitos apresentados na Seo 3.1.1, que trata do teste de unidade para variveis persistentes. Seja G(UP) um grafo de programa e um conjunto de caminhos completos de G(UP). Seja um conjunto de tuplas {1, 2, ..., c} pertencentes a uma dada tabela t:
Todos os t-usos: requer para todas as associaes definio-t-uso [<l,i>, (j,k), t] que pelo menos um caminho =(nin, .., l, .., i, .., j, k, .., nout) , livre de definio persistente de <l,i> at (j, k) c.r.a. t, seja exercitado pelo menos uma vez, para a mesma tupla .
Todos os dtu-caminhos: requer que todos os dtu-caminhos (nl , ..., ni, ..., nj, nk) sejam executados pelo menos uma vez. A associao deve ser exercitada para a mesma tupla .
Assim, um conjunto de caso de testes Tc, que resulta em e : Satisfaz o critrio (Todos os t-usos) se, para todo par <l, i> de ns G(UP) com defT<l,i> para toda varivel t defT<l,i>, incluir todas as associaes [<l,i>, (j,k), t] onde <l, i> contm uma defT<l,i> e existir um t-uso em (j, k) sendo j fdsu(t, i) e j NS; e existe um caminho livre de definio persistente de <l,i> at (j, k). A associao ser satisfeita se e somente se for exercitada para a mesma tupla . Satisfaz o critrio (todos os dtu-caminhos) se, para todo par <l, i> de ns G(UP) com defT<l,i> , incluir todos os dtu-caminhos de <l,i> at (j, k), c. r. a. cada varivel t defT<l,i> para todas as associaes [<l,i>, (j, k), t ] tal que <l , i> contm uma defT<l,i> e existe um t-uso em (j, k) onde j fdsu(t, i) e j NS; e existe um
66
Captulo 4 Critrios de Teste: Definio e Anlise de Propriedades caminho livre de definio persistente de <l,i> at (j, k). A associao ser satisfeita se e somente se for exercitada para a mesma tupla . Esses critrios tm como objetivo requerer que todo sub-caminho que inicia no n l da SQL (INSERT ou DELETE ou UPDATE) e passa pelo n i (COMMIT), onde ocorre a definio persistente de t, e alcana um arco de sada do n da SQL, onde ocorre o uso de t (t-uso) com os comandos (INSERT, DELETE, UPDATE ou SELECT), sejam executados pelo menos uma vez para a mesma tupla . Como exemplo, considere o Grafo G(UP) da Figura 4.3, uma UP que contm as quatro operaes da SQL. Neste exemplo, u1, u2, u3 e u4 representam os arcos que contm um uso de t (t-uso) e d1, d2 e d3 representam os pares de ns que caracterizam a definio persistente de t (sempre representado pelo par <l,i>). O critrio todos os t-usos para o teste de unidade s ter elementos requeridos se existirem comandos de repetio envolvendo comandos de manipulao da Base de Dados na UP ou repetio dos comandos de
Todos-t-usos 1 2 3 5 7 10 ocorrncias
INSERT
6 u2
UPDATE
8 u3
DELETE
11 u4
SELECT
u1
COMMIT
12
16 18
13 14 15
17
19
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
[<4, 9>, (4, 9), t] [ <4, 9>, (4, 13), t] [ <4, 9>, (6, 9), t] [<4, 9>, (6, 13), t] [<4, 9>, (8, 9), t] [<4, 9>, (8, 13), t] [<4, 9>, (11, 12), t] [<4, 9>, (11, 13), t] [<6, 9>, (4, 9), t] [<6, 9>, (4, 13), t] [<6, 9>, (6, 9), t] [<6, 9>, (6, 13), t] [<6, 9>, (8, 9), t] [<6, 9>, (8, 13), t] [<6, 9>, (11, 12), t] [<6, 9>, (11, 13), t] [<8, 9>, (4, 9), t] [<8, 9>, (4, 13), t] [<8, 9>, (6, 9), t] [<8, 9>, (6, 13), t] [<8, 9>, (8, 9), t] [<8, 9>, (8, 13), t] [<8, 9>, (11, 12), t] [<8, 9>, (11, 13), t]
d1u1 d1. d1 u1.. d1u2d2.. d1u2.. d1u3d3.. d1u3... d1u4... d1u4... d2 u1d1. d2 u1.. d2u2d2.. d2u2.. d2u3d3.. d2u3... d2u4... d2u4... d3 u1d1. d3 u1.. d3u2d2.. d3u2.. d3u3d3.. d3u3... d3u4... d3u4...
Figura 4.3: Exemplo de um procedimento que contm todas operaes da SQL.
67
manipulao na seqncia de execuo da UP. No caso da varivel tabela a ocorrncia de anomalias de fluxo de dados no necessariamente um defeito. Uma seqncia de ocorrncias que define uma varivel tabela no precisa ser usada antes de uma outra definio da mesma varivel. Outro tipo de anomalia, que no necessariamente um defeito, o uso de uma varivel t em uma UP sem uma definio da mesma no programa. Lembrando que os critrios de teste que exercitam as variveis persistentes somente so satisfeitos se a associao definio-t-uso for exercitada com a mesma tupla; o objetivo exercitar as associaes de t em memria secundria. No exemplo da Figura 4.3 temos os seguintes dtu-caminhos:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 4 9 3 4 13 5 6 9 5 6 13 7 8 9 7 8 13 10 11 12 10 11 13 3 4 9 3 4 13 5 6 9 5 6 13 7 8 9 7 8 13 10 11 12 10 11 13 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 4 9 3 4 13 5 6 9 5 6 13 7 8 9 7 8 13 10 11 12 10 11 13 3 4 9 3 4 13 5 6 9 5 6 13 7 8 9 7 8 13 10 11 12 10 11 13 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 14 14 14 14 14 14 14 14 15 15 15 15 15 15 15 15 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 4 9 3 4 13 5 6 9 5 6 13 7 8 9 7 8 13 10 11 12 10 11 13 3 4 9 3 4 13 5 6 9 5 6 13 7 8 9 7 8 13 10 11 12 10 11 13
Como exemplo, o quinto dtu-caminho (4
9 13 14 17 2 7 8 9)
ser satisfeito se e
somente se a tupla usada na definio persistente no par <4, 9> for a mesma usada no arco de sada do n da SQL (8, 9) onde ocorre um t-uso e existir um caminho livre de definio persistente c.r.a. t do par <4, 9> at o arco (8, 9) e um caminho livre de lao a partir do n 9 at o arco (8, 9). De maneira anloga essas regras so vlidas a todos dtu-caminhos.
4.3.2 Critrios aplicados ao teste de integrao intra-modular

Os critrios de teste de integrao intra-modular so divididos segundo duas abordagens de teste: Baseada no grafo de chamada - para exercitar as variveis definidas na memria interna pode ser usado qualquer critrio de teste de integrao como os
descritos em [VIL98]; Baseada na dependncia de dados - para exercitar as variveis persistentes so propostos critrios especficos para programas de aplicao que requerem o exerccio de associaes def-uso de variveis persistentes.
68
Os critrios de integrao intra-modular visam a exercitar as associaes definiot-uso determinadas pelos comandos de manipulao da base de dados. Tanto os critrios de integrao baseados no grafo de chamadas como os critrios baseados na dependncia de dados determinada pelas tabelas da base de dados visam a exercitar as associaes referentes s variveis de programa (P), variveis host (H) ou variveis tabela (T), de acordo com o enfoque estabelecido pelos critrios.
4.3.2.1 Critrios de Teste de integrao baseados no grafo de chamadas

Os critrios definidos nesta seo esto baseados na mesma idia dos critrios Potenciais Uso de Integrao definidos e analisados em Vilela [VIL98]. O grafo de chamada um multi-grafo, podendo haver mais de uma chamada entre duas Unidades de Programa, o que corresponde ocorrncia de mais de um arco ligando os respectivos ns do grafo. Essa abordagem considera a integrao das Unidades de Programa (UPs), feita duas-a-duas (pairwise) e os requisitos de teste so, consequentemente, derivados para cada par de UPs. Para estender os critrios de integrao propostos por Vilela, so definidos dois critrios que tm como finalidade exercitar as associaes envolvendo as variveis tabela t. Os critrios de teste de integrao em [VIL98, OST91, LIN90, HAR91] so derivados dos critrios de teste de unidade, visando a associar pontos de definio e uso para as variveis globais ou variveis passadas por parmetros que se mantm vivas ao longo das unidades envolvidas na integrao, controladas pelo grafo de chamada do programa. Nesse caso, so consideradas as variveis de programa e as variveis host. Os critrios propostos nesta seo tm como objetivo exercitar associaes definio uso para as variveis tabela j que no caso das variveis host, quando forem tratadas como variveis globais, podem ser exercitadas por qualquer critrio de teste estrutural de integrao. Por exemplo, os critrios de Vilela possibilitam considerar as variveis host, com definio global em algum n i de uma unidade UPa que, a partir de um caminho livre de definio, alcance algum comando de chamada para outra unidade UPb. Os critrios Potenciais-Usos de integrao contemplam as variveis host e tabelas de viso, existentes em programas de aplicao (casos i e ii da Seo 3.1.2.1).
69
As definies dadas em iii e iv da Seo 3.1.2.1 contemplam as variveis persistentes e do origem aos dois critrios: todas as associaes-definio-t-uso-int e todos os dtu-caminhos-int (de integrao), apresentados abaixo. Esses critrios exercitam as associaes baseadas no grafo de chamada, para as variveis tabela como variveis persistentes. Lembre-se que o t-uso ocorre nos arcos de sada do n da SQL com uso de t. i) Todos os t-usos interprocedimentais de chamada: requer que todas as associaes [<l,i>, (j, k), t, c] sejam satisfeitas, onde c uma chamada de uma unidade UPa para outra unidade UPb no n nc do G(UPa); t inc; onde defT<l,i> , e l NS e i NS e so ns de G(UPa) que contm uma definio persistente de t; j NS e um n de G(UPa), existe um t-uso global de t em (j, k) Arcout(j) e contm um sub-caminho livre de definio c.r.a t de i para nc e c.r.a t de nin(UPb) para j; a associao satisfeita se e somente se for exercitada atravs da mesma tupla . Uma associao-definio-t-uso interprocedimentais de chamada representada pela sextupla: [UPa, <l, i>, UPb, (j, k), t, c] ii) Todos os t-usos interprocedimentais de retorno: requer que todas as associaes [<l,i>, (j, k), t, r] sejam satisfeitas, onde c uma chamada de uma unidade UPa para outra unidade UPb no n nc de G(UPa); t outc; onde defT<l,i> , e l NS e i NS e so ns de G(UPb) que contm uma definio persistente de t; j NS e um n de G(UPa), existe um t-uso global de t em (j, k) Arcout(j) e contm um sub-caminho livre de definio c.r.a t (tratada em [VIL98]) de i para outc e c.r.a t de nc(UPa) para j e a associao satisfeita se e somente se for exercitada atravs da mesma tupla . Uma associao-definio-t-uso interprocedimental de retorno representada pela sextupla: [UPa, <l, i>, UPb, (j, k), t, r]
70
iii)
Todos os dtu-caminhos interprocedimentais de chamada: requer que todos os dtu-caminhos (nl , ..., ni, ..., nc, ..., nj, nk) sejam satisfeitos, onde c uma chamada de uma unidade UPa para outra unidade UPb no n nc do G(UPa); t inc; onde defT<l,i> , l NS e i NS e so ns de G(UPa) que contm uma definio persistente de t; onde j NS em UPb, onde j fdsu(t, i) e contm um t-uso em (j, k), e existe um sub-caminho livre de definio persistente c.r.a. t de i para nc c.r.a. t de nin(UPb) para (j,k); o dtu-caminho satisfeito se for exercitado atravs da mesma tupla .
iv)
Todos os dtu-caminho interprocedimentais de retorno: requer que todos os dtu-caminhos (nl , ..., ni, ..., nr, ..., nj, nk) sejam satisfeitos, onde r o retorno da unidade UPb para UPa no n nr de G(UPb); t outr; defT<l,i> , l NS e i NS so ns de G(UPb) que contm uma definio persistente c.r.a. t; ; onde j NS em UPa onde j fdsu(t, i) e contm um t-uso em (j, k) e existe um sub-caminho livre de definio c.r.a t de i para outc e c.r.a t de nc(UPa) para (j,k); o dtu-caminho satisfeito se for exercitado atravs da mesma tupla .
As estruturas das unidades UPa e UPb (que chama e que chamada, respectivamente) tm uma ligao direta entre elas, com a existncia do comando de chamada. Os critrios aplicados ao teste de integrao so complementares aos do teste de unidade e visam a exercitar classes de erros distintas. Embora nem sempre seja possvel exercitar tais critrios dois a dois, pode-se estender os critrios de a a d para ciclos de chamadas indiretas (usando mais de uma UP para satisfazer a associao), contanto que se respeitem as propriedades de caminhos livres de definio e a mesma tupla seja usada na definio persistente de t e no uso de t, para satisfazer a associao. Os casos abordados nesta seo sero estudados com mais profundidade em trabalhos futuros, juntamente com o trabalho desenvolvido por Vilela [VIL98], no sendo, portanto, o principal enfoque desta tese.
71
A seguir so apresentados os critrios de teste de integrao baseados na dependncia de dados ocasionada pelas tabelas da base de dados, tendo em vista a persistncia das variveis tabela.
4.3.2.2 Critrios de teste de integrao baseados na dependncia de dados

O fluxo de dados ocasionado pelas variveis tabela considerado o mais importante em ABDR, tendo em vista a sua persistncia. A varivel tabela definida por uma unidade de programa mantm-se viva ao longo do tempo, determinando a existncia de uma associao def-t-uso entre duas UPs executadas em momentos distintos, sem a necessidade de um comando de chamada de uma para outra. Dizemos que uma associao def-t-uso existe, se uma varivel t definida em UPA tem um t-uso em UPB. Exemplo: Sejam duas unidades UPA e UPB pertencentes ao mesmo Mdulo Modi. Um dado colocado em uma tabela t pela unidade UPA pode ocasionar um resultado no esperado na unidade UPB (em outro momento de execuo), durante um uso de t; esse tipo de falha s observvel pela execuo seqenciada de UPA e UPB, exigida pelos critrios de integrao baseados em dependncia de dados . As associaes definio-t-uso de integrao so exercitadas com seqncias de execues para pares de unidades (UPd, unidade que define t; UPu, unidade que usa t). Neste caso, importante definir uma estratgia que exercite essas associaes utilizando os mesmos valores, tanto para a execuo de UPd como para a de UPu. Depois que todas as unidades de programa so associadas aos pares, para o exerccio das variveis persistentes, algumas associaes podem no ter sido exercitadas, devido dependncia de dados existente entre uma varivel tabela t e outra varivel tabela t. Neste caso, existe a necessidade de acrescentar uma unidade que define a varivel t exigindo-se um ciclo a mais de execuo para exercitar a associao referente varivel t.
Critrios baseados no fluxo de dados intra-modular

Estes critrios baseiam-se nas dependncias de dados existentes entre os procedimentos de um mesmo Mdulo de Programa com relao a uma varivel tabela da base de dados e requerem a mesma tupla para satisfazer a associao definio-t-uso. Cada unidade UPA que contm uma definio persistente da varivel t associada a outra 72
unidade UPB que contm um uso de t (t-uso); os pares (UPA, UPB) so requeridos pelo critrio com um ciclo de execuo (denomina-se de ciclo1) Considere que G(UPA) e G(UPB) sejam os grafos das unidades A e B, respectivamente, envolvidas na integrao e seja o conjunto dos caminhos completos em G(UPA) e G(UPB) e o conjunto de tuplas. (a, b) implica que existe a concatenao
a, b, onde a G(UPA) e b G(UPB).

Todas os t-usos-ciclo1-intra: e satisfazem o critrio (todos os t-usos-ciclo1intra) para o par de unidades UPA e UPB pertencentes ao mesmo mdulo se, para todos os pares de caminhos (a, b) , a inclui o par de ns <l,i> G(UPA) tal que defT<l,i>
c.r.a. t, e existir um caminho livre de definio c.r.a. t de <l, i> at nout de G(UPA); e b
inclui o arco (j, k) G(UPB) onde j fdsu(t,i) e existe um t-uso em (j, k), e existir um caminho livre de definio persistente c.r.a. t de nin at o arco (j, k); a associao satisfeita se for exercitada atravs da mesma tupla . Uma associao-t-uso-ciclo1-intra representada pela quntupla: [zUPA , <l, i>, zUPB , (j, k) , t] Todos os dtu-caminhos-intra: e satisfazem o critrio (todos os dtu-caminhosintra) para o par de unidades UPA e UPB pertencentes ao mesmo mdulo se, para todos os pares de caminhos (a, b) , a incluir um dtu-caminho do n l at o n nout de G(UPA) passando pelo par de ns <l, i> G(UPA) onde defT<l,i> c.r.a. t, atravs da tupla e b incluir um dtu-caminho c.r.a t do n nin de G(UPB) at o arco (j, k) G(UPB) sendo j fdsu(t,i) e existe um t-uso em (j, k), atravs da mesma tupla e existir um caminho livre de definio persistente que vai do par <l, i> em UPA at o arco (j, k) em UPB c.r.a t na composio dos caminhos a . b. O elemento requerido pelo critrio todos os dtu-caminhos-intra representado pela n-upla abaixo, sendo z o nmero do mdulo que contm as unidades A e B: [zUPA l a1 ... an i ... nout - zUPB nin ... j k] Onde zUPA a unidade onde ocorre a definio de t e l a1 ... an i ... nout o dtucaminho de <l , i> at o n de sada, podendo ou no passar por um sub-caminho (a1 ... 73
Captulo 4 Critrios de Teste: Definio e Anlise de Propriedades an) livre de lao; zUPB a unidade onde ocorre o uso de t e nin ... j k o dtu-caminho que vai do n inicial at o arco (j, k) onde existe um t-uso c.r.a. t. Existem dependncias que no podem ser exercitadas com a execuo de apenas duas unidades (uma de definio e outra de uso), mas necessitam da execuo de outra unidade para satisfazer a associao. Isso ocorre quando existem dependncias mltiplas, ou seja, para definir a varivel t necessrio estar definida a varivel t e, para isso, pode ser necessrio executarmos a unidade que define a varivel t para depois executarmos a unidade que define t e finalmente executarmos a UP que usa t. Observe que podem existir dependncias mltiplas exigindo mais de dois ciclos de execuo. A observao mais importante que mesmo executando trs unidades: UP1, UP2 e UP3, a associao de UP1 para UP3 ou UP2 para UP3. A unidade UP1 ou a unidade UP2 tem a definio persistente de uma varivel t que usada em UP3. Outro caso ocorre quando existem usos mltiplos em UP3 e para satisfaz-los temos que executar duas ou mais unidades para definir as variveis tabelas referenciadas em UP3, ocasionando associaes mltiplas (UP1, UP3) e (UP2, UP3) e que podem ser satisfeitas com o critrio de Ciclo2. Todos os t-usos-ciclo2-intra: e satisfazem o critrio (todos os t-usos-ciclo2intra) para as unidades UPA, UPB e UPC pertencem ao mesmo mdulo se, para todos os caminhos (a, b, c) , onde a o caminho que contm um par de ns <l,i> que define a varivel t pela tupla ; o caminho b contm um par de ns <l,i> que define t pela tupla podendo ou no ter uma dependncia de t, e o caminho c possuir um n que contm um uso de t e ou t pela mesma tupla e/ou , respectivamente, e o caminho a passar pelo par de ns <l,i> G(UPA) com defT<l,i> c.r.a. t; existir um caminho livre de definio c.r.a. t de i at nout de G(UPA); o caminho a passar pelo par de ns <l,i> G(UPB) onde defT<l,i> c.r.a. t; existir um caminho livre de definio c.r.a. t de i at nout de G(UPB); o caminho b passar pelo arco (j,k) G(UPC)/ existe um t-uso em (j,k) e j fdsu(t,i) (sendo t e/ou t) e existir um caminho livre de definio c.r.a. t e/ou t de nin at o arco (j,k). A associao [<l,i>, UPA, <l,i>, UPB, (j,k), UPC, {t, t}] satisfeita se e somente se a mesma tupla ( ) usada para satisfazer a definio de t ( t) tambm usada para satisfazer o uso.
74
Neste caso, os elementos requeridos so representados por uma stupla do tipo: [zUPA , <l, i>, zUPB, <l, i>, zUPC , (j, k) , {t, t}] Dois enfoques podem ser considerados: Utilizar as mesmas tuplas para satisfazer os pares definio-uso na integrao ou utilizar tuplas diferentes para satisfazer os elementos requeridos no cobertos com a mesma tupla. O primeiro enfoque mais conservador e mostrou, na execuo de um exemplo de aplicao, ser melhor para a deteco de defeitos do que o segundo.
4.4 Critrios de integrao inter-modular

Os critrios de integrao inter-modular so semelhantes aos critrios de integrao intra-modular com a diferena de que as unidades associadas devem pertencer a Mdulos de Programa distintos. Esses critrios visam a exercitar associaes de variveis tabela que so definidas em unidades de um Mdulo e so usadas em unidades de outro Mdulo . Neste caso, a associao definio-t-uso uma n-upla [Mod1UPA ,<l,i>, Mod2UPB , (j,k), t ] onde a definio persistente em <l,i> G(UPA)Mod1 c.r.a. t associada a um uso de t em (j, k) G(UPB)Mod2.
Critrios baseados no fluxo de dados inter-modular

Considere duas unidades UPA, pertencente a um mdulo Modx, e UPB, pertencente a outro mdulo Mody. Considere tambm os mesmos conjuntos e definidos anteriormente. Temos: Todos os t-usos-ciclo1-inter: Este critrio idntico ao critrio todos os t-usosciclo1-intra, com a nica diferena que as unidades UPA e UPB pertencem a Mdulos distintos. Neste caso o elemento requerido representado pela quntupla: [zUPA , <l, i>,wUPB , (j, k) , t] onde z representa o mdulo Modz e w representa Modw.
75
Todos os dtu-caminhos-inter: Este critrio idntico ao critrio todos os dtucaminhos-intra, com a nica diferena que a unidade onde existe uma definio persistente (UPA) pertence a um Mdulo e a unidade onde existe um t-uso pertence a outro Mdulo. Neste caso o elemento requerido representado pela quntupla: [zUPA l a1 ... an i ... nout - wUPB nin ... j k] onde z representa o mdulo Modz e w representa Modw. Todos os t-usos-ciclo2-inter: idntico ao critrio todos os t-usos-ciclo2-intra, com a diferena que as unidades associadas devem pertencer a Mdulos distintos. Neste caso, os elementos requeridos so representados por uma stupla do tipo: [zUPA , <l, i>, yUPB, <l, i>, wUPC , (j, k) , {t, t}]
4.5
Anlise de Propriedades
Estudos de propriedades e caractersticas de teste estrutural tm sido conduzidos em trabalhos anteriores [FRA88, MAL91, ZHU96] visando a comparar os diferentes critrios. Critrios incomparveis analiticamente podem ter suas foras relativas avaliadas empiricamente para determinar quais so os mais exigentes com relao ao nmero de casos de teste necessrios para satisfaz-los. Comparaes entre os critrios da FCPU e os critrios de teste de integrao baseados na dependncia de dados intra-modular foram realizadas com os exemplos de aplicao descritos resumidamente no Captulo 6; os exemplos so apresentados detalhadamente no Apndice C. A seguir apresentada uma anlise de incluso entre os critrios propostos neste trabalho. Na Seo 4.5.2, apresentado um estudo da complexidade dos critrios de teste propostos neste trabalho.
4.5.1 Anlise de incluso entre os critrios

O resultado da anlise de incluso de critrios uma ordem parcial entre esses critrios. Um critrio de teste C1 inclui um critrio de teste C2 se, para qualquer fluxo de controle G(UP) (qualquer Programa P), um conjunto de caminhos completos que seja
76
Captulo 4 Critrios de Teste: Definio e Anlise de Propriedades C1 adequado para P tambm C2-adequado para P; ou seja, se satisfaz C1 tambm satisfaz C2. Dizemos que um critrio C1 inclui estritamente um critrio C2 (C1 C2), se C1 inclui C2 e, para algum grafo G(UP), existe um conjunto de caminhos completos de G(UP) que satisfaz C2, mas no satisfaz C1. E dizemos que dois critrios so incomparveis quando nem C1 C2 e nem C2 C1. Um critrio de teste CBD um critrio que para ser satisfeito, exige um conjunto de caminhos completos de G(UP) e as mesmas tuplas utilizadas para exercit-los. Nesse caso, um critrio de teste C para software convencional no inclui um critrio CBD pois no necessrio a determinao de tuplas para satisfazer um critrio de teste C. Para simplificar as demonstraes adotou-se a notao TC, como sendo um conjunto de casos de teste; C um critrio de teste para programas convencionais (FPU e FCFD); CBD um critrio exclusivo para Banco de Dados; CBDint um critrio de teste de integrao (intra-modular e inter-modular); representa o conjunto de tuplas usadas na execuo dos casos de testes ao exercitar os critrios CBD e CBDint; TC so os casos de testes controlados por tuplas ; UPd (que define) e UPu (que usa) representam as unidades que definem uma varivel tabela e usam uma varivel tabela, respectivamente; t a varivel tabela; um conjunto de caminhos completos e; um caminho completo. Teorema 1: Os critrios da FCPU so incomparveis com os critrios todos os tusos e todos os dtu-caminhos. Prova: Os critrios todos os t-usos e todos os dtu-caminhos exercitam as variveis persistentes, existentes em programas de aplicao, no contempladas pelos critrios tradicionais. A Figura 4.4 mostra um exemplo que no permite comparar os critrios da FCPU com os critrios gerados especialmente para exercitar as variveis persistentes. i) (todos os potenciais-usos) (todos os t-usos) (todos os t-usos) (todos os potenciais-usos) A primeira condio verdadeira devido ao fato de que o critrio todos os t-usos requer a mesma tupla para exercitar a associao definio-t-uso c.r.a t e o critrio todos os potenciais-usos no. ii) A segunda condio verdadeira por existirem partes do programa que no envolvem ns de SQL e, sendo assim, o critrio todos os t-usos no requer nenhum 77
elemento requerido nessas partes, enquanto os critrios todos os potenciais-usos requerem vrias associaes potenciais usos. No exemplo da Figura 4.8 os caminhos (1, 10, 11, 13, 14) e (1, 10, 12, 13, 14) so requeridos para satisfazer o critrio todos os potenciais-usos e no so exigidos pelo critrio todos os t-usos por no existir nenhum comando de manipulao de dados da SQL, nesta parte do programa que caracterize uma definio persistente de qualquer varivel tabela. iii) As condies i) e ii) se estendem aos critrios todos os potenciais-du-caminhos e todos os dtu-caminhos, respectivamente. Teorema 2: O critrio todos os dtu-caminhos inclui parcialmente o critrio todos os t-usos. Na presena de caminhos no executveis eles so incomparveis. As Figuras 4.6 e 4.7 mostram as respectivas rvores de incluso relacionadas a estes critrios. Prova: Um conjunto de casos de testes TC CBD adequado para P se existir um caminho executvel que vai de um ponto do programa onde ocorre uma definio persistente c.r.a. t at um ponto do programa onde h um uso de t. O que preciso provar, neste caso, que mesmo na presena de laos entre o par de ns <l, i> onde ocorre a definio persistente at o arco (j, k) onde existe um uso de t em j, o critrio todos os dtucaminho cobre parcialmente o critrio todos os t-usos. i) Suponha que o caminho completo (I, ..., n1, n2, ..., l, ..., i, ..., nl, ...,nl, ns, ..., j, k, ..., F) satisfaz o critrio todos os t-usos. Se existir um caminho executvel que no entra no lao a partir de l (I, ..., n1, n2, .. , l, ..., i, ..., nl, ns, ..., j, k, ..., F), que satisfaz o critrio todos os dtu-caminhos, este caminho tambm ir satisfazer o critrio todos os t-usos. Isto s verdadeiro quando todos os caminhos so executveis. ii) No caso de existir mais de um caminho entre o ponto onde ocorreu a definio persistente <l, i> at o arco (j, k), o critrio todos os dtu-caminhos requerem todos os caminhos usados para satisfazer o critrio todos os t-usos, alm de outros caminhos entre <l, i> at o arco (j,k) ainda no executados. A Figura 4.5 mostra uma situao semelhante a esta. iii) Os critrios de teste da FCPU exigem que as associaes potenciais usos das variveis que so definidas nos ns 1, 10, 11 e 12 sejam exercitadas pelo menos uma vez, enquanto o critrio todos os t-usos (usado para exercitar as variveis tabela), no 78
requer nenhuma associao relacionada a esses ns, uma vez que requer apenas associaes de variveis persistentes (que no caso de variveis tabela so definidas e usadas apenas em ns da SQL). Por outro lado, o critrio de teste todos os t-usos incomparvel ao critrio todos os potenciais-usos, conforme mostra o exemplo da Figura 4.4, quando existem partes da estrutura (ns 10, 11, 12 e 13) do programa que so tratadas pelo critrio Todos os Potenciais Usos e que no so tratadas pelo critrio de teste todos os t-usos devido ausncia de comandos da SQL que contm comandos de manipulao. Em qualquer unidade de programa UPd onde h uma definio persistente de t e que possua um caminho livre de definio persistente do par de ns <l, i> at o n de sada nout(UPd), existe uma associao definio-t-uso com outra UPu com t-uso e onde existe um caminho livre de definio persistente c.r.a. t do n nin(UPu) at o arco (j, k) onde ocorre o t-uso. Em qualquer par de unidades de programa UPd e UPu que caracterizam uma ou mais associaes persistentes c.r.a. t, existe um conjunto de casos de testes TC que CBDint adequado para UPD e UPU onde CBDint representa os critrios de testes todos os t-usos-intra e todos os dtu-caminhos-intra, se ambas as unidades pertencem ao mesmo Mdulo ou representa os critrios todos os t-usos-inter e todos os dtu-caminhos-inter, se ambas as unidades so de Mdulos distintos.
79
Check(connect);
1
connect=0 Connect<>0
2 f =1 read(h); 3
read(f); 10 f =2 5 f >2 read(h);

cod1000 read(cid); cod>1000
s=cod/6; 11
12
s:= cod/12;
4
INSERT
6
INSERT
t1 t1 7
COMMIT
t2 t2
13
write(s);
8
h:=append(h);
14
all-potential-uses={(1,2,3,4,7,8,2,3,4,7,8,2,9,14), (1,2,3,4,7,8,2,5,6,7,8,2,9,14), (1,2,3,4,8,2,3,4,7,8,2,9,14), (1,2,3,4,8,2,5,6,7,8,2,9,14), (1,2,5,6,7,8,2,3,4,7,8,2,9,14), (1,2,5,6,7,8,2,5,6,7,8,2,9,14), (1,2,5,6,8,2,3,4,7,8,2,9,14), (1,2,5,6,8,2,5,6,7,8,2,9,14),(1,10,11,13,14),(1,10,12,13,14) } No requer a mesma tupla. all-potential-du-path=all-potential-uses {(1,2,9,14)} all-t-uses=all-dtu-paths= { (1,2,3,4,7,8,2,3,4,7,8,2,9,14),(1,2,3,4,7,8,2,5,6,7,8,2,9,14), (1,2,3,4,7,2,3,4,8,2,9,14), (1,2,3,4,7,2,5,6,8,2,9,14), (1,2,5,6,7,8,2,3,4,7,8,2,9,14),(1,2,5,6,7,8,2,5,6,7,8,2,9,14), (1,2,5,6,7,2,3,4,8,2,9,14), (1,2,5,6,7,2,5,6,8,2,9,14)} cada definio e uso na mesma tupla .
Figura 4.4 Exemplo 1 para anlise de Incluso.
80
read(op)
2 op=i op=d 3 read(h) 4 I 5 read(h) 6 t U cod ! error ! error 9 C 10 cod < 0 11 op=u 7 read(h) 8 S ! error error error h cod 0 12 PRINT(h); t t cod 15 op=f 14
all-potential-t-uses: {(1,2,3,4,9,10,12,13,2,3,4,9,10,12,13,2,14,15), (1,2,3,4,9,10,12,13,2,3,4,10,11,13,2,14,15), (1,2,3,4,9,10,12,13,2,5,6,9,10,12,13,2,14,15), (1,2,3,4,9,10,12,13,2,5,6,10,11,13,2,14,15), (1,2,3,4,9,10,12,13,2,7,8,9,10,12,13,2,14,15), (1,2,3,4,9,10,12,13,2,7,8,10,11,13,2,14,15),
PRINT(
(1,2,5,6,9,10,12,13,2,3,4,9,10,12,13,2,14,15), (1,2,5,6,9,10,12,13,2,3,4,10,11,13,2,14,15), (1,2,5,6,9,10,12,13,2,5,6,9,10,12,13,2,14,15), (1,2,5,6,9,10,12,13,2,5,6,10,11,13,2,14,15), (1,2,5,6,9,10,12,13,2,7,8,9,10,12,13,2,14,15), (1,2,5,6,9,10,12,13,2,7,8,10,11,13,2,14,15), (1,2,7,8,9,10,12,13,2,3,4,9,10,12,13,2,14,15), (1,2,7,8,9,10,12,13,2,3,4,10,11,13,2,14,15), (1,2,7,8,9,10,12,13,2,5,6,9,10,12,13,2,14,15), (1,2,7,8,9,10,12,13,2,5,6,10,11,13,2,14,15), (1,2,7,8,9,10,12,13,2,7,8,9,10,12,13,2,14,15), (1,2,7,8,9,10,12,13,2,7,8,10,11,13,2,14,15)} all-potential-dtu-paths=all-potential-t-uses {(1,2,3,4,9,10,11,13,2,3,4,9,10,12,13,2,14,15), (1,2,3,4,9,10,11,13,2,3,4,10,11,13,2,14,15), (1,2,3,4,9,10,11,13,2,5,6,9,10,12,13,2,14,15), (1,2,3,4,9,10,11,13,2,5,6,10,11,13,2,14,15), (1,2,3,4,9,10,11,13,2,7,8,9,10,12,13,2,14,15), (1,2,3,4,9,10,11,13,2,7,8,10,11,13,2,14,15), (1,2,5,6,9,10,11,13,2,3,4,9,10,12,13,2,14,15), (1,2,5,6,9,10,11,13,2,3,4,10,11,13,2,14,15), (1,2,5,6,9,10,11,13,2,5,6,9,10,12,13,2,14,15), (1,2,5,6,9,10,11,13,2,5,6,10,11,13,2,14,15), (1,2,5,6,9,10,11,13,2,7,8,9,10,12,13,2,14,15), (1,2,5,6,9,10,11,13,2,7,8,10,11,13,2,14,15), (1,2,7,8,9,10,11,13,2,3,4,9,10,12,13,2,14,15), (1,2,7,8,9,10,11,13,2,3,4,10,11,13,2,14,15), (1,2,7,8,9,10,11,13,2,5,6,9,10,12,13,2,14,15), (1,2,7,8,9,10,11,13,2,5,6,10,11,13,2,14,15), (1,2,7,8,9,10,11,13,2,7,8,9,10,12,13,2,14,15), (1,2,7,8,9,10,11,13,2,7,8,10,11,13,2,14,15)} Requer que a mesma tupla seja usada na definio e no uso c.r.a. t
t t cod error
t t+
13
read(op) cod
Figura 4.5 Exemplo 2 para anlise de incluso. OBS: Os ns 4, 6 e 8 possuem respectivamente as letras I, U e S para representar os comandos Insere, Update e Select da SQL.
81
Teorema-3: O critrio de integrao todos os dtu-caminhos-intra (dtu-caminhosinter) inclui parcialmente o critrio todos os t-usos-intra (todos os t-usos-inter). Na presena de caminhos no executveis eles so incomparveis. A Figura 4.8 mostra a rvore de incluso relacionada a estes critrios.
Todos-Caminhos
Todos os dtu-caminhos
Todos os t-usos Figura 4.6 - rvore de incluso parcial dos critrios de teste de unidade de ABDR Todos-Caminhos*
Todos os dtu-caminhos *
Todos os t-usos *
Figura 4.7 rvore de incluso dos critrios de teste de unidade de ABDR para caminhos executveis
Prova: Um conjunto de casos de testes controlados pela mesma tupla (TC) CBDint adequado para UPd UPu se existe um caminho executvel que vai do par de ns <l, i> da unidade UPD onde ocorre a definio persistente c.r.a. t, at o n final (em UPd ) e existe um ou mais caminhos executveis que vai do n de entrada nin(UPu) at o arco (j, k) onde ocorre um t-uso. O que preciso provar que, mesmo na presena de laos entre o par de ns <l, i> onde ocorre a definio persistente em UPd at o arco onde ocorre um t-uso em UPu (arco (j, k)) o critrio todos os dtu-caminhos cobre parcialmente o critrio todos os tusos (de integrao). Assim como os resultados obtidos no Teorema 2, na associao, o que altera apenas a concatenao dos caminhos d e u resultantes da execuo das unidades UPd e UPu. i) Suponha que os pares de caminhos (...,l, ..., i, ...,nl, nl+1, ...,nl, ns, ..., nout)d (nin, ..., j, k)u ou (...,l, ..., i, ..., nout)d (nin, ..., nl, nl+1, ...,nl, ns, ..., j, k)u satisfazem o
82
critrio todos os t-usos-intra (todos os t-usos-inter) eles satisfazem o critrio todos os dtu-caminhos-intra (todos os dtu-caminhos-inter) se existe um caminho executvel que no pertena ao lao. Neste caso, este caminho tambm satisfaz o critrio todos os tusos-intra (todos os t-usos-inter). Portanto, o critrio todos os dtu-caminhos-intra (todos os dtu-caminhos-inter) cobre parcialmente o critrio todos os t-usos-intra (todos os t-usos-inter). ii) A Figura 4.8 mostra um caso onde o critrio todos os dtu-caminhos-intra (todos os dtu-caminhos-inter) cobre o critrio todos os t-usos-intra (todos os t-usos-inter), mas o critrio todos os t-usos-intra (todos os t-usos-inter) no cobre o critrio todos os dtucaminhos-intra (todos os dtu-caminhos-inter).
1 UPA UPB (A B) todos t-usos intra ou inter)={(A, 1, 2, 3, 4, 5, 7, B, 1, 2, 4, 5, 6), (A, 1, 2, 3, 4, 5, 7, B, 1, 2, 4, 5, 6)} (A B)todos-dtu-caminhos) = (A B)todos os t-usos intra ou inter) ={(A, 1, 2, 3, 4, 5, 7, B, 1, 3, 4, 5, 6), (A, 1, 2, 3, 4, 5, 7, B, 1, 3, 4, 5, 6), (A, 1, 2, 3, 4, 6, 7, B, 1, 2, 4, 5, 6), (A, 1, 2, 3, 4, 6, 7, B, 1, 2, 4, 5, 6), (A, 1, 2, 3, 4, 6, 7, B, 1, 3, 4, 5, 6), (A, 1, 2, 3, 4, 6, 7, B, 1, 3, 4, 5, 6)}.
1 #i 1 2 3 4 5 6 7 8 n A C E D T W C B s S S J S J S S J p 4 3 6 4 5 6 7 3 2 4
2 t
3 4
5 7
6 7
Figura 4.8 Exemplo para anlise de incluso dos critrios (todos os tusos-intra ou inter)x(todos os dtu-caminhos-intra ou inter)
Tendo em vista que os critrios todos os t-usos-intra e os critrios todos os dtucaminhos-intra exigem que as associaes sejam exercitadas com a mesma tupla da base de dados e que o critrio da FCPU no possui a mesma exigncia, foram observados no caso i) apenas os caminhos percorridos; caso contrrio, os casos de testes gerados no teste de unidade com relao aos critrios todos os t-usos no seriam satisfeitos.
83

Todos os caminhos-intra (todos os caminhos-inter)
Todos os dtu-caminhos-intra (todos os dtu-caminhos-inter)
Todos os t-usos-intra (todos os t-usos-inter)

Figura 4.9 Arvore de incluso dos critrios de integrao. O critrio todos os dtu-caminhos (intra ou inter) inclui parcialmente o critrio todos os t-usos ( intra ou inter)
4.5.2 Anlise de Complexidade

A complexidade de um critrio C definida como o nmero de casos de teste requeridos pelo critrio no pior caso, para exercitar todos os elementos requeridos pelo critrio de teste. Dado um Mdulo de Programa Modi, existe um conjunto de casos de teste TC tal que a cardinalidade de TC menor ou igual complexidade do critrio C. Deve-se considerar a distribuio de ocorrncia de variveis em qualquer grafo de fluxo de controle de uma Unidade de Programa G(UP). Os critrios da FCPU foram analisados em [MAL91]; os resultados mostram que todos os critrios baseados em fluxo de dados tm complexidade de ordem exponencial e, portanto, do ponto de vista terico, estes critrios no seriam aplicveis na prtica. No entanto, estudos empricos tm demonstrado que, para programas reais, esses critrios demandam um pequeno nmero de casos de teste. A complexidade de um critrio um fator importante para as atividades de teste, principalmente na estimativa e determinao de custos associados a essas atividades. As anlises so sempre focadas nos piores casos, embora na prtica seja muito improvvel sua ocorrncia. No caso dos critrios de testes para programas de ABDR, apresentou-se alguns grafos de fluxo que ilustram a complexidade dos critrios de teste todas as associaesdefinio-t-usos e todos os dtu-caminhos para a mesma tupla de t. A complexidade de um critrio analisada a partir de uma estrutura de fluxo de controle, considerando o fluxo de dados que maximiza o nmero de elementos requeridos pelo critrio. O grafo de fluxo de controle apresentado na Figura 4.10 maximiza o nmero 84
de operaes da SQL para cada tabela, aumentando o nmero de associaes definio-tusos requeridas. Considere que temos n tabelas e um comando requer 3*4 associaes para cada tabela, resultando em n*3*4 elementos requeridos pelos critrios todos os t-usos e todos os dtu-caminhos (onde 3 representa o nmero de comandos da SQL que geram uma definio de t e 4 representa o nmero de comandos que usam as variveis t). Para cada definio de t os critrios todos os dtu-caminhos e todos os t-usos associam apenas os ns que realmente possuem um uso de t e no requerem associaes nos ns onde a varivel tabela t no estiver sendo relacionada. Em exemplos de [MAL91], programas com estruturas de controle consistindo de seqncias de comandos IF-THEN-ELSE requerem 2k casos de teste. No caso de programas de aplicao possvel aplicar comandos de SQL em comandos IF-THEN-ELSE exigindo um nmero bem acentuado de elementos requeridos para satisfazer os critrios todos os dtu-caminhos e todos os t-usos, de modo a requerer 2k casos de testes para satisfazer esses critrios, sendo k o nmero de comandos de deciso na UP.
t1
t2
t3
t4
fim
Figura 4.10: Grafo de fluxo de controle que maximiza o nmero de combinaes do critrio todos os t-usos.
A Figura 4.11 mostra uma UP que possui k comandos de deciso e que maximiza o nmero de casos de teste para satisfazer os critrios de teste estrutural para programas de ABDR. Os critrios de teste de integrao todos os t-usos (intra-modular e inter-modular) extraem seus elementos requeridos das possveis combinaes existentes entre os comandos 85
da SQL (de manipulao da base de dados) c.r.a varivel tabela. Sendo assim, existe um fator relevante que se reflete diretamente na complexidade do critrio; este fator est relacionado quantidade de tabelas envolvidas na Aplicao. Geralmente, quanto mais tabelas existirem maior ser o nmero de comandos de manipulao da SQL que contribuem diretamente com o acrscimo da quantidade de elementos requeridos em cada critrio de integrao. A complexidade do critrio todos os t-usos, a partir desse tipo de estrutura, dada pela soma de todas as combinaes possveis que vo de uma definio at um t-uso, alcanado por um caminho livre de definio persistente e livre de lao. Neste caso a complexidade dada pela equao: [n*4*2]*m sendo m o nmero de tabelas associadas em cada opo; n o nmero de comandos que possuem uma definio de t (no pior caso, foram considerados os trs comandos juntos); 4 representa o nmero de distintos comandos executveis da SQL que possuem um uso de t e 2 representa o uso nos arcos de sada dos ns da SQL (no pior caso) que contm um t-uso. Ao invs de exigir-se uma potencial associao como ocorre nos critrios FCPU, foi exigido apenas a associao definio-t-uso entre os comandos que usam a mesma varivel tabela, evitando-se uma exploso de elementos requeridos no executveis (devido exigncia de executar a associao com a mesma tupla). Na estrutura apresentada na Figura 4.11, para cada n que contm um comando ifthen-else existe uma entrada de dados que decide a execuo dos laos then ou else do comando if. Em cada lao then e else colocada uma estrutura que define e usa uma ou mais tabelas diferentes ou, no pior caso, todas as tabelas usando a estrutura case mostrada na Figura 4.11; com essa combinao de estruturas, temos o maior nmero de elementos requeridos pelo critrio de teste todos os t-usos, [(3*4*2)*m*2k], onde m o nmero de tabelas envolvidas na estrutura do programa e k o nmero de comandos if-then-else. A complexidade deste critrio de ordem exponencial em relao ao nmero de caminhos de deciso como os demais critrios da FCPU [MAL91].
86
read t1
2a+2
read t2
4a+2
read t3
. . .
(k-1)2a+2 read t k
2ka+2
2ka+3
2ka+4
Figura 4.11: Grafo de fluxo de controle com estrutura que maximiza o critrio todos os t-usos, onde a o nmero de ns em cada estrutura e k o nmero de comandos if-then-else.
87
O mesmo ocorre para os critrios de teste de integrao intra-modular e intermodular que, apesar de serem associados a duas unidades de cada vez e terem algumas diferenas em relao aos critrios de teste de unidades estudados em [MAL88 e MAL91], tm estruturas de grafo de programa com nmeros de casos de teste que alcanam a ordem exponencial no pior caso. Assim, os critrios todos os t-usos-intra (todos os t-usos-inter) e todos os dtu-caminhos-intra (todos os dtu-caminhos-inter) tambm tm complexidade de ordem O(2k), onde k representa o nmero de comandos de deciso que exigem uma entrada de dados nas unidade de programa onde ocorre a definio, UPD, e o uso de t, UPU. A partir dessas UPs so formadas as possveis combinaes de pares definio-uso persistentes c.r.a. t; na prtica, o nmero de combinaes pode no ser de ordem exponencial, tornandose assim vivel no caso geral. No caso de ABDR, tratando-se de associaes que relacionam apenas ns de SQL com a mesma varivel tabela t e que sejam alcanveis por um caminho livre de definio c.r.a. t, acredita-se que o nmero de combinaes no atinja ordem exponencial. Um estudo mais detalhado pode ser realizado em trabalhos futuros visando a estudar outros fatores que podem elevar a ordem de complexidade dos critrios de teste estrutural de programas de ABDR; por exemplo, a quantidade de tabelas envolvidas, o nmero de Mdulos existentes, entre outros, que afetam diretamente a gerao dos elementos requeridos dos critrios propostos neste trabalho.

Neste captulo foi apresentada a definio dos critrios de teste estrutural para programas de aplicao para o teste de unidade e teste de integrao intra-modular e integrao inter-modular que requerem a mesma tupla para satisfazer a associao definio-uso c.r.a. t. Uma caracterstica marcante desses critrios a abordagem de integrao entre duas unidades de programas sem a existncia de um comando de chamada entre elas. Foi apresentada uma anlise de incluso entre os critrios de teste propostos. Tendo em vista que esses critrios exercitam as variveis tabela, a anlise foi feita apenas para os trechos de programas cujo caminho inclui algum n da SQL, atendendo ao objetivo
88
proposto inicialmente (que era o de complementar os critrios de teste estrutural de programas convencionais). Em relao anlise de complexidade foi mostrado que todos os critrios de teste baseados em fluxo de dados tm complexidade de ordem exponencial e, do ponto de vista terico, estes critrios no seriam aplicveis na prtica; entretanto, estudos empricos podem mostrar que esses critrios demandam um pequeno nmero de casos de teste. Para os programas de aplicao, maximizar o nmero de comandos de SQL pode maximizar o nmero de associaes definio t-uso c.r.a. t, aumentando assim a complexidade; na prtica, isso no comum ocorrer. A anlise de complexidade dos critrios envolvidos na etapa de integrao deve ser reavaliada em trabalhos futuros buscando, assim, uma estimativa mais adequada para os casos reais; embora o pior caso seja exponencial, no caso de programas de ABDR no so apenas os comandos de deciso que contribuem com esta ordem de grandeza, mas tambm o nmero de variveis tabela envolvido no relacionamento entre as unidades de um ou mais mdulos da aplicao. Esse estudo tem a importncia de mostrar que apesar da ordem exponencial dos critrios de testes, na prtica vivel a sua utilizao. Isso pode ser mostrado atravs de experimentos.
89
90
5 Os Modelos de Implementao dos Critrios de Teste

Neste captulo so abordados vrios aspectos relacionados ao projeto da ferramenta de suporte aplicao dos Critrios de Teste em ABDR. Na Seo 5.2 descrito o modelo de fluxo de controle; na Seo 5.3 so descritos os modelos de instrumentao; na Seo 5.4 so descritos os modelos de fluxo de dados; e na Seo 5.5 discute-se a descrio dos elementos requeridos.
5.1 Consideraes Iniciais

Uma proposta de modificao da ferramenta POKE-TOOL apresentada, visando incluso dos critrios de integrao propostos neste trabalho. A aplicao de um critrio de teste estrutural envolve a anlise de cobertura para avaliar o grau de satisfao do critrio, obtida pela execuo dos casos de teste. A anlise de cobertura feita atravs da instrumentao de cada unidade do programa em teste, pela monitorao dos caminhos executados pelo conjunto de casos de teste e pela determinao dos elementos requeridos executados e no executados. Para os critrios especficos para banco de dados, a cobertura analisada a partir dos caminhos percorridos e das tuplas que exercitam as associaes definio-t-uso. Para isso, necessita-se incluir pontas de provas que identifiquem o nmero da Unidade de Programa em teste e das tuplas que foram utilizadas para exercitar as unidades de programa envolvidas no teste. Essa instrumentao utilizada para avaliar a cobertura dos critrios baseados na dependncia de dados entre as variveis persistentes (nas etapas de teste intra-modular). Neste captulo so apresentados os modelos propostos para a implementao de uma ferramenta de apoio ao teste de programas de ABDR. No modelo de fluxo de controle apresentou-se os comandos da SQL que ocasionam fluxos distintos de controle e tambm apresentou-se uma extenso da Linguagem Intermediria (LI) para os comandos SQL. A LI uma linguagem utilizada na ferramenta POKE-TOOL para torn-la multi-linguagem, ou seja, parte do processamento da ferramenta feito sobre a LI e parte sobre a linguagem do programa testado [CHA91]. A POKE-TOOL possui caractersticas que permitem a incorporao de novos critrios de teste estrutural englobando os quatro modelos: Fluxo de Controle, 91
Captulo 5 Os Modelos de Implementao dos Critrios de Teste
Instrumentao, Fluxo de dados e Descrio dos Elementos Requeridos [MAL91]. Os modelos bsicos necessrios para os nossos critrios: O Modelo de Grafo de Fluxo de Controle; O Modelo de Instrumentao; O Modelo de Dados; e O Modelo de Descrio dos Elementos Requeridos, so discutidos a seguir.
5.2 O Modelo de Fluxo de Controle

No modelo de fluxo de controle adotado, um programa P representado por um grafo dirigido G(UP) = (NBD, E, nin, nout), definido no Captulo 3 como grafo de fluxo de controle ou grafo de programa. Cabe lembrar que os ns de Nh representam blocos de comandos da linguagem hospedeira e que os comandos declarativos da SQL so colocados juntos com esses blocos de comandos. Os comandos executveis da SQL so representados pelos ns NS e so colocados um em cada n. Maldonado [MAL91] apresenta as construes bsicas dos comandos da linguagem LI. Diferentemente, na SQL o fluxo de controle dos comandos executveis definido pelo comando declarativo WHENEVER <condio> <ao>, no qual pode-se especificar uma ao a ser tomada quando for detectada uma condio de error, uma condio de warning ou uma condio de not found em um comando executvel da SQL. As aes incluem condies de: parada (stop), continuao (continue), desvio condicional (goto <rtulo>) ou execuo de uma funo (do <function>). Os SGBDs utilizam esses comandos para tratamento de erros nos comandos executveis da SQL; assim sendo, o comando declarativo WHENEVER deve anteceder os comandos executveis da SQL. importante observar que o comando WHENEVER tem sua ao controlada de cima para baixo com relao s linhas de comandos do programa fonte; assim, o esquecimento de um comando declarativo antes de um comando executvel da SQL pode causar um erro de fluxo. A Figura 5.1 apresenta a construo bsica do grafo de fluxo de controle para o comando WHENEVER. A linguagem LI representa os comandos executveis da linguagem SQL. Um grafo de programa de uma ABDR formado pela simples concatenao das construes bsicas apresentadas em [MAL91] para os comandos da linguagem hospedeira e das construes bsicas dos comandos executveis da linguagem SQL. Observe que o modelo de fluxo de
92
controle importante para refletir os aspectos semnticos da LI e para a instrumentao das unidades em teste. As condies podem ser SQLWARNING, SQLERROR ou NOT FOUND sendo que cada tipo de condio pode gerar informaes de controle nos comandos executveis da SQL durante a execuo. Essas informaes so passadas para as variveis correspondentes, que compem a rea de comunicao da SQL (SQLCA). Conforme mostrado na Figura 5.1, existem quatro tipos de aes que determinam o fluxo de controle aps cada comando executvel da SQL: CONTINUE, STOP, GOTO <rtulo> e DO <funo>. A ao CONTINUE faz com que o fluxo passe para o prximo comando do programa independentemente do resultado obtido na condio adotada, conforme mostra a Figura 5.2. A ao STOP faz com que o fluxo de controle aps o comando executvel da SQL tenha dois arcos, um apontando para o prximo comando do programa indicando que a condio no foi satisfeita (FALSE) e outro para o final do programa, caso a condio tenha sido satisfeita (TRUE), mostrado na Figura 5.2. A ao GOTO <rtulo> faz com que existam dois fluxos diferentes aps o comando executvel da SQL sendo um para o prximo comando do programa, caso a condio no tenha sido satisfeita (FALSE) e o outro para o ponto do programa onde o rtulo foi colocado, veja a Figura 5.2. A ao DO <funo> faz com que o fluxo de controle aps um comando executvel da SQL, tenha um
Comando declarativo WHENEVER >> EXEC SQL WHENEVER NOT FOUND SQLERROR SQLWARNING > WHENEVER os comandos declarativos da SQL so colocados juntos com os blocos de comandos da linguagem hospedeira associados a um nico n.
>------- CONTINUE -------------------------;-------------------->< GOTO label_name STOP DO function
EXEC SQL WHENEVER <condition> <action>

<WHENEVER>::=<whenever_atm> <cond_atm> <act_atm> <whenever_atm>::= $WHENEVER <cond_atm>::=$SQLERROR | $SQLWARNING | $NOT_FOUND <act_atm>::= $CONTINUE | $GOTO | $STOP | $DO
Figura 5.1 Modelo de fluxo de controle e instrumentao associado aos comandos da SQL: comando declarativo de controle de erros WHENEVER
93
arco para um comando de chamada da funo, caso a condio tenha sido satisfeita (TRUE), ou para o prximo comando, caso a condio no tenha sido satisfeita (FALSE),
DO <funo> k representa um subgrafo que antecede o comando executvel SELECT. Seja s um n que contm um comando declarativo da SQL cuja ao DO <FUNC>. Instrumentao: Antes do n i (que contm um comando executvel da SQL) inserida uma ponta de prova i; seja j o n de entrada do subgrafo l, inserida uma ponta de prova j no incio do subgrafo l; e seja r o n que contm o comando de chamada da funo FUNC colocada na ao DO, colocada uma ponta de prova r no incio deste n. k GOTO <label> k representa um subgrafo que antecede o comando executvel da SQL. Seja s um n que contm um comando declarativo da SQL cuja ao GOTO <label>. Instrumentao: Antes do n i (que contm um comando executvel da SQL) inserida uma ponta de prova i; seja j o n de entrada do subgrafo l, inserida uma ponta de prova j no incio do subgrafo l, e seja r o n que contm o rtulo da ao GOTO, colocada uma ponta de prova r no incio deste n. k STOP
k representa um subgrafo que antecede o comando executvel da SQL. Seja s um n que contm um comando declarativo da SQL cuja ao STOP. Instrumentao: Antes do n i inserido a ponta de prova i; Seja j o n de entrada do subgrafo l, inserida uma ponta de prova j no incio do subgrafo l e inserida uma ponta de prova f no incio do n final.
CONTINUE k representa um subgrafo que antecede o comando executvel da SQL. Seja s um n que contm um comando declarativo da SQL cuja ao seja CONTINUE. Instrumentao: Antes do n i inserida a ponta de prova i; Seja j o n de entrada do subgrafo l, inserida a ponta de prova j no incio do n j. k
INSERT DELETE UPDATE SELET
INSERT DELETE UPDATE SELET
i r
l
INSERT DELETE UPDATE SELECT
INSERT DELETE UPDATE SELECT
i
l l
r f
Figura 5.2: O modelo de fluxo de controle para os comandos executveis da SQL gerado pela ao do comando declarativo WHENEVER. Na descrio apresentado o Modelo de instrumentao referente a cada ao nos comandos executveis da SQL.
mostrada na Figura 5.2. As aes utilizadas nos comandos declarativos de tratamento de erros que determinam as regras de fluxo de controle a partir dos comandos executveis da SQL e os comandos de desvios condicionais e incondicionais apresentados em [MAL91] introduzem grandes modificaes no fluxo de controle e, conseqentemente, no modelo de instrumentao de uma ABDR mostrada na Figura 5.2. Para cada n da SQL executvel 94
coloca-se uma ponta_de_prova (uma informao do nmero do n) antes do n da SQL, marcando o nmero do n da SQL (vlido para todos ns da SQL) e, para cada ao existe um arco de sada do n da SQL para representar a respectiva ao. Para a ao GOTO <rtulo> existe um arco que liga o n da SQL ao prximo n (ou bloco) (para representar a condio = false) e outro arco para o n (bloco) que contm o rtulo associado ltima ao GOTO (para representar a condio = true) (Figura 5.2). Da mesma forma, para a ao STOP existe um arco saindo do n da SQL que contm um comando executvel da DML, para o ltimo n (bloco) do programa e o outro para o prximo bloco do programa (prximo n) (mostrado pela Figura 5.2). Para a ao CONTINUE existe apenas um arco de sada do n da SQL, que contm um comando executvel da DML, para o prximo n (bloco) (mostrado pela Figura 5.2). Para a ltima ao DO <funo> adotada a mesma estratgia do comando IF_THEN onde, no bloco THEN existe uma chamada de funo (a funo colocada na ao DO <funo>) e a colocada uma ponta_de_prova marcando o nmero deste n e, caso a condio no seja satisfeita, h um arco para o prximo comando na seqncia do programa aps o comando SQL onde existe uma ponta_de_prova no incio do bloco. Neste caso, alm da ponta_de_prova colocada antes do n, colocada outra ponta_de_prova do prximo nmero do n executvel dentro da funo usada na ao e outra ponta_de_prova logo aps o n da SQL para marcar o bloco (caso seja um if_then) (mostrado pela Figura 5.2). As Figuras 5.3 a 5.6 mostram a sintaxe parcial dos comandos executveis da DML, o comando INSERT na Figura 5.3, o comando DELETE na Figura 5.4, o comando UPDATE na Figura 5.5 e o comando SELECT na Figura 5.6. A proposta aqui apresentada para a instrumentao foi feita manualmente para exercitar o exemplo de aplicao que mostrado no prximo captulo. Como trabalho futuro pretende-se transformar a instrumentao uma operao automatizada e segura quanto ao acrscimo das informaes.
95
Comando Executvel INSERT >> > EXEC SQL AT db_name INSERT INTO table_name > FOR host_integer > , ( column_name ) ) ; >
, > VALUES ( subquery value
>
:host_variable expression literal :indicator
>>
EXEC SQL INSERT INTO <tabela> [<atributos>] VALUES <val_em_ordem_atributos>;

<INSERT>::=<ins_atm><tab_atm> [{<atr_atm>}]<values_atm> {<val_atm>} <ins_atm>::=$INSERT <tab_atm>::=$T(n)n <atr_atm>::=$Sn <values_atm>::=$VALUES <val_atm>::=$Vn
Figura 5.3 Sintaxe parcial e LI para o comando INSERT.
96
Comando Executvel DELETE >> > EXEC SQL AT db_name DELETE FROM table_name FOR :host_integer > alias > WHERE search_condition
CURRENT OF
>
><
cursor_name
EXEC SQL DELETE FROM <tabela> WHERE [<search_condition>]/ [CURRENT OF <cursor_name>]
<DELETE>::= <del_from_atm><tab_atm> <where_atm> [<cond_atm>/<cur_atm>] <del_from_atm>::= $DELETE <tab_atm>::= $T(n)n <where_atm>::= $WHERE <cond_atm>::= $C(n)n <current_atm>::= $CURRENT <cur_atm>::= $P
Figura 5.4 Sintaxe parcial e LI para o comando DELETE..
97
Comando Executvel UPDATE >> > EXEC SQL UPDATE AT db_name table_name FOR :host_integer > alias , > SET ( column_name , column_name > WHERE search_condition
CURRENT OF
>
) =
, value ( subquery )
>
value ; ><
cursor_name
EXEC SQL UPDATE <tabela> SET {<column_name> = :<var_host>} WHERE [<search_condition>]/ [CURRENT OF <cursor_name>] <UPDATE>::=<up_ atm><tab_atm> <set_atm> {<stat_atm>} <where_atm> [<cond_atm>/<cur_atm>] <up_atm>::=$UPDATE <tab_atm>::=$T(n)n <set_atm>::=$SET <stat_atm>::=$Sn <where_atm>::=$WHERE <cond_atm>::=$C(n)n <current_atm>::=$CURRENT <cur_atm>::=$P Figura 5.5 Sintaxe parcial e LI para o comando UPDATE.
98
Comando Executvel SELECT >> > EXEC SQL SELECT AT db_name table_name FOR :host_integer > alias , > SET ( column_name , column_name > WHERE search_condition
CURRENT OF
>
) =
, value ( subquery )
>
value ; ><
cursor_name
EXEC SQL SELECT <column_name> INTO :<var_host> FROM <table_name> WHERE [<search_condition>]/ [CURRENT OF <cursor_name>] <SELECT>::=<sel_ atm>{<col_atm>} [<into_atm> <var_atm>] <from_atm> {<tab_atm>} <where_atm> [<cond_atm>/<cur_atm>] <sel_atm>::=$SELECT <tab_atm>::=$T(n)n <set_atm>::=$SET <stat_atm>::=$Sn <where_atm>::=$WHERE <cond_atm>::=$C(n)n <current_atm>::=$CURRENT <cur_atm>::=$P Figura 5.6 Sintaxe parcial e LI para o comando SELECT.
A seguir apresentado um modelo de instrumentao para o teste estrutural de programas de aplicao. A instrumentao tem como objetivo dar condies necessrias para a avaliao dos critrios intra-modular e inter-modular.
5.3 Os Modelos de Instrumentao

A instrumentao do programa original tem como objetivo capturar informaes sobre a execuo de casos de teste para a anlise de cobertura dos elementos requeridos
99
pelos diversos critrios de teste. No caso de programas de aplicao, a instrumentao dividida em duas etapas: i) modificar o programa fonte inserindo comandos e informaes, gerando uma nova verso do programa, usualmente denominada de unidade instrumentada para o teste de Unidade; ii) a outra etapa de instrumentao captura informaes referentes identificao das unidades em teste e sobre as tuplas envolvidas na execuo dos comandos da SQL, para os testes intra-modular e inter-modular. No caso da POKETOOL, a unidade instrumentada armazenada no arquivo denominado TESTEPROG.C. Os detalhes e exemplos so mostrados no Apndice C. A instrumentao consiste, essencialmente, em inserir pontas de prova para indicar o nmero de cada bloco de comandos da linguagem hospedeira ou um comando executvel da linguagem SQL, possibilitando a identificao dos caminhos executados pelos casos de teste usados durante o teste. A ponta de prova um comando de escrita do nmero do n em um arquivo produzindo a seqncia de execuo dos ns em cada caso de teste durante o teste (no caso da POKE-TOOL este arquivo denominado de PATH.TES). No teste de integrao um nmero identifica o Mdulo de Programa e a Unidade de Programa. Esta informao escrita no incio do arquivo PATH.TES, representada pelo nmero muuu (m o nmero do mdulo e uuu o nmero da unidade). A unidade UPA do mdulo Mod3.pc tem o nmero 3001 onde 3 representa o nmero do mdulo e 001 representa o nmero da unidade no mdulo Mod3.pc. Para os critrios que tratam das associaes definio-t-uso usadas tanto no teste de unidade como no teste de integrao (intra-modular e inter-modular), utilizada uma instrumentao especial no programa, cujo objetivo informar as tuplas utilizadas durante a execuo dos comandos de manipulao da SQL. Essas informaes so gravadas em um arquivo denominado Keyint.tes indicando o nmero de cada caso de teste juntamente com as informaes sobre as tuplas utilizadas na execuo do respectivo caso de teste. Essa instrumentao difere da primeira tendo em vista que sua informao depende da composio dos campos que compem a tupla. A partir do programa instrumentado, cada execuo dos casos de testes resulta em uma escrita de todos os ns percorridos no programa referente Unidade instrumentada, gerando um arquivo Pathn.tes onde n representa o nmero do caso de teste. Tal escrita facilita a implementao de outras funes; por exemplo: determina quantas vezes um 100
comando foi executado bem como auxilia na depurao aps a ocorrncia de uma falha durante a fase de teste. Exemplo e detalhes podem ser vistos no Apndice C.
5.3.1 Instrumentando o programa original

A instrumentao reflete a semntica dos comandos da LI de forma a viabilizar a avaliao exata dos caminhos efetivamente executados. O fluxo de controle adotado para cada comando , entretanto, representado pela instrumentao que reflete o fluxo correlato no momento da execuo das unidades instrumentadas. Quanto aos comandos da SQL, cuidados especiais devem ser tomados com relao ao comando declarativo de tratamento de erros que o responsvel pelo fluxo de controle dos comandos executveis da SQL. A ferramenta POKE-TOOL instrumenta programas escritos em linguagem C e os transformam em uma linguagem intermediria LI [MAL91, CHA91]. Para os comandos executveis da SQL existem cuidados relativos s aes de controle de erros, sendo que a ao denominada DO <funo> faz com que o gerador do programa instrumentado modifique alguns comandos do programa. No caso da ao DO <funo> ocorrem as seguintes modificaes: i) alterar o comando declarativo EXEC SQL WHENEVER <condio> DO <funo> para o comando EXEC SQL WHENEVER <condio> CONTINUE e; ii) incluir o comando if sqlerror<0 {ponta de prova (n); <funo>} aps os comandos de manipulao da SQL que sucedem ao comando declarativo de manipulao de erro; n representa o nmero do bloco de comando onde o comando de chamada da funo foi acrescentado. Isto implica que quando a operao do comando de manipulao resultar em um erro de execuo, o comando funo() colocado aps o comando de manipulao da SQL deve ser executado, conforme mostra a Figura 5.7.
101
Comando de manipulao da SQL
Ao DO <funo> no comando declarativo de tratamento de erro da SQL
Ponta_de-prova (b)
EXECSQL WHENEVER SQLERROR CONTINUE; Ponta_de-prova (b+1)

O n b representa um bloco de comandos da linguagem hospedeira; O n retangular (b+1) pode ser qualquer comando de manipulao de dados da SQL; O n (b+2) um bloco virtual colocado para atender a ao do comando declarativo de tratamento de erro, cuja ao DO <funo>; aps a ocorrncia do bloco b+2 o fluxo seguido para o bloco b+3 ou interrompido o fluxo se existir um comando exit(1) no final do bloco b+2. !=error
INSERT/ DELETE/ UPDATE/ SELECT
b+1
==error
Ponta_de-prova (b+2) Funo( );
b+2
b+3
Ponta_de-prova (b+3) ...
um subgrafo podendo existir ns da linguagem hospedeira ou da SQL.
Figura 5.7 Instrumentao dos comandos de manipulao da SQL para a ao DO <funo>
A ao STOP do comando declarativo de tratamento de erro faz com que o gerador de instrumentao provoque vrias modificaes no programa: i) alterar o comando declarativo EXEC SQL WHENEVER <condio> STOP para o comando EXEC SQL WHENEVER <condio> CONTINUE; e ii) incluir o comando if (sqlca.sqlcode < 0) {ponta de prova(f); exit(1); } aps os comandos de manipulao da SQL que sucederem ao comando declarativo de manipulao de erro; f representa o nmero do ltimo comando do programa (ltimo n). A instrumentao para todos os blocos de comandos sempre anotada no incio de cada bloco e, nos casos dos comandos executveis da SQL, ela ocorre antes de cada comando. No caso da ao GOTO <rtulo> no ocorre nenhuma modificao nos 102
comandos; apenas so acrescentadas as pontas de provas no incio de cada bloco de comando e antes de cada comando executvel da SQL. O mesmo ocorre para a ao CONTINUE.
5.3.2 Identificando as tuplas

A instrumentao para a incluso das informaes sobre as tuplas utilizadas durante a execuo de cada comando de manipulao da SQL, em uma definio ou um uso persistente de uma tabela t, feita em duas etapas. A primeira etapa preenchida pelo prprio testador que fornece vrias informaes ao analisador sinttico, responsvel pela instrumentao do programa. A segunda etapa gerar um arquivo que informa todas as variveis tabela e suas respectivas chaves primrias: cada tipo e quais comandos devem ser includos no programa para gerar a informao referente s tuplas (conforme mostra a Figura 5.8). As informaes iniciais se restringem ao nome de cada varivel tabela do programa e sua respectiva chave primria. Essas informaes so armazenadas em um arquivo denominado tab_ch_pr.tes mostrado na Figura 5.9. Em seguida so informados os nomes das variveis host utilizadas para relacionar as chaves primrias de cada varivel tabela. Dessa forma, o analisador sinttico incluir no programa novos comandos que indicaro as chaves primrias, colocadas pelo testador no arquivo tab_ch_pr.tes (Figura 5.8), que so usadas no comando de manipulao da SQL. Para cada comando que caracteriza uma definio persistente da tabela t, existe um comando especfico para indicar a tupla utilizada. O comando SELECT o comando que necessita de mais informaes. Sempre que a chave primria est ausente no comando, necessrio inclu-la. A Figura 5.9 mostra o arquivo de auxlio para a instrumentao das informaes sobre as tuplas referentes a cada varivel tabela no Mdulo de Programa Mod3.pc do experimento realizado. Este arquivo auxilia a etapa de instrumentao. Ele composto por comandos de atribuio das chaves primrias para cada varivel tabela no Mdulo da aplicao. Esses comandos do auxlio instrumentao para aplicar os critrios de teste que requerem as associaes das variveis persistentes.
103
Arquivo inst_ch_pr.tes EXEC SQL BEGIN DECLARE SECTION; int mhp1,mhsi1,mhd1,mhe1,mhc1,mhso1; char mhfd1[5]; VARCHAR mhfd2[7], mhfd3[5], mhfc1[4]; EXEC SQL END DECLARE SECTION; char me_emp_id[11], mso_id[11], md_dept_id[11], mfc_code[7], mfd_year[6], mfd_quarter[5], mfd_code[7], mp_prod_id[11], msi_id[11], mc_cust_id[11]; /* Conversoes */ NUMBER(11) p.prod_id in PRODUCT for int :mhp1 ->char mp_prod_id[11]; NUMBER(11) si.id in SALES_ORDER_ITEMS for int :mhsi1 ->char msi_id[11]; NUMBER(11) d.dept_id in DEPARTAMENTO for int :mhd1 ->char md_dept_id[11]; NUMBER(11) e.emp_id in EMPLOYEE for int :mhe1 ->char me_emp_id[11]; NUMBER(11) c.cust_id in CUSTOMER for int :mhc1 ->char mc_cust_id[11]; NUMBER(11) so.id in SALES_ORDER for int :mhso1 ->char mso_id[11]; CHAR(4) fd.year, VARCHAR2(7) fd.quarter,VARCHAR2(4) fd.code in FIN_DATE for char :mhfd1, VARCHAR :mhfd2,:mhfd3 ->char mfd_year[6], mfd_quarter[5],mfd_code[7]; VARCHAR2(4) fc.code in FIN_CODE for VARCHAR :mhfc1 ->char mfc_code[7]; PRODUCT: mhp1=hp1; /* INSERT, DELETE, UPDATE */ itoa(mhp1, mp_prod_id); /* int para char */ fprintf(key, "PRODUCT: %s \n",mp_prod_id); SALES_ORDER_ITEMS: mhsi1=hsi1; /* INSERT, DELETE, UPDATE */ itoa(mhsi1,msi_id); /* int para char */ fprintf(key, "SALES_ORDER_ITEMS: %s \n",msi_id); DEPARTAMENTO: mhd1=hd1; /* INSERT, DELETE, UPDATE */ itoa(mhd1,md_dept_id); /* int para char */ fprintf(key, "DEPARTAMENTO: %s \n",md_dept_id); EMPLOYEE: mhe1=he1;
/* INSERT, DELETE, UPDATE */
itoa(mhe1,me_emp_id); /* int para char */ fprintf(key, "EMPLOYEE: %s \n",me_emp_id); CUSTOMER: mhc1=h1; /* INSERT, DELETE, UPDATE */ itoa(mhc1, mc_cust_id); /* int para char */ fprintf(key, "CUSTOMER: %s \n",mc_cust_id); SALES_ORDER: mhso1=hso1; /* INSERT, DELETE, UPDATE */ itoa(mhso1,mso_id); /* int para char */ fprintf(key, "SALES_ORDER: %s \n",mso_id);
Figura: 5.8: Arquivo de auxlio instrumentao das tuplas para as tabelas: EMPLOYEE, DEPARTAMENTO, CUSTOMER E SALES_ORDER.
104
Arquivo Tab_ch_pr.tes Relao das chaves primrias e dos tipos de dados para cada varivel tabela.
Tabela Employee he1 emp_id NUMBER(11) Tabela Sales_Order hso1 id NUMBER(11) Tabela Department hd1 dept_id NUMBER(11) Tabela Fin_Code hfc1 code VARCHAR2(4) Tabela hfd1 hfd2 hfd3 Fin_Date year CHAR(4) quarter VARCHAR2(7) code VARCHAR(4)
Figura 5.9: Arquivo tab_ch_pr.tes: chaves primrias das tabelas usadas no programa Mod3.pc
Nos exemplos apresentados nas Figuras 5.10a, 5.10b e 5.10c so mostrados os arquivos utilizados na elaborao da instrumentao de uma UP do Mdulo de Programa Mod3.pc, usado nos exemplos de utilizao dos critrios; a Figura 5.10a mostra o Programa Fonte usado no teste; o Exemplo da Figura 5.10b mostra o arquivo gerado na primeira instrumentao (ns e caminhos) e o Exemplo da Figura 5.10c mostra o arquivo gerado na segunda instrumentao (tuplas).
105
Arquivo testemod3.pc (inicial) int insemp (line) RECORD *line; { he1 = atoi (line->e_emp_id); he2 = atoi (line->e_manager_id); EXEC SQL WHENEVER SQLERROR GOTO end1; EXEC SQL INSERT INTO EMPLOYEE ( emp_id, manager_id) VALUES ( :he1, :he2); EXEC SQL COMMIT; end1: return (sqlca.sqlcode);
Figura
Arquivo testeprog3.pc (Instrumentao dos caminhos) int insemp (line) RECORD *line; { FILE * path =fopen("insemp/path.tes","a"); static int printed_nodes = 0; ponta_de_prova(1);
/*
/* /*
1 */
1 */
he1 = atoi (line->e_emp_id);

EXEC SQL WHENEVER SQLERROR GOTO end1; ponta_de_prova(2);
1 */ he2 = atoi (line->e_manager_id);
/* 2 */ EXEC SQL INSERT INTO EMPLOYEE

( emp_id, manager_id) VALUES ( :he1, :he2); ponta_de_prova(3); EXEC SQL COMMIT; end1: ponta_de_prova(4); ponta_de_prova(5);
/* 3 */ /* 4 */
fclose(path); /* 4 */ return (sqlca.sqlcode); /* 5 */ } Figura 5.10b Programa instrumentado para o teste de Unidade
106
Arquivo Mod3_int.pc (Instrumentao dos caminhos) int insemp (line) RECORD *line; { FILE * path =fopen("insemp/path.tes","a"); FILE * key = fopen("insemp/key.tes","a"); static int printed_nodes = 0; ponta_de_prova(3001); /* nmero do programa insemp */ ponta_de_prova(1);
/* 1 */
/* 1 */ /* 1 */
he1 = atoi (line->e_emp_id);

he2 = atoi (line->e_manager_id); EXEC SQL WHENEVER SQLERROR GOTO end1; ponta_de_prova(2);
/* 2 */
EXEC SQL INSERT INTO EMPLOYEE

( emp_id, manager_id) VALUES ( :he1, :he2);
mhe1=he1; /* INSERT, DELETE, UPDATE */ itoa(mhe1,me_emp_id); /* int para char */ fprintf(key, "EMPLOYEE: %s \n",me_emp_id); ponta_de_prova(3); EXEC SQL COMMIT; end1: ponta_de_prova(4); ponta_de_prova(5); fclose(key); fclose(path); return (sqlca.sqlcode); }
/* 3 */ /* 4 */
/* 4 */ /* 5 */
Exemplo 5.10c: Programa instrumentado para os critrios de integrao intra-modulares e inter-modulares.
5.4 Modelo de Fluxo de Dados

No contexto de teste de software, a anlise de fluxo de dados usualmente utilizada para estender o grafo de programa pela associao de tipos de ocorrncias de variveis aos elementos desse grafo que, posteriormente, utilizado para determinao de associaes requeridas pelos critrios de teste. Para programas de ABDR o modelo de fluxo de dados dividido em dois tipos de fluxos: intra-modular e inter-modular.
107
Existem trs tipos de ocorrncias das variveis: definio, uso e indefinio. Essas ocorrncias so aplicadas s variveis de programa e variveis host. J para as variveis tabela, adotou-se apenas as ocorrncias de definio e uso por razes j apresentadas. O modelo intra-modular aplicado no teste de unidade e no teste de integrao das unidades de um Mdulo. O modelo inter-modular aplicado na integrao entre os Mdulos da aplicao.
5.4.1 Modelo de Fluxo de Dados Intra-Modular

Para o teste de unidade foram escolhidos para ilustrao os critrios Potenciais Usos [MAL91], implementados na POKE-TOOL. O grafo_def gerado pela POKE-TOOL a partir da ocorrncia de definio das variveis do programa de aplicao. O grafo_def informa as definies e referncias ocorridas em cada n do programa c.r.a. variveis de programa e variveis host, cujas ocorrncias foram estudadas na Seo 3.2.1. A passagem de valores entre procedimentos atravs de parmetros pode ser feita por: valor, referncia ou nome. Se a varivel for passada por referncia ou por nome considera-se que seja um parmetro de sada. As definies decorrentes de possveis definies em chamadas de procedimentos so distinguidas das demais e so ditas definidas por referncia; esta distino utilizada na gerao do grafo(i) [MAL91], ou seja, na determinao dos caminhos livres de definio para cada varivel definida em i. Da mesma forma, as ocorrncias das variveis tabela foram estudadas na Seo 3.2.1. Para a construo do grafo_def apenas indicada a ocorrncia da definio por referncia de t no n onde existir um comando de manipulao da SQL. As Figuras 5.11 e 5.12 sintetizam os conceitos e hipteses para a determinao do grafo_def a partir do modelo de fluxo de controle dos principais comandos da SQL na linguagem LI.
108
Comandos de Manipulao da SQL INSERT, DELETE, UPDATE

<WHENEVER>::=<whenever_atm> <cond_atm> <act_atm> <INSERT>::=<ins_atm><tab_atm> [{<atr_atm>}]<values_atm> {<val_atm>} <DELETE>::= <del_from_atm><tab_atm> <where_atm> [<cond_atm>/<cur_atm>] <UPDATE>::=<up_ atm><tab_atm> <set_atm> {<stat_atm>} <where_atm> [<cond_atm>/<cur_atm>] STOP k k
INSERT DELETE UPDATE INSERT DELETE UPDATE INSERT DELETE UPDATE
CONTINUE
GOTO <rotulo> k
DO <FUNC> k
INSERT DELETE UPDATE
i
r
i
l l l
r f
O n k contm o conjunto de variveis definidas no bloco de comandos associados a este n que envolve o comando declarativo da SQL WHENEVER, o qual responsvel pelo fluxo de controle no comando de manipulao da SQL colocado no n i. O n l contm o conjunto de variveis definidas no bloco de comandos da linguagem hospedeira, associado a este n. O n i contm o conjunto de variveis tabela associadas a um dos comandos de manipulao da SQL (INSERT, DELETE, UPDATE), contendo uma definio por referncia neste n, a qual atribuda uma definio por valor se o comando COMMIT estiver no subgrafo l conforme mostram os fluxos de controles acima.
Figura 5.11: Diretrizes para a Expanso do Grafo de Programa para Obteno do Grafo def: Comandos de Manipulao da Base de Dados (SQL)
109
Comandos de Manipulao da SQL SELECT

<WHENEVER>::=<whenever_atm> <cond_atm> <act_atm>
<SELECT>::=<sel_ atm>{<col_atm>} [<into_atm> <var_atm>] <from_atm> {<tab_atm>} <where_atm> [<cond_atm>/<cur_atm>]

STOP k k
SELECT SELECT SELECT SELECT
CONTINUE
GOTO <rotulo> k
DO <FUNC> k
i
l
r
l
r f
O n k contm o conjunto de variveis definidas no bloco de comandos associados a este n que envolve o comando declarativo da SQL WHENEVER, o qual responsvel pelo fluxo de controle no comando de seleo da SQL colocado no n i. O n l contm o conjunto de variveis definidas no bloco de comandos, da linguagem hospedeira, associado a este n. O n i contm tambm o conjunto de variveis host associadas ao comando de seleo da SQL (SELECT) na clusula <into> <var_host>.
Figura 5.12: Diretrizes para a Expanso do Grafo de Programa para Obteno do Grafo def: Comandos de Seleo da Base de Dados (SQL)
Para obter as informaes referentes aos critrios que exercitam as variveis persistentes, foi necessrio criar uma relao que identifique os pontos do programa onde ocorrem os comandos de manipulao da SQL (INSERT, DELETE, UPDATE) seguido do
110
comando COMMIT para caracterizar a definio persistente de uma tabela t e dos comandos que caracterizam um uso persistente da tabela t (INSERT, DELETE, UPDATE e SELECT). Este arquivo, denominado Tabdtu.tes, gerado para cada tabela utilizada no programa da aplicao. Este arquivo indica o nmero da Unidade de Programa que contm um uso ou uma definio da tabela t mostrando o nmero do n onde ocorre uma definio e um uso persistente de t. A partir deste arquivo so construdas as associaes definio-tuso para cada tabela envolvida no programa. Essas informaes so utilizadas para a gerao dos elementos requeridos para o teste de unidade e integrao referentes aos critrios exclusivos de ABDR. Para exemplificar foi utilizado o Mdulo Mod3.pc que relaciona 5 variveis tabela. Para a varivel EMPLOYEE foi gerado o arquivo Tabdtu.tes mostrado na Figura 5.13. O nmero (3001) do arquivo Tabdtu.tes representa o nmero da Unidade. Defp indica os nmeros dos ns onde ocorrem as definies persistentes; o primeiro nmero representa o n l referente ao comando de manipulao da SQL e o nmero que antecede o zero representa o n i referente ao comando COMMIT da SQL. J os nmeros de uso representam os ns que contm um dos comandos de manipulao ou de alterao da SQL que caracterizam um t-uso. O nmero zero (0) indica que no existe nenhum n para defp ou uso. Arquivo Tabdtu.tes - EMPLOYEE
3001 defp: uso: 3006 defp: uso: 3011 defp: uso: 3016 defp: uso: 2 3 0 2 0 2 3 0 2 0 2 3 0 2 0 0 3 6 9 12 0
Figura 5.13: Arquivo tabdeftuso.tes para a tabela EMPLOYEE no Mdulo Mod3.pc
111
5.4.2 Modelo de Fluxo de Dados Inter-Modular

As principais caractersticas para o teste estrutural de uma ABDR, no teste de integrao entre os Mdulos, esto relacionadas ao fluxo de dados ocasionado entre os diferentes Mdulos que definem e usam uma varivel tabela, ocasionando assim, um fluxo de dados entre os Mdulos. Neste caso, para tratar dos critrios Todos os t-usos-ciclo1-int, Todos os dtu-caminhos-int e Todos os t-usos-ciclo2-int definidos na Seo 4.4, so construdos arquivos que relacionam os mdulos que definem e usam uma mesma tabela. Isso feito para cada varivel tabela presente no Mdulo, conforme mostrado na Figura. 5.14 para a tabela EMPLOYEE. O arquivo denominado de Tabidtu.tes. A Figura 5.14 mostra tambm um grafo de fluxo para duas UPs referentes aos Mdulos Mod3.ps e Mod6.ps. A partir deste arquivo so extrados todos os elementos requeridos pelos critrios de Arquivo Tabidtu.tes - EMPLOYEE
3000 3001 3001 defp: uso: 3006 defp: uso: 3011 defp: uso: 3016 defp: uso: 6000 6002 defp: 0 uso: 2 5 0 6003 defp: 0 uso: 2 5 0 6004 defp: 0 uso: 2 5 0 2 3 0 2 0 2 3 0 2 0 2 3 0 2 0 0 3 6 9 12 0 EMPLOYEE 6002
Para cada Unidade de um Mdulo que define a tabela Employee existe uma associao com outra Unidade de outro Mdulo. Esta combinao feita para cada tabela. E assim construdo o elemento requerido para satisfazer o critrio todos os t-usos-ciclo1-inter e para o critrio Todos-dtu-caminhos-inter.
Figura 5.14: Arquivo Tabidtu.tes para a tabela EMPLOYEE nos Mdulos Mod3.pc e Mod6.pc
112
teste inter-modular, utilizados na integrao dos Mdulos da aplicao.
5.5 Modelo de Descrio dos Elementos Requeridos

O modelo de descrio dos elementos requeridos para os critrios propostos nesta tese no apresentado neste trabalho, tendo em vista que no foi desenvolvida nenhuma ferramenta para apoiar esses critrios. O modelo implementado na POKE-TOOL est fundamentado no conceito de arco primitivo [CHU87] e no conceito de grafo(i) [MAL88b]. O conceito de arco primitivo se baseia no fato de existirem arcos10 dentro de um grafo de programa que so sempre executados quando outro arco executado. Desta forma, a FCPU passa a requerer associaes com base nos arcos primitivos, eliminando os demais arcos denominados de arcos herdeiros. Para os critrios de ABDR a utilizao de arcos primitivos no contexto de fluxo de dados continua sendo a mesma de Maldonado [MAL91]. Sendo assim, a implementao dos descritores dos critrios abordados nesta tese mais simples, considerando apenas os caminhos que possuem os ns da SQL. Para os critrios de teste de unidade e teste de integrao, que requerem associaes definio-tuso, foi criado o grafo<l,i> (extrado do conceito de grafo(i), definido em [MAL91]). O grafo<l,i> construdo a partir de cada par de ns <l,i>, com definio persistente c.r.a. t, que alcanar: ou um t-uso (n de SQL), ou um o n de sada do grafo de programa, com um caminho livre de definio c.r.a. t e livre de lao. O modelo de descrio dos elementos requeridos para os critrios de programas de aplicao pode ter como ponto de partida o modelo de implementao apresentado em [MAL91]. Nossa expectativa implementar uma ferramenta que apie os critrios de ABDR e complemente os demais critrios estruturais (como os da FCPU ou FCFD). Nos exemplos utilizados para ilustrar a aplicao dos critrios, os descritores dos elementos requeridos foram gerados manualmente, separados em diretrios referentes a cada varivel tabela envolvida na associao. No caso do critrio todos os t-usos-ciclo1intra criado um arquivo que armazena todas as associaes definio-t-uso referentes a uma varivel tabela. Durante a execuo dos casos de testes (execuo do teste) so
Esses arcos so considerados no essenciais para a anlise de cobertura. J os arcos primitivos so considerados essenciais para a anlise de cobertura por garantirem a execuo dos demais arcos do grafo de programa.
10
113
gerados dois arquivos: 1) pathint.tes que armazena o nmero do caso de teste, mais o nmero da unidade exercitada e o respectivo caminho executado; e 2) keyint.tes que armazena o nmero de cada caso de teste, o nmero da unidade executada e a tupla utilizada para exercitar o caso de teste (em alguns casos pode ser a prpria chave primria). Depois que todos os casos de teste so executados, a avaliao da cobertura do critrio feita manualmente, avaliando cada caso de teste, tuplas e quais unidades foram envolvidas, para depois avaliar quais associaes foram satisfeitas. Essa avaliao pode ser feita utilizando um autmato finito que avalie o grafod<l,i> que inicia na definio persistente e no grafou<l,i> que inicia no n de entrada do grafo de programa (da unidade associada) e termina nos ns que contm um t-uso. No Apndice C, mostrado um exemplo completo que apresenta as associaes definio-t-uso e os casos de testes que executaram a associao.

Os modelos tericos aqui apresentados visam a fornecer maior preciso e uniformidade automatizao dos critrios de testes baseados em fluxo de dados para Aplicaes de Banco de Dados Relacional. Uma das propostas de continuidade deste trabalho incorporar ferramenta POKE-TOOL os critrios de teste de integrao intramodular e inter-modular, de modo a auxiliar o teste de programas de aplicao. Os modelos de fluxo de controle, de instrumentao e de fluxo de dados so fundamentais para completar os estudos de comparao emprica dos critrios aqui propostos. Para a implementao desses modelos na ferramenta POKE-TOOL deve-se inicialmente acrescentar informaes referentes aos comandos da SQL (estender a LI), de modo a possibilitar o teste de unidade em programas de aplicao. Vrios programas devem ser modificados para a gerao dos descritores e dos elementos requeridos referentes aos novos critrios. A partir da descrio dos elementos requeridos para os critrios de teste de unidade usada em [MAL91] (conceitos de arcos primitivos, de grafo_def e de grafo(i)), podemos estend-los para extrair o grafo<l,i> para os critrios que exercitam as variveis
114
persistentes. Os estudos iniciados neste captulo do suporte implementao de um sistema automatizado para a aplicao dos critrios de testes propostos para ABDR. Para o teste de integrao intra-modular e inter-modular, acredita-se que conveniente a preparao de um ambiente que controle e organize os elementos requeridos separando-os para cada varivel tabela envolvida nos Mdulos de Programa. Pode at mesmo ser mais conveniente a construo de uma nova ferramenta de apoio ao teste de integrao.
115
116
6 Exemplos de Utilizao dos Critrios de Teste

Este captulo ilustra a utilizao dos critrios propostos para o teste de programas de ABDR. Na Seo 6.2 so apresentados a descrio das tabelas, dependncias e fluxo de dados para o exemplo de aplicao. Na Seo 6.3 so apresentados resultados obtidos nos exemplos de utilizao. Na Seo 6.4 so apresentadas algumas comparaes referentes utilizao dos critrios. Algumas observaes so feitas sobre os resultados do teste dos programas do exemplo de aplicao.
6.1 Consideraes Iniciais

Para ilustrar a utilizao dos critrios foi desenvolvido um exemplo completo de uma aplicao composta por quatro Mdulos de Programas em linguagem C com SQL embutida, com programas que foram adaptados de uma aplicao real. As tabelas escolhidas para compor a aplicao foram extradas do mdulo de demonstrao do sistema de Banco de Dados da Sybase. A construo desse exemplo tambm teve como objetivo mostrar o comportamento dos fluxos de controle e de dados dos principais comandos da SQL. Inicialmente foi construdo o projeto da base de dados a partir do mdulo SQL/PLUS (que permite usar comandos SQL para criar, manipular e consultar as tabelas da base de dados). Com todas as tabelas devidamente criadas e com suas regras definidas (chaves primrias, chaves estrangeiras, e outras regras), os programas foram construdos e submetidos ao teste estrutural para todos os critrios propostos. Para a execuo dos exemplos foi necessrio fazer algumas modificaes nos arquivos gerados pela ferramenta. A POKE-TOOL no aceita SQL; a primeira tarefa foi instrumentar o programa sem os comandos de SQL e, em seguida, acrescentar os comandos e modificar o programa instrumentado acrescentando os comandos SQL e as novas pontas de provas. Aps a preparao dos programas e da modificao de todos os arquivos (incluso de informaes referentes aos comandos e variveis de ABDR) gerados pela ferramenta (como: tab_vardef.tes, funo.gfc, etc), foram gerados os descritores (para os critrios FCPU) e, em seguida, iniciou-se o teste de cada unidade. Para os testes de integrao intra-modular e inter-modular, a instrumentao para a integrao e os arquivos necessrios foram gerados e modificados manualmente. 117
Captulo 6 Exemplos de Utilizao dos Critrios de Teste
O teste executado em trs fases distintas. A primeira, anlise esttica do programa fonte, consiste em gerar o programa instrumentado, a verso LI do programa e os arquivos referentes s variveis. No programa instrumentado so colocadas vrias informaes que so usadas na ltima fase do teste. Na segunda fase do teste, executam-se os casos de teste para satisfazer os critrios. Para o teste de integrao, foram modificados os programas que controlam a execuo dos casos de teste (de pokeexec para pokeexec_int1e pokeexec_int2) para contemplar os dois ciclos de execuo (critrios de ciclo1 e ciclo2). A ltima fase do teste consiste na anlise dos resultados atravs da avaliao da cobertura dos elementos requeridos pelos critrios. Esses exemplos serviram para avaliar a dificuldade de gerar os casos de teste (uso da mesma tupla, controle do estado das tabelas, etc) que exercitem os elementos requeridos. Como a POKE-TOOL no possui recursos para o teste de integrao, a organizao dos arquivos, a preparao dos resultados e a avaliao so feitas manualmente.
6.2 Descrio das Tabelas, Dependncias e Fluxo de Dados
EMPLOYEE CUSTOMER 1 VENDE 1
n
EMPREGA
n
COMPRA
SALES_ORDER
n
1 FAZ PARTE DE SALES_ORDER_ITENS 1 n 1
TRABALHA 1 DEPARTMENT
FIN_CODE 1
POSSUI REFERE -SE 1 1 FIN_DATE PRODUCT
Figura 6.1a Diagrama de Entidades e Relacionamentos
118
A Figura 6.1a mostra o Diagrama de Entidades e Relacionamentos (DER) da base de dados dos exemplos de aplicao, e a Figura 6.1b mostra o fluxo de dependncia entre as tabelas com suas respectivas chaves primrias e chaves estrangeiras. Foram utilizadas nove tabelas; note-se que a tabela CONTACT no possui relacionamento com as demais tabelas.
cust_id fname lname address city state zip phone company_name Customer <fk> number(11) varchar2(15) varchar2(20) varchar2(35) varchar2(20) varchar2(5) varchar2(10) varchar2(12) varchar2(35) Contact <pk>
cont_id last_name first_name tittle street city state zip phone fax
number(11) varchar2(15) varchar2(15) varchar2(2) varchar2(30) varchar2(20) varchar2(2) varchar2(10) varchar2(10) varchar2(10)
cust_id
id cust_id order_date code region emp_id
Sales_Order <pk> number(11) <fk> number(11) date <fk> varchar(11) varchar2(7) <fk> number(11)
id line_id prod_id quantity ship_date
Sales_Order_Items <pk,fk> number(11) <pk> number(7) <fk> number(11) number(11) date
id code
emp_id
prod_id
code type description
Fin_code <pk>
varchar2(4) varchar2(10) varchar2(50)
emp_id manager_id emp_fname emp_lname dept_id street city state zip_code phone status ss_number salary start_date termination_date birth_date bene_health_ins bene_life_ins bene_day_care sex
Employee <pk> number(11) number(11) varchar2(20) varchar2(20) <fk> number(11) varchar2(40) varchar2(20) varchar2(5) varchar2(11) varchar2(11) varchar2(6) varchar2(11) number(22.2) date char(16) date varchar2(15) varchar2(13) varchar2(13) varchar2(3)
prod_id name description size color quantity unit_price
Product <pk> number(11) varchar2(15) varchar2(30) varchar2(18) varchar2(6) number(11) number(17,2)
code
dept_id
manager_id
year quarter code amount
Fin_date <pk> varchar2(4) <pk> varchar2(7) <pk,fk> varchar2(4) number(11)
dept_id dept_name manager_id fk_manager_id
Department <pk> number(11) varcha2(40) <fk> number(11) number(11)
Figura 6.1b: Tabelas da base de dados e fluxo de dependncia.
Os exemplos de utilizao dos critrios foram desenvolvidos com os objetivos de: i) mostrar que os critrios de teste baseados em anlise de fluxo de dados, em particular os
119
critrios Potenciais Usos, podem ser adaptados para programas de aplicao; ii) estudar o fluxo de controle dos comandos SQL e o fluxo de dados ocasionados pelas variveis tabela e variveis host; iii) estudar os fluxos de dados intra-modular e inter-modular c.r.a. variveis tabela. As tabelas da base de dados so acessadas pelos programas dos exemplos. A aplicao consiste de quatro Mdulos compostos por unidades com comandos SQL que possuem diferentes fluxos de dados. A Figura 6.2 apresenta um diagrama de composio da aplicao, mostrando os fluxos de dados existentes entre os Mdulos e as variveis tabela.
Mdulos de Programa
Mod1
Eployee
Mod2
Sales_order Department
Mod3
Fin_Code Fin_Date
Mod6
Tabelas
Customer
Product
Sales_O_I
t8 t1 t2 t5 t6 t7 t4 t3 Figura 6.2: Fluxo de dados inter-modular da ABDR composta por 4 Mdulos de Programa e 8 tabelas que constituem a base de dados
A Tabela 6.1 explica a Figura 6.2; as letras D e U indicam que o Mdulo (Modi) possui pelo menos uma Unidade que define a varivel tabela (D) e/ou que existe pelo menos uma Unidade que usa a varivel tabela (U). Sendo assim, existe um fluxo do Mdulo para a Tabela quando existir D e um fluxo da Tabela para o Mdulo quando existir
U.
Tabela 6.1: Ocorrncias de definio persistente e uso das variveis tabela nos Mdulos de Programas (D: Definio / U: Uso). Tabelas\
t1 Customer t2 Employee t3 Sales_order t4 Department t5 Fin_Code t6 Fin_Date t7 Product t8 Sales_Order_items t9 Contact
Mod1
D/U D/U D/U D/U D/U
Mod2
D/U D/U -
Mod3
D/U D/U D/U D/U D/U -
Mod6
U U U U U U U U U
120
6.3 Resultados dos Exemplos de Utilizao

A seguir so mostrados os resultados obtidos nos exemplos de utilizao dos critrios de teste para fluxos de dados intra-modular e inter-modular, apresentados no Captulo 4.
6.3.1 Teste intra-modular

O teste intra-modular o teste de cada Mdulo da aplicao, envolvendo o teste de unidade e o teste de integrao baseado no fluxo de dados entre as unidades. Para ilustrar a utilizao dos critrios de teste intra-modular as situaes possveis de ocorrer em um sistema de Banco de Dados Relacional foram consideradas. Os programas em C com SQL embutida desenvolvidos espelham uma amostra real das operaes bsicas de SQL que ocorrem na prtica. Os resultados dos exemplos foram usados para anlise e estudo dos critrios de testes, visando a obter indicaes quanto aplicabilidade dos critrios.
6.3.1.1 Teste de unidade

Tendo em vista que cada programa utilizado no exemplo supera mil linhas de cdigo, sero apresentadas apenas as principais partes dos Mdulos utilizadas para ilustrar o teste e seus respectivos critrios; um exemplo completo est no Apndice C para complementar as informaes sobre como utilizar os critrios. A seguir apresentada uma seqncia de exemplos de resultados parciais do teste de unidade para o Mdulo Mod3.pc - Unidade Insemp. Programa Original: Modulo3.pc Unidade: Insemp
#include <stdio.h> #include <string.h> #include <stdlib.h> typedef struct { char e_emp_id [11]; char e_manager_id[11]; . . . } RECORD; EXEC SQL BEGIN DECLARE SECTION; int h1,he1; VARCHAR h2[15]; EXEC SQL END DECLARE SECTION; EXEC SQL INCLUDE sqlca; . . .
121
int insemp (line) RECORD *line; { he1 = atoi (line->e_emp_id); he2 = atoi (line->e_manager_id); . . . EXEC SQL WHENEVER SQLERROR GOTO end1; EXEC SQL INSERT INTO EMPLOYEE ( emp_id, manager_id, VALUES ( :he1, :he2, . . . EXEC SQL COMMIT; end1: return (sqlca.sqlcode); } .... main() { ... }
Programa Mod3.pc Instrumentado - Unidade: Insemp

#define ponta_de_prova(num) if(++printed_nodes % 10) fprintf(path," %2d ",num);\ else fprintf(path," %2d\n",num); #include <stdio.h> #include <string.h> #include <stdlib.h> .... /* manteve o mesmo do original */ .... int insemp (line) RECORD *line; /* 1 */ { FILE * path = fopen("insemp/path.tes","a"); static int printed_nodes = 0; ponta_de_prova(1); he1 = atoi (line->e_emp_id); he2 = atoi (line->e_manager_id); . . . EXEC SQL WHENEVER SQLERROR GOTO end1; ponta_de_prova(2); EXEC SQL INSERT INTO EMPLOYEE ( emp_id, manager_id, . . . ) VALUES ( :he1, :he2, . . . ); ponta_de_prova(3); EXEC SQL COMMIT;
/* /* /*
1 */ 1 */ 1 */
/* 2 */
/* 3 */
122
/* 4 */
end1: ponta_de_prova(4); ponta_de_prova(5); fclose(path); return (sqlca.sqlcode); }
/* /*
4 */ 5 */
Alm da instrumentao do programa em teste, a POKE-TOOL gera os seguintes arquivos relativos Unidade Insemp (para o teste de unidade): Tabvardef.tes - contm informao sobre todas as variveis globais e locais utilizadas no programa instrumentado Mod3.pc para a unidade Insemp; arquivo Insemp.gfc contm a descrio do grafo de programa da Unidade Insemp.
Arquivo Tabvardef.tes do Mdulo Mod3.pc da Unidade Insemp # Tabela de Variaveis Definidas do Modulo insemp # Globais @ 137 he13 . . . @ 102 he2 @ 101 he1 @ 100 hfd4 # @ @ @ @ Locais 3 sqlca 2 strcpy 1 atoi 0 line
@@
# Grafo Def Sintetico do Modulo insemp @@ 1 Defs: 101 102 103 111 112 113 121 122 123 133 134 135 137 @ Refs: @ @@ 2 Defs: @ Refs: 109 @ @@ 3 Defs: @ Refs: 110 @ @@ 4 Defs: @ Refs: @ @@ 5 Defs: @
114
115
116
117
118
119
120
Refs: @
123
Insemp.gfc: Grafo de programa da Unidade Insemp.
5
Total de ns no grafo
1
2 0
2
3 4 0 3 4 0 4 5 0 5 0
Insemp.sql: Ns de SQL na unidade Insemp.

2
Total de ns SQL
2 3
N do n SQL
A partir do arquivo Insemp.gfc e do arquivo Insemp.sql a ferramenta ViewGraph 2.0 [CRU99] gera a visualizao do grafo com os ns da SQL; essa visualizao mostrada na Figura 6.3. O arquivo Arcprim.tes contm os arcos primitivos referentes ao grafo de programa. A ferramenta ViewGraph oferece a opo de desenhar o grafo de programa os arcos primitivos utilizando o arquivo Arcprim.tes.
ARCOS PRIMITIVOS da Unidade Insemp 1) arco ( 2, 3) 2) arco ( 2, 4)
Exemplo 6.3: Arquivo Arcprim.tes.
A segunda fase do teste de Unidade a execuo dos casos de teste. Aps compilado, o Programa Instrumentado (mostrado no Exemplo 6.2) utilizado para a execuo dos casos de testes. Para ilustrar esta etapa, foram apresentados os exemplos referentes unidade Insemp do Exemplo 6.1. A fase de execuo dos casos de teste feita a partir do programa pokeexec da POKE-TOOL.
124
Figura 6.3: Visualizao do teste da unidade Insemp
A seguir apresentado um dado de entrada para exercitar a unidade Insemp; os dados foram colocados em arquivos de entrada numerados (finp01, finp02 etc). No Exemplo 6.4 apresentado o arquivo finp01 com os valores separados por vrgula (, ).
i, 1, 1903, 1576, Carlos, Germanni, 400, Av Maracan, Rio de janeiro, RJ, 21060009, 02198882, A, 118998234, 34000.000, 12-JUL-90, (NULL), 09-DEC60, Y, Y, N, M Exemplo 6.4: Ilustra um arquivo de entrada (finp01) para o Mdulo Mod3
O resultado da execuo um arquivo de sada para cada caso de teste executado. Esses arquivos so armazenados no diretrio output; cada arquivo numerado como output1, output2, etc (onde 1 e 2 referem-se ao nmero de cada caso de teste). Os arquivos de entrada so armazenados no diretrio keyboard ou no diretrio input, que mostram as entradas utilizadas durante a execuo dos casos de testes. Na execuo gerado um arquivo referente ao caminho percorrido no grafo de programa; esses arquivos so numerados como path1, path2 etc, conforme o nmero de cada caso de teste. No exemplo, a execuo do dado de teste finp01 gerou o arquivo path1 para a funo Insemp.
125
Exemplo 6.5: Arquivo path1 - caminho de execuo do dado de teste do Exemplo 6.4
Esse arquivo utilizado posteriormente para a anlise de cobertura dos critrios todos-potenciais-usos. Para avaliar os critrios que exercitam as variveis persistentes necessrio gerar o arquivo keyint.tes onde so armazenadas as tuplas utilizadas durante a execuo dos casos de teste. No Exemplo 6.5, no existe nenhuma associao-t-uso na mesma unidade. Sempre que existir pelo menos uma unidade que possibilite a ocorrncia de uma associao definio-t-uso, com relao a alguma varivel tabela, necessrio fazer a reinstrumentao desta unidade. Para indicar se existe ou no a associao definio-t-uso na unidade, foi criado um arquivo denominado dtuassoc.tes onde so armazenadas todas as associaes da unidade. A re-instrumentao feita a partir do programa intrumentado do teste de unidade. Para o exemplo de utilizao dos critrios a instrumentao foi feita manualmente.
6.3.1.2 Teste de integrao baseado na dependncia de dados

O teste de integrao baseado na dependncia de dados entre as Unidades envolvidas nesta etapa preparado com a re-instrumentao dos programas utilizados no teste de unidade. A re-instrumentao para esta fase acrescenta informaes pertinentes ao nmero de cada unidade e s tuplas, mantendo as demais informaes instrumentadas do teste de unidade. Para ilustrar um programa re-instrumentado apresentado o Exemplo 6.6, o programa do Exemplo 6.2 (unidade Insemp). A re-instrumentao acrescenta informaes sobre as chaves primrias usadas para representar as tuplas das variveis tabela, exigidas pelos critrios propostos neste trabalho, e um nmero que usado para indicar qual unidade foi exercitada durante um caso de teste. Os elementos requeridos pelos critrios de teste de integrao so gerados para cada varivel tabela. Os elementos requeridos dos critrios todos os t-usos-ciclo1-intra e todos os dtu-caminhos-intra so gerados para todos os pares de Unidades que possuem comandos
126
de manipulao da SQL de uma mesma tabela e so colocados em diretrios denominados ciclo1 e organizados pelo nome de cada tabela.
int insemp (line) RECORD *line; /* 1 */ { FILE * path = fopen("insemp/pathint.tes","a"); Arquivos FILE * key = fopen("insemp/keyint.tes","a"); static int printed_nodes = 0; Caminho ponta_de_prova(3001); fprintf(key,3001 \n); ponta_de_prova(1); Tuplas he1 = atoi (line->e_emp_id); he2 = atoi (line->e_manager_id); . . . EXEC SQL WHENEVER SQLERROR GOTO end1; ponta_de_prova(2); mhe1=he1; /* INSERT, DELETE, UPDATE */ itoa(mhe1,me_emp_id); /* int para char */ fprintf(key, "EMPLOYEE: %s \n",me_emp_id); EXEC SQL INSERT INTO EMPLOYEE ( emp_id, manager_id, . . . ) VALUES ( :he1, :he2, . . . ); ponta_de_prova(3); EXEC SQL COMMIT; end1: ponta_de_prova(4); ponta_de_prova(5); fclose(path); fclose(key); return (sqlca.sqlcode); }
/* /* /*
1 */ 1 */ 1 */
/* 2 */
/* 3 */ /* 4 */
/* /*
4 */ 5 */
Exemplo 6.6 Funo Insemp do Programa Mod3 re-instrumentada para o teste de integrao.
A organizao dos arquivos para o teste de integrao do Mdulo Mod3 mostrada na Figura 6.4. Os arquivos dtuassoc.tes e dtupaths_intra.tes contm os elementos requeridos dos critrios todos os t-usos-ciclo1-intra e todos os dtu-caminhos-intra, respectivamente.
127
Figura 6.4 Organizao dos arquivos utilizados para o teste de integrao intra-modular. Os arquivos que contm os elementos requeridos dos critrios todos os t-usosciclo1-intra e todos os dtu-caminhos-intra so mostrados no Exemplo 6.7. O Exemplo 6.7 mostra parte dos elementos requeridos para os critrios todos os tusos; <3001,<2,3>,3016,(2,4),{EMPLOYEE}> a associao entre as unidades 001 e 016 do Mdulo 3. No par <2,3> ocorre a definio persistente da varivel EMPLOYEE, na Unidade 001, e no arco (2,4) ocorre o uso da varivel EMPLOYEE, na Unidade 016. O mesmo ocorre com os elementos requeridos para o critrio todos os dtu-caminhos representados pela seguinte seqncia 3011 2 3 4 5 - 3016 1 11 12 18, onde a primeira seqncia 3011 2 3 4 5 o dtu-caminho (2, 3, 4, 5) da Unidade 011 do Mdulo 3 referente definio-persistente de alguma varivel tabela, e a seqncia 3016 1 11 12 18 o dtu-caminho (1, 11, 12, 18) referente ao uso da varivel persistente.
128
ASSOCIACOES REQUERIDAS PELOS CRITERIOS TODAS DEF-T-USOS-INTRA EMPLOYEE Associacoes requeridas pelo Grafo(3001) - insemp 1) <3001,<2,3>,3001,(2,3),{EMPLOYEE}> 3001 - Unidade (001) pertencente ao Mdulo 3
2) <3001,<2,3>, 3001,(2,4),{EMPLOYEE}>
. . . 14) <3001,<2,3>, 3016,(12,18),{EMPLOYEE}> Associacoes requeridas pelo Grafo(3006) 15) 16) . . 28) <3006,<2,3>,3001,(2,3),{EMPLOYEE}> <3006,<2,3>,3001,(2,4),{EMPLOYEE}> . <3006,<2,3>,3016,(12,18),{EMPLOYEE}>
Associacoes requeridas pelo Grafo(3011) 29) <3011,<2,3>,3001,(2,3),{EMPLOYEE}> 30) <3011,<2,3>,3001,(2,4),{EMPLOYEE}> . . .
42) <3011,<2,3>,3016,(12,18),{EMPLOYEE}>
ASSOCIACOES REQUERIDAS PELOS CRITERIOS TODOS DTU-PATHS-INTRA EMPLOYEE Associacoes requeridas pelo Grafo(3001) - insemp 01) 02) . . 14) 3001 2 3 4 5 - 3001 1 2 3 3001 2 3 4 5 - 3001 1 2 4 . 3001 2 3 4 5 - 3016 1 11 12 18
Associacoes requeridas pelo Grafo(3006) - delemp 15) 16) . . 28) 3006 2 3 4 5 - 3001 1 2 3 3006 2 3 4 5 - 3001 1 2 4 . 3006 2 3 4 5 - 3016 1 11 12 18
Associacoes requeridas pelo Grafo(3011) - updemp 29) 30) . . 42) 3011 2 3 4 5 - 3001 1 2 3 3011 2 3 4 5 - 3001 1 2 4 . 3011 2 3 4 5 - 3016 1 11 12 18
Exemplo 6.7: Arquivos dos elementos requeridos pelos critrios todos os t-usos-ciclo1intra e todos os dtu-caminhos-intra. As informaes de re-instrumentao so utilizadas no teste de integrao intramodular e no teste de integrao inter-modular, alm das informaes sobre as tuplas utilizadas na execuo de cada caso de teste. 129
No caso especfico da varivel tabela EMPLOYEE foram executados 65 casos de teste para satisfazer os elementos requeridos pelo teste de integrao baseado na dependncia de dados. A Figura 6.5 mostra os arquivos Pathint.tes e Keyint.tes, gerados pela execuo dos casos de teste referentes tabela EMPLOYEE no teste de integrao baseado na dependncia de dados intra-modular. Esses arquivos armazenam as informaes referentes aos caminhos e tuplas (para cada unidade envolvida no teste de integrao), utilizadas na avaliao da cobertura dos elementos requeridos pelos critrios de teste de integrao. A avaliao da cobertura dos elementos requeridos pelos critrios propostos nesta tese foi realizada manualmente. Os elementos no exercitados so examinados isoladamente, analisando-se a possibilidade de serem exercitados por outros casos de teste. Neste caso, novos casos de teste so includos. Sempre que executamos um mesmo conjunto de casos de teste em programas convencionais obtm-se a mesma cobertura. No caso do teste de programas de ABDR, devido persistncia da varivel tabela, a execuo de um mesmo conjunto de casos de teste pode ocasionar coberturas distintas. Assim, necessrio restaurar os estados iniciais das tabelas envolvidas no teste antes de iniciarmos a execuo dos casos de teste. O estado inicial de cada tabela denominado de estado start, que o estado em que a tabela deve se encontrar no incio do teste. O estado start da tabela preparado com o menor nmero de elementos que represente todas as dependncias e restries do projeto lgico da base de dados. Para retornar ao estado start, aps uma sesso de teste preciso recuperar os valores de todos os elementos que foram modificados durante o teste.
130
Pathint.tes #1 3001 #2 3006 #3 3001 #4 3011 #5 3001 #6 3001 #7 1 2 3 4 5
Keyint.tes
#1 3001 EMPLOYEE: 1900 #2 3006 EMPLOYEE: 1900 #3 3001 EMPLOYEE: 1900 #4 3011 EMPLOYEE: 1900 #5 3001 EMPLOYEE: 1900 . . . . #nmero do caso de teste . nmero das unidades (3xxx) . varivel e tuplas utilizadas (ch primria)
3001 1 2 4 5 . . . . #nmero do caso de teste . nmero da unidade e seus respectivos caminhos executados
Figura 6.5: Arquivos Pathint.tes e Keyint.tes informaes sobre a execuo do teste de integrao intra-modular.
A cobertura de cada critrio avaliada manualmente. Para simplificar a anlise de cobertura foi criado um arquivo denominado aval_int que apresenta todos os elementos requeridos de um critrio. A partir dos arquivos da Figura 6.5 feita uma avaliao de quais elementos requeridos (do arquivo aval_int) foram exercitados. O arquivo aval_his contm as informaes relacionadas cobertura dos elementos requeridos e quais resultados foram obtidos para compar-los com os resultados esperados. O objetivo desse arquivo simplesmente armazenar a avaliao de cobertura e os resultados do teste. No caso do teste de ABDR, existem elementos requeridos que no so exercitados com a mesma tupla; esses elementos podem ser descartados aps algumas tentativas. Esses elementos foram o testador a exercitar situaes que podem revelar defeitos de implementao. Por exemplo, no comando DELETE ao eliminar uma tupla que chave estrangeira (possui uma referncia a outra tabela) neste caso a tupla no removida. 131
O critrio todos os t-usos-ciclo2-intra, que exercita as dependncias mltiplas, foi aplicado ao Mdulo Mod3, para a Unidade Selfin (3019) que emite um relatrio referente s tabelas FIN_CODE e FIN_DATE. Os elementos requeridos pelo critrio de ciclo2-intra, apresentados no Exemplo 6.8, exercitam as associaes ocasionadas pelas variveis FIN_CODE e FIN_DATE em relao s unidades Insfinc (3005), Insfind (3006), Delfinc (3009), Delfind (3010), Updfinc (3014) e Updfind (3015).
ASSOCIACOES REQUERIDAS PELOS CRITERIOS TODAS DEF-T-USOS-CICLO2-INTRA FIN_CODE/ FIN_DATE Associacoes requeridas pelo Grafo(3004/3005) 1) <3004, <2,3>, 3005, <2,3>, 3019, (2,3), {FIN_CODE,FIN_DATE}> 2) <3004, <2,3>, 3005, <2,3>, 3019, (2,8), {FIN_CODE,FIN_DATE}> Associacoes requeridas pelo Grafo(3009/3010) 3) <3009, <2,3>, 3010, <2,3>, 3019, (2,3), {FIN_CODE,FIN_DATE}> 4) <3009, <2,3>, 3010, <2,3>, 3019, (2,8), {FIN_CODE,FIN_DATE}> Associacoes requeridas pelo Grafo(3014/3015) 5) <3014, <2,3>, 3015, <2,3>, 3019, (2,3), {FIN_CODE,FIN_DATE}> 6) <3014, <2,3>, 3015, <2,3>, 3019, (2,18), {FIN_CODE,FIN_DATE}>
Exemplo 6.8: Arquivo dtuassoc.tes elementos requeridos do critrio Todos os t-usos-ciclo2-intra
Este critrio tambm pode ser aplicado quando existe a necessidade de se definir uma tabela para conseguir a associao-definio-t-uso de outra varivel tabela.
6.3.2 Teste de integrao inter-modular

A integrao inter-modular realizada com base nas dependncias de dados entre as tabelas e os Mdulos da aplicao. Vrias associaes inter-modular so requeridas pelos critrios para o exemplo de aplicao. Nos mdulos Mod1, Mod2, Mod3 e Mod6, existem vrias combinaes de associaes com relao a diferentes variveis tabela. Para continuar a ilustrar o critrio inter-modular, apresenta-se uma associao entre os Mdulos Mod3 e Mod6 em relao varivel Employee. A Figura 6.6 mostra uma tela do teste de integrao inter-modular dos Mdulos Mod3 e Mod6 (envolvendo as Unidades InsEmp (3001) do Mdulo Mod3 e a Unidade RelGer (6002) do Mdulo Mod6).
132
O Exemplo 6.9 apresenta os elementos requeridos do critrio todos os t-usos-ciclo1inter para a tabela Employee e Mdulos Mod3 e Mod6.
ASSOCIACOES REQUERIDAS PELOS CRITERIOS DE INTEGRACAO TODOS_T_USOS INTER_MODULAR: MOD3 X MOD6 -- CICLO1 - MESMA TUPLA - EMPLOYEE Associacoes originadas de Insemp (3001) 0102. . 06<3001, <3,4>, 6002, (2,3),EMPLOYEE> <3001, <3,4>, 6002, (5,6),EMPLOYEE> . <3001, <3,4>, 6004, (5,6),EMPLOYEE>
Associacoes originadas de Delemp (3006) 0708. . 12<3006, <3,4>, 6002, (2,3),EMPLOYEE> <3006, <3,4>, 6002, (5,6),EMPLOYEE> . <3006, <3,4>, 6004, (5,6),EMPLOYEE>
Associacoes originadas de Updemp (3011) 13- <3011, <3,4>, 6002, (2,3),EMPLOYEE> 14- <3011, <3,4>, 6002, (5,6),EMPLOYEE> . . .
18- <3011, <3,4>, 6004, (5,6),EMPLOYEE>

Exemplo 6.9: Arquivo dtuassoc_emp.tes; Elementos requeridos do critrio todos os t-usos-ciclo1-inter.
Este um exemplo montado para exercitar a integrao das unidades do Mdulo Mod6, que no tm nenhuma definio persistente das variveis tabela referenciadas neste Mdulo. Sendo assim, no existe nenhum elemento requerido pelos critrios de integrao intra-modular para o Mdulo Mod6. Com a integrao inter-modular foi possvel exercitar as unidades do Mdulo Mod6 integrando-o com outros Mdulos (Mod2 e Mod3). A POKETOOL no apia o teste de integrao; para executar o teste de integrao inter-modular o programa pokeexec foi substitudo pelo programa pokeexec_inter, que executa os casos de teste para a integrao inter-modular. O programa pokeexec_inter decomposto em dois programas, visando a satisfazer os critrios de ciclo1 e ciclo2 para o teste inter-modular. Os critrios todos os t-usos-ciclo1-inter e todos os dtu-caminhos-inter foram aplicados atravs do programa pokeexec_inter_1 e o critrio todos os t-usos-ciclo2-inter foi aplicado atravs
133
do programa pokeexec_inter_2. O Exemplo 6.10 mostra os arquivos de sada pathint.tes e keyint.tes, gerados pela execuo dos casos de testes. Esses arquivos so usados na avaliao da cobertura dos critrios todos os t-usosciclo1-inter e todos os dtu-caminhos-inter.
Employee
3 4 y 4 5 R 5 4 F 2 3 G 7 2 T 6 7 Y 8 8 N 9 9 H 0 7 J r e 7 8 e w 1 y 5 7 t 3 6 r 2 5 s 8 8 t 1 9 r 3 0 f q t r q t i q 4 r u d f j s j s r 5 7 3 R d F c R b F h R j F k R l T q e 7 8 0 g 6 7 4 e 7 8 0 g 3 3 1 e 7 8 0
6 w s 5 w y 4 r 4 r 5 r 4 r j n x
b h 9 3 1 c n 5 5 1 b h 9 3 1 c n 2 2 2
7 2 d u
6 w s 6 w v
2 1 h o
2 0 M r
w 5 2 t
D j
Figura 6.6: Teste de Integrao inter-modular: Unidade Insemp do Mdulo Mod3 e Unidade RelGer do Mdulo Mod6.
Os arquivos para a avaliao desses critrios so organizados da mesma forma que os arquivos para avaliao do teste de integrao (intra-modular), referente aos mesmos critrios. Os critrios todos os t-usos-ciclo1-inter e todos os t-usos-ciclo2-inter (Mod3xMod6) para a varivel tabela EMPLOYEE requerem 18 (dezoito) associaes. Para satisfazer essas associaes foram necessrios 18 casos de testes, sendo 9 para executar o Mdulo Mod3 e 9
134
para Mod6 no ciclo1 (associaes apresentadas no Exemplo 6.9); para o ciclo2 foram necessrios 27 casos de testes, sendo 18 para o Mod3 e 9 para o Mod6 (associaes apresentadas no Exemplo 6.10). O principal objetivo do teste estrutural de programas de aplicao detectar a presena de defeitos relacionados implementao. Contudo, existem situaes em que o teste em ABDR exercita: i) a consistncia nos comandos de manipulao da SQL em relao a um atributo das variveis tabela (por exemplo: se, no comando UPDATE, o programador permitisse uma alterao de um atributo que chave estrangeira de outra tabela acusaria o erro de consistncia); ii) se a segurana das transaes entre os comandos de manipulao da base de dados est correta (exemplo: um comando que removesse uma tupla que tem uma regra relacionada a outra tabela o sistema no deveria permitir a excluso da tupla). Isso foi observado aps a execuo dos casos de testes na
#1 3001 #1 6002 5 5 5 5 5 5 5 10 #2 3011 #2 6002 5 5 5 5 5 5 #3 3001 #3 1 2 3 4 5
#1 3001 EMPLOYEE: 1920 6 6 6 6 6 6 6 6 7 7 7 7 7 7 8 7 8 8 8 8 8 8 4 8 4 4 4 4 4 4 9 4 #1 6002 DEPARTAMENTO: 400 EMPLOYEE: 1920 #2 3011 EMPLOYEE: 1920 #2 6002 DEPARTAMENTO: 300 EMPLOYEE: 1920 6 6 6 6 6 6 7 7 7 7 7 7 8 8 8 8 8 8 4 4 4 4 4 4 #3 3001 EMPLOYEE: 1901 #3 6003 DEPARTAMENTO: 200 EMPLOYEE: 902 #4 3011 EMPLOYEE: 1576 6 7 8 4 #4 6003 DEPARTAMENTO: 400 EMPLOYEE: 1576
1 6 6 6 6 6 6 6 7 7 7 7 7 7 7
2 8 8 8 8 8 8 8
3 4 4 4 4 4 4 4
4 5 5 5 5 5 5 5
1 6 6 6 6 6 6 7 7 7 7 7 8
2 8 8 8 8 8 4
3 4 4 4 4 4 9
4 5 5 5 5 5 10
6003 1 2 3 4 5 5 6 8 4 9 10 #4 3011 1 2 3 4 5
Figura 6.7: Arquivos Pathint.tes caminhos executados e Keyint.tes seqncia de tuplas.
135
integrao intra-modular e inter-modular. Defeitos em comandos de consultas da SQL (uso de queries indevidas) so detectados ao exercitar os elementos requeridos pelos critrios de integrao (intra-modular e inter-modular). Vrias associaes com dependncia mltipla foram detectadas nos Mdulos Mod3 e Mod6. Neste caso foi gerado o arquivo dtu_assoc_inter_mod3x6.tes, mostrado no Exemplo 6.10. Aqui vemos uma situao onde o Mdulo Mod6 no possui nenhum elemento requerido para o teste de integrao intra-modular e no entanto ele exercitado no teste de integrao inter-modular.
ASSOCIACOES REQUERIDAS PELOS CRITERIOS DE INTEGRACAO TODOS_T_USOS INTER_MODULAR: MOD3 X MOD6 -- CICLO2 - MESMA TUPLA - EMPLOYEE, SALES_ORDER E DEPARTAMENTO Associacoes originadas de Insemp(3001),Inssal(3002) e Insdep(3003) 0102. . 06<3003,(3,4),3001,(3,4),6002,(2,3),{DEPARTAMENTO,EMPLOYEE}> * 1 <3003,(3,4),3001,(3,4),6002,(5,6),{DEPARTAMENTO,EMPLOYEE}> * 1 . <3001,(3,4),3002,(3,4),6004,(5,6),{SALES_ORDER,EMPLOYEE}> * 3
Associacoes originadas de Delemp(3006),Delsal(3007) e Deldep(3008) 0708. . 12<3006,(3,4),3008,(3,4),6002,(2,3),{DEPARTAMENTO,EMPLOYEE}> <3006,(3,4),3008,(3,4),6002,(5,6),{DEPARTAMENTO,EMPLOYEE}> . <3007,(3,4),3006,(3,4),6004,(5,6),{SALES_ORDER,EMPLOYEE}>
Associacoes originadas de Updemp(3011), Updsal(3012) e Upddep(3013) 1314. . 18<3013,(3,4),3011,(3,4),6002,(2,3),{DEPARTAMENTO,EMPLOYEE}> <3013,(3,4),3011,(3,4),6002,(5,6),{DEPARTAMENTO,EMPLOYEE}> . <3011,(3,4),3012,(3,4),6004,(5,6),{SALES_ORDER,EMPLOYEE}>
Exemplo 6.10: Elementos requeridos pelo critrio todos os t-usos-ciclo2-inter. As comparaes apresentadas visam a avaliar a utilizao dos critrios de teste propostos. Um dos principais problemas no teste de integrao a gerao do grande volume de dados em cada tipo de integrao (intra-modular e inter-modular), dificultando a elaborao da anlise de cobertura. A cobertura neste caso deve ser observada entre as ocorrncias das Unidades envolvidas na definio da varivel tabela com a Unidade que usou a varivel tabela para a mesma tupla, um exemplo mostrado no final do Apndice C.
136
6.4 Comparao da utilizao dos critrios

Inicialmente mostrado o total parcial do nmero de casos de testes necessrios para o teste de unidade e para o teste de integrao.
Teste de unidade
A Tabela 6.2 mostra o nmero de casos de teste necessrios para satisfazer os critrios (da FCPU) de Teste de Unidade para cada Mdulo do exemplo.
Tabela6.2: Quadro geral dos Mdulos de Programas executados no teste de Unidade.
Mdulo de Programa Mod2 Mod3 Mod6
Nmero de Casos de testes 168 98 56
No. de Ups em teste 07 20 06
No teste de integrao, os casos de testes so escolhidos para cada varivel tabela envolvida nas associaes, devido exigncia de mesma tupla para satisfazer os critrios de teste de integrao.
Teste de integrao
A Tabela 6.3 apresenta o total de elementos requeridos (elem.req.) pelo critrio Todos os t-usos-ciclo1-intra, para as variveis tabela associadas no Mdulo Mod3; apresenta tambm o total de elementos requeridos no executveis (ne) dando como resultado, a porcentagem de cobertura atingida para este critrio. Tabela 6.3: Testes para o critrio de integrao todos os t-usos-ciclo1-intra para o Mdulo Mod3 Tabelas Total de elem.req. (ne) Nos de Casos de testes Cobertura Departamento Employee Fin Sales 36 (9) 42 (10) 48(24) 36(10) 60 65 60 49 75% 76,19% *50% 72,20%
A Tabela 6.4 mostra o resultado para tabelas associadas nos testes de integrao (intra-modular e inter-modular) dos Mdulos para os critrios de ciclo1 e ciclo2.
137
Captulo 6 Exemplos de Utilizao dos Critrios de Teste 1.
Observaes No teste de integrao intra-modular-ciclo1 (Tabela 6.3) para o Mdulo Mod3 foram necessrios 234 casos de testes para satisfazer os elementos requeridos das associaes entre as UPs do Mdulo Mod3; no teste de unidade para os critrios da FCPU (Tabela 6.2) foram necessrios 98 casos de testes. No caso do Mdulo Mod6 no houve nenhuma associao intra-modular, devido ausncia de comandos que definem uma varivel tabela; no teste de unidade (Tabela 6.2) foram necessrios 56 casos de testes para satisfazer os elementos requeridos.
2.
No teste de integrao intra-modular no existe nenhum elemento requerido para o Mdulo Mod6; na integrao inter-modular existem 48 elementos requeridos em cada ciclo para o critrio todos os t-usos (sendo 42 com Mod3 e 6 com o Mod2). Os erros ocasionados pelas queries durante as consultas s foram observados com a integrao entre os mdulos envolvendo o Mod6. Tabela 6.4: Elementos requeridos pelo critrio todos os t-usos-inter para os mdulos Mod2, Mod3 e Mod6. Elementos Requeridos Moddef Moduso Casos de testes
Todos os t-usos
Ciclo1 Mod2 Mod2 Mod3 Mod3 Mod3 Mod6 Mod2 Mod6 9 6 9 42
ciclo2 6 42
ciclo1 18 12 18 40
Ciclo2 18 60
3.
Esses resultados mostram que os critrios de teste de unidade, de integrao intra-modular e de integrao inter-modular, alm de serem incomparveis teoricamente, no podem tampouco ser comparados quanto sua fora relativa (no se pode concluir sobre a dificuldade relativa de satisfaz-los). Isto se deve ao fato de que cada um deles enfoca aspectos distintos de programas de uma ABDR. Os erros observados pelos critrios da FCPU no destacam os erros
138
referentes ao uso dos comandos da SQL, sendo esses observados somente com os critrios baseados da dependncia de dados intra-modular e inter-modular.

O exemplo de aplicao apresentado neste captulo mostra que possvel utilizar os critrios propostos e analisar os diferentes tipos de fluxos de dados de uma ABDR. Foi necessrio adaptar a ferramenta POKE-TOOL, modificando manualmente os arquivos utilizados pela ferramenta. As ferramentas POKE-TOOL e VIEWGRAPH (V.2.0) foram essenciais para a elaborao do exemplo em tempo hbil. Os exemplos de utilizao mostram que os critrios so complementares e importantes no teste de programas de aplicao, por exigirem, caractersticas exclusivas de ABDR. O teste inter-modular complementa o teste intra-modular atravs da combinao de mdulos que somente consultam uma varivel tabela com mdulos que possuem definio persistente da mesma tabela. Durante a realizao do teste, notou-se que a exigncia de mesma tupla para satisfazer os critrios de integrao faz com que exercitemos diferentes tipos de combinaes de atributos das variveis tabela; isto fora o entendimento das condies do projeto do Banco de Dados (consistncia da base de dados em relao s chaves primrias e estrangeiras; restries ou regras existentes no projeto; etc), dando a oportunidade de deteco de defeitos de implementao dos comandos SQL. Em nosso exemplo, defeitos foram detectados no teste de integrao intra-modular e inter-modular relativamente aos comandos SQL. Tambm foi possvel observar a existncia de algumas associaes definio-t-uso que podem ser omitidas ou cuja dificuldade de exercitar pode ser indicada ao testador. A Tabela 6.6 apresenta uma relao entre as possveis associaes dos comandos que definem a varivel t e comandos que usam t. Os comandos colocados na coluna so os responsveis pela definio persistente de t. Os comandos colocados na linha superior da tabela so os responsveis pelo t-uso. As colunas Error correspondem s associaes com os arcos de sada que representam o arco de tratamento de erro dado pelo comando WHENEVER <condio> <ao> e as colunas !Error representam o fluxo de sada sem a ocorrncia de erro. 139
t-uso Definio t INSERT DELETE UPDATE * omitir
Tabela 6.6: Associaes entre os comandos da SQL c.r.a. t INSERT DELETE UPDATE Error E *E * !Error * E E Error * E * !Error E * E Error E E E !Error E E E
SELECT Error E+ E+ E+ !Error E+ E+ E+
*E casos critcos E exercitar
E+ exercitar com mais ateno
Observe que 50% das associaes cujos t-usos esto em ns com INSERT e DELETE no precisam ser exercitadas (casos crticos como presena de condio CASCADE devem ser observados *E). As associaes (E+) que possuem um t-uso no comando SELECT so todos necessrios para explorar as situaes em que ocorre mais do que um elemento consultado ou casos onde ocorre duplicao de chaves utilizadas no predicado do comando. Neste caso, deve-se forar as diferentes situaes para exercitar os arcos com Error ou !Error aps o comando SELECT. O exemplo mostra tambm que os critrios de teste de unidade e de integrao no podem ser comparados quanto sua fora relativa devido ao fato de enfocarem aspectos distintos de programas de ABDR e, portanto, classes distintas de defeitos. No caso dos critrios de teste da FCPU visam a exercitar as variveis que tm definio e uso na memria interna do computador, durante uma mesma execuo. J os critrios especficos para ABDR exercitam as variveis persistentes, que neste caso so representadas pelas variveis tabela.
140
7 Concluses e Trabalhos Futuros

Na Seo 7.1 deste captulo so apresentadas as concluses desta tese; na Seo 7.2, so discutidas as principais contribuies da tese; e, finalmente, na ltima seo so propostos e discutidos os trabalhos de pesquisas futuros.
7.1 Concluses
Apesar de os critrios de teste estrutural de software desenvolvidos nos ltimos anos serem aplicveis a diversos tipos de softwares, eles no se aplicam a todas as reas de desenvolvimento de software. O enfoque principal deste trabalho o desenvolvimento de programas de Aplicao de Banco de Dados Relacional com SQL embutida. proposta uma abordagem de teste estrutural baseada em dois tipos de fluxos de dados: intra-modular e inter-modular. O primeiro tipo de fluxo aplica-se ao teste isolado de programas de ABDR com SQL embutida; o segundo tipo de fluxo de dados aplica-se integrao de mdulos, requerendo a execuo de comandos SQL que manipulam as variveis tabela de uma ABDR. Critrios de teste estrutural podem ser usados para o teste de unidade usando o fluxo de dados intra-modular; novos critrios (com caractersticas exclusivas para exercitar as variveis tabela de programas de ABDR) so propostos neste trabalho. introduzida uma nova abordagem de teste de integrao para exercitar associaes definio-t-uso de variveis persistentes; essa abordagem pode ser estendida para exercitar outros tipos de variveis persistentes (gravadas e acessadas em meio fsico). Estabeleceu-se tambm uma terminologia para os critrios de teste propostos, tendo como alvo principal s associaes definio-uso das variveis tabela. Os critrios propostos para o teste de integrao baseado na dependncia de dados intra-modular e inter-modular exigem a mesma tupla da varivel tabela para exercitar as associaes definio-t-uso. Foi apresentada uma proposta com os seguintes modelos de implementao: i) Modelo de instrumentao dos comandos de SQL; ii) Modelo de fluxo de controle; iii) Modelo de fluxo de dados; e iv) Descrio dos elementos requeridos pelos critrios. Esses modelos so a base de ferramentas de apoio ao teste de programas de ABDR. 141
Captulo 7 Concluses e Trabalhos Futuros
A partir do exemplo de aplicao foi possvel observar que os critrios possuem exigncias distintas por exercitarem aspectos diferentes. Foi possvel observar tambm que nenhum critrio mais forte do que os outros e que eles so complementares por exercitarem tipos diferentes de fluxo de dados. Os critrios de teste de integrao intra-modular e inter-modular requerem o exerccio de todas as possveis combinaes de usos das queries nos comandos SQL para cada varivel tabela. A realizao do teste do exemplo de ABDR mostrou que importante controlar o estado inicial da varivel tabela para manter a mesma cobertura quando executarmos um mesmo conjunto de casos de teste. Este fato mostra que o testador deve estar bem atento quanto escolha dos casos de teste e quanto ao estado inicial da varivel tabela; isso equivale a estender o conjunto de casos de teste acrescentando o estado inicial de cada varivel tabela. O exemplo mostrou que possvel adaptar critrios de teste de unidade para programas de ABDR e que o auxlio das ferramentas de apoio ao teste facilitam a aplicao dos critrios, mesmo para programas extensos. Os objetivos iniciais foram alcanados e o teste estrutural passa a dispor de uma abordagem que pode ser estendida para outras classes de programas que utilizam variveis persistentes.
7.2 Contribuies da Tese

As contribuies desta tese so caracterizadas pela proposio e anlise de propriedades de critrios de teste para programas de ABDR com SQL embutida, alm da utilizao desses critrios em um exemplo de aplicao derivado de um caso real e do estudo dos resultados da utilizao dos critrios. As principais contribuies so apresentadas e discutidas a seguir: i) A primeira contribuio deste trabalho foi observar que os critrios de teste estrutural podem ser usados no teste de unidade; para complet-lo foram propostos outros critrios exclusivos para variveis persistentes (variveis tabela). Dois tipos de fluxos de dados foram identificados para contemplar as associaes envolvendo definies e uso de variveis tabela. ii) Os critrios propostos, ao exigirem o uso da mesma tupla para satisfazer as associaes definio-t-uso, distinguem-se da maioria dos demais critrios de 142
teste; isto obriga o testador a escolher os dados de teste com mais cuidado e resulta, ao mesmo tempo, em um teste mais efetivo ao que se refere integridade das tabelas. iii) A dependncia de dados por variveis persistentes define uma maneira de integrar as unidades (fluxo intra-modular) e integrar os Mdulos (fluxo intermodular) podem ser estendidas para outros tipos de programas que utilizam variveis persistentes. iv) Modelos de implementao dos critrios contribuem com a gerao de uma possvel ferramenta de apoio ao teste de programas de ABDR. v) Resultados da execuo de um exemplo completo de utilizao dos critrios de teste de integrao baseados na dependncia de dados das variveis tabela mostram que os critrios so complementares e suas foras relativas so incomparveis; cada um deles enfoca aspectos distintos de programas de ABDR. Finalizando, os objetivos iniciais foram atingidos, podendo-se caracterizar
contribuies tanto no aspecto terico relativo aos fluxos de dados intra-modular e intermodular, como quanto anlise de propriedades e caractersticas dos critrios de teste que exercitam as variveis tabela, tratadas neste contexto como variveis persistentes. Quanto ao aspecto prtico, foram utilizados quatro Mdulos com dezenas de Unidades que manipulam nove tabelas da base de dados, que possibilitaram exercitar e demonstrar a aplicabilidade dos critrios em programas de ABDR. A partir desses resultados espera-se que novas atividades de pesquisas sejam desenvolvidas como expandir os critrios aqui apresentados para outras aplicaes de Banco de Dados como PL/SQL, DB2 etc, visando a tornar os critrios independentes da linguagem.
7.3 Trabalhos Futuros

As abordagens apresentadas nesta tese envolveram duas fases de teste de um programa: teste de unidade e teste de integrao. Essas fases esto distribudas e apoiadas no fluxo de dados intra-modular e no fluxo de dados inter-modular. Visando um melhor planejamento dessas fases distintas de teste, pode-se visualizar direes de pesquisas
143
futuras relevantes para a rea de teste de programas de aplicaes de Banco de Dados Relacional. A disponibilidade de uma ferramenta de suporte ao teste de programas de ABDR fundamental para as equipes de desenvolvimento de software de Banco de Dados, tendo em vista a grande quantidade de informaes que surgem nas fases de teste de software e do elevado nmero de associaes provenientes das integraes baseadas nas dependncias de dados. Sendo assim, um trabalho futuro adaptar a POKE-TOOL ou uma ferramenta similar para torn-la uma ferramenta de suporte ao teste de unidade para programas de ABDR e incluir o teste de integrao baseado nos critrios todos os t-usos e todos os dtucaminhos intra-modular e inter-modular. Outra sugesto de trabalho futuro aplicar os Fluxos de Dados intra-modular e inter-modular e seus respectivos critrios de teste que exercitam as associaes definiouso com relao s variveis persistentes, em programas escritos em linguagens de programao (PL) existentes em cada SGBDR. No caso do SGBD da Oracle existe o mdulo PL/SQL que possibilita gerar vrios programas com SQL embutida e que interagem com as tabelas da base de dados; tais programas possuem comandos semelhantes aos dos programas em C, Pascal e PL/I, tornando possvel aplicao desses critrios. Para qualquer programa que utilize varivel persistente, pode-se aplicar os conceitos bsicos desenvolvidos nesta tese para exercitar tais variveis. Atravs da adaptao dos critrios que exercitam as variveis tabela, podero ser propostos novos critrios de teste para programas que utilizam variveis com as mesmas caractersticas de uma varivel persistente. A exigncia de se utilizar a mesma tupla para definio e uso de uma varivel persistente (tabela), pode ser estudada como uma possibilidade adicional em outros critrios baseados em fluxo de dados, com o objetivo de estabelecer associaes que sejam mais rigorosas. No caso de ABDR a instrumentao das tuplas nos programas dever ser estudada visando a possibilidade de automatizar esta tarefa para o teste de integrao. Uma linha de trabalho enfocando uma tcnica bem diferente o estudo da utilizao da abordagem de anlise de mutantes para o teste de programas de ABDR. Experimentos podem ser realizados com o objetivo de estudar a aplicabilidade e a eficcia dos critrios propostos e estabelecer classes de defeitos que podem ser detectados. 144
Referncias Bibliogrficas
[ARA00] Aranha, C. M. Sistematizao para o Uso de Critrios de Testes de Banco de Dados Relacional, Tese de Doutorado em andamento, DCA/FEECUNICAMP, Campinas SP Brasil. [BEI90] Beizer, B. Software Testing Techniques, Van Nostrand Reinhold, N.Y., USA,1990. [BER62] Berge, C. Theory of Graphs and Its Applications, John Willey & Sons, N.Y, 1962. [BUD81] Budd, T. A. Mutation Analysis: Ideas, Examples, Problems and Prospects, Computer Program Testing, North-Holand Publishing Company, 1991, pp.129-148. [BUT93] Butler, B. and Canter, S., Testes de Performance: Bancos de Dados SQL, PC. Magazine Labs, Dezember 1993, pp.5-9. [CHA91] Chaim, M. L. Poke-tool Uma Ferramenta para Suporte ao Teste Estrutural de Programas Baseado em Anlise de Fluxo de Dados, Dissertao de Mestrado, DCA/FEE/UNICAMP, Campinas SP Brasil, April 1991. [CHA91a] Chaim, M. L., Maldonado, J. C. e Jino, M., Projeto / Implementao de uma Ferramenta de Teste de Software, Relatrio Tcnico DCA/RT/007/91 DCA/FEEC/UNICAMP - 1991. [CHA91b] Chaim, M. L., Maldonado, J. C. e Jino, M., Manual de Configurao da POKETOOL, Relatrio Tcnico DCA/RT/008/91 - DCA/FEEC/UNICAMP 1991. [CHA91c] Chaim, M. L., Maldonado, J. C. e Jino, M., Manual de Usurio da POKETOOL, Relatrio Tcnico DCA/RT/009/91 - DCA/FEE/UNICAMP - 1991.
145
[CHA97] Chaim, M. L., J. C. Maldonado e M. Jino, Ferramentas para Teste Estrutural de Software Baseado em Anlise de Fluxo de Dados: o caso da POKE-TOOL, Workshop do Projeto Validao e Teste de Sistemas de Operao, WPVTSO97, guas de Lindia, Janeiro, 1997. [CHA00] Chays, D., Dan, S., Frankl, P. G., Vokolos, F. and Weyuker, E. J. A Framework for Testing Database Applications, ISSTA00, ACM, Oregon, PO, pp. 147-157, 2000. [CHU87] Chusho, T., Test Data Selection and Quality Estimation Based on the Concept of Essencial Branches for Path Testing, IEEE Trans. Software Eng. Vol.13, No. 5, May 1987, pp. 509-517. [CLA89] Clarke, L. A. et al. A Formal Evaluation of Data Flow Path Selection Criteria, IEEE TSE, 15(11), pp. 1318-1332, November 1989. [COD70] Codd, E. A Relational Model for Large Shared Data Banks, CACM, June 1970. [CRU99] Cruzes, D. Gerao e Visualizao de Informaes para Suporte a Depurao e Teste de Programas, Dissertao de Mestrado, DCA/FEE/NICAMP, Campinas SP Brasil, Julho 1999. [DAT84] Date, C. A Critique of the SQL Database Language, ACM SIGMOD Record, 14-3, November 1984. [DAT90] Date, C. An Introduction to Database Systems, Fifth Edition, Vol. 1, AddisonWesley, 1990. [DAV97] Davis Application Development Methodology, Univ. of California, USA, 1997 (pesquisa via Internet). [DEL97] Delamaro, M.E.; Maldonado, J.C.; Interface Mutation: An Approach for Integration Testing, Workshop do Projeto Validao e Teste de Sistemas de Operao, guas de Lindia, Janeiro, 1997.
146
[DEL99] Delamaro, M.E. and Maldonado, J.C., "Interface Mutation: Assessing Testing Quality at Interprocedural Level", International Conference of the Chilean Computer Science Society (SCCC99), Talca - Chile, 1999. [DEM78] De Millo, R.A., Lipton, R. J. and Syward, F. G. Hints on Test Data Selection for the Practicing Programmer, Computer, April 1978. [DEM80] De Millo, R. A. Mutation Analisys as a Tool For Software Quality Assurance, in Proc. Of COMPASAC 80, Chicago-IL, October 1980. [ELM94] Elmasri, R. and Navathe, S. B. Fundamentals of Database Systems Sec. Edition, Addison Wesley, 1994. [FON93] Fonseca, R.P., Suporte ao Teste Estrutural de Programas Fortran no Ambiente POKE-TOOL, Dissertao de Mestrado, DCA/FEE/UNICAMP, Campinas, SP, Janeiro, 1993. [FRA85a] Frankl, F. G. and Weyuker, E. J., ASSET A System to Select and Evaluate Tests In Proc. Of the IEEE Conference on Software Tool, April 1985, pp. 72-79. [FRA85b] Frankl, F. G. and Weyuker, E. J., Data Flow Testing Tool, In Proc. Softfair II, San Francisco, CA, Dezember, 1985, pp. 46-53. [FRA86] Frankl, F. G. and Weyuker, E. J., Data Flow Testing in The Presence of Unexecutable Paths in Proc. Workshop on Software Testing, Banff, Canada, July 1986, pp. 4-13. [FRA87] Frankl, F. G. The Use of Data Flow Information for the Selection and Evaliation of Software Test Data Phd. Thesis, Courant Institue of Mathematical Sciences, N.Y. University, October 1987. [FRA88] Frankl, F. G. and Weyuker, E. J., An Applicable Family of Data Flow Testing Criteria, IEEE Trans. on Software Eng., Vol. 14, No. 10, October 1988, pp. 1483-1498. [FRA93] Frankl, F. G. and Weyuker, E. J., Provable Improvements on Branch Testing, IEEE Trans. on Software Eng., Vol. 19, No. 10, October 1993, pp. 962-974. 147
[GOD75] Goodenough, J. e Gerhart, S. L., Toward a Theory of Test Data Selection, IEEE Trans. on Software Eng., Vol.1, 1975. [HAN92] Hanson, E. N. Rule Condition Testing and Action Execution in Ariel- ACM SIGMOD, June 1992. [HAN95] Hanson, E. N. and all Optimized Rule Condition Testing in Ariel Using Gator Networks- National Science Foundation, October 1995. [HAR69] Harary, F. Graph Theory, Addison-Wesley, Reading, Mass. 1969. [HAR91] Harrold, M. J. and Soffa, M. L. Selecting and Using Data for Integration Testing- IEEE Software, Vol. 8, N. 2, pp.58-65, March 1991. [HAR93] Harrold, M. J. and Rothermel, G. A System for Testing and Analysis of C Programs Proc. Quality Week93, May 1993. [HAR94] Harrold, M. J. and Rothermel, G., Performing Data Flow Testing on Classes, Proc. of the 2nd ACM SIGSOFT Symposium on Foundations of Soft. Eng., Vol. 19, N. 5, Dezember 1994, pp. 154-163. [HEC77] Hecht, M. S. Flow Analysis of Computer Programs, North Holland, N.Y., 1977. [HER76] Herman, P. M. A Data Flow Analysis Approach to Program Testing Australian Computer Journal, Vol.8, N. 3, November 1976. [HET87] Hetzel, W., Guia Completo ao Teste de Software, Ed. Campus, Rio de Janeiro, 1987. [HOR88] Horwitz, S., Reps, T. and Binkley, D. Interprocedural Slicing Using Dependence Graphs, ACM SIGPLAN, Note 23, 7, July 1988, pp-10-44. [HOR91] Horgan, J.R. and London, S. Data Flow Coverage and the C Language, Fourth Symp. Soft. Testing, Analysis, and Verification, October 1991, pp. 87-97. [HOW87] Howden, W.E. Functional Program Testing and Analysis, McGraw-Hill, USA, 1987.
148
[HUA75] Huang, J. C. An Approach to Program Testing, Computing Surveys, Vol. 7, No. 3, September 1975, pp. 113-128. [ISO92] ISO/IEC 9075 - Information Technology - Database Language - SQL, Third Edition 1992(E). [KOR85] Korel, B.and Laski, J., A Tool for Data Flow Oriented Program Testing, Proc. Softfair II, San Francisco, CA, Dezember 1985, pp. 34-38. [KRO98] Kroenke, D.M., Database Processing: Fundamentals, Design, and Implementation, 6 Edio, Prentice Hall, 1998. [LAS83] Laski, J. W. and Korel, B., A Data Flow Oriented Program Testing Strategy, IEEE Trans. Software Eng., Vol. 9, No. 3, May 1983, pp. 347-354. [LEI92] Leito, P.S.J., Suporte ao Teste Estrutural de Programas Cobol no Ambiente POKE-TOOL, Dissertao de Mestrado, DCA/FEEC/UNICAMP, Campinas, SP, Agosto, 1992. [LIN90] Linnenkugel, U. and Mllerburg, M. Test Data Selection Criteria for (Software) Integration Testing, In First Intern. Conf. on Syst. Integration, pp. 709-717, Morristown, N.J., USA, April 1990. [MAL88] Maldonado, J. C.; Chaim, M. L. and Jino, M. Seleo de Casos de Testes Baseada nos Critrios Potenciais Usos, II SBES, Canela, RS, Brasil, Outubro, 1988, pp.24-35. [MAL88b] Maldonado, J. C.; Chaim, M. L. and Jino, M. Resultados do Estudo de uma Famlia de Critrios de Teste de Programas baseada em Fluxo de Dados, Relatrio Tcnico, DCA/FEE/UNICAMP RT/DCA-001/88 Campinas SP- Brasil, 1988. [MAL89] Maldonado, J. C.; Chaim, M. L. and Jino, M., Feasible Potential Uses Criteria Analysis, Relatrio Tcnico - DCA/FEE/UNICAMP RT/DCA-001/89 Campinas SP- Brasil, 1989.
149
[MAL91] Maldonado, J. C., Critrios Potenciais Usos: Uma Contribuio ao Teste Estrutural de Software, Tese de Doutorado, DCA/FEEC/UNICAMP Campinas, SP, Brasil, Julho, 1991. [MAL92] Maldonado, J. C.; Chaim, M.L.; Jino, M. - Bridging the Gap in the Presence of Infeasible Paths: Potential Uses Testing Criteria II International Conference of the SCCC, 1992, pp. 323-339. [MAN89] Manilla, H. and Rih, K.J. - Automatic Generation of Test Data for Relational Queries- Journal of Computer and System Sciences, Vol. 38, No.2, 1989, pp.240. [MAR96] Marx, D. I. S. and Frankl, P. G. The Path-Wise Approach to Data Flow Testing with Pointers Variables, In ISSTA96, February 1996. [MYE79] Myers, G.- The Art of Software Testing, Wiley, New York, 1979. [NAK97] Nakagawa, E. Y., et al, Aspectos e Implementao de Interfaces Grficas do Usurio para Ferramentas de Teste de Software, Workshop do Projeto Validao e Teste de Sistemas de Operao, WPVTSO97, guas de Lindia, Janeiro, 1997. [NTA84] Ntafos, S. C., On Required Element Testing, IEEE Trans. Software Eng., Vol. SE - 10, November 1984, pp. 795-803. [NTA88] Ntafos, S. C.,, A Comparison of Some Structural Testing Strategies, IEEE TSE, Vol. 14, No. 6, June 1988, pp. 868-873. [ORA90] Oracle Corporation, - Programmers Guide to the Oracle Precompilers - Version 1.3 - Part No. 5315 - V.1.3, Revised Dezember 1990. [OST91] Ostrand, T. J. and Weyuker, E. J. Data Flow-based Test Adequacy Analysis for Languages With Pointers, In Fourth Symp. Soft. Testing, Analysis, and Verification, October 1991, pp. 74-86. [PRE97] Pressman, R.S., Software Engineering: A Practitioners Approach, McGrawHill, 4 Ed. - New York, 1997.
150
[PRI87]
Price, A. M., Garcia, F. e Purper, C.B., Visualizando o Fluxo de Controle de Programas, in Proc. I SBES, Petrpolis, R.J., October 1987.
[RAP82]
Rapps, S.and Weyuker, E.J. Data Flow Analysis Techniques for Test Data Selection, In International Conference on Software Engineering, Tokio Japan, September 1982, pp. 272-278
[RAP85]
Rapps, S.and Weyuker, E.J. Selection Software Test Data Using Data Flow Information, IEEE, TSE, SE-11, April, 1985, pp. 367-375.
[SPO96] Spoto, E. S.; Jino, M. and Maldonado, J. C. Teste Estrutural de Software Programas de Aplicao de Banco de Dados Relacional, I Workshop de Tese e Dissertaes em Engenharia de Software SBES96, So Carlos SP, Brasil, Outubro,1996. [SPO97] Spoto, E. S.; Jino, M. and Maldonado, J. C. Teste Estrutural Baseado em Fluxo de Dados de Software Aplicativo de Banco de Dados Relacional, Workshop do Projeto Validao e Teste de Sistemas de Operao, guas de Lindia SP, Brasil, pp.163-176, Janeiro,1997. [SPO99] Spoto, E. S., Experimento de Teste Estrutural Baseado em Fluxo de Dados em Programas de Aplicao de Banco de Dados Relacional, Relatrio Tcnico, DCA/FEEC/UNICAMP Campinas SP, Julho 1999. [SPO00] Spoto, E. S.; Jino, M. and Maldonado, J. C. Teste Estrutural de Software: Uma abordagem para Aplicao de Banco de Dados Relacional, SBES00, XIV Simpsio Brasileiro de Engenharia de Software, Joo Pessoa PB, pp. 243258, Outubro 2000. [TAI96] Tai, K. C. Theory of Fault-Based Predicate Testing for computer ProgramsIEEE, TSE, Vol.22, N.8, Agosto, 1996, pp.552-562. [VIL94] Vilela, P. R., Ferramenta de Visualizao, Dissertao de Mestrado, DCA/FEE/UNICAMP, Campinas SP Brasil, Maro 1994. [VIL97] Vilela, P.R.; Maldonado, J.C. and Jino, M. Program Graph Visualization, Software-Practice and Experience, 27(11), Novembro, 1997. 151
[VIL98]
Vilela, P. R. S. Critrios Potenciais Usos de Integrao: Definio e Anlise- Tese de doutorado FEEC UNICAMP, Abril, 1998.
[ZHU96] Zhu, H. A Formal Analysis of The subsume Relational Between Software Test Adequacy Criteria- IEEE T.S.E., Vol. 22, No. 4, April 1996.. [WEY84] Weyuker, E. J., The Complexity of Data Flow Criteria for Test Data Selection, Information Processing Letters, Vol. 19, No. 2, Agosto, 1984, pp. 103-109. [WEY86] Weyuker, E. J., Axiomatizing Software Test Data Adequacy, IEEE Trans. on Software Eng. Vol. SE 12, No. 12, Dezembro, 1986, pp. 1128-1138. [WEY88] Weyuker, E. J., An Empirical Study of the Complexity of Data Flow Testing, in Proc. Of Second Workshop on Software, Verification and Analysis, Banff, Canada, Julho, 1988. [WHI87] White, Lee J., Software Testing and Verification, Advances in Computers Vol.26, Ed. Acad. Press, Inc., 1987 [YAN91] Yan, S. Y. Declarative Testing of Logic Databases-Computer Mathematical Vol.22, N.11, 1991, pp.39-45.
152
APNDICE A A Ferramenta POKE-TOOL

Neste apndice apresentada uma sntese da ferramenta POKE-TOOL descrita com detalhes em [CHA91a, CHA91b, CHA91c, CHA91]. A POKE-TOOL (Potential Uses Criteria Tool for Program Testing) [MAL89, CHA91] foi desenvolvida na Faculdade de Engenharia Eltrica e de Computao da Universidade Estadual de Campinas FEEC/UNICAMP. Essa ferramenta apia a aplicao dos critrios Potenciais-Usos e de outros critrios estruturais como Todos-Ns e Todos-Arcos. Inicialmente, foi desenvolvida para o teste de unidade de programas escritos em C [CHA91], mas atualmente, devido sua caracterstica de multi-linguagem, j existem configuraes para o teste de programas em Cobol e FORTRAN [LEI92, FON93]. A POKE-TOOL uma ferramenta interativa cuja operao orientada para sesso de trabalho. Nesta, o usurio realiza todas as tarefas de teste: anlise esttica da unidade a ser testada; preparao para o teste; submisso de casos de teste; avaliao e gerenciamento dos resultados de teste. Na POKE-TOOL, a sesso de trabalho dividida em duas fases: a fase esttica e a fase dinmica [CHA97]. Na fase esttica, a ferramenta analisa o cdigofonte, obtm as informaes necessrias para a aplicao dos critrios e instrumenta o cdigo-fonte, inserindo pontas de prova (instrues de escrita que produzem um trace do caminho executado), gerando nova verso (verso instrumentada) da unidade em teste, que viabiliza uma posterior avaliao da adequao de um dado conjunto de casos de teste. Ao trmino dessa fase, a POKE-TOOL apresenta, por solicitao do usurio, entre outras coisas, o conjunto de caminhos requeridos pelo critrio todos-potenciais-du-caminhos e o conjunto de associaes requeridas pelo critrio todos-potenciais-usos e todos-potenciaisusos/du. A partir dessas informaes, o usurio pode projetar seus casos de teste a fim de que os mesmos executem os caminhos ou associaes exigidas. A fase dinmica consiste do processo de execuo e avaliao de casos de teste. Antes de executar os casos de teste, porm, necessrio que o programa executvel seja gerado, a partir da verso instrumentada da unidade a ser testada. Aps a execuo dos casos de teste, a POKE-TOOL realiza a avaliao destes de acordo com um dos trs 153
critrios Potenciais Usos. O resultado da avaliao um conjunto de caminhos ou associaes que restam ser executados para satisfazer os critrios e o percentual de cobertura do conjunto de casos de teste. Nesta fase, a ferramenta fornece tambm o conjunto de caminhos ou associaes que foram executados, as entradas e sadas, bem como os caminhos percorridos em cada um dos casos de teste. O processo de execuo/avaliao deve continuar at que todos os caminhos ou associaes restantes tenham sido satisfeitos, ou seja, tenham sido executados ou tenha sido detectada a sua no executabilidade. O usurio pode interromper a sesso de trabalho sem que tenha atingido uma das situaes anteriores. Nesse caso, a POKE-TOOL fornece meios para a interrupo da sesso, armazenamento dos dados gerados e do estado da ferramenta at aquele momento, e permite a recuperao da sesso de trabalho e o recomeo dos testes. Assim, a POKE-TOOL recebe como entrada um programa escrito em linguagem de programao (no caso da primeira verso da ferramenta, um programa escrito em C), um conjunto de casos de teste e a seleo de um dos critrios (todos-potenciais-usos, todospotenciais-usos/Du, todos-potenciais-du-caminhos, todos-ns e todos-arcos). A estrutura da POKE-TOOL est baseada na composio de vrios mdulos que se comunicam atravs de arquivos e implementam as funes ou partes das funes descritas acima, realizando o processo de teste de forma a garantir a qualidade requerida para o mesmo. Na Figura A1 [CHA91], apresentado um diagrama contendo os mdulos e os diversos produtos gerados pela ferramenta. No diagrama apresentado na Figura A1, os retngulos representam os mdulos, os losangos representam as entradas fornecidas pelos usurios ferramenta, os crculos representam os produtos gerados, as linhas tracejadas representam o fluxo de controle e as linhas cheias representam o fluxo de informao.
154
O mdulo Poketool (interface) responsvel pela comunicao entre a ferramenta e o usurio e pela seqenciao das atividades de teste atravs da ativao dos demais mdulos. O mdulo LI realiza a traduo da unidade em teste para a unidade escrita na
POKETOOL (Interface)
Unidade em teste na linguagem fonte Entrada do caso de teste
Critrio
li
chanomat
pokernel
gera executvel
executa caso de teste
avaliador
grafo Def
programa executvel
caminho executado
cam. ou associac. restantes
cam. ou associac. restantes
unidade em LI
unidade instrumentada
sada do caso de teste
cam. ou associac. executados
grafo de fluxo de controle
arcos primitivos
entrada do caso de teste
anlise de cobertura
grafo(i)
descritores
cam. e assoc. requeridas
Figura A1: Projeto da Ferramenta POKE-TOOL
linguagem intermediria (LI). Possui como entrada a unidade em teste e como sada a unidade em LI [CHA91]. A linguagem intermediria tem como funo principal identificar 155
o fluxo de execuo em um programa. Assim, a LI tem dois tipos de comandos principais: comandos seqenciais e comandos de controle de fluxo. Os comandos seqenciais da LI indicam os comandos das linguagens procedurais que representam uma declarao ou computao do valor da varivel (comandos de atribuio ou chamadas de procedimentos) e que, portanto, no alteram o fluxo de execuo. Os comandos de controle de fluxo da LI so equivalentes aos comandos das linguagens procedurais que causam seleo, seleo mltipla, iterao e transferncia incondicional. O mdulo Chanomat gera o GFC (Grafo de Fluxo de Controle) da unidade em teste. Possui como entrada a unidade em LI e como sadas unidade em LIA1 e o GFC. O mdulo Pokernel responsvel pela anlise esttica do cdigo-fonte. Possui como entradas a unidade em teste, a unidade em LI numerada (Unidade na linguagem intermediria com os ns onde cada comando est relacionado) e o GFC e como sadas o grafo def (mostra quais ns tm definio e referncia a variveis, e quais so elas), a unidade instrumentada (unidade modificada contendo as pontas de prova), os arcos primitivos (Arcos dentro do GFC que so sempre executados quando um outro arco executado), e os caminhos e associaes requeridas para cada critrio de teste. O mdulo Gera Executvel fornece ao usurio condies para gerao da unidade executvel da verso instrumentada e engloba a funo seleo de compilador. Possui como sada o cdigo-executvel. O mdulo Executa Caso de Teste controla a execuo dos casos de testes, salvando as entradas, sadas e o caminho executado para cada caso de teste. Possui como entradas o cdigo-executvel e os casos de testes e como sadas os caminhos executados pelos casos de testes, as sadas e a entrada dos casos de testes. O mdulo Avaliador verifica quais caminhos ou associaes so executadas pelos casos de testes e fornece uma anlise de cobertura do conjunto de casos de testes fornecido. Gera ainda relatrios com as informaes de potenciais-du-caminho executados e no executados, ns executados e no executados para o critrio todos-ns, arcos executados e
A1
Unidade em LI onde cada n do GFC est relacionado com seus respectivos comandos na unidade em teste.
156
no executados para o critrio todos-arcos e associaes executadas e associaes no executadas para o critrio Potenciais Usos. A POKE-TOOL encontra-se disponvel para os ambientes DOS e UNIX. A verso para DOS possui interface simples, baseada em menus, A verso para UNIX possui mdulos funcionais cuja utilizao se d atravs de interface grfica [NAK97] ou linha de comandos(shell scripts). As modificaes a serem executadas na ferramenta POKE-TOOL passam por duas etapas distintas. A primeira etapa a incluso da LI para os comandos da SQL. Nesta etapa o mdulo LI ser modificado para o mdulo denominado LIBD, onde o novo mdulo LIBD ir conter a mesma LI anterior acrescida da LI dos comandos de SQL. A modificao do mdulo LI para LIBD reflete automaticamente na modificao do mdulo Chanomat ocasionando os arquivos LI e grafo de fluxo de controle j incluindo os comandos de SQL. A segunda etapa se refere modificao do mdulo Pokernel que a partir dos arquivos LI e grafo_def gerados pelo mdulo Chanomat gerado o novo programa-fonte instrumentado (j com os comandos de SQL) e os demais arquivos que so gerados pelo mdulo Pokernel j incluindo as informaes dos comandos de SQL e variveis host e variveis tabela. Nesta etapa gerado o arquivo tabvardef.tes que contm todas as variveis que so definidas em cada n do grafo. A partir deste arquivo so gerados os descritores para os critrios da FCPU. Com essas modificaes possvel executar a etapa de teste de unidade para os critrios Potenciais Usos. Na etapa de teste de integrao, ser necessria a construo de novos mdulos a fim de atender as necessidades dos critrios de teste de integrao estudados nesta tese. Essas modificaes sero nossos principais temas de estudos futuros, visando a elaborao de uma ferramenta que organize e auxilie o teste de integrao para aplicaes de Banco de Dados Relacional, aplicando os critrios estudados nesta tese.
157
POKETOOLBD (Interface)
Unidade em teste na Linguagem fonte
LIBD
Chanomat
Pokernel
Idem
Grafo Def . c/ SQL
Caminhos ou Associaes restantes
Unidade com SQL em LI
Unidade Instrumentada
Grafo de Fluxo de Controle G(UP)
Arcos Primitivos
Grafo(i)
Descritores
Cam. e assoc. requeridas
Figura A2: Apresenta uma proposta de modificao do projeto da ferramenta POKETOOL para atender programas de ABDR na etapa de teste de unidade.
158
APNDICE B Comandos de SQL

Nesta seo so apresentados os comandos de SQL estudados e aplicados no desenvolvimento desta tese. Apesar da existncia de vrios Sistemas Gerenciadores de Banco de Dados Relacional, observe que, em grande parte desses sistemas so usados comandos de SQL considerados padro, existindo assim, pouca distino entre eles. A Figura B1 apresenta um conjunto de comandos de SQL embutida agrupados pelo tipo que cada comando exerce na ABDR. Inicialmente, so apresentados os comandos declarativos e em seguida os comandos executveis. Os comandos executveis so divididos em duas classes de comandos sendo comandos de definio de dados e comandos de manipulao de dados (DDL e DML). Os comandos que compem a DDL so divididos da seguinte maneira: para definio de dados e para acesso de controle de dados. Os comandos que compem a DML so divididos em comandos de manipulao de dados, comandos de recuperao de dados, comandos para processo de transao de dados e para uso de SQL dinmica. Os comandos que possuem um * so apropriados para o modo interativo (SQLPLUS). Eles so comandos prprios para SQL embutida em programas hospedeiros (C, Pascal, Ada etc). Os principais comandos que foram considerados neste trabalho sero apresentados com mais detalhes a seguir. Esses comandos so facilmente encontrados em livros de Banco de Dados. Outros comandos podem ser includos no futuro se houver necessidades. No Sistema Gerenciador de Banco de Dados da Oracle os comandos SQL podem ser utilizados tanto nos mdulos de PL/SQL como, embutidos nos programas de ABDR. Para o caso de programas de ABDR existem pr-compiladores para transformarem os programas com os comandos de SQL para um programa na linguagem hospedeira. No caso da linguagem C o programa inicialmente escrito com a extenso pc e em seguida transformado na extenso c.
159
Apndice B: Comandos de SQL
DECLARATIVE BEGIN DECLARE SECTION * END DECLARE SECTION * DECLARE * INCLUDE * WHENEVER * Para declarar as variveis host
Para declarar objetos Para reas de comunicao Para tratamento de erros

EXECUTABLE Definio de Dados
ALTER CREATE DROP RENAME CONNECT GRANT LOCK TABLE REVOKE Manipulao de Dados DELETE INSERT UPDATE CLOSE* FETCH* OPEN* SELECT COMMIT ROLLBACK SAVEPOINT SET TRANSACTION DESCRIBE* EXECUTE* PREPARE*
Para definio de dados
Para controlar acesso aos dados
Para manipular dados
Para recuperar dados
Para processar transaes
Para uso de SQL dinmico
Figura B1: Comandos da SQL embutida, agrupados por tipos. Os comandos com * no existem no modo interativo.
As variveis host so as chaves de comunicao entre a linguagem hospedeira e a Base de Dados. Uma varivel host pode ser declarada da mesma maneira que as demais variveis existentes no programa e compartilhada com os atributos das tabelas da base de dados. As variveis host so usadas tanto para levar valores do programa para as tabelas, 160
como trazer os valores das tabelas para o programa, por isso so tambm conhecidas como variveis de ligao. A nica restrio que as variveis host devem ser pr-fixadas com : quando forem referenciadas nos comandos de SQL. No programa hospedeiro pode ser usada em qualquer expresso como as variveis programa. Outras caractersticas referentes varivel host podem ser encontradas nos SGBDRs existentes no mercado. COMANDOS DE SQL EMBUTIDA A seguir apresentaremos os principais comandos utilizados em programas de Aplicao. Lembre que os comandos de definio de dados no so apresentados abaixo por considerar que esses comandos so utilizados antes da implementao da Aplicao. Marca o incio do diagrama Marca o final do diagrama Mostra que o diagrama continua na linha abaixo Mostra a continuao do diagrama da linha de cima Representa um lao
COMANDOS DECLARATIVOS: WHENEVER

EXEC SQL WHENEVER NOT FOUND SQLERROR SQLWARNING
CONTINUE GOTO <label_name> STOP DO <funo>
Ex:
EXEC SQL WHENEVER NOT FOUND CONTINUE; EXEC SQL WHENEVER SQLERROR GOTO parar;
161
EXEC SQL WHENEVER SQLWARNING STOP; EXEC SQL WHENEVER SQLERROR DO func_parar(); DECLARE CURSOR
EXEC SQL AT db_name
DECLARE
Cursor_name
CURSO
FOR
subquery
statement_name
block_name
Ex: EXEC SQL DECLARE emp_cursor CURSOR FOR SELECT ENAME, EMPNO, JOB, SAL FROM EMP WHERE DEPTNO = :deptno FOR UPDATE OF SAL;
DECLARE DATABASE EXEC Ex: EXEC SQL DECLARE oracle3 DATABASE; DECLARE STATEMENT EXEC
AT db_name DECLARE db_name DATABASE ;
DECLARE
statement_nam
block_name
STATEMENT
162
Ex: EXEC SQL AT remote_db DECLARE sql_stmt STATEMENT; EXEC SQL PREPARE my_statement FROM :my_string; EXEC SQL EXECUTE :my_statement; DECLARE TABLE EXEC
DECLARE table_name TABLE
column_name
datatype
column_specs
Onde o padro column_specs tem a seguinte sintaxe:
DEFAUT
expression
NULL NOT NULL
NOT NULL WITH DEFAULT
Ex: EXEC SQL DECLARE PARTS TABLE ( PARTNO BIN QTY NUMBER NOT NULL, NUMBER, NUMBER); COMANDOS EXECUTVEIS CLOSE EXEC Ex: EXEC SQL CLOSE emp_cursor; COMMIT EXEC
AT db_name COMMIT WORK RELEASE CLOSE cursor_name
Ex: 163
EXEC SQL AT sales_db COMMIT RELEASE; EXEC SQL COMMIT;
CONNECT EXEC
CONNECT :username :username_password IDENTIFIED BY :password
;
USING AT db_name :db_string
Ex: EXEC SQL CONNECT :userrid; EXEC SQL CONNECT :username IDENTIFIED BY :password; CREATE TABLE
schema EXEC SQL CREATE TABLE
table_name
DEFAUT column
expr
column_ref clause
column_constraint
datatype )
(
table_coinstraint table_ref_clause
Ex: EXEC SQL CREATE TABLE table_name (empno NUMBER NOT NULL, .., deptno VARCHAR(2) constraint nn_deptno NOT NULL CONSTRAINT fk_deptno REFERENCES scott.dep (deptno) );
164
DESCRIBE EXEC
DESCRIBE BIND VARIABLES FOR
SELECT LIST FOR statement_name INTO descriptor_name
block_name
Ex: EXEC SQL PREPARE my_statement FROM :my_string; EXEC SQL DECLARE emp_cursor FOR EXEC SQL DESCRIBE BIND VARIABLES FOR my_statement INTO bind_descriptor; EXEC SQL OPEN emp_cursor USING EXEC SQL DESCRIBE SELECT LIST FOR my_statement INTO select_decriptor; EXECUTE EXEC
AT db_name FOR :host_integer
EXECUTE
statement_name block_name
; , USING :host_variable :indicator descriptor_name
DESCRIPTOR
Ex: 165
EXEC SQL PREPARE my_statement FROM :my_string; EXEC SQL EXECUTE my_statement USING :my_var; EXECUTE IMMEDIATE
EXEC SQL AT db_name
EXECUTE IMMEDIATE
:host_string
string_literal
Ex: set my_string = DELETE FROM EMP WHERE EMPNO = 2055; EXEC SQL EXECUTE IMMEDIATE :my_string; ou EXEC SQL EXECUTE IMMEDIATE DELETE FROM EMP WHERE EMPNO = 2055;
FETCH
EXEC
FOR :host_integer
FETCH
cursor_name
, INTO :host_variable :indicator descriptor_name
USING DESCRIPTOR
Ex: EXEC SQL FETCH emp_cursor INTO :empno, :ename;
166
FOR
:host_integer
FOR
Ex: EXEC SQL FOR :limit FETCH emp_cursor INTO ; Set limit = 10; EXEC SQL FOR :limit DELETE FROM EMP WHERE ENAME = :ename_array AND JOB= :job_array; OPEN EXEC
FOR :host_integer OPEN cursor_name
;
, USING :host_variable :indicator
DESCRIPTOR
descriptor_name
O exemplo abaixo ilustra o uso do comando OPEN: EXEC SQL DECLARE emp_cursor CURSOR FOR SELECT ENAME, EMPNO, JOB, SAL FROM EMP WHERE DEPTNO = :deptno; EXEC SQL OPEN emp_cursor;
167
PREPARE EXEC
PREPARE
statement_name
block_name :host_string
FROM
string_literal
Ex: EXEC SQL PREPARE my_statement FROM :my_string; EXEC SQL EXECUTE my_statement; ROLLBACK EXEC
AT db_name ROLLBACK WORK
;
TO SAVEPOINT savepoint_name RELEASE
O exemplo abaixo ilustra o uso do comando ROLLBACK: EXEC SQL ROLLBACK TO SAVEPOINT point4;
SAVEPOINT EXEC
AT db_name SAVEPOINT savepoint_name
O exemplo abaixo ilustra o uso do comando SAVEPOINT: EXEC SQL SAVEPOINT savepoint_name;
168
INSERT EXEC
AT db_name FOR :host_integer
INSERT INTO
table_name
,
( , VALUES ( subquery value ) ; column_name )
Em caso de utilizar valores (VALUES) atravs das variveis host a sintaxe seria a seguinte:
:host_variable :indicator
expression
literal
Os exemplos abaixo ilustram o uso do INSERT: EXEC SQL INSERT INTO EMP (ENAME, EMPNO, SAL) VALUES (:ename, :empno, :sal); EXEC SQL INSERT INTO NEW_EMP (ENAME, EMPNO, SAL) SELECT ENAME, EMPNO, SAL FROM EMP WHERE DEPTNO= :deptno;
169
DELETE
EXEC
ATdb_name FOR :host_integer
DELETE
FROM
table_name alias
;
WHERE search_condition CURRENT OF cursor_name
Os exemplos a seguir mostram os usos do comando DELETE:
EXEC SQL DELETE FROM EMP WHERE DEPTNO = :deptno AND JOB = :job; EXEC SQL DECLARE emp_cursor CURSOR FOR SELECT EMPNO, COMM FROM EMP WHERE DEPTNO= :dept_number FOR UPDATE OF COMM; EXEC SQL OPEN emp_cursor;
EXEC SQL FETCH emp_cursor INTO :emp_number, :commission; EXEC SQL DELETE FROM EMP
WHERE CURRENT OF emp_cursor;
170
UPDATE
EXEC
At db_name table_name alias FOR :host_integer
UPDATE
, SET ( column_name ) = (
, value ( subquery ) , )
column_name
value ( subquery )
;
WHERE search_condition CURRENT OF cursor_name
Os exemplos abaixo ilustram o uso do comando UPDATE:
EXEC SQL UPDATE EMP SET SAL = :sal, COMM = :comm WHERE ENAME = :ename;
EXEC SQL UPDATE EMP SET SAL, COMM = (:sal, :comm.) WHERE ENAME = :ename;
EXEC SQL UPDATE EMP SET SAL, COMM = (SELECT SAL*1.1, COMM*1.1 FROM EMP); EXEC SQL UPDATE DEPT SET EMPCNT = (SELECT COUNT (*) FROM EMP WHERE EMP.DEPTNO = DEPT.DEPTNO); 171
SELECT EXEC At SELECT ALL

DISTINCT
FOR , , column_name alias expression ,
:host integer
INTO
:host_variable :indicator
,
FROM table_name alias
WHERE
search_condition
172
CONNECT BY
condition START WITH condition
, GROUP BY expression HAVING condition
UNION INTERSECT MINUS
subquery
,
ORDER BY expression ASC position DESC
, FOR UPDATE OF column_name NOWAIT
O seguinte exemplo ilustra o uso do SELECT: EXEC SQL ENAME, SAL+100, JOB INTO :ename, :sal, :job FROM EMP WHERE EMPNO = :empno;
173
174
APNDICE C
Um Exemplo Completo das etapas de integrao intra-modular e inter-modular. Os exemplos realizados nesta tese so compostos por quatro programas em C com comandos de SQL e com uma base de dados composta por (09) nove tabelas. A ilustrao dos critrios, atravs de exemplos, resultou em um relatrio de 147 pginas. Para mostrar os resultados dos critrios de integrao intra-modular e intermodular, apresentado um exemplo completo envolvendo algumas tabelas utilizadas no exemplo da aplicao. Inicialmente apresentou-se partes do programa Mod3.pc j instrumentado. A Figura C1 mostra um quadro geral das Unidades existentes neste
Main
InsFinc
DelFinc
UpdFinc
InsEmp
DelEmp
UpdEmp
InsDep
DelDep
UpdDe
InsSal
DelSal
UpdSal
InsFind
DelFind
UpdFind
SelEmp Seldep
SelSal
SelFin C1
Figura C1: Quadro geral do programa Modulo3.pc utilizado no exemplo
175
Apndice C: Um Exemplo Completo das etapas de integrao
programa. Para ilustrar o exemplo so apresentadas as principais Unidades que envolvem a tabela DEPARTMENT. Em seguida mostrado o arquivo que armazena os elementos requeridos pelo critrio todos-t-usos-ciclo1-intra.
#define ponta_de_prova(num) if(++printed_nodes % 10) fprintf(path," %2d ",num);\ else fprintf(path," %2d\n",num); #include #include #include #include <stdio.h> <string.h> <stdlib.h> <curses.h> */
/* Declarando estrutura referente a tabela DEPARTMENT typedef struct {char d_dept_id [11]; char d_dept_name[40]; char d_manager_id[11]; }RECORD3;
EXEC SQL BEGIN DECLARE SECTION; int h1,he1, he2, he5,hso1,hso2,hso6,hd1,hd3,hfd4; VARCHAR h2[15],h3[20],h4[35],h5[20],h6[2],he3[20],he4[20],he6[40], he7[20],he8[4],he9[10],he10[10],he11[1],he12[11],he17[1], he18[1],he19[1],he20[1],hd2[40],hso4[11],hso5[7],hfc1[4], hfc2[10],hfc3[50],hfd2[7],hfd3[5]; char he14[12], he15[12], he16[12],hfd1[5], hso3[12]; float he13; EXEC SQL END DECLARE SECTION; EXEC SQL INCLUDE sqlca; EXEC SQL BEGIN DECLARE SECTION; int mhp1,mhsi1,mhd1,mhe1,mhc1,mhso1; char mhfd1[5]; VARCHAR mhfd2[7], mhfd3[5], mhfc1[4]; EXEC SQL END DECLARE SECTION; char me_emp_id[11], mso_id[11], md_dept_id[11], mfc_code[7], mfd_year[6], mfd_quarter[5], mfd_code[7], mp_prod_id[11], msi_id[11], mc_cust_id[11]; . . . int insdep (line3) RECORD3 *line3; /* 1 */ { FILE * path = fopen("insdep/path.tes","a"); FILE * key = fopen("insdep/key.tes","a"); static int printed_nodes = 0; ponta_de_prova(3003); ponta_de_prova(1); /* 1 */ hd1 = atoi (line3->d_dept_id); mhd1=hd1; /* 1 */ hd3 = atoi (line3->d_manager_id); /* 1 */ strcpy (hd2.arr, line3->d_dept_name); /* 1 */ hd2.len = strlen (hd2.arr); /* 1 */ EXEC SQL WHENEVER SQLERROR GOTO end3; ponta_de_prova(2); mhd1=hd1; /* INSERT, DELETE, UPDATE */ itoa(mhd1,md_dept_id); /* int para char */
176
fprintf(key, "DEPARTMENT: %s /* 2 */ EXEC SQL INSERT INTO DEPARTMENT ( dept_id, dept_name, manager_id ) VALUES ( :hd1, :hd2, :hd3 );
\n",md_dept_id);
/* /*
3 */ 4 */
ponta_de_prova(3); EXEC SQL COMMIT; end3: ponta_de_prova(4); ponta_de_prova(5);
/* /*
fclose(path); fclose(key); 4 */ return (sqlca.sqlcode); 5 */ }
. . . int deldep (line3) RECORD3 *line3; /* 1 */ { FILE * path = fopen("deldep/path.tes","a"); FILE * key = fopen("deldep/key.tes","a");
/* /* /*
1 */ 1 */ 1 */
/*
2 */
/* /*
3 */ 4 */
/* /*
4 */ 5 */
static int printed_nodes = 0; ponta_de_prova(3008); ponta_de_prova(1); hd1 = atoi (line3->d_dept_id); hd3 = atoi (line3-> d_manager_id); EXEC SQL WHENEVER SQLERROR GOTO end8; ponta_de_prova(2); mhd1=hd1; /* INSERT, DELETE, UPDATE */ itoa(mhd1,md_dept_id); /* int para char */ fprintf(key, "DEPARTMENT: %s \n",md_dept_id); EXEC SQL DELETE FROM DEPARTMENT WHERE dept_id = :hd1 AND manager_id = :hd3; ponta_de_prova(3); EXEC SQL COMMIT; end8: ponta_de_prova(4); ponta_de_prova(5); fclose(path); fclose(key); return (sqlca.sqlcode); }
. . . int upddep (line3) RECORD3 *line3; /* 1 */ { FILE * path = fopen("upddep/path.tes","a"); FILE * key = fopen("upddep/key.tes","a"); static int printed_nodes = 0; ponta_de_prova(3013); ponta_de_prova(1); /* 1 */ hd1 = atoi (line3-> d_dept_id); /* 1 */ strcpy (hd2.arr, line3->d_dept_name); /* 1 */ hd2.len = strlen (hd2.arr); /* 1 */ hd3 = atoi (line3-> d_manager_id); /* 1 */ EXEC SQL WHENEVER SQLERROR GOTO end13;
177
ponta_de_prova(2); mhd1=hd1; /* INSERT, DELETE, UPDATE */ itoa(mhd1,md_dept_id); /* int para char */ fprintf(key, "DEPARTMENT: %s \n",md_dept_id); EXEC SQL UPDATE DEPARTMENT SET dept_name = :hd2, manager_id = :hd3 WHERE dept_id = :hd1; ponta_de_prova(3); EXEC SQL COMMIT; end13: ponta_de_prova(4); ponta_de_prova(5); fclose(path); fclose(key); return (sqlca.sqlcode); }
/*
*/
/* /*
3 4
*/ */
/* /*
4 */ 5 */
. . . int seldep (line3) RECORD3 *line3; /* 1 */ { FILE * path = fopen("seldep/path.tes","a"); FILE * key = fopen("seldep/key.tes","a"); static int printed_nodes = 0; /* 1 */ char string[50]; /* 1 */ EXEC SQL BEGIN DECLARE SECTION; int field; int cod_dep_value, cod_ger_value; VARCHAR nome_value [40]; EXEC SQL END DECLARE SECTION; ponta_de_prova(3018); ponta_de_prova(1); /* 1 */ EXEC SQL WHENEVER SQLERROR GOTO end18; /* 1 */ printf(" \n 1-Codigo do DEPARTMENT 2- Codigo_gerente do Dept. 3Nome_DEPARTMENT"); /* 1 */ gets (string); /* 1 */ field = atoi (&string[0]); /* 1 */ switch(field) /* 1 */ { /* 2 */ case 1 : /* 2 */ { ponta_de_prova(2); /* 2 */ printf ("\n Digite o codigo da DEPARTMENT: "); /* 2 */ gets (line3->d_dept_id); /* 2 */ cod_dep_value = atoi (line3->d_dept_id); ponta_de_prova(3); fprintf(key, "DEPARTMENT (dept_id): %s \n ",line3->d_dept_id); /* 3 */ EXEC SQL SELECT dept_id, TO_CHAR(dept_id), dept_name, TO_CHAR(manager_id) INTO :mhd1, :hd1, :hd2, :hd3 FROM DEPARTMENT WHERE dept_id = :cod_dep_value; itoa(mhd1,md_dept_id); /* int para char */ fprintf(key, "Resultado: %s \n",md_dept_id); ponta_de_prova(4); /* /* 4 */ 4 */ break; }
178
/* /* /* /* /*
5 */ 5 */ 5 */ 5 */ 5 */
case 2 : { ponta_de_prova(5); printf ("\n Digite Codigo do Gerente do DEPARTMENT:"); gets (line3->d_manager_id); cod_ger_value = atoi (line3->d_manager_id); ponta_de_prova(6);
fprintf(key, "DEPARTMENT (manager_id): /* 6 */
%s
\n ",line3->d_manager_id);
EXEC SQL SELECT dept_id, TO_CHAR(dept_id), dept_name, TO_CHAR(manager_id) INTO :mhd1, :hd1, :hd2, :hd3 FROM DEPARTMENT WHERE manager_id = :cod_ger_value; itoa(mhd1,md_dept_id); /* int para char */ fprintf(key, "Resultado: %s \n",md_dept_id); ponta_de_prova(7); break; } case 3 : { ponta_de_prova(8); printf ("\n Digite o Nome do DEPARTMENT:"); gets (line3->d_dept_name); strcpy (nome_value.arr, line3->d_dept_name); nome_value.len = strlen (nome_value.arr); ponta_de_prova(9); fprintf(key, "DEPARTMENT (dept_name): %s \n ",line3->d_dept_name);
/* /* /* /* /* /* /* /*
7 7 8 8 8 8 8 8
*/ */ */ */ */ */ */ */
/*
9 */
EXEC SQL SELECT dept_id, TO_CHAR(dept_id), dept_name, TO_CHAR(manager_id) INTO :mhd1, :hd1, :hd2, :hd3 FROM DEPARTMENT WHERE dept_name = :nome_value; itoa(mhd1,md_dept_id); /* int para char */ fprintf(key, "Resultado: %s \n",md_dept_id); ponta_de_prova(10); break; } default: { ponta_de_prova(11); printf("\n Codigo errado : "); sqlca.sqlcode=-1; } } ponta_de_prova(12); if(sqlca.sqlcode == 0) { ponta_de_prova(13); if(sqlca.sqlerrd[2] == 1) { ponta_de_prova(14);
/* /* /* /* /* /* /* /*
10 10 11 11 11 11 11 12
*/ */ */ */ */ */ */ */
/* 12 */ /* 13 */ /* 13 */ /* 14 */
179
/* /* /* /*
14 14 14 14
*/ */ */ */ }
itoa(hd1, line3->d_dept_id); hd2.arr [hd2.len] = \0; strcpy (line3->d_dept_name, hd2.arr); itoa(hd3, line3->d_manager_id);
/* 14 */ /* 15 */
ponta_de_prova(15); }
/* 16 */ end18: ponta_de_prova(16); ponta_de_prova(17); fclose(path); fclose(key); /* 16 */ return (sqlca.sqlcode); /* 17 */ } . . . main () /* 1 */
{ FILE * path = fopen("main/path.tes","a"); static int printed_nodes = 0; int cod_ret, field, transacao, temp; char string[50], strfield[4]; RECORD linha; RECORD2 linha2; RECORD3 linha3; RECORD4 linha4; RECORD5 linha5; RECORD6 linha6; ponta_de_prova(3000); ponta_de_prova(1); cod_ret = dbconn(); if(cod_ret == 0) { ponta_de_prova(2); printf (" \n digite a transacao: {I, D, U, S}-> "); gets(string); transacao = string[0]; transacao=tolower(transacao); switch(transacao) { case i : { ponta_de_prova(3); printf(" \n Inserir 1- Empr 2- Vendas 3-Depart 4-Codigo-fin 5-Data-fin : "); gets (strfield); field = atoi (&strfield); switch(field) { case 1: { ponta_de_prova(4); printf (" \n Digite o codigo do Empregado: "); cod_ret = insemp (&linha); if( cod_ret == 0) { ponta_de_prova(5); printf ("Inclusao efetuada EMPLOYEE\n"); } ponta_de_prova(6); break; } case 2: { ponta_de_prova(7); printf (" \n Digite o codigo da Venda: ");
/*
1 */
/* /* /* /* /* /*
1 1 1 1 1 1
*/ */ */ */ */ */
/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* . . /* /* /* /* /* /* /* /* /* /*
1 */ 1 */ 2 */ 2 2 2 2 2 2 3 3 3 3 3 3 3 4 4 4 . 4 4 5 */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */
5 */ 5 */ 6 6 7 7 */ */ */ */
7 */
180
. . /* /* /* /* /*
. 7 */ 7 */ 8 */ 8 */ 8 */
/* 9 */ /* 9 */ /* 10 */ /* 10 */ /* /* /* /* /* /* /* /* /* 10 10 10 10 10 10 10 10 11 */ */ */ */ */ */ */ */ */
cod_ret = inssal (&linha2); if( cod_ret == 0) { ponta_de_prova(8); printf ("Inclusao efetuada SALES_ORDER\n"); } ponta_de_prova(9); break; } case 3: { ponta_de_prova(10); printf (" \n Digite o codigo do DEPARTMENT: "); gets (linha3.d_dept_id); printf (" \n Digite o nome do DEPARTMENT: "); gets (linha3.d_dept_name); printf (" \n Digite o codigo empregado do DEPARTMENT: "); gets (linha3.d_manager_id); cod_ret = insdep (&linha3); if( cod_ret == 0) { ponta_de_prova(11); printf ("Inclusao efetuada DEPARTMENT\n"); } ponta_de_prova(12); break; } case 4: { ponta_de_prova(13); printf (" \n Digite o codigo do financ. de Venda: "); cod_ret = insfinc(&linha4); if( cod_ret == 0) { ponta_de_prova(14); printf ("Inclusao efetuada FIN_CODE\n"); } ponta_de_prova(15); break; } case 5: { ponta_de_prova(16); printf (" \n Digite o Ano da data de Financ: "); gets (linha5.fd_year); gets (linha5.fd_amount); cod_ret = insfind (&linha5); if( cod_ret == 0) { ponta_de_prova(17); printf ("Inclusao efetuada FIN_DATE\n"); } ponta_de_prova(18); } } ponta_de_prova(19); break; } case u : { ponta_de_prova(20); printf(" \n Atualizar 1- Empregado gets (strfield); field = atoi (&strfield); switch(field) {
/* 11 */ /* 11 */ /* /* /* /* 12 12 13 13 */ */ */ */ */ */ */ */
/* 13 . . . /* 13 /* 13 /* 14
/* 14 */ /* 14 */ /* /* /* /* 15 15 16 16 */ */ */ */ */ */ */ */ */ */
/* 16 /* 16 . . . /* 16 /* 16 /* 16 /* 17
/* 17 */ /* 17 */ /* 18 */ /* 19 */ /* /* /* /* 19 19 20 20 */ */ */ */
/* 20 */ fin: "); /* 20 */ /* 20 */ /* 20 */ /* 20 */
2- Vendas 3-DEPARTMENT 4-Codigo-fin 5-Data-
181
/* 21 */ /* 21 */ /* 21 /* 21 . . . /* 21 /* 21 /* 22 */ */ */ */ */
case 1: { ponta_de_prova(21); printf (" \n Digite o codigo do Empregado: "); gets (linha.e_emp_id); cod_ret = updemp (&linha); if( cod_ret == 0) { ponta_de_prova(22); printf ("Atualizacao efetuada EMPLOYEE\n"); } ponta_de_prova(23); break; } case 2: { ponta_de_prova(24); printf (" \n Digite o codigo da Venda: "); gets (linha2.s_id); cod_ret = updsal (&linha2); if( cod_ret == 0) { ponta_de_prova(25); printf ("Atualizacao efetuada SALES_ORDER\n"); } ponta_de_prova(26); break; } case 3: { ponta_de_prova(27); printf (" \n Digite o codigo do DEPARTMENT: "); gets (linha3.d_dept_id); printf (" \n Digite o nome do DEPARTMENT: "); gets (linha3.d_dept_name); printf (" \n Digite o codigo empregado do DEPARTMENT: "); gets (linha3.d_manager_id); cod_ret = upddep (&linha3); if( cod_ret == 0) { ponta_de_prova(28); printf ("Atualizacao efetuada DEPARTMENT\n"); } ponta_de_prova(29); break; } case 4: { ponta_de_prova(30); printf (" \n Digite o codigo do financ. de Venda: "); gets (linha4.fc_code); cod_ret = updfinc(&linha4); if( cod_ret == 0) { ponta_de_prova(31); printf ("Atualizacao efetuada FIN_CODE\n"); } ponta_de_prova(32); break; } case 5: { ponta_de_prova(33); printf (" \n Digite o Ano da data de Financ: "); gets (linha5.fd_year); cod_ret = updfind (&linha5);
/* 22 */ /* 22 */ /* /* /* /* 23 23 24 24 */ */ */ */ */ */ */ */ */
/* 24 /* 24 . . . /* 24 /* 24 /* 25
/* 25 */ /* 25 */ /* /* /* /* /* /* /* /* /* /* /* /* /* 26 26 27 27 27 27 27 27 27 27 27 27 28 */ */ */ */ */ */ */ */ */ */ */ */ */
/* 28 */ /* 28 */ /* /* /* /* 29 29 30 30 */ */ */ */ */ */ */ */ */
/* 30 /* 30 . . . /* 30 /* 30 /* 31
/* 31 */ /* 31 */ /* /* /* /* 32 32 33 33 */ */ */ */
/* 33 */ /* 33 */ . . . /* 33 */
182
/* 33 */ /* 34 */ /* 34 */ /* 34 */ /* 35 */ /* 36 */ /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* 36 36 37 37 37 37 37 37 37 38 38 38 38 38 38 39 */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */
if( cod_ret == 0) { ponta_de_prova(34); printf ("Atualizacao efetuada FIN_DATE\n"); } ponta_de_prova(35); } } ponta_de_prova(36); break; } case d : { ponta_de_prova(37); printf(" \n Remover 1- Empr 2- Vendas 3-Depart 4-Codigo-fin 5-Data-fin :"); gets(strfield); field = atoi (&strfield); switch(field) { case 1: { ponta_de_prova(38); printf (" \n Digite o codigo do Empregado a ser Removido: "); gets (linha.e_emp_id); cod_ret = delemp (&linha); if((cod_ret == 0) && (sqlca.sqlerrd[2]) > 0 ) { ponta_de_prova(39); printf ("Remocao efetuada EMPLOYEE\n"); } ponta_de_prova(40); break; } case 2: { ponta_de_prova(41); printf (" \n Digite o codigo da Venda a ser removida: "); gets (linha2.s_id); cod_ret = delsal (&linha2); printf (" --> "); printf("\n Linhas deletada =----==> %d", sqlca.sqlerrd[3]); if((cod_ret == 0) && (sqlca.sqlerrd[2]) > 0 ) { ponta_de_prova(42); printf ("Remocao efetuada SALES_ORDER\n"); } ponta_de_prova(43); break; } case 3: { ponta_de_prova(44); printf (" \n Digite o codigo do DEPARTMENT a ser removido: "); gets (linha3.d_dept_id); printf (" \n Digite o codigo empregado do DEPARTMENT: "); gets (linha3.d_manager_id); cod_ret = deldep (&linha3); if((cod_ret == 0) && (sqlca.sqlerrd[2]) > 0 ) { ponta_de_prova(45); printf ("Remocao efetuada DEPARTMENT\n"); } ponta_de_prova(46); break; } case 4: { ponta_de_prova(47); printf (" \n Digite o codigo do financ. de Venda: "); gets (linha4.fc_code); cod_ret = delfinc(&linha4);
/* 39 */ /* 39 */ /* /* /* /* 40 40 41 41 */ */ */ */
/* 41 */ /* 41 */ /* 41 */ /* 41 */ /* 42 */ /* 42 */ /* 42 */ /* /* /* /* /* /* /* /* /* /* /* 43 43 44 44 44 44 44 44 44 44 45 */ */ */ */ */ */ */ */ */ */ */
/* 45 */ /* 45 */ /* /* /* /* 46 46 47 47 */ */ */ */
/* 47 */ /* 47 */ /* 47 */
183
/* 47 */ /* 48 */ /* 48 */ /* 48 */ /* /* /* /* /* /* /* /* /* /* /* /* /* 49 49 50 50 50 50 50 50 16 16 50 50 51 */ */ */ */ */ */ */ */ */ */ */ */ */
/* 51 */ /* 51 */ /* 52 */ /* 53 */
printf (" --> "); printf("\n Linhas deletada =----==> %d", sqlca.sqlerrd[2]); if( (cod_ret == 0) && (sqlca.sqlerrd[2]) > 0) { ponta_de_prova(48); printf ("Remocao efetuada FIN_CODE\n"); } ponta_de_prova(49); break; } case 5: { ponta_de_prova(50); printf (" \n Digite o Ano da data de Financ: "); gets (linha5.fd_year); printf (" \n Digite o Trimestre (Q1/Q2/Q3/Q4) do Financ: "); gets (linha5.fd_quarter); printf (" \n Digite o codigo do financ. de Venda: "); gets (linha5.fd_code); cod_ret = delfind (&linha5); if((cod_ret == 0) && (sqlca.sqlerrd[2]) > 0 ) { ponta_de_prova(51); printf ("Remocao efetuada FIN_DATE\n"); } ponta_de_prova(52); }
} ponta_de_prova(53); /* 53 */ break; /* 53 */ } /* 54 */ case s : /* 54 */ { ponta_de_prova(54); /* 54 */ printf(" \n Deseja Selecionar 1:Tabela de Empregados 2:Tabela de ordem_vendas 3:Tabela de DEPARTMENT ou 4:Tabelas de codigo e data de financiamento :"); /* 54 */ gets(strfield); /* 54 */ field = atoi (&strfield); /* 54 */ switch(field) /* 54 */ { /* 55 */ case 1 : /* 55 */ { ponta_de_prova(55); /* 55 */ cod_ret = selemp (&linha); /* 55 */ if(cod_ret == 0) /* 56 */ { ponta_de_prova(56); . . . /* 56 */ } /* 57 */ else /* 57 */ { ponta_de_prova(57); /* 57 */ if(cod_ret == 1403) /* 58 */ { ponta_de_prova(58); /* 58 */ printf ("nao encontrado (employee)\n"); /* 58 */ } /* 59 */ else /* 59 */ { ponta_de_prova(59); /* 59 */ printf ("erro de selecao (employee)\n"); /* 59 */ printf ("sqlcode = %d\n", sqlca.sqlcode); /* 59 */ } ponta_de_prova(60); /* 60 */ } ponta_de_prova(61); /* 61 */ break; /* 61 */ } /* 62 */ case 2: /* 62 */ { ponta_de_prova(62);
184
/* 62 */ /* 62 */ /* 63 */ . . . /* 63 */ /* 64 */ /* 64 */ /* 64 */ /* 65 */ /* /* /* /* 65 65 66 66 */ */ */ */
cod_ret = selsal (&linha2); if(cod_ret == 0) { ponta_de_prova(63); } else { ponta_de_prova(64); if(cod_ret == 1403) { ponta_de_prova(65); printf ("nao encontrado (vendas)\n"); } else { ponta_de_prova(66); printf ("erro de selecao (vendas)\n"); printf ("sqlcode = %d\n", sqlca.sqlcode); } ponta_de_prova(67); } ponta_de_prova(68); break;
/* 66 */ /* 66 */ /* 66 */ /* 67 */ /* /* /* /* 68 68 69 69 */ */ */ */
} case 3: { ponta_de_prova(69); /* 69 */ cod_ret = seldep (&linha3); /* 69 */ if(cod_ret == 0) /* 70 */ { ponta_de_prova(70); /* 70 */ printf ("\n Codigo_dept: %s" , linha3.d_dept_id); /* 70 */ printf ("\n Nome_dept: %s Ident: %s ", linha3.d_dept_name, linha3.d_manager_id); /* 70 */ } /* 71 */ else /* 71 */ { ponta_de_prova(71); /* 71 */ if(cod_ret == 1403) /* 72 */ { ponta_de_prova(72); /* 72 */ printf ("nao encontrado (dept)\n"); /* 72 */ } /* 73 */ else /* 73 */ { ponta_de_prova(73); /* 73 */ printf ("erro de selecao (dept)\n"); /* 73 */ printf ("sqlcode = %d\n", sqlca.sqlcode); /* 73 */ } ponta_de_prova(74); /* 74 */ } ponta_de_prova(75); /* 75 */ break; /* 75 */ } /* 76 */ case 4: /* 76 */ { ponta_de_prova(76); /* 76 */ cod_ret = selfin (&linha4,&linha5); /* 76 */ if(cod_ret == 0) /* 77 */ { ponta_de_prova(77); /* 77 */ printf ("\n Codigo_fin: %s" , linha4.fc_code); . . . /* 77 */ } /* 78 */ else /* 78 */ { ponta_de_prova(78); /* 78 */ if(cod_ret == 1403) /* 79 */ {
185
/* /* /* /*
79 79 80 80
*/ */ */ */
ponta_de_prova(79); printf ("nao encontrado (fin)\n"); } else { ponta_de_prova(80); printf ("erro de selecao (fin)\n"); printf ("sqlcode = %d\n", sqlca.sqlcode); } ponta_de_prova(81); } ponta_de_prova(82); break; } } ponta_de_prova(83); } } printf(" \n Codigo de erro %d", cod_ret); ponta_de_prova(84); cod_ret = dbdisconn(); printf("\n code: = %d",cod_ret); if(cod_ret<0) { ponta_de_prova(85); printf ("erro durante a desconexao\n"); } ponta_de_prova(86); } else { ponta_de_prova(87); printf ("erro de conexao\n"); } ponta_de_prova(88); }
/* 80 */ /* 80 */ /* 80 */ /* 81 */ /* 82 */ /* 82 */ /* 83 */ /* 83 */ /* 84 */
/* 84 */ /* 84 */ /* 85 */ /* 85 */ /* 85 */ /* 86 */ /* 87 */ /* 87 */ /* 87 */ /* 87 */ /* 88 */
A seguir so apresentados os elementos requeridos e as seqncias de execuo dos casos de testes que exercitam os elementos requeridos para este critrio e para a tabela DEPARTMENT.
Associaes requeridas pela tabela DEPARTMENT ASSOCIACOES REQUERIDAS PELOS CRITERIOS TODOS T-USOS-INT-INTRA Associacoes requeridas pelo Grafo(INSDEP > 3003) 01) n.e 02) 03) 04) n.e 05) 06) 07) 08) * 09) 10) * 11) * 12) <3003,(2,3),3003,(2,3),{DEPARTMENT}> <3003,(2,3),3003,(2,4),{DEPARTMENT}> * <3003,(2,3),3008,(2,3),{DEPARTMENT}> * <3003,(2,3),3008,(2,4),{DEPARTMENT}> <3003,(2,3),3013,(2,3),{DEPARTMENT}> * <3003,(2,3),3013,(2,4),{DEPARTMENT}> * <3003,(2,3),3018,(3,4),{DEPARTMENT}> * <3003,(2,3),3018,(3,16),{DEPARTMENT}> <3003,(2,3),3018,(6,7),{DEPARTMENT}> * <3003,(2,3),3018,(6,16),{DEPARTMENT}> <3003,(2,3),3018,(9,10),{DEPARTMENT}> <3003,(2,3),3018,(9,16),{DEPARTMENT}> Associacoes requeridas pelo Grafo(DELDEP > 3008) 13) 14) n.e 15) 16) n.e 17) 18) 19) 20) n.e 21) 22) * 23) * 24) * <3008,(2,3),3003,(2,3),{DEPARTMENT}> * <3008,(2,3),3003,(2,4),{DEPARTMENT}> <3008,(2,3),3008,(2,3),{DEPARTMENT}> * <3008,(2,3),3008,(2,4),{DEPARTMENT}> (mesmo s/chave deleta 0 <3008,(2,3),3013,(2,3),{DEPARTMENT}> * <3008,(2,3),3013,(2,4),{DEPARTMENT}> * <3008,(2,3),3018,(3,4),{DEPARTMENT}> * <3008,(2,3),3018,(3,16),{DEPARTMENT}> <3008,(2,3),3018,(6,7),{DEPARTMENT}> * <3008,(2,3),3018,(6,16),{DEPARTMENT}> <3008,(2,3),3018,(9,10),{DEPARTMENT}> <3008,(2,3),3018,(9,16),{DEPARTMENT}>
Associacoes requeridas pelo Grafo(UPDDEP > 3013)
186
25) 26) 27) 28) n.e 29) 30) n.e 31) 32) n.e 33) 34) * 35) * 36) *
<3013,(2,3),3003,(2,3),{DEPARTMENT}> * <3013,(2,3),3003,(2,4),{DEPARTMENT}> * <3013,(2,3),3008,(2,3),{DEPARTMENT}> * <3013,(2,3),3008,(2,4),{DEPARTMENT}> <3013,(2,3),3013,(2,3),{DEPARTMENT}> * <3013,(2,3),3013,(2,4),{DEPARTMENT}> (mesma tupla) <3013,(2,3),3018,(3,4),{DEPARTMENT}> * <3013,(2,3),3018,(3,16),{DEPARTMENT}> (mesma tupla) <3013,(2,3),3018,(6,7),{DEPARTMENT}> * <3013,(2,3),3018,(6,16),{DEPARTMENT}> <3013,(2,3),3018,(9,10),{DEPARTMENT}> <3013,(2,3),3018,(9,16),{DEPARTMENT}>
fint04 :::::::::::::: u 3 600 Kids & Pats 249 #4 3013 1 2 3 4 5
Segunda avaliacao: nao permite mesmo DEPARTMENT (dept e a chave primaria).: Tabela DEPARTMENT ========================================== ========================= :::::::::::::: Dado de teste fint01 :::::::::::::: i Nmero do caso de teste 3 600 Geral Manager 1643 #1 3003 1 2 3 4 5 Caminho percorrido
DEPARTMENT: 600 =======================(26)========== :::::::::::::: fint05 :::::::::::::: i 3 600 Geral Manager 1643 #5 3003 1 2 4 5
Tupla usada
DEPARTMENT: 600 =======================n.e========== :::::::::::::: fint06 :::::::::::::: s 3 1 600 #6
DEPARTMENT: 600 =====================(03)============ :::::::::::::: fint02 A seqncia fint01 e :::::::::::::: d fint02 satisfaz o 3 elemento requerido 600 1643 nmero 03 #2 3008 1 2 3 4 5
3018 17
12
13
14
15
16
DEPARTMENT: 600 =======================(13)========== :::::::::::::: fint03 :::::::::::::: i 3 600 Geral Manager 1643 #3 3003 1 2 3 4 5
DEPARTMENT (dept_id): 600 Resultado: 600 ======================n.e=========== :::::::::::::: fint07 :::::::::::::: i 3 700 Drinks 249 #7 3003 1 2 3 4 5
DEPARTMENT: 600 =======================(05)========== ::::::::::::::
DEPARTMENT: 700 ======================(02)=========== :::::::::::::: fint08 :::::::::::::: i 3 700 Drinks 249
187
#8 3003 1 2 4 5
3 650 Controler 247 #13 3003 1 2 3 4 5
DEPARTMENT: 700 ======================n.e=========== :::::::::::::: fint09 :::::::::::::: i 3 800 TV & Sound 1576
#9 3003 1 2 3 4 5
DEPARTMENT: 650 ======================(11)=========== :::::::::::::: fint14 :::::::::::::: s 3 3 Controler #14
DEPARTMENT: 800 ======================n.e=========== :::::::::::::: fint10 :::::::::::::: d 3 600 1643 #10 3008 1 2 3 4 5
3018 17
10
12
13
14
15
16
DEPARTMENT: 600 ======================(14)=========== :::::::::::::: fint11 :::::::::::::: i 3 600 Geral Manager 102 #11 3003 1 2 4 5
DEPARTMENT (dept_name): Controler Resultado: 650 ======================n.e=========== :::::::::::::: fint15 :::::::::::::: i 3 660 Controler 247 #15 3003 1 2 3 4 5
DEPARTMENT: 660 ======================(12)========== :::::::::::::: fint16 :::::::::::::: s 3 3 Controler #16 3018 1 8 9 16 17 Controler
DEPARTMENT: 600 ======================n.e=========== :::::::::::::: fint12 :::::::::::::: s 3 2 102 #12 3018 1 5 6 7 12 16 17
DEPARTMENT (dept_name):
DEPARTMENT (manager_id): 102 Resultado: 0 ======================n.e=========== :::::::::::::: fint13 :::::::::::::: i
======================n.e=========== :::::::::::::: fint17 :::::::::::::: i 3 880 Controler 703 #17 3003 1 2 3 4 5
188
DEPARTMENT: 880 ======================(06)=========== :::::::::::::: fint18 :::::::::::::: u 3 880 Ships & Ships 102 #18 3013 1 2 4 5
#22 3018 1 8 9 16 17 Controler
======================n.e=========== :::::::::::::: fint23 :::::::::::::: u 3 750 Birds 1576 #23 3013 1 2 3 4 5
DEPARTMENT: 880 ======================n.e=========== :::::::::::::: fint19 :::::::::::::: i 3 690 Machines 247 #19 3003 1 2 3 4 5
DEPARTMENT: 750 ======================n.e=========== :::::::::::::: fint24 :::::::::::::: i 3 750 Birds 1576 #24 3003 1 2 4 5
DEPARTMENT: 690 ======================(10)=========== :::::::::::::: fint20 :::::::::::::: s 3 2 247 #20 3018 1 5 6 16 17 247
DEPARTMENT (manager_id):
DEPARTMENT: 750 ======================n.e=========== :::::::::::::: fint25 :::::::::::::: u 3 780 Reg & Dig 102 #25 3013 1 2 3 4 5
DEPARTMENT: 780 ======================(27)=========== :::::::::::::: fint26 :::::::::::::: d 3 780 102 #26 3008 1 2 3 4 5
DEPARTMENT: 750 ======================n.e=========== :::::::::::::: fint22 :::::::::::::: s 3 3 Controler
DEPARTMENT: 780 ======================(15)=========== :::::::::::::: fint27 :::::::::::::: d
189
3 780 102 #27 3008 1 2 3 4 5
fint32 :::::::::::::: u 3 600 Join & Join 249 #32 3013 1 2 3 4 5
DEPARTMENT: 780 ======================(17)=========== :::::::::::::: fint28 :::::::::::::: u 3 780 Join & Join 247 #28 3013 1 2 3 4 5
DEPARTMENT: 600 ======================(31)=========== :::::::::::::: fint33 :::::::::::::: s 3 1 600 #33
DEPARTMENT: 780 ======================(29)=========== :::::::::::::: fint29 :::::::::::::: u 3 780 Join & Ships 247 #29 3013 1 2 3 4 5
3018 17
12
13
14
15
16
DEPARTMENT (dept_id): 600 Resultado: 600 ======================n.e=========== :::::::::::::: fint34 :::::::::::::: d 3 660 247 #34 3008 1 2 3 4 5
DEPARTMENT: 780 ======================n.e=========== :::::::::::::: fint30 :::::::::::::: d 3 600 703 #30 3008 1 2 3 4 5
DEPARTMENT: 660 ======================(19)=========== :::::::::::::: fint35 :::::::::::::: s 3 1 660 #35 3018 1 2 3 4 12 16 17
DEPARTMENT: 600 ======================(18)=========== :::::::::::::: fint31 :::::::::::::: u 3 600 Shopping 102 #31 3013 1 2 4 5
DEPARTMENT (dept_id): 660 Resultado: 0 ======================n.e=========== :::::::::::::: fint36 :::::::::::::: u 3 670 Shopping 1903 #36
DEPARTMENT: 600 ======================n.e=========== ::::::::::::::
190
3013
5 #41
DEPARTMENT: 670 ======================(35)=========== :::::::::::::: fint37 :::::::::::::: s 3 3 Shopping #37 3018 1 8 9 10 12 16 17
3018 17
12
13
14
15
16
DEPARTMENT (manager_id): 1607 Resultado: 700 ======================n.e=========== :::::::::::::: fint42 :::::::::::::: d 3 700 1607 #42 3008 1 2 3 4 5
DEPARTMENT (dept_name): Shopping Resultado: 0 ======================n.e=========== :::::::::::::: fint38 :::::::::::::: d 3 670 1903 #38 3008 1 2 3 4 5
DEPARTMENT: 700 =========================n.e======== :::::::::::::: fint43 :::::::::::::: s 3 2 1607 #43 3018 1 5 6 7 12 16 17
DEPARTMENT: 670 ======================(21)=========== :::::::::::::: fint39 :::::::::::::: s 3 2 1903 #39 3018 1 5 6 7 12 16 17
DEPARTMENT (manager_id): 1903 Resultado: 0 ======================n.e=========== :::::::::::::: fint40 :::::::::::::: u 3 700 Books 1607 #40 3013 1 2 3 4 5
DEPARTMENT (manager_id): 1607 Resultado: 0 =========================n.e======== :::::::::::::: fint44 :::::::::::::: i 3 695 Sales 1191 #44 3003 1 2 3 4 5
DEPARTMENT: 695 =========================(07)======== :::::::::::::: fint45 :::::::::::::: s 3 1 695 #45 3018 17 1 2 3 4 12 13 14 15 16
DEPARTMENT: 700 ======================(33)=========== :::::::::::::: fint41 :::::::::::::: s 3 2 1607
DEPARTMENT (dept_id): 695 Resultado: 695 ======================n.e=========== ::::::::::::::
191
fint46 :::::::::::::: u 3 750 Birds 1191 #46
======================(23)=========== :::::::::::::: fint51 :::::::::::::: s 3 3 Machines #51
3013
5 3018 1 8 9 10 12 16 17
DEPARTMENT: 750 ======================(34)=========== :::::::::::::: fint47 :::::::::::::: s 3 1 1191 #47 3018 1 5 6 16 17
DEPARTMENT (dept_name): Machines Resultado: 0 ======================n.e=========== :::::::::::::: fint52 :::::::::::::: i 3 760 Machines 1576 #52
DEPARTMENT (manager_id): 1191 ======================n.e=========== :::::::::::::: fint48 :::::::::::::: d 3 750 1191 #48 3008 1 2 3 4 5
3003
DEPARTMENT: 760 ======================n.e=========== :::::::::::::: fint53 :::::::::::::: d 3 760 1576 #53
DEPARTMENT: 750 ======================(24)=========== :::::::::::::: fint49 :::::::::::::: s 3 3 Sales #49 3018 1 8 9 16 17
3008
DEPARTMENT: 760 ======================(22)=========== :::::::::::::: fint54 :::::::::::::: s 3 2 1576 #54
Sales 3018 1 5 6 16 17 1576
======================n.e=========== :::::::::::::: fint50 :::::::::::::: d 3 690 247 #50 3008 1 2 3 4 5
======================n.e=========== :::::::::::::: fint55 :::::::::::::: u 3 650 Controler 902 #55
DEPARTMENT: 690
192
3013
3 Sales #58 3018 1 8 9 16 17 Sales
DEPARTMENT: 650 ======================n.e=========== :::::::::::::: fint56 :::::::::::::: s 3 2 902 #56 3018 1 5 6 16 17 902
======================n.e=========== :::::::::::::: fint57 :::::::::::::: u 3 650 Sales 902 #57 3013 1 2 3 4 5
DEPARTMENT: 910 ======================(09)=========== :::::::::::::: fint60 :::::::::::::: s 3 2 1740 #60 3018 17 1 5 6 7 12 13 14 15 16
DEPARTMENT: 650 ======================(36)=========== :::::::::::::: fint58 :::::::::::::: s 3
DEPARTMENT (manager_id): Resultado: 910
1740
Esta etapa encerra o teste de Integrao para a varivel DEPARTMENT para o Mdulo Mod3 com associaes de ciclo1-intra.
Existem Unidades que para serem exercitadas ainda no teste intra-modular necessitam ser associadas a partir dos critrios de ciclo2. Como exemplo iremos apresentar casos que recaem em associaes de ciclo2 aplicadas ao teste inter-modular cujas caractersticas so semelhantes aos critrios do teste intra-modular. Inicialmente, apresentada uma parte do Mdulo Mod6 considerando apenas a Unidade (6002) que utiliza as variveis DEPARTMENT e EMPLOYEE.
#define ponta_de_prova(num) if(++printed_nodes % 10) fprintf(path," %2d ",num);\ else fprintf(path," %2d\n",num); #include <stdio.h> #include <string.h> #include <stdlib.h> . . . /* Declarando estrutura referente a tabela EMPLOYEE */
193
typedef struct {char e_emp_id [11]; char e_manager_id[11]; char e_emp_fname[20]; char e_emp_lname [20]; char e_dept_id[11]; char e_street[40]; char e_city[20]; char e_state[5]; char e_zip_code[12]; char e_phone [15]; char e_status[11]; char e_ss_number[11]; float e_salary; char e_start_date[16]; char e_termination_date[16]; char e_birth_date[16]; char e_bene_health_ins[15]; char e_bene_life_ins[13]; char e_bene_day_care[13]; char e_sex[3]; }RECORD1; /* Declarando estrutura referente a tabela SALES_ORDER typedef struct {char char char char char char s_id [11]; s_cust_id[11]; s_order_date[16]; s_code[11]; s_region[10]; s_emp_id[11]; }RECORD2; */ */
/* Declarando estrutura referente a tabela DEPARTMENT typedef struct {char d_dept_id [11]; char d_dept_name[40]; char d_manager_id[11]; }RECORD3; . . .
EXEC SQL BEGIN DECLARE SECTION; int h1, he1, he2, he5, hso1,hso2,hso6,hd1,hd3,hfd4; VARCHAR h2[15], h3[20], h4[35],h5[20],h6[2],h7[10],h8[12],h9[35], he3[20], he4[20],he6[40],he7[20],he8[4],he9[9],he10[10], he11[1],he12[11],he17[1],he18[1],he19[1],he20[1],hd2[40], hso4[2],hso5[7],hfc1[4],hfc2[10],hfc3[50],hfd2[7], hfd3[5],hp1[11],hp2[20],hp3[20],hp4[30],hp5[20],hsi1[11],hsi2[7], hsi3[11],hsi5[10]; char he14[12], he15[12], he16[12],hso3[12], hfd1[5]; float he13,hsi4,hp6,hp7; EXEC SQL END DECLARE SECTION; EXEC SQL BEGIN DECLARE SECTION; int mhp1, mhsi1, mhd1, mhe1,mhc1,mhso1; char mhfd1[5]; VARCHAR mhfd2[7], mhfd3[5], mhfc1[4]; EXEC SQL END DECLARE SECTION; char me_emp_id[11], mso_id[11],md_dept_id[11],mfc_code[7], mfd_year[6],mfd_quarter[5],mfd_code[7], mp_prod_id[11], msi_id[11],mc_cust_id[11]; EXEC SQL INCLUDE SQLCA; . . . int empdep() /* 1 */ { FILE * path = fopen("empdep/path.tes","a"); FILE * key = fopen("empdep/key.tes","a"); static int printed_nodes = 0; EXEC SQL BEGIN DECLARE SECTION; int cod_dept;
/*
1 */
194
/* /* /* /*
1 */ 1 */ 1 */ 2 */
/* 3 */ /* 3 */ /* 3 */ /* 3 */ CIDADE /* 3 */
EXEC SQL END DECLARE SECTION; char e_emp_fname[20]; char e_emp_lname [20]; char e_emp_nome_aux[40]; char e_city[20]; char e_state[5]; char e_phone [15]; char d_dept_id [11]; char d_dept_name[40]; ponta_de_prova(6002); ponta_de_prova(1); printf ("\n Digite o codigo do DEPARTMENT (100..1000): "); gets (d_dept_id); cod_dept = atoi (d_dept_id); ponta_de_prova(2); EXEC SQL DECLARE emp_dep_cursor CURSOR FOR SELECT d.dept_id, e.emp_id, d.dept_name, e.emp_fname, e.emp_lname, e.city, e.state, e.phone FROM DEPARTMENT d, EMPLOYEE e WHERE d.dept_id = :cod_dept and d.dept_id = e.dept_id; ponta_de_prova(3); EXEC SQL OPEN emp_dep_cursor; printf("\n Relacao de empregados:\n"); printf("DEPARTMENT: %s \n", d_dept_id); printf("| DEPARTMENT = | NOME DO EMPREGADO |ESTADO| TELEFONE | \n"); printf("|====================");
/* 3 */ printf("|==========================================|================== ===|======|=============| \n");

/* /* 3 */ 4 */ sqlca.sqlcode=0; while (sqlca.sqlcode != 1403) { ponta_de_prova(4); ponta_de_prova(5); EXEC SQL FETCH emp_dep_cursor INTO :mhd1, :mhe1, :hd2, :he3, :he4, :he7, :he8, :he10; ponta_de_prova(6); if (sqlca.sqlcode != 1403) { ponta_de_prova(7); hd2.arr [hd2.len] = \0; strcpy (d_dept_name, hd2.arr); he3.arr [he3.len] = \0; strcpy (e_emp_fname, he3.arr); he4.arr [he4.len] = \0; strcpy (e_emp_lname, he4.arr); he7.arr [he7.len] = \0; strcpy (e_city, he7.arr); he8.arr [he8.len] = \0; strcpy (e_state, he8.arr); he10.arr [he10.len] = \0; strcpy (e_phone, he10.arr); strcpy (e_emp_nome_aux,e_emp_fname); strcat (e_emp_nome_aux, " ");
G(empdep)Mod6
/*
5 */
/*
6 */
/* /* /* /* /* /* /* /* /* /* /* /*
7 7 7 7 7 7 7 7 7 7 7 7
*/ */ */ */ */ */ */ */ */ */ */ */
195
strcat (e_emp_nome_aux,e_emp_lname); itoa(mhd1,md_dept_id); /* int para char */ fprintf(key, "DEPARTMENT: %s \n",md_dept_id); itoa(mhe1,me_emp_id); /* int para char */ fprintf(key, "EMPLOYEE: %s \n",me_emp_id); /* 7 */ printf("| %18s | %40s | %19s | %4s | %11s |\n",d_dept_name, e_emp_nome_aux, e_city, e_state, e_phone); } ponta_de_prova(8); /* 8 */ } ponta_de_prova(4); ponta_de_prova(9);
/* 9 */ printf("|=================================================================================== =======================|\n"); /* 9 */ ponta_de_prova(10); EXEC SQL WHENEVER NOT FOUND CONTINUE; EXEC SQL CLOSE emp_dep_cursor; fclose(path); fclose(key); /* 9 */ return (sqlca.sqlcode); /* 10 */ } . . . main( ) . . .
Os Mdulos Mod3 so associados com o Mdulo Mod6 cujas associaes envolvem as variveis tabela DEPARTMENT, EMPLOYEE e SALES_ORDER.
ASSOCIACOES REQUERIDAS PELOS CRITERIOS DE INTEGRACAO POT_S_USO INTER_MODULAR: MOD3 X MOD6 -CICLO2 - MESMA TUPLA - EMPLOYEE, SALES_ORDER E DEPARTMENT Associacoes originadas de Insemp(3001),Inssal(3002) e Insdep(3003) 010203040506070809<3003,(3,4),3001,(3,4),6002,(4,9),{DEPARTMENT,EMPLOYEE}> * 1 2 3 <3003,(3,4),3001,(3,4),6002,(6,7),{DEPARTMENT,EMPLOYEE}> * 1 2 3 <3003,(3,4),3001,(3,4),6002,(6,8),{DEPARTMENT,EMPLOYEE}> * 1 2 3 <3001,(3,4),3003,(3,4),6003,(4,9),{DEPARTMENT,EMPLOYEE}> * 4 5 6 <3001,(3,4),3003,(3.4),6003,(6,7),{DEPARTMENT,EMPLOYEE}> * 4 5 6 <3001,(3,4),3003,(3,4),6003,(6,8),{DEPARTMENT,EMPLOYEE}> * 4 5 6 <3001,(3,4),3002,(3,4),6004,(4,9),{SALES_ORDER,EMPLOYEE}> * 7 8 9 <3001,(3,4),3002,(3,4),6004,(6,7),{SALES_ORDER,EMPLOYEE}> * 7 8 9 <3001,(3,4),3002,(3,4),6004,(6,8),{SALES_ORDER,EMPLOYEE}> * 7 8 9
Associacoes originadas de Delemp(3006),Delsal(3007) e Deldep(3008) 101112131415161718<3006,(3,4),3008,(3,4),6002,(4,9),{DEPARTMENT,EMPLOYEE}> * 10 11 12 <3006,(3,4),3008,(3,4),6002,(6,7),{DEPARTMENT,EMPLOYEE}> * 10 11 12 <3006,(3,4),3008,(3,4),6002,(6,8),{DEPARTMENT,EMPLOYEE}> * 10 11 12 <3008,(3,4),3006,(3,4),6003,(4,9),{DEPARTMENT,EMPLOYEE}> * 13 14 15 <3008,(3,4),3006,(3,4),6003,(6,7),{DEPARTMENT,EMPLOYEE}> * 13 14 15 <3008,(3,4),3006,(3,4),6003,(6,8),{DEPARTMENT,EMPLOYEE}> * 13 14 15 <3007,(3,4),3006,(3,4),6004,(4,9),{SALES_ORDER,EMPLOYEE}> * 16 17 18 <3007,(3,4),3006,(3,4),6004,(6,7),{SALES_ORDER,EMPLOYEE}> * 16 17 18 <3007,(3,4),3006,(3,4),6004,(6,8),{SALES_ORDER,EMPLOYEE}> * 16 17 18
Associacoes originadas de Updemp(3011), Updsal(3012) e Upddep(3013) 192021222324<3013,(3,4),3011,(3,4),6002,(4,9),{DEPARTMENT,EMPLOYEE}> <3013,(3,4),3011,(3,4),6002,(6,7),{DEPARTMENT,EMPLOYEE}> <3013,(3,4),3011,(3,4),6002,(6,8),{DEPARTMENT,EMPLOYEE}> <3011,(3,4),3013,(3,4),6003,(4,9),{DEPARTMENT,EMPLOYEE}> <3011,(3,4),3013,(3,4),6003,(6,7),{DEPARTMENT,EMPLOYEE}> <3011,(3,4),3013,(3,4),6003,(6,8),{DEPARTMENT,EMPLOYEE}> n.e n.e n.e n.e n.e n.e 19 19 19 22 22 22 20 20 20 23 23 23 21 21 21 24 24 24
196
25- <3011,(3,4),3012,(3,4),6004,(4,9),{SALES_ORDER,EMPLOYEE}> n.e 25 26 27 26- <3011,(3,4),3012,(3,4),6004,(6,7),{SALES_ORDER,EMPLOYEE}> n.e 25 26 27 27- <3011,(3,4),3012,(3,4),6004,(6,8),{SALES_ORDER,EMPLOYEE}> n.e 25 26 27 ==================================================================
As seqncias de execuo, mostradas a seguir, so utilizadas para exercitar as associaes de ciclo2, mostradas acima, que envolvendo dois Mdulos: Mod3 e Mod6 (inter-modular) (no exemplo so mostrados apenas os casos de testes que exercitam os elementos requeridos em negrito).
:::::::::::::: fddep01 :::::::::::::: i 3 700 Drinks 249 #1 3003 1 2 3 4 5 DEPARTMENT: 700 ========================= :::::::::::::: fdemp01 :::::::::::::: i 1 1920 249 Edmundo Spoto 700 520 Nelson de Souza Barbara Street Campinas SP 13080-260 0192080705 A 118998234 34992.000 12-FEB-87 (NULL) 11-MAR-57 Y Y N M #2 3011 1 2 3 4 5 3001 1 2 3 4 5 EMPLOYEE: 1920 ========================= :::::::::::::: finu01 :::::::::::::: e 700 t EMPLOYEE: 1920 ========================= :::::::::::::: finu04 :::::::::::::: e 700 t #3 6002 1 2 3 4 5 6 7 8 4 5 6 8 4 9 10 DEPARTMENT: 700 EMPLOYEE: 1920 ================*1,2,3============== :::::::::::::: fddep04 :::::::::::::: u 3 700 Encadernacao 501 #10 3013 1 2 3 4 5 DEPARTMENT: 700 ========================= :::::::::::::: fdemp04 :::::::::::::: u 1 1920 501 700 114 Great Plain Avenue Winchester MA 01890 6175557835 A 45000.00 #11
197
#12 6002 1 2 3 4 5 6 7 8 4 5 6 8 4 9 10 DEPARTMENT: 700 EMPLOYEE: 1920 ==================*10,11,12======= :::::::::::::: fdemp07 :::::::::::::: d 1 1920 #19 3006 1 2 3 4 5 EMPLOYEE: 1920 ========================= :::::::::::::: fddep07 :::::::::::::: d 3 700 501 #20 3008 1 2 3 4 5 DEPARTMENT: 700 ========================= :::::::::::::: finu07 :::::::::::::: e 700 t #21 6002 1 2 3 4 5 6 8 4 9
10 ============n.e:19,20,21=======
COBERTURA
A cobertura mostrada da seguinte forma: Os dados de teste fddep01, fdemp01 e finu01 quando executados seqencialmente geram os caminhos 3003 1 2 3 4 5 3001 1 2 3 4 5 6002 1 2 3 4 5 6 7 8 4 5 6 8 4 9 10. Como as tuplas so respectivamente: 3003 DEPARTMENT: 700 3001 EMPLOYEE: 1920 e 6002 DEPARTMENT: 700 EMPLOYEE: 1920 Neste exemplo, os casos de teste 1, 2 e 3 cobrem as associaes 1, 2 e 3 da pgina 194. Assim, cada seqncia de execuo de 3 dados de teste gera outros trs casos de teste para satisfazer uma ou mais associaes de ciclo2. Os nmeros dos casos de teste anotados na frente das associaes representam as seqncias de casos de testes necessrias para cobrir a associao. Neste exemplo foram apresentados apenas alguns casos de teste para ilustrar a cobertura dos elementos requeridos (associaes def-t-uso de ciclo2).
198
ndice Remissivo
NDICE REMISSIVO
199
ndice Remissivo
A ABDR, 3, 4, 5, 20, 23, 26, 28, 30, 32, 35, 37-39, 43, 45, 48, 50, 89, 90, 92, 105, 109-112, 115, 128-129, 133, 136-142, 157 Anlise de incluso, 76 Anlise de Propriedades, 61, 75 anlise esttica, 8, 116, 151, 154 Anomalia, 39, 67 Aplicabilidade, 13 Aplicao de Banco de Dados Relacional, 23, 35 arcos, 7-9, 14, 16, 19, 36-37, 41-43, 54-55, 67, 69, 91, 111-112, 122, 137-138, 152, 154 Associao, 10, 15, 17, 45-47, 65-66, 70-74, 77-78, 81, 105, 111-112, 124, 126, 130, 136 Associao definio-c-uso, 9-10, 45 Associao definio-p-uso, 10 Associao definio-s-uso, 45 Associao definio-t-uso, 45, 51, 68, 72, 75 Associao definio-t-uso interprocedimental de chamada, 52 Associao definio-t-uso-inter, 64 Associao definio-uso, 15, 40, 54 Associao inter-unidade, 52 Associao potencial-uso, 16 Associao-definio-s- interprocedimental de chamada, 50 Associao-definio-s-uso interprocedimental de retorno, 50 Associao-definio-t-uso interprocedimental de chamada, 50 Associao-definio-t-uso interprocedimental de retorno, 50 Associao-p-uso, 9, 45 Associaes definio-t-uso, 61 Associaes definio-t-uso de integrao, 72 Associaes definio-t-usos, 83 Associaes definio-uso, 19, 64 Atributo, 21 Avaliao, 2, 97, 99, 112, 116, 128, 129, 132, 151 B Banco de Dados Relacional, 3, 7, 20, 23, 32, 35, 39, 52, 57, 112, 119, 139, 141, 143, 149, 155, 157 big-bang, 12 bloco de comandos, 7, 8, 19, 98 Bottom-Up, 12 C Cadequado, 13
caminho executvel, 47 caminho livre de definio, 74 caminho livre de definio persistente, 43, 45, 52, 66 caminho livre de lao, 45 caminho simples, 8-9, 45 caso de teste, 2, 7, 11, 32, 98, 111-112, 123-124, 127, 154 classes de defeitos, 4, 10, 11, 57, 138, 142 classes distintas de erros, 7 clusters, 12 cobertura, 47, 131,136,198 coleta e anlise de requisitos, 23 comando de manipulao da SQL, 44, 166-171 comandos da LI, 99 comandos de linguagem, 3 comandos de SQL, 27,159-173 comando COMMIT, 40 comandos executveis da linguagem SQL, 25, 28, 36, 90,163-173 complexidade de um critrio, 4, 13,76, 83-85, 87 conceitos bsicos, 7, 20, 23, 35, 39, 43, 45, 142 conjunto factvel:, 47 Critrios: - contexto elementar de dados, 14 - estrutural de teste de integrao, 51 - todos os arcos, 16 - todos os caminhos, 13 - todos os ramos, 13 - todos-arcos, 8, 154 - todos-caminhos, 8, 17 - todos-ns, 8, 154 - ver (todos os...) - baseados em fluxo de dados, 13 - de integrao inter-modular, 59 - de teste, 4, 7, 19, 32, 35, 39, 45, 47, 57,61, 65, 6869, 71, 76, 78, 83, 87, 89, 98, 101, 105, 110-112, 117-119, 124, 128, 134-136, 138-142, 155 - de teste de integrao, 18 - de teste estrutural, 17 c-uso, 9, 15, 43, 47 c-uso global, 43 c-uso local, 43 D declarativos, 25 defeito, 1, 11, 46, 67 defg(i), 16 definio, 8, 9, 13, 16-17, 30, 39-43, 46, 53, 55, 56, 57, 65, 66, 68-75, 77-78, 83, 87, 89, 98, 101, 106, 109, 111-112, 118, 124, 126, 130-131, 134, 137, 139-140, 142, 154, 157, 159 definio global, 9-10, 17, 43, 45-46, 69 definio persistente, 40, 43-44, 51-52, 62 definio por referncia, 41 definio por valor, 41
caminho, 8-9, 37, 40-41, 43, 45-46, 50, 66, 69-70, 7274, 76-78, 81, 111, 123-124, 126, 151, 154 caminho completo, 8, 14-15, 47, 51, 66, 72, 76 caminho de integrao, 19, 51 caminho de integrao interprocedimental, 51
200
ndice Remissivo
definies globais, 9, 50 defT<l,i>, 43 Dependncia de dados, 52, 55, 68, 72 Dependncia externa de dados, 53, 55 Dependncia interna, 53 Desenvolvimento, 1-5, 27, 30-31, 139, 141, 157 domnio, 21 domnio de entrada, 7 drivers, 11 dsu(v,i), 43 dtu-caminho, 45 dtu-caminhos, 68 du-caminho, 9, 45 E elementos requeridos, 9, 10, 65, 67, 74-75, 83-85, 87, 89, 97, 109-112, 116, 124-131, 133, 135-136, 139, 174, 184, 195 error, 1, 90 especificao, 2, 7, 10, 24, 31 esquema da base de dados relacional, 22 estrutural, 4, 5, 7, 11, 19, 23, 35, 38, 39, 47, 57, 61, 65-66, 69, 75, 89, 97, 110, 115, 133, 139-140 executvel ou factvel, 15, 25 exemplo de aplicao, 37, 47, 74, 115, 130, 136, 140 exemplos de utilizao, 103, 115, 117-118, 137, 197 F falha, 1, 4, 72, 99 Famlia de Critrios, 9, 10, 15-18, 20, 66, 147 - Potenciais Usos, 10 fases de teste, 35, 141 ferramenta de suporte, 87, 141 ferramenta de visualizao, 47 ferramentas, 2, 17, 30, 47, 136, 139-140 Fluxo de Controle, 89, 90, 148, 154 fluxo de dados inter-modular, 64 fluxo de dados intra-modular, 62 fpdcu(x,i), 16 fpdpu(x,i), 16 funcional, 3, 11 G grafo, 9, 14, 18, 39, 41, 43, 47, 48, 66, 68, 69, 76, 83, 87, 90, 105, 106, 110-112, 121-123, 154-155 grafo (i), 46 grafo de chamada, 18, 19, 39, 47, 48, 52, 65, 68-69 grafo de dependncia de dados, 54, 62 grafo de dependncia Interna, 55 grafo de fluxo de controle, 7, 83 grafo de fluxo de dados, 46 grafo de programa, 7, 9, 14, 17, 19, 36, 37, 46, 54, 62, 66, 87, 90, 105, 111-112, 121-123 Grafo geral, 55 grafo(i), 46 grafo-def, 46 grau de uma relao, 21
I implementao, 2, 3, 4, 7, 11, 23, 26, 28, 31, 44, 61, 89, 98, 111-112, 129, 133, 137, 139, 141, 159 inclui, 14, 76 inclui parcialmente, 77 incomparveis, 14, 76, 81 indefinio, 8, 39, 106 instncia, 22 integrao baseada no grafo de chamada, 35 inter-modular, 35, 37, 38, 39, 47, 53, 57, 61, 74, 75, 76, 97-98, 105, 106, 110, 112, 115, 118, 127, 130, 131, 133-137, 139-142, 173, 192, 195 interprocedimental, 19 intra-modular, 35, 37, 39, 47, 53, 55, 57,61, 68, 72, 74, 76, 97-98, 105-106, 112, 115, 118-119, 127128, 131-137, 139-142, 173, 192 L linguagem de definio de dados, 32 linguagem de manipulao de dados, 32 linguagem hospedeira, 24 linguagens hospedeiras, 4, 25 M mesma tupla, 65-74, 77, 81-85, 116, 129, 134-135, 137, 139-140, 142, 185 mistake, 1 Modelo de Dados Relacional, 21 modelo relacional formal, 21, 25 modelos de fluxo de dados, 89 modelos de instrumentao, 89 mdulo, 2, 12, 36, 62, 72-75, 98, 115, 142, 153-155 Mdulos de programa, 35 multi-grafo, 19, 55 N ns, 7-9, 18-19, 36-37, 41, 43, 48-49, 64, 67-72, 7576, 88, 90, 96, 101, 107, 109-110, 120, 135, 150, 152 n-tuplas, 22 O ocorrncia, 40, 42, 57 ordem de complexidade, 85 ordem exponencial, 81 ordem parcial, 14 P pairwise, 12, 20, 67 par de ns, 40, 45, 51, 72, 79, 109 pares de ns, 65 pdcu(v,i), 16 pdpu(v,i), 16 persistncia dos dados, 52 planejamento, 1, 2, 31, 139 POKE-TOOL, 46, 47, 87, 96, 97, 104, 109-110, 113, 114, 118, 120, 129, 134, 139, 141, 143, 145, 149, 150, 153 potencial associao, 10, 17, 46, 83 potencial-du-caminho, 16
201
ndice Remissivo
programas convencionais, 35, 47, 48, 52, 74, 126 programas de aplicao, 4, 25, 35, 39, 43, 45-49, 57, 59, 66-67, 75, 95-96, 109-110, 115, 131, 135 programas de Aplicaes de Banco de Dados Relacional, 3 projeto, 1, 2, 23, 31, 59, 87, 113, 126, 135 projeto de banco de dados conceitual, 23 projeto de banco de dados fsico, 24 projeto de banco de dados lgico, 23 projeto lgico, 27 propriedades, 13, 14, 23, 30, 59, 69, 73, 138-139 p-uso, 9-10, 15, 45, 47 Q qualidade de, 3, 13 R redefinio, 9, 43, 52 relao, 22, 23 requisitos de teste, 2, 13, 20, 67 Restries de Integridade Referencial, 32 S sintaticamente alcanvel, 43 Sistema Gerenciador, 3, 27, 36, 155
SQL, 3, 4, 23-27, 29-30, 32, 35-37, 40-42, 49, 57, 59, 60, 62, 65-67, 75, 76, 87-90, 96-99, 104, 106-107, 109-110, 113, 116-118, 120, 122-123, 131, 135, 137-144, 153, 155, 157-175, 190-192 SQL embutida, 27 SQLBench, 30 stubs, 11, 12 sub-caminho, 65 sub-caminho livre de definio, 50 s-uso, 42 s-uso (i), 43 T Tabelas de Viso, 26 tcnica de teste, 3, 57 tcnica estrutural, 2, 7 Todos os t-usos-ciclo2-inter, 75 Todos os t-usos-ciclo2-intra, 74 Todos-c-usos, 15 Todos-c-usos/algum-p-uso, 15 Todos-du-caminhos, 15 Todos-potenciais-du-caminhos, 17 Todos-potenciais-usos, 17 Todos-potenciais-usos/DU, 17 Todos-p-usos, 15 Todos-p-usos/algum-c-uso, 15 Todos-usos, 15 top-down, 12 tratamento de erro, 41, 100 U unidade chamada, 48 unidade chamadora, 48
tcnica funcional, 2, 7 terminologia, 7, 21, 35, 39, 137 teste de integrao, 2, 4, 11-12, 14, 17-20, 35, 37, 39, 47-48, 55-57, 60, 63, 66-67, 69, 74, 85, 96, 104, 108-110, 114, 117, 122-123, 125-126, 128-130, 132-135, 137-140, 153 teste de integrao baseado na dependncia de dados, 47, 56, 59, 122, 126, 137 teste de integrao baseado no grafo, 59 teste de integrao intra-modular, 59, 60 teste de sistema, 2 teste de software, 2-3, 103, 139 Teste de Software, 1, 2, 141, 144, 146 teste de unidade, 2, 4, 10-12, 14, 17, 18, 20, 35, 37, 39, 44-45, 47-48, 57, 59-60, 63-65, 67, 69, 80, 96, 104, 107, 109-110, 117-118, 122, 132, 134, 136140, 149, 153 teste estrutural, 11, 13, 20, 37 teste inter-mtodos:, 20 teste intra-classe, 20 teste intra-mtodo, 20 tipos de dados, 21 todas as relaes, 18 Todas os t-usos-ciclo1-intra, 70 todas relaes mltiplas, 18 todas seqncias de chamadas, 18 todas seqncias simples descendentes, 18 todas seqncias simples descendentes sem lao, 18 todas-definies, 15 Todos os dtu-caminho interprocedimentais de retorno, 69 Todos os dtu-caminhos interprocedimentais de chamada, 68 Todos os dtu-caminhos-intra, 71 todos os mdulos, 18 Todos os t-usos interprocedimentais de chamada, 68 Todos os t-usos interprocedimentais de retorno, 68 Todos os t-usos-ciclo1-inter, 75 Unidades de Programa, 35 uso, 8, 10, 17, 23, 39-43, 46-47, 55, 65-66, 68-75, 77, 81, 87, 89, 98, 106, 109, 111-112, 116, 118, 124, 126, 130, 133, 137, 139-140, 142, 157, 165-167, 169, 171 uso de t, 67 uso persistente, 42, 62 V valores atmicos, 21 variveis de programa, 13, 39-40, 49, 61, 69, 106 variveis host, 29, 35, 39-40, 42, 45, 49, 51, 61, 69, 101, 106, 118, 155, 158, 167 variveis persistentes, 30, 57, 61, 65-66, 68-69, 72, 77-78, 89, 101, 108, 112, 124, 139, 140-142
202
ndice Remissivo
variveis tabela, 30, 35, 38, 39, 42, 44-46, 49, 57, 6162, 64-65, 69, 71, 74, 78, 101, 106, 109, 118, 124, 130-131, 133, 135, 137, 139-141, 155, 194
variveis tabela de viso, 39 ViewGraph, 47
203
ndice Remissivo
Informaes:
O relatrio dos exemplos de utilizao dos critrios propostos nesta tese pode ser obtido com o autor Prof. Edmundo Srgio Spoto (dino@din.uem.br) Universidade Estadual de Maring PR Departamento de Informtica, ou com o Prof. Dr. Mario Jino na Universidade Estadual de Campinas Faculdade de Engenharia Eltrica e de Computao (FEEC).
204

Spoto, Edmundo Sergio

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Spoto, Edmundo Sergio

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELTRICA E DE COMPUTAO DEPARTAMENTO DE ENGENHARIA DE COMPUTAO E AUTOMAO INDUSTRIAL

TESTE ESTRUTURAL DE PROGRAMAS DE APLICAO DE BANCO DE DADOS RELACIONAL

Edmundo Srgio Spoto

Campinas SP Brasil 2000

FICHA CATALOGRFICA ELABORADA PELA BIBLIOTECA DA REA DE ENGENHARIA - BAE - UNICAMP

TESTE ESTRUTURAL DE PROGRAMAS DE APLICAO DE BANCO DE DADOS RELACIONAL

Campinas SP Brasil 2000

3.1.1 Teste de Unidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 041 3.1.2 Teste de Integrao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 050

5.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 x

1.1 Teste de Software

1.3 Objetivos da Tese

1.4 Organizao da tese

2 Conceitos Bsicos e Terminologia

2.1 Teste Estrutural Baseado em Fluxo de Dados

Captulo 2 Conceitos Bsicos e Terminologia

N representa uma instruo simples (comando) ou uma

seqncia de instrues executadas como um bloco de comandos. Cada arco a

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

2.1.1 Teste de Unidade

Unidade de Programa em Teste

Figura 2.1 Ambiente para o teste de unidade

Captulo 2 Conceitos Bsicos e Terminologia

2.1.2 Teste de Integrao

Captulo 2 Conceitos Bsicos e Terminologia

2.1.3 Trabalhos Relacionados ao Teste Estrutural

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

associao potencial-uso uma associao potencial-definio-c-uso, uma associao potencial-definio-p-uso ou um potencial-du-caminho.

G tal que defg(i) (onde o

G tal que defg(i) e para

defg(i) requer que todos os potenciais du-

caminho c.r.a. x sejam exercitados pelo menos uma vez;

defg(i) requer o exerccio das mesmas potenciais

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

R) = {iP1, iP2,..., iPn}C,R

Captulo 2 Conceitos Bsicos e Terminologia

2.2 Banco de Dados Relacional

2.2.1 Modelo de Dados Relacional

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

2.2.2 Aplicao de Banco de Dados Relacional (ABDR)

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

2.2.2.1 Linguagem de Banco de Dados Relacional SQL

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

2.2.2.2 Comandos da Linguagem SQL embutida

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

comando executvel !condio condio !condio

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

Captulo 2 Conceitos Bsicos e Terminologia

3 Teste Estrutural de Aplicaes de Banco de Dados Relacional: Conceitos e Terminologia

3.1 Teste estrutural de ABDR: conceitos bsicos e terminologia