Instituto de Cincias Matemticas e de Computao e a ca

ISSN - 0103-2585

INTRODUCAO AO TESTE DE SOFTWARE (Verso 2004-01 ) a

Jos Carlos Maldonado e Ellen Francine Barbosa Auri Marcelo Rizzo Vincenzi Mrcio Eduardo Delamaro a Simone do Rocio Senger de Souza Mario Jino

No 65

NOTAS DIDATICAS DO ICMC

So Carlos a ABRIL/2004

Introduco ao Teste de Software a

(Verso 2004-01 ) a

Jos Carlos Maldonado e Ellen Francine Barbosa Auri Marcelo Rizzo Vincenzi Universidade de So Paulo ICMC/USP a {jcmaldon, francine, auri}@icmc.usp.br Mrcio Eduardo Delamaro a Centro Universitrio Eur a pides de Mar UNIVEM lia delamaro@fundanet.br Simone do Rocio Senger de Souza Universidade Estadual de Ponta Grossa UEPG srocio@uepg.br Mario Jino Universidade Estadual de Campinas DCA/FEEC/UNICAMP jino@dca.fee.unicamp.br

Resumo As exigncias por softwares com maior qualidade tm motivado a deniao de e e c mtodos e tcnicas para o desenvolvimento de softwares que atinjam os padres de e e o qualidade impostos. Com isso, o interesse pela atividade de teste de software vem aumentando nos ultimos anos. Vrios pesquisadores tm investigado os diferentes a e critrios de teste, buscando obter uma estratgia de teste com baixo custo de aplie e caao, mas ao mesmo tempo, com grande capacidade em revelar erros. O objetivo c deste minicurso apresentar os aspectos tericos e prticos relacionados ` ativie o a a dade de teste de software. Uma s ntese das tcnicas de teste funcional, estrutural e e baseada em erros, bem como de critrios de teste pertencentes a cada uma delas, e ser apresentada. Fatores utilizados na comparaao e avaliaao de critrios de teste a c c e de software (custo, eccia e strength) tambm sero abordados, tanto do ponto a e a de vista terico como emp o rico. A importncia da automatizaao da atividade de a c teste ser destacada, caracterizando-se os esforos da comunidade cient a c ca nessa direao. Dar-se- nfase ao critrio de teste Anlise de Mutantes apresentando uma c ae e a reviso histrica do seu surgimento e desenvolvimento. Aspectos tericos e prtia o o a cos de sua utilizaao sero abordados e as estratgias que procuram minimizar o c a e

Partes deste trabalho foram extra das de [1] e [2].

custo de aplicaao desse critrio sero discutidas. Ser apresentado o critrio Muc e a a e taao de Interface que estende o critrio Anlise de Mutantes visando ` atividade c e a a de teste no n de integraao. A atividade de teste e os problemas pertinentes ` vel c a ela sero ilustrados utilizando-se as ferramentas PokeTool, Proteum e P a ROTEU M, M/I que apiam, respectivamente, critrios estruturais, o critrio Anlise de Mutantes o e e a e o critrio Mutaao de Interface. Identicam-se ainda outras iniciativas e esforos e c c da comunidade para a automatizaao desses critrios. Sero apresentadas tambm c e a e as extenses do critrio Anlise de Mutantes para aplicaao no contexto de eso e a c pecicaoes, discutindo sua deniao para validaao de especicaoes baseadas em c c c c Statecharts, Mquinas de Estados Finitos, Redes de Petri, Estelle e SDL, alm de a e extenses destinadas ao teste de programas Orientado a Objetos. Perspectivas e o trabalhos de pesquisa sendo realizados nessas reas tambm sero discutidos. a e a

Introduo ca

A Engenharia de Software evoluiu signicativamente nas ultimas dcadas procurando e estabelecer tcnicas, critrios, mtodos e ferramentas para a produo de software, em e e e ca conseqncia da crescente utilizao de sistemas baseados em computao em praticaue ca ca mente todas as reas da atividade humana, o que provoca uma crescente demanda por a qualidade e produtividade, tanto do ponto de vista do processo de produo como do ca ponto de vista dos produtos gerados. A Engenharia de Software pode ser denida como uma disciplina que aplica os princ pios de engenharia com o objetivo de produzir software de alta qualidade a baixo custo [3]. Atravs de um conjunto de etapas que envolvem o dee senvolvimento e aplicao de mtodos, tcnicas e ferramentas, a Engenharia de Software ca e e oferece meios para que tais objetivos possam ser alcanados. c O processo de desenvolvimento de software envolve uma srie de atividades nas quais, e apesar das tcnicas, mtodos e ferramentas empregados, erros no produto ainda podem e e ocorrer. Atividades agregadas sob o nome de Garantia de Qualidade de Software tm e sido introduzidas ao longo de todo o processo de desenvolvimento, entre elas atividades de VV&T Vericao, Validao e Teste, com o objetivo de minimizar a ocorrncia de ca ca e erros e riscos associados. Dentre as tcnicas de vericao e validao, a atividade de teste e ca ca uma das mais utilizadas, constituindo-se em um dos elementos para fornecer evidncias e e da conabilidade do software em complemento a outras atividades, como por exemplo o uso de revises e de tcnicas formais e rigorosas de especicao e de vericao [4]. o e ca ca A atividade de teste consiste de uma anlise dinmica do produto e uma atividade a a e relevante para a identicao e eliminao de erros que persistem. Do ponto de vista de ca ca qualidade do processo, o teste sistemtico uma atividade fundamental para a ascenso a e a ao N vel 3 do Modelo CMM do Software Engineering Institute SEI [5]. Ainda, o conjunto de informao oriundo da atividade de teste signicativo para as atividades de ca e depurao, manuteno e estimativa de conabilidade de software [3,69]. Salienta-se que ca ca a atividade de teste tem sido apontada como uma das mais onerosas no desenvolvimento de software [3, 10, 11]. Apesar deste fato, Myers observa que aparentemente conhece-se muito menos sobre teste de software do que sobre outros aspectos e/ou atividades do desenvolvimento de software [10]. O teste de produtos de software envolve basicamente quatro etapas: planejamento de testes, projeto de casos de teste, execuo e avaliao dos resultados dos testes [3,4,10,11]. ca ca Essas atividades devem ser desenvolvidas ao longo do prprio processo de desenvolvimento o 2

de software, e em geral, concretizam-se em trs fases de teste: de unidade, de integrao e ca e de sistema. O teste de unidade concentra esforos na menor unidade do projeto de c software, ou seja, procura identicar erros de lgica e de implementao em cada mdulo o ca o do software, separadamente. O teste de integrao uma atividade sistemtica aplicada ca e a durante a integrao da estrutura do programa visando a descobrir erros associados `s ca a interfaces entre os mdulos; o objetivo , a partir dos mdulos testados no n de unidade, o e o vel construir a estrutura de programa que foi determinada pelo projeto. O teste de sistema, realizado aps a integrao do sistema, visa a identicar erros de funes e caracter o ca co sticas de desempenho que no estejam de acordo com a especicao [3]. a ca Um ponto crucial na atividade de teste, independentemente da fase, o projeto e/ou e a avaliao da qualidade de um determinado conjunto de casos de teste T utilizado para ca o teste de um produto P , dado que, em geral, impraticvel utilizar todo o dom e a nio de dados de entrada para avaliar os aspectos funcionais e operacionais de um produto em teste. O objetivo utilizarem-se casos de teste que tenham alta probabilidade de encontrar e a maioria dos defeitos com um m nimo de tempo e esforo, por questes de produtividade. c o Segundo Myers [10], o principal objetivo do teste de software revelar a presena de erros e c no produto. Portanto, o teste bem sucedido aquele que consegue determinar casos de e teste para os quais o programa em teste falhe. Tem-se observado que a prpria atividade o de projeto de casos de teste bastante efetiva em evidenciar a presena de defeitos de e c software. Em geral, os critrios de teste de software so estabelecidos, basicamente, a partir e a de trs tcnicas: a funcional, a estrutural e a baseada em erros. Na tcnica funcional, e e e os critrios e requisitos de teste so estabelecidos a partir da funo de especicao e a ca ca do software; na tcnica estrutural, os critrios e requisitos so derivados essencialmente e e a a partir das caracter sticas de uma particular implementao em teste; e, na tcnica ca e baseada em erros, os critrios e requisitos de teste so oriundos do conhecimento sobre e a erros t picos cometidos no processo de desenvolvimento de software. Observa-se tambm e o estabelecimento de critrios de gerao de seqncias de teste baseados em Mquinas e ca ue a de Estados Finito [12, 13]. Esses ultimos tm sido aplicados no contexto de validao e e ca teste de sistemas reativos e de sistemas orientados a objetos [1422]. Segundo Howden [23], o teste pode ser classicado de duas maneiras: teste baseado em especicao (specication-based testing) e teste baseado em programa (programca based testing). De acordo com tal classicao, tm-se que os critrios da tcnica funcional ca e e e so baseados em especicao e tanto os critrios estruturais quanto baseados em erros a ca e so considerados critrios baseados em implementao. a e ca No teste baseado em especicao (ou teste caixa-preta) o objetivo determinar se o ca e programa satisfaz aos requisitos funcionais e no-funcionais que foram especicados. O a problema que, em geral, a especicao existente informal e, desse modo, a determie ca e nao da cobertura total da especicao que foi obtida por um dado conjunto de casos ca ca de teste tambm informal [24]. Entretanto, os critrios de teste baseados em especie e e cao podem ser utilizados em qualquer contexto (procedimental ou orientado a objetos) ca e em qualquer fase de teste sem a necessidade de modicao. Exemplos desses critrios ca e so: particionamento em classe de equivalncia [3], anlise do valor limite [3], grafo de a e a causa-efeito [3] e teste baseado em estado [16, 19]. Ao contrrio do teste baseado em especicao, o teste baseado em programa (ou teste a ca caixa-branca) requer a inspeo do cdigo fonte e a seleao de casos de teste que exercitem ca o c partes do cdigo e no de sua especicao [24]. o a ca 3

 E importante ressaltar que as tcnicas de teste devem ser vistas como complementares e e a questo est em como utiliz-las de forma que as vantagens de cada uma sejam melhor a a a exploradas em uma estratgia de teste que leve a uma atividade de teste de boa qualidade, e ou seja, ecaz e de baixo custo. As tcnicas e critrios de teste fornecem ao desenvolvee e dor uma abordagem sistemtica e teoricamente fundamentada, alm de constitu a e rem um mecanismo que pode auxiliar a avaliar a qualidade e a adequao da atividade de teste. ca Critrios de teste podem ser utilizados tanto para auxiliar na gerao de conjunto de casos e ca de teste como para auxiliar na avaliao da adequao desses conjuntos. ca ca Dada a diversidade de critrios que tm sido estabelecidos [3, 4, 10, 11, 2535] e recone e hecido o carter complementar das tcnicas e critrios de teste [3544], um ponto crucial a e e que se coloca nessa perspectiva a escolha e/ou a determinao de uma estratgia de e ca e teste, que em ultima anlise passa pela escolha de critrios de teste, de forma que as a e vantagens de cada um desses critrios sejam combinadas objetivando uma atividade de e teste de maior qualidade. Estudos tericos e emp o ricos de critrios de teste so de extrema e a relevncia para a formao desse conhecimento, fornecendo subs a ca dios para o estabelecimento de estratgias de baixo custo e alta eccia. Identicam-se diversos esforos da e a c comunidade cient ca nessa direo [35, 4143, 4551]. ca Fundamental se faz o desenvolvimento de ferramentas de teste para o suporte ` ativia dade de teste propriamente dita, uma vez que essa atividade muito propensa a erros, e alm de improdutiva, se aplicada manualmente, bem como para dar apoio a estudos e emp ricos que visem a avaliar e a comparar os diversos critrios de teste. Assim, a e disponibilidade de ferramentas de teste propicia maior qualidade e produtividade para as atividades de teste. Observam-se na literatura esforos da comunidade cient c ca nessa direo [11, 35, 43, 5267]. ca Pode-se observar que os critrios baseados em anlise de uxo de dados [27, 2933] e a e o critrio Anlise de Mutantes (Mutation Analysis) [25, 34, 68] tm sido fortemente e a e investigados por diversos pesquisadores em diferentes aspectos [7, 37, 38, 41, 42, 44, 46, 50, 57, 59, 6979]. Resultados desses estudos fornecem evidncias de que esses critrios, e e hoje investigados fundamentalmente no meio acadmico, `s vezes em cooperao com e a ca a indstria, podem, em mdio prazo, constituir o estado da prtica em ambientes de u e a produo de software. Uma forte evidncia nessa direo o esforo alocado pela Telcordia ca e ca e c Technologies (USA) no desenvolvimento da xSuds [80], um ambiente que apia a aplicao o ca de critrios baseados em anlise de uxo de controle e de dados em programas C e C++. e a De uma maneira geral, pode-se classicar as contribuies para a rea de Teste de co a Software em: Estudos Tericos, Estudos Emp o ricos e Desenvolvimento de Ferramentas. Este texto aborda esses trs aspectos, dando-se nfase a estudos tericos e emp e e o ricos de critrios baseados em anlise de uxo de dados e do critrio Anlise de Mutantes para o e a e a teste de programas em n de unidade, assim como as ferramentas que apiam a aplivel o cao desses critrios. Com esse objetivo em mente, o texto est organizado da seguinte ca e a forma: na Seo 2 so introduzidos a terminologia e os conceitos bsicos pertinentes ` ca a a a atividade de teste. Na Seo 3 so apresentados os critrios de teste mais difundidos das ca a e tcnicas funcional, estrutural e baseada em erros e ilustrados os principais aspectos ope eracionais das ferramentas PokeTool, Proteum e P ROTEU M que apiam a aplicao de M/I o ca critrios estruturais e dos critrios Anlise de Mutantese Mutao de Interface, respectivae e a ca mente. Na Seo 4 so identicados os principais esforos e iniciativas de automatizao ca a c ca e na Seo 5 so sintetizados os principais resultados de estudos emp ca a ricos envolvendo os critrios apresentados neste texto. Na Seo 6 so apresentados alguns trabalhos que e ca a 4

aplicam critrios de teste para validao de especicaoes formais em Redes de Petri, e ca c Mquinas de Estados Finitos, Statecharts e Estelle. Na Seo 7 so apresentados alguns a ca a trabalhos que aplicam o teste de mutao em programas OO. Na Seo 8 so apresentadas ca ca a as concluses e perspectivas de trabalhos futuros. o

Terminologia e Conceitos Bsicos a

A IEEE tem realizado vrios esforos de padronizao, entre eles para padronizar a a c ca terminologia utilizada no contexto de Engenharia de Software. O padro IEEE nmero a u 610.12-1990 [81] diferencia os termos: defeito (fault) passo, processo ou denio de daca dos incorreto, como por exemplo, uma instruo ou comando incorreto; engano (mistake) ca ao humana que produz um resultado incorreto, com por exemplo, uma ao incorreta ca ca tomada pelo programador; erro (error) diferena entre o valor obtido e o valor esperado, c ou seja, qualquer estado intermedirio incorreto ou resultado inesperado na execuo do a ca programa constitui um erro; e falha (failure) produo de uma sa incorreta com ca da relao ` especicao. Neste texto, os termos engano, defeito e erro sero referenciaca a ca a dos como erro (causa) e o termo falha (conseqncia) a um comportamento incorreto do ue programa. De uma forma geral, os erros so classicados em: erros computacionais a o erro provoca uma computao incorreta mas o caminho executado (seqncias de ca ue comandos) igual ao caminho esperado; e erros de dom e nio o caminho efetivamente executado diferente do caminho esperado, ou seja, um caminho errado selecionado. e e A atividade de teste permeada por uma srie de limitaes [23,31,8284]. Em geral, os e e co seguintes problemas so indecid a veis: dados dois programas, se eles so equivalentes; dados a duas seqncias de comandos (caminhos) de um programa, ou de programas diferentes, ue se eles computam a mesma funo; e dado um caminho se ele executvel ou no, ou ca e a a seja, se existe um conjunto de dados de entrada que levam ` execuo desse caminho. a ca Outra limitao fundamental a correo coincidente o programa pode apresentar, ca e ca coincidentemente, um resultado correto para um item particular de um dado d D, ou seja, um particular item de dado ser executado, satisfazer a um requisito de teste e no a revelar a presena de um erro. c Diz-se que um programa P com dom nio de entrada D correto com respeito a uma e especicao S se S(d) = P (d) para qualquer item de dado d pertencente a D, ou seja, se o ca comportamento do programa est de acordo com o comportamento esperado para todos os a dados de entrada. Dados dois programas P1 e P2 , se P1 (d) = P2 (d), para qualquer d D, diz-se que P1 e P2 so equivalentes. No teste de software, pressupe-se a existncia de a o e um orculo o testador ou algum outro mecanismo que possa determinar, para qualquer a item de dado d D, se S(d) = P (d), dentro de limites de tempo e esforos razoveis. c a Um orculo decide simplesmente se os valores de sa so corretos. Sabe-se que o teste a da a exaustivo impraticvel, ou seja, testar para todos os elementos poss e a veis do dom nio de entrada , em geral, caro e demanda muito mais tempo do que o dispon e vel. Ainda, deve-se salientar que no existe um procedimento de teste de propsito geral que possa a o ser usado para provar a corretitude de um programa. Apesar de no ser poss a vel, atravs e de testes, provar que um programa est correto, os testes, se conduzidos sistemtica e a a criteriosamente, contribuem para aumentar a conana de que o software desempenha as c funes especicadas e evidenciar algumas caracter co sticas m nimas do ponto de vista da qualidade do produto.

Assim, duas questes so chaves na atividade de teste: Como os dados de teste devem o a ser selecionados? e Como decidir se um programa P foi sucientemente testado?. Critrios para selecionar e avaliar conjuntos de casos de teste so fundamentais para o e a sucesso da atividade de teste. Tais critrios devem fornecer indicao de quais casos de e ca teste devem ser utilizados de forma a aumentar as chances de revelar erros ou, quando erros no forem revelados, estabelecer um n elevado de conana na correo do programa. a vel c ca Um caso de teste consiste de um par ordenado (d, S(d)), no qual d D e S(d) a e respectiva sa esperada. da Dados um programa P e um conjunto de casos de teste T , denem-se: Critrio de Adequao de Casos de Teste: predicado para avaliar T no teste e ca de P ; Mtodo de Seleo de Casos de Teste: procedimento para escolher casos de e ca teste para o teste de P . Existe uma forte correspondncia entre mtodos de seleo e critrios de adequao e e ca e ca de casos de teste pois, dado um critrio de adequao C, existe um mtodo de seleo e ca e ca M C que estabelece: selecione T tal que T seja adequado a C. De forma anloga, dado a um mtodo de seleo M , existe um critrio de adequao CM que estabelece: T e ca e ca e adequado se foi selecionado de acordo com M . Desse modo, costuma-se utilizar o termo critrio de adequao de casos de teste (ou simplesmente critrio de teste) tambm para e ca e e designar mtodo de seleo [4, 55]. Dados P , T e um critrio C, diz-se que o conjunto de e ca e casos de teste T C-adequado para o teste de P se T preencher os requisitos de teste e estabelecidos pelo critrio C. Outra questo relevante nesse contexto dado um conjunto e a e T C1 -adequado, qual seria um critrio de teste C2 que contribuiria para aprimorar T ? Essa e questo tem sido investigada tanto em estudos tericos quanto em estudos emp a o ricos. Em geral, pode-se dizer que as propriedades m nimas que devem ser preenchidas por um critrio de teste C so: e a 1. garantir, do ponto de vista de uxo de controle, a cobertura de todos os desvios condicionais; 2. requerer, do ponto de vista de uxo de dados, ao menos um uso de todo resultado computacional; e 3. requerer um conjunto de casos de teste nito. As vantagens e desvantagens de critrios de teste de software podem ser avaliadas e atravs de estudos tericos e emp e o ricos. Do ponto de vista de estudos tericos, esses o estudos tm sido apoiados principalmente por uma relao de incluso e pelo estudo da e ca a complexidade dos critrios [31,83,85]. A relao de incluso estabelece uma ordem parcial e ca a entre os critrios, caracterizando uma hierarquia entre eles. Diz-se que um critrio C1 e e inclui um critrio C2 se para qualquer programa P e qualquer conjunto de casos de teste e T1 C1 -adequado, T1 for tambm C2 -adequado e existir um programa P e um conjunto e T2 C2 -adequado que no seja C1 -adequado. A complexidade denida como o nmero a e u mximo de casos de teste requeridos por um critrio, no pior caso. No caso dos critrios a e e baseados em uxo de dados, esses tm complexidade exponencial, o que motiva a conduo e ca de estudos emp ricos para determinar o custo de aplicao desses critrios do ponto de ca e 6

vista prtico. Mais recentemente, alguns autores tm abordado do ponto de vista terico a e o a questo de eccia de critrios de teste, e tm denido outras relaes, que captem a a a e e co capacidade de revelar erros dos critrios de teste [37, 38, 86, 87]. e Do ponto de vista de estudos emp ricos, trs aspectos costumam ser avaliados: custo, e eccia e strength (ou diculdade de satisfao) [40,41,46,73,78,88]. O fator custo reete o a ca esforo necessrio para que o critrio seja utilizado; em geral medido pelo nmero de cac a e e u sos de teste necessrios para satisfazer o critrio. A eccia refere-se ` capacidade que um a e a a critrio possui de detectar a presena de erros. O fator strength refere-se ` probabilidade e c a de satisfazer-se um critrio tendo sido satisfeito um outro critrio [41]. e e Uma atividade muito citada na conduo e avaliao da atividade de teste a anlise de ca ca e a cobertura, que consiste basicamente em determinar o percentual de elementos requeridos por um dado critrio de teste que foram exercitados pelo conjunto de casos de teste e utilizado. A partir dessa informao o conjunto de casos de teste pode ser aprimorado, ca acrescentando-se novos casos de teste para exercitar os elementos ainda no cobertos. a Nessa perspectiva, fundamental o conhecimento sobre as limitaes tericas inerentes ` e co o a atividade de teste, pois os elementos requeridos podem ser no executveis, e em geral, a a determinar a no executabilidade de um dado requisito de teste envolve a participao do a ca testador.

