Um Conjunto de Artefatos para Apoio à Definição de Estudos Experimentais em Teste de Software

Transcrição

1 Um Conjunto de Artefatos para Apoio à Definição de Estudos Experimentais em Teste de Software Marllos Paiva Prado, Diogo Nascimento Campanha, Simone do Rocio Senger de Souza, José Carlos Maldonado 1 Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo Av. do Trabalhador São-Carlense, 400 Cx. Postal 668 CEP São Paulo, SP {marllos,diogonc,srocio,jcmaldon}@icmc.usp.br Resumo. Um estudo experimental requer, além do conhecimento da teoria subjacente, artefatos que viabilizem e diminuam custos em sua definição, execução e análise. No domínio de teste de software, esses subsídios correspondem, entre outros, a programas adeqüadamente especificados, massas de testes, oráculos, medidas e ferramentas. Sob essa perspectiva, esse material pode ainda ser aproveitado como forma de apoio ao ensino e treinamento de testes. Neste artigo é apresentado um panorama do estágio atual de nosso trabalho no apoio a essas necessidades. Para tanto, um estudo experimental comparando custo e strength de critérios de teste sobre o paradigma OO e procedimental está sendo realizado, como metodologia para levantamento e construção desses artefatos. A pesquisa encontra-se em andamento, contudo alguns resultados preliminares evidenciam a relevância do presente trabalho. 1. Introdução O ensino e o treinamento em teste de software requerem além do conhecimento teórico, recursos que viabilizem a aplicação prática de seus conceitos para permitir que os alunos sejam capazes de vivenciar detalhes, dificuldades e vantagens na aplicação dessa atividade. Existem diversos materiais didáticos publicados na área abordando os mais variados assuntos de testes, os quais abrangem desde o ensino de cada técnica até a sua aplicação em cada contexto de desenvolvimento. Contudo, a concretização final no processo de aprendizagem de teste muitas vezes depende da disponibilidade de especificações, programas e resultados adequadamente preparados e disponibilizados para essa finalidade. Quanto à engenharia de software experimental, apesar das investigações nesse campo se preocuparem com a sustentação de novas propostas e com a revalidação de conceitos de teste antes verificados apenas por pequenos exemplos, a área ainda sofre uma carência de materiais e resultados que apóiem e facilitem as definições desses estudos. O rigor dos aspectos teóricos envolvidos e do processo para uma condução adequada dos experimentos, e mais especificamente de experimentos controlados, já consome grande parte dos esforços destinados a essa parte da pesquisa. Desse modo, prover artefatos que possam ser utilizados ou reaproveitados nessas investigações é uma importante contribuição na redução dos esforços exigidos, além de trazerem maior confiança aos pesquisadores menos experientes no campo dos estudos experimentais. Este artigo apresenta uma pesquisa em andamento, cujo propósito final é desenvolver um arcabouço de recursos e resultados de teste. Para alcançar este objetivo, foi usada como metodologia de execução do trabalho a condução de um estudo experimental aplicado a um benchmark de programas do domínio de estrutura de dados. Neste artigo benchmark é usado com o sentido de conjunto de programas dentro de um domínio para estabelecer uma marca de nível [Michaellis 2008] em algum atributo de teste, sem

