Escolar Documentos
Profissional Documentos
Cultura Documentos
apostilaUSP PDF
apostilaUSP PDF
Resumo
Neste texto so apresentados alguns critrios de teste de software, conceitos pertinentes
e ferramentas de apoio. So abordados critrios de teste funcional, estrutural baseados
em fluxo de controle e em fluxo de dados e baseados em mutao. nfase dada no
teste de mutao. Apesar de sua eficcia em revelar a presena de erros, o teste de mu-
tao apresenta problemas de custo relacionados ao grande nmero de mutantes gerados
e determinao de mutantes equivalentes, mesmo para pequenos programas. Visando a
reduzir os custos de aplicao do teste de mutao diversos estudos tericos e empricos
vm sendo realizados. Uma sntese dos principais estudos empricos relacionados ao tes-
te de mutao apresentada. Esses estudos procuram estabelecer uma estratgia de teste
que viabilize a utilizao do teste de mutao no teste de produtos comerciais de software.
Ilustram-se a atividade de teste e os problemas pertinentes utilizando-se as ferramentas
PokeTool, Proteum e PROTEUM=IM, que apiam, respectivamente, critrios estruturais, o
critrio Anlise de Mutantes e o critrio Mutao de Interface. Identificam-se ainda outras
iniciativas e esforos da comunidade para a automatizao desses critrios.
1
1 Introduo
A Engenharia de Software evoluiu significativamente nas ltimas dcadas procurando estabe-
lecer tcnicas, critrios, mtodos e ferramentas para a produo de software, em conseqncia
da crescente utilizao de sistemas baseados em computao em praticamente todas as reas
da atividade humana, o que provoca uma crescente demanda por qualidade e produtividade,
tanto do ponto de vista do processo de produo como do ponto de vista dos produtos gerados.
A Engenharia de Software pode ser definida como uma disciplina que aplica os princpios de
engenharia com o objetivo de produzir software de alta qualidade a baixo custo [3]. Atravs
de um conjunto de etapas que envolvem o desenvolvimento e aplicao de mtodos, tcnicas e
ferramentas, a Engenharia de Software oferece meios para que tais objetivos possam ser alcan-
ados.
O processo de desenvolvimento de software envolve uma srie de atividades nas quais, ape-
sar das tcnicas, mtodos e ferramentas empregados, erros no produto ainda podem ocorrer.
Atividades agregadas sob o nome de Garantia de Qualidade de Software tm sido introduzidas
ao longo de todo o processo de desenvolvimento, entre elas atividades de VV&T Verifica-
o, Validao e Teste, com o objetivo de minimizar a ocorrncia de erros e riscos associados.
Dentre as tcnicas de verificao e validao, a atividade de teste uma das mais utilizadas,
constituindo-se em um dos elementos para fornecer evidncias da confiabilidade do software
em complemento a outras atividades, como por exemplo o uso de revises e de tcnicas formais
e rigorosas de especificao e de verificao [4].
A atividade de teste consiste de uma anlise dinmica do produto e uma atividade relevante
para a identificao e eliminao de erros que persistem. Do ponto de vista de qualidade do
processo, o teste sistemtico uma atividade fundamental para a ascenso ao Nvel 3 do Modelo
CMM do Software Engineering Institute SEI [5]. Ainda, o conjunto de informao oriundo
da atividade de teste significativo para as atividades de depurao, manuteno e estimativa de
confiabilidade de software [3,69]. Salienta-se que 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]. Essas ati-
vidades devem ser desenvolvidas ao longo do prprio processo de desenvolvimento de software,
e em geral, concretizam-se em trs fases de teste: de unidade, de integrao e de sistema. O
teste de unidade concentra esforos na menor unidade do projeto de software, ou seja, procura
identificar erros de lgica e de implementao em cada mdulo do software, separadamente.
O teste de integrao uma atividade sistemtica aplicada durante a integrao da estrutura
do programa visando a descobrir erros associados s interfaces entre os mdulos; o objetivo ,
a partir dos mdulos testados no nvel de unidade, construir a estrutura de programa que foi
determinada pelo projeto. O teste de sistema, realizado aps a integrao do sistema, visa a
identificar erros de funes e caractersticas de desempenho que no estejam de acordo com a
especificao [3].
Um ponto crucial na atividade de teste, independentemente da fase, o projeto e/ou a avali-
2
ao da qualidade de um determinado conjunto de casos de teste T utilizado para o teste de um
produto P , dado que, em geral, impraticvel utilizar todo o domnio 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 a maioria dos defeitos com um
mnimo de tempo e esforo, por questes de produtividade. Segundo Myers [10], o principal
objetivo do teste de software revelar a presena de erros no produto. Portanto, o teste bem
sucedido aquele que consegue determinar casos de teste para os quais o programa em teste
falhe. Tem-se observado que a prpria atividade de projeto de casos de teste bastante efetiva
em evidenciar a presena de defeitos de software.
Em geral, os critrios de teste de software so estabelecidos, basicamente, a partir de trs
tcnicas: a funcional, a estrutural e a baseada em erros. Na tcnica funcional, os critrios e
requisitos de teste so estabelecidos a partir da funo de especificao do software; na tcnica
estrutural, os critrios e requisitos so derivados essencialmente a partir das caractersticas de
uma particular implementao em teste; e, na tcnica baseada em erros, os critrios e requisitos
de teste so oriundos do conhecimento sobre erros tpicos cometidos no processo de desenvolvi-
mento de software. Observa-se tambm o estabelecimento de critrios de gerao de seqncias
de teste baseados em Mquinas de Estados Finito [12, 13]. Esses ltimos tm sido aplicados no
contexto de validao e teste de sistemas reativos e de sistemas orientados a objetos [1422].
Segundo Howden [23], o teste pode ser classificado de duas maneiras: teste baseado em
especificao (specification-based testing) e teste baseado em programa (program-based tes-
ting). De acordo com tal classificao, tm-se que os critrios da tcnica funcional so baseados
em especificao e tanto os critrios estruturais quanto baseados em erros so considerados cri-
trios baseados em implementao.
No teste baseado em especificao (ou teste caixa-preta) o objetivo determinar se o pro-
grama satisfaz aos requisitos funcionais e no-funcionais que foram especificados. O problema
que, em geral, a especificao existente informal e, desse modo, a determinao da cober-
tura total da especificao que foi obtida por um dado conjunto de casos de teste tambm
informal [24]. Entretanto, os critrios de teste baseados em especificao podem ser utiliza-
dos em qualquer contexto (procedimental ou orientado a objetos) e em qualquer fase de teste
sem a necessidade de modificao. Exemplos desses critrios so: particionamento em classe
de equivalncia [3], anlise do valor limite [3], grafo de causa-efeito [3] e teste baseado em
estado [16, 19].
Ao contrrio do teste baseado em especificao, o teste baseado em programa (ou teste
caixa-branca) requer a inspeo do cdigo fonte e a seleo de casos de teste que exercitem
partes do cdigo e no de sua especificao [24].
importante ressaltar que as tcnicas de teste devem ser vistas como complementares e a
questo est em como utiliz-las de forma que as vantagens de cada uma sejam melhor explo-
radas em uma estratgia de teste que leve a uma atividade de teste de boa qualidade, ou seja,
eficaz e de baixo custo. As tcnicas e critrios de teste fornecem ao desenvolvedor uma aborda-
gem sistemtica e teoricamente fundamentada, alm de constiturem um mecanismo que pode
auxiliar a avaliar a qualidade e a adequao da atividade de teste. Critrios de teste podem ser
utilizados tanto para auxiliar na gerao de conjunto de casos de teste como para auxiliar na
avaliao da adequao desses conjuntos.
3
Dada a diversidade de critrios que tm sido estabelecidos [3,4,10,11,2535] e reconhecido
o carter complementar das tcnicas e critrios de teste [3544], um ponto crucial que se coloca
nessa perspectiva a escolha e/ou a determinao de uma estratgia de teste, que em ltima an-
lise passa pela escolha de critrios de teste, de forma que as vantagens de cada um desses crit-
rios sejam combinadas objetivando uma atividade de teste de maior qualidade. Estudos tericos
e empricos de critrios de teste so de extrema relevncia para a formao desse conhecimen-
to, fornecendo subsdios para o estabelecimento de estratgias de baixo custo e alta eficcia.
Identificam-se diversos esforos da comunidade cientfica nessa direo [35, 4143, 4551].
Fundamental se faz o desenvolvimento de ferramentas de teste para o suporte atividade
de teste propriamente dita, uma vez que essa atividade muito propensa a erros, alm de im-
produtiva, se aplicada manualmente, bem como para dar apoio a estudos empricos que visem
a avaliar e a comparar os diversos critrios de teste. Assim, a disponibilidade de ferramentas
de teste propicia maior qualidade e produtividade para as atividades de teste. Observam-se na
literatura esforos da comunidade cientfica nessa direo [11, 35, 43, 5265].
Pode-se observar que os critrios baseados em anlise de fluxo de dados [27, 2933] e o
critrio Anlise de Mutantes (Mutation Analysis) [25, 34, 66] tm sido fortemente investigados
por diversos pesquisadores em diferentes aspectos [7, 37, 38, 41, 42, 44, 46, 50, 57, 59, 6777].
Resultados desses estudos fornecem evidncias de que esses critrios, hoje investigados funda-
mentalmente no meio acadmico, s vezes em cooperao com a indstria, podem, em mdio
prazo, constituir o estado da prtica em ambientes de produo de software. Uma forte evidn-
cia nessa direo o esforo alocado pela Telcordia Technologies (USA) no desenvolvimento
da xSuds [78], um ambiente que apia a aplicao de critrios baseados em anlise de fluxo de
controle e de dados em programas C e C++.
De uma maneira geral, pode-se classificar as contribuies para a rea de Teste de Soft-
ware em: Estudos Tericos, Estudos Empricos e Desenvolvimento de Ferramentas. Este texto
aborda esses trs aspectos, dando-se nfase a estudos tericos e empricos de critrios baseados
em anlise de fluxo de dados e do critrio Anlise de Mutantes para o teste de programas em
nvel de unidade, assim como as ferramentas que apiam a aplicao desses critrios. Com esse
objetivo em mente, o texto est organizado da seguinte forma: na Seo 2 so introduzidos a ter-
minologia e os conceitos bsicos pertinentes atividade de teste. Na Seo 3 so apresentados
os critrios de teste mais difundidos das tcnicas funcional, estrutural e baseada em erros e ilus-
trados os principais aspectos operacionais das ferramentas PokeTool, Proteum e PROTEUM=IM
que apiam a aplicao de critrios estruturais e dos critrios Anlise de Mutantese Mutao
de Interface, respectivamente. Na Seo 4 so identificados os principais esforos e iniciativas
de automatizao e na Seo 5 so sintetizados os principais resultados de estudos empricos
envolvendo os critrios apresentados neste texto. Na Seo 6 so apresentadas as concluses e
perspectivas de trabalhos futuros.
4
diferencia os termos: defeito (fault) passo, processo ou definio de dados incorreto, como
por exemplo, uma instruo ou comando incorreto; engano (mistake) ao humana que pro-
duz um resultado incorreto, com por exemplo, uma ao incorreta tomada pelo programador;
erro (error) diferena entre o valor obtido e o valor esperado, ou seja, qualquer estado inter-
medirio incorreto ou resultado inesperado na execuo do programa constitui um erro; e falha
(failure) produo de uma sada incorreta com relao especificao. Neste texto, os termos
engano, defeito e erro sero referenciados como erro (causa) e o termo falha (conseqncia) a
um comportamento incorreto do programa. De uma forma geral, os erros so classificados em:
erros computacionais o erro provoca uma computao incorreta mas o caminho executado
(seqncias de comandos) igual ao caminho esperado; e erros de domnio o caminho efeti-
vamente executado diferente do caminho esperado, ou seja, um caminho errado selecionado.
A atividade de teste permeada por uma srie de limitaes [23, 31, 8082]. Em geral, os
seguintes problemas so indecidveis: dados dois programas, se eles so equivalentes; dados
duas seqncias de comandos (caminhos) de um programa, ou de programas diferentes, se
eles computam a mesma funo; e dado um caminho se ele executvel ou no, ou seja, se
existe um conjunto de dados de entrada que levam execuo desse caminho. Outra limitao
fundamental a correo coincidente o programa pode apresentar, coincidentemente, um
resultado correto para um item particular de um dado d 2 D , ou seja, um particular item de
dado ser executado, satisfazer a um requisito de teste e no revelar a presena de um erro.
Diz-se que um programa P com domnio de entrada D correto com respeito a uma es-
pecificao S se S (d) = P (d) para qualquer item de dado d pertencente a D , ou seja, se o
comportamento do programa est de acordo com o comportamento esperado para todos os da-
dos de entrada. Dados dois programas P1 e P2 , se P1 (d) = P2 (d), para qualquer d 2 D , diz-se
que P1 e P2 so equivalentes. No teste de software, pressupe-se a existncia de um orculo
o testador ou algum outro mecanismo que possa determinar, para qualquer item de dado
d 2 D , se S (d) = P (d), dentro de limites de tempo e esforos razoveis. Um orculo decide
simplesmente se os valores de sada so corretos. Sabe-se que o teste exaustivo impratic-
vel, ou seja, testar para todos os elementos possveis do domnio de entrada , em geral, caro
e demanda muito mais tempo do que o disponvel. Ainda, deve-se salientar que no existe um
procedimento de teste de propsito geral que possa ser usado para provar a corretitude de um
programa. Apesar de no ser possvel, atravs de testes, provar que um programa est correto,
os testes, se conduzidos sistemtica e criteriosamente, contribuem para aumentar a confiana
de que o software desempenha as funes especificadas e evidenciar algumas caractersticas
mnimas do ponto de vista da qualidade do produto.
Assim, duas questes so chaves na atividade de teste: Como os dados de teste devem ser
selecionados? e Como decidir se um programa P foi suficientemente testado?. Critrios para
selecionar e avaliar conjuntos de casos de teste so fundamentais para o sucesso da atividade de
teste. Tais critrios devem fornecer indicao de quais casos de teste devem ser utilizados de
forma a aumentar as chances de revelar erros ou, quando erros no forem revelados, estabelecer
um nvel elevado de confiana na correo do programa. Um caso de teste consiste de um par
ordenado (d; S (d)), no qual d 2 D e S (d) a respectiva sada esperada.
Dados um programa P e um conjunto de casos de teste T , definem-se:
5
Critrio de Adequao de Casos de Teste: predicado para avaliar T no teste de P ;
Mtodo de Seleo de Casos de Teste: procedimento para escolher casos de teste para o
teste de P .
Existe uma forte correspondncia entre mtodos de seleo e critrios de adequao de ca-
sos de teste pois, dado um critrio de adequao C , existe um mtodo de seleo M C que
estabelece: selecione T tal que T seja adequado a C . De forma anloga, dado um mtodo de
seleo M , existe um critrio de adequao C M que estabelece: T adequado se foi seleciona-
do 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 designar mtodo de seleo [4, 55].
Dados P , T e um critrio C , diz-se que o conjunto de casos de teste T C -adequado para o
teste de P se T preencher os requisitos de teste estabelecidos pelo critrio C . Outra questo
relevante nesse contexto dado um conjunto T C 1 -adequado, qual seria um critrio de teste C2
que contribuiria para aprimorar T ? Essa questo tem sido investigada tanto em estudos tericos
quanto em estudos empricos.
Em geral, pode-se dizer que as propriedades mnimas que devem ser preenchidas por um
critrio de teste C so:
2. requerer, do ponto de vista de fluxo de dados, ao menos um uso de todo resultado com-
putacional; e
por um critrio, no pior caso. No caso dos critrios baseados em fluxo de dados, esses tm
complexidade exponencial, o que motiva a conduo de estudos empricos para determinar o
custo de aplicao desses critrios do ponto de vista prtico. Mais recentemente, alguns autores
tm abordado do ponto de vista terico a questo de eficcia de critrios de teste, e tm definido
outras relaes, que captem a capacidade de revelar erros dos critrios de teste [37, 38, 84, 85].
Do ponto de vista de estudos empricos, trs aspectos costumam ser avaliados: custo, efic-
cia e strength (ou dificuldade de satisfao) [40,41,46,71,76,86]. O fator custo reflete o esforo
necessrio para que o critrio seja utilizado; em geral medido pelo nmero de casos de teste
necessrios para satisfazer o critrio. A eficcia refere-se capacidade que um critrio possui
6
de detectar a presena de erros. O fator strength refere-se probabilidade de satisfazer-se um
critrio tendo sido satisfeito um outro critrio [41].
Uma atividade muito citada na conduo e avaliao da atividade de teste a anlise de co-
bertura, 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 utilizado. A partir
dessa informao o conjunto de casos de teste pode ser aprimorado, acrescentando-se novos
casos de teste para exercitar os elementos ainda no cobertos. Nessa perspectiva, fundamental
o conhecimento sobre as limitaes tericas inerentes atividade de teste, pois os elementos re-
queridos podem ser no executveis, e em geral, determinar a no executabilidade de um dado
requisito de teste envolve a participao do testador.
7
/****************************************************************************************
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 ()
int valid_s(char ch)
/* 1 */ {
/* 1 */ {
/* 1 */ char achar;
/* 1 */ if(((ch >= A) &&
/* 1 */ int length, valid_id;
(ch <= Z)) ||
/* 1 */ length = 0;
((ch >= a) &&
/* 1 */ valid_id = 1;
(ch <= z)))
/* 1 */ printf ("Identificador: ");
/* 2 */ {
/* 1 */ achar = fgetc (stdin);
/* 2 */ return (1);
/* 1 */ valid_id = valid_s(achar);
/* 2 */ }
/* 1 */ if(valid_id)
/* 3 */ else
/* 2 */ {
/* 3 */ {
/* 2 */ length = 1;
/* 3 */ return (0);
/* 2 */ }
/* 3 */ }
/* 3 */ achar = fgetc (stdin);
/* 4 */ }
/* 4 */ while(achar != \n)
/* 5 */ {
int valid_f(char ch)
/* 5 */ if(!(valid_f(achar)))
/* 1 */ {
/* 6 */ {
/* 1 */ if(((ch >= A) &&
/* 6 */ valid_id = 0;
(ch <= Z)) ||
/* 6 */ }
((ch >= a) &&
/* 7 */ length++;
(ch <= z)) ||
/* 7 */ achar = fgetc (stdin);
((ch >= 0) &&
/* 7 */ }
(ch <= 9)))
/* 8 */ if(valid_id &&
/* 2 */ {
(length >= 1) && (length < 6))
/* 2 */ return (1);
/* 9 */ {
/* 2 */ }
/* 9 */ printf ("Valido\n");
/* 3 */ else
/* 9 */ }
/* 3 */ {
/* 10 */ else
/* 3 */ return (0);
/* 10 */ {
/* 3 */ }
/* 10 */ printf ("Invalid\n");
/* 4 */ }
/* 10 */ }
/* 11 */ }
8
possvel de casos de teste, baseando-se na hiptese que um elemento 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 particionamento permite examinar os re-
quisitos mais sistematicamente e restringir o nmero de casos de teste existentes. Alguns
autores tambm consideram o domnio de sada do programa para estabelecer as classes
de equivalncia.
Anlise do Valor Limite: um complemento ao critrio Particionamento em Classes de
Equivalncia, sendo que os limites associados s condies de entrada so exercitados
de forma mais rigorosa; ao invs de selecionar-se qualquer elemento de uma classe, os
casos de teste so escolhidos nas fronteiras das classes, pois nesses pontos se concentra
um grande nmero de erros. O espao de sada do programa tambm particionado e so
exigidos casos de teste que produzam resultados nos limites dessas classes de sada.
Grafo de Causa-Efeito: os critrios anteriores no exploram combinaes das condies
de entrada. Este critrio estabelece requisitos de teste baseados nas possveis combina-
es das condies de entrada. Primeiramente, so levantadas as possveis condies de
entrada (causas) e as possveis aes (efeitos) do programa. A seguir construdo um
grafo relacionando as causas e efeitos levantados. Esse grafo convertido em uma tabela
de deciso a partir da qual so derivados os casos de teste.
Um dos problemas relacionado aos critrios funcionais que muitas vezes a especificao
do programa feita de modo descritivo e no formal. Dessa maneira, os requisitos de teste
derivados de tais especificaes so tambm, de certa forma, imprecisos e informais. Como
conseqncia, tem-se dificuldade em automatizar a aplicao de tais critrios, que ficam, em
geral, restritos aplicao manual. Por outro lado, para a aplicao desses critrios essencial
apenas que se identifiquem as entradas, a funo a ser computada e a sada do programa, o que
os tornam aplicveis praticamente em todas fases de teste (unidade, integrao e sistema) [35].
A ttulo de ilustrao, considerando o programa identifier e o critrio Particionamento em
Classes de Equivalncia, so identificadas na Tabela 1 as condies de entrada e classes de equi-
valncia vlidas e invlidas. A partir dessas classes o seguinte conjunto de casos de teste poderia
ser elaborado: T0 = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)}. De
posse do conjunto T0 , seria natural indagar se esse conjunto exercita todos os comandos ou to-
dos os desvios de fluxo de controle de uma dada implementao. Usualmente, lana-se mo de
critrios estruturais de teste, apresentados a seguir, como critrios de adequao ou critrios de
cobertura para se analisar questes como essas, propiciando a quantificao e a qualificao da
atividade de teste de acordo com o critrio escolhido. Quanto mais rigoroso o critrio utilizado
e se erros no forem revelados, maior a confiana no produto em desenvolvimento.
9
Tabela 1: Classes de Equivalncia para o programa identifier.
Restries de Entrada Classes Vlidas Classes Invlidas
Tamanho (t) do identificador 1t6 t>6
(1) (2)
Primeiro caracter (c) uma letra Sim No
(3) (4)
Contm somente caracteres vlidos Sim No
(5) (6)
software [MAL91]. Independentemente dessas desvantagens, essa tcnica vista como com-
plementar tcnica funcional [3] e informaes obtidas pela aplicao desses critrios tm sido
consideradas relevantes para as atividades de manuteno, depurao e confiabilidade de soft-
ware [3, 69].
Na tcnica de teste estrutural, tambm conhecida como teste caixa branca (em oposio
ao nome caixa preta), os aspectos de implementao so fundamentais na escolha dos 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 de programa conhecida
como grafo de fluxo 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 comandos desse bloco, na ordem dada. Todos os
comandos de um bloco, possivelmente com exceo do primeiro, tm um nico predecessor e
exatamente um nico sucessor, exceto possivelmente o ltimo comando.
A representao de um programa P como um grafo de fluxo de controle (G = (N; E ; s))
consiste em estabelecer uma correspondncia entre ns e blocos e em indicar possveis fluxos
de controle entre blocos atravs dos arcos. Um grafo de fluxo de controle portanto um grafo
orientado, com um nico n de entrada s 2 N e um nico n de sada, no qual cada vrtice
representa um bloco indivisvel de comandos e cada aresta representa um possvel desvio de
um bloco para outro. Cada bloco tem as seguintes caractersticas: 1) uma vez que o primei-
ro comando do bloco executado, todos os demais so executados seqencialmente; e 2) no
existe desvio de execuo para nenhum comando dentro do bloco. A partir do grafo de pro-
grama podem ser escolhidos os componentes que devem ser executados, caracterizando assim
o teste estrutural. Considere o programa identifier. Na Figura 1 identifica-se a caracterizao
dos blocos de comandos atravs dos nmeros esquerda dos comandos. A Figura 2 ilustra o
grafo de fluxo de controle do programa identifier (funo main) gerado pela ferramenta View-
Graph [64].
Seja um grafo de fluxo de controle G = (N; E ; s) onde N representa o conjunto de ns,
E o conjunto de arcos, e s o n de entrada. Um caminho uma seqncia finita de ns
10
e se OU T (x) = 0, x um n de sada. Em relao ao programa identifier, (2,3,4,5,6,7) um
caminho simples e livre de laos e o caminho (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) no executvel e qualquer caminho completo que o
inclua tambm no executvel, ou seja, no existe um dado de entrada que leve execuo
desse caminho.
11
requer que cada aresta do grafo, ou seja, cada desvio de fluxo de controle do programa,
seja exercitada pelo menos uma vez; e Todos-Caminhos requer que todos os cami-
nhos possveis do programa sejam executados [3]. Outros critrios dessa categoria so:
Cobertura de Deciso; Cobertura de Condio; Cobertura de Condies Mltiplas;
LCSAJ (Linear Code Sequence and Jump) [90]; o critrio Boundary-Interior [91]; e a
famlia de critrios K-tuplas requeridas de Ntafos [32].
Os casos de teste obtidos durante a aplicao dos critrios funcionais podem corresponder
ao conjunto inicial dos testes estruturais. Como, em geral, o conjunto de casos de teste funcional
no suficiente para satisfazer totalmente um critrio de teste estrutural, novos casos de teste so
gerados e adicionados ao conjunto at que se atinja o grau de satisfao desejado, explorando-
se, desse modo, os aspectos complementares das duas tcnicas [43].
Um problema relacionado ao teste estrutural a impossibilidade, em geral, de se determinar
automaticamente se um caminho ou no executvel, ou seja, no existe um algoritmo que
dado um caminho completo qualquer decida se o caminho executvel e fornea o conjunto de
valores que causam a execuo desse caminho [92]. Assim, preciso a interveno do testador
para determinar quais so os caminhos no executveis para o programa sendo testado.
12
adequados para certas classes de erros, como erros computacionais, uma vez que dependncias
de dados so identificadas, e portanto, segmentos funcionais so requeridos como requisitos de
teste.
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 do fluxo
de dados do programa, caracterizando associaes entre pontos do programa onde atribudo
um valor a uma varivel (chamado de definio da varivel) e pontos onde esse valor utilizado
(chamado de referncia ou uso de varivel). Os requisitos de teste so determinados com base
em tais associaes. A Figura 3 ilustra o Grafo-Def-Uso do programa identifier. Conforme o
modelo de fluxo de dados definido em [4], uma definio de varivel ocorre quando um valor
armazenado em uma posio de memria. Em geral, em um programa, uma ocorrncia de
varivel uma definio se ela est: i) no lado esquerdo de um comando de atribuio; ii) em
um comando de entrada; ou iii) em chamadas de procedimentos como parmetro de sada. A
passagem de valores entre procedimentos atravs de parmetros pode ser por valor, referncia
ou por nome [93]. Se a varivel for passada por referncia ou por nome considera-se que seja
um parmetro de sada. As definies decorrentes de possveis definies em chamadas de
procedimentos so diferenciadas das demais e so ditas definidas por referncia. A ocorrncia
de uma varivel um uso quando a referncia a essa varivel no a estiver definindo. Dois tipos
de usos so distinguidos: c-uso e p-uso. O primeiro tipo afeta diretamente uma computao
sendo realizada ou permite que o resultado de uma definio anterior possa ser observado; o
segundo tipo afeta diretamente o fluxo de controle do programa.
O critrio mais bsico dos critrios baseados em anlise de fluxo de dados o critrio Todas-
13
Definies (all-defs) e faz parte da famlia de critrios definidos por Rapps e Weyuker [31].
Entre os critrios dessa famlia o critrio Todos-Usos (all-uses) tem sido um dos mais utilizados
e investigados.
Todas-Definies: requer que cada definio de varivel seja exercitada pelo menos uma
vez, no importa se por um c-uso ou por um p-uso.
Todos-Usos: requer que todas as associaes entre uma definio de varivel e seus sub-
seqentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, atravs de pelo
menos um caminho livre de definio, ou seja, um caminho onde a varivel no redefi-
nida.
14
Na verdade, basta ter a extenso do grafo de programa associando a cada n do grafo infor-
maes a respeito das definies que ocorrem nesses ns, denominado de Grafo Def [4]. Por
exemplo, as potenciais-associaes (1,6,length) e (7,6,length) so requeridas pelo critrio
Todos-Potenciais-Usos [4], mas no seriam requeridas pelos demais critrios de fluxo de dados
que no fazem uso do conceito potencial-uso. Observe-se que, por definio, toda associao
uma potencial-associao. Dessa forma, as associaes requeridas pelo critrio Todos-Usos
so um subconjunto das potenciais-associaes requeridas pelo critrio Todos-Potenciais-Usos.
A relao de incluso uma importante propriedade dos critrios, sendo utilizada para
avali-los, do ponto de vista terico. O critrio Todos-Arcos, por exemplo, inclui o critrio
Todos-Ns, ou seja, qualquer conjunto de casos de teste que satisfaz o critrio Todos-Arcos
tambm satisfaz o critrio Todos-Ns, necessariamente. Quando no possvel estabelecer
essa ordem de incluso para dois critrios, como o caso de Todas-Defs e Todos-Arcos, diz-se
que tais critrios so incomparveis [31]. Deve-se observar que os critrios Potenciais-Usos
so os nicos critrios baseados em anlise de fluxo de dados que satisfazem, na presena de
caminhos no executveis, as propriedades mnimas esperadas de um critrio de teste, e que
nenhum outro critrio baseado em anlise de fluxo de dados os inclui. Um aspecto relevante
que alguns dos critrios Potenciais-Usos bridge the gap entre os critrios Todos-Arcos e
Todos-Caminhos mesmo na presena de caminhos no executveis, o que no ocorre para os
demais critrios baseados em fluxo de dados.
Como j citado, uma das desvantagens do teste estrutural a existncia de caminhos re-
queridos no executveis. Existe tambm o problema de caminhos ausentes, ou seja, quando
uma certa funcionalidade deixa de ser implementada no programa, no existe um caminho que
corresponda quela funcionalidade e, como conseqncia, nenhum caso de teste ser requerido
para exercit-la. Mesmo assim, esses critrios estabelecem de forma rigorosa os requisitos de
teste a serem exercitados, em termos de caminhos, associaes definio-uso, ou outras estrutu-
ras do programa, fornecendo medidas objetivas sobre a adequao de um conjunto de teste para
o teste de um dado programa P . Esse rigor na definio dos requisitos favorece a automatizao
desses critrios.
Os critrios estruturais tm sido utilizados principalmente no teste de unidade, uma vez que
os requisitos de teste por eles exigidos limitam-se ao escopo da unidade. Vrios esforos de pes-
quisa no sentido de estender o uso de critrios estruturais para o teste de integrao podem ser
identificados. Haley e Zweben propuseram um critrio para selecionar caminhos em um mdulo
que deveria ser testado novamente na fase de integrao com base em sua interface [94]. Lin-
nenkugel e Mllerburg apresentaram uma srie de critrios que estendem os critrios baseados
em fluxo de controle e em fluxo de dados para o teste de integrao [68]. Harrold e Soffa propu-
seram uma tcnica para determinar as estruturas de definio-uso interprocedurais permitindo a
aplicao dos critrios baseados em anlise de fluxo de dados em nvel de integrao [95]. Jin
15
e Offutt definiram alguns critrios baseados em uma classificao de acoplamento entre mdu-
los [96]. Vilela, com base no conceito de potencial-uso, estendeu os critrios Potenciais-Usos
para o teste de integrao [97].
livre de definio c.r.a v1 ; : : : ; vn do n i ao arco (j; k ). Observe-se que podem existir outros
caminhos livres de definio c.r.a algumas das variveis v 1; : : : ; vn mas que no sejam, simul-
taneamente, livres de definio para todas as variveis v1 ; : : : ; vn .
Utilizando o conjunto de casos de teste T 0 = {(a1, Vlido), (2B3, Invlido), (Z-12, Inv-
lido), (A1b2C3d, Invlido)} gerado anteriormente procurando satisfazer o critrio Particiona-
mento em Classes de Equivalncia, observa-se qual a cobertura obtida em relao aos critrios
16
Figura 4: Opes disponveis na ferramenta PokeTool.
17
Tabela 4: Elementos requeridos pelo critrio Todos-Potenciais-Usos.
Associaes Requeridas
h f
1) 1; (6; 7); lengthgi h f
17) 2; (6; 7); lengthgi
h f gi
2) 1; (1; 3); achar ; length ; valid_id h f
18) 2; (5; 6); lengthgi
h f gi
3) 1; (8; 10); length ; valid_ id h f
19) 3; (8; 10); achargi
h f
4) 1; (8; 10); valid_ id gi h f
20) 3; (8; 9); achargi
h f
5) 1; (8; 9); length ; valid_idgi h f
21) 3; (5; 7); achargi
h f
6) 1; (8; 9); valid_ id gi h f
22) 3; (6; 7); achargi
h f
7) 1; (7; 4); valid_ id gi h f
23) 3; (5; 6); achargi
h f
8) 1; (5; 7); length ; valid_idgi h f
24) 6; (8; 10); valid_ id gi
h f
9) 1; (5; 7); valid_ id gi h f
25) 6; (8; 9); valid_ id gi
h f gi
10) 1; (5; 6); length ; valid_ id h f
26) 6; (5; 7); valid_ id gi
h f
11) 1; (5; 6); valid_id gi h f
27) 6; (5; 6); valid_ id gi
h f
12) 1; (2; 3); achar; valid_id gi h f
28) 7; (8; 10); achar ; length gi
h f
13) 1; (1; 2); achar; length; valid_id gi h f
29) 7; (8; 9); achar; length gi
h f
14) 2; (8; 10); lengthgi h f
30) 7; (5; 7); achar; length gi
h f
15) 2; (8; 9); lengthgi h f
31) 7; (6; 7); achar; length gi
h f
16) 2; (5; 7); lengthgi h f
32) 7; (5; 6); achar; length gi
18
h2 (8 10) flengthgi e h6 (8 9) fvalid_idgi so no executveis. Na Tabela 5 esse proces-
; ; ; ; ; ;
h
1) 1; (6; 7); lengthf gi X h f
17) 2; (6; 7); lengthgi X
h f
2) 1; (1; 3); achar ; length; valid_id gi X h f
18) 2; (5; 6); lengthgi X
h f
3) 1; (8; 10); length ; valid_ id gi X h f
19) 3; (8; 10); achargi X
h
4) 1; (8; 10); valid_ idf gi X h f
20) 3; (8; 9); achargi X
h f
5) 1; (8; 9); length ; valid_id gi h f
21) 3; (5; 7); achargi X
h f
6) 1; (8; 9); valid_ id gi X h f
22) 3; (6; 7); achargi X
h f
7) 1; (7; 4); valid_ id gi X h f
23) 3; (5; 6); achargi X
h f
8) 1; (5; 7); length ; valid_id gi X h f
24) 6; (8; 10); valid_ id gi X
h f
9) 1; (5; 7); valid_ id gi X h f
25) 6; (8; 9); valid_ id gi
h f
10) 1; (5; 6); length ; valid_ id gi X h f
26) 6; (5; 7); valid_ id gi X
h f
11) 1; (5; 6); valid_ id gi X h f
27) 6; (5; 6); valid_ id gi X
h f
12) 1; (2; 3); achar; valid_id gi X h f
28) 7; (8; 10); achar ; length gi X
h f
13) 1; (1; 2); achar; length; valid_id gi X h f
29) 7; (8; 9); achar; length gi X
h
14) 2; (8; 10); length f gi h f
30) 7; (5; 7); achar; length gi X
h
15) 2; (8; 9); lengthf gi X h f
31) 7; (6; 7); achar; length gi X
h
16) 2; (5; 7); lengthf gi X h f
32) 7; (5; 6); achar; length gi X
T0 = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)}
T1 = T0 [
{(1#, Invlido), (%, Invlido), (c, Vlido)}
T2 = T1 [
{(#-%, Invlido)}
Observe-se que mesmo tendo satisfeito um critrio mais rigoroso como o critrio Todos-
Potenciais-Usos, a presena do erro ainda no foi revelada. Assim, motiva-se a pesquisa de
critrios de teste que exercitem os elementos requeridos com maior probabilidade de revelar
erros [101]. Outra perspectiva que se coloca utilizar uma estratgia de teste 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 requeridos pelo critrio
Todos-Potenciais-Usos, e, posteriormente, poder-se-ia considerar o critrio Anlise de Mutantes
(descrito na prxima seo), que do ponto de vista terico incomparvel com os critrios
baseados em fluxo de dados, mas em geral de maior custo de aplicao.
19
de Mutantes utiliza um conjunto de programas ligeiramente modificados (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 conjunto de casos de teste que consiga
revelar, atravs da execuo de P , as diferenas de comportamento existentes entre P e seus
mutantes [66].
A seguir d-se uma viso geral do critrio Anlise de Mutantes e da ferramenta de apoio
Proteum, desenvolvida no ICMC-USP [62]. Informaes mais detalhadas sobre a Anlise de
Mutantes e sobre a ferramenta Proteum podem ser obtidas em [1, 62, 103].
20
A seguir, os mutantes so executados com o mesmo conjunto de casos de teste T . O objetivo
obter casos de teste que resultem apenas em mutantes mortos (para algum caso 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 2 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 ocorrerem [34].
preciso ressaltar que, em geral, a equivalncia entre programas uma questo indecidvel
e requer a interveno do testador. Essa limitao terica, no entanto, no significa que o
problema deva ser abandonado por no apresentar soluo. Na verdade, alguns mtodos e
heursticas tm sido propostos para determinar a equivalncia de programas em uma grande
porcentagem dos casos de interesse [25].
Um ponto importante destacado por DeMillo [52] que a Anlise de Mutantes fornece
uma medida objetiva do nvel de confiana da adequao dos casos de teste analisados atravs
da definio de um escore de mutao (mutation score), que relaciona o nmero de mutantes
mortos com o nmero de mutantes gerados. O escore de mutao calculado da seguinte forma:
DM (P; T )
ms(P; T ) =
M (P ) E M (P )
sendo:
DM (P; T ) : nmero de mutantes mortos pelos casos de teste em T .
21
3.4.1 A Ferramenta de Teste Proteum
Como ressaltado anteriormente, a aplicao de critrios de teste sem o apoio de uma ferramenta
de software propensa a erros. Vrias so as iniciativas de desenvolvimento de ferramentas de
apoio aplicao do critrio Anlise de Mutantes [35, 43, 52, 53, 62, 103, 112]. A Proteum [62,
103], desenvolvida no ICMC-USP, a nica ferramenta que apia o teste de mutao para
programas C existente atualmente. Alm disso, devido a caractersticas de multi-linguagem,
ela tambm pode ser configurada para o teste de programas escritos em outras linguagens. A
Proteum est disponvel para os sistemas operacionais SunOS, Solaris e Linux. Na Figura 7
apresentada a tela principal da ferramenta bem como as funes disponveis. Basicamente, a
ferramenta Proteum oferece ao testador recursos para, atravs da aplicao do critrio Anlise
de Mutantes, avaliar a adequao de ou 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 obter um conjunto adequado ao critrio. Desse modo, a ferramenta pode ser
utilizada como instrumento de avaliao bem como de seleo de casos de teste.
Os recursos oferecidos pela ferramenta (Figura 7) permitem a execuo das seguintes ope-
raes: definio de casos de teste, execuo do programa em teste, seleo dos operadores
de mutao que sero utilizados para gerar os mutantes, gerao dos mutantes, execuo dos
mutantes com os casos de teste definidos, anlise dos mutantes vivos e clculo do escore de
mutao. As funes implementadas na Proteum possibilitam que alguns desses recursos sejam
executados automaticamente (como a execuo dos mutantes), enquanto que para outros so
fornecidas facilidades para que o testador possa realiz-los (como a anlise de mutantes equi-
valentes) [35, 62]. Alm disso, diversas caractersticas adicionais foram incorporadas de modo
a facilitar a atividade de teste e/ou a conduo de experimentos. o caso, por exemplo, da pos-
sibilidade de executar um mutante com todos os casos de teste disponveis, mesmo que algum
deles j o tenha matado. Atravs desse tipo de teste, chamado research, conseguem-se dados a
respeito da eficincia dos operadores de mutao ou mesmo para a determinao de estratgias
de minimizao dos conjuntos de casos de teste [62, 103].
Um dos pontos essenciais para a aplicao do critrio Anlise de Mutantes a definio do
conjunto de operadores de mutao. A Proteum conta com 71 operadores de mutao dividi-
dos em quatro classes (Figura 8) [62]: mutao de comandos (statement mutations), mutao
de operadores (operator mutations), mutao de variveis (variable mutations) e mutao de
constantes (constant mutations). possvel escolher os operadores de acordo com a classe de
erros que se deseja enfatizar, permitindo que a gerao de mutantes seja feita em etapas ou
at mesmo dividida entre vrios testadores trabalhando independentemente. Na Tabela 6 so
ilustrados alguns operadores de mutao para cada uma das classes de operadores.
A Proteum tambm trabalha com sesso de teste, ou seja, conjunto de atividades envolvendo
um teste que podem ser realizadas em etapas, sendo possvel ao usurio iniciar e encerrar o teste
de um programa, bem como retom-lo a partir de onde este foi interrompido. Para o programa
identifier, o processo de criao de uma sesso de teste utilizando a interface grfica ilustrado
na Figura 9 abaixo.
Uma sesso de teste com o apoio das ferramentas Proteum e PokeTool pode ser conduzida
atravs de uma interface grfica ou atravs de scripts. A interface grfica permite ao usurio
22
Figura 7: Opes disponveis na ferramenta Proteum.
23
Tabela 6: Exemplos de operadores de mutao para programas C.
Operador Descrio
SSDL Retira um comando de cada vez do programa.
ORRN Substitui um operador relacional por outro operador relacional.
VTWD Substitui a referncia escalar pelo seu valor sucessor e predecessor.
Ccsr Substitui referncias escalares por constantes.
SWDD Substitui o comando while por do-while.
SMTC Interrompe a execuo do lao aps duas execues.
OLBN Substitui operador lgico por operador bitwise.
Cccr Substitui uma constante por outra constante.
VDTR Fora cada referncia escalar a possuir cada um dos valores: negativo, positivo e zero.
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 elaborao de scripts exige
um esforo de programao e completo domnio tanto dos conceitos sobre o teste baseado em
mutao quanto dos prprios programas que compem as ferramentas, devendo ser utilizado
pelo testador mais experiente [35]. Scripts de teste tm se mostrado de grande utilidade na
conduo de estudos empricos, onde uma mesma seqncia de passos deve ser executada vrias
vezes at que os resultados obtidos sejam significantes do ponto de vista estatstico.
A seguir, ser avaliada a adequao da atividade de teste do programa identifier, realizada
at este ponto com o uso da ferramenta PokeTool, em relao ao critrio Anlise de Mutantes,
com o apoio da ferramenta Proteum; ou seja, ser avaliada a adequao dos conjuntos Todos-
Usos-adequado e Todos-Potenciais-Usos-adequado em relao ao critrio Anlise de Mutantes.
Inicialmente, somente os casos de teste do conjunto T 0 foram importados; a Figura 10(a) mostra
o estado da sesso de teste aps a execuo dos mutantes. Em seguida, como o escore de
mutao ainda no satisfatrio, foram adicionados os casos de teste do conjunto T 1 e T2
(Figura 10(b)). Observa-se que mesmo aps a adio 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 mais
24
13 casos de teste foram criados visando a matar os mutantes vivos no-equivalentes: T 3 = T2 [
{(zzz, Vlido), (aA, Vlido), (A1234, Vlido), (ZZZ, Vlido), (AAA, Vlido), (aa09, Vlido),
([, Invlido), ({, Invlido), (x/, Invlido), (x:, Invlido), (x18, Vlido), (x[[, Invlido), (x{{,
Invlido)}. A Figura 11 ilustra dois dos mutantes vivos que foram analisados. O mutante
da Figura 11 (a) um mutante equivalente e o mutante da Figura 11 (b) um mutante que
morre com o caso de teste ([, Invlido), presente em T3 . Os pontos nos quais as mutaes
foram aplicadas est destacado em negrito. A Figura 10(c) ilustra o resultado obtido aps
T3 ter sido executado com todos os mutantes vivos. Como pode ser observado, 64 mutantes
ainda permaneceram vivos. Isto significa que qualquer um desses 64 mutantes poderiam ser
considerados corretos em relao atividade de teste atual, uma vez que no existe um caso
de teste selecionado que seja capaz de distinguir entre o comportamento dos mutantes e do
programa original (Figura 10(c)).
A fim de obter uma melhor cobertura do critrio Anlise de Mutantes, o processo de anlise
dos mutantes vivos continuou at que todos os equivalentes fossem marcados. Ao trmino desse
25
.. ..
. .
int valid_s(char ch)
main() { {
... if(((ch >= A) &&
if(valid_id * (ch <= z)) ||
(length >= 1) && ((ch >= a) &&
(length < 6)) (ch <= z)))
{ {
printf ("Valido\n"); return (1);
} }
else else
{ {
printf ("Invalid\n"); return (0);
} }
}
.. ..
. .
(a) Mutante equivalente (b) Mutante no-equivalente
Figura 11: Exemplos de mutantes do programa identifier.
.. ..
. .
if(valid_id && if(valid_id &&
(length >= 1) && (length >= 1) &&
(PRED(length) < 6)) (length <= 6))
{ {
printf ("Valido\n"); printf ("Valido\n");
} }
.. ..
. .
(a) Mutante error-revealing (b) Mutante correto
Figura 12: Mutantes vivos do programa identifier.
processo, mais quatro casos de teste foram construdos (T 4 = T3 [ {(@, Invlido), (, Invlido),
(x@, Invlido), (x, Invlido)}). A Figura 10(d) mostra o resultado final 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: Figura 12 (b). Um mutante dito ser
error-revealing se para qualquer caso de teste t tal que P (t) 6= M (t) pudermos concluir que
P (t) no est de acordo com o resultado esperado, ou seja, revela a presena de um erro.
Observe que os mutantes error-revealing, Figura 12 (a) e (b), foram gerados pelos operado-
res de mutao ORRN e VTWD e que necessariamente o erro presente na verso do programa
identifier ser revelado ao elaborar-se qualquer caso de teste que seja capaz de distinguir o com-
portamento desses mutantes e a verso do programa identifier em teste. Os mutantes Figura 12
morrem, por exemplo, com o caso de teste (ABCDEF, Vlido).
O erro encontrado no programa original foi corrigido e, aps a sua correo o conjunto
completo de casos de teste T5 foi reavaliado (T5 = T4 [ {(ABCDEF, Vlido)}, resultando
em um conjunto 100% adequado ao critrio Anlise de Mutantes, para a verso corrigida do
programa identifier(Figura 13). A parte corrigida est destacada em negrito.
Para o programa identifier, utilizando-se todos os operadores de mutao, foram gerados
933 mutantes. Aplicando-se somente os operadores da Tabela 6 teriam sido gerados somente
26
/****************************************************************************************
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 () int valid_s(char ch)
/* 1 */ { /* 1 */ {
/* 1 */ char achar; /* 1 */ if(((ch >= A) &&
/* 1 */ int length, valid_id; (ch <= Z)) ||
/* 1 */ length = 0; ((ch >= a) &&
/* 1 */ valid_id = 1; (ch <= z)))
/* 1 */ printf ("Identificador: "); /* 2 */ {
/* 1 */ achar = fgetc (stdin); /* 2 */ return (1);
/* 1 */ valid_id = valid_s(achar); /* 2 */ }
/* 1 */ if(valid_id) /* 3 */ else
/* 2 */ { /* 3 */ {
/* 2 */ length = 1; /* 3 */ return (0);
/* 2 */ } /* 3 */ }
/* 3 */ achar = fgetc (stdin); /* 4 */ }
/* 4 */ while(achar != \n)
/* 5 */ { int valid_f(char ch)
/* 5 */ if(!(valid_f(achar))) /* 1 */ {
/* 6 */ { /* 1 */ if(((ch >= A) &&
/* 6 */ valid_id = 0; (ch <= Z)) ||
/* 6 */ } ((ch >= a) &&
/* 7 */ length++; (ch <= z)) ||
/* 7 */ achar = fgetc (stdin); ((ch >= 0) &&
/* 7 */ } (ch <= 9)))
/* 8 */ if(valid_id && /* 2 */ {
(length >= 1) && (length <= 6)) /* 2 */ return (1);
/* 9 */ {
/* 9 */ printf ("Valido\n"); /* 2 */ }
/* 9 */ } /* 3 */ else
/* 10 */ else /* 3 */ {
/* 10 */ { /* 3 */ return (0);
/* 10 */ printf ("Invalid\n"); /* 3 */ }
/* 10 */ } /* 4 */ }
/* 11 */ }
27
Mutao de Interface inserir perturbaes nas conexes entre duas unidades.
Utilizando o raciocnio do teste de mutao, casos de teste capazes de distinguir mutantes
de interface tambm devem ser capazes de revelar grande parte dos erros de integrao. Essa
afirmao depende, evidentemente, de quais mutantes so utilizados ou, em outras palavras,
quais operadores de mutao so aplicados [35].
Segundo Haley e Zweben [94], os erros de integrao podem ser classificados em erros de
integrao de domnio e computacional. Dada uma funo F que chama G, o primeiro ocorre
quando um erro de domnio1 em G causa uma sada incorreta em F. O segundo ocorre quando
um erro computacional em G produz um valor incorreto que passado para F que, por sua vez,
produz uma sada incorreta. Em ambos os casos existe algum valor incorreto sendo passado
entre as unidades, o que resulta em uma sada incorreta. Considerando esses aspectos possvel
classificar os erros de integrao em trs categorias.
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 S I (G) como o conjunto de valores passados para G e
S O (G) os valores retornados por G. Ao executar P com o caso de teste t, um erro de integrao
Erro Tipo 3 (Figura 14 (c)): os valores contidos em S I (G) so os esperados por G, mas
valores incorretos em S O (G) so produzidos dentro de G e esses valores fazem com que
F produza um resultado incorreto aps o retorno de G. Esse tipo de erro pode ocorrer se
uma funo chamada com todos os parmetros corretos, mas internamente ela realiza
um clculo incorreto produzindo um valor de retorno no esperado que, posteriormente,
leva a um resultado incorreto.
Percebe-se que esta classificao dos tipos de erros abrangente e no especifica o local
do defeito que causa o erro. Ela simplesmente considera a existncia de um valor incorreto
entrando ou saindo de uma funo chamada. Isso exclui, por exemplo, o caso em que S I (G)
tem os valores esperados mas um erro dentro de G produz uma sada incorreta antes do retorno
de G. Neste caso, no existe nenhuma propagao de erro atravs da conexo F-G e esse tipo
de erro deveria ser detectado no teste de unidade.
1
Um erro de domnio ocorre quando um caminho incorreto executado; um erro computacional ocorre quando
o caminho correto executado mas o valor computado incorreto.
28
Saida Saida
F F incorreta F
incorreta
Saida G G
G
incorreta
Figura 14: Tipos de Erros de Integrao [35]: (a) Erro Tipo 1, (b) Erro Tipo 2, (c) Erro Tipo 3.
29
Figura 15: Grupos e operadores de mutao da PROTEUM=IM.
por exemplo, quando a unidade F faz duas chamadas unidade G. Nesse caso, os mutantes
associados a primeira chamada s podero ser mortos por 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 F chama G. Entretanto, para os operadores do Grupo-I
isso no ocorre. Visto que a mutao realizada no corpo da unidade G, necessrio saber
qual chamada ser usada de modo que o mutante s possa ser morto a partir daquele ponto de
chamada. Caso a unidade seja chamada a partir de outro ponto, ela deve se comportar como no
programa original, ou seja, a mutao no deve ser habilitada [88].
Para ilustrar a aplicao do critrio Mutao de Interface, a seguir, da mesma forma como
anteriormente, a ferramenta PROTEUM=IM ser utilizada para avaliar a adequao dos con-
juntos de casos de teste adequados aos critrios Particionamento em Classes de Equivalncia
(T0 ), Todos-Potenciais-Usos (T2 ) e Anlise de Mutantes (T5 ). As Figuras 17(b), 17(c) e 17(d)
ilustram as coberturas obtidas para esses conjuntos de casos de teste, respectivamente.
Como pode ser observado, utilizando-se todos os operadores de mutao de interface, foram
gerados 456 mutantes. A ttulo de ilustrao, a Figura 18 mostra dois dos mutantes de interface
gerados para o programa identifier. O mutante da Figura 18 (a) foi gerado pelo operador I-
30
F() {
s1;
s2;
...
Primeiro Conjunto
G(); de Mutantes
...
G(); Segundo Conjunto
de Mutantes
...
}
31
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 funo PREPARE_MUTA()
no ponto de chamada da funo que se deseja testar, no caso a funo valid_s, e no corpo
de valid_s, outra funo (IF_MUTA()) verifica se a mesma foi chamada a partir do ponto
desejado, do contrrio a mutao no ativada.
.. ..
. .
main() {
...
printf ("Identificador: ");
achar = fgetc (stdin);
(valid_id = PREPARE2_MUTA(valid_s(achar)));
...
}
printf ("Identificador: ");
int valid_s(char ch) { achar = fgetc (stdin);
if(IF_MUTA(((ch >= A) && (ch <= Z)) || valid_id = valid_s(-achar);
((ch >= a) && (ch <= z)), if(valid_id)
((ch >= A) && (ch <= Z)) || {
((ch >= a) && (ch <= z))) length = 1;
{ }
return (1);
}
else
{
return (0);
}
}
.. ..
. .
(a) Mutante do Grupo-I (b) Mutante do Grupo-II
Figura 18: Exemplos de mutantes gerados pela ferramenta PROTEUM=IM.
Aps a execuo dos mutantes de interface com o conjunto T 0 , 243 mutantes permanece-
ram vivos, resultando em um escore de mutao de, aproximadamente, 0,47 (Figura 17(a)).
Analisando-se os mutantes vivos, observa-se que 28 deles eram equivalentes. Recalculando o
escore de mutao, eliminando os equivalentes, o valor obtido para T 0 passou a ser de 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 Mutao de Interface
no teriam sido cobertos por T0 .
Em seguida, na Figura 17(c) tem-se a adequao do conjunto Todos-Potenciais-Usos-adequado
(T2 ) em relao Mutao de Interface. Observa-se que, mesmo tendo o dobro de casos de tes-
te que T0 , o escore de mutao obtido com T2 ainda no satisfatrio (0,50) e a metade dos
requisitos exigidos pela Mutao de Interface ainda no foram satisfeitos.
Continuando a avaliar a cobertura obtida pelo conjunto de casos de teste adequados ao
critrio Anlise de Mutantes (T5 ) observa-se que foi possvel obter um conjunto Mutao de
Interface-adequado, ou seja, para o programa identifier, um conjunto de casos de teste Anli-
se de Mutantes-adequado tambm se mostrou Mutao de Interface-adequado (Figura 17(d)).
Deve-se observar que os critrios Anlise de Mutantes e Mutao de Interface so incompar-
veis do ponto de vista da relao de incluso [51]. Nos experimentos conduzidos, utilizando-se
32
programas de maior complexidade, observou-se que conjuntos de casos de teste Anlise de
Mutantes-adequados no eram Mutao de Interface-adequados e vice-versa. Em nvel de uni-
dade, observou-se que os critrios Anlise de Mutantes e Todos-Potenciais-Usos so incompar-
veis tanto do ponto de vista terico quanto emprico [43]. Tais resultados motivam a investigar
qual a relao existente entre o critrio Mutao de Interface e os critrios Potenciais-Usos de
unidade [4] e de integrao [97].
33
Quanto aos critrios baseados em anlise de fluxo de dados, como um dos primeiros esforos
significantes tem-se a ferramenta Asset (A System to Select and Evaluate Tests), 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 fluxo de dados definidos por Rapps
e Weyuker [30, 31].
A Proteste [69] tem como objetivo implementar um ambiente completo para suporte ao tes-
te estrutural de programas escritos em Pascal, incluindo tanto critrios baseados em fluxo de
controle (Todos-Ns e Todos-Arcos) quanto critrios baseados em fluxo de dados (os definidos
por Rapps e Weyuker [30, 31] e os Potenciais-Usos [4]). Alm de Pascal, possvel configurar
o ambiente para outras linguagens atravs da utilizao de uma ferramenta que gera analisa-
dores de cdigo fonte especficos para cada linguagem. O ambiente Proteste um prottipo
desenvolvido na Universidade Federal do Rio Grande do Sul.
Um dos esforos mais significativos no contexto de ferramentas de teste foi o desenvolvi-
mento da Atac (Automatic Test Analysis for C), pela Telcordia Technologies [56]. A Atac apia
a aplicao de critrios estruturais de fluxo de controle e de dados no teste de programas escritos
nas linguagens C e C++. Basicamente, a ferramenta permite verificar a adequao de um con-
junto de casos de teste, visualizar cdigo no coberto pelos casos de teste, auxiliar na gerao
de casos de teste e reduzir o tamanho do conjunto de teste, atravs da eliminao de casos de
teste redundantes.
Atualmente a Atac est integrada ao xSuds (Telcordia Software Visualization and Analysis
Toolsuite), um ambiente de suporte s atividades de teste, anlise e depurao [78]. O ambiente
xSuds vem sendo comercializado pela IBM, sendo uma forte evidncia de que o uso de critrios
baseados em fluxo de dados constituir, em um futuro prximo, o estado da prtica no que diz
respeito ao teste de software.
As ferramentas de teste, embora implementem tcnicas e critrios diferentes, apresentam
caractersticas globais bastante semelhantes. Assim, pode-se identificar conjuntos bsicos de
operaes que caracterizam atividades pertinentes ao processo de teste de software. As opera-
es realizadas por tais ferramentas podem ser divididas em [116]: criao da sesso de teste,
tratamento de casos de teste (adio, eliminao, visualizao, importao e minimizao do
conjunto de casos de teste), gerao dos requisitos de teste, anlise da adequao do conjunto
de casos de teste e gerao de relatrios. Na Tabela 8 esto sintetizadas algumas das principais
caractersticas das ferramentas Proteum, PROTEUM=IM e PokeTool.
5 Estudos Empricos
Em virtude da diversidade de critrios de teste existente, saber qual deles deve ser utilizado ou
como utiliz-los de forma complementar a fim de obter o melhor resultado com o menor custo
uma questo complicada. A realizao de estudos empricos procura, atravs da compara-
o entre os critrios, obter uma estratgia que seja eficaz para revelar a presena de erros no
programa, ao mesmo tempo em que apresente um baixo custo de aplicao.
Para entender a importncia desses estudos, considere a seguinte situao [41]: preciso
testar um programa P que ser usado em um ambiente de segurana crtica e o funcionamento
34
Tabela 8: Principais caractersticas das ferramentas PokeTool, Proteum e PROTEUM=IM.
PokeTool Proteum PROTEUM=IM
Linguagem C, COBOL, FORTRAN C C
Gerao automtica de casos de teste No No No
Edio de casos de teste Sim Sim Sim
Registro sobre caminhos no executveis Sim Sim Sim
ou mutantes equivalentes
Restrio de tamanho do programa a ser No No No
testado
Eliminao de casos de teste redundantes Sim Sim No
Interface Menu, Janelas e Scripts Janelas e Scripts Janelas e Scripts
Sesses de teste Sim Sim Sim
Apoio a experimentos Sim Sim Sim
Importao de casos de teste Sim Sim Sim
Gerao seletiva de mutantes No se aplica Sim Sim
Ambiente compilado/interpretado Compilado Compilado Compilado
Execuo distribuda No No No
Determinao automtica de mutantes Sim No No
equivalentes ou caminhos no executveis
(heursticas)
desse sistema depende de que P tenha sido bem testado. O testador deve testar P tanto quanto
for possvel e, para isso, decide usar vrios critrios de teste a fim de verificar a adequao dos
casos de teste desenvolvidos. Inicialmente, os casos de teste so gerados de modo a satisfazerem
um determinado critrio C1 . Assim, uma questo que surge : Tendo obtido um conjunto
de casos de teste T adequado ao critrio C1 e, utilizando agora o critrio C2 , consegue-se
melhorar o conjunto de casos de teste T?. Atravs de estudos empricos procura-se responder
a essa e outras questes que surgem diante da dificuldade em decidir quando um programa est
suficientemente testado.
Segundo Wong et al. [47], custo, eficcia e dificuldade de satisfao (strength) so fatores
bsicos para comparar a adequao dos critrios de teste. Custo: refere-se ao esforo necessrio
na utilizao de um critrio. Pode ser medido atravs do nmero de casos de teste requeridos
para satisfazer o critrio ou por outras mtricas dependentes do critrio, tais como: o tempo
necessrio para executar todos os mutantes gerados ou o tempo gasto para identificar os mu-
tantes equivalentes, caminhos e associaes no executveis, construir manualmente os casos
de teste e aprender a utilizar as ferramentas de teste. Eficcia: refere-se capacidade de um
critrio em detectar um maior nmero de erros em relao a outro. Dificuldade de satisfao:
refere-se probabilidade de satisfazer um critrio tendo satisfeito outro [41]; seu objetivo
verificar o quanto consegue-se satisfazer um critrio C1 tendo satisfeito um critrio C2 (C1 e C2
so incomparveis ou C1 inclui C2 ).
Utilizando-se tais fatores comparativos, estudos empricos e tericos so conduzidos com
o objetivo de encontrar formas econmicas e produtivas para a realizao dos testes. O desen-
volvimento de experimentos requer a elaborao de um framework para sua conduo. Esse
framework composto, basicamente, pelas seguintes atividades [42]:
35
seleo e preparao dos programas;
36
custo/eficcia. Segundo os autores, ambas mostraram-se igualmente eficazes, obtendo-se signi-
ficativa reduo no nmero de mutantes a serem analisados sem sensvel perda na eficcia em
revelar erros.
Em outro trabalho realizado por Mathur e Wong [41] foi comparada a adequao de con-
juntos de casos de teste em relao aos critrios Anlise de Mutantes e Todos-Usos. O objetivo
do experimento era verificar a dificuldade de satisfao entre os dois critrios, bem como seus
custos, uma vez que esses critrios so incomparveis do ponto de vista terico. Nesse estudo,
os conjuntos de casos de teste Anlise de Mutantes-adequados tambm se mostraram Todos-
Usos-adequados. No entanto, os conjuntos de casos de teste Todos-Usos-adequados no se
mostraram, em muitos dos casos, adequados para o critrio Anlise de Mutantes. Esses resul-
tados demonstram que mais difcil satisfazer o critrio Anlise de Mutantes do que o critrio
Todos-Usos, podendo-se dizer, na prtica, que Anlise de Mutantes inclui Todos-Usos [41].
Wong et al. [47] utilizaram a Mutao Aleatria (10%) e a Mutao Restrita para compa-
rar o critrio Anlise de Mutantes com o critrio Todos-Usos; o objetivo era verificar o custo,
eficcia e dificuldade de satisfao desses critrios. Os autores forneceram evidncias de que
os critrios Todos-Usos, Mutao Aleatria (10%) e Mutao Restrita representam, nesta or-
dem, o decrscimo do custo necessrio para a aplicao do critrio (nmero de casos de teste
requeridos), ou seja, o critrio Todos-Usos requer mais casos de teste para ser satisfeito do que
a Mutao Restrita. Em relao eficcia para detectar erros, a ordem (do mais eficaz para
o menos) Mutao Restrita, Todos-Usos e Mutao Aleatria. Observou-se, com isso, que
examinar somente uma pequena porcentagem de mutantes pode ser uma abordagem til na ava-
liao e construo de conjuntos de casos de teste na prtica. Desse modo, quando o testador
possui pouco tempo para efetuar os testes (devido ao prazo de entrega do produto) pode-se usar
o critrio de Anlise de Mutantes para testar partes crticas do software, utilizando alternativas
mais econmicas, tal como a Mutao Restrita ou o critrio Todos-Usos, para o teste das demais
partes do software, sem comprometer significativamente a qualidade da atividade de teste.
Offutt tambm realizou um experimento comparando o critrio Anlise de Mutantes com
o critrio Todos-Usos [118]. Os resultados foram semelhantes queles obtidos por Wong et
al. [47], ou seja, o critrio Anlise de Mutantes revelou um maior nmero de erros do que o
critrio Todos-Usos e mais casos de testes foram necessrios para satisfazer o critrio Anlise
de Mutantes. Alm disso, os conjuntos de casos de teste Anlise de Mutantes-adequados foram
adequados ao critrio Todos-Usos, no sendo o inverso verdadeiro, 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 eficcia em revelar erros. Analisou-se a eficcia das classes de
mutao obtidas a partir dos operadores de mutao da ferramenta Proteum. Desse experimento
pode-se observar quais classes de mutao eram mais econmicas (baixo custo de aplicao) e
eficazes. Com isso, foi possvel o estabelecimento de uma ordem incremental para o emprego
dessas classes de mutao, com base na eficcia e custo de cada uma. Desse modo, os conjuntos
de casos de testes podem ser construdos inicialmente de forma a serem adequados classe com
menor relao custoeficcia. Na seqncia, quando as restries de custo permitirem, esse
conjunto pode ser melhorado de modo a satisfazer as classes de mutao com maior relao
custoeficcia.
37
Souza [43] realizou um estudo emprico com a finalidade de avaliar o strength e o custo
do critrio Anlise de Mutantes empregando, para efeito comparativo, os critrios Potenciais-
Usos [4], os quais incluem o critrio Todos-Usos. Os resultados demonstraram que o custo de
aplicao do critrio Anlise de Mutantes, estimado pelo nmero de casos de teste necessrio
para satisfazer o critrio, apresentou-se maior do que o custo dos critrios Potenciais-Usos. Em
relao dificuldade de satisfao (strength) observou-se que, de uma maneira geral, os critrios
Anlise de Mutantes e Todos-Potenciais-Usos (PU) so incomparveis mesmo do ponto de vista
emprico. J os critrios Todos-Potenciais-Usos/Du (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 investigar-se o aspecto complementar desses critrios
quanto eficcia.
Entre os estudos empricos que visam a estabelecer alternativas viveis para a aplicao do
critrio Anlise de Mutantes pode-se destacar o trabalho de Offutt et al. [46]. O objetivo do
estudo conduzido por Offutt et al. [46] era determinar um conjunto essencial de operadores de
mutao para o teste de programas FORTRAN, a partir dos 22 operadores de mutao utiliza-
dos pela Mothra. Os resultados obtidos demonstraram que apenas cinco eram suficientes para
aplicar eficientemente o teste de mutao.
Nessa mesma linha, um estudo preliminar realizado por Wong et al. [119], comparando a
Mutao Restrita no contexto das linguagens C e Fortran, resultou na seleo de um subcon-
junto de operadores de mutao da ferramenta Proteum [62, 120], constituindo uma base para a
determinao do conjunto essencial de operadores de mutao para a linguagem C. A aplicao
deste subconjunto de operadores possibilitou reduzir o nmero e mutantes gerados, mantendo a
eficcia do critrio em revelar a presena de erros. A seleo dos operadores de mutao foi re-
alizada com base na experincia dos autores e os resultados motivaram a conduo do trabalho
de Barbosa [77]. Nesse trabalho forma conduzidos experimentos com o objetivo de investigar
alternativas pragmticas para a aplicao do critrios Anlise de Mutantes e, nesse contexto, foi
proposto o procedimento Essencial para a determinao de um conjunto essencial de operado-
res de mutao para a linguagem C, com base nos operadores de mutao implementados na
ferramenta Proteum.
Para a aplicao e validao desse procedimento dois experimentos foram conduzidos. No
primeiro, utilizou-se um grupo de 27 programas os quais compem um editor de texto simplifi-
cado; no segundo, 5 programas utilitrios do UNIX foram utilizados. De um modo geral, ambos
os conjuntos essenciais obtidos apresentaram um alto grau de adequao em relao ao crit-
rio Anlise de Mutantes, com escores de mutao acima de 0,995, proporcionando, em mdia,
redues de custo superiores a 65% [77].
Com a proposio do critrio Mutao de Interface [35, 121] evidente o aspecto positivo
de se utilizar o mesmo conceito de mutao nas diversas fases do teste. Tambm natural a
indagao sobre qual estratgia utilizar para se obter a melhor relao custoeficcia quando
so aplicados os critrios Anlise de Mutantes e Mutao de Interface 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 utilizar tais critrios de forma complementar na
atividade de teste, tendo como objetivo contribuir para o estabelecimento de uma estratgia de
teste incremental, de baixo custo de aplicao e que garanta um alto grau de adequao em
38
relao a ambos os critrios [44].
Inicialmente, estabeleceu-se uma estratgia incremental para a aplicao dos operadores
de mutao implementados na ferramenta PROTEUM=IM [35], procurando reduzir o custo de
aplicao do critrio Mutao de Interface. A utilizao dessa estratgia possibilitou uma re-
duo no custo de aplicao do critrio Mutao de Interface em torno de 25% e, ainda assim,
conjuntos de casos de teste MI-adequados foram obtidos. Alm disso, um estudo preliminar
para a determinao do conjunto essencial de operadores de mutao interface foi conduzido,
utilizando o procedimento Essencial definido por Barbosa [77]. O conjunto essencial obtido
possibilitou a seleo de conjuntos de casos de teste altamente adequados ao critrio Muta-
o de Interface (escores de mutao em torno de 0,998) com reduo de custo, em termos do
nmero de mutantes gerados, superior a 73% [44].
A dificuldade de satisfao entre os critrios Anlise de Mutantes e Mutao de Interface
tambm foi avaliada, observando-se que tais critrios so incomparveis do ponto de vista da
relao de incluso [30], devendo ser utilizados em conjunto para assegurar um teste de melhor
qualidade. Explorando o aspecto complementar desses critrios, algumas estratgias de aplica-
o dos operadores de mutao de unidade e de integrao foram estabelecidas. Tais estratgias
demonstraram que, mesmo com um nmero reduzido de operadores, possvel determinar con-
juntos de casos de teste adequados ou muito prximos da adequao para ambos os critrios, a
um menor custo [44].
6 Concluso
Neste texto foram apresentados alguns critrios de teste de software e conceitos pertinentes,
com nfase naqueles considerados mais promissores a curto e mdio prazo: os critrios basea-
dos em fluxo de dados, o critrio Anlise de Mutantes e o critrio Mutao de Interface. Foram
tambm apresentadas as ferramentas de teste PokeTool, Proteum e PROTEUM=IM, assim co-
mo identificadas vrias outras iniciativas e esforos de automatizao desses critrios, dada a
relevncia desse aspecto para a qualidade e produtividade da prpria atividade de teste.
Deve-se ressaltar que os conceitos e mecanismos desenvolvidos neste texto aplicam-se no
contexto do paradigma de desenvolvimento de software orientado a objeto, com as devidas
adaptaes. Em uma primeira etapa espera-se explorar a aplicao desses critrios no teste de
programas C++ e Java. Tanto no teste intra-mtodo quanto inter-mtodo, a aplicao dos crit-
rios Anlise de Mutantes e Mutao de Interface, respectivamente, praticamente direta. Poste-
riormente, quando outras interaes forem consideradas, bem como caractersticas especficas
da linguagem orientada a objetos, tais como, acoplamento dinmico, herana, polimorfismo e
encapsulamento, pode ser necessrio o desenvolvimento de novos operadores de mutao que
modelem os erros tpicos cometidos nesse contexto.
Procurou-se ressaltar o aspecto complementar das diversas tcnicas e critrios de teste e a
relevncia de se conduzir estudos empricos para a formao de um corpo de conhecimento
que favorea o estabelecimento de estratgias de teste incrementais que explorem as diversas
caractersticas dos critrios. Nessas estratgias seriam aplicados inicialmente critrios "mais
fracos"e talvez menos eficazes para a avaliao da adequao do conjunto de casos de teste, e em
39
funo da disponibilidade de oramento e de tempo, incrementalmente, poderiam ser utilizados
critrios mais fortes e eventualmente mais eficazes, porm, em geral, mais caros. Estudos
empricos so conduzidos no sentindo de avaliar os aspectos de custo, strength e eficcia dos
critrios de teste, buscando contribuir para o estabelecimento de estratgias de teste eficazes,
de baixo custo e para a transformao do estado da prtica, no que tange ao uso de critrios e
ferramentas de teste.
Foi salientado que a atividade de teste desempenha um papel relevante na temtica Quali-
dade de Software, tanto do ponto de vista de processo quanto do ponto de vista do produto.
Por exemplo, do ponto de vista de qualidade do processo de desenvolvimento de software, o
teste sistemtico uma atividade essencial para ascenso ao Nvel 3 do Modelo CMM do SEI.
Ainda, o conjunto de informao oriundo da atividade de teste significativo para as atividades
de depurao, estimativa de confiabilidade e de manuteno de software.
Referncias
[1] M. E. Delamaro and J. C. Maldonado. Uma viso sobre a aplicao da anlise de mutan-
tes. Technical Report 133, ICMC/USP, So Carlos - SP, March 1993.
[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 flow analysis for regression testing. In Sixth
Annual Pacific Northwest Software Quality Conference, Portland - Oregon, September
1988.
[7] J. Hartmann and D. J. Robson. Techniques for selective revalidation. IEEE Software,
pages 3136, January 1990.
[8] A. Veevers and A. Marshall. A relationship between software coverage metrics and
reliability. Software Testing, Verification and Reliability, 4:38, 1994.
[9] G. S. Varadan. Trends in reliability and test strategies. IEEE Software, May 1995.
[10] G. J. Myers. The Art of Software Testing. Wiley, New York, 1979.
40
[11] B. Beizer. Software Testing Techniques. Van Nostrand Reinhold Company, New York,
2nd edition, 1990.
[12] T. S. Chow. Testing software design modeled by finite-state machines. IEEE Transacti-
ons on Software Engineering, 4(3):178187, 1978.
[16] D. Hoffman and P. Strooper. A case study in class testing. In CASCON 93, pages 472
482, IBM Toronto Laboratory, October 1993.
[17] M. D. Smith and D. J. Robson. A framework for testing object-oriented programs. Jour-
nal of Object-Oriented Programming, 5(3):4553, June 1992.
[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.
[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, pages 1319, January/February 1990.
41
[25] T. A. Budd. Mutation Analysis: Ideas, Example, Problems and Prospects, chapter Com-
puter 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.
[27] P. M. Herman. A data flow analysis approach to program testing. Australian Computer
Journal, 8(3):, November 1976.
[28] W. Howden. Weak mutation testing and completeness of test sets. IEEE Transactions on
Software Engineering, SE-8(4):371379, July 1982.
[29] J. W. Laski and B. Korel. A data flow oriented program testing strategy. IEEE Transac-
tions on Software Engineering, 9(3), May 1983.
[30] S. Rapps and E. J. Weyuker. Data flow 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 flow information.
IEEE Transactions on Software Engineering, SE-11(4):367375, April 1985.
[32] S. C. Ntafos. On required element testing. IEEE Transactions on Software Engineering,
SE-10: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 Adequao Inter-procedimental
para o Teste de Integrao. PhD thesis, Instituto de Fsica de So Carlos - Universidade
de So Paulo, So Carlos, SP, June 1997.
[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 flow 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, Banff
- Canad, July 1986. Computer Science Press.
42
[40] A. P. Mathur. On the relative strengths of data flow and mutation testing. In Ninth Annual
Pacific Northwest Software Quality Conference, pages 165181, Portland, OR, October
1991.
[41] A. P. Mathur and W. E. Wong. An empirical comparison of data flow and mutation
based test adequacy criteria. The Journal of Software Testing, Verification, and Relability,
4(1):931, March 1994.
[42] W. E. Wong. On Mutation and Data Flow. PhD thesis, Department of Computer Science,
Purdue University, W. Lafayette, IN, December 1993.
[45] A. P. Mathur and W. E. Wong. Evaluation of the cost of alternate mutation strategies. In
7th Brazilian Symposium on Software Engineering, pages 320335, Rio de Janeiro, RJ,
Brazil, October 1993.
43
[52] R. A. Demillo. Mutation analysis as a tool for software quality assurance. In COMP-
SAC80, pages , Chicago, IL, October 1980.
[53] R. A. DeMillo, D. S. Gwind, K. N. King, W. N. McKraken, and A. J. Offutt. An exten-
ded overview of the mothra testing environment. In Software Testing, Verification and
Analysis, Banff, Canad, July 1988.
[54] M. Luts. Testing tools. IEEE Software, 7(3), May 1990.
[55] F. G. Frankl and E. J. Weyuker. Data flow 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 flow coverage and the C language. In Symposium
Software Testing, Analysis, and Verification, pages 8797, October 1991.
[58] B. Korel and J. W. Laski. A tool for data flow oriented program testing. In Softfair II,
pages 3438, San Francisco, CA, December 1985.
[59] T. J. Ostrand and E. J. Weyuker. Data flow based test adequacy for languages with
pointers. In Symposium on Software Testing, pages 7486, October 1996.
[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, So
Paulo, SP, September 1989.
[61] M. L. Chaim. Poke-tool uma ferramenta para suporte ao teste estrutural de progra-
mas baseado em anlise de fluxo de dados. Masters thesis, DCA/FEEC/UNICAMP,
Campinas, SP, April 1991.
[62] M. E. Delamaro. Proteum: Um ambiente de teste baseado na anlise de mutantes. Mas-
ters thesis, ICMC/USP, So Carlos - SP, October 1993.
[63] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Proteum/FSM U
uma ferramenta para apoiar a validao de mquinas de estado finito pelo critrio anlise
de mutantes. In IX Simpsio Brasileiro de Engenharia de Software, 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 submited.
[66] R. A Demillo. Software Testing and Evaluation. The Benjamin/Cummings Publishing
Company Inc 1987.
44
[67] E. J. Weyuker and T. Ostrand. Theory of program testing and the application of revealing
subdomains. IEEE Transactions on Software Engineering, 6, June 1980.
[68] U. Linnenkugel and M. Mllerburg. Test data selection criteria for (software) integra-
tion testing. In First International Conference on Systems Integration, pages 709717,
Morristown, NJ, April 1990.
[70] R. A. DeMillo and A. J. Offutt. Constraint based automatic test data generation. IEEE
Transactions on Software Engineering, SE-17(9):900910, September 1991.
[73] M. J. Harrold and G. Rothermel. Performing data flow testing on classes. In Second
ACM SIGSOFT Symposium on Foundations of Software Engineering, pages 154163,
New York, December 1994. ACM Press.
[74] 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 Enginee-
ring, pages 186195, Monterey, CA, November 1994.
[75] 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.
[76] W. E. Wong and A. P. Mathur. Fault detection effectiveness of mutation and data flow
testing. Software Quality Journal, 4(1):6983, March 1995.
[78] H. Agrawal, J. Alberi, J. R. Horgan, J. Li, S. London, W. E. Wong, S. Ghosh, and N. Wil-
de. Mining system tests to aid software maintenance. ieeec, pages 6473, July 1998.
[79] IEEE. Ieee standard glossary of software engineering terminology. Standard 610.12,
IEEE Press, 1990.
45
[80] 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] E. J. Weyuker. The complexity of data flow for test data selection. Information Proces-
sing Letters, 19(2):103109, August 1984.
[84] E. J. Weyuker and B. Jeng. Analyzing partition testing strategies. IEEE Transactions on
Software Engineering, 17(7):703711, July 1991.
[85] H. Zhu. A formal analysis of the subsume relation between software test adequacy crite-
ria. IEEE Transactions on Software Engineering, SE-22(4):248255, April 1996.
[86] E. J. Weyuker. The cost of data flow testing: an empirical study. IEEE Transactions on
Software Engineering, SE-16(2):121128, February 1990.
[89] W. E. Howden. Functional Program Testing and Analysis. McGrall-Hill, New York,
1987.
[90] M. R. Woodward, D. Heddley, and M. A. Hennel. Experience with path analysis and
testing of programs. IEEE Transactions on Software Engineering, SE-6:278286, May
1980.
[91] W. Howden. Methodology for the generation of program test data. IEEE Computer,
C-24(5):554559, May 1975.
[92] S. R. Verglio, J. C. Maldonado, and M. Jino. Uma estratgia para a gerao de dados
de teste. In VII Simpsio Brasileiro de Engenharia de Software, pages 307319, Rio de
Janeiro, RJ, October 1993.
[93] C. Ghezzi and M. Jazayeri. Programming Languages Concepts. John Wiley and Sons,
New York, 2 edition, 1987.
46
[94] 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.
[95] M. J. Harrold and M. L. Soffa. Selecting and using data for integration test. IEEE
Software, 8(2):5865, March 1991.
[96] Z. Jin and A. J. Offut. Integration testing based on software couplings. In X Annual Con-
ference on Computer Assurance (COMPASS 95), pages 1323, Gaithersburg, Maryland,
January 1995.
[97] P. R. S. Vilela. Critrios Potenciais Usos de Integrao: Definio e Anlise. PhD thesis,
DCA/FEEC/UNICAMP, Campinas, SP, April 1998.
[98] P. S. J. Leit ao. Suporte ao teste estrutural de programas cobol no ambiente poke-tool.
Masters thesis, DCA/FEE/UNICAMP, Campinas, SP, August 1992.
[100] T. Chusho. Test data selection and quality estimation based on concept of essential bran-
ches for path testing. IEEE Transactions on Software Engineering, 13(7):509517, 1987.
[102] A. D. Friedman. Logical Design of Digital Systems. Computer Science Press, 1975.
[103] M. E. Delamaro and J. C. Maldonado. Proteum - a tool for the assesment of test adequacy
for C programs. In Conference on Performability in Computing Systems (PCS 96), pages
7995, Brunswick, NJ, July 1996.
[106] T. A. Budd. Mutation Analysis of Program Test Data. PhD thesis, Yale University, New
Haven, CT, 1980.
[107] 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 Verification, pages
5865, Key West, FL, December 1989.
47
[108] E. W. Krauser, A. P. Mathur, and V. J. Rego. High performance software testing on simd
machines. IEEE Transactions on Software Engineering, SE-17(5):403422, May 1991.
[110] B. J. Choi and A. P. Mathur. High-performance mutation testing. The Journal of Systems
and Software, 1(20):135152, February 1993.
[114] A. T. Acree. On Mutation. PhD thesis, Georgia Institute of Technology, Atlanta, GA,
1980.
[115] 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, Anaheim - CA, November 1999.
[118] A. J. Offutt, J. Pan, K. Tewary, and T. Zhang. An experimental evaluation of data flow
and mutation testing. Software Practice and Experience, 26(2):165176, 1996.
[119] W.E. Wong, J.C. Maldonado, M.E. Delamaro, and S.R.S. Souza. A comparison of selec-
tive mutation in C and fortran. In Workshop of the Validation and Testing of Operational
Systems Project, pages 7180, guas de Lindia - SP - Brazil, January 1997.
[120] M. E. Delamaro, J. C. Maldonado, and A. P. Mathur. Proteum - a tool for the assesment of
test adequacy for C programs - users guide. Technical Report SERC-TR168-P, Software
Engineering Research Center, Purdue University, April 1996.
48
[121] M. E. Delamaro, J. C. Maldonado, and A. P. Mathur. Interface mutation: An approach
for integration testing. IEEE Transactions on Software Engineering, (to appear).
49