Tcnicas e Critrios de Teste e e

Conforme mencionado anteriormente, para se conduzir e avaliar a qualidade da atividade de teste tm-se as tcnicas de teste funcional, estrutural e baseada em erros. Tais e e tcnicas diferenciam-se pela origem da informao utilizada na avaliao e construo dos e ca ca ca conjuntos de casos de teste [4]. Neste texto apresentam-se com mais detalhes as duas ultimas tcnicas, mais especicamente os critrios Potenciais-Usos [4], o critrio Anlise e e e a de Mutantes [34] e o critrio Mutao de Interface [35], e as ferramentas de suporte Pokee ca Tool [60, 61, 89], Proteum [62] e P ROTEU M [35, 90]. Atravs desses critrios, ilustram-se M/I e e os principais aspectos pertinentes ` atividade de teste de cobertura de software. Para propa iciar uma viso mais abrangente, apresentam-se primeiramente uma viso geral da tcnica a a e funcional e os critrios mais conhecidos dessa tcnica. O programa identier (Figura 1) e e ser utilizado para facilitar a ilustrao dos conceitos desenvolvidos neste texto. a ca

3.1

Tcnica Funcional e

O teste funcional tambm conhecido como teste caixa preta [10] pelo fato de tratar o e e software como uma caixa cujo contedo desconhecido e da qual s poss visualizar u e oe vel o lado externo, ou seja, os dados de entrada fornecidos e as respostas produzidas como sa da. Na tcnica de teste funcional so vericadas as funes do sistema sem se preocupar e a co com os detalhes de implementao. ca O teste funcional envolve dois passos principais: identicar as funes que o software co deve realizar e criar casos de teste capazes de checar se essas funes esto sendo realizadas co a pelo software [3]. As funes que o software deve possuir so identicadas a partir de sua co a especicao. Assim, uma especicao bem elaborada e de acordo com os requisitos do ca ca usurio essencial para esse tipo de teste. a e Alguns exemplos de critrios de teste funcional so [3]: e a

/**************************************************************************************** Identifier.c ESPECIFICACAO: O programa deve determinar se um identificador eh ou nao valido em Silly Pascal (uma estranha variante do Pascal). Um identificador valido deve comecar com uma letra e conter apenas letras ou digitos. Alem disso, deve ter no minimo 1 caractere e no maximo 6 caracteres de comprimento ****************************************************************************************/ #include <stdio.h> main () { char achar; int length, valid_id; length = 0; valid_id = 1; printf ("Identificador: "); achar = fgetc (stdin); valid_id = valid_s(achar); if(valid_id) { length = 1; } achar = fgetc (stdin); while(achar != \n) { if(!(valid_f(achar))) { valid_id = 0; } length++; achar = fgetc (stdin); } if(valid_id && (length >= 1) && (length < 6)) { printf ("Valido\n"); } else { printf ("Invalid\n"); } }

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

1 1 1 1 1 1 1 1 1 2 2 2 3 4 5 5 6 6 6 7 7 7 8 9 9 9 10 10 10 10 11

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

/* 1 */ /* 1 */

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

int valid_s(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z))) { return (1); } else { return (0); } } int valid_f(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z)) || ((ch >= 0) && (ch <= 9))) { return (1); } else { return (0); } }

/* 1 */ /* 1 */

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

Figura 1: Programa exemplo: identier (contm ao menos um erro). e

 Particionamento em Classes de Equivalncia: a partir das condies de ene co trada de dados identicadas na especicao, divide-se o dom de entrada de um ca nio programa em classes de equivalncia vlidas e invlidas. Em seguida seleciona-se o e a a menor nmero poss de casos de teste, baseando-se na hiptese que um elemento u vel o de uma dada classe seria representativo da classe toda, sendo que para cada uma das classes invlidas deve ser gerado um caso de teste distinto. O uso de particionaa mento permite examinar os requisitos mais sistematicamente e restringir o nmero u de casos de teste existentes. Alguns autores tambm consideram o dom de sa e nio da do programa para estabelecer as classes de equivalncia. e Anlise do Valor Limite: um complemento ao critrio Particionamento em a e e Classes de Equivalncia, sendo que os limites associados `s condies de entrada so e a co a exercitados de forma mais rigorosa; ao invs de selecionar-se qualquer elemento de e uma classe, os casos de teste so escolhidos nas fronteiras das classes, pois nesses a pontos se concentra um grande nmero de erros. O espao de sa do programa u c da tambm particionado e so exigidos casos de teste que produzam resultados nos e e a limites dessas classes de sa da. Grafo de Causa-Efeito: os critrios anteriores no exploram combinaes das e a co condies de entrada. Este critrio estabelece requisitos de teste baseados nas posco e s veis combinaes das condies de entrada. Primeiramente, so levantadas as co co a poss veis condies de entrada (causas) e as poss co veis aes (efeitos) do programa. co A seguir constru um grafo relacionando as causas e efeitos levantados. Esse e do grafo convertido em uma tabela de deciso a partir da qual so derivados os casos e a a de teste. Um dos problemas relacionado aos critrios funcionais que muitas vezes a especie e cao do programa feita de modo descritivo e no formal. Dessa maneira, os requisitos ca e a de teste derivados de tais especicaes so tambm, de certa forma, imprecisos e inforco a e mais. Como conseqncia, tem-se diculdade em automatizar a aplicao de tais critrios, ue ca e que cam, em geral, restritos ` aplicao manual. Por outro lado, para a aplicao desses a ca ca critrios essencial apenas que se identiquem as entradas, a funo a ser computada e e e ca a sa do programa, o que os tornam aplicveis praticamente em todas fases de teste da a (unidade, integrao e sistema) [35]. ca Outt e Irvine [91], por exemplo, propem a utilizao do Mtodo de Partioo ca e ca Categoria (Category-Partition Method ) no teste de programas OO. Segundo os autores, existe muita preocupao no desenvolvimento de novas tcnicas e critrios para o teste de ca e e programas OO sem que se tenha investigado a eccia das tcnicas e critrios tradicionais a e e nesse contexto. Outt e Irvine comentam que diversos autores acham que utilizar somente tcnicas de teste tradicionais insuciente para testar programas OO mas, segundo Outt e e e Irvine, somente um autor d alguma evidncia desse fato e suas evidncias ainda no a e e a so conclusivas. Nesse contexto eles propem o uso de um critrio de teste baseado em a o e especicao (que, teoricamente aplicvel tanto para programas procedimentais quanto ca e a OO, indistintamente) no teste de programas OO. Outro critrio baseado em especicao o Particionamento em Classes de Equivalne ca e e cia. A t tulo de ilustrao, considerando o programa identier e o critrio Particionamento ca e em Classes de Equivalncia, so identicadas na Tabela 1 as condies de entrada e classes e a co de equivalncia vlidas e invlidas. A partir dessas classes o seguinte conjunto de casos e a a 9

de teste poderia ser elaborado: T0 = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), a a a (A1b2C3d, Invlido)}. De posse do conjunto T0 , seria natural indagar se esse conjunto a exercita todos os comandos ou todos os desvios de uxo de controle de uma dada implementao. Usualmente, lana-se mo de critrios estruturais de teste, apresentados a ca c a e seguir, como critrios de adequao ou critrios de cobertura para se analisar questes e ca e o como essas, propiciando a quanticao e a qualicao da atividade de teste de acordo ca ca com o critrio escolhido. Quanto mais rigoroso o critrio utilizado e se erros no forem e e a revelados, maior a conana no produto em desenvolvimento. c Tabela 1: Classes de Equivalncia para o programa identier. e
Restries de Entrada co Tamanho (t) do identicador Primeiro caracter (c) uma letra e Contm somente caracteres vlidos e a Classes Vlidas a 1t6 (1) Sim (3) Sim (5) Classes Invlidas a t>6 (2) No a (4) No a (6)

Steve et al. [92] deniram o critrio de Teste Funcional Sistemtico (Systematic Funce a tional Testing) o qual, basicamente, combina os critrios Particionamento em Classes de e Equivalncia e Anlise do Valor Limite, para a gerao de casos de teste baseados em e a ca especicao. No estudo de caso conduzido, o conjunto de casos de teste desenvolvido ca utilizando o Teste Funcional Sistemtico foi capaz de distinguir 100% dos mutantes de a unidades gerados no equivalentes do programa Cal (utilitrio do UNIX) ao passo que os a a outros 11 conjuntos de teste gerados gerados a partir dos critrios Particionamento em e Classe de Equivalncia, Anlise do Valor Limite e Teste Aleatrio resultaram em escores e a o de mutao entre 98% e 56%. ca

3.2

Tcnica Estrutural e

A tcnica estrutural apresenta uma srie de limitaes e desvantagens decorrentes e e co das limitaes inerentes `s atividades de teste de programa enquanto estratgia de valco a e idao [31, 82, 83, 93]. Esses aspectos introduzem srios problemas na automatizao do ca e ca processo de validao de software [MAL91]. Independentemente dessas desvantagens, essa ca tcnica vista como complementar ` tcnica funcional [3] e informaes obtidas pela aplie e a e co cao desses critrios tm sido consideradas relevantes para as atividades de manuteno, ca e e ca depurao e conabilidade de software [3, 69]. ca Na tcnica de teste estrutural, tambm conhecida como teste caixa branca (em oposio e e ca ao nome caixa preta), os aspectos de implementao so fundamentais na escolha dos ca a casos de teste. O teste estrutural baseia-se no conhecimento da estrutura interna da implementao. Em geral, a maioria dos critrios dessa tcnica utiliza uma representao ca e e ca de programa conhecida como grafo de uxo de controle ou grafo de programa. Um programa P pode ser decomposto em um conjunto de blocos disjuntos de comandos; a execuo do primeiro comando de um bloco acarreta a execuo de todos os outros coca ca mandos desse bloco, na ordem dada. Todos os comandos de um bloco, possivelmente com exceo do primeiro, tm um unico predecessor e exatamente um unico sucessor, exceto ca e possivelmente o ultimo comando. A representao de um programa P como um grafo de uxo de controle (G = (N, E, s)) ca consiste em estabelecer uma correspondncia entre ns e blocos e em indicar poss e o veis 10

uxos de controle entre blocos atravs dos arcos. Um grafo de uxo de controle portanto e e um grafo orientado, com um unico n de entrada s N e um unico n de sa o o da, no qual cada vrtice representa um bloco indivis e vel de comandos e cada aresta representa um poss desvio de um bloco para outro. Cada bloco tem as seguintes caracter vel sticas: 1) uma vez que o primeiro comando do bloco executado, todos os demais so executados e a seqencialmente; e 2) no existe desvio de execuo para nenhum comando dentro do u a ca bloco. A partir do grafo de programa podem ser escolhidos os componentes que devem ser executados, caracterizando assim o teste estrutural. Considere o programa identier. Na Figura 1 identica-se a caracterizao dos blocos de comandos atravs dos nmeros ca e u ` esquerda dos comandos. A Figura 2 ilustra o grafo de uxo de controle do programa a identier (funo main) gerado pela ferramenta ViewGraph [64]. ca Seja um grafo de uxo de controle G = (N, E, s) onde N representa o conjunto de ns, o E o conjunto de arcos, e s o n de entrada. Um caminho uma seqncia nita de ns o e ue o (n1 , n2 , . . . , nk ), k 2, tal que existe um arco de ni para ni + 1 para i = 1, 2, . . . , k 1. Um caminho um caminho simples se todos os ns que compem esse caminho, exceto e o o possivelmente o primeiro e o ultimo, so distintos; se todos os ns so distintos diz-se que a o a esse caminho um caminho livre de lao. Um caminho completo um caminho e c e onde o primeiro n o n de entrada e o ultimo n o n de sa do grafo G. Seja o e o o e o da IN (x) e OU T (x) o nmero de arcos que entram e que saem do n x respectivamente. Se u o IN (x) = 0 x uma n de entrada, e se OU T (x) = 0, x um n de sa e o e o da. Em relao ca ao programa identier, (2,3,4,5,6,7) um caminho simples e livre de laos e o caminho e c (1,2,3,4,5,7,4,8,9,11) um caminho completo. Observe que o caminho (6,7,4,5,7,4,8,9) e e no executvel e qualquer caminho completo que o inclua tambm no executvel, ou a a e e a a seja, no existe um dado de entrada que leve ` execuo desse caminho. a a ca

Figura 2: Grafo de Fluxo de Controle do Programa identier gerado pela ViewGraph. Os critrios de teste estrutural baseiam-se em diferentes tipos de conceitos e come ponentes de programas para determinar os requisitos de teste. Na Tabela 2 ilustram-se alguns elementos componentes de programas e critrios associados. e Os critrios de teste estrutural so, em geral, classicados em: e a Critrios Baseados em Fluxo de Controle: utilizam apenas caracter e sticas de controle da execuo do programa, como comandos ou desvios, para determica 11

Tabela 2: Elementos e critrios associados em relao ao programa identier. e ca

Elemento N o Arco Lao c Caminho Deniao de variveis c a Uso predicativo de variveis a Uso computacional de variveis a Exemplo (identier) 6 (7,4) (4,5,6,7,4) (1,2,3,4,8,9,11) length=0 achar != \n length++ Critrio e Todos-Ns o Todos-Arcos Boundary-Interior Todos-Caminhos Todas-Defs Todos-P-Usos Todos-C-Usos

nar quais estruturas so necessrias. Os critrios mais conhecidos dessa classe so a a e a Todos-Ns exige que a execuo do programa passe, ao menos uma vez, em o ca cada vrtice do grafo de uxo, ou seja, que cada comando do programa seja exee cutado pelo menos uma vez; Todos-Arcos requer que cada aresta do grafo, ou seja, cada desvio de uxo de controle do programa, seja exercitada pelo menos uma vez; e Todos-Caminhos requer que todos os caminhos poss veis do programa sejam executados [3]. Outros critrios dessa categoria so: Cobertura de Deciso; e a a Cobertura de Condio; Cobertura de Condies M ltiplas; LCSAJ (Linca co u ear Code Sequence and Jump) [94]; o critrio Boundary-Interior [95]; e a fam e lia de critrios K-tuplas requeridas de Ntafos [32]. e Critrios Baseados em Fluxo de Dados: utilizam informaes do uxo de dae co dos do programa para determinar os requisitos de teste. Esses critrios exploram as e interaes que envolvem denies de variveis e referncias a tais denies para co co a e co estabelecerem os requisitos de teste [31]. Exemplos dessa classe de critrios so os e a Critrios de Rapps e Weyuker [30, 31] e os Critrios Potenciais-Usos [4]. e e Visto que tais critrios sero utilizados nos estudos comparativos a serem realizae a dos durante o desenvolvimento deste trabalho, as prximas sees destinam-se a o co descrev-los mais detalhadamente. e Critrios Baseados na Complexidade: utilizam informaes sobre a complexie co dade do programa para derivar os requisitos de teste. Um critrio bastante conhecido e dessa classe o Critrio de McCabe, que utiliza a complexidade ciclomtica do e e a grafo de programa para derivar os requisitos de teste. Essencialmente, esse critrio e requer que um conjunto de caminhos linearmente independentes do grafo de programa seja executado [3]. Os casos de teste obtidos durante a aplicao dos critrios funcionais podem correca e sponder ao conjunto inicial dos testes estruturais. Como, em geral, o conjunto de casos de teste funcional no suciente para satisfazer totalmente um critrio de teste estrutua e e ral, novos casos de teste so gerados e adicionados ao conjunto at que se atinja o grau a e de satisfao desejado, explorando-se, desse modo, os aspectos complementares das duas ca tcnicas [43]. e Um problema relacionado ao teste estrutural a impossibilidade, em geral, de se e determinar automaticamente se um caminho ou no executvel, ou seja, no existe um e a a a algoritmo que dado um caminho completo qualquer decida se o caminho executvel e e a fornea o conjunto de valores que causam a execuo desse caminho [96]. Assim, preciso c ca e

12

a interveno do testador para determinar quais so os caminhos no executveis para o ca a a a programa sendo testado. 3.2.1 Critrios Baseados em Fluxo de Dados e

Em meados da dcada de 70 surgiram os critrios baseados em anlise de uxo de e e a dados [27], os quais utilizam informaes do uxo de dados para derivar os requisitos de co teste. Uma caracter stica comum dos critrios baseados em uxo de dados que eles e e requerem que sejam testadas as interaes que envolvam denies de variveis e subseco co a qentes referncias a essas denies [27,29,3133]. Uma motivao para a introduo dos u e co ca ca critrios baseados na anlise de uxo de dados foi a indicao de que, mesmo para prograe a ca mas pequenos, o teste baseado unicamente no uxo de controle no ser ecaz para revelar a a presena at mesmo de erros simples e triviais. A introduo dessa classe de critrios c e ca e procura fornecer uma hierarquia entre os critrios Todos-Arcos e Todos-Caminhos, procue rando tornar o teste mais rigoroso, j que o teste de Todos-Caminhos , em geral, ima e praticvel. Segundo Ural [33], esses critrios so mais adequados para certas classes de a e a erros, como erros computacionais, uma vez que dependncias de dados so identicadas, e a e portanto, segmentos funcionais so requeridos como requisitos de teste. a Rapps e Weyuker propuseram o Grafo Def-Uso (Def-Use Graph) que consiste em uma extenso do grafo de programa [30, 31]. Nele so adicionadas informaes a respeito a a co do uxo de dados do programa, caracterizando associaes entre pontos do programa co onde atribu um valor a uma varivel (chamado de denio da varivel) e pontos e do a ca a onde esse valor utilizado (chamado de referncia ou uso de varivel). Os requisitos de e e a teste so determinados com base em tais associaes. A Figura 3 ilustra o Grafo-Defa co Uso do programa identier. Conforme o modelo de uxo de dados denido em [4], uma denio de varivel ocorre quando um valor armazenado em uma posio de memria. ca a e ca o Em geral, em um programa, uma ocorrncia de varivel uma denio se ela est: i) e a e ca a no lado esquerdo de um comando de atribuio; ii) em um comando de entrada; ou iii) ca em chamadas de procedimentos como parmetro de sa a da. A passagem de valores entre procedimentos atravs de parmetros pode ser por valor, referncia ou por nome [97]. Se e a e a varivel for passada por referncia ou por nome considera-se que seja um parmetro de a e a sa da. As denies decorrentes de poss co veis denies em chamadas de procedimentos co so diferenciadas das demais e so ditas denidas por referncia. A ocorrncia de uma a a e e varivel um uso quando a referncia a essa varivel no a estiver denindo. Dois tipos de a e e a a usos so distinguidos: c-uso e p-uso. O primeiro tipo afeta diretamente uma computao a ca sendo realizada ou permite que o resultado de uma denio anterior possa ser observado; ca o segundo tipo afeta diretamente o uxo de controle do programa. O critrio mais bsico dos critrios baseados em anlise de uxo de dados o critrio e a e a e e Todas-Denies (all-defs) e faz parte da fam de critrios denidos por Rapps e Weyuker [31]. co lia e Entre os critrios dessa fam o critrio Todos-Usos (all-uses) tem sido um dos mais utie lia e lizados e investigados. Todas-Denies: requer que cada denio de varivel seja exercitada pelo menos co ca a uma vez, no importa se por um c-uso ou por um p-uso. a Todos-Usos: requer que todas as associaes entre uma denio de varivel e seus co ca a subseqentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, atravs u e de pelo menos um caminho livre de denio, ou seja, um caminho onde a varivel ca a no redenida. a e 13

Figura 3: Grafo Def-Uso do Programa identier. Por exemplo, para exercitar a denio da varivel length denida no n 1, de acordo ca a o com o critrio Todas-Denies, poderiam ser executados um dos seguintes subcaminhos: e co (1,3,4,5,7); (1,3,4,8,9); (1,3,4,8,10); e (1,3,4,5,6,7). O subcaminho (1,3,4,8,9) no exee a cutvel, e qualquer caminho completo que o inclua tambm no executvel. Se qualquer a e e a a um dos demais caminhos for exercitado, o requisito de teste estaria sendo satisfeito, e para satisfazer o critrio Todas-Denies esta anlise teria que ser feita para toda denio e co a ca que ocorre no programa. Em relao ao critrio Todos-Usos, com respeito ` mesma ca e a denio, seriam requeridas as seguinte associaes: (1,7, length); (1,(8,9),length) e ca co (1,(8,10),length). As notaes (i,j,var) e (i,(j, k),var) indicam que a varivel var co a e denida no n i e existe um uso computacional de var no n j ou um uso predicativo de o o var no arco (j, k), respectivamente, bem como pelo menos um caminho livre de denio ca do n i ao n j ou ao arco (j, k). Observe que a associao (1,(8,9), length) no o o ca e a executvel pois o unico caminho que livre de denio poss de exercit-la seria um a ca vel a caminho que inclu o subcaminho (1,3,4,8,9). J para a associao (1,7,length) qualsse a ca quer caminho completo executvel incluindo um dos subcaminhos (1,3,4,5,6,7), (1,3,4,5,7) a seria suciente para exercit-la. Esta mesma anlise deveria ser feita para todas as demais a a variveis e associaes pertinentes, a m de satisfazer o critrio Todos-Usos. a co e A maior parte dos critrios baseados em uxo de dados, para requerer um determie nado elemento (caminho, associao, etc.), exige a ocorrncia expl ca e cita de um uso de varivel e no garante, necessariamente, a incluso dos critrios Todos-Arcos na presena a a a e c de caminhos no executveis, presentes na maioria dos programas. a a Com a introduo do conceito potencial-uso so denidos vrios critrios, denomica a a e nados critrios Potenciais-Usos [4], cujos elementos requeridos so caracterizados indee a pendentemente da ocorrncia expl e cita de uma referncia um uso a uma determinada e denio; se um uso dessa denio pode existir, ou seja, existir um caminho livre de ca ca denio at um certo n ou arco um potencial-uso a potencial-associao entre ca e o ca a denio e o potencial-uso caracterizada, e eventualmente requerida. Na realidade, ca e 14