2 implicar necessariamente em teste de desempenho como é usualmente associado seu significado em computação. O estudo consiste na avaliação entre programas procedimentais e OO, comparando custo e dificuldade de satisfação de critérios(strength) entre paradigmas, com relação à aplicação das técnicas de teste funcional e estrutural. Em Rothermel e S. Elbaum [2005] nota-se uma preocupação similar com relação às necessidades apontadas. Nesse trabalho os autores fazem um survey de vários artigos com resultados experimentais sobre teste de software, reportando as dificuldades encontradas na condução dos mesmos e analisam os principais desafios enfrentados pelos pesquisadores durante a execução de um experimento. Em resposta a esses obstáculos, definem uma infra-estrutura a qual consiste em um repositório web constituído de programas, versões, casos de teste, defeitos e scripts já estabilizados para realização de estudos experimentais. Contudo, a infra-estrutura é composta somente de artefatos de teste e existe uma preocupação em atender de forma genérica a essa atividade, dando particular enfoque ao teste de regressão. Nossa investigação por sua vez, é focada no contexto de estrutura de dados e precedida de um estudo experimental no qual são identificadas as necessidades em termos de recursos e resultados, tanto do ponto de vista de testes quanto de experimentação. Assim, envolve desde códigos, especificações e ferramentas de teste até formulários, conjuntos adequados de teste nas duas técnicas, métricas de teste e de implementação. Além disso, estabelece resultados iniciais sobre uma hipótese ainda não investigada. O trabalho encontra-se em andamento, contudo alguns resultados parciais já obtidos são apresentados. O restante deste artigo encontra-se dividido da seguinte forma: na Seção 2, alguns fundamentos sobre teste de software e engenharia de software experimental são apresentados, contextualizando os termos e conceitos aplicados no trabalho. Na Seção 3, a metodologia utilizada na execução da investigação é explicada, na qual a definição e o planejamento do estudo experimental proposto são caracterizados. Na Seção 4 são exibidos alguns resultados preliminares obtidos até o momento. Na Seção 5 são discutidas as expectativas pretendidas para a finalização do trabalho com base no que foi construído até o momento e direções para evoluções futuras. 2. Fundamentos de Teste de Software e Experimentação O teste de software é uma atividade de garantia de qualidade que tem como objetivo revelar a presença de erros em programas [Myers 1979]. Essa atividade é dividida em quatro etapas: planejamento, projeto de casos de teste, execução e análises [Pressman 2005], as quais em geral ocorrem em paralelo com o desenvolvimento do software. Além da divisão por etapas, três níveis de teste podem ser considerados: teste de unidade, teste de integração e teste de sistema. O teste de unidade tem a finalidade de encontrar erros de lógica e implementação em cada módulo do software, separadamente. O teste de integração tem como objetivo descobrir erros associados às interfaces entre unidades. O teste de sistema procura detectar possíveis erros na integração do software com recursos e plataforma ao qual está vinculado, verificando assim se o funcionamento e o desempenho obtido correspondem ao esperado. Para garantir a ausência de erros em um programa seria necessário pelo menos testar o software com todos os valores do domínio de entrada possíveis. Essa tarefa, contudo, é reconhecida em geral como impraticável. Desta forma, técnicas e critérios de teste vêm sendo propostos, os quais definem um meio para selecionar casos de teste com grande probabilidade de identificar os erros existentes. As principais técnicas de teste para programas são as técnicas funcional, estrutural e baseada em erros. A técnica de teste funcional consiste em verificar para uma dada entrada fornecida