pode-se dizer que, com a introduo do conceito potencial-uso, procura-se explorar todos ca os poss veis efeitos a partir de uma mudana de estado do programa em teste, decorrente c de denio de variveis em um determinado n i. Da mesma forma como os demais ca a o critrios baseados na anlise de uxo de dados, os critrios Potenciais-Usos podem utilizar e a e o Grafo Def-Uso como base para o estabelecimento dos requisitos de teste. Na verdade, basta ter a extenso do grafo de programa associando a cada n do grafo informaes a rea o co speito das denies que ocorrem nesses ns, denominado de Grafo Def [4]. Por exemplo, co o as potenciais-associaes (1,6,length) e (7,6,length) so requeridas pelo critrio Todosco a e Potenciais-Usos [4], mas no seriam requeridas pelos demais critrios de uxo de dados a e que no fazem uso do conceito potencial-uso. Observe-se que, por denio, toda assoa ca ciao uma potencial-associao. Dessa forma, as associaes requeridas pelo critrio ca e ca co e Todos-Usos so um subconjunto das potenciais-associaes requeridas pelo critrio Todosa co e Potenciais-Usos. Todos-Potenciais-Usos: requer, basicamente, para todo n i e para toda varivel o a x, para a qual existe uma denio em i, que pelo menos um caminho livre de ca denio com relao ` varivel (c.r.a) x do n i para todo n e para todo arco ca ca a a o o poss de ser alcanado a partir de i por um caminho livre de denio c.r.a. x vel c ca seja exercitado. A relao de incluso uma importante propriedade dos critrios, sendo utilizada ca a e e para avali-los, do ponto de vista terico. O critrio Todos-Arcos, por exemplo, inclui a o e o critrio Todos-Ns, ou seja, qualquer conjunto de casos de teste que satisfaz o critrio e o e Todos-Arcos tambm satisfaz o critrio Todos-Ns, necessariamente. Quando no pose e o a e s estabelecer essa ordem de incluso para dois critrios, como o caso de Todas-Defs vel a e e e Todos-Arcos, diz-se que tais critrios so incomparveis [31]. Deve-se observar que os e a a critrios Potenciais-Usos so os unicos critrios baseados em anlise de uxo de dados que e a e a satisfazem, na presena de caminhos no executveis, as propriedades m c a a nimas esperadas de um critrio de teste, e que nenhum outro critrio baseado em anlise de uxo de dados e e a os inclui. Um aspecto relevante que alguns dos critrios Potenciais-Usos bridge the gap e e entre os critrios Todos-Arcos e Todos-Caminhos mesmo na presena de caminhos no e c a executveis, o que no ocorre para os demais critrios baseados em uxo de dados. a a e Como j citado, uma das desvantagens do teste estrutural a existncia de caminhos a e e requeridos no executveis. Existe tambm o problema de caminhos ausentes, ou seja, a a e quando uma certa funcionalidade deixa de ser implementada no programa, no existe um a caminho que corresponda `quela funcionalidade e, como conseqncia, nenhum caso de a ue teste ser requerido para exercit-la. Mesmo assim, esses critrios estabelecem de forma a a e rigorosa os requisitos de teste a serem exercitados, em termos de caminhos, associaes co denio-uso, ou outras estruturas do programa, fornecendo medidas objetivas sobre a ca adequao de um conjunto de teste para o teste de um dado programa P . Esse rigor na ca denio dos requisitos favorece a automatizao desses critrios. ca ca e Os critrios estruturais tm sido utilizados principalmente no teste de unidade, uma e e vez que os requisitos de teste por eles exigidos limitam-se ao escopo da unidade. Vrios a esforos de pesquisa no sentido de estender o uso de critrios estruturais para o teste de c e integrao podem ser identicados. Haley e Zweben propuseram um critrio para seleca e cionar caminhos em um mdulo que deveria ser testado novamente na fase de integrao o ca com base em sua interface [98]. Linnenkugel e Mllerburg apresentaram uma srie de u e critrios que estendem os critrios baseados em uxo de controle e em uxo de dados para e e 15

o teste de integrao [70]. Harrold e Soa propuseram uma tcnica para determinar as ca e estruturas de denio-uso interprocedurais permitindo a aplicao dos critrios baseados ca ca e em anlise de uxo de dados em n de integrao [99]. Jin e Outt deniram alguns a vel ca critrios baseados em uma classicao de acoplamento entre mdulos [100]. Vilela, com e ca o base no conceito de potencial-uso, estendeu os critrios Potenciais-Usos para o teste de e integrao [101]. ca Harrold e Rothermel [75] estenderam o teste de uxo de dados para o teste de classes. Os autores comentam que os critrios de uxo de dados destinados ao teste de programas e procedimentais [31,102,103] podem ser utilizados tanto para o teste de mtodos individuais e quanto para o teste de mtodos que interagem entre si dentro de uma mesma classe. e Entretanto, esses critrios no consideram interaes de uxo de dados quando os usurios e a co a de uma classe invocam seqncia de mtodos em uma ordem arbitrria. ue e a Para resolver esse problema, os autores apresentam uma abordagem que permite testar diferentes tipos de interaes de uxo de dados entre classes. A abordagem proposta usa co as tcnicas tradicionais de uxo de dados para testar os mtodos individuais e as intere e aes entre os mtodos dentro de mesma classe. Para testar os mtodos que so acess co e e a veis fora da classe e podem serem utilizados por outras classes, uma nova representao, deca nominada grafo de uxo de controle de classe (CCFG - class control ow graph), foi desenvolvida. A partir do CCFG, novos requisitos de teste inter-mtodo, intra-classe e e inter-classe podem ser derivados [75]. Vincenzi et al. [104] tambm tm investigado o uso de critrios de uxo de controle e e e e de dados no teste de programas OO e de componentes [105]. Visando ` desenvolver a uma soluo que fosse aplicvel tanto a programas OO quanto componentes de software ca a (os quais, em geral, so testados pelos clientes utilizando somente tcnicas funcionais), a e investigou-se como realizar anlise esttica de programas Java diretamente a partir do a a cdigo objeto (Java bytecode). Com isso, independentemente da existncia do cdigo o e o fonte da aplicao sendo testada, poss derivar requisitos de teste estruturais os quais ca e vel podem ser utilizados tanto para avaliar a qualidade de conjuntos de teste quanto para a prpria gerao de casos de teste. Para apoiar a aplicao do teste estrutural intra-mtodo o ca ca e em programas e componentes Java foi desenvolvida a ferramenta JaBUTi (Java Bytecode Understanding and Testing) [67]. 3.2.2 A Ferramenta de Teste PokeTool

Vrias so as iniciativas de desenvolvimento de ferramentas de teste para apoiar a a a aplicao de critrios de teste [11, 35, 43, 5265]. Para ilustrar os conceitos abordados ca e acima ser utilizada a ferramenta PokeTool (Potential Uses Criteria Tool for Program a Testing) [60, 61], desenvolvida na Faculdade de Engenharia Eltrica e de Computao e ca da Universidade Estadual de Campinas UNICAMP. Essa ferramenta apia a aplicao o ca dos critrios Potenciais-Usos e tambm de outros critrios estruturais como Todos-Ns e e e e o Todos-Arcos. Inicialmente foi desenvolvida para o teste de unidade de programas escritos em C [61], mas atualmente, devido ` sua caracter a stica de multi-linguagem, j existem a conguraes para o teste de programas em Cobol e FORTRAN [106, 107]. A Figura 4 co mostra a tela principal da ferramenta e as funes fornecidas. co A ferramenta PokeTool orientada a sesso de trabalho. O termo sesso trabalho e a a ou de teste utilizado para designar as atividades envolvendo um teste. O teste pode e ser realizado em etapas onde so armazenados os estados intermedirios da aplicao de a a ca teste a m de que possam ser recuperados posteriormente. Desse modo, poss e vel ao 16

usurio iniciar e encerrar o teste de um programa, bem como retom-lo a partir de onde a a este foi interrompido. Basicamente, o usurio entra com o programa a ser testado, com a o conjunto de casos de teste e seleciona todos ou alguns dos critrios dispon e veis (TodosPotenciais-Usos, Todos-Potenciais-Usos/Du, Todos-Potenciais-Du-Caminhos, Todos-Ns o e Todos-Arcos). Como sa a ferramenta fornece ao usurio o conjunto de arcos primda, a itivos [108], o Grafo Def obtido do programa em teste, o programa instrumentado para teste, o conjunto de associaes necessrias para satisfazer o critrio selecionado e o conco a e junto de associaes ainda no exercitadas. O conjunto de arcos primitivos consiste de co a arcos que uma vez executados garantem a execuo de todos os demais arcos do grafo de ca programa.

Figura 4: Opes dispon co veis na ferramenta PokeTool. A Figura 5 mostra a criao de uma sesso de teste para o programa identier utica a lizando todos os critrios apoiados pela ferramenta. e

Figura 5: Tela para criar uma sesso de teste na PokeTool. a A PokeTool encontra-se dispon vel para os ambientes DOS e UNIX. A verso para a DOS possui interface simples, baseada em menus. A verso para UNIX possui mdulos a o 17

funcionais cuja utilizao se d atravs de interface grca ou linha de comando (shell ca a e a scripts). Considerando-se os critrios Todos-Arcos e Todos-Potenciais-Usos e o programa idene tier, as Tabelas 3 e 4 trazem os elementos requeridos por esses critrios, respectivamente. e Introduz-se a notao i, (j, k), {v1 , . . . , vn } para representar o conjunto de associaes ca co i, (j, k), {v1 } , . . ., i, (j, k), {vn } ; ou seja, i, (j, k), {v1 , . . . , vn } indica que existe pelo menos um caminho livre de denio c.r.a v1 , . . . , vn do n i ao arco (j, k). Observe-se que ca o podem existir outros caminhos livres de denio c.r.a algumas das variveis v1, . . . , vn ca a mas que no sejam, simultaneamente, livres de denio para todas as variveis v1 , . . . , vn . a ca a Tabela 3: Elementos requeridos pelo critrio Todos-Potenciais-Usos. e
Arco (1,2) Arco (1,3) Arcos Primitivos Arco (5,6) Arco (5,7) Arco (8,9) Arco (8,10)

Tabela 4: Elementos requeridos pelo critrio Todos-Potenciais-Usos. e

Associaes Requeridas co 1) 1, (6, 7), {length} 17) 2, (6, 7), {length} 2) 1, (1, 3), {achar, length, valid id} 18) 2, (5, 6), {length} 3) 1, (8, 10), {length, valid id} 19) 3, (8, 10), {achar} 4) 1, (8, 10), {valid id} 20) 3, (8, 9), {achar} 5) 1, (8, 9), {length, valid id} 21) 3, (5, 7), {achar} 6) 1, (8, 9), {valid id} 22) 3, (6, 7), {achar} 7) 1, (7, 4), {valid id} 23) 3, (5, 6), {achar} 8) 1, (5, 7), {length, valid id} 24) 6, (8, 10), {valid id} 9) 1, (5, 7), {valid id} 25) 6, (8, 9), {valid id} 10) 1, (5, 6), {length, valid id} 26) 6, (5, 7), {valid id} 11) 1, (5, 6), {valid id} 27) 6, (5, 6), {valid id} 12) 1, (2, 3), {achar, valid id} 28) 7, (8, 10), {achar, length} 13) 1, (1, 2), {achar, length, valid id} 29) 7, (8, 9), {achar, length} 14) 2, (8, 10), {length} 30) 7, (5, 7), {achar, length} 15) 2, (8, 9), {length} 31) 7, (6, 7), {achar, length} 16) 2, (5, 7), {length} 32) 7, (5, 6), {achar, length}

Utilizando o conjunto de casos de teste T0 = {(a1, Vlido), (2B3, Invlido), (Z-12, Ina a vlido), (A1b2C3d, Invlido)} gerado anteriormente procurando satisfazer o critrio Para a e ticionamento em Classes de Equivalncia, observa-se qual a cobertura obtida em relao e ca aos critrios Todos-Arcos e Todos-Potenciais-Usos (Figura 6(a) e Figura 6(b), respectie vamente). Ainda na Figura 6(b), so ilustrados para o critrio Todos-Potenciais-Usos os a e elementos requeridos e no executados quando a cobertura inferior a 100%. a e Observa-se que somente com os casos de teste funcionais foi poss cobrir o critrio vel e Todos-Arcos ao passo que para se cobrir o critrio Todos-Potenciais-Usos ainda necessrio e e a analisar as associaes que no foram executadas. Deve-se ressaltar que o conjunto T0 co a Todos-Arcos-adequado, ou seja, o critrio Todos-Arcos foi satisfeito e o erro presente e e no programa identier no foi revelado. Certamente, um conjunto adequado ao critrio a e Todos-Arcos que revelasse o erro poderia ter sido gerado; o que se ilustra aqui que no e a necessariamente a presena do erro revelada. c e Desejando-se melhorar a cobertura em relao ao critrio Todos-Potenciais-Usos, novos ca e casos de teste devem ser inseridos visando a cobrir as associaes que ainda no foram co a executadas. Primeiramente, deve-se vericar, entre as associaes no executadas, se exco a istem associaes no executveis. No caso, as associaes 1, (8, 9), {length, valid id} , co a a co 2, (8, 10), {length} e 6, (8, 9), {valid id} so no executveis. Na Tabela 5 esse proa a a 18

(a) Todos-Arcos

(b) Todos-Potenciais-Usos

Figura 6: Relatrios gerados pela PokeTool em relao ao programa identier. o ca cesso ilustrado at que se atinja a cobertura de 100% para o critrio Todos-Potenciaise e e Usos. O s mbolo indica quais associaes foram cobertas por quais conjuntos de casos co de teste e o s mbolo mostra quais so as associaes no-executveis. a co a a Tabela 5: Ilustrao da evoluo da sesso de teste para cobrir o critrio Todos-Potenciaisca ca a e Usos.
Associaes Requeridas co T0 T1 T2 Associaes Requeridas co 1) 1, (6, 7), {length} 17) 2, (6, 7), {length} 2) 1, (1, 3), {achar, length, valid id} 18) 2, (5, 6), {length} 3) 1, (8, 10), {length, valid id} 19) 3, (8, 10), {achar} 4) 1, (8, 10), {valid id} 20) 3, (8, 9), {achar} 5) 1, (8, 9), {length, valid id} 21) 3, (5, 7), {achar} 6) 1, (8, 9), {valid id} 22) 3, (6, 7), {achar} 7) 1, (7, 4), {valid id} 23) 3, (5, 6), {achar} 8) 1, (5, 7), {length, valid id} 24) 6, (8, 10), {valid id} 9) 1, (5, 7), {valid id} 25) 6, (8, 9), {valid id} 10) 1, (5, 6), {length, valid id} 26) 6, (5, 7), {valid id} 11) 1, (5, 6), {valid id} 27) 6, (5, 6), {valid id} 12) 1, (2, 3), {achar, valid id} 28) 7, (8, 10), {achar, length} 13) 1, (1, 2), {achar, length, valid id} 29) 7, (8, 9), {achar, length} 14) 2, (8, 10), {length} 30) 7, (5, 7), {achar, length} 15) 2, (8, 9), {length} 31) 7, (6, 7), {achar, length} 16) 2, (5, 7), {length} 32) 7, (5, 6), {achar, length} T0 = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)} a a a a T1 = T0 {(1#, Invlido), (%, Invlido), (c, Vlido)} a a a T2 = T1 {(#-%, Invlido)} a T0 T1 T2

Observe-se que mesmo tendo satisfeito um critrio mais rigoroso como o critrio Todose e Potenciais-Usos, a presena do erro ainda no foi revelada. Assim, motiva-se a pesquisa c a de critrios de teste que exercitem os elementos requeridos com maior probabilidade de e revelar erros [109]. Outra perspectiva que se coloca utilizar uma estratgia de teste e e incremental, que informalmente procura-se ilustrar neste texto. Em primeiro lugar foram exercitados os requisitos de teste requeridos pelo critrio Todos-Arcos, em seguida os e requeridos pelo critrio Todos-Potenciais-Usos, e, posteriormente, poder-se-ia considerar e o critrio Anlise de Mutantes (descrito na prxima seo), que do ponto de vista terico e a o ca o incomparvel com os critrios baseados em uxo de dados, mas em geral de maior custo e a e de aplicao. ca 19

3.3

Teste Baseado em Erros

A tcnica de teste baseada em erros utiliza informaes sobre os tipos de erros mais e co freqentes no processo de desenvolvimento de software para derivar os requisitos de teste. u A nfase da tcnica est nos erros que o programador ou projetista pode cometer durante e e a o desenvolvimento e nas abordagens que podem ser usadas para detectar a sua ocorrncia. e Semeadura de Erros (Error Seeding) [25] e Anlise de Mutantes (Mutation Anala ysis) [34] so critrios t a e picos que se concentram em erros. Neste texto d-se nfase ao a e critrio Anlise de Mutantes. e a O critrio Anlise de Mutantes surgiu na dcada de 70 na Yale University e Georgia e a e Institute of Technology, possuindo um forte relacionamento com um mtodo clssico para e a deteco de erros lgicos em circuitos digitais o modelo de teste de falha unica [110]. ca o O critrio Anlise de Mutantes utiliza um conjunto de programas ligeiramente modicae a dos (mutantes) obtidos a partir de determinado programa P para avaliar o quanto um conjunto de casos de teste T adequado para o teste de P . O objetivo determinar um e e conjunto de casos de teste que consiga revelar, atravs da execuo de P , as diferenas de e ca c comportamento existentes entre P e seus mutantes [68]. A seguir d-se uma viso geral do critrio Anlise de Mutantes e da ferramenta de a a e a apoio Proteum, desenvolvida no ICMC-USP [62]. Informaes mais detalhadas sobre a co Anlise de Mutantes e sobre a ferramenta Proteum podem ser obtidas em [1, 62, 111]. a

3.4

O Critrio Anlise de Mutantes e a

Um dos primeiros artigos que descrevem a idia de teste de mutantes foi publicado em e 1978 [34]. A idia bsica da tcnica apresentada por DeMillo, conhecida como hiptese e a e o do programador competente (competent programmer hypothesis), assume que programadores experientes escrevem programas corretos ou muito prximos do correto. Assuo mindo a validade desta hiptese, pode-se armar que erros so introduzidos nos programas o a atravs de pequenos desvios sintticos que, embora no causem erros sintticos, alteram a e a a a semntica do programa e, conseqentemente, conduzem o programa a um comportamento a u incorreto. Para revelar tais erros, a Anlise de Mutantes identica os desvios sintticos a a mais comuns e, atravs da aplicao de pequenas transformaes sobre o programa em e ca co teste, encoraja o testador a construir casos de testes que mostrem que tais transformaes co levam a um programa incorreto [112]. Uma outra hiptese explorada na aplicao do critrio Anlise de Mutantes o efeito o ca e a e de acoplamento (coupling eect) [34], a qual assume que erros complexos esto relaa cionados a erros simples. Assim sendo, espera-se, e alguns estudos emp ricos j conra maram esta hiptese [113, 114], que conjuntos de casos de teste capazes de revelar erros o simples so tambm capazes de revelar erros complexos. Nesse sentido, aplica-se uma a e mutao de cada vez no programa P em teste, ou seja, cada mutante contm apenas uma ca e transformao sinttica. Um mutante com k transformaes sintticas referenciado por ca a co a e k-mutante; neste texto so utilizados apenas 1-mutantes. a Partindo-se da hiptese do programador competente e do efeito de acoplamento, a o princ pio, o testador deve fornecer um programa P a ser testado e um conjunto de casos de teste T cuja adequao deseja-se avaliar. O programa executado com T e se apresentar ca e resultados incorretos ento um erro foi encontrado e o teste termina. Caso contrrio, o a a programa ainda pode conter erros que o conjunto T no conseguiu revelar. O programa P a

20

sofre ento pequenas alteraes, dando origem aos programas P1 , P2 , . . . , Pn denominados a co mutantes de P , diferindo de P apenas pela ocorrncia de erros simples. e Com o objetivo de modelar os desvios sintticos mais comuns, operadores de mua tao (mutant operators) so aplicados a um programa P , transformando-o em programas ca a similares: mutantes de P . Entende-se por operador de mutao as regras que denem as ca alteraes que devem ser aplicadas no programa original P . Os operadores de mutao co ca so constru a dos para satisfazer a um entre dois propsitos: 1) induzir mudanas sintticas o c a simples com base nos erros t picos cometidos pelos programadores (como trocar o nome de uma varivel); ou 2) forar determinados objetivos de teste (como executar cada arco a c do programa) [46]. A seguir, os mutantes so executados com o mesmo conjunto de casos de teste T . O a objetivo obter casos de teste que resultem apenas em mutantes mortos (para algum caso e de teste o resultado do mutante e o do programa original diferem entre si) e equivalentes (o mutante e o programa original apresentam sempre o mesmo resultado, para qualquer d D); neste caso, tem-se um conjunto de casos de teste T adequado ao programa P em teste, no sentido de que, ou P est correto, ou possui erros pouco provveis de a a ocorrerem [34]. E preciso ressaltar que, em geral, a equivalncia entre programas uma questo ine e a decid vel e requer a interveno do testador. Essa limitaao terica, no entanto, no ca c o a signica que o problema deva ser abandonado por no apresentar soluo. Na verdade, a ca alguns mtodos e heur e sticas tm sido propostos para determinar a equivalncia de proe e gramas em uma grande porcentagem dos casos de interesse [25]. Um ponto importante destacado por DeMillo [52] que a Anlise de Mutantes fornece e a uma medida objetiva do n de conana da adequao dos casos de teste analisados vel c ca atravs da denio de um escore de mutao (mutation score), que relaciona o nmero e ca ca u de mutantes mortos com o nmero de mutantes gerados. O escore de mutao calculado u ca e da seguinte forma: ms(P, T ) = sendo: DM (P, T ): nmero de mutantes mortos pelos casos de teste em T . u M (P ): nmero total de mutantes gerados. u EM (P ): nmero de mutantes gerados equivalentes a P . u O escore de mutao varia no intervalo entre 0 e 1 sendo que, quanto maior o escore ca mais adequado o conjunto de casos de teste para o programa sendo testado. Percebe-se e com essa frmula que apenas DM (P, T ) depende do conjunto de casos de teste utilizado o e que, EM (P ) obtido ` medida que o testador, manualmente ou com o apoio de heur e a sticas, decide que determinado mutante vivo equivalente [43]. e Um dos maiores problemas para a aplicao do critrio Anlise de Mutantes est ca e a a relacionado ao seu alto custo, uma vez que o nmero de mutantes gerados, mesmo para u pequenos programas, pode ser muito grande, exigindo um tempo de execuo muito alto. ca Vrias estratgias tm sido propostas para fazer com que a Anlise de Mutantes possa a e e a ser utilizada de modo mais eciente, dentro de limites economicamente viveis. A utia lizao de arquiteturas de hardware avanadas para diminuir o tempo de execuo dos ca c ca 21 DM (P, T ) M (P ) EM (P )

mutantes [115118] e o uso da anlise esttica de anomalias de uxo de dados para reduzir a a o nmero de mutantes gerados [119] so algumas dessas estratgias. Alm disso, critrios u a e e e alternativos derivados da Anlise de Mutantes tambm foram criados com o intuito de a e reduzir o custo a ela associado: Mutao Aleatria (Randomly Selected X% Mutation), ca o Mutao Restrita (Constrained Mutation) e Mutao Seletiva (Selective Mutation). ca ca Tais critrios procuram selecionar apenas um subconjunto do total de mutantes gerados, e reduzindo o custo associado, mas com a expectativa de no se reduzir a eccia do critrio. a a e Uma das vantagens do critrio baseado em mutao sua exibilidade no teste de e ca e diversas entidades executveis. Essa exibilidade vem do fato de que para se aplicar o a teste de mutao necessria a existncia de um modelo que seja executvel que aceite ca e a e a uma entrada e produza uma sa que possa ser comparada com a sa do mutante. Alm da da e disso, necessria a denio de um conjunto de operadores de mutao responsvel pela e a ca ca a representao do modelo de erros correspondente a entidade executvel em questo. ca a a Nesse sentido, os operadores de mutao so dependentes da linguagem. Existem ca a conjuntos de operadores de mutao denidos para o teste de programas em Fortran [72], ca C [112,120] e Java [121,122]. Alm disso, existem conjuntos de operadores de mutao para e ca o teste de especicaes em Mquinas de Estado Finito [123,124], Redes de Petri [125,126], co a Statecharts [22, 127] e Especicaes Algbricas [128]. As extenses do teste de mutao co e o ca para o teste de especicaes, bem como as ferramentas de apio existentes, so descritas co o a mais detalhadamente na Seo 6 e as extenses para programas OO so descritas na ca o a Seo 7. ca 3.4.1 A Ferramenta de Teste Proteum

Como ressaltado anteriormente, a aplicao de critrios de teste sem o apoio de uma ca e ferramenta de software propensa a erros. Vrias so as iniciativas de desenvolvimento de e a a ferramentas de apoio ` aplicao do critrio Anlise de Mutantes [35,43,52,53,62,111,129]. a ca e a A Proteum [62, 111], desenvolvida no ICMC-USP, a unica ferramenta que apia o teste e o de mutao para programas C existente atualmente. Alm disso, devido a caracter ca e sticas de multi-linguagem, ela tambm pode ser congurada para o teste de programas escritos e em outras linguagens. A Proteum est dispon para os sistemas operacionais SunOS, a vel Solaris e Linux. Na Figura 7 apresentada a tela principal da ferramenta bem como e as funes dispon co veis. Basicamente, a ferramenta Proteum oferece ao testador recursos para, atravs da aplicao do critrio Anlise de Mutantes, avaliar a adequao de ou e ca e a ca gerar um conjunto de casos de teste T para determinado programa P . Com base nas informaes fornecidas pela Proteum, o testador pode melhorar a qualidade de T at co e obter um conjunto adequado ao critrio. Desse modo, a ferramenta pode ser utilizada e como instrumento de avaliao bem como de seleo de casos de teste. ca ca Os recursos oferecidos pela ferramenta (Figura 7) permitem a execuo das seguintes ca operaes: denio de casos de teste, execuo do programa em teste, seleo dos opco ca ca ca eradores de mutao que sero utilizados para gerar os mutantes, gerao dos mutantes, ca a ca execuo dos mutantes com os casos de teste denidos, anlise dos mutantes vivos e clca a a culo do escore de mutao. As funes implementadas na Proteum possibilitam que alguns ca co desses recursos sejam executados automaticamente (como a execuo dos mutantes), enca quanto que para outros so fornecidas facilidades para que o testador possa realiz-los a a (como a anlise de mutantes equivalentes) [35, 62]. Alm disso, diversas caracter a e sticas adicionais foram incorporadas de modo a facilitar a atividade de teste e/ou a conduo ca de experimentos. E o caso, por exemplo, da possibilidade de executar um mutante com 22

todos os casos de teste dispon veis, mesmo que algum deles j o tenha matado. Atravs a e desse tipo de teste, chamado research, conseguem-se dados a respeito da ecincia dos e operadores de mutao ou mesmo para a determinao de estratgias de minimizao dos ca ca e ca conjuntos de casos de teste [62, 111].

Figura 7: Opes dispon co veis na ferramenta Proteum. Um dos pontos essenciais para a aplicao do critrio Anlise de Mutantes a denio ca e a e ca do conjunto de operadores de mutao. A Proteum conta com 71 operadores de mutao ca ca divididos em quatro classes (Figura 8) [62]: mutao de comandos (statement mutations), ca mutao de operadores (operator mutations), mutao de variveis (variable mutations) e ca ca a poss escolher os operadores de acordo mutao de constantes (constant mutations). E ca vel com a classe de erros que se deseja enfatizar, permitindo que a gerao de mutantes seja ca feita em etapas ou at mesmo dividida entre vrios testadores trabalhando independene a temente. Na Tabela 6 so ilustrados alguns operadores de mutao para cada uma das a ca classes de operadores.

Figura 8: Classes e operadores de mutao existentes na Proteum. ca A Proteum tambm trabalha com sesso de teste, ou seja, conjunto de atividades e a envolvendo um teste que podem ser realizadas em etapas, sendo poss ao usurio inivel a 23

Tabela 6: Exemplos de operadores de mutao para programas C. ca

Operador SSDL ORRN VTWD Ccsr SWDD SMTC OLBN Cccr VDTR Descrio ca Retira um comando de cada vez do programa. Substitui um operador relacional por outro operador relacional. Substitui a referncia escalar pelo seu valor sucessor e predecessor. e Substitui referncias escalares por constantes. e Substitui o comando while por do-while. Interrompe a execuao do lao aps duas execues. c c o co Substitui operador lgico por operador bitwise. o Substitui uma constante por outra constante. Fora cada referncia escalar a possuir cada um dos valores: negativo, positivo e zero. c e

ciar e encerrar o teste de um programa, bem como retom-lo a partir de onde este foi a interrompido. Para o programa identier, o processo de criao de uma sesso de teste ca a utilizando a interface grca ilustrado na Figura 9 abaixo. a e Uma sesso de teste com o apoio das ferramentas Proteum e PokeTool pode ser cona duzida atravs de uma interface grca ou atravs de scripts. A interface grca permite e a e a ao usurio iniciante explorar e aprender os conceitos de teste relacionados ao critrio em a e uso e da prpria ferramenta. Alm disso, oferece melhores recursos para a visualizao dos o e ca casos de teste e dos requisitos de teste, por exemplo dos mutantes, no caso da Proteum, facilitando algumas tarefas como a identicao dos mutantes equivalentes. ca

Figura 9: Criando uma sesso de teste para o programa identier na Proteum. a Conduzir uma sesso de teste atravs da interface grca provavelmente mais fcil, a e a e a porm menos ex do que quando se utiliza a chamada direta aos programas que come vel pem as ferramentas. A interface grca depende de constante interao do testador, ao o a ca passo que a utilizao de scripts possibilita a execuo de longas sesses de teste em batch. ca ca o O usurio pode construir um programa especicando o teste a ser realizado e a ferramenta a simplesmente executa esse programa, permitindo que se economize tempo na atividade de teste devido ` reduo do nmero de interaes com a ferramenta. Por outro lado, a ca u co a elaborao de scripts exige um esforo de programao e completo dom ca c ca nio tanto dos conceitos sobre o teste baseado em mutao quanto dos prprios programas que compem ca o o as ferramentas, devendo ser utilizado pelo testador mais experiente [35]. Scripts de teste tm se mostrado de grande utilidade na conduo de estudos emp e ca ricos, onde uma mesma seqncia de passos deve ser executada vrias vezes at que os resultados obtidos sejam ue a e signicantes do ponto de vista estat stico. 24

A seguir, ser avaliada a adequao da atividade de teste do programa identier, rea ca alizada at este ponto com o uso da ferramenta PokeTool, em relao ao critrio Anlise e ca e a de Mutantes, com o apoio da ferramenta Proteum; ou seja, ser avaliada a adequao dos a ca conjuntos Todos-Usos-adequado e Todos-Potenciais-Usos-adequado em relao ao critrio ca e Anlise de Mutantes. Inicialmente, somente os casos de teste do conjunto T0 foram impora tados; a Figura 10(a) mostra o estado da sesso de teste aps a execuo dos mutantes. a o ca Em seguida, como o escore de mutao ainda no satisfatrio, foram adicionados os ca a e o casos de teste do conjunto T1 e T2 (Figura 10(b)). Observa-se que mesmo aps a adio o ca de todos os casos de teste do conjunto Todos-Potenciais-Usos-adequado, 371 mutantes ainda permaneceram vivos. Em uma primeira anlise dos mutantes vivos, 78 foram marcados como equivalentes e a mais 13 casos de teste foram criados visando a matar os mutantes vivos no-equivalentes: a T3 = T2 {(zzz, Vlido), (aA, Vlido), (A1234, Vlido), (ZZZ, Vlido), (AAA, Vlido), a a a a a (aa09, Vlido), ([, Invlido), ({, Invlido), (x/, Invlido), (x:, Invlido), (x18, Vlido), (x[[, a a a a a a Invlido), (x{{, Invlido)}. A Figura 11 ilustra dois dos mutantes vivos que foram analisaa a dos. O mutante da Figura 11 (a) um mutante equivalente e o mutante da Figura 11 (b) e um mutante que morre com o caso de teste ([, Invlido), presente em T3 . Os pontos nos e a quais as mutaes foram aplicadas est destacado em negrito. A Figura 10(c) ilustra o co a resultado obtido aps T3 ter sido executado com todos os mutantes vivos. Como pode ser o observado, 64 mutantes ainda permaneceram vivos. Isto signica que qualquer um desses 64 mutantes poderiam ser considerados corretos em relao ` atividade de teste atual, ca a uma vez que no existe um caso de teste selecionado que seja capaz de distinguir entre o a comportamento dos mutantes e do programa original (Figura 10(c)). A m de obter uma melhor cobertura do critrio Anlise de Mutantes, o processo e a de anlise dos mutantes vivos continuou at que todos os equivalentes fossem marcados. a e Ao trmino desse processo, mais quatro casos de teste foram constru e dos (T4 = T3 {(@, Invlido), (, Invlido), (x@, Invlido), (x, Invlido)}). A Figura 10(d) mostra o resultado a a a a nal obtido. Observa-se que ainda restaram dois mutantes vivos (Figura 12 (a) e (b)). Esses mutantes so mutantes error-revealing e um deles representa o programa correto: a Figura 12 (b). Um mutante dito ser error-revealing se para qualquer caso de teste t e tal que P (t) = M (t) pudermos concluir que P (t) no est de acordo com o resultado a a esperado, ou seja, revela a presena de um erro. c Observe que os mutantes error-revealing, Figura 12 (a) e (b), foram gerados pelos operadores de mutao ORRN e VTWD e que necessariamente o erro presente na verso ca a do programa identier ser revelado ao elaborar-se qualquer caso de teste que seja capaz a de distinguir o comportamento desses mutantes e a verso do programa identier em teste. a Os mutantes Figura 12 morrem, por exemplo, com o caso de teste (ABCDEF, Vlido). a O erro encontrado no programa original foi corrigido e, aps a sua correo o conjunto o ca completo de casos de teste T5 foi reavaliado (T5 = T4 {(ABCDEF, Vlido)}, resultando a em um conjunto 100% adequado ao critrio Anlise de Mutantes, para a verso corrigida e a a do programa identier(Figura 13). A parte corrigida est destacada em negrito. a Para o programa identier, utilizando-se todos os operadores de mutao, foram gerca ados 933 mutantes. Aplicando-se somente os operadores da Tabela 6 teriam sido gerados somente 340 mutantes, representando uma economia de aproximadamente 63%. Os operadores de mutao ilustrados na Tabela 8 constituem um conjunto de operadores essenciais ca para a linguagem C [79], ou seja, um conjunto de casos de teste que seja capaz de distinguir os mutantes gerados por esses operadores, em geral, seria capaz de distinguir os mutantes 25

(a) Conjunto T0

(b) Conjuntos T1 e T2

(c) Conjunto T3

(d) Conjuntos T4

Figura 10: Telas de status da sesso de teste da ferramenta Proteum. a . . .

main() { ... if(valid_id * (length >= 1) && (length < 6)) { printf ("Valido\n"); } else { printf ("Invalid\n"); } int valid_s(char ch) { if(((ch >= A) && (ch <= z)) || ((ch >= a) && (ch <= z))) { return (1); } else { return (0); } }

. . .

. . . (a) Mutante equivalente

. . . (b) Mutante no-equivalente a

Figura 11: Exemplos de mutantes do programa identier. no equivalentes gerados pelos demais operadores de mutao, determinando um escore de a ca mutao bem prximo de 1. Observe-se que os operadores de mutao ORRN e VTWD, ca o ca que geraram os mutantes error-revealing, esto entre os operadores essenciais, o que neste a caso, no comprometeria a eccia da atividade de teste. a a

26

. . .
if(valid_id && (length >= 1) && (PRED(length) < 6)) { printf ("Valido\n"); }

. . .
if(valid_id && (length >= 1) && (length <= 6)) { printf ("Valido\n"); }

. . . (a) Mutante error-revealing

. . . (b) Mutante correto

Figura 12: Mutantes vivos do programa identier.

/**************************************************************************************** Identifier.c ESPECIFICACAO: O programa deve determinar se um identificador eh ou nao valido em Silly Pascal (uma estranha variante do Pascal). Um identificador valido deve comecar com uma letra e conter apenas letras ou digitos. Alem disso, deve ter no minimo 1 caractere e no maximo 6 caracteres de comprimento ****************************************************************************************/ #include <stdio.h> main () { char achar; int length, valid_id; length = 0; valid_id = 1; printf ("Identificador: "); achar = fgetc (stdin); valid_id = valid_s(achar); if(valid_id) { length = 1; } achar = fgetc (stdin); while(achar != \n) { if(!(valid_f(achar))) { valid_id = 0; } length++; achar = fgetc (stdin); } if(valid_id && (length >= 1) && (length <= { printf ("Valido\n"); } else { printf ("Invalid\n"); } }

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

1 1 1 1 1 1 1 1 1 2 2 2 3 4 5 5 6 6 6 7 7 7 8

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

/* 1 */ /* 1 */

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

int valid_s(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z))) { return (1); } else { return (0); } } int valid_f(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z)) || ((ch >= 0) && (ch <= 9))) { return (1); } else { return (0); } }

/* 1 */ /* 1 */