3 se a saída gerada é consistente com aquela especificada. Para derivar os requisitos de teste o testador utiliza somente a especificação funcional do programa. Alguns exemplos de critérios de teste funcional são: Particionamento em Classe de Equivalência, Análise do Valor Limite e Grafo de Causa-Efeito [Maldonado et al. 2007]. Na técnica de teste estrutural os requisitos de testes são determinados a partir da estrutura interna da implementação. A maioria dos critérios dessa técnica utiliza uma representação de programa conhecida como grafo de fluxo de controle. Os critérios dessa técnica são classificados em: critérios baseados em fluxo de controle nos quais se destacam [Pressman 2005]: Todos-Nós; Todos-Arcos e Todos-Caminhos; Critérios Baseados em Fluxo de Dados, sendo os principais exemplos os critérios Todas-Definições e Todos- Usos de Rapps e Weyuker [1985]. Na técnica de teste baseada em erros os requisitos de testes são construídos com base nos tipos de erros mais comuns encontrados no processo de desenvolvimento de software. Semeadura de Erros [Budd 1981] e Análise de Mutantes [DeMillo et al. 1978] são exemplos de critérios dessa técnica. Em decorrência da diversidade de ferramentas, processos, técnicas e critérios desenvolvidos para o teste de software, a engenharia de software experimental tem sido utilizada para caracterizar, comparar e verificar na prática essas novas propostas com base em evidências, confirmando nesse contexto a sua utilidade enquanto forma sistemática, disciplinada e controlada de avaliar atividades realizadas por humanos [Wohlin et al. 2000]. Na engenharia de software experimental a diferenciação ou classificação das estratégias experimentais depende principalmente do grau de controle e objetivos pretendidos para a investigação. Três principais tipos de estudos são considerados pela literatura: survey, estudo de caso e experimento controlado. O primeiro é um tipo de estudo que visa caracterizar retrospectivamente uma ferramenta ou técnica utilizada. Tem objetivos descritivos, explanatórios ou exploratórios e não oferece nenhum controle sobre execução, medição e manipulação de variáveis. O segundo estudo é utilizado para o acompanhamento de um projeto, atividade ou tarefa. É realizado por meio da observação contínua de um, ou um conjunto limitado de, atributo(s) correlacionado(s). Devido à falta de controle de execução, a validade interna desse tipo de experimento é limitada. O terceiro tipo de estudo é o experimento controlado o qual é caracterizado pelo controle sistemático das variáveis e do processo utilizado. Geralmente é uma investigação mais rigorosa e cara de ser praticada. Dentre os objetivos desse último tipo de estudo experimental podem-se citar: confirmação de teorias, confirmar conhecimento convencional, explorar relacionamentos, avaliar a predição de modelos ou validar medidas [Travassos 2002]. 3. Metodologia para definição dos Artefatos Para que os artefatos produzidos sejam significativos é interessante que os mesmos sejam definidos e construídos por meio de uma linha de trabalho que viabilize o seu uso e reaproveitamento na definição de futuros experimentos. Dessa forma, elegeu-se como metodologia da pesquisa conduzir um estudo experimental, investigando como hipóteses a existência ou não de diferenças de custos e strength entre os mesmos critérios de testes, quando aplicados nos paradigmas orientado a objetos (OO) e procedimental. A escolha dessas hipóteses foi motivada por duas razões. Em primeiro lugar, existe a motivação de verificar na prática dois dos dez axiomas estabelecidos em Weyuker [1988], com relação aos critérios adotados e os conjuntos de teste gerados para os mesmos durante o estudo. A segunda motivação da investigação é de que já existem vários estudos na literatura comparando custo e strength de critérios de teste distintos sobre programas de um mesmo paradigma, ou ignorando a influência deste ([Basili e Selby 1987],

4 [Weyuker 1990], [Bieman e Schultz 1992] e [Wong et al. 1994]). Entretanto, não foi detectado nenhum resultado comparando os mesmos critérios com relação a programas implementados em paradigmas diferentes. Logo a segunda razão colaboraria com o estabelecimento de resultados iniciais sobre essa questão. O conjunto de axiomas definidos em Weyuker [1988], consistem em propriedades usadas como base para avaliação dos critérios de teste. O primeiro axioma de interesse é o da antiextensionalidade. Esse axioma define que Existem dois programas P e Q tal que P é equivalente a Q, T é adequado para P, mas T não é adequado para Q. A propriedade reflete o fato de que a igualdade semântica entre dois programas não é suficiente para implicar que os mesmos devam necessariamente ser testados da mesma maneira. O teste baseado em programa não deve depender simplesmente das funções computadas pelo mesmo, mas também de sua implementação [Weyuker 1988]. O segundo axioma de interesse é o da mudança múltipla geral. Esse axioma define que Existem dois programas P e Q os quais possuem a mesma forma e um conjunto de teste T tal que T é adequado para P, mas T não é adequado para Q. De acordo com a autora, dois programas possuem a mesma forma se um pode ser transformado no outro aplicando-se um conjunto determinado de regras de tradução. Assim como o axioma da antiextensionalidade estabelece que a proximidade semântica não é suficiente para implicar que dois programas sejam necessariamente testados da mesma forma, esta propriedade estabelece que a proximidade sintática de dois programas também não é suficiente para implicar que eles devam necessariamente ser testados da mesma forma. Uma das principais características dessa pesquisa que a diferencia de grande parte dos trabalhos que envolvem experimento é a finalidade principal de sua condução. Enquanto a maioria dos estudos experimentais usa o processo de experimentação como meio para alcançar adeqüadamente a confirmação ou refutação das hipóteses investigadas em seu fim, neste o processo de experimentação é usado para levantar as necessidades em termos de recursos, resultados e ferramentas que seriam necessários para investigar as suas hipóteses (ou hipóteses semelhantes) em um contexto real, colaborando com a definição de futuros pacotes de laboratório. Logo, pode ser entendido como um estudo pré-experimental. Neste trabalho, o processo de experimentação controlada foi adotado, por prover uma forma sistemática e consistente de organizar o experimento, além de evidenciar as necessidades futuras para definição de experimentos controlados reais. Contudo, o estudo experimental proposto não pode ser caracterizado como um experimento controlado ou mesmo um quasi-experimento. De acordo com [Wohlin et al. 2000], o termo quasiexperimento é aplicado a um experimento quando não é realizada a distribuição aleatória de participantes aos diferentes tratamentos. Esta, entretanto, não é a única característica que diferencia o nosso estudo de um experimento controlado. Outras particularidades como o fato dos próprios projetistas desempenharem o papel de aplicadores do tratamento, usando artefatos elaborados e/ou adaptados pelos mesmos e o próprio comprometimento em gerar resultados de teste corretos que sirvam de oráculo para validação de resultados obtidos em estudos experimentais futuros, são propriedades que também são incomuns à caracterização de um experimento controlado ou um quasi-experimento. Além disso, essas características representam ameaças à validade dos resultados obtidos com relação às hipóteses estabelecidas e portanto deverão ser tratadas ao final da investigação.

5 3.1. Definição e Planejamento do Estudo Experimental A definição do estudo experimental foi feita com base no template Goal Question Metric [Briand et al. 1996]. Dessa forma, estabeleceu-se que seriam analizados os critérios de teste estruturais e funcionais aplicados no paradigma OO e os critérios de teste estruturais e funcionais aplicados no paradigma procedimental, para o propósito de caracterização e comparação, do ponto de vista do pesquisador, com respeito a custo e strength, no contexto de estudante de mestrado testando programas no domínio de estrutura de dados. Outra característica desse estudo é o de que os testes serão construídos e executados pelos próprios projetistas do experimento, ao invés do uso de participantes externos. Uma das razões dessa decisão foi a de que seria necessário definir uma massa de testes que permitisse não somente a coleta de medidas, mas que servisse de oráculo (Um oráculo pode ser entendido como um conjunto resposta tomado como verdade acerca de determinada questão) para futuros experimentos que venham a utilizar esse mesmo benchmark. Na caracterização do contexto do estudo, o mesmo foi considerado como sendo um experimento off-line, conduzido por dois estudantes de mestrado, abordando um problema real (identificação e comparação de custos e strength de critérios de teste), em um contexto específico (domínio de estruturas de dados). As hipóteses nulas definidas no estudo estabelecem que não existe diferença significativa de custo e strength dos critérios de teste, em razão do paradigma, entre os conjuntos A (programas procedimentais) e B (programas OO). As hipóteses alternativas correspondentes por sua vez, estabelecem que existe uma diferença significativa de custo e strength dos critérios de teste, em razão do paradigma, entre os conjuntos A e B Variáveis do Estudo e Princípios de Design As variáveis independentes consideradas de maior relevância na investigação foram: o paradigma em que os programas estão implementados; as ferramentas de teste usadas; os critérios de teste empregados; a ordem de aplicação dos testes; e a habilidade do testador em aplicar corretamente os critérios. Note-se que apesar destas serem variáveis independentes, a única considerada de interesse na investigação é o paradigma. Logo, esse é o único fator de interesse do experimento. As demais variáveis foram fixadas para não interferirem nos resultados obtidos. As variáveis dependentes foram eleitas de acordo com a sua capacidade de representar adequadamente os elementos do foco de qualidade do experimento. Sendo assim, considerou-se que o custo de critérios de teste, diferentemente do custo da atividade de teste, deve ser representado por medidas que revelem quão dispendiosos são os critérios, somente em razão das condições de satisfação impostas por sua aplicação sobre o conjunto de programas. Dessa forma, foram eleitas como variáveis dependendes para o foco de qualidade custo: número de elementos requeridos, número de elementos não-executáveis e número de casos de teste por programa e por critério, no qual a medição por critério consiste na média e desvio padrão dos valores obtidos para todos os programas, na aplicação de um critério específico, em um determinado paradigma. Para o foco de qualidade strength, as variáveis dependentes correpondem às porcentagens de adequação dos conjuntos de teste adequados a um critério em um determinado paradigma sobre o paradigma oposto, por programa e por critério. Como princípios de design aplicados ao experimento para minimizar a influência de fatores adversos sobre os resultados obtidos, podem-se citar:

6 Aninhamento do fator critério de teste em relação a cada tratamento do paradigma, com três níveis de critérios (a saber, funcionais, estruturais fluxo de controle e estruturais fluxo de dados). Esse design foi preferido em relação ao cruzado, já que ele permite a comparação dos paradigmas em relação a um mesmo tipo de critério, sem implicar na análise inversa, ou seja, também comparar os critérios em relação a um mesmo tipo de paradigma. Balanceamento entre os níveis de critérios aplicados, no qual cada nível é constituído de dois critérios representativos (particionamento de equivalência e análise valor limite no nível funcional; Todos-Nós e Todos-Arcos no nível estrutural fluxo de controle; Todos-Usos e Todos-Potenciais-Usos no nível estrutural fluxo de dados). O princípio de balanceamento também foi aplicado à quantidade de programas nos dois paradigmas, já que a comparação dos custos e strength nos dois critérios depende de um equilíbrio em termos do número de unidades testadas. Randomização da ordem dos testes, com relação à seqüência das especificações dos programas e o paradigma a ser considerado. Esse princípio foi aplicado por acreditarse que o testador ganhe habilidade em razão da ordem com que os programas são testados e da ordem com que cada paradigma pode ser priorizado, o que pode gerar tédio, ganho de experiência (maturação), cansaço acumulado durante a execução dos testes e afetar a corretude da aplicação dos tratamentos. A variável ferramentas de teste, tem um valor fixo e distinto para cada paradigma. No paradigma procedimental, o valor é determinado pelo par CUTE e Poketool para aplicação dos critérios funcionais e estruturais respectivamente [Sommerlad e Graf 2007, Chaim 1991]. No paradigma OO, JUnit e JaBUTi representam na mesma ordem, as ferramentas para aplicação dos critérios de teste [Riehle 2008, Vincenzi et al. 2003]. A escolha das ferramentas está amparada por um levantamento prévio das principais ferramentas candidatas a uso no experimento. Os critérios de escolha dessas ferramentas foram: apoio à aplicação dos critérios investigados; disponibilidade para uso livre; possibilidade de execução em plataforma linux e semelhança na utilização das ferramentas nos dois paradigmas. A especificação dos programas que compõem o conjunto procedimental é a mesma dos programas que compõem o conjunto OO. Essa é uma característica inerente à forma com que o estudo foi concebido e favorece os propósitos de comparação de custo e strength estabelecidos. Por fim, a habilidade dos testadores envolvidos na realização dos teste é considerada equivalente nas duas linguagens representativas de cada paradigma e com relação aos critérios de teste verificados Instrumentação A instrumentação foi elaborada em várias etapas, de forma a suprir as três categorias de artefatos requeridos para operação do experimento: objetos do experimento, guidelines e instrumentos de medida. A primeira consiste do benchmark de programas, aos quais são aplicados os tratamentos do experimento, dos documentos e dos formulários associados. Conforme explicado anteriormente, os programas que compõem o mesmo foram obtidos de Ziviani [2005b] (programas C, representantes do paradigma procedimental) e Ziviani [2005a] (programas Java, representantes do paradigma OO). Contudo, por terem sido projetados com propósito exclusivamente acadêmico, esses programas não apresentavam-se

7 adequados para uso direto no estudo experimental. Um dos motivos foi a ausência de especificações em um formato apropriado para os testes e independente para cada programa. O outro motivo, foi a necessidade de adequar as implementações entre os dois paradigmas: algumas operações implementadas na linguagem OO simplesmente não existiam ou eram diferentes daquelas implementadas na linguagem procedimental, apesar de se referirem à mesma especificação. Isso exigiu um trabalho prévio de preparação desses programas seguindo alguns procedimentos padrões definidos. O primeiro foi separar as implementações referentes a cada especificação. Em muitos casos, uma mesma especificação possuia um número diferente de classes implementadas em Java com relação ao número de programas em C. O relacionamento especificação/classes e especificação/programa C foi feito por meio de um trabalho seqüencial de análise e correspondência entre cada solução comum estabelecida nos dois livros com seus referidos programas. Após o estabelecimento dessa correspondência, as especificações foram descritas em um formato padrão, pré-estabelecido. Esse formato de especificação foi derivado e adaptado a partir do pacote de laboratório de Basili et al. [2008]. Além das especificações, a aplicação dos tratamentos no experimento requer outros documentos que auxiliem na execução dos testes. Para tanto, foi concebido um documento de implementação, de forma a suprir o testador das informações necessárias para a construção dos casos de teste funcionais sem que fosse necessária a leitura do código-fonte das implementações. Esse documento serve ainda para registrar métricas de implementação, cujos valores podem ser pré-estabelecidos pelo projetista do experimento, ou coletadas durante sua operação, dependendo da intenção sobre as mesmas no contexto do experimento. Dois formulários também foram estabelecidos para aplicação dos testes: um formulário auxiliar para definição das classes de equivalência durante os testes funcionais e um formulário de teste, para registrar os casos de teste para cada critério avaliado e as medidas de teste auferidas. Além desses formulários e documentos, a instrumentação do estudo-experimental conta com os códigos-fontes dos programas em linguagem C e Java, as ferramentas de teste e um documento de guidelines para condução do experimento. Como instrumento de medida, são usadas as próprias ferramentas de teste para a medição do número de requisitos de teste e a ferramenta Code Analyzer para coleta de algumas medidas de implementação. Além desses artefatos, houve a preocupação de configurar um ambiente uniforme que viabilizasse a aplicação dos testes durante a operação do experimento. Para atender essa necessidade, uma máquina virtual foi definida na qual foram configuradas e instaladas as quatro ferramentas de teste adotadas assim como os pacotes relativos a cada programa a ser testados. 4. Resultados Preliminares Até o estágio atual do trabalho, a maioria dos esforços foram direcionados para a definição e planejamento do estudo experimental e dos artefatos provenientes dessas fases. Como resultado, durante um período de 3 meses, um total de 34 especificações e 68 programas foram adaptados e reestruturados para estabelecer o conjunto de operações equivalentes. Além disso, 68 documentos de implementação foram gerados, para cada um dos quais 12 métricas de implementação foram coletadas além da própria definição dos templates dos formulários e documentos discutidos na seção anterior. Com relação aos resultados do estudo experimental, o tratamento foi aplicado a 5 especificações (10 programas) do total disponível. Apesar do tamanho do subconjunto de

8 Procedimental Funcional Estrutural-FC Estrutural-FD Programas E.R. N.E C.T. E.R. N.E. C.T. E.R. N.E. C.T. Lista Arranjo Pilha Arranjo Grafo Matriz Adj Ord. Parcial Casamento Exato Média ,8 61 0,4 16,8 265,6 17,2 19,8 Desv. Padrão 3 0 2,77 40,3 0,89 2,77 247,9 18,95 5,167 Orientado a Objetos Lista Arranjo Pilha Arranjo Grafo Matriz Adj Ord. Parcial Casamento Exato Média , ,2 500, ,4 Desv. Padrão 3 0 2,77 56,73 0 3,03 469,4 27,67 4,93 Tabela 1. Valores das três métricas de teste: n Elementos Requeridos (E.R.), n Elementos Requeridos não-executáveis (N.E.), n Casos de Teste (C.T.) programas testados ainda não permitir o uso de técnicas de inferência estatísticas, algumas informações interessantes puderam ser observadas a partir das medidas coletadas. Conforme pode-se observar na Tabela 1, apesar dos elementos requeridos gerados para os critérios funcionais serem os mesmos para os programas nos dois paradigmas, nos critérios estruturais Fluxo de Controle e Fluxo de Dados, a quantidade média de elementos requeridos gerados passa a ter uma diferença considerável no paradigma OO em relação ao procedimental. Mesmo assim, o número de casos de teste gerados para a adequação desses critérios, se mantem semelhante nos dois paradigmas. Esse primeiro resultado pode estar sendo influenciado pelo fato da ferramenta de teste estrutural em C aplicar algumas otimizações durante o processo de geração dos elementos requeridos, o que não ocorre na ferramenta em Java. Logo, por ser uma ameaça à validade de construção dos resultados, essa métrica não deverá ser usada isoladamente com propósito de comparação entre os paradigmas. Da mesma forma, o número de elementos requeridos não executáveis pode estar sendo influenciado por esses algoritmos de otimização, e a mesma decisão para a métrica de elementos requeridos deverá ser tomada. Apesar de não poderem ser consideradas isoladamente, a razão entre o número de elementos requeridos não-executáveis detectados e o número de elementos requeridos gerados foi adotada como uma solução para minimizar a ameaça de validade identificada e atender os propósitos comparativos pré-estabelecidos. Além disso, as medidas coletadas para essas duas métricas poderão ser úteis na definição de futuros estudos experimentais envolvendo esse benchmark. Uma outra informação interessante que pode ser observada na Tabela 2, é que as medidas de implementação mantiveram-se próximas entre os dois paradigmas, mesmo com as diferenças das medidas de teste identificadas. Apesar de prematuro para obter conclusões, essa informações fornecem indícios de que somente propriedades estáticas dos códigos podem não ser suficientes para revelar a possível diferença de custo de teste entre os dois paradigmas.

9 Procedimental Orientado a Objetos Programas n un. LOC n desv. McCabe n un. LOC n desv. McCabe Lista Arranjo Pilha Arranjo Grafo Matriz de Adj Ord. Parcial Casamento Exato Média 6, , ,2 20 Desv. Padrão 2,59 42,35 10,30 12,94 2,59 30,75 10,62 12,88 Tabela 2. Valores das quatro principais métricas de implementação: número de unidades (n un.), linhas de código (LOC), número de desvios (n desv) e complexidade de McCabe (McCabe). A verificação dos axiomas de Weyuker deverá ser feita no final do trabalho, quando os resultados de custo e strength de todo o conjunto de programas estiverem disponíveis. 5. Conclusão Neste artigo foi apresentado o panorama geral de um estudo experimental em progresso comparando critérios de teste funcionais e estruturais nos paradigmas de desenvolvimento Procedimental e Orientado a Objetos sobre um conjunto representativo de programas do domínio de estrutura de dados. O macro-objetivo deste trabalho é definir subsídios que contribuam com a definição de futuros experimentos e pacotes de laboratório em teste de software, envolvendo os critérios e paradigmas abordados. Os propósitos imediatos da investigação visam o provimento de resultados iniciais para caracterização das possíveis diferenças de custo e strength entre esses critérios, em decorrência da mudança de paradigma. Desta forma, foram descritas algumas informações relevantes sobre o planejamento e a instrumentação desse estudo experimental e, ao final, alguns resultados parciais obtidos foram ilustrados. Dentro do nosso grupo de pesquisa, um outro trabalho concomitante a este está sendo desenvolvido porém com foco no critério análise de mutantes. Os artefatos funcionais assim como o benchmark utilizado, estão sendo elaborados e compartilhados entre os dois trabalhos. A idéia é que com a conclusão de ambas as investigações, disponha-se de resultados e materiais de experimentação nas três técnicas de teste de software investigadas. Referências Basili, V., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sørumgård, S., e Zelkowitz, M. (2008). Lab Package for the Empirical Investigation of Perspective-Based Reading. World Wide Web. Disponível em: package/manual.html. Basili, V. R. e Selby, R. W. (1987). Comparing the effectiveness of software testing strategies. IEEE Transactions on Software Engineering, 13(12): Bieman, J. M. e Schultz, J. L. (1992). An empirical evaluation (and specification) of the all-du-paths testing criterion. Software Engineering Journal, p Briand, L. C., Differding, M. C., e Rombach, H. D. (1996). Practical guidelines for measurement-based process improvement. Software Process Improvement and Practice, 2(4):253,280.

10 Budd, T. A. (1981). Mutation analysis: Ideas, example, problems and prospects. Computer Program Testing, p Chaim, M. L. (1991). Poke-Tool uma ferramenta para suporte ao teste estrutural de programas baseados em análise de fluxo de dados. Dissertação de Mestrado, DCA/FEEC/UNICAMP, Campinas, SP. DeMillo, R. A., Lipton, R. J., e Sayward, F. G. (1978). Hints on test data selection: Help for the practicing programmer. IEEE Computer,11(4): Maldonado, J. C., Delamaro, M. E., e Jino, M. (2007). Introdução ao Teste de Software. editora Elsevier, 1st edition. Michaellis (2008). Moderno Dicionário da Língua Portuguesa. Editora Melhoramentos. Myers, G. J. (1979). The Art of Software Testing. Wiley, New York. Pressman, R. S. (2005). Software engineering: A practitioner s approach. ed. McGraw- Hill, 6th. edition. Rapps, S. e Weyuker, E. J. (1985). Selecting software test data using data flow information. IEEE Transactions on Software Engineering, SE-11(4): Riehle, D. (2008). Junit 3.8 documented using collaborations. SIGSOFT Softw. Eng. Notes, 33(2):1 28. Rothermel, G. e S. Elbaum, H. D. (2005). Supporting controlled experimentation with testing techniques: An infrastructure and its potential impact. Empirical Software Engineering: An International Journal. Sommerlad, P. e Graf, E. (2007). Cute: C++ unit testing easier. In OOPSLA 07: Companion to the 22nd ACM SIGPLAN conference on Object oriented programming systems and applications companion, p , New York, NY, USA. ACM. Travassos, G. (2002). Introdução à engenharia de software experimental. Relatório Técnico RT-ES. Vincenzi, A. M. R., Wong, W. E., Delamaro, M. E., e Maldonado, J. C. (2003). JaBUTi: A coverage analysis tool for java programs. In XVII Simpósio Brasileiro de Engenharia de Software (SBES 2003), Manaus, AM. Weyuker, E. J. (1988). The evaluation of program-based software teste data adequacy criteria. Communications of the ACM, 31(6): Weyuker, E. J. (1990). The cost of data flow testing: an empirical study. IEEE Transactions on Software Engineering, 16(2): Wohlin, C., Runeson, P., Host, M., Ohlsson, M. C., Regnell, B., e Wesslén, A. (2000). Experimentation in software engineering: an introduction. Kluwer Academic Publishers. Wong, W. E., Mathur, A. P., e Maldonado, J. C. (1994). Mutation versus all-uses: An empirical evaluation of cost, strength, and effectiveness. In International Conference on Software Quality and Productivity, p , Hong Kong. Ziviani, N. (2005a). Projeto de Algoritmos com Implementações em Java e C++. Thomson. Ziviani, N. (2005b). Projeto de Algoritmos com Implementações em Pascal e C. Thomson, 2nd. edition.