6)) /* 9 /* 9 /* 9 /* 10 /* 10 /* 10 /* 10 /* 11

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

Figura 13: Verso do programa identier corrigida. a

27

3.5

O Critrio Mutao de Interface e ca

O critrio Mutao de Interface [35] uma extenso da Anlise de Mutantes e preocupae ca e a a se em assegurar que as interaes entre unidades sejam testadas. Assim, o objetivo do co critrio Mutao de Interface inserir perturbaes nas conexes entre duas unidades. e ca e co o Utilizando o racioc nio do teste de mutao, casos de teste capazes de distinguir muca tantes de interface tambm devem ser capazes de revelar grande parte dos erros de intee grao. Essa armao depende, evidentemente, de quais mutantes so utilizados ou, em ca ca a outras palavras, quais operadores de mutao so aplicados [35]. ca a Segundo Haley e Zweben [98], os erros de integrao podem ser classicados em erros ca de integrao de dom e computacional. Dada uma funao F que chama G, o primeiro ca nio c 1 ocorre quando um erro de dom nio em G causa uma sa incorreta em F. O segundo da ocorre quando um erro computacional em G produz um valor incorreto que passado e para F que, por sua vez, produz uma sa incorreta. Em ambos os casos existe algum da valor incorreto sendo passado entre as unidades, o que resulta em uma sa incorreta. da Considerando esses aspectos poss classicar os erros de integrao em trs categorias. e vel ca e Considere um programa P e um caso de teste t para P . Suponha que em P existam funes F e G tal que F chama G. Considere SI(G) como o conjunto de valores passados co para G e SO(G) os valores retornados por G. Ao executar P com o caso de teste t, um erro de integrao identicado na chamada de G a partir de F quando [35]: ca e Erro Tipo 1 (Figura 14 (a)): os valores contidos em SI(G) no so os esperados por a a G, inuenciando a produo de sa ca das erradas antes do retorno de G. Esse tipo de erro ocorre, por exemplo, quando uma funo chamada com parmetros incorretos ca e a fazendo com que a funo chamada produza uma sa incorreta; ca da Erro Tipo 2 (Figura 14 (b)): os valores contidos em SI(G) no so os esperados a a por G, desse modo, SO(G) assume valores errados fazendo com que F produza uma sa incorreta aps o retorno de G. Um erro desse tipo pode ocorrer, por exemplo, da o quando um parmetro incorreto passado para a funo utilizado para calcular o a ca e valor de retorno; e Erro Tipo 3 (Figura 14 (c)): os valores contidos em SI(G) so os esperados por a G, mas valores incorretos em SO(G) so produzidos dentro de G e esses valores a fazem com que F produza um resultado incorreto aps o retorno de G. Esse tipo de o erro pode ocorrer se uma funo chamada com todos os parmetros corretos, mas ca e a internamente ela realiza um clculo incorreto produzindo um valor de retorno no a a esperado que, posteriormente, leva a um resultado incorreto. Percebe-se que esta classicao dos tipos de erros abrangente e no especica o ca e a local do defeito que causa o erro. Ela simplesmente considera a existncia de um valor e incorreto entrando ou saindo de uma funo chamada. Isso exclui, por exemplo, o caso em ca que SI(G) tem os valores esperados mas um erro dentro de G produz uma sa incorreta da antes do retorno de G. Neste caso, no existe nenhuma propagao de erro atravs da a ca e conexo F-G e esse tipo de erro deveria ser detectado no teste de unidade. a Operadores de mutao destinados ao teste de unidade possuem semelhanas e diferca c enas em relao aos operadores de mutao destinados ao teste de integrao. A idia c ca ca ca e
Um erro de dom ocorre quando um caminho incorreto executado; um erro computacional ocorre nio e quando o caminho correto executado mas o valor computado incorreto. e e
1

28

Saida

incorreta

Saida incorreta

SI (G)
incorreto

SI (G)
incorreto

So (G)
incorreto

So (G)
incorreto

G
(a)

Saida incorreta (b)

G
(c)

Figura 14: Tipos de Erros de Integrao [35]: (a) Erro Tipo 1, (b) Erro Tipo 2, (c) Erro ca Tipo 3. bsica de ambos a mesma, ou seja, introduzir modicaes sintticas no programa em a e co a teste transformando-o em programas similares: mutantes. Por outro lado, os operadores de mutao de interface esto relacionados a uma conexo entre duas unidades. Desse ca a a modo, os operadores, quando utilizados para testar uma conexo F-G, so aplicados de a a dois modos diferentes: 1) nos pontos onde F chama G; e 2) nos pontos dentro de G relacionados com a interface de comunicao entre as unidades. No segundo caso necessrio ca e a um mecanismo adicional que permita identicar o ponto a partir do qual G foi chamada. Visto que somente a conexo F-G est sendo testada, a mutao s deve estar ativa se G a a ca o foi chamada a partir de F. De outro modo, G deve se comportar da mesma forma que no programa original. Essa caracter stica pode requerer, em linguagens tais como C, que a deciso de aplicar ou no a mutao seja tomada em tempo de execuo [35]. a a ca ca 3.5.1 A Ferramenta de Teste P ROTEU M M/I

A ferramenta P ROTEU M semelhante ` ferramenta Proteum. A arquitetura e imM/I e a plementao de ambas so similares (em [35, 111] podem ser encontradas informaes ca a co detalhadas a respeito da arquitetura dessas ferramentas). A diferena existente entre c elas , basicamente, o conjunto de operadores de mutao que cada uma utiliza e o fato e ca de que a Proteum destina-se ao teste de unidade enquanto que a P ROTEU M oferece M/I caracter sticas para testar a conexo entre as unidades, ou seja, teste de integrao [130]. a ca

Figura 15: Grupos e operadores de mutao da P ca ROTEU M. M/I Dada uma conexo entre duas unidades F e G (F chamando G), existem dois grupos a de mutaes: os operadores do primeiro grupo (Grupo-I) aplicam mutaes no corpo da co co 29

funo G, por exemplo, incrementando a referncia a um parmetro formal. Os operca e a adores do segundo grupo (Grupo-II) realizam mutaes nos pontos onde a unidade F faz co chamadas ` unidade G, por exemplo, incrementando o argumento sendo passado para G. A a ferramenta P ROTEU M possui um conjunto de 33 operadores de mutao: 24 do Grupo-I M/I ca e 9 do Grupo-II. A Figura 15 ilustra a tela de gerao de mutantes da P ca ROTEU M. A M/I Tabela 7 apresenta a descrio de alguns dos operadores de interface. ca Tabela 7: Exemplos de operadores de mutao de interface. ca
Operador II-ArgAriNeg I-CovAllNod I-DirVarBitNeg I-IndVarBitNeg I-IndVarRepGlo I-IndVarRepExt I-IndVarRepLoc I-IndVarRepReq Descrio ca Acrescenta negaao aritmtica antes de argumento. c e Garante cobertura de ns. o Acrescenta negaao de bit em variveis de interface. c a Acrescenta negaao de bit em variveis no de interface. c a a Troca varivel no de interface por variveis globais utilizadas na funo chamada. a a a ca Troca varivel no de interface por variveis globais no utilizadas na funo chamada. a a a a ca Troca varivel no de interface por variveis locais, declaradas na funao chamada. a a a c Troca varivel no de interface por constantes requeridas. a a

E importante observar que a aplicao do critrio Mutaao de Interface est relaca e c a cionada ` conexo entre duas unidades e no a uma unidade somente. A Figura 16 a a a mostra o que acontece, por exemplo, quando a unidade F faz duas chamadas ` unidade a G. Nesse caso, os mutantes associados a primeira chamada s podero ser mortos por o a casos de teste que os exercitem a partir desse ponto de chamada. Para os mutantes do Grupo-II isso trivial visto que as mutaes so realizadas exatamente nos locais onde e co a F chama G. Entretanto, para os operadores do Grupo-I isso no ocorre. Visto que a a mutao realizada no corpo da unidade G, necessrio saber qual chamada ser usada ca e e a a de modo que o mutante s possa ser morto a partir daquele ponto de chamada. Caso a o unidade seja chamada a partir de outro ponto, ela deve se comportar como no programa original, ou seja, a mutao no deve ser habilitada [90]. ca a
F() { s1; s2;

...

G();

Primeiro Conjunto de Mutantes

...
G();

Figura 16: Conjuntos de mutantes gerados quando os operadores de interface so aplicados a a uma conexo F-G [90]. a Para ilustrar a aplicao do critrio Mutao de Interface, a seguir, da mesma forma ca e ca como anteriormente, a ferramenta P ROTEU M ser utilizada para avaliar a adequao dos M/I a ca conjuntos de casos de teste adequados aos critrios Particionamento em Classes de Equive alncia (T0 ), Todos-Potenciais-Usos (T2 ) e Anlise de Mutantes (T5 ). As Figuras 17(b), e a

...

Segundo Conjunto de Mutantes

30

17(c) e 17(d) ilustram as coberturas obtidas para esses conjuntos de casos de teste, respectivamente.

(a) Conjunto T0

(b) Conjunto T0 e equivalentes

(c) Conjunto T2

(d) Conjunto T5

Figura 17: Telas de status da sesso de teste da ferramenta P a ROTEU M. M/I Como pode ser observado, utilizando-se todos os operadores de mutao de interface, ca foram gerados 456 mutantes. A t tulo de ilustrao, a Figura 18 mostra dois dos mutantes ca de interface gerados para o programa identier. O mutante da Figura 18 (a) foi gerado pelo operador I-DirVarIncDec do Grupo-I e o mutante da Figura 18 (b) foi gerado pelo operador II-ArgAriNeg do Grupo-II. Observe que no caso do mutante da Figura 18 (a), existe uma funao PREPARE MUTA() c no ponto de chamada da funo que se deseja testar, no caso a funo valid_s, e no corpo ca ca de valid_s, outra funo (IF MUTA()) verica se a mesma foi chamada a partir do ponto ca desejado, do contrrio a mutao no ativada. a ca a e Aps a execuo dos mutantes de interface com o conjunto T0 , 243 mutantes pero ca maneceram vivos, resultando em um escore de mutao de, aproximadamente, 0,47 (Figura 17(a)). ca Analisando-se os mutantes vivos, observa-se que 28 deles eram equivalentes. Recalculando o escore de mutao, eliminando os equivalentes, o valor obtido para T0 passou a ser de ca 0,497 Figura 17(b). Tal resultado demonstra que se somente o conjunto de casos de teste funcional fosse utilizado, mais de 50% dos requisitos de teste exigidos pelo critrio e Mutao de Interface no teriam sido cobertos por T0 . ca a Em seguida, na Figura 17(c) tem-se a adequao do conjunto Todos-Potenciais-Usosca adequado (T2 ) em relao ` Mutao de Interface. Observa-se que, mesmo tendo o dobro ca a ca

31

. . .
main() { ... printf ("Identificador: "); achar = fgetc (stdin); (valid_id = PREPARE2_MUTA(valid s(achar))); ... } int valid_s(char ch) { if(IF_MUTA(((ch >= ((ch >= ((ch ((ch >= { return (1); } else { return (0); } }

. . .

A) && a) && >= A) a) &&

(ch <= (ch <= && (ch (ch <=

Z)) || z)), <= Z)) || z)))

printf ("Identificador: "); achar = fgetc (stdin); valid_id = valid_s(-achar); if(valid_id) { length = 1; }

. . . (a) Mutante do Grupo-I

. . . (b) Mutante do Grupo-II

Figura 18: Exemplos de mutantes gerados pela ferramenta P ROTEU M. M/I de casos de teste que T0 , o escore de mutao obtido com T2 ainda no satisfatrio (0,50) ca a e o e a metade dos requisitos exigidos pela Mutao de Interface ainda no foram satisfeitos. ca a Continuando a avaliar a cobertura obtida pelo conjunto de casos de teste adequados ao critrio Anlise de Mutantes (T5 ) observa-se que foi poss obter um conjunto Mue a vel tao de Interface-adequado, ou seja, para o programa identier, um conjunto de casos de ca teste Anlise de Mutantes-adequado tambm se mostrou Mutao de Interface-adequado a e ca (Figura 17(d)). Deve-se observar que os critrios Anlise de Mutantes e Mutao de Ine a ca terface so incomparveis do ponto de vista da relao de incluso [51]. Nos experimentos a a ca a conduzidos, utilizando-se programas de maior complexidade, observou-se que conjuntos de casos de teste Anlise de Mutantes-adequados no eram Mutao de Interface-adequados a a ca e vice-versa. Em n vel de unidade, observou-se que os critrios Anlise de Mutantes e e a Todos-Potenciais-Usos so incomparveis tanto do ponto de vista terico quanto emp a a o rico [43]. Tais resultados motivam a investigar qual a relao existente entre o critrio Mutao ca e ca de Interface e os critrios Potenciais-Usos de unidade [4] e de integrao [101]. e ca

Automatizao da Atividade de Teste ca

A qualidade e produtividade da atividade de teste so dependentes do critrio de teste a e utilizado e da existncia de uma ferramenta de teste que o suporte. Sem a existncia de e e uma ferramenta automatizada a aplicao de um critrio torna-se uma atividade propensa ca e a erros e limitada a programas muito simples. A disponibilidade de ferramentas de teste permite a transferncia de tecnologia para as e indstrias e contribui para uma cont u nua evoluo de tais ambientes, fatores indispensveis ca a para a produo de software de alta qualidade. Alm disso, a existncia de ferramentas ca e e automatizadas auxiliam pesquisadores e alunos de Engenharia de Software a adquirir os conceitos bsicos e experincia na comparao, seleo e estabelecimento de estratgias a e ca ca e de teste.

32

Outro fator importante o suporte oferecido pelas ferramentas aos testes de regresso. e a Os casos de teste utilizados durante a atividade de teste podem ser facilmente obtidos para revalidao do software aps uma modicao. Com isso, poss checar se a funcionalca o ca e vel idade do software foi alterada, reduzir o custo para gerar os testes de regresso e comparar a os resultados obtidos nos testes de regresso com os resultados do teste original [43]. a No que diz respeito ao teste de mutao, as primeiras ferramentas comearam a surgir ca c no nal da dcada de 70 e in da dcada de 80 [25,131]. Tais ferramentas apresentavam e cio e algumas limitaes e eram destinadas ao teste de programas escritos em Fortran. A partir co do nal da dcada de 80 e durante a dcada de 90 novas ferramentas foram desenvolvie e das a m de suprir as decincias encontradas nas anteriores. Entre elas destacam-se a e Mothra [53, 115], a Proteum [62, 111] e a P ROTEU M [35, 132]. M/I A Mothra uma ferramenta de apoio ao critrio Anlise de Mutantes para o teste de e e a programas na linguagem FORTRAN. Foi desenvolvida na Purdue University e Georgia Institute of Technology e possui 22 operadores de mutao [53, 115]. Alm disso, a ferraca e menta apresenta interface baseada em janelas, facilitando a visualizao das informaes, ca co e permite a incorporao de outras ferramentas (gerador de casos de teste, vericador de ca equivalncia e orculo). e a As ferramentas Proteum [62, 111] e P ROTEU M [35, 132] foram desenvolvidas no InM/I stituto de Cincias Matemticas e de Computao ICMC/USP e apiam a aplicao e a ca o ca os critrios Anlise de Mutantes e Mutao de Interface, respectivamente. Ambas so e a ca a ferramentas multi-linguagem, ou seja, permitem testar programas escritos em diferentes linguagens de programao; atualmente esto conguradas para o teste de programas esca a critos na linguagem C. O que diferencia ambas as ferramentas o conjunto de operadores e de mutao utilizados em cada uma e o fato de que a Proteum/IM oferece caracter ca sticas para testar a conexo entre as unidades do software. a Quanto aos critrios baseados em anlise de uxo de dados, como um dos primeiros e a esforos signicantes tem-se a ferramenta Asset (A System to Select and Evaluate Tests), c desenvolvida na New York University em 1985 por Frankl e Weyuker [55] para o teste de programas Pascal. Esta utiliza os critrios de adequao baseados na anlise de uxo de e ca a dados denidos por Rapps e Weyuker [30, 31]. A Proteste [71] tem como objetivo implementar um ambiente completo para suporte ao teste estrutural de programas escritos em Pascal, incluindo tanto critrios baseados e em uxo de controle (Todos-Ns e Todos-Arcos) quanto critrios baseados em uxo de o e dados (os denidos por Rapps e Weyuker [30, 31] e os Potenciais-Usos [4]). Alm de e Pascal, poss congurar o ambiente para outras linguagens atravs da utilizao de e vel e ca uma ferramenta que gera analisadores de cdigo fonte espec o cos para cada linguagem. O ambiente Proteste um prottipo desenvolvido na Universidade Federal do Rio Grande e o do Sul. Um dos esforos mais signicativos no contexto de ferramentas de teste foi o desenc volvimento da Atac (Automatic Test Analysis for C), pela Telcordia Technologies [56]. A Atac apia a aplicao de critrios estruturais de uxo de controle e de dados no teste de o ca e programas escritos nas linguagens C e C++. Basicamente, a ferramenta permite vericar a adequao de um conjunto de casos de teste, visualizar cdigo no coberto pelos casos ca o a de teste, auxiliar na gerao de casos de teste e reduzir o tamanho do conjunto de teste, ca atravs da eliminao de casos de teste redundantes. e ca Atualmente a Atac est integrada ao xSuds (Telcordia Software Visualization and Anala ysis Toolsuite), um ambiente de suporte `s atividades de teste, anlise e depurao [80]. a a ca 33

O ambiente xSuds vem sendo comercializado pela IBM, sendo uma forte evidncia de que e o uso de critrios baseados em uxo de dados constituir, em um futuro prximo, o estado e a o da prtica no que diz respeito ao teste de software. a As ferramentas de teste, embora implementem tcnicas e critrios diferentes, apree e sentam caracter sticas globais bastante semelhantes. Assim, pode-se identicar conjuntos bsicos de operaes que caracterizam atividades pertinentes ao processo de teste de softa co ware. As operaes realizadas por tais ferramentas podem ser divididas em [133]: criao co ca da sesso de teste, tratamento de casos de teste (adio, eliminao, visualizao, impora ca ca ca tao e minimizao do conjunto de casos de teste), gerao dos requisitos de teste, anlise ca ca ca a da adequao do conjunto de casos de teste e gerao de relatrios. Na Tabela 8 esto ca ca o a sintetizadas algumas das principais caracter sticas das ferramentas Proteum, P ROTEU M M/I e PokeTool. Tabela 8: Principais caracter sticas das ferramentas PokeTool, Proteum e P ROTEU M. M/I
PokeTool C, COBOL, FORTRAN No a Sim Sim No a Sim Menu, Janelas e Scripts Sim Sim Sim No se aplica a Compilado No a Sim Proteum C No a Sim Sim No a Sim Janelas e Scripts Sim Sim Sim Sim Compilado No a No a

P ROTEU M M/I
C No a Sim Sim No a No a Janelas e Scripts Sim Sim Sim Sim Compilado No a No a

Linguagem Geraao automtica de casos de teste c a Ediao de casos de teste c Registro sobre caminhos no exea cutveis ou mutantes equivalentes a Restriao de tamanho do programa a c ser testado Eliminaao de casos de teste redunc dantes Interface Sesses de teste o Apoio a experimentos Importaao de casos de teste c Geraao seletiva de mutantes c Ambiente compilado/interpretado Execuao distribu c da Determinaao automtica de mutantes c a equivalentes ou caminhos no exea cutveis (heur a sticas)

Estudos Emp ricos

Em virtude da diversidade de critrios de teste existente, saber qual deles deve ser e utilizado ou como utiliz-los de forma complementar a m de obter o melhor resultado a com o menor custo uma questo complicada. A realizao de estudos emp e a ca ricos procura, atravs da comparao entre os critrios, obter uma estratgia que seja ecaz para revelar e ca e e a presena de erros no programa, ao mesmo tempo em que apresente um baixo custo de c aplicao. ca Para entender a importncia desses estudos, considere a seguinte situao [41]: a ca e preciso testar um programa P que ser usado em um ambiente de segurana cr a c tica e o funcionamento desse sistema depende de que P tenha sido bem testado. O testador deve testar P tanto quanto for poss e, para isso, decide usar vrios critrios de teste a m vel a e 34

de vericar a adequao dos casos de teste desenvolvidos. Inicialmente, os casos de teste ca so gerados de modo a satisfazerem um determinado critrio C1 . Assim, uma questo a e a que surge : Tendo obtido um conjunto de casos de teste T adequado ao critrio C1 e, e e utilizando agora o critrio C2 , consegue-se melhorar o conjunto de casos de teste T?. e Atravs de estudos emp e ricos procura-se responder a essa e outras questes que surgem o diante da diculdade em decidir quando um programa est sucientemente testado. a Segundo Wong et al. [47], custo, eccia e diculdade de satisfao (strength) a ca so fatores bsicos para comparar a adequao dos critrios de teste. Custo: refere-se a a ca e ao esforo necessrio na utilizao de um critrio. Pode ser medido atravs do nmero c a ca e e u de casos de teste requeridos para satisfazer o critrio ou por outras mtricas dependentes e e do critrio, tais como: o tempo necessrio para executar todos os mutantes gerados ou o e a tempo gasto para identicar os mutantes equivalentes, caminhos e associaes no execo a cutveis, construir manualmente os casos de teste e aprender a utilizar as ferramentas de a teste. Eccia: refere-se ` capacidade de um critrio em detectar um maior nmero de a a e u erros em relao a outro. Diculdade de satisfao: refere-se ` probabilidade de satisfazer ca ca a um critrio tendo satisfeito outro [41]; seu objetivo vericar o quanto consegue-se sate e isfazer um critrio C1 tendo satisfeito um critrio C2 (C1 e C2 so incomparveis ou C1 e e a a inclui C2 ). Utilizando-se tais fatores comparativos, estudos emp ricos e tericos so conduzidos o a com o objetivo de encontrar formas econmicas e produtivas para a realizao dos testes. o ca O desenvolvimento de experimentos requer a elaborao de um framework para sua conca duo. Esse framework composto, basicamente, pelas seguintes atividades [42]: ca e seleo e preparao dos programas; ca ca seleo das ferramentas de teste; ca gerao de conjuntos de casos de teste; ca execuo dos programas com os casos de teste gerados; ca anlise dos resultados do experimento. a A gerao dos conjuntos de casos de teste feita, em geral, aleatoriamente. A gerao ca e ca aleatria alm de ser facilmente automatizada e de gerar grandes conjuntos de casos o e de teste a baixo custo, tambm elimina poss e veis inuncias do testador em conduzir e a gerao dos casos de teste de acordo com o conhecimento dos programas utilizados. ca Normalmente, dene-se o dom nio de entrada de cada programa para a gerao aleatria ca o e, quando no se consegue satisfazer o critrio, casos de teste criados manualmente so a e a adicionados ao conjunto [43]. Alm dessas atividades, conforme o tipo de experimento a ser realizado, so necessrias e a a atividades adicionais. Ao comparar o critrio Anlise de Mutantes com os critrios baseae a e dos em anlise de uxo de dados, por exemplo, necessrio, durante a execuo dos proa e a ca gramas, identicar os mutantes equivalentes e os caminhos/associaes no executveis. co a a 5.0.2 Estudos Emp ricos: Critrios Baseados em Anlise de Fluxo de Dados e a e Critrios Baseados em Mutao e ca

Do ponto de vista terico, os critrios baseados em anlise de uxo de dados tm como e a e plexidade exponencial [4], o que motiva a conduo de estudos emp ca ricos para determinar o custo de aplicao desses critrios do ponto de vista prtico. ca e a 35

Estudos emp ricos foram conduzidos para determinao da complexidade desses critrios ca e em termos prticos, ou seja, uma avaliao emp a ca rica desses e de outros critrios de teste e objetivando a determinao de um modelo para estimativa do nmero de casos de teste ca u necessrios. Essa determinao muito importante para as atividades de planejamento a ca e do desenvolvimento, por razes bvias. Weyuker [88] caracterizou um benchmark para o o a avaliao emp ca rica de uma fam de critrios de teste estruturais; esse mesmo benchlia e mark foi aplicado para uma primeira avaliao emp ca rica dos critrios Potenciais-Usos [134]. e Com a aplicao do benchmark, obtiveram-se resultados bastante interessantes. Em geral, ca pode-se dizer que os critrios Potenciais-Usos, do ponto de vista prtico, so fact e a a veis e demandam um nmero de casos de teste relativamente pequeno. u Atravs de estudos emp e ricos tm-se obtido evidncias de que a Anlise de Mutantes e e a tambm pode constituir na prtica um critrio atrativo para o teste de programas [45]. e a e Tais experimentos, alm de mostrarem como a Anlise de Mutantes se relaciona com e a outros critrios de teste, buscam novas estratgias a m de reduzir os custos associados e e ao critrio. e Mathur e Wong [45] compararam dois critrios de mutao alternativos: a Mutao e ca ca Aleatria (no caso, foi selecionado 10% de cada operador de mutao) e a Mutao Reo ca ca strita. Esse experimento foi conduzido para comparar qual dessas estratgias apresentava e melhor relao custo/eccia. Segundo os autores, ambas mostraram-se igualmente eca a cazes, obtendo-se signicativa reduo no nmero de mutantes a serem analisados sem ca u sens perda na eccia em revelar erros. vel a Em outro trabalho realizado por Mathur e Wong [41] foi comparada a adequao de ca conjuntos de casos de teste em relao aos critrios Anlise de Mutantes e Todos-Usos. ca e a O objetivo do experimento era vericar a diculdade de satisfao entre os dois critrios, ca e bem como seus custos, uma vez que esses critrios so incomparveis do ponto de vista e a a terico. Nesse estudo, os conjuntos de casos de teste Anlise de Mutantes-adequados o a tambm se mostraram Todos-Usos-adequados. No entanto, os conjuntos de casos de teste e Todos-Usos-adequados no se mostraram, em muitos dos casos, adequados para o critrio a e Anlise de Mutantes. Esses resultados demonstram que mais dif satisfazer o critrio a e cil e Anlise de Mutantes do que o critrio Todos-Usos, podendo-se dizer, na prtica, que a e a Anlise de Mutantes inclui Todos-Usos [41]. a Wong et al. [47] utilizaram a Mutao Aleatria (10%) e a Mutao Restrita para ca o ca comparar o critrio Anlise de Mutantes com o critrio Todos-Usos; o objetivo era verie a e car o custo, eccia e diculdade de satisfao desses critrios. Os autores forneceram a ca e evidncias de que os critrios Todos-Usos, Mutao Aleatria (10%) e Mutao Restrita e e ca o ca representam, nesta ordem, o decrscimo do custo necessrio para a aplicao do critrio e a ca e (nmero de casos de teste requeridos), ou seja, o critrio Todos-Usos requer mais casos de u e teste para ser satisfeito do que a Mutao Restrita. Em relao ` eccia para detectar ca ca a a erros, a ordem (do mais ecaz para o menos) Mutao Restrita, Todos-Usos e Mutao e ca ca Aleatria. Observou-se, com isso, que examinar somente uma pequena porcentagem de o mutantes pode ser uma abordagem util na avaliao e construo de conjuntos de casos ca ca de teste na prtica. Desse modo, quando o testador possui pouco tempo para efetuar a os testes (devido ao prazo de entrega do produto) pode-se usar o critrio de Anlise de e a Mutantes para testar partes cr ticas do software, utilizando alternativas mais econmicas, o tal como a Mutao Restrita ou o critrio Todos-Usos, para o teste das demais partes do ca e software, sem comprometer signicativamente a qualidade da atividade de teste.

36

Outt tambm realizou um experimento comparando o critrio Anlise de Mutantes e e a com o critrio Todos-Usos [135]. Os resultados foram semelhantes `queles obtidos por e a Wong et al. [47], ou seja, o critrio Anlise de Mutantes revelou um maior nmero de e a u erros do que o critrio Todos-Usos e mais casos de testes foram necessrios para satisfazer e a o critrio Anlise de Mutantes. Alm disso, os conjuntos de casos de teste Anlise de e a e a Mutantes-adequados foram adequados ao critrio Todos-Usos, no sendo o inverso vere a dadeiro, resultado semelhante ao de Mathur [41]. Nos trabalhos de Wong et al. [48] e Souza [43] foram comparadas seis diferentes classes de mutao restrita quanto ` eccia em revelar erros. Analisou-se a eccia das classes ca a a a de mutao obtidas a partir dos operadores de mutao da ferramenta Proteum. Desse ca ca experimento pode-se observar quais classes de mutao eram mais econmicas (baixo ca o custo de aplicao) e ecazes. Com isso, foi poss o estabelecimento de uma ordem ca vel incremental para o emprego dessas classes de mutao, com base na eccia e custo de ca a cada uma. Desse modo, os conjuntos de casos de testes podem ser constru dos inicialmente de forma a serem adequados ` classe com menor relao custoeccia. Na seqncia, a ca a ue quando as restries de custo permitirem, esse conjunto pode ser melhorado de modo a co satisfazer as classes de mutao com maior relao custoeccia. ca ca a Souza [43] realizou um estudo emp rico com a nalidade de avaliar o strength e o custo do critrio Anlise de Mutantes empregando, para efeito comparativo, os critrios e a e Potenciais-Usos [4], os quais incluem o critrio Todos-Usos. Os resultados demonstraram e que o custo de aplicao do critrio Anlise de Mutantes, estimado pelo nmero de casos de ca e a u teste necessrio para satisfazer o critrio, apresentou-se maior do que o custo dos critrios a e e Potenciais-Usos. Em relao ` diculdade de satisfao (strength) observou-se que, de uma ca a ca maneira geral, os critrios Anlise de Mutantes e Todos-Potenciais-Usos (PU) so income a a parveis mesmo do ponto de vista emp a rico. J os critrios Todos-Potenciais-Usos/Du a e (PUDU) e Todos-Potenciais-DU-Caminhos (PDU) [4] apresentaram maior strength que o critrio Todos-Potenciais-Usos (PU) em relao ` Anlise de Mutantes, o que motiva a e ca a a investigar-se o aspecto complementar desses critrios quanto a eccia. e ` a Entre os estudos emp ricos que visam a estabelecer alternativas viveis para a aplicao a ca do critrio Anlise de Mutantes pode-se destacar o trabalho de Outt et al. [46]. O e a objetivo do estudo conduzido por Outt et al. [46] era determinar um conjunto essencial de operadores de mutao para o teste de programas FORTRAN, a partir dos 22 operadores ca de mutao utilizados pela Mothra. Os resultados obtidos demonstraram que apenas cinco ca eram sucientes para aplicar ecientemente o teste de mutaao. c Nessa mesma linha, um estudo preliminar realizado por Wong et al. [136], comparando a Mutao Restrita no contexto das linguagens C e Fortran, resultou na seleo de um ca ca subconjunto de operadores de mutao da ferramenta Proteum [62, 137], constituindo ca uma base para a determinao do conjunto essencial de operadores de mutao para a ca ca linguagem C. A aplicao deste subconjunto de operadores possibilitou reduzir o nmero ca u e mutantes gerados, mantendo a eccia do critrio em revelar a presena de erros. A a e c seleo dos operadores de mutao foi realizada com base na experincia dos autores e ca ca e os resultados motivaram a conduo do trabalho de Barbosa [79]. Nesse trabalho forma ca conduzidos experimentos com o objetivo de investigar alternativas pragmticas para a a aplicao do critrios Anlise de Mutantes e, nesse contexto, foi proposto o procedimento ca e a Essencial para a determinao de um conjunto essencial de operadores de mutao para a ca ca linguagem C, com base nos operadores de mutao implementados na ferramenta Proteum. ca

37

Para a aplicao e validao desse procedimento dois experimentos foram conduzidos. ca ca No primeiro, utilizou-se um grupo de 27 programas os quais compem um editor de texto o simplicado; no segundo, 5 programas utilitrios do UNIX foram utilizados. De um modo a geral, ambos os conjuntos essenciais obtidos apresentaram um alto grau de adequao ca em relao ao critrio Anlise de Mutantes, com escores de mutao acima de 0,995, ca e a ca proporcionando, em mdia, redues de custo superiores a 65% [79]. e co Com a proposio do critrio Mutao de Interface [35, 120] evidente o aspecto ca e ca e positivo de se utilizar o mesmo conceito de mutao nas diversas fases do teste. Tamca bm natural a indagao sobre qual estratgia utilizar para se obter a melhor relao e e ca e ca custoeccia quando so aplicados os critrios Anlise de Mutantes e Mutao de Ina a e a ca terface no teste de um produto. Nesse contexto, investigou-se empiricamente qual o relacionamento entre os critrios Anlise de Mutantes e Mutao de Interface e como e a ca utilizar tais critrios de forma complementar na atividade de teste, tendo como objetivo e contribuir para o estabelecimento de uma estratgia de teste incremental, de baixo custo e de aplicao e que garanta um alto grau de adequao em relao a ambos os critrios [44]. ca ca ca e Inicialmente, estabeleceu-se uma estratgia incremental para a aplicao dos opere ca adores de mutao implementados na ferramenta P ca ROTEU M [35], procurando reduzir o M/I custo de aplicao do critrio Mutao de Interface. A utilizao dessa estratgia possibilca e ca ca e itou uma reduo no custo de aplicao do critrio Mutao de Interface em torno de 25% ca ca e ca e, ainda assim, conjuntos de casos de teste MI-adequados foram obtidos. Alm disso, um e estudo preliminar para a determinao do conjunto essencial de operadores de mutao ca ca interface foi conduzido, utilizando o procedimento Essencial denido por Barbosa [79]. O conjunto essencial obtido possibilitou a seleo de conjuntos de casos de teste altamente ca adequados ao critrio Mutao de Interface (escores de mutao em torno de 0,998) com e ca ca reduo de custo, em termos do nmero de mutantes gerados, superior a 73% [44]. ca u A diculdade de satisfao entre os critrios Anlise de Mutantes e Mutao de Interca e a ca face tambm foi avaliada, observando-se que tais critrios so incomparveis do ponto de e e a a vista da relao de incluso [30], devendo ser utilizados em conjunto para assegurar um ca a teste de melhor qualidade. Explorando o aspecto complementar desses critrios, algumas e estratgias de aplicao dos operadores de mutao de unidade e de integrao foram e ca ca ca estabelecidas. Tais estratgias demonstraram que, mesmo com um nmero reduzido de e u operadores, poss determinar conjuntos de casos de teste adequados ou muito prxie vel o mos da adequao para ambos os critrios, a um menor custo [44]. ca e

Aplicao do Critrio Anlise de Mutantes no Conca e a texto de Especicaes Formais co

Tcnicas de especicao formal fornecem uma linguagem com sintaxe e semntica e ca a formalmente denidas que possibilitam a denio do sistema de forma mais completa, ca consistente, precisa e no amb a gua. As tcnicas formais so empregadas durante a especie a cao, anlise e projeto, principalmente, de sistemas de segurana cr ca a c tica. Apesar de todo rigor das tcnicas formais, no se garante que a especicao formal e a ca esteja livre de erros e de acordo com os requisitos do usurio. Observa-se tambm que a e quanto mais cedo os erros so detectados no processo de desenvolvimento, menos dif a cil torna-se a tarefa de remov-los. e

38

Algumas iniciativas de denio de critrios de teste para a validao de especicaes ca e ca co formais so identicadas. Tcnicas para seleo de seqncias de teste para especicaes a e ca ue co baseadas em Mquinas de Estados Finitos e Mquinas de Estados Finitos Estendidas so a a a propostas, principalmente para o teste de conformidade de protocolos de comunicao. ca Os critrios de teste propostos por Ural [138], Probert e Guo [139], Fabbri [22], Souza et e al. [140] procuram utilizar o conhecimento adquirido no teste de programas, mapeando critrios de teste empregados no n de programa para o n de especicao. Essa e vel vel ca abordagem tem se mostrado promissora e pode complementar as tcnicas de simulao e ca e anlise de alcanabilidade, normalmente empregadas para a validao de especicaes a c ca co baseadas em Mquinas de Estados, Redes de Petri, Estelle, entre outras. a Nesta seo, so apresentados os resultados da denio do critrio Anlise de Muca a ca e a tantes no contexto de especicaes formais, em particular, especicaes baseadas em co co Redes de Petri, Mquinas de Estados Finitos, Statecharts e Estelle. Essas tcnicas formais a e possuem apoio grco e por isso so bastante empregadas, pois facilitam a visualizao e a a ca a descrio do sistema. ca As Redes de Petri foram criadas para modelar sistemas que apresentam concorrncia, e paralelismo, comunicao s ca ncrona e ass ncrona [141]. Sua execuo gera uma seqncia ca ue de eventos, obtidos a partir do disparo das transies, podendo ocorrer no determinismo co a no disparo das transies. Outro fator importante que as Redes de Petri podem ser co e utilizadas para anlise de alcanabilidade do sistema e para deteco de impasses (deada c ca lock), sendo que a rvore de alcanabilidade uma das principais tcnicas para anlise de a c e e a Redes de Petri [22]. A tcnica Mquinas de Estados Finitos (MEFs) muito utilizada para especicao e a e ca do aspecto comportamental de sistemas reativos, particularmente, na rea de protocolos a de comunicao [142]. Sistemas Reativos so sistemas baseados em eventos que reagem ca a a est mulos internos ou do ambiente, interagindo com o mesmo de forma a produzir resultados corretos dentro de intervalos de tempo previamente especicados [143]. So a sistemas que devem funcionar com alto grau de conabilidade, pois falhas podem ocasionar perdas humanas e econmicas. O sistema modelado em uma MEF descrito por uma o e mquina, composto de estados e transies, estando em somente um de seus estados num a co dado momento. A partir de uma entrada, a mquina gera uma sa e muda de estado. a da A mquina pode ser representada por um diagrama de transio de estados ou por uma a ca tabela de transio, esta ultima seguindo o modelo de Mealy interseo da linha com a ca ca coluna especica o prximo estado e a sa gerada; ou o modelo de Moore interseo o da ca da linha com a coluna contm apenas o prximo estado e existe uma coluna separada para e o indicar a sa associada com cada estado [144]. Com o objetivo de aumentar o poder da de representao das MEFs, extenses dessa tcnica so propostas, podendo-se citar: ca o e a Mquinas de Estados Finitos Estendidas (MEFEs) que representa o uso e denio a ca de variveis associadas `s transies; e Mquinas de Estados Finitos com Comunicao a a co a ca (MEFCs) que representam os aspectos de comunicao entre MEFs atravs de canais ca e de comunicao com las associadas. ca Statecharts uma tcnica de especicao formal proposta por Harel [143] para dee e ca screver o aspecto comportamental de sistemas reativos, atravs de uma hierarquia de e MEFEs. As caracter sticas dessa tcnica a tornam mais atrativa que outras tcnicas fore e mais, como MEF, MEFE e Redes de Petri. Tais caracter sticas so: apresentao do a ca modelo por meio de uma hierarquia de MEFEs, que torna o modelo mais claro sendo poss visualizar os aspectos de concorrncia; ortogonalidade, que possibilita descrever vel e 39

o paralelismo entre os componentes (MEFEs) do modelo especicado; broadcasting ou reao em cadeia, que permite descrever a sincronizao entre os componentes ortogonais ca ca do modelo; e histria, que possibilita lembrar estados que foram visitados previamente. o Essa tcnica permite descrever a dinmica dos sistemas reativos, de forma clara e ree a al stica, e ao mesmo tempo formal e rigorosa, de maneira a possibilitar tambm uma e simulao detalhada do sistema [143]. ca Estelle - Extended State Transition Language uma tcnica de descrio formal desene e ca volvida pela ISO (International Standards Organization), para especicao de sistemas ca distribu dos, protocolos de comunicao e servios. O padro ISO 9074 (1987) descreve a ca c a semntica e sintaxe formal dessa tcnica. Um sistema especicado em Estelle estrutua e e rado em uma hierarquia de mdulos que se comunicam atravs de troca de mensagens. O o e comportamento de cada mdulo descrito atravs de uma MEFE e utiliza, com algumas o e e restries, a linguagem Pascal, o que torna Estelle uma tcnica de fcil aprendizagem. As co e a mensagens recebidas pelos mdulos so armazenadas em las de tamanho innito (tipo o a FIFO - rst in rst out) e so processadas de acordo com as condioes, prioridades e atraa c sos associados `s transies da MEFE. Estelle permite a descrio de paralelismo s a co ca ncrono e ass ncrono entre as MEFEs do sistema, permitindo evoluo dinmica da congurao ca a ca do sistema. A especicao pode ser descrita em diferentes n ca veis de abstrao, vindo da ca forma mais abstrata at aproximar-se da implementao [145]. e ca Para a denio do critrio Anlise de Mutantes no contexto de especicaes feito ca e a co e um mapeamento da hiptese do programador competente, denindo a hiptese do eso o pecicador ou projetista competente: se a especicao em teste foi constru por ca da um projetista ou especicador competente ou est correta ou est muito prxima do a a o correto. Fabbri [22] dene mais formalmente: dada uma especicao S, gera-se um conca junto de mutantes de S, (S), com base em um conjunto de operadores de mutao, cuja ca denio um ponto fundamental para aplicao do critrio Anlise de Mutantes, e diz-se ca e ca e a que um conjunto de teste T adequado para S em relao a se para cada especicao e ca ca Z (S), ou Z equivalente a S, ou Z difere de S em pelo menos um ponto de T . e Como mencionado anteriormente, um aspecto fundamental do critrio Anlise de Mue a necessrio que esse conjunto tantes a denio do conjunto de operadores de mutao. E e ca ca a consiga representar os tipos de erros mais comuns que podem ser cometidos, no caso, pela tcnica de especicao. e ca Desse modo, Fabbri [22] dene o critrio Anlise de Mutantes para validao de ese a ca pecicaes baseadas em Redes de Petri, em Mquinas de Estado Finito e em Statecharts, co a considerando, para denio do conjunto de operadores de mutao de cada tcnica, a ca ca e classicao de erros sugerida por Chow [12]. Chow classica os erros de Mquinas de Esca a tados Finitos em 3 tipos: erros de transferncia (erros de transio), erros de operao e ca ca (erros de sa da) e erros de estados extras ou ausentes (erros de estados). Para a tcnica Statecharts, o conjunto de operadores de mutao formado pelos e ca e operadores denidos para MEF; pelos operadores de mutao para MEFEs, os quais foram ca denidos com base nos operadores de mutao para a linguagem C [112] e que so relativos ca a ao uso de variveis e condies; e por alguns operadores de mutao relativos aos aspectos a co ca intr nsecos de Statecharts, como histria, broadcasting e paralelismo. Trs estratgias de o e e abstrao para aplicao do critrio Anlise de Mutantes para Statecharts so propostas: ca ca e a a Bsica, Baseada em Ortogonalidade e Baseada em Histria. Essas estratgias permitem a o e selecionar os componentes do Statecharts em diferentes n veis de hierarquia, possibilitando que a conduo do teste seja realizada atravs das abordagens top-down ou bottomca e 40

up. A partir dos componentes, o teste da especicao pode partir do n ca vel mais alto de abstrao, que corresponde ao prprio Statecharts, ou partir do n mais baixo de ca o vel abstrao, composto pelos componentes cujos estados so tomos ou bsicos [22]. ca a a a Para a denio do critrio Anlise de Mutantes para Estelle, Souza et al. [146] utica e a lizaram como base os operadores de mutao denidos por Fabbri [22] para MEF e MEFE; ca o trabalho de Probert e Guo [139], que dene operadores de mutao para o aspecto ca comportamental (MEFE) de Estelle; e o critrio Mutao de Interface denido por Delae ca maro [120]. Os operadores de mutao para Estelle so divididos em 3 classes de acordo ca a com os aspectos da especicao que so abordados: mutao nos mdulos, que conca a ca o siste, basicamente, na aplicao de operadores de mutao para as MEFEs dos mdulos; ca ca o mutao de interface, que procura validar os aspectos de comunicao entre os mdulos ca ca o do sistema; e mutao na estrutura, que aplica os operadores de mutao nos aspectos ca ca arquiteturais da especicao, como por exemplo, nas conexes entre os mdulos. Uma ca o o estratgia incremental para aplicao dos operadores de mutao apresentada. e ca ca e Critrios de mutao alternativo tambm foram denidos para as tcnicas de especie ca e e cao, visando a reduzir o nmero de mutantes gerados e, conseqentemente, o custo do ca u u critrio Anlise de Mutantes. So utilizados os critrios mutao aleatria (seleo de 10% e a a e ca o ca dos mutantes de cada operador) e mutao restrita, visto que esses critrios apresentam ca e bons resultados para o n de programas, conforme apresentado na Seo 3.4. vel ca Mecanismos e ferramentas para automatizar a aplicao do critrio Anlise de Muca e a tantes no contexto dessas especicaes formais tambm tm sido explorados. Utilizando co e e a ferramenta Proteum como base, foram denidas as ferramentas: Proteum-RS/FSM que apia o teste de especicaes baseadas em MEF [147]; Proteum-RS/ST que apia o co o o teste de especicaes baseadas em Statecharts [127,148] e Proteum-RS/PN que apia co o o teste de especicaes baseadas em Redes de Petri [125, 126]. A disponibilidade dessas co ferramentas permite a realizao de experimentos para avaliar o custo e tambm eccia ca e a do critrio Anlise de Mutantes no contexto de especicaes. Esses aspectos esto sendo e a co a investigados. Ainda no contexto do teste de especicaes, Wong et al. [149] investigaram como co critrios de uxo de controle e de dados poderiam ser utilizados no teste de especicaes e co em SDL. Para auxiliar as atividades de teste e validao de especicaes, foi desenca co volvida a ferramenta CATSDL (Coverage Analysis Tool SDL), que permite a anlise de a cobertura de teste para especicaes baseadas em SDL e fornece dicas ao testador que co auxiliam na gerao de casos de teste. A cobertura dos casos de teste avaliada em reca e lao a cinco critrios de teste inicialmente denidos para o teste em n de programas, ca e vel Todos-Blocos, Todas-Decises, Todos-Usos, Todos-P-Usos e Todos-C-Usos, sendo os dois o primeiros critrios de uxo de controle e os trs ultimos critrios de uxo de dados. e e e

Aplicao do Critrio Anlise de Mutantes no Conca e a texto de Programas OO

Atualmente, vrios pesquisadores tm trabalhado na denio de operadores de mua e ca tao para programas OO. Dentre eles destacam-se os trabalhos de Kim et al. [121, 150] ca que denem um conjunto de operadores de mutao de classes que no exploram todas ca a as caracter sticas de um programa OO; de Bieman et al. [151] que denem um conjunto de operadores de mutao espec ca co para o teste de determinadas classes da Java API; e 41

de Ma et al. [122] os quais propuseram um conjunto de operadores de mutao de classe ca para Java que incluem os operadores propostos por Kim et al. [121, 150]. Outros pesquisadores tm tambm explorado o teste de mutaao no contexto de sise e c temas distribu dos que se comunicam via CORBA [152,153]. Ainda, Delamaro et al. [154] deniram um conjunto de operadores de mutao que modelam erros t ca picos cometidos em programas concorrentes em Java. Dada a existncia de um conjunto de operadores de mutao denido para a linguagem e ca C para o teste de unidade e de integrao, Vincenzi [155] identicou, para o teste de ca mtodos, quais dos operadores de unidade da linguagem C poderiam ser aplicados no e contexto de programas C++ e Java. Usando a linguagem de descrio de operadores de mutao MuDeL [156], todos os ca ca 80 operadores de mutao de unidade foram implementados em MuDeL. Em seguida, ca devido `s similaridades das gramticas das linguagens de C, C++ e Java em determinadas a a construes, foram avaliadas tanto a possibilidade de aproveitar a mesma descrio do co ca operador de mutao em MuDeL nas trs linguagens, bem como a concepo do operador ca e ca em si. A Figura 19 sintetiza os resultados obtidos. Considerando que no total so 80 opera adores de mutao, observa-se que 31 (38,75%) operadores so comuns `s trs linguagens ca a a e de programao. A maioria, 34 (42,50%), so comuns `s linguagens C e C++. Alm disso, ca a a e para a linguagem C, outros 15 (18,75%) operadores podem ser aplicados, totalizando os 80 operadores. O mesmo acontece para a linguagem C++. No caso da linguagem Java, alm dos operadores comuns 31 (38,75%) , mais 28 (35,00%) puderam ser instanciados e por caracterizarem erros t pico que podem ocorrer quando se programa em Java. Os demais, por serem de caracter sticas intr nsecas de C e C++, tais como ponteiros, no foram a implementados. Observa-se entretanto que, embora existam operadores espec cos para estruturas sintticas de C e C++ que no existem em Java, como o caso do operador SGLR a a goto Label Replacement , a idia do operador pode ser aproveitada no contexto de Java. e Ou seja, embora Java no tenha comando goto, Java possui comandos tais como break a e continue com rtulos, os quais no existem em C e C++. Assim sendo, esse operador o a que troca rtulos de comandos goto em programas C e C++ pode ser adaptado para o o contexto de Java para trocar os rtulos de comandos break e continue com rtulos. o o Um ponto importante destacado por Binder [157,158] que, em geral, a complexidade e dos mtodos em programas OO no muito grande. A idia desenvolver mtodos simples e a e e e e que, pela interao com outros mtodos da mesma ou de outras classes, implementem a ca e funcionalidade desejada. Nesse sentido, o teste de integrao entre mtodos to ou ca e e a mais importante no teste de programas OO quanto o teste de unidade em programas procedimentais. Assim sendo, o prximo passo a avaliao da adequao dos operadores de Mutao o e ca ca ca de Interface [35] no teste de programas OO. Uma vez que OO apresenta caracter sticas de encapsulamento, herana, polimorsmo e acoplamento dinmico, necessrio invesc a e a tigar como essas caracter sticas impactam a aplicao dos critrios e quais operadores ca e devem ser adaptados/redenidos de modo a permitir a aplicaao do critrio Mutao de c e ca Interfaceno contexto de programas OO, viabilizando o teste de integrao nesse contexto: ca inter-mtodo, intra-classe e inter-classe. Alm disso, a ferramenta de teste JaBUTi deve e e ser estendida para apoiar o teste de mutao em programas OO [155]. ca

42

CGCR OASN OESA OLSN OSAA OSLN SRSR

CLCR OBLN OIPM ORAN OSAN OSRN VASM

OALN OBRN OLAN ORBN OSBA OSSA VDTR

OARN OBSA OLBN ORLN OSBN OSSN VTWD

OASA OBSN OLRN ORSN OSEA SGLR

C++

CGSR SMVB VGSR VLSR

CLSR SSOM VGTR VLTR

CRCR OCOR VGAR VGPR VLAR VLPR VSCR OAAA OBAA OBNG OLNG SBRn SMTT SWDD OAAN OBAN OCNG OMMO SCRB SSDL OABA OBBA OEAA OPPO SCRn SSWM OABN OBBN OEBA ORRN SDWD STRI OAEA OBEA OLLN SBRC SMTC STRP

CGSR SMVB VGSR VLSR

CLSR SSOM VGTR VLTR

CRCR OCOR VGAR VGPR VLAR VLPR VSCR

Java
CGCR OASA OESA OSEA SSOM VLAR CGSR OASN OSAA OSSA VASM VLSR CLCR OBSA OSAN OSSN VDTR VTWD CLSR OBSN OSBA SMVB VGAR CRCR OCOR OSBN SRSR VGSR

Figura 19: Classicao Operadores Linguagem. ca

Concluso a

Neste texto foram apresentados alguns critrios de teste de software e conceitos pere tinentes, com nfase naqueles considerados mais promissores a curto e mdio prazo: os e e critrios baseados em uxo de dados, o critrio Anlise de Mutantes e o critrio Mutao e e a e ca de Interface. Foram tambm apresentadas as ferramentas de teste PokeTool, Proteum e e P ROTEU M, assim como identicadas vrias outras iniciativas e esforos de automatizaM/I a c co desses critrios, dada a relevncia desse aspecto para a qualidade e produtividade da a e a prpria atividade de teste. o Procurou-se ressaltar o aspecto complementar das diversas tcnicas e critrios de teste e e e a relevncia de se conduzir estudos emp a ricos para a formao de um corpo de conhecica mento que favorea o estabelecimento de estratgias de teste incrementais que explorem c e as diversas caracter sticas dos critrios. Nessas estratgias seriam aplicados inicialmente e e critrios mais fracos e talvez menos ecazes para a avaliao da adequao do conjunto e ca ca de casos de teste, e em funo da disponibilidade de oramento e de tempo, incremenca c talmente, poderiam ser utilizados critrios mais fortes e eventualmente mais ecazes, e porm, em geral, mais caros. Estudos emp e ricos so conduzidos no sentindo de avaliar a os aspectos de custo, strength e eccia dos critrios de teste, buscando contribuir para o a e estabelecimento de estratgias de teste ecazes, de baixo custo e para a transformao do e ca estado da prtica, no que tange ao uso de critrios e ferramentas de teste. a e Discutiu-se a denio de critrio de teste para a aplicaao no contexto de especica e c caes baseadas em Redes de Petri, Mquinas de Estado Finito, Statecharts, Estelle e SDL. co a Mecanismos e ferramentas de teste para apoiar a aplicao desse critrio no contexto de esca e pecicaes tm sido desenvolvidas, com por exemplo as ferramentas Proteum-RS/FSM, co e Proteum-RS/ST, Proteum-RS/PN e CATSDL que apiam o teste de especicaes em o co importante observar que o MEFs, Statecharts, Redes de Petri e SDL, respectivamente. E

43

conjunto de casos de teste obtido para testar e validar a especicao pode ser utilizado ca durante o teste de conformidade da implementao em teste. A relao existente entre ca ca esses n veis de abstrao: especicao e implementao esto sendo investigados. ca ca ca a Mostrou-se tambm que os conceitos e mecanismos desenvolvidos originalmente para e o teste de programas procedimentais podem ser utilizados no contexto do paradigma de desenvolvimento de software orientado a objeto, com as devidas adaptaes. Extenses de co o critrios de teste baseados em uxo de controle, uxo de dados e de mutao foram proe ca postas para o teste de programas OO. Alm disso, ferramentas de apoio a esses critrios e e tambm foram desenvolvidas, como por exemplo as ferramentas X Suds e JaBUTi. De e uma maneira geral, pode-se dizer que a atividade de teste tem forte relao com a ativica dade de Qualidade do Software, sendo que testes bem conduzidos procuram aumentar a conabilidade do software. Alm disso, o conjunto de informaes obtidos na atividade e co de teste signicativo para as atividades de depurao, estimativa de conabilidade e de e ca manuteno. ca

Referncias e
[1] M. E. Delamaro and J. C. Maldonado. Uma viso sobre a aplicao da anlise de a ca a mutantes. Technical Report 133, ICMC/USP, So Carlos SP, March 1993. a [2] J. C. Maldonado, A. M. R. Vincenzi, E. F. Barbosa, S. R. S. Souza, and M. E. Delamaro. Aspectos tericos e emp o ricos de teste de cobertura de software. Technical Report 31, Instituto de Cincias Matemticas e de Computao ICMC-USP, June e a ca 1998. [3] R. S. Pressman. Software Engineering A Practitioners Approach. McGraw-Hill, 4 edition, 1997. [4] J. C. Maldonado. Critrios Potenciais Usos: Uma Contribuiao ao Teste Estrutural e c de Software. PhD thesis, DCA/FEE/UNICAMP, Campinas, SP, July 1991. [5] M. C. Paulk. Capability maturity model for software version 1.1. Technical Report 93-TR-24, CMU/SEI, February 1993. [6] T. J. Ostrand and E. J. Weyuker. Using data ow analysis for regression testing. In Sixth Annual Pacic Northwest Software Quality Conference, Portland Oregon, September 1988. [7] J. Hartmann and D. J. Robson. Techniques for selective revalidation. IEEE Software, 7(1):3136, January/February 1990. [8] A. Veevers and A. Marshall. A relationship between software coverage metrics and reliability. Software Testing, Verication and Reliability, 4(1):38, 1994. [9] G. S. Varadan. Trends in reliability and test strategies. IEEE Software, 12(3):10, May 1995. [10] G. J. Myers. The Art of Software Testing. Wiley, New York, 1979.

44

[11] B. Beizer. Software Testing Techniques. Van Nostrand Reinhold Company, New York, 2nd edition, 1990. [12] T. S. Chow. Testing software design modelled by nite-state machines. IEEE Transactions on Software Engineering, 4(3):178187, May 1978. [13] S. Fujiwara, G. V. Bochmann, F. Khendek, M. Amalou, and A. Ghedamsi. Test selection based on nite state models. IEEE Transactions on Software Engineering, 17(6):591603, June 1991. [14] E. V. Berard. Essays on Object-Oriented Software Engineering, volume 1. PrenticeHall Inc, Englewood Clis, New Jersey, 1992. [15] M. J. Harrold, J. D. McGregor, and K. J. Fitzpatrick. Incremental testing of objectoriented class structures. In 14th International Conference on Software Engineering, pages 6880, Los Alamitos, CA, May 1992. IEEE Computer Society Press. [16] D. Homan and P. Strooper. A case study in class testing. In CASCON 93, pages 472482, IBM Toronto Laboratory, October 1993. [17] M. D. Smith and D. J. Robson. A framework for testing object-oriented programs. Journal of Object-Oriented Programming, 5(3):4553, June 1992. [18] P. C. Jorgensen and C. Erickson. Object oriented integration testing. Communications of the ACM, 37(9):3038, September 1994. [19] J. D. McGregor. Functional testing of classes. In Proc. 7th International Quality Week, San Francisco, CA, May 1994. Software Research Institute. [20] G. C. Murphy, P. Townsend, and P. S. Wong. Experiences with cluster and class testing. Communications of the ACM, 37(9):3947, September 1994. [21] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Uma ferramenta para apoiar a validao de mquinas de estado nito pelo critrio de ca a e anlise de mutantes. In Software Tools Proceedings of the 9th Brazilian Symposium a on Software Engineering, pages 475478, Recife PE, Brazil, October 1995. [22] S. C. P F. Fabbri. A Anlise de Mutantes no Contexto de Sistemas Reativos: Uma a Contribuio para o Estabelecimento de Estratgias de Teste e Validaao. PhD ca e c thesis, IFSC-USP, So Carlos SP, October 1996. a [23] W. E. Howden. Software Engineering and Technology: Functional Program Testing and Analysis. McGrall-Hill Book Co, New York, 1987. [24] D. E. Perry and G. E. Kaiser. Adequate testing and object-oriented programming. Journal on Object-Oriented Programming, 2(5):1319, January/February 1990. [25] T. A. Budd. Mutation Analysis: Ideas, Example, Problems and Prospects, chapter Computer Program Testing. North-Holand Publishing Company, 1981. [26] J. B. Goodenough and S. L. Gerhart. Towards a theory of test data selection. IEEE Transactions on Software Engineering, 2(3):156173, September 1975. 45

[27] P. M. Herman. A data ow analysis approach to program testing. Australian Computer Journal, 8(3):9296, November 1976. [28] W. E. Howden. Weak mutation testing and completeness of test sets. IEEE Transactions on Software Engineering, 8(4):371379, July 1982. [29] J. W. Laski and B. Korel. A data ow oriented program testing strategy. IEEE Transactions on Software Engineering, 9(3):347354, May 1983. [30] S. Rapps and E. J. Weyuker. Data ow analysis techniques for program test data selection. In 6th International Conference on Software Engineering, pages 272278, Tokio, Japan, September 1982. [31] S. Rapps and E. J. Weyuker. Selecting software test data using data ow information. IEEE Transactions on Software Engineering, 11(4):367375, April 1985. [32] S. C. Ntafos. On required element testing. IEEE Transactions on Software Engineering, 10(6):795803, November 1984. [33] H. Ural and B. Yang. A structural test selection criterion. Information Processing Letters, 28:157163, 1988. [34] R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):3443, April 1978. [35] M. E. Delamaro. Mutao de Interface: Um Critrio de Adequaao Interca e c procedimental para o Teste de Integraao. PhD thesis, Instituto de F c sica de So a Carlos Universidade de So Paulo, So Carlos, SP, June 1997. a a [36] J. W. Duran and S. C. Ntafos. An evaluation of random testing. IEEE Transactions on Software Engineering, 10(4), July 1984. [37] P. G. Frankl and E. J. Weyuker. A formal analysis of the fault-detecting ability of testing methods. IEEE Transactions on Software Engineering, 19(3):202213, March 1993. [38] P. G. Frankl and E. J. Weyuker. An analytical comparison of the fault-detecting ability of data ow testing techniques. In XV International Conference on Software Engineering, pages 415424, May 1993. [39] M. R. Girgis and M. R. Woodward. An experimental comparison of the error exposing ability of program testing criteria. In Workshop on Software Testing, pages 6471, Ban Canada, July 1986. Computer Science Press. [40] A. P. Mathur. On the relative strengths of data ow and mutation testing. In Ninth Annual Pacic Northwest Software Quality Conference, pages 165181, Portland, OR, October 1991. [41] A. P. Mathur and W. E. Wong. An empirical comparison of data ow and mutation based test adequacy criteria. The Journal of Software Testing, Verication, and Reliability, 4(1):931, March 1994.

46

[42] W. E. Wong. On Mutation and Data Flow. PhD thesis, Department of Computer Science, Purdue University, W. Lafayette, IN, December 1993. [43] S. R. S. Souza. Avaliao do custo e eccia do critrio anlise de mutantes na ca a e a atividade de teste de programas. Masters thesis, ICMC-USP, So Carlos SP, a June 1996. [44] A. M. R. Vincenzi. Subs dios para o estabelecimento de estratgias de teste baseadas e na tcnica de mutao. Masters thesis, ICMC-USP, So Carlos SP, November e ca a 1998. [45] A. P. Mathur and W. E. Wong. Evaluation of the cost of alternative mutation strategies. In VII Simpsio Brasileiro de Engenharia de Software, pages 320335, o Rio de Janeiro, RJ, Brazil, October 1993. [46] A. J. Outt, A. Lee, G. Rothermel, R. H. Untch, and C. Zapf. An experimental determination of sucient mutant operators. ACM Transactions on Software Engineering Methodology, 5(2):99118, April 1996. [47] W. E. Wong, A. P. Mathur, and J. C. Maldonado. Mutation versus all-uses: An empirical evaluation of cost, strength, and eectiveness. In International Conference on Software Quality and Productivity, pages 258265, Hong Kong, December 1994. Chapman and Hall. [48] W. E. Wong, J. C. Maldonado, M. E. Delamaro, and A. P. Mathur. Constrained mutation in C programs. In 8th Brazilian Symposium on Software Engineering, pages 439452, Curitiba, PR, Brazil, October 1994. [49] E. F. Barbosa, J. C. Maldonado, and A. M. R. Vincenzi. Towards the determination of sucient mutant operators for C. In First International Workshop on Automated Program Analysis, Testing and Verication, Limerick, Ireland, June 2000. (Edio ca especial do Software Testing Verication and Reliability Journal, 11(2), 2001). [50] J. C. Maldonado, E. F. Barbosa, A. M. R. Vincenzi, and M. E. Delamaro. Evaluation N-selective mutation for C programs: Unit and integration testing. In Mutation 2000 Symposium, pages 2233, San Jose, CA, October 2000. Kluwer Academic Publishers. [51] A. M. R. Vincenzi, J. C. Maldonado, E. F. Barbosa, and M. E. Delamaro. Unit and integration testing strategies for C programs using mutation-based criteria. In Symposium on Mutation Testing, page 45, San Jose, CA, October 2000. Kluwer Academic Publishers. (Edio especial do Software Testing Verication and Reliability ca Journal 11(4), 2001). [52] R. A. Demillo. Mutation analysis as a tool for software quality assurance. In COMPSAC80, Chicago, IL, October 1980. [53] R. A. DeMillo, D. S. Gwind, K. N. King, W. N. McKraken, and A. J. Outt. An extended overview of the mothra testing environment. In Software Testing, Verication and Analysis, pages 142151, Ban, Canada, July 1988. [54] M. Luts. Testing tools. IEEE Software, 7(3), May 1990. 47

[55] F. G. Frankl and E. J. Weyuker. Data ow testing tools. In Softfair II, pages 4653, San Francisco, CA, December 1985. [56] J. R. Horgan and P. Mathur. Assessing testing tools in research and education. IEEE Software, 9(3):6169, May 1992. [57] J. R. Horgan and S. A. London. Data ow coverage and the C language. In Symposium Software Testing, Analysis, and Verication, pages 8797, Victoria, British Columbia, Canada, October 1991. ACM Press. [58] B. Korel and J. W. Laski. A tool for data ow oriented program testing. In Softfair II, pages 3438, San Francisco, CA, December 1985. [59] T. J. Ostrand and E. J. Weyuker. Data ow based test adequacy for languages with pointers. In Symposium on Software Testing, Analysis and Verication TAV4, pages 7486, Victoria, British Columbia, Canada, October 1991. ACM Press. [60] J. C. Maldonado, M. L. Chaim, and M. Jino. Arquitetura de uma ferramenta de teste de apoio aos critrios potenciais usos. In XXII Congresso Nacional de Informtica, e a So Paulo, SP, September 1989. a [61] M. L. Chaim. Poke-tool uma ferramenta para suporte ao teste estrutural de programas baseado em anlise de uxo de dados. Masters thesis, DCA/FEEC/UNICAMP, a Campinas, SP, April 1991. [62] M. E. Delamaro. Proteum: Um ambiente de teste baseado na anlise de mutantes. a Masters thesis, ICMC/USP, So Carlos SP, October 1993. a [63] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Proteum/FSM uma ferramenta para apoiar a validao de mquinas de estado nito ca a pelo critrio anlise de mutantes. In IX Simpsio Brasileiro de Engenharia de Softe a o ware, pages 475478, Recife, PE, October 1995. [64] P. R. S. Vilela, J. C. Maldonado, and M. Jino. Program graph visualization. Software Practice and Experience, 27(11):12451262, November 1997. [65] M. E. Delamaro, J. C. Maldonado, A. Pasquini, and A. P. Mathur. Interface mutation test adequacy criterion: An empirical evaluation. To be submitted. [66] A. M. R. Vincenzi, M. E. Delamaro, A. S. Simo, W. E. Wong, and J. C. Maldonado. a Jab a Java bytecode analyzer. In XVI SBES Simpsio Brasileiro de Engenharia a o de Software, pages 414419, Gramado, RS, Brasil, October 2002. [67] A. M. R. Vincenzi, W. E. Wong, M. E. Delamaro, and J. C. Maldonado. JaBUTi: A coverage analysis tool for Java programs. In XVII SBES Simpsio Brasileiro o de Engenharia de Software, Manaus, AM, Brasil, October 2003. a ser publicado. [68] R. A Demillo. Software Testing and Evaluation. The Benjamin/Cummings Publishing Company Inc 1987. [69] E. J. Weyuker and T. Ostrand. Theory of program testing and the application of revealing subdomains. IEEE Transactions on Software Engineering, 6, June 1980. 48

[70] U. Linnenkugel and M. Mllerburg. Test data selection criteria for (software) inu tegration testing. In First International Conference on Systems Integration, pages 709717, Morristown, NJ, April 1990. IEEE Computer Society. [71] A. M. Price and A. Zorzo. Visualizando o uxo de controle de programas. In IV Simpsio Brasileiro de Engenharia de Software, Aguas de So Pedro, SP, October o a 1990. [72] R. A. DeMillo and A. J. Outt. Constraint based automatic test data generation. IEEE Transactions on Software Engineering, 17(9):900910, September 1991. [73] E. J. Weyuker, S. N. Weiss, and R. G. Hamlet. Comparison of program testing strategies. In 4th Symposium on Software Testing, Analysis and Verication, pages 154164, Victoria, British Columbia, Canada, 1991. ACM Press. [74] R. A. DeMillo, A. P. Mathur, and W. E. Wong. Some critical remarks on a hierarchy of fault-detecting abilities of test methods. IEEE Transactions on Software Engineering, 21(10):858860, October 1995. [75] M. J. Harrold and G. Rothermel. Performing data ow testing on classes. In Second ACM SIGSOFT Symposium on Foundations of Software Engineering, pages 154 163, New York, NY, December 1994. ACM Press. [76] Y. K. Malaiya, N. Li, J. Bieman, R. Karcick, and B. Skibe. The relationship between test coverage and reliability. In International Symposium on Software Reliability Engineering, pages 186195, Monterey, CA, November 1994. [77] W. E. Wong and A. P. Mathur. Reducing the cost of mutation testing: An empirical study. The Journal of Systems and Software, 31(3):185196, December 1995. [78] W. E. Wong and A. P. Mathur. Fault detection eectiveness of mutation and data ow testing. Software Quality Journal, 4(1):6983, March 1995. [79] E. F. Barbosa, A. M. R. Vincenzi, and J. C. Maldonado. Uma contribuio para ca a determinao de um conjunto essencial de operadores de mutao no teste de ca ca programas C. In XII Simpsio Brasileiro de Engenharia de Software, pages 103 o 120, Maring, PR, October 1998. a [80] H. Agrawal, J. Alberi, J. R. Horgan, J. Li, S. London, W. E. Wong, S. Ghosh, and N. Wilde. Mining system tests to aid software maintenance. IEEE Computer, 31(7):6473, July 1998. [81] IEEE. IEEE standard glossary of software engineering terminology. Standard 610.12, IEEE Computer Society Press, 1990. [82] F. G. Frankl. The Use of Data Flow Information for the Selection and Evaluation of Software Test Data. PhD thesis, Universidade de New York, New York, NY, October 1987. [83] S. C. Ntafos. A comparison of some structural testing strategies. IEEE Transactions on Software Engineering, 14(6):868873, July 1988. 49

[84] M. J. Harrold. Testing: A roadmap. In 22th International Conference on Software Engineering Future of SE Track, pages 6172, June 2000. [85] E. J. Weyuker. The complexity of data ow for test data selection. Information Processing Letters, 19(2):103109, August 1984. [86] E. J. Weyuker and B. Jeng. Analyzing partition testing strategies. IEEE Transactions on Software Engineering, 17(7):703711, July 1991. [87] H. Zhu. A formal analysis of the subsume relation between software test adequacy criteria. IEEE Transactions on Software Engineering, 22(4):248255, April 1996. [88] E. J. Weyuker. The cost of data ow testing: an empirical study. IEEE Transactions on Software Engineering, 16(2):121128, February 1990. [89] M. Jino M. L. Chaim, J. C. Maldonado. Ferramenta para o teste estrutural de software baseado em anlise de uxo de dados: o caso poke-tool. In Workshop a do Projeto de Validao e Teste de Sistemas de Operaao, pages 2939, Aguas de ca c Lindia SP, January 1997. o [90] M. E. Delamaro, J. C. Maldonado, and A. M. R. Vincenzi. Proteum/IM 2.0: An integrated mutation testing environment. In Mutation 2000 Symposium, pages 91 101, San Jose, CA, October 2000. Kluwer Academic Publishers. [91] A. J. Outt and A. Irvine. Testing object-oriented software using the categorypartition method. In 17th International Conference on Technology of ObjectOriented Languages and Systems, pages 293304, Santa Barbara, CA, August 1995. Prentice-Hall. [92] S. Linkman, A. M. R. Vincenzi, and J. Maldonado. An evaluation of systematic functional testing using mutation testing. In 7th International Conference on Empirical Assessment in Software Engineering EASE, Keele, UK, April 2003. The IEE. [93] W. E. Howden. Functional Program Testing and Analysis. McGrall-Hill, New York, 1987. [94] M. R. Woodward, D. Heddley, and M. A. Hennel. Experience with path analysis and testing of programs. IEEE Transactions on Software Engineering, 6:278286, May 1980. [95] W. E. Howden. Methodology for the generation of program test data. IEEE Computer, C-24(5):554559, May 1975. [96] S. R. Verg lio, J. C. Maldonado, and M. Jino. Uma estratgia para a gerao de e ca dados de teste. In VII Simpsio Brasileiro de Engenharia de Software, pages 307 o 319, Rio de Janeiro, RJ, October 1993. [97] C. Ghezzi and M. Jazayeri. Programming Languages Concepts. John Wiley and Sons, New York, 2 edition, 1987.

50

[98] A. Haley and S. Zweben. Development and application of a white box approach to integration testing. The Journal of Systems and Software, 4:309315, 1984. [99] M. J. Harrold and M. L. Soa. Selecting and using data for integration test. IEEE Software, 8(2):5865, March 1991. [100] Z. Jin and A. J. Out. Integration testing based on software couplings. In X Annual Conference on Computer Assurance (COMPASS 95), pages 1323, Gaithersburg, Maryland, January 1995. [101] P. R. S. Vilela. Critrios Potenciais Usos de Integraao: Deniao e Anlise. PhD e c c a thesis, DCA/FEEC/UNICAMP, Campinas, SP, April 1998. [102] P. G. Frankl and E. J. Weyuker. An applicable family of data ow testing criteria. IEEE Transactions on Software Engineering, 14(10):14831498, October 1988. [103] M. J. Harrold and M. L. Soa. Interprocedural data ow testing. In 3rd Testing, Analysis, and Verication Symposium, pages 158167, Key West, Florida, December 1989. ACM Press. [104] A. M. R. Vincenzi, M. E. Delamaro, J. C. Maldonado, and W. E. Wong. Java bytecode static analysis: Deriving structural testing requirements. In 2nd UK Software Testing Workshop UK-Softest2003, Department of Computer Science, University of York, York, England, September 2003. University of York Press. [105] A. M. R. Vincenzi, J. C. Maldonado, M. E. Delamaro, E. S. Spoto, and W. E. Wong. Component-Based Software Quality: Methods and Techniques, volume 2693 of Lecture Notes in Computer Science, chapter Component-Based Software: An Overview of Testing, pages 99127. Springer-Verlag, New York, NY, June 2003. (A. Cechich and M. Piattini and A. Vallecillo ed.). [106] P. S. J. Leito. Suporte ao teste estrutural de programas cobol no ambiente pokea tool. Masters thesis, DCA/FEE/UNICAMP, Campinas, SP, August 1992. [107] R. P. Fonseca. Suporte ao teste estrutural de programas fortran no ambiente poketool. Masters thesis, DCA/FEE/UNICAMP, Campinas, SP, January 1993. [108] T. Chusho. Test data selection and quality estimation based on concept of essential branches for path testing. IEEE Transactions on Software Engineering, 13(5):509 517, 1987. [109] S. R. Vergilio. Critrios Restritos: Uma Contribuiao para Aprimorar a Eccia da e c a Atividade de Teste de Software. PhD thesis, DCA/FEEC/UNICAMP, Campinas, SP, July 1997. [110] A. D. Friedman. Logical Design of Digital Systems. Computer Science Press, 1975. [111] M. E. Delamaro and J. C. Maldonado. Proteum a tool for the assessment of test adequacy for C programs. In Conference on Performability in Computing Systems (PCS96), pages 7995, East Brunswick, NJ, July 1996.

51

[112] H. Agrawal, R. A. DeMillo, R. Hathaway, W. Hsu, W. Hsu, E. W. Krauser, R. J. Martin, A. P. Mathur, and E. H. Spaord. Design of mutant operators for the C programming language. Technical Report SERC-TR41-P, Software Engineering Research Center, Purdue University, West Lafayette, IN, March 1989. [113] A. T. Acree, T. A. Budd, R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Mutation analysis. Technical Report GIT-ICS-79/08, Georgia Institute of Technology, Atlanta, GA, September 1979. [114] T. A. Budd. Mutation Analysis of Program Test Data. PhD thesis, Yale University, New Haven, CT, 1980. [115] B. J. Choi, A. P. Mathur, and A. P. Pattison. pmothra: Scheduling mutants for execution on a hypercube. In 3rd Symposium on Software Testing, Analysis and Verication, pages 5865, Key West, FL, December 1989. [116] E. W. Krauser, A. P. Mathur, and V. J. Rego. High performance software testing on simd machines. IEEE Transactions on Software Engineering, 17(5):403422, May 1991. [117] A. P. Mathur and E. W. Krauser. Modeling mutation on vector processor. In X International Conference on Software Engineering, pages 154161, Singapore, April 1988. [118] B. J. Choi and A. P. Mathur. High-performance mutation testing. The Journal of Systems and Software, 1(20):135152, February 1993. [119] A. C. Marshall, D. Hedley, I. J. Riddell, and M. A. Hennell. Static dataow-aided weak mutation analysis (sdawm). Information and Software Technology, 32(1), January/February 1990. [120] M. E. Delamaro, J. C. Maldonado, and A. P. Mathur. Interface mutation: An approach for integration testing. IEEE Transactions on Software Engineering, 27(3):228247, March 2001. [121] S. Kim, J. A. Clark, and J. A. Mcdermid. Class mutation: Mutation testing for object-oriented programs. In FMES, 2000. http://www-users.cs.york.ac.uk/ ~jac/ [15-04-2001]. [122] Y.-S. Ma, Y.-R. Kwon, and J. Outt. Inter-class mutation operators for Java. In 13th International Symposium on Software Reliability Engineering - ISSRE2002, pages 352366, Annapolis, MD, November 2002. IEEE Computer Society Press. [123] S. C. P. F. Fabbri, J. C. Maldonado, P. C. Masiero, and M. E. Delamaro. Anlise de a mutantes baseada em mquinas de estado nito. In XI SBRC Simpsio Brasileiro a o de Redes de Computadores, pages 407425, Campinas, SP, May 1993. [124] S. C. P. F. Fabbri, J. C. Maldonado, P. C. Masiero, and M. E. Delamaro. Mutation analysis testing for nite state machines. In 5th International Symposium on Software Reliability Engineering (ISSRE94), pages 220229, Monterey CA, November 1994. IEEE Computer Society Press. 52

[125] S. C. P. F. Fabbri, J. C. Maldonado, P. C. Masiero, and M. E. Delamaro. Mutation analysis applied to validate specications based on petri nets. In FORTE95 8th IFIP Conference on Formal Descriptions Techniques for Distribute Systems and Communication Protocols, pages 329337, Montreal, Canada, October 1995. Kluwer Academic Publishers. [126] A. S. Simo. Proteum-RS/PN: Uma ferramenta para a validao de redes de petri a ca baseada na anlise de mutantes. Masters thesis, ICMC/USP, So Carlos, SP, Februa a ary 2000. [127] T. Sugeta. Proteum-rs/st : Uma ferramenta para apoiar a validao de especica caes statecharts baseada na anlise de mutantes. Masters thesis, ICMC-USP, So co a a Carlos, SP, November 1999. [128] M. R. Woodward. Mutation testing its origin and evolution. Information and Software Technology, 35(3):163169, March 1993. [129] S. P. F. Fabbri and J. C. Maldonado. Proteum/FSM: Uma ferramenta de teste baseada na anlise de mutantes para apoiar a validao de especicaes em a ca co mquinas de estado nito. Revista da Asser, November 1996. a [130] A. M. R. Vincenzi, E. F. Barbosa, Vincenzi S. R. S. Souza, M. E. Delamaro, and J. C. Maldonado. Critrio anlise de mutantes: Estado atual e perspectivas. In e a Workshop do Projeto de Validaao e Teste de Sistemas de Operaao, pages 1526, c c Aguas de Lindia SP, January 1997. o [131] A. T. Acree. On Mutation. PhD thesis, Georgia Institute of Technology, Atlanta, GA, 1980. [132] M.E. Delamaro and J.C. Maldonado. Interface mutation: Assessing testing quality at interprocedural level. In 19th International Conference of the Chilean Computer Science Society (SCCC99), pages 7886, Talca Chile, November 1999. [133] E. Y. Nakagawa and et al. Aspectos de projeto e implementao de interfaces ca grcas do usurio para ferramentas de teste. In Workshop do Projeto de Validao a a ca e Teste de Sistemas de Operaao, pages 5767, Aguas de Lindia SP, January c o 1997. [134] S. R. Verg lio, J. C. Maldonado, and M. Jino. Caminhos no-executveis na aua a tomao das atividades de teste. In VI Simpsio Brasileiro de Engenharia de Softca o ware, pages 343356, Gramado, RS, November 1992. [135] A. J. Outt, J. Pan, K. Tewary, and T. Zhang. An experimental evaluation of data ow and mutation testing. Software Practice and Experience, 26(2):165176, February 1996. [136] W.E. Wong, J.C. Maldonado, M.E. Delamaro, and S.R.S. Souza. A comparison of selective mutation in C and fortran. In Workshop do Projeto Validaao e Teste de c Sistemas de Operao, pages 7180, Aguas de Lindia, SP, January 1997. ca o

53

[137] M. E. Delamaro, J. C. Maldonado, and A. P. Mathur. Proteum a tool for the assessment of test adequacy for C programs users guide. Technical Report SERCTR168-P, Software Engineering Research Center, Purdue University, April 1996. [138] H. Ural. Test sequence selection based on static data ow analysis. Computer Communications, 10(5):234242, October 1987. [139] R. L. Probert and F. Guo. Mutation testing of protocols: Principles and preliminary experimental results. In IFIP TC6 Third International Workshop on Protocol Test Systems, pages 5776. North-Holland, 1991. [140] S. R. S. Souza, J. C. Maldonado, S. C. P. Fabbri, and P. C. Masiero. Statecharts specications: A family of coverage testing criteria. In XXVI Conferncia Latie noamericana de Informtica CLEI2000, Tecnologico de Monterrey Mxico, a e September 2000. (CD-ROM Arquivo PDF cdigo a000185). o [141] J. L. Peterson. Petri nets. ACM Computing Surveys, 9(3):223252, September 1977. [142] A. Gill. Introduction to the Theory of Finite State Machines. McGraw-Hill, New York, 1962. [143] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231274, June 1987. [144] A. M. Davis. A comparison of techniques for the specication of external system behavior. Communications of the ACM, 31(9), September 1988. [145] S. Budkowski and P. Dembinski. An introduction to Estelle: a specication language for distributed systems. Computer Network and ISDN Systems, 14(1):323, 1987. [146] S. R. S. Souza, J. C. Maldonado, S. C. P. F. Fabbri, and W. Lopes de Souza. Mutation testing applied to estelle specications. Software Quality Journal, 8(4):285301, December 1999. [147] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Proteum/FSM: A tool to support nite state machine validation based on mutation testing. In XIX SCCC International Conference of the Chilean Computer Science Society, pages 96104, Talca, Chile, 1999. [148] S. C. P. F. Fabbri, J. C. Maldonado, T. Sugeta, and P. C. Masiero. Mutation testing applied to validate specications based on statecharts. In ISSRE International Symposium on Software Reliability Systems, pages 210219, November 1999. [149] W. E. Wong, T. Sugeta, J. J. Li, and J. C. Maldonado. Coverage testing software architectural design in sdl. Journal of Computer Networks, 42(3):359374, June 2003. [150] S. Kim, J. A. Clark, and J. A. Mcdermid. Investigating the eectiveness of objectoriented testing strategies with the mutation method. Software Testing, Verication and Reliability, 11(4), December 2001.

54

[151] J. M. Bieman, S. Ghosh, and R. T. Alexander. A technique for mutation of Java objects. In 16th IEEE Internation Conference on Automated Software Engineering, pages 2326, San Diego, CA, November 2001. [152] S. Ghosh and A. P. Mathur. Interface mutation. Software Testing, Verication and Reliability, 11(4):227247, December 2001. (Special Issue: Mutation 2000 - A Symposium on Mutation Testing. Issue Edited by W. Eric Wong). [153] B. Sridhanan, S. Mundkur, and A. P. Mathur. Non-intrusive testing, monitoring and control of distributed corba objects. In TOOLS33 33rd International Conference on Technology of Object-Oriented Languages, pages 195206, Mont-saint-Michel, France, June 2000. [154] M. E. Delamaro, M. Pezz`, A. M. R. Vincenzi, and J. C. Maldonado. Mutant e operators for testing concurrent Java programs. In Brazilian Symposium on Software Engineering2001, pages 272285, Rio de Janeiro, RJ, Brazil, October 2001. [155] A. M. R. Vincenzi. Orientaao a Objetos: Deniao e Anlise de Recursos de c c a Teste e Validao. Exame geral de qualicao, Instituto de Cincias Matemticas ca ca e a e de Computao ICMC/USP, So Carlos, SP, October 2000. (Doutorado em ca a andamento). [156] A. S. Simo and J. C. Maldonado. MuDeL: A language and a system for describing a and generating mutants. In XV SBES Simpsio Brasileiro de Engenharia de o Software, pages 240255, Rio de Janeiro, Brasil, October 2001. [157] R. V. Binder. The free approach to testing object-oriented software: An overview. Pgina WWW, 1996. Available on-line at: http://www.rbsc.com/pages/FREE. a html [01-20-2003]. [158] R. V. Binder. Testing Object-Oriented Systems: Models, Patterns, and Tools, volume 1. Addison Wesley Longman, Inc., 1999.